3. Как все было?
● PostgreSQL 9.0.7 master;
● PostgreSQL 9.0.7 slave;
● 4 app-сервера с nginx+passenger;
● сервер со Sphinx.
4. Как все было?
app1 app2 app3 app4
sphinx Master Slave
5. Какие сложности впереди?
● кластер не заработает если просто обновить пакет с 9.0
на 9.2;
● pg_upgrade невозможен без остановки кластера;
● переинициализация и последующий pg_restore тоже
делать нельзя, т.к. влечет остановку;
● нельзя сначала обновить мастер, а потом обновить
слейв. Потоковая репликация между мажорными
версиями не будет работать.
6. Какой выход?
● Поднимаем кластер pg-9.2 по соседству;
● запускаем в соседнем кластере потоковую
репликацию;
● реплицируем pg-9.0 на pg-9.2 через
Skytools;
● все изменения приходящие в master-9.2
будут тутже реплицироваться на slave-9.2
● переключаем бэкенды через смену DNS.
7. Skytools?
● Skytools (Londiste);
● Репликация отдельных баз и таблиц;
● Паралельное копирование (только в 3.0).
8. План мероприятия
● Подготовительный план:
– админские работы;
– настройки мониторингов;
– построение отчетов.
● Процесс переключения;
● Мониторинг и отладка:
– поиск и устранение неисправностей.
9. Подготовительные мероприятия
● поднимаем новый кластер pg-9.2;
● настраиваем londiste между pg-9.0 и pg-9.2 в холостом режиме;
● поднимаем новый slave.pg-9.2 на соседнем порту и настраиваем потоковую репликацию c master.pg-
9.2;
● подготовить свежие отчеты pgfouine с мастера 9.0 и слейва 9.0 за любой будний день.
● добавить в провайдера londiste все схемы, которые не потребуют создания первичных ключей;
● проверить со всех бекендов возможность подключения к новым инстансам PostgreSQL;
● перепроверить конфиги для новых баз, лимиты коннектов, настройки автовакуума;
● настроить мониторинг для новых баз (используем zabbix вкупе с самописными bash-скриптами
дергающими таблицы pg_stat*);
● для новых баз создать dns-имена db-master и db-slave;
● предупредить редакцию о проведении работ в субботу (это просто преупреждение верхов чтоб были
готовы, и не задавали вопросы в случае чего).
10. Мероприятия перед
переключением
● запустить перенос данных через londistе.
● подготовить список схем для ручного
переноса.
11. Переключение
● проверить топ 10 запросов с мастера и слейва на 9.2;
● подготовить команды для ручного переноса схем.
● остановить кроны, демон фоновых задач и дождаться завершения
активных задач;
● закрыть редактирование;
● перенести дампом оставшиеся схемы в новую базу;
разваливаем londiste репликацию (выводим таблицы, секвенции,
ноды, останавливаем londiste и pgqd);
● поправить конфиги на бэкендах;
● перезапустить приложения на бэкендах (nginx+passenger);
● обновить конфиг для sphinx и перезапустить его.
12. Мероприятия после
переключения
● поправить конфигурацию демона фоновых задач и запустить его. запустить кроны;
● открыть редактирование;
● открыть все мониторинги и искать возможные косяки.
включить ночной импорт;
● проверить логи крона, логи демона фоновых задач, лаг репликации.
● перенести db-slave на стандартный порт, для этого:
● бэкенды работающие со слейвом переключить на работу с мастером;
● выключить pg-9.0;
● настроить новый pg-9.2 на работу с полным объемом памяти (незабываем что на хосте
было 2 инстанса PostgreSQL, поэтому пришлось поделить между ними память);
● запустить db-slave на порту 5432, проверить подключение с бэкендов и со sphinx'а;
● проверить целостность и лаг репликации;
● ввести в строй слейв на стороне бэкендов;
● поиск и устранение проблем.
