Тихо и незаметно подкралась ко мне задача оптимизировать работу своих серверов. Долго я её откладывал и совсем не хотел ей заниматься, НО настало время когда нужно было что то делать. Итак первым делом мы в нашем отделе решили, что наверное как то неразумно использовать на каждом своём сервере Postgresql сервер, и решили вынести всё на отдельную мощную машинку.
Итак заказали мы машинку, долго её ждали, и жутко обрадовались когда эта самая машинка поселилась в нашей серверной. Поставили мы на неё «базу» и начали тестировать развернув по копии базы каждого из имеющихся у нас проектов. Вроде всё работало положительно, НО тут образовался вопрос: а что делать если вдруг машинка упадёт ?!
После долгих споров было решено для резервирования приобрести еще один сервер. И опять мы ждали, пока не пропишется у нас в серверной и вторая машинка. И вот это случилось!
Теперь нужно было решить каким способом мы будем эти самые данные резервировать, да еще и так чтобы данные на одном сервере были всегда актуальны, а именно чтобы в любой момент времени данные на обеих машинах были абсолютно идентичны. Порылись в интернете и нашли 3 живых проекта, реализующих репликацию postgres.
Итак первый из них был Pgpool. Поставить и сконфигурировать его особого труда не составило. Но сразу не понравилось что pgpool не поддерживает md5 шифрование в режиме репликации — это сразу очень сильно покоробило. Да и работал он всё таки не так как нам бы хотелось на тот момент. И было решено отказаться от данного решения.
Вторым способом был избран Slony-I из за большого количества доступной документации. Хотя сразу нам не понравилось что всё как то сложно и геморно. Но ничего, нам не привыкать. Поставили настроили, заработало! И думали что вот оно решение которое мы так долго искали, даже уже написали какие то скрипты для автоматического добавления баз данных и таблиц в реплецируемый кластер, ан нет и тут оказалось не всё так гладко. Во первых когда пришло время обновления одного из проектов, мы в ужасе узнали что slony-I не умеет DDL, а при обновлении проекта как раз требовалось создать новые колонки в одной из таблиц. Ну что ж, подумал я, значит проведем изменения в базе сначала на мастер сервере, а потом уже и на слэйве и всё у нас будет реплецироваться замечательно. Ан нет, не тут то было! Оказывается Slon-I при старте репликации успешно заблокировал таблицы на slave сервере и проведя успешные изменения таблицы на мастер сервере, на слэйве нам это сделать не удалось, после этого было найдено решение: slony.info/documentation/ddlchanges.html. Но нам показалось что использовать его постоянно( а обновления у нас процедура довольно частая ) это слишком неудобно и не комфортно. И тут было принято решение, которого я сильно опасался по причине отсутствия на тот момент хоть мало мальски внятной документации у проекта. А именно решено было попробовать skytools(londiste) от Skype.
Сейчас уже можно сказать, что зря я наверно тогда так сильно волновался по поводу Londiste. Всё оказалось очень просто, а что, наверное, самое главное работоспособно и надёжно. Итак установка:
Сразу скажу что мы используем CentOs на своих серверах. Сначала необходимо всё правильно поставить. SkyTools есть в репозиториях постгреса для CentOs, но проблема заключается что в этом пакете не включены модули дополнительные, а именно Pgq_LowLevel. Поэтому сделал следующее:
Скачал последнюю версию skytools с сайта, сконфигурил, скомпилировал, и взял оттуда лишь модули для питона Pgq_LowLevel, затем поставил пакет( благо версии пакета в репозитории и модулей совпали) и скопировал модули pgq_lowlevel.so, pgq_triggers.so, logtriga.so в /usr/lib/pgsql/.
Всё дальше можно переходить к репликации.
Теперь все нижеследующие действия будут проходить от пользователя postgres и только на master сервере, но нужно учесть, что на слэйв сервер был доступ для пользователя владеющего базой данных, то есть должна выполняться команда:
Теперь нужно установить pgqadmin. Создаём любой файл следующего содержания:
в моём случае это файл /etc/pgq_database_name.
Дальше «проинсталлируем» pgq для каждой конкретной базы.
Pапускаем pgqadm в режиме демона
Создаём очередь и регистрируем консьюмер для каждой базы.
Теперь когда создана очередь, мы можем начать нашу репликацию. Создаём файл /etc/londiste_your_cluster_name.ini вида:
Когда файл создан запускаем londiste:
Добавляем таблицы для репликации и запустим репликацию:
Так же нужно заметить что у каждой реплицируемой таблицы должен быть Primary Key.
Вот собственно и всё. Теперь Оставалось протестировать всё это. Собственно DDL londiste так же как и Slony-I тоже не умеет, зато при репликации он не блокирует таблицы на Slave сервере и мы можем спокойно производить изменения таблиц на как на слэйве так и на мастер сервере. Был написан сценарий для capistrano(с его помощью у нас выкатываются все последние изменения и апдейты ) который проводит изменения на 2 хостах сразу. Работает всё это очень быстро. Крайне удобно всем этим управлять благодаря средствам Londiste. Добавить например таблицу или же удалить её из репликации труда особого не составляет.
После всего написал плагины для нагиоса для мониторинга репликации. Вернее даже сказать что они просто дёргают сначала из одной, а потом из другой базы количество записей в одной из таблиц и сравнивают их. Так же монитором наличие процесса londiste.py replay но это всё уже просто на всякий случай, пербоев и прерываний репликации к счастью пока не было, надеюсь не будет и впредь.
После успешного тестирования данной системы, потизоньку перетащили все базы с локальных хостов на один выделенный сервер, что принесло весьма положительный эффект и сейчас очень этим довольны.
P.S. Не ругайте сильно, если что не так, это моя первая статья на хабре.
Итак заказали мы машинку, долго её ждали, и жутко обрадовались когда эта самая машинка поселилась в нашей серверной. Поставили мы на неё «базу» и начали тестировать развернув по копии базы каждого из имеющихся у нас проектов. Вроде всё работало положительно, НО тут образовался вопрос: а что делать если вдруг машинка упадёт ?!
После долгих споров было решено для резервирования приобрести еще один сервер. И опять мы ждали, пока не пропишется у нас в серверной и вторая машинка. И вот это случилось!
Теперь нужно было решить каким способом мы будем эти самые данные резервировать, да еще и так чтобы данные на одном сервере были всегда актуальны, а именно чтобы в любой момент времени данные на обеих машинах были абсолютно идентичны. Порылись в интернете и нашли 3 живых проекта, реализующих репликацию postgres.
Итак первый из них был Pgpool. Поставить и сконфигурировать его особого труда не составило. Но сразу не понравилось что pgpool не поддерживает md5 шифрование в режиме репликации — это сразу очень сильно покоробило. Да и работал он всё таки не так как нам бы хотелось на тот момент. И было решено отказаться от данного решения.
Вторым способом был избран Slony-I из за большого количества доступной документации. Хотя сразу нам не понравилось что всё как то сложно и геморно. Но ничего, нам не привыкать. Поставили настроили, заработало! И думали что вот оно решение которое мы так долго искали, даже уже написали какие то скрипты для автоматического добавления баз данных и таблиц в реплецируемый кластер, ан нет и тут оказалось не всё так гладко. Во первых когда пришло время обновления одного из проектов, мы в ужасе узнали что slony-I не умеет DDL, а при обновлении проекта как раз требовалось создать новые колонки в одной из таблиц. Ну что ж, подумал я, значит проведем изменения в базе сначала на мастер сервере, а потом уже и на слэйве и всё у нас будет реплецироваться замечательно. Ан нет, не тут то было! Оказывается Slon-I при старте репликации успешно заблокировал таблицы на slave сервере и проведя успешные изменения таблицы на мастер сервере, на слэйве нам это сделать не удалось, после этого было найдено решение: slony.info/documentation/ddlchanges.html. Но нам показалось что использовать его постоянно( а обновления у нас процедура довольно частая ) это слишком неудобно и не комфортно. И тут было принято решение, которого я сильно опасался по причине отсутствия на тот момент хоть мало мальски внятной документации у проекта. А именно решено было попробовать skytools(londiste) от Skype.
Сейчас уже можно сказать, что зря я наверно тогда так сильно волновался по поводу Londiste. Всё оказалось очень просто, а что, наверное, самое главное работоспособно и надёжно. Итак установка:
Сразу скажу что мы используем CentOs на своих серверах. Сначала необходимо всё правильно поставить. SkyTools есть в репозиториях постгреса для CentOs, но проблема заключается что в этом пакете не включены модули дополнительные, а именно Pgq_LowLevel. Поэтому сделал следующее:
Скачал последнюю версию skytools с сайта, сконфигурил, скомпилировал, и взял оттуда лишь модули для питона Pgq_LowLevel, затем поставил пакет( благо версии пакета в репозитории и модулей совпали) и скопировал модули pgq_lowlevel.so, pgq_triggers.so, logtriga.so в /usr/lib/pgsql/.
Всё дальше можно переходить к репликации.
Теперь все нижеследующие действия будут проходить от пользователя postgres и только на master сервере, но нужно учесть, что на слэйв сервер был доступ для пользователя владеющего базой данных, то есть должна выполняться команда:
psql -h slave.server.r -U your_user -d your_database
Теперь нужно установить pgqadmin. Создаём любой файл следующего содержания:
[pgqadm]
job_name = your_cluster_name
db = dbname=your_database_name
# how often to run maintenance [seconds]
maint_delay = 600
# how often to check for activity [seconds]
loop_delay = 0.1
logfile = ~/log/%(job_name)s.log
pidfile = ~/pid/%(job_name)s.pid
в моём случае это файл /etc/pgq_database_name.
Дальше «проинсталлируем» pgq для каждой конкретной базы.
$ pgqadm.py /etc/pgq_database_name install
Pапускаем pgqadm в режиме демона
$ pgqadm.py -d /etc/pgq_database_name
Создаём очередь и регистрируем консьюмер для каждой базы.
$ pgqadm.py create your_queue
$ pgqadm.py /ect/pgq_databse_name register your_queue your_consumer
Теперь когда создана очередь, мы можем начать нашу репликацию. Создаём файл /etc/londiste_your_cluster_name.ini вида:
[londiste]
job_name = your_cluster_name
provider_db = dbname=your_database
subscriber_db = dbname=your_database port=5432 host=slave.server.r user=files_testing password=your_password
# it will be used as sql ident so no dots/spaces
pgq_queue_name = your_queue
logfile = /tmp/%(job_name)s.log
pidfile = /tmp/%(job_name)s.pid
Когда файл создан запускаем londiste:
londiste.py /etc/londiste_your_cluster_name.ini provider install
londiste.py /etc/londiste_your_cluster_name.ini subscriber install
Добавляем таблицы для репликации и запустим репликацию:
londiste.py /etc/londiste_your_cluster_name.ini provider add table1 table2 table3
londiste.py /etc/londiste_your_cluster_name.ini subscriber add table1 table2 table3
londiste.py -d /etc/londiste_your_cluster_name.ini replay
Так же нужно заметить что у каждой реплицируемой таблицы должен быть Primary Key.
Вот собственно и всё. Теперь Оставалось протестировать всё это. Собственно DDL londiste так же как и Slony-I тоже не умеет, зато при репликации он не блокирует таблицы на Slave сервере и мы можем спокойно производить изменения таблиц на как на слэйве так и на мастер сервере. Был написан сценарий для capistrano(с его помощью у нас выкатываются все последние изменения и апдейты ) который проводит изменения на 2 хостах сразу. Работает всё это очень быстро. Крайне удобно всем этим управлять благодаря средствам Londiste. Добавить например таблицу или же удалить её из репликации труда особого не составляет.
После всего написал плагины для нагиоса для мониторинга репликации. Вернее даже сказать что они просто дёргают сначала из одной, а потом из другой базы количество записей в одной из таблиц и сравнивают их. Так же монитором наличие процесса londiste.py replay но это всё уже просто на всякий случай, пербоев и прерываний репликации к счастью пока не было, надеюсь не будет и впредь.
После успешного тестирования данной системы, потизоньку перетащили все базы с локальных хостов на один выделенный сервер, что принесло весьма положительный эффект и сейчас очень этим довольны.
P.S. Не ругайте сильно, если что не так, это моя первая статья на хабре.