Синхронизация и репликация ДБ по многим частям света

[Boriskin]

Решали подобную задачу. Пришли к выводу, что конкретная база роли не играет, можно брать ту, к которой больше душа лежит. Мы все сделали через Single Master & Multiple Slaves. В мастер данные только пишутся. Мастер ничего не знает о репликах и конфликты решаются по принципу "кто последний, тот и папа", т.е. если из разных стран прилетят апдэйты по одному ключу, то будет принят последний.

Понял, спасибо!

Если единственного мастера окажется мало, например по причини миллионов пользователей, то боюсь, что тут уже никто вам не даст готового рецепта.

Миллионов не будет точно, десятки тысяч - теоретический предел.

[tessob]

А пишут непосредственно клиенты? Им нужно знать о ближайшем рабе и хозяине?
Или как-то форвардятся запросы?

Вся запись только в мастер, а чтение только из слейвов. Просто было принято волевое решение, что запись в базу будет дорогой, но зато дешевое чтение и никакого гимора с консистентностью. Ну и любое количество слейвов, в том числе для всякого репортинга и прочей фигни.

[Vladimir Kr.]

Мастер ничего не знает о репликах

... пишешь одно, читаешь дрyгое.
при чем здесь "Синхронизация и репликация" ?

[tessob]

Мастер ничего не знает о репликах

... пишешь одно, читаешь дрyгое.

Па Чи Му !?

при чем здесь "Синхронизация и репликация" ?

Без понятия. Почему Вы про них решили заговорить? Я рассказывал как мы решали аналогичную задачу на практике. Что там, в этот момент, происходило в теории я не в курсе.

[Vladimir Kr.]

Мастер ничего не знает о репликах

... пишешь одно, читаешь дрyгое.

Па Чи Му !?

при чем здесь "Синхронизация и репликация" ?

Без понятия. Почему Вы про них решили заговорить? Я рассказывал как мы решали аналогичную задачу на практике. Что там, в этот момент, происходило в теории я не в курсе.

Вы пишите только в мастер, "Мастер ничего не знает о репликах", читаете только с реплик.
почему в реплике будет идентичное мастеру сразу после записи в мастер?

У нас топик "Синхронизация и репликация" мастер-мастер базы.
Вы решали задачу мастер-мастер репликации, путем приведения ее к мастер-слейв?

[VovaK98]

Встала след. задача - сделать DB solution с примерно следующими характеристиками
1. требуется репликация всех данных целиком на разные регионы - Сев. Америка, Зап. Европа и Азия
2. адекватная синхронизация данных между регионами за приемлемое время (суперскорость в силу определенных причин не критична), но хотелось бы чтобы write/update в одном месте доходили до других не через часы.
3. максимальная пропускная способность при чтении (имеют место пиковые часы по нагрузке)
4. желательно бесплатно, можно как SQL based, так и NoSQL - данные легко утрамбуются и туда и туда.
...
Мысли - советы - велкам!

Вспомнилось вот.
Когда я в середине девяностых коптил в одной из большой шестерки (щас уже big-4), такое решение совершенно безпроблемно работало на Лотусе Домино. Репликация и секюрити всегда были сильной стороной Лотуса. Мы, сидя в Москве, тянули реплики из UK, там хаб был. Питерский и региональные офисы тянули данные уже у нас. Лотус Домино - можно сказать, чистый NoSQL. Писали данные при этом во все реплики, и оно само уже расползалось.
Щас Лотус уже как бы всё, но вроде как несколько лет назад то что осталось перетянули на DB2 формат данных. Сам я уже не в струе, но поскольку вспомнилось- то вот - могу порекомендовать посмотреть в сторону IBM.
Успехов!

[tessob]

Вы пишите только в мастер, "Мастер ничего не знает о репликах", читаете только с реплик.
почему в реплике будет идентичное мастеру сразу после записи в мастер?

У нас топик "Синхронизация и репликация" мастер-мастер базы.
Вы решали задачу мастер-мастер репликации, путем приведения ее к мастер-слейв?

Перечитайте пункты 2 и 3 из первого поста. Если вы знаете как решить подобную задачу в реальном времени и в реальном мире, то напишите пожалуйста свою версию. Только имейте ввиду, что в реальном мире shit happens (сервера падают, провайдеры лажают, пакеты теряются). Мне и самому будет интересно узнать как "правильно" дизайнить распределенные системы.

[Vladimir Kr.]

