gremlintv2
@gremlintv2

Pgpool2 multy-master mode где искать мануалы по настройке? Как вы масштабируете базу(под запись)?

Не могу найти толковый мануал по настройке multy-master mode в том числе на оф. сайте, подскажите что спрашивать гугл... С вашего личного опыта: какие есть угрозы при такой балансировке базы? Сильно ли нагружает сервер процес синхронной репликация? Есть ли возможность регулировать таймаут(задержку) репликации? Правда ли что репликация на уровне утилит типа pgpool, repmgr, skytools еще сыровата и чаще всего используеться репликация на уровне приложения, а не утилит?
Сейчас читаю эту статейку https://habrahabr.ru/post/263225/ возможно она решит поставленую задачу
  • Вопрос задан
  • 985 просмотров
Решения вопроса 1
Melkij
@Melkij
PostgreSQL DBA
Как вы масштабируете базу(под запись)?

В основном никак. У нас нет баз на столько десятков террабайт данных чтобы внятно настроенный единственный мастер с парой обычных потоковых ro-реплик не справлялся.

Если у вас столько данных пишется что одного мастера действительно мало - то репликация вам не подходит по своему определению, она не про масштабирование записи, а только чтения и high availability (репликация = копия. Копию нельзя сделать, если писать не все данные).

А те базы что у нас распиливались - распиливались они не потому что в мастер упёрлись:
Что-то пилится на горячее-архивное: отдельные одна или несколько машин на более дешёвых (медленных) дисках, куда переносятся данные старше какого-то времени, к которым обращаются редко.
Что-то пилится на части функционально. Например, сайт - один кластер, данные для окружающих некритичных сервисов - другой кластер. Или данные ru-сайта - один кластер, данные нескольких других стран - отдельные базы на другом кластере.

Ещё можно пилить по каким-нибудь другим динамическим критериям. Например, данные всех пользователей от 1 до 1000 - на один кластер, от 1000 до 2000 - на другой. Плюс пара машин с данными координатора какой id на какой машине и авторизации. Это уже эталонное горизонтальное масштабирование. Крайне редко кому действительно нужно и собирается типично вручную с пониманием что и зачем делается.

Сильно ли нагружает сервер процес синхронной репликация?

Железо - не очень. Со стороны приложения кажется что очень. Потому что латентность коммита локально и согласовать коммит с даже хотя бы одной синхронной репликой - вещи очень сильно расходящиеся по латентности.

чаще всего используеться репликация на уровне приложения

Репликация чаще всего используется штатная потоковая.
Запросы от приложения удобнее направлять именно из приложения не из-за сырости прокси, а потому что именно приложению лучше знать, нужно ли запрос отправлять на реплику (и если реплику - то какую, боевую? отдельную для медленных запросов аналитики?) или его вообще можно выполнять только на мастере.

какие есть угрозы при такой балансировке базы?

В смысле при мультимастере? Кучу головной боли вам доставит CAP теорема, из-за которой внятного мультимастера нет.
Самое весёлое - split brain, когда у вас образовались противоречащие друг другу данные на двух мастерах.
Или триггерная репликация внезапно встала колом и надо разбираться, из-за чего.
Отправлять пишущие запросы синхронно на несколько хостов и предполагать, что там будут сходиться данные в итоге - это надо быть или большим оптимистом или очень внимательно проверять каждый запрос на предмет что именно он будет делать и как себя поведёт при конкурентном доступе.
Ответ написан
Пригласить эксперта
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы