У меня есть производственная база данных с репликацией master-slave. Резервное копирование производственной БД выполняется с ведомого сервера.
Я бы хотел сделать так, чтобы произвольное количество сред разработки могло быть репликой ведомого. Проблема в том, что, в то время как подчиненный сервер ничего не записывает на него, серверы разработки могут. Например, даже простой вход через веб-интерфейс на сайт разработчика может вызвать INSERT в таблицу loginLog или что-то подобное, что может привести к остановке репликации ведомого устройства с такими ошибками:
Не удалось выполнить событие Write_rows для таблицы dbname.tablename; Повторяющаяся запись "15610534" для ключа "PRIMARY", код ошибки: 1062; ошибка обработчика HA_ERR_FOUND_DUPP_KEY; главный журнал событий bin-log.000829, end_log_pos 8209872
Мой вопрос ... можно ли настроить подчиненную БД таким образом, чтобы при обнаружении конфликтов данные главной БД перезаписывали данные подчиненной БД?
Преимущество этого будет означать, что разработчики могут иметь доступ к данным в реальном времени в среде разработки. Например, если разработчик разрабатывает какой-то отчет о продажах в реальном времени (например, «таблицу лидеров»), эти данные в реальном времени могут быть полезны.
Нет, вы не можете устранить такие проблемы с помощью репликации mysql.
Но почему при разработке отчета могут возникнуть ключевые ошибки нарушения?
Большой вопрос заключается в том, насколько актуальной должна быть копия ваших производственных данных для разработки? А о каком количестве данных мы говорим?
Вы можете запустить очень большое количество ведомых устройств с одного ведущего устройства. Но, возможно, правильным решением здесь является запуск дополнительного ведомого устройства в качестве копии основного тома производственных данных, а затем отключение его на ночь для создания копий уровня файловой системы, которые затем монтируются на новых экземплярах. Это легко сделать с помощью сетей хранения данных. Но это также возможно с копиями, запущенными на том же хосте, или путем запуска подчиненного устройства копирования основного тома поверх зеркала локального диска и DRBD, а затем переназначения удаленного DRBD на зеркало RAID для синхронизации спутниковой копии.
Или, если это небольшая база данных, просто используйте rsync.
Это означает, что вы потеряете все тестовые данные, созданные между моментальными снимками.