Комментарии 17
>Т.е. невозможно вернуть его назад в состояние slave без полной синхронизации с master.
вот это-то и смущает
в моделях же master-master (где фактически второй мастер используется как слейв/резервный) переключения/поднятия происходят безшовно в обе стороны
вот это-то и смущает
в моделях же master-master (где фактически второй мастер используется как слейв/резервный) переключения/поднятия происходят безшовно в обе стороны
Да, смущает. Но даже, все-таки не это. Это не страшно.
Более существенно, что переключение других слэйвов на новый мастер делается только через полное копирование каталога базы. Конечно, это касается случая когда новый мастер образуется с помощью файлового тригера. Вполне возможно, что можно сделать новый мастер из одного из слэйвов изменением конфига и перезапуском (такой вариант НЕ тестировался). Т.к. timeline будет тот-же, возможно что и слэйвы подключаться к нему нормально.
Более существенно, что переключение других слэйвов на новый мастер делается только через полное копирование каталога базы. Конечно, это касается случая когда новый мастер образуется с помощью файлового тригера. Вполне возможно, что можно сделать новый мастер из одного из слэйвов изменением конфига и перезапуском (такой вариант НЕ тестировался). Т.к. timeline будет тот-же, возможно что и слэйвы подключаться к нему нормально.
полная синхронизация через rsync идет очень быстро, т.к. догоняются только изменения в файлах, а не целиком файло.
Вызывают сомнение измерение замедления, создаваемого fsync. Я сам не проверял как работает VMWare Player, но сомневаюсь, что fsync гостевой ОС приводит к сбросу данных на физический жесткий диск. Скорее всего данные оказываются в кэше родительской ОС, а это совсем другие порядки задержек.
Если в вашем тесте было много маленьких транзакций, а асинхронный commit выключен, то цифра 3.3% выглядит не реалистично. Разве что на RAID с кэшем и батарейкой.
Если в вашем тесте было много маленьких транзакций, а асинхронный commit выключен, то цифра 3.3% выглядит не реалистично. Разве что на RAID с кэшем и батарейкой.
подскажите, какие планировщики IO были использованы в тестировании и как менялись результаты?
у нас боевая связка (pgpool + pgpool под HA) + ( pg-master + pg-slave на стриме) + допилка скриптами. БД около 500Г.
подробнее:
на входе стоят 2 pgpool подвешенных через HA. для отказа.
мастер/слейв 2 тачки по стриминг реплике. отставание практически нет. на слейв идет 99% запросов на выборки.
нагруз на входе около 1500 коннектов в сек. на серверах около 50-100 коннектов. запросов и не сосчитать… мало ли в Бразилии донов Педров!
продакшен. полет нормальный.
подробнее:
на входе стоят 2 pgpool подвешенных через HA. для отказа.
мастер/слейв 2 тачки по стриминг реплике. отставание практически нет. на слейв идет 99% запросов на выборки.
нагруз на входе около 1500 коннектов в сек. на серверах около 50-100 коннектов. запросов и не сосчитать… мало ли в Бразилии донов Педров!
продакшен. полет нормальный.
тесты гонялись на стенде: pgpool + 3 сервера pg ( мастер и 2 слейва). все тесты прошли. все переключалось, догонялось, синкалось и работало. слейвы становились мастерами, мастера слейвами.
не было замечено рассинхронизации более чем на 1-2 секунды
а их и не будет, пока не упрёшься в сеть или диск. попробуйте немного усложнить работу с вашей тестовой таблицой, не просто пихайте в неё строки, а навесте пару индексов и обновляйте/удаляйте данные.
ну и запросы усложните, чтобы хотя бы index scan получался
Ну, в общем, такую нагрузку тоже использовали. Параллельно в цикле шли запросы типа like "%aaa%".
ак, данные то не изменяли/удаляли :)
в общем я хочу предупредить что вполне «легальные» задержки могут составлять до max_standby_streaming_delay секунд, и запрос на слэйве может быть отменён самим слэйвом :)
и это нормальное поведение с которым придётся считаться :)
подробнее www.postgresql.org/docs/9.1/static/hot-standby.html#HOT-STANDBY-CONFLICT
в общем я хочу предупредить что вполне «легальные» задержки могут составлять до max_standby_streaming_delay секунд, и запрос на слэйве может быть отменён самим слэйвом :)
и это нормальное поведение с которым придётся считаться :)
подробнее www.postgresql.org/docs/9.1/static/hot-standby.html#HOT-STANDBY-CONFLICT
на мастере выполняйте insert, update чтобы запись на диск быстрая была и никакого чтения с диска приэтом. на слэйве в этоже время делайте select с множеством inner join и критерием по всем соединяемым табличкам, ну чтоб таблички были гигов по 5 минимум… это приведёт к тому что на слэйве диск будет сильно занят чтением, поэтому не будет успевать писать с той же скоростью с какой пишет мастер. вот тут можно получить десинхранизацию минут на 10 — 30, а то и вообще слэйв отпадёт!
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Экстремальное тестирование streaming репликации PostgreSQL 9.1