репликация, поле uuid в качестве первичного ключа, репликация на основе строк

Question

Я ищу лучший способ реализовать репликацию нескольких сайтов с MySDQL. Поскольку я в основном являюсь пользователем MS-SQL, я чувствую себя довольно некомфортно из-за терминологии репликации MySQL и нескольких версий MySQL, которые не выполняют одно и то же.

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

Итак, моя цель здесь - определить правильное правило первичного ключа, которое будет использоваться для наших таблиц. Поскольку нам нужны исключительно суррогатные ключи, у нас есть возможность использовать либо целочисленные \ autoincrement, либо поля uuid / uuid_short. Чтобы избежать конфликтов репликации, целое число \ autoincrement не соответствует нашим потребностям, поскольку может создавать конфликты репликации, когда между двумя синхронизациями оба сервера вставляют запись в одну и ту же таблицу. Поэтому, по моему мнению, правильное решение, позволяющее избежать конфликтов репликации \ первичного ключа:

• использовать поля uuid или uuid-short в качестве первичных ключей
• имеет соответствующие значения uuid, установленные сервером во время ВСТАВКИ
• установить репликацию в режим RBR (репликация на основе строк - звучит эквивалентно репликации слиянием MS-SQl), а не SBR (репликация на основе операторов - похоже на репликацию транзакций). Насколько я понимаю, RBR вставит вычисленное значение uuid «как есть» на других серверах во время репликации, в то время как SBR вызовет функцию uuid () и сгенерирует новое значение на каждом сервере ... что вызовет серьезную проблему!

Будет ли это работать?

Answer 1

Я думаю, что здесь есть две не связанные проблемы:

1

Выбор первичного ключа способом, который, вероятно, уникален - UUID является приемлемым подходом. Вы можете использовать его с SBR или RBR, при условии, что клиентское приложение генерирует UUID. Если вы вызываете функцию mysql для ее генерации, вам необходимо использовать репликацию на основе строк. Репликация на основе строк, как правило, намного лучше, поэтому единственной причиной, по которой вы хотите использовать репликацию на основе операторов, является обратная совместимость с подчиненным MySQL <5.1 или унаследованным приложением, которое зависит от некоторых его свойств. </p>

2

Во-вторых, вы хотите сделать репликацию с несколькими мастерами. ЭТО НЕ БУДЕТ РАБОТАТЬ.

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

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

В репликации MySQL отсутствует алгоритм «разрешения конфликтов», он просто останавливается и прерывается, если обнаружен конфликт.

Даже если предположить, что ваша база данных не содержит НИКАКИХ УНИКАЛЬНЫХ ИНДЕКСОВ, кроме первичных ключей, которые выделяются UUID, у вашего приложения все еще могут быть правила, которые приводят к сбою нескольких мастеров.

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