Никогда не используйте репликацию мастер-мастер. Нет механизма разрешения конфликтов. Если вы попытаетесь выполнить запись на оба мастера одновременно (или на один мастер до того, как он обнаружит изменения, которые вы ранее записали в другой), вы получите сценарий с нарушенной репликацией. Служба не остановится, они будут просто дрейфовать дальше и дальше, делая невозможным примирение.
Не используйте репликацию MySQL без хорошо продуманного мониторинга, чтобы убедиться, что он работает нормально. Не думайте, что из-за того, что вы настроили его правильно, он будет продолжать работать, ИЛИ оставаться в синхронизации.
НЕОБХОДИМО иметь хорошо документированную, хорошо протестированную процедуру для восстановления рабов из-за несинхронизации или остановки. Иметь аналогично документированную процедуру установки нового ведомого с нуля.
Вашему приложению может потребоваться достаточный интеллект, чтобы знать, что ведомое устройство не синхронизировано или остановлено, и что его не следует использовать, если вы заботитесь о правильных или обновленных данных. Для этого вам понадобится какая-то обратная связь с вашим мониторингом.
Если у вас есть раб, скажем, в США, когда ваш мастер находится в Европе, это обычно дает вам ожидаемую величину задержки, т.е. что-то на 150 мс больше, чем если бы они были в одном месте.
В MySQL ведомый не запускает запрос до тех пор, пока мастер его не завершит, поэтому он всегда будет отставать от времени, которое занимает обновление.
Кроме того, ведомое устройство является однопоточным, поэтому один «жесткий» запрос на обновление задержит все последующие.
Если вы настаиваете на своем главном на многопоточной загрузке записи, предполагая, что ваши ведомые устройства имеют идентичное оборудование, очень маловероятно, что они будут в состоянии поддерживать.