Вы пишите только в мастер, "Мастер ничего не знает о репликах", читаете только с реплик.
почему в реплике будет идентичное мастеру сразу после записи в мастер?

У нас топик "Синхронизация и репликация" мастер-мастер базы.
Вы решали задачу мастер-мастер репликации, путем приведения ее к мастер-слейв?

Перечитайте пункты 2 и 3 из первого поста. Если вы знаете как решить подобную задачу в реальном времени и в реальном мире, то напишите пожалуйста свою версию. Только имейте ввиду, что в реальном мире shit happens (сервера падают, провайдеры лажают, пакеты теряются). Мне и самому будет интересно узнать как "правильно" дизайнить распределенные системы.

Как тут правильно сказали, для общего решения задачи синхронизации мастер-мастер серверов нужно определиться с алгоритмом разрешения конфликтов при сравнении двух commited записей с двух и более серверов. Это не та-же задача, что клиент-сервер, из-за отсутствия комита на клиенте.
Конкретную задачу ТС#2 можно решить выбрав один из алгоритмов плюс возможено шардинг, но останется вопрос об адекватности синхронизации.

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

Объединяем эти два подхода, добавляем мастер-слейв:
как обычно, читаем с любого сервера.
используем двухфазный коммит, но только с одним сервером, там где запись (table row) помечена как мастер копия. Это может быть тот-же сервер, или другой, но он будет один. После коммита изменения на мастер сервере, нужно в бакграунде оповестить _все_ остальные сервера об изменении. Если мастер не найден, это то в случае, если сервер резко умер (или потерял связь), то нужно подтвержение от всех серверов о смене мастер метки конкретной записи. Если при этом (отсутствие сервера с мастер меткой) запись изменилась сразу в 2х местах, то смотри выше вариант с двухфазным комитом. Но лучше сервера гасить с передачей всех мастер меток на ближайший. При потере связи да и вообще в бакграунде нужно сравнить логи транзакций с ближайшим сервером, на предмет более свежих записей. Если добавить распределение мастер меток по шардингу регионов, то не будет тормозить на cross-region ХА commit.

Получается чуть сложнее, чем обычный двухфазный коммит, но ничего супер сложного. Надежно, сравнительно быстро, тру мастер-мастер с AZ & HA & DR.

Я не знаю как с Ораклом, да и с Постгресом тоже не в курсе всех особенностей их вариантов. Может у Касандры похожая реализация?

[tessob]

Короче, правильно ли я понимаю, что:
1) В первом случае, если пользователи создадут на двух мастерах записи с одинаковыми ключами (инкремент) консистентность идет лесом?
2) Во втором случае мы просто ухудшаем производительность не выигрывая ни в чем?
3) В третьем случае клиент должен гулять по куче серверов разыскивая строчки с правильными метками, что как бы еще более медленное решение чем во втором случае?

Вы хоть один из этих подходов на практике реализовывали?

[uncle_Pasha]

Текущее решение сбацано на Postgres и к оному можно прикрутить варианты репликации, hot standby и так далее, но конечная эффективность всего этого выглядит не гарантированной даже без учета сопутствующего головняка на тему физической реализации замысла.

Сам амазон пользовать низзя, тк все должно быть внутри корпоративной сети, внутренний эквивалент AWS есть, но заточен на веб-аппс и (микро)сервисы, с поддержкой продвинутых фич для реляционных баз данных из коробки - голяк.

Поглядываю на Кассандру, коя целиком и полностью поддерживается, по описанию выглядит как возможный кандидат, но есть сомнения на тему скорости чтения из базы - насколько быстро оно читает...

Я не уловил требований, которые препятствуют использования репликации с Postgress.
Тот же Amazon его использует в AWS - и read-only реплики работают вполне сносно.
Можно, конечно, что-то еще прикрутить, но почему бы не начать с того, что работает уже сейчас?

[Vladimir Kr.]

Короче, правильно ли я понимаю, что:
1) В первом случае, если пользователи создадут на двух мастерах записи с одинаковыми ключами (инкремент) консистентность идет лесом?

нет.
если в общем случае, то консистентность решается правилом устранения конфликтов. если с шардингом, то и конфликтов не будет.

2) Во втором случае мы просто ухудшаем производительность не выигрывая ни в чем?

нет,
выигрыш будет, не в записи, но в чтении и HA

3) В третьем случае клиент должен гулять по куче серверов разыскивая строчки с правильными метками, что как бы еще более медленное решение чем во втором случае?

