У нас есть базы данных MySQL 5.1 в 5 разных местах, которые нам нужно поддерживать как можно более синхронизированными. Каждый офис должен читать / писать с / на локальный сервер в этом офисе, но мне нужна БД в каждом офисе, чтобы отражать изменения, сделанные во всех офисах. Изменения в данных производятся только в обычные рабочие часы с 9 до 5, а скорость WAN низкая (1-5 Мбит / с).
Я не могу передавать записи со всех сайтов одному мастеру, и мое понимание из документов и других Вопросы и ответы здесь заключается в том, что репликация мастер-мастер не подходит для такой ситуации и может привести к потере данных.
Вот подход, к которому я склоняюсь:
настроить триггеры для аудита вставок, обновлений (только измененных полей) и удалений и записать их в 1 место в конце дня.
задание выполняется каждую ночь в каждом офисе, который загружает весь журнал аудита для всех офисов и записывает самые последние изменения на основе отметки времени журнала аудита - это упрощенный подход, но у нас нет многих ограничений, о которых нужно беспокоиться, и приложение, использующее данные, создает идентификаторы GUID для новых записей, поэтому не нужно беспокоиться об автоинкременте.
Есть ли лучший способ, чем этот ручной подход, или есть лучший способ сделать это вручную? Мне что-то не хватает в отношении репликации с несколькими мастерами? Это далеко не идеально, но, по крайней мере, позволяет нам синхронизироваться в начале каждого дня. Буду рад любым предложениям.
Спасибо.
Галера - это синхронное решение с несколькими мастерами, которое может вам пригодиться. Я сам мало что знаю об этом и считаю это эзотерическим, но, возможно, вам стоит присмотреться к нему поближе.
Ура
Если вы придерживаетесь этого подхода, потенциальный компромисс для скорости может заключаться в использовании флагов для новых и грязных записей (new может быть по умолчанию для строк INSERTed, грязный может быть установлен триггером на UPDATE), но зависит от рабочего процесса и требований аудита. Вместо того, чтобы реплицировать все повторяющиеся изменения записи в течение дня, во всех других системах будет обновлено только окончательное значение, а затем флаг будет сброшен. Вам все равно понадобится таблица для удалений (если вы не хотите использовать очень популярную временную метку «deleted_on» и, вероятно, изменить весь свой код). Если записи не сильно меняются после того, как они были написаны, вы не получите от этого многого.
Однако для этого потребуется, чтобы сервер был включен в конце дня. С помощью таблицы аудита вы можете периодически записывать таблицу аудита в файл в другом месте (а не только в конце дня) в случае сбоя БД.
В зависимости от приложения есть вещи, которые прерываются при репликации, а именно конфликты между вставками ключей auto_increment.
Репликация будет работать, круговая или звездообразная, и она будет передавать только операции, требующие записи. Если он получит уже обработанный пакет записи, он проигнорирует его. Поскольку полоса пропускания между сайтами мала, при отсутствии проблем с коллизиями вы можете остановить репликацию ведомого устройства в рабочее время, чтобы сэкономить пропускную способность, и запустить ее в конце дня. Если ваш код не знает, что он выполняет обновления, у вас, вероятно, будет несколько раз, когда ведомое устройство останавливается из-за ошибки и требует внимания.
Если у вас достаточно места, вы можете установить начальное значение auto_increment для каждого из удаленных офисов достаточно далеко друг от друга, чтобы они не перекрывали друг друга.
Репликация не идеальна для вашей ситуации, и поскольку ваша система на самом деле не знает, что репликация происходит, у вас могут быть некоторые проблемы, но она может работать достаточно хорошо.