Я прочитал вопрос и ответы на Как настроить репликацию MySQL с минимальным временем простоя. Похоже, я могу синхронизировать подчиненную БД без простоев, если использую только таблицы Innodb.
В моих основных таблицах используется механизм Innodb, но у меня также есть набор таблиц, в которых записывается история основных таблиц. Набор триггеров перехватывает обновления и делает копию старых данных перед их изменением вместе с меткой времени. Эти данные хранятся в архивных таблицах, которые только когда-либо добавляются.
Могу ли я использовать аналогичную технику, чтобы репликация продолжалась без простоев?
Я не возражаю, если архивные таблицы временно не синхронизированы, и могу смириться с этим, если они не являются идеальной записью изменений, произошедших во время процесса синхронизации. Меня прежде всего беспокоит то, что доступность таблиц innodb не должна прерываться или почти не прерываться.
Количество задействованных таблиц довольно велико и несколько динамично. Намного лучше были бы решения, которые не предполагают составления списков таблиц вручную.
Перехожу с mariadb 5.5. В настоящее время я планирую перейти на ту же версию на новом сервере, а затем обрабатывать это обновление отдельно, но если обновление целевой версии будет иметь существенное значение, сообщите об этом.
Вы можете попробовать использовать перкону кластер xtradb , но имейте в виду, что вам могут потребоваться некоторые изменения кода для обработки ошибок COMMIT, как описано Вот:
Все запросы выполняются локально на узле, а специальная обработка есть только на COMMIT. Когда выдается COMMIT, транзакция должна пройти сертификацию на всех узлах. Если он не пройдет, вы получите ERROR в качестве ответа на этот запрос. После этого транзакция применяется на локальном узле.