Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 12
Synchronous replication в 9.1 — это возможность проводить транзакции в синхронном режиме (с подтверждением записи WAL от standby). Standby уже достаточно давно может переходить в активный режим с помощью trigger file в pg_standby (или pg_ctl promote в 9.1), но при этом primary придется убивать самому.
Самый частый use case для сторонней репликации — это упомянутая частичная репликация данных, скажем, на одной ноде нужна таблица A, на другом — таблица B.
Второй по частоте — это когда вы думаете, что вам нужен multi-master, который есть в Bucardo, но нет в WAL-based replication.
Третий — это уже упомянутая каскадная репликация.
Ну и пограничный случай — когда нужно зареплицировать данные из постгреса куда-нибудь еще, триггерную репликацию можно написать практически на коленке, а вот заставить другую СУБД понимать WAL от PostgreSQL — это тот еще fun :-).
Самый частый use case для сторонней репликации — это упомянутая частичная репликация данных, скажем, на одной ноде нужна таблица A, на другом — таблица B.
Второй по частоте — это когда вы думаете, что вам нужен multi-master, который есть в Bucardo, но нет в WAL-based replication.
Третий — это уже упомянутая каскадная репликация.
Ну и пограничный случай — когда нужно зареплицировать данные из постгреса куда-нибудь еще, триггерную репликацию можно написать практически на коленке, а вот заставить другую СУБД понимать WAL от PostgreSQL — это тот еще fun :-).
Почему для failover-а нельзя использовать streaming replication? Когда я это делал полгода назад, там не хватало удобных скриптов, но необходимая функциональность присутствовала.
Если несколько слейвов, то да, не всё так просто. Мастером можно сделать слейв с не самыми последними данными и тогда более слейв с более новыми данными не сможет продолжать с новым мастером.
Если несколько слейвов, то да, не всё так просто. Мастером можно сделать слейв с не самыми последними данными и тогда более слейв с более новыми данными не сможет продолжать с новым мастером.
Да я вроде и не писал о том, что нельзя использовать встроенную репликацию для «безотказности». Написанная шпаргалка перечисляет лишь ситуации, в которых, на мой взгляд, использовать сторонние продукты предпочтительнее. Она полезна тем, кто впервый раз задаётся вопросом — а чем один инструмент отличается принципиально от другого?
>> Если требуется failover (т.е. останавливается Master и все запросы временно идут на Slave, а потом запущенный Master начинает догоняется до актуального состояния со Slave).
failover — переключение при падении мастера на один из слейвов, востановление тут не причем. Кстати, какая тригерная репликация сделает так, что б мастер догнал слейв (без переключения мастера в режим слейва — стриминг так тоже умеет)?
>>Master и Slave не являются 1:1 идентичными. Например, по какой-то причине на Slave надо держать дополнительные данные (базы/таблицы) или же копированию с Master подлежат не все базы/таблицы, или же при удалении данных — они должны сохраниться на Slave.
Тогда это не репликация.
>>В проекте требуется рекурсивная репликация Master-Slave1-Slave2-Slave3 или в реально нагруженном INSERT/UPDATE проекте к Master параллельно подключается больше, чем 1 Slave (хотя некоторые проекты имеют нагрузку, с которой могут нормально работать и до 5-6 Slave).
Вы имеете ввиду каскадную репликацию или несколько слейвов на одно мастере? И то и другое умеет делать стриминг репликация.
>> Если по какой-то причине требуются различные права доступа к объектам базы на Master и Slave.
Опять же, при чем тут репликация?
ЗЫ Репликация — механизм синхронизации содержимого нескольких копий объекта.
failover — переключение при падении мастера на один из слейвов, востановление тут не причем. Кстати, какая тригерная репликация сделает так, что б мастер догнал слейв (без переключения мастера в режим слейва — стриминг так тоже умеет)?
>>Master и Slave не являются 1:1 идентичными. Например, по какой-то причине на Slave надо держать дополнительные данные (базы/таблицы) или же копированию с Master подлежат не все базы/таблицы, или же при удалении данных — они должны сохраниться на Slave.
Тогда это не репликация.
>>В проекте требуется рекурсивная репликация Master-Slave1-Slave2-Slave3 или в реально нагруженном INSERT/UPDATE проекте к Master параллельно подключается больше, чем 1 Slave (хотя некоторые проекты имеют нагрузку, с которой могут нормально работать и до 5-6 Slave).
Вы имеете ввиду каскадную репликацию или несколько слейвов на одно мастере? И то и другое умеет делать стриминг репликация.
>> Если по какой-то причине требуются различные права доступа к объектам базы на Master и Slave.
Опять же, при чем тут репликация?
ЗЫ Репликация — механизм синхронизации содержимого нескольких копий объекта.
Поверьте, проекты бывают очень разные и очень странные. В шпаргалке я описал ситуации, в которых, на мой взгляд, ориентироваться на встроенное потоковое решение не стоит.
Вообще в потоковой асинхронной каскадной (рекурсивной) репликации или же при колличестве слейвов больше 1-2 при большом потоке INSERT/UPDATE на Master мы можем воткнуться на несогласованность данных — когда слейвы начнут тихо и не злобно тормозить с обновлениями.
Вообще в потоковой асинхронной каскадной (рекурсивной) репликации или же при колличестве слейвов больше 1-2 при большом потоке INSERT/UPDATE на Master мы можем воткнуться на несогласованность данных — когда слейвы начнут тихо и не злобно тормозить с обновлениями.
Вообще в потоковой асинхронной каскадной (рекурсивной) репликации или же при колличестве слейвов больше 1-2 при большом потоке INSERT/UPDATE на Master мы можем воткнуться на несогласованность данных — когда слейвы начнут тихо и не злобно тормозить с обновлениями.
Можете подробней рассказать про «несогласованность данных» и почему слейвы начнут тормозить?
имел факт — при большом потоке INSERT/UPDATE и цепочки из 5и Slave, SELECT-запросы от серверов приложений на последние Slave в цепочки очень часто вытягивали не самые свежие данные. Т.е. за приемлемый промежуток времени на Master и Slave1/2/3 обновления произошли, а на Slave4/5 данные еще не обновились, но уже счиатались SELECTом. В итоге имели рассогласованность по предполагаемым идентичным состояним на серверах приложений.
Ну так это понятное дело при работе с асинхронной репликацией — вы получаете скорость, но теряете корректность(consistency) узлов. Для этого вы могли использовать
На мастере:
SELECT pg_current_xlog_location()
на слеве:
SELECT pg_last_xlog_receive_location()
и получали разницу в отставании узла от мастера. В 9.1 для этого на мастере появилась новая view pg_stat_replication, в которой как раз и показаны состояния (и отставания) слейвов.
Для автоматизации применения селекта со свейвов используется pgpool-|| 3 версии, который может балансировать при стриминг репликации учитывая отставания слейвов (используя методику, что я выше написал).
Так что ваша проблема высосана из пальца, не более.
На мастере:
SELECT pg_current_xlog_location()
на слеве:
SELECT pg_last_xlog_receive_location()
и получали разницу в отставании узла от мастера. В 9.1 для этого на мастере появилась новая view pg_stat_replication, в которой как раз и показаны состояния (и отставания) слейвов.
Для автоматизации применения селекта со свейвов используется pgpool-|| 3 версии, который может балансировать при стриминг репликации учитывая отставания слейвов (используя методику, что я выше написал).
Так что ваша проблема высосана из пальца, не более.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Когда триггерная репликация предпочтительнее встроенной в PostgreSQL