снова нет.
метка со ссылкой мастера будет прямо в записи. проверить надо только один сервер. при правильном шардинге, этот сервер будет в том-же дата центре (регионе). и только, если указанный сервер не доступен, то надо все сервера опрашивать.

Вы хоть один из этих подходов на практике реализовывали?

извините я не утверждал что решил задачу, просто указал, что решение есть. и например у Постгреса куча мастер-мастер вариантов репликации, может где-то это уже сделано.

[alex_127]

Общего решения нету. Все работает в определенных узеньких рамочках :-/
Если у вас есть то что работает лучше спаннера - я куплю. Оплата деньгами, дорого, сразу.

[tessob]

Короче, правильно ли я понимаю, что:
1) В первом случае, если пользователи создадут на двух мастерах записи с одинаковыми ключами (инкремент) консистентность идет лесом?

нет.
если в общем случае, то консистентность решается правилом устранения конфликтов. если с шардингом, то и конфликтов не будет.

Владимир, простите, но мне лень аргументированно приводить примеры по всем вашим примерам. Давайте ограничимся самым первым? Представьте, что что моя база - это справочник сотрудников в некой HCM/HR системе. Предположим, что есть только два мастер-мастер сервака. Пускай на обоих серверах заводится по новому сотруднику и они инкрементом получают идентичные ИД. Но в одной из баз помимо заведения сотрудника ему начисляют бонус за релокацию, и платежные данные с ИД сотрудника передаются в третью систему для выполнения оплаты. Через некоторое время, после получения подтверждения оплаты банком, третья система вернет информацию о факте оплаты обратно, разумеется, с ИД.

Каким правилом вы планируете это разруливать?

[Vladimir Kr.]

Короче, правильно ли я понимаю, что:
1) В первом случае, если пользователи создадут на двух мастерах записи с одинаковыми ключами (инкремент) консистентность идет лесом?

нет.
если в общем случае, то консистентность решается правилом устранения конфликтов. если с шардингом, то и конфликтов не будет.

Владимир, простите, но мне лень аргументированно приводить примеры по всем вашим примерам. Давайте ограничимся самым первым? Представьте, что что моя база - это справочник сотрудников в некой HCM/HR системе. Предположим, что есть только два мастер-мастер сервака. Пускай на обоих серверах заводится по новому сотруднику и они инкрементом получают идентичные ИД. Но в одной из баз помимо заведения сотрудника ему начисляют бонус за релокацию, и платежные данные с ИД сотрудника передаются в третью систему для выполнения оплаты. Через некоторое время, после получения подтверждения оплаты банком, третья система вернет информацию о факте оплаты обратно, разумеется, с ИД.

Каким правилом вы планируете это разруливать?

Извините, но вы смешали все в кучу: создание записи, ее изменение, связь с 3rd party на грязных данных, отсустствие синхронизации за вменяемое время, да еще и отсутствие шардинга.

Разбейте свой пример на этапы и примените правило "первый" или "последний" на этапе после создания записей, т.е синхронизация должна удалить или изменить ИД на одной из записей, сразу после создания. Вот наличие правил и неявное изменение, и есть основная проблема синхронизации мастер-мастер на commited данных. А какое это будет правило, это вопрос, который был в самом начале трейда - какое правило выберете, такое и будет.

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

Но правильнее всего, это использовать 2й способ - XA transaction (двухфазный коммит) или 3й способ.

[tessob]

Извините, но вы смешали все в кучу: создание записи, ее изменение, связь с 3rd party на грязных данных, отсустствие синхронизации за вменяемое время, да еще и отсутствие шардинга.

Пример вполне корректный. Мы же про реальную жизнь тут говорим. Представьте, что таким образом я хочу собирать чеки пробитые на кассах. Там еще и бумажка с ИД появится. Случаи, когда в одну табличку пишется одна строчка - скорее экзотика.

Но правильнее всего, это использовать 2й способ - XA transaction (двухфазный коммит) или 3й способ.

У вас в обоих случаях будет проигрыш в производительности в сравнении с единственным мастером. Кроме того мне не очень понятно как вы заблокируете другие потоки на запись. Просто представьте, что два клиента параллельно выполнили все проверки и фиганули свои записи на разные сервера с одинаковым ключом. У Вас тут будут те же проблемы с "гонкой", что и в многопоточном программировании. Только в сравнении с многопоточным программированием у вас нет единой среды выполнения.