Pull to refresh

Comments 17

>Т.е. невозможно вернуть его назад в состояние slave без полной синхронизации с master.
вот это-то и смущает

в моделях же master-master (где фактически второй мастер используется как слейв/резервный) переключения/поднятия происходят безшовно в обе стороны
Да, смущает. Но даже, все-таки не это. Это не страшно.

Более существенно, что переключение других слэйвов на новый мастер делается только через полное копирование каталога базы. Конечно, это касается случая когда новый мастер образуется с помощью файлового тригера. Вполне возможно, что можно сделать новый мастер из одного из слэйвов изменением конфига и перезапуском (такой вариант НЕ тестировался). Т.к. timeline будет тот-же, возможно что и слэйвы подключаться к нему нормально.
Тоже не получается. Единственный способ сменить мастера — залить на все слэйвы новую базу с нового мастера.
полная синхронизация через rsync идет очень быстро, т.к. догоняются только изменения в файлах, а не целиком файло.
Вызывают сомнение измерение замедления, создаваемого fsync. Я сам не проверял как работает VMWare Player, но сомневаюсь, что fsync гостевой ОС приводит к сбросу данных на физический жесткий диск. Скорее всего данные оказываются в кэше родительской ОС, а это совсем другие порядки задержек.
Если в вашем тесте было много маленьких транзакций, а асинхронный commit выключен, то цифра 3.3% выглядит не реалистично. Разве что на RAID с кэшем и батарейкой.
Прогнал этот тест на физическом сервере. Сервер мощный и пока не загруженный. Результат странный. На нем получается что с включенным fsync вставка идет чуть-чуть быстрее.

Вставка производиться в цикле. Вставляется 100 000 записей с коммитом через каждые 1000.
Если по 1000 записей, то согласен, разница от fsync может быть незначительной. Хотя не понятно, конечно, почему быстрее.
подскажите, какие планировщики IO были использованы в тестировании и как менялись результаты?
У нас не стояла задача проверить скорость в зависимости от планировщика. Такие тесты не проводились. Вообще, у нас даже не было цели протестировать скорость работы — только синхронизацию и поведение репликации при сбоях питания.
у нас боевая связка (pgpool + pgpool под HA) + ( pg-master + pg-slave на стриме) + допилка скриптами. БД около 500Г.

подробнее:

на входе стоят 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
на мастере выполняйте insert, update чтобы запись на диск быстрая была и никакого чтения с диска приэтом. на слэйве в этоже время делайте select с множеством inner join и критерием по всем соединяемым табличкам, ну чтоб таблички были гигов по 5 минимум… это приведёт к тому что на слэйве диск будет сильно занят чтением, поэтому не будет успевать писать с той же скоростью с какой пишет мастер. вот тут можно получить десинхранизацию минут на 10 — 30, а то и вообще слэйв отпадёт!
Only those users with full accounts are able to leave comments. Log in, please.