Возникла задача внедрения streaming репликации Postgresql 9.1 на продакшене. А т.к. раньше с нею дела не имели, решили провести ее «эстремальное тестирование».Для этого были запущены две виртуальные машины VMWare Player с Ubuntu Server. Установлена и настроена streaming репликация на Postgresql 9.1.
Скорость синхронизации
С хост машины был запущен скрипт, добавляющий в тестовую таблицу реплицируемой БД в цикле множество строк. Скрипт был запущен в 3 потока.
На виртуальных машинах была создана нагрузка как на процессор (бесконечный цикл в bash), так и чтением данных из тестовой таблицы. Проверялась и неравномерная нагрузка — она то отключалась на slave, то на master.
По результатам получилась очень приятная картина. Хотя они и оценивались «на глаз», но не было замечено рассинхронизации более чем на 1-2 секунды. И то, такая рассинхронизация возникала лишь при очень высокой нагрузке (несколько параллельных нагрузочных процессов) и на короткое время.
Стабильность при отключениях питания
fsync=off
Для ускорения операций обновления и вставки предыдущая версия Postgresql использовалась с опцией fsync=off. Было протестировано поведение репликации при отключенном fsync и жестком выключении виртуальной машины (симуляция отключения питания).
Результаты оказались вполне предсказуемыми. После ее запуска и восстановления БД оказалось, что текущая точка в бинарном логе на master находится раньше, чем обработанная точка на slave. Т.е. база полностью рассинхронизирована и необходима синхронизация серверов с нуля (по обычной процедуре создания slave базы — с копированием всего каталога данных).
fsync=on
После синхронизации серверов было проведено тестирование поведения репликации в случае, когда fsync включен.
При «жестком» выключении salve ничего особенного не происходило. Он поднимался и «догонялся» по журналу с master.
Более интересна ситуация при отключении master. При его акуратном отключении типа «отключил, подождал, включил, проверил», все происходило нормально. База поднималась, восстанавливалась и оказывалась синхронизированной со slave.
Далее была произведена симуляция «мигания электричества» в дата-центре. Мастер сервер был «жестко» перезагружен несколько раз в произвольные моменты времени. Обычно эти моменты попадали на момент запуска сервера Postgresql или чуть позже. В итогде, база на мастере поднялась нормально, но со slave возникли небольшие проблемы. В логе slave начали выскакивать сообщения о неверном размере какой-то записи транзакции и он не синхронизировался с master. Однако, при перезапуске Postgresql на slave все опять отлично заработало.
Быстродействие вставки в зависимости от значения fsync
Была протестирована в нескольких циклах зависимость скорости вставки от значения fsync. По результатам получилось что при fsync=off скорость выше примерно на 3.3%. Стоит-ли такое ускорение потери базы при отключении питания — решать каждому самостоятельно. Я лично намерен использовать Postgresql исключительно с fsync=on.
Переключение slave в режим master с помощью файлового триггера
Переключение срабатывает неплохо. Но есть одно «но». При таком переключении slave становиться совершенно самостоятельным мастером. Т.е. невозможно вернуть его назад в состояние slave без полной синхронизации с master. Это следствие того, что на нем создается новая линия времени — timeline. Также, в следствии этого, если у вас используется несколько slave, все остальные оказываются отключенными от нового мастера. И для их подключения требуется их полная синхронизация.
Итоги
В результате этих тестов у меня лично возникла уверенность, что streming репликация в Postgresql 9.1 вполне работоспособна и надежна.
