- PVSM.RU - https://www.pvsm.ru -
Все доброго времени суток!
Как известно, недавно вышел PostgreSQL 9.2 [1] с массой интересных и полезных вещей. Недолго думая мы решили обновить наш кластер потоковой репликации с 9.0 на 9.2. Все бы ничего, если бы не несколько обстоятельств:
Чтож, так даже интересней… Как мы это делали и что из этого вышло читайте дальше.
Зачем все это?
Дано:
Сложности:
Какой мы нашли выход?
Выход в использовании Londiste из пакета Skytools-3.0, однажды мы уже переезжали с его помощью с 8.4 на 9.0, поэтому опыт есть. Репликация с Londiste удобна тем что позволяет реплицировать отдельные таблицы и базы в кластере (к примеру потоковая репликация, реплицирует целиком кластер). Плюс ко всему относительно прошлого переезда у нас появилась потоковая репликация. И это тоже не проблема. Данные среплицированные через Londiste будем тут же реплицировать на свежеподнятый слейв 9.2 с помощью потоковой репликации. Отличная выходит схема: среплицировавшись на 9.2 мы прозрачно заполним данными слейв 9.2. Итак схема и алгоритм задачи:
1. Админская часть:
Итак с технической стороны все готово. Теперь остается спланировать ход выполнения репликации и момент переключения. Днем переключения выбрана суббота. Если что-то пойдет не так, у нас остается воскресенье. Мероприятия мы разбили на две стадии, подготовительная стадия и стадия переключения. Как же будет выполняться переключение? Для этого мы ввели два новых DNS-имени для новой связки 9.2: db-master и db-slave. В нужный момент мы пропишем эти имена в конфиги бэкендов и перезапустим приложения.
Часть мероприятий подготовительного плана уже описана выше, но для полноты картины я их все же оставлю в кратком виде:
До пятницы:
Пятница:
Суббота: это день переключения:
11.00-12.00 приостановка редактирования:
12.00-12.30 переключение:
Всё. после этого репликация через londiste становится неконсистентной, так как вся внешняя запись (источник записи — клиенты на сайте) пошла в кластер 9.2;
После переключения:
После переезда
Откат. План на случай если что-то пойдет не так:
Собственно весь алгоритм. По ходу мероприятия конечно же не все прошло в соответствии с генеральным планом. К счастью прибегнуть к плану отката не пришлось.
Если говорить о том что пошло не так, то тут всего пара пунктов,
первый пункт касается недавно введенного в строй сервиса и механизма ручного переноса схем (которого вобще желательно избегать). Пара слов о сервисе: завалился сервис основанный на работе pgq, несовсем было понятно как реплицировать схему pgq (pgq являлся сам частью механизма репликации). Перенос вручную тоже не исправил ситуацию, поэтому пришлось переинициализировать схему и перезапускать сервис (благо это некритично, но все же косяк).
Про перенос схем… практика показала что перенос схем не всегда проходит как хочется. Учитывая что схема всей базы создается на раннем этапе настройки репликации, в дальнейшем приходится переносить либо схему поверх существующих объектов, либо отдельные данные, то в ходе переноса можно напороться на ошибки типа:
ERROR: insert or update on table violates foreign key constraint
DETAIL: Key is not present in table.
Отсюда вывод что перенос схем лучше делать так:
Переименовываем существующуюю пустую схему в базе назначения, затем переносим полностью схему из источника, удаляем из базы назначения старую переименованую схему. Проверка одинаковости схем, можно осуществить через bash конструкцию. Команду запускаем на обоих хостах, вывод сравниваем на предмет соответствия (использовать diff)
# for i in schema_1 schema_2 schema_3; do psql -ltAF. -U postgres -c "dt $i." db_name |cut -d. -f1,2 ; done |while read line ; do echo "$line" - $(psql -qAtX -U postgres -c "select count() from $line" db_name); done
В конце конечно хочется отметить что нужно на несколько раз проверить все места где может появиться запись в базу и исключить вероятность записи при переключении, когда часть сервисов/бэкендов уже переключилась на новую базу, а другая часть еще нет. Если рассуждать еще дальше, то теоретически можно уж совсем перевести том в readonly, и выполнять переключение (mount/dmsetup/blockdev).
Ну и чуть-чуть графиков.
1. NewRelic. Процесс переключения бэкендов
2. Zabbix. Суточная работа сервера с PG 9.0 (понедельник 10 сентября)
3. Zabbix. Дневная работа сервера с PG 9.0 (понедельник 10 сентября)
4. Zabbix. Суточная работа сервера с PG 9.2 + FlashCache (понедельник 17 сентября)
5. Zabbix. Дневная работа сервера с PG 9.2 + FlashCache (понедельник 17 сентября)
Самое большое зло в графиках Zabbix, это черная линия, отражающая iowait. Как видно, использование flashcache позволило значительно снизить нагрузку на жесткие диски.
Кому интересны технические детали:
как настривается потоковая репликация в PostgreSQL, смотреть здесь [2].
как настривается потабличная репликация между класетрами PostgreSQL с помощью Skytool-3, смотреть здесь [3].
Вот такая история одного субботника. Спасибо за внимание!
Автор: lesovsky
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/postgresql/15502
Ссылки в тексте:
[1] вышел PostgreSQL 9.2: http://www.postgresql.org/docs/9.2/static/release-9-2.html
[2] здесь: http://virtbox.blogspot.com/2012/09/postgresql-streaming-replication.html
[3] здесь: http://virtbox.blogspot.com/2012/09/skytools-30-simple-replication.html
Нажмите здесь для печати.