Pull to refresh

Экстремальное тестирование streaming репликации PostgreSQL 9.1

PostgreSQL
imageВозникла задача внедрения 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 вполне работоспособна и надежна.
Tags:postgresqlрепликациятестированиеfsync
Hubs: PostgreSQL
Total votes 28: ↑24 and ↓4 +20
Views5.1K

Comments 17

Only those users with full accounts are able to leave comments. Log in, please.

Popular right now