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

[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й способ.

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

[Vladimir Kr.]

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

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

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

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

А у вас будет zero performance when server down.

Сори, но мы говорим на разных языках. Please google and understand first: DB transactions, XA (two phase commit), sharding (aka partitioning). и как решают у DB проблемы с "гонкой".

Мои поинт был в том, чтобы (a): показать, что решение существует, (b): спросить про реализацию, если кто знает.

[tessob]

ИМХО тут ошибка в дизайне базы данных. Необходимо исключить дупликат ИД. Для этого можно (Oracle as an example) :
1. Сделать функцию, которая выдает уникальный ИД. Типа только мастер раздает ИД. Двухфазный коммит, линк на удаленную базу данных в помощь.
2. Сделать ИД композитным , состоящим из двух колонок, типа ИД и кода локации
3. Сделать ИД уникальным с помощью sys_guid and datatype raw(16).

Как спроектировать идеальную базу - это предмет отдельного разговора. Что делать, если база уже существует? Мигрировать?

А у вас будет zero performance when server down.

Там и сейчас такая же картина. Однако это плата за консистентность. Скажите мне, как вы сможете восстановить консистентность данных, если один из ваших серверов "потеряет" связь с внешним миром, но какие-то клиенты продолжат работу с ним? Опять в Гугл мне идти?

Сори, но мы говорим на разных языках. Please google and understand first: DB transactions, XA (two phase commit), sharding (aka partitioning). и как решают у DB проблемы с "гонкой".

Мои поинт был в том, чтобы (a): показать, что решение существует, (b): спросить про реализацию, если кто знает.

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

[Boriskin]

Я не уловил требований, которые препятствуют использования репликации с Postgress.

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

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

Вот я и пробую разобраться, как и на елку влезть и попу не ободрать.

[tessob]

ИМХО с точки зрения бизнеса проще купить каналы связи "поширше" чем заниматься переделкой.

Вот тут мы на 100% сходимся.

Решений для повышения отказоустойчивости базы данных много. Как пример на Оракле это Real Application Cluster (RAC) c Transparent Application Failover(TAF), or Oracle Physical Standby c Dataguard. Что использовать, зависит от требований к отказоустойчивости: несколько минут или несколько секунд.

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

[oshibka_residenta]

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

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

Если можно позволить себе роскошь иметь single master, то, конечно, это way to go. Тогда и говорить не о чем.
p.s.
Мы используем Oracle Golden Gate. Сколько он стоит - хрен его знает. Нам надо, чтобы работало.

Смотрели в эту сторону https://www.cockroachlabs.com/ но пока это только мысли. На бумаге это решает все проблемы ТС. Но практического опыта с этим хозяйством нет.

[iDesperado]

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

да, обозвать oracle rac "технологией с неочевидными сайд-эффектами и минимумом открытых фидбеков от клиентов", учитывая что технология добрую четверть все рынка рдбмс занимает (всего оракл это 50% рынка), это сильно.
реально топикастеру надо смотреть мсскл где мультимастер репликация из коробки и во всех редакциях + много у кого нормально работает.
оракл конечно круто, но смысла тратить много больше на явно не космические задачи явно нет. EE редакция со всякими RAC, golden gate чудовищно дороги, в стандарт редакции репликация кастрированная хрень. я когда исследовал вопрос, нашел http://www.dbvisit.com/ которые предлагают репликацию под оракл стандарт едишен. вроде они и под другие субд предлагают.

[Mark]

Решений для повышения отказоустойчивости базы данных много. Как пример на Оракле это Real Application Cluster (RAC) c Transparent Application Failover(TAF), or Oracle Physical Standby c Dataguard. Что использовать, зависит от требований к отказоустойчивости: несколько минут или несколько секунд.

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

Бояцца не надо
С моей точки зрения надо "брать" проверенные технологии с техподдержкой. А если сами "не шмогли", то заплатить консультатнту или просто посмотреть доку.

А если серьезно : можно сразу не брать, можно просто почитать. Качнуть пробную версию. ИМХО если нет опыта с Оракл, то Oracle RAC поставить может не получится. Сразу надо сказать : Oracle RAC - Это очень дoрого. Если не надо отказоусточивости в секунды, то можно обойтись Oracle Standard Edition with Physical Standby and Dataguard. Получится гораздо бюджетнее.

Тут несколько наоборот в Standard Edition (SE)- RAC is free. А Dataguard в SE нету.

[Boriskin]

реально топикастеру надо смотреть мсскл где мультимастер репликация из коробки и во всех редакциях + много у кого нормально работает.

А МССКЛ вообще живет на линуксах?

[Flash-04]

2017 - да!

[Boriskin]

А чего так воодушевленно?

[Flash-04]

Ну раз тебе нужно...

[valchkou]

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

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

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

[major Major Major Major]

Встала след. задача - сделать DB solution с примерно следующими характеристиками

На Монго это все делается с пол пинка. Я в свое время настроил с нуля replica set за пару часов не имея никакого понятия как оно работает заранее. При этом у меня пара нодов крутилась в офисе а третья машина была у девелопера в России (для быстроты отладки), уходя в оффлайн постоянно. Был поражен лекгостью с какой все это заработало

[valchkou]

Встала след. задача - сделать DB solution с примерно следующими характеристиками

На Монго это все делается с пол пинка. Я в свое время настроил с нуля replica set за пару часов не имея никакого понятия как оно работает заранее. При этом у меня пара нодов крутилась в офисе а третья машина была у девелопера в России (для быстроты отладки), уходя в оффлайн постоянно. Был поражен лекгостью с какой все это заработало

монго это хорошая опция, проста не только в установке но и для програмистов
вопрос в объемах данных и high availability
если когда вдруг потребуется шардинг то вот где и начинается засада

[major Major Major Major]

Встала след. задача - сделать DB solution с примерно следующими характеристиками

На Монго это все делается с пол пинка. Я в свое время настроил с нуля replica set за пару часов не имея никакого понятия как оно работает заранее. При этом у меня пара нодов крутилась в офисе а третья машина была у девелопера в России (для быстроты отладки), уходя в оффлайн постоянно. Был поражен лекгостью с какой все это заработало

монго это хорошая опция, проста не только в установке но и для програмистов
вопрос в объемах данных и high availability
если когда вдруг потребуется шардинг то вот где и начинается засада

Да, у них отличный драйвер для .net с поддержкой линка. Работал и из r studio без проблем. Шардинг это уже сложнее, там надо думать и лучше на этапе дизайна базы. Я когда налаживал наверное раза три все убивал нафиг и начинал с нуля, думаю пару тройку дней потратил. Но топикстартеру шардинг вряд ли понадобится. Я рекомендую поставить и поиграться. Монговские процессы можно поднять на одной машине, то есть для первоначального устройства реплики сета запустить три штуки локально, никаких дополнительных серверов не потребуется, а потом присоединять внешние по мере надобности.

[valchkou]

ну тогда https://mariadb.com/

[iDesperado]

На Монго это все делается с пол пинка. Я в свое время настроил с нуля replica set за пару часов не имея никакого понятия как оно работает заранее. При этом у меня пара нодов крутилась в офисе а третья машина была у девелопера в России (для быстроты отладки), уходя в оффлайн постоянно. Был поражен лекгостью с какой все это заработало

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

[tessob]

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

Более двадцати лет работаю с Ораклом. Если вы не знакомы с этими продуктами/технологиями, то это ваши проблемы
Обозвать Оракл "проприетарные технологии с неочевидными сайд-эффектами и минимумом открытых фидбеков от клиентов" , спасибо, посмешили. В Гугл батенька

Простите, но именно такие специалисты как вы и отпугивают меня от таких брендов, как Oracle. Посмотрите сами, ваш RAC - до 100 километров. Вы действительно считаете, что если я размещу кластер на разных материках в публичных сетях, то никаких сайд эффектов у меня точно не будет?

[iDesperado]

Простите, но именно такие специалисты как вы и отпугивают меня от таких брендов, как Oracle. Посмотрите сами, ваш RAC - до 100 километров. Вы действительно считаете, что если я размещу кластер на разных материках в публичных сетях, то никаких сайд эффектов у меня точно не будет?

я тоже считаю, что нужно быть ну очень крупным спецом, что бы после 20 лет с ораклом оставались "неочевидные сайд-эффекты" при синхронизации буферного кэша оракла. там требование sync в микросекунды, какие сотни км ? возьмите что-то попроще, вы явно 20 лет потеряли впустую. возьмите NoSQL, там все заметно проще.

[major Major Major Major]

На Монго это все делается с пол пинка. Я в свое время настроил с нуля replica set за пару часов не имея никакого понятия как оно работает заранее. При этом у меня пара нодов крутилась в офисе а третья машина была у девелопера в России (для быстроты отладки), уходя в оффлайн постоянно. Был поражен лекгостью с какой все это заработало

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

Ну так от задачи и от подхода зависит. При правильно построенной модели документов в их идеологии много из мира SQL становится уже не особо нужным. Я не утверждаю что Монго это замена скажем ms sql для любой задачи, у них своя ниша где уже sql server неуютно себя ощущает (вот такая региональная репликация к примеру, или те же aggregation pipeline). У меня системы есть как на той так и на другой платформе, главное не забывать про поговорку про молоток и гвозди.