Embed Size (px)
Citation preview
Перевод новостного приложенияна базу данных PostgreSQL
Meetup в Mail.ru3 ноября 2015
Дмитрий КремерАдминистратор баз данных
E-mail: [email protected] jabber: [email protected]
#PostgreSQLRussia
Title:mail.ru.eps Creator:Adobe Illustrator(R) 15.0 CreationDate:7/11/2010 LanguageLevel:2
МИА «Россия сегодня»● Ведущее международное новостное агентство с 1941 года (тогда СовИнформБюро)
● Крупнейший поставщик новостного и медиа-контента в Российской Федерации (бренды РИА Новости иSputnik News)
● Фотохостинг Олимпиады в Сочи 2014
● Десятки корреспондентов по всей России
● Современные мультимедиа-прессцентры в Москве и Симферополе
● Платформы в социальных сетях
● Производство и распространение фотоконтента, инфографики, контента для мобильных приложений.
Дмитрий Кремер
● Опыт работы с различными базами данных в качестве разработчика и системного администратора с 1999 года.
● Непрерывный опыт работы с БД Oracle c 2007 года
● Oracle Certified Professional 9i, 10g
● Начал работать с PostgreSQL в мае 2015 года.
Особенности новостного приложения
● Работа в режиме 24/7. Прерывание работы сайтов должна стремиться к нулю.Прерывание сервисов выпуска допустимо на минуты в периоды минимальнойнагрузки.
● Использование движка (структур данных и кода приложений) собственной разработки,стандартизация кодовой базы проектов.
● Трёхзвенная архитектура — бизнес-логика на сервере приложений
● Использование преимущестенно свежих данных (partitioning)
● Многоязычность (UTF-8)
● Необходимость использования полнотекстового поиска (Solr, tsearch2 и т. д.)
● Solr — поиск на сайте
● tsearch2 — поиск в редакторском интерфейсе
Требования к переводу
● Избежать деградации производительности и отказоустойчивости системы.
● Избежать существенной деградации уровня контроля над системой, мониторинга истредств разрешения проблем (troubleshooting).
● По возможности не касаться структуры БД — одно из требований миграции.
● Все изменения должны быть максимально прозрачными для движка приложения.
● Минимизация простоя.
● Предварительная подготовка структуры БД.
● Использование собственных скриптов.
● Миграция данных + накат дэльты
Особенности конвертации БД
● Серьезное отличие средств и методик диагностики проблем и мониторинга
● Использование пула соединений pgbouncer в транзакционном режиме
● Необходимость сопоставления типов (различные варианты хранения числовыхзначений, дат и т.д.)
● Автоматическая конвертация исключительно структур данных без хранимых объектов.Использование Ora2Pg для получения первичного варианта структур данных.
● В исходной БД и PostgreSQL данные об объектах в словаре (dictionary иinformation_schema + pg_catalog) хранятся в разных регистрах. Dictionary — в верхнем,information_schema + pg_catalog — в нижнем. Поэтому использование кавычек вназваниях объектов должно быть объектом пристального внимания!!!
Производительность системы
● 40+ проектов (баз данных) на одном сервере БД.
● 124 миллиона транзакций в сутки
● 8 тысяч запросов в секунду
● 1200 DML операций в секунду
● 300+ vacuum операций в сутки
● Среднее время запросов 5ms
Особенности настройки БД
● Авторизация и аутентификация пользователей
● Настройка autovacuum (согласно презентации Ильи Космодемьянского)
http://www.slideshare.net/PostgreSQL-Consulting/postgresql-meetup-berlin-at-zalando-hq
● Агрессивные настройки в БД
● Понижение приоритета процесса autovacuum в операционной системе
● Настройка streaming replication
● Использование шаблонов базы данных для развёртывания стандартных проектов
● Логи пишутся на syslog-сервер
Авторизация и аутентификация пользователей
● Аутентификация пользователей через pgbouncer
● Хеши паролей пользователей хранятся не в БД, а в конфигурационном файле pgbouncer
● Пользователи с привилегиями DDL-операций соединяются с БД только локально из ssh-сессии или ssh-тунеля (поддерживается EMS SQL Manager for PostgreSQL)
● Пользователь для реплики создаётся исключительно с правами replication без праваlogin. Это единственный пользователь, который соединяется с БД удалённо минуяpgbouncer. В pg_hba.conf соединение разрешено только между реплицируемыми нодамии сервером бэкапа.
● Авторизация пользователей
● Для приложений каждого проекта создаётся свой пользователь с минимальнымипривилегиями
● Для пользователей DevOps создана соответствующая роль-владелец объектов без праваlogin от которой наследуются привилегии для конкретных пользователей
Настройка streaming replication
● Симметричная конфигурация
● Отказ от триггерного файла, ручное переключение ролей репликации, безшовныйпереход с мастер-сервера на сервер реплики (standby) без смены timeline
● wal_level = hot_standby
wal_keep_segments = 500
hot_standby = on
hot_standby_feedback = on
Backup и PITR-сервер
● Доставка wal-логов с использованием демона lsyncd и подсстемы ядра Linuxобработки событий файловой системы inotify.
● После очистки каталога wal-огов на мастере демон lsyncd нужно перезапустить спроверкой очистки дочерних ssh-процессов, а лучше остановить, почистить, запуститьlsyncd
● Резервное копирование с использованием pg_basebackup с опцией --xLog — созданиебэкапа, готового к восстановлению.
● Полное дублирование компонентов архитектуры
● Использование Point In Time Recovery (PITR) сервера для замены функционала OracleFlashback Database (не является аналогом этой технологии)
● Использование pg_switch_xlog() для создания точки восстановления.
Доставка wal-логов с использованием lsyncd
Конфигурация lsyncd#cat lsyncd/lsyncd.conf.templatesettings { logfile = "/var/log/lsyncd/lsyncd.log", statusFile = "/var/log/lsyncd-status.log", nodaemon = false, statusInterval = 20}
sync { default.rsync, source="@@arch_dir@@", target="@@slave_host@@:@@wal_dir@@", rsync = { binary = "/usr/bin/rsync", rsh = "/usr/bin/ssh -l postgres -i /data/home/postgres/.ssh/id_rsa -o StrictHostKeyChecking=no", archive = true, compress = false, owner = true, perms = true, whole_file = false, checksum = true }, delete = false}
sync { default.rsync, source="@@arch_dir@@", target="@@pitr_host@@:/data/bckp/@@short_name@@/pgwal/", rsync = { binary = "/usr/bin/rsync", rsh = "/usr/bin/ssh -l postgres -i /data/home/postgres/.ssh/id_rsa -o StrictHostKeyChecking=no", archive = true, compress = false, owner = true, perms = true, whole_file = false, checksum = true }, delete = false}
Мониторинг и производительность
● Использование Zabbix
● За основу взят шаблон https://github.com/lesovsky/zabbix-extensions
● Доработка дискавера БД+таблица
● Использование pg_buffercache и pg_stat_statements
● Выставить параметры в postgresql.conf:
shared_preload_libraries = 'pg_stat_statements'
pg_stat_statements.max = 10000
pg_stat_statements.track = all
● Использование pgBadger (объём логов, ротация)
● pgBadger установлен на syslog-серверах
● Ротация логов каждый час: инкрементальное добавление данных в отчёт, ротация и сжатие часового лога
Благодарности:
● Сергею Томулевичу — за помощь в подготовке выступления
● Алексею Лесовскому — за шаблон мониторинга PostgreSQL на Zabbix
● Николаю Самохвалову — за приглашение на мероприятие в качестве спикера.
Спасибо за внимание!Вопросы?
Meetup в Mail.ru3 ноября 2015
Дмитрий КремерАдминистратор баз данных
E-mail: [email protected] jabber: [email protected]
#PostgreSQLRussia
Title:mail.ru.eps Creator:Adobe Illustrator(R) 15.0 CreationDate:7/11/2010 LanguageLevel:2
