Я считал вопрос и ответы в том, Как установить репликацию MySQL с минимальным временем простоя. Похоже, что я могу получить ведомый DB в синхронизацию без времени простоя, если я использую только таблицы Innodb.
Мои первичные таблицы используют механизм Innodb, но у меня также есть ряд таблиц, который записывает историю первичных таблиц. Ряд триггеров прерывает обновления и делает копию старых данных, прежде чем это будет изменено, наряду с меткой времени. Эти данные хранятся в архивных таблицах, которые только когда-либо добавляются к.
Таким образом, я могу использовать подобную технику для получения репликации, обходящейся без помощи времени простоя?
Я не возражаю, если архивные таблицы временно вне синхронизации и могут жить с нею, если они не идеальная запись изменений, которые произошли во время синхронизирующего процесса. Мое первое беспокойство - то, что доступность innodb таблиц должна иметь минимальное прерывание.
Количество включенных таблиц является довольно большим, и несколько динамичным. Решения, которые не включают вручную входящие списки таблиц, были бы намного лучше.
Я перемещаюсь от mariadb 5.5. Я в настоящее время планирую перемещение в ту же версию на новом сервере и затем рассматриваю то обновление отдельно, но если обновление целевой версии имело бы значительное значение, скажите так.
Можно попробовать использовать percona xtradb cluster, но имейте в виду, что для обработки COMMIT-ошибок могут понадобиться некоторые изменения кода, как объяснялось здесь:
Все запросы выполняются локально на узле, и есть специальная обработка только на COMMIT. После выдачи COMMIT транзакция должна пройти сертификацию на всех узлах. Если она не пройдет, вы получите ОШИБКА в качестве ответа на этот запрос. После этого транзакция применяется на локальном узле.