Насколько быстро происходит репликация MySQL?

Я подумываю о настройке репликации нашей базы данных mysql, чтобы иметь возможность иметь локальных подчиненных в каждом из наших филиалов, а также иметь главного в главном офисе для повышения производительности приложений (значительно) в наших филиалах.

Сама БД не такая большая (<1 ГБ), но мне интересно; с учетом 200-300 записей обновлений / мин. Какова скорость репликации? (предполагая, во-первых, общее dsl-соединение 5 Мб, быстрее, если это необходимо - пытаясь максимально снизить затраты, но денег хватит на большее)

Копируются ли целые таблицы партиями? Выполняется ли репликация по требованию, так как каждая запись в таблице обновляется (из документов, я думаю, я вижу, что она настраивается)?

Примечания:

• Я думаю , 1 хозяин, 2 рабов (2 филиалов в настоящее время) установки , как в документации здесь за исключением того, что это приложение, а не веб - клиент
• Любое обновление, выполненное на ведущем устройстве, должно реплицироваться на другие ведомые устройства в течение <10 минут.
• Все это предполагает, что я могу порадовать наш ORM (DevExpress XPO) концепцией чтения из ведомого устройства и записи в ведущий.

Репликация MySQL происходит как можно ближе к реальному времени, насколько это ограничено дисковым и сетевым вводом-выводом. Рабы открывают розетку для мастера, которая остается открытой. Когда транзакция происходит на ведущем устройстве, она записывается в журнал и просто воспроизводится на ведомом (ых). Если сокет между ведущим и ведомым устройством прерван, то при следующем успешном соединении бинлог воспроизводится для ведомого устройства.

Репликация с несколькими мастерами делает то же самое, но в обоих направлениях.

Некоторые базовые расчеты помогут вам лучше определить ваши потребности в пропускной способности.

Average transaction size * number of slaves * updates/minute = bandwidth needed

Надеюсь это поможет.

Репликация на ведомой стороне обрабатывается двумя независимыми потоками.

• Процесс чтения журнала, который подключается к мастеру, получает каждый оператор изменения данных и записывает его в журнал ретрансляции.
• Процесс записи SQL, который получает новые элементы из журнала ретрансляции, фиксирует операторы в базе данных ведомых устройств, а затем перемещает указатель подчиненного устройства за этим оператором, чтобы указать получение запроса.

Задержка репликации ограничивается вводом-выводом, во-первых, вводом-выводом в ведомой базе данных для применения транзакций из журнала ретрансляции (что может включать сложные запросы SQL), а во-вторых, вводом-выводом в ведущем устройстве для считывания его двоичного журнала и передачи его каждому ведомому устройству.

Репликация MySQL увеличивает емкость запросов на чтение, но не увеличивает производительность записи запросов, которая контролируется со скоростью, с которой ввод-вывод может быть сброшен в binlog как на главном, так и на ведомом устройствах

Репликация в MySQL довольно быстро доставляет данные на ведомое устройство (быстрее, чем вы сможете запустить UPDATEна ведущем устройстве и переключиться в другое окно для запуска SELECTна ведомом устройстве, если(и только если) сетевые подключения все в порядке, и все работает нормально. Любое соединение класса DSL должно подойти для общего случая ваших обычных небольших запросов, но для больших запросов вставки / обновления может потребоваться некоторое время для копирования и повторной синхронизации в случае заполнения репликации (а MySQL жестоко склонен к это, к сожалению) займет некоторое время (снова скопировав всю базу данных из мастера). Существуют хитрости для ограничения воздействия ресинхронизации на ваш мастер, например, установка MySQL на LVM, чтобы вы могли сделать очень быструю блокировку / моментальный снимок и rsync содержимое моментального снимка для ведомого устройства, но в конечном итоге повторная синхронизация будет неудачной.