Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Перевод новостного приложения
на базу данных PostgreSQL
Meetup в Mail.ru
3 ноября 2015
Дмитрий Кремер
Администратор баз да...
МИА «Россия сегодня»
● Ведущее международное новостное агентство с 1941 года (тогда СовИнформБюро)
● Крупнейший поставщик ...
Особенности новостного приложения
● Работа в режиме 24/7.Прерывание работы сайтов должна стремиться к нулю.
Прерывание сер...
Требования к переводу
● Избежать деградации производительности и отказоустойчивости системы.
● Избежать существенной дегра...
Особенности конвертации БД
● Серьезное отличие средств и методик диагностики проблем и мониторинга
● Использование пула со...
Производительность системы
● 40+ проектов (баз данных) на одном сервере БД.
● 124 миллиона транзакций в сутки
● 8 тысяч за...
Особенности настройки БД
● Авторизация и аутентификация пользователей
● Настройка autovacuum (согласно презентации Ильи Ко...
Авторизация и аутентификация пользователей
● Аутентификация пользователей через pgbouncer
● Хеши паролей пользователей хра...
Настройка streaming replication
● Симметричная конфигурация
● Отказ от триггерного файла,ручное переключение ролей реплика...
Backup и PITR-сервер
● Доставка wal-логов с использованием демона lsyncd и подсстемы ядра Linux
обработки событий файловой...
Доставка wal-логов с использованием lsyncd
Конфигурация lsyncd
#cat lsyncd/lsyncd.conf.template
settings {
logfile = "/var/log/lsyncd/lsyncd.log",
statusFile = "/var...
Мониторинг и производительность
● Использование Zabbix
● За основу взят шаблон https://github.com/lesovsky/zabbix-extensio...
Благодарности:
● Сергею Томулевичу —за помощь в подготовке выступления
● Алексею Лесовскому —за шаблон мониторинга Postgre...
Спасибо за внимание!
Вопросы?
Meetup в Mail.ru
3 ноября 2015
Дмитрий Кремер
Администратор баз данных
E-mail: d.kremer@rian...
Upcoming SlideShare
Loading in …5
×

Перевод новостного приложения на БД PostgreSQL

663 views

Published on

#PostreSQLRussia MeetUp at Mail.ru office

Published in: Software

Перевод новостного приложения на БД PostgreSQL

  1. 1. Перевод новостного приложения на базу данных PostgreSQL Meetup в Mail.ru 3 ноября 2015 Дмитрий Кремер Администратор баз данных E-mail: d.kremer@rian.ru jabber: dmitry.kremer@gmail.com #PostgreSQLRussia
  2. 2. МИА «Россия сегодня» ● Ведущее международное новостное агентство с 1941 года (тогда СовИнформБюро) ● Крупнейший поставщик новостного и медиа-контента в Российской Федерации (бренды РИА Новости и Sputnik News) ● Фотохостинг Олимпиады в Сочи 2014 ● Десятки корреспондентов по всей России ● Современные мультимедиа-прессцентры в Москве и Симферополе ● Платформы в социальных сетях ● Производство и распространение фотоконтента,инфографики,контента для мобильных приложений. Дмитрий Кремер ● Опыт работы с различными базами данных в качестве разработчика и системного администратора с 1999 года. ● Непрерывный опыт работы с БД Oracle c 2007 года ● Oracle Certified Professional 9i,10g ● Начал работать с PostgreSQL в мае 2015 года.
  3. 3. Особенности новостного приложения ● Работа в режиме 24/7.Прерывание работы сайтов должна стремиться к нулю. Прерывание сервисов выпуска допустимо на минуты в периоды минимальной нагрузки. ● Использование движка (структур данных и кода приложений) собственной разработки, стандартизация кодовой базы проектов. ● Трёхзвенная архитектура —бизнес-логика на сервере приложений ● Использование преимущестенно свежих данных (partitioning) ● Многоязычность (UTF-8) ● Необходимость использования полнотекстового поиска (Solr,tsearch2 и т. д.) ● Solr —поиск на сайте ● tsearch2 —поиск в редакторском интерфейсе
  4. 4. Требования к переводу ● Избежать деградации производительности и отказоустойчивости системы. ● Избежать существенной деградации уровня контроля над системой,мониторинга и стредств разрешения проблем (troubleshooting). ● По возможности не касаться структуры БД —одно из требований миграции. ● Все изменения должны быть максимально прозрачными для движка приложения. ● Минимизация простоя. ● Предварительная подготовка структуры БД. ● Использование собственных скриптов. ● Миграция данных + накат дэльты
  5. 5. Особенности конвертации БД ● Серьезное отличие средств и методик диагностики проблем и мониторинга ● Использование пула соединений pgbouncer в транзакционном режиме ● Необходимость сопоставления типов (различные варианты хранения числовых значений,дат и т.д.) ● Автоматическая конвертация исключительно структур данных без хранимых объектов. Использование Ora2Pg для получения первичного варианта структур данных. ● В исходной БД и PostgreSQL данные об объектах в словаре (dictionary и information_schema + pg_catalog) хранятся в разных регистрах.Dictionary —в верхнем, information_schema + pg_catalog —в нижнем.Поэтому использование кавычек в названиях объектов должно быть объектом пристального внимания!!!
  6. 6. Производительность системы ● 40+ проектов (баз данных) на одном сервере БД. ● 124 миллиона транзакций в сутки ● 8 тысяч запросов в секунду ● 1200 DML операций в секунду ● 300+ vacuum операций в сутки ● Среднее время запросов 5ms
  7. 7. Особенности настройки БД ● Авторизация и аутентификация пользователей ● Настройка autovacuum (согласно презентации Ильи Космодемьянского) http://www.slideshare.net/PostgreSQL-Consulting/postgresql-meetup-berlin-at-zalando-hq ● Агрессивные настройки в БД ● Понижение приоритета процесса autovacuum в операционной системе ● Настройка streaming replication ● Использование шаблонов базы данных для развёртывания стандартных проектов ● Логи пишутся на syslog-сервер
  8. 8. Авторизация и аутентификация пользователей ● Аутентификация пользователей через pgbouncer ● Хеши паролей пользователей хранятся не в БД,а в конфигурационном файле pgbouncer ● Пользователи с привилегиями DDL-операций соединяются с БД только локально из ssh- сессии или ssh-тунеля (поддерживается EMS SQL Manager for PostgreSQL) ● Пользователь для реплики создаётся исключительно с правами replication без права login.Это единственный пользователь,который соединяется с БД удалённо минуя pgbouncer.В pg_hba.conf соединение разрешено только между реплицируемыми нодами и сервером бэкапа. ● Авторизация пользователей ● Для приложений каждого проекта создаётся свой пользователь с минимальными привилегиями ● Для пользователей DevOps создана соответствующая роль-владелец объектов без права login от которой наследуются привилегии для конкретных пользователей
  9. 9. Настройка streaming replication ● Симметричная конфигурация ● Отказ от триггерного файла,ручное переключение ролей репликации,безшовный переход с мастер-сервера на сервер реплики (standby) без смены timeline ● wal_level = hot_standby wal_keep_segments = 500 hot_standby = on hot_standby_feedback = on
  10. 10. Backup и PITR-сервер ● Доставка wal-логов с использованием демона lsyncd и подсстемы ядра Linux обработки событий файловой системы inotify. ● После очистки каталога wal-огов на мастере демон lsyncd нужно перезапустить с проверкой очистки дочерних ssh-процессов,а лучше остановить,почистить,запустить lsyncd ● Резервное копирование с использованием pg_basebackup с опцией --xLog —создание бэкапа,готового к восстановлению. ● Полное дублирование компонентов архитектуры ● Использование Point In Time Recovery (PITR) сервера для замены функционала Oracle Flashback Database (не является аналогом этой технологии) ● Использование pg_switch_xlog() для создания точки восстановления.
  11. 11. Доставка wal-логов с использованием lsyncd
  12. 12. Конфигурация lsyncd #cat lsyncd/lsyncd.conf.template settings { 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 }
  13. 13. Мониторинг и производительность ● Использование 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-серверах ● Ротация логов каждый час: инкрементальное добавление данных в отчёт,ротация и сжатие часового лога
  14. 14. Благодарности: ● Сергею Томулевичу —за помощь в подготовке выступления ● Алексею Лесовскому —за шаблон мониторинга PostgreSQL на Zabbix ● Николаю Самохвалову —за приглашение на мероприятие в качестве спикера.
  15. 15. Спасибо за внимание! Вопросы? Meetup в Mail.ru 3 ноября 2015 Дмитрий Кремер Администратор баз данных E-mail: d.kremer@rian.ru jabber: dmitry.kremer@gmail.com #PostgreSQLRussia

×