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

[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 без проблем. Шардинг это уже сложнее, там надо думать и лучше на этапе дизайна базы. Я когда налаживал наверное раза три все убивал нафиг и начинал с нуля, думаю пару тройку дней потратил. Но топикстартеру шардинг вряд ли понадобится. Я рекомендую поставить и поиграться. Монговские процессы можно поднять на одной машине, то есть для первоначального устройства реплики сета запустить три штуки локально, никаких дополнительных серверов не потребуется, а потом присоединять внешние по мере надобности.