[ответ автора статьи, Игоря Косенкова]
Есть положительный опыт построения 3-х нодового кластера, «растянутого» на 3 дата-центра — каждая нода живет в своем дата-центре.
В таком кластере есть свои нюансы, которые необходимо учитывать.
Первый — невозможность обеспечить надежный управляющий линк между нодами, поскольку нельзя гарантировать надежный канал между дата-центрами. Линк между нодами (считай, между дата-центрами) может периодически пропадать. В ОУК с дефолтными настройками такое пропадание линка будет считаться сбоем и Pacemaker на это среагирует — переместит ресурсы на «живую» ноду.
Поэтому встает задача выставить оптимальные таймауты на время реагирования Pacemaker'ом.
Выставить большие таймауты — значит будет большее время переключения роли Мастера между нодами.
Выставить короткий таймаут — значит будут ложные срабатывания Pacemaker'ом.
Оптимальные таймауты можно подобрать только эмпирическим путем.
Второй — необходимо организовать единое адресное пространство между дата-центрами. Это дополнительное оборудование, расходы, и с точки зрения надежности — включение дополнительных элементов (VPN-устройств) необходимо также резервировать.
Третий — ввиду того, что задержка между дата-центрами может составлять большее время, чем в локальной сети, то придется отказаться от синхронной реплики при построении ОУК. А это влечет небольшую потерю данных — реплика от мастера будет отставать, и при переключении роли мастера на асинхронную реплику небольшая часть данных будет потеряна.
Про pgDay не берусь сказать (может кто-то подскажет более информированный), зато знаю, что все доклады pgConf 2017, 16 и 15 выложены на сайте конференции. вот, например: pgconf.ru/2017/93506. 2018 появятся чуть попозже.
Прекрасно. если это произошло только что, то я могу включить в подборку новостей, которую сейчас собираю. и вообще можно кидать новости на почту, внизу есть адрес.
Выше был ответ x-wao: «Некоторые фичи из Enterprise будут со временем переходить в более доступные версии и даже в open source. Например, 64-разрядный счетчик транзакций мы хотим сделать частью PostgreSQL.»
разработчики говорят так:
для двух узлов есть несколько вариантов:
1) голосующий узел — инстанс постгреса без данных, который в случае выхода из строя одной ноды разрешит другой продолжить работу
2) можно на одной из нод включить major режим, тогда эта нода продолжит работать в случае поломки соседа. Если major нода поломается, то её соседа включать вручную
3) есть возможность использовать внешний fencing, если он доступен
Есть положительный опыт построения 3-х нодового кластера, «растянутого» на 3 дата-центра — каждая нода живет в своем дата-центре.
В таком кластере есть свои нюансы, которые необходимо учитывать.
Первый — невозможность обеспечить надежный управляющий линк между нодами, поскольку нельзя гарантировать надежный канал между дата-центрами. Линк между нодами (считай, между дата-центрами) может периодически пропадать. В ОУК с дефолтными настройками такое пропадание линка будет считаться сбоем и Pacemaker на это среагирует — переместит ресурсы на «живую» ноду.
Поэтому встает задача выставить оптимальные таймауты на время реагирования Pacemaker'ом.
Выставить большие таймауты — значит будет большее время переключения роли Мастера между нодами.
Выставить короткий таймаут — значит будут ложные срабатывания Pacemaker'ом.
Оптимальные таймауты можно подобрать только эмпирическим путем.
Второй — необходимо организовать единое адресное пространство между дата-центрами. Это дополнительное оборудование, расходы, и с точки зрения надежности — включение дополнительных элементов (VPN-устройств) необходимо также резервировать.
Третий — ввиду того, что задержка между дата-центрами может составлять большее время, чем в локальной сети, то придется отказаться от синхронной реплики при построении ОУК. А это влечет небольшую потерю данных — реплика от мастера будет отставать, и при переключении роли мастера на асинхронную реплику небольшая часть данных будет потеряна.
для двух узлов есть несколько вариантов:
1) голосующий узел — инстанс постгреса без данных, который в случае выхода из строя одной ноды разрешит другой продолжить работу
2) можно на одной из нод включить major режим, тогда эта нода продолжит работать в случае поломки соседа. Если major нода поломается, то её соседа включать вручную
3) есть возможность использовать внешний fencing, если он доступен