16.3.5. Улучшение Производительности Репликации

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

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

Один способ улучшить производительность процесса репликации состоит в том, чтобы создать более глубокую структуру репликации, которая позволяет ведущему устройству тиражироваться только к одному ведомому устройству, и для остающихся ведомых устройств, чтобы соединиться с этим основным ведомым устройством для их отдельных требований репликации. Выборку этой структуры показывают в рисунке 16.3, "Используя Дополнительный Узел Репликации, чтобы Улучшить Производительность".

Рисунок 16.3. Используя Дополнительный Узел Репликации, чтобы Улучшить Производительность

Используя дополнительную репликацию размещают, чтобы улучшить производительность

Для этого, чтобы работать, следует сконфигурировать экземпляры MySQL следующим образом:

Ведущее устройство 1 является основным ведущим устройством, где все изменения и обновления пишутся базе данных. Двоичное журналирование должно быть включено на этой машине.
Ведущее устройство 2 является ведомым устройством Ведущего устройства 1, который обеспечивает функциональность репликации для остатка от ведомых устройств в структуре репликации. Ведущее устройство 2 является единственной машиной, разрешенной соединяться с Ведущим устройством 1. Ведущему устройству 2 также включали двоичному журналированию, и --log-slave-updates опция так, чтобы инструкции репликации от Ведущего устройства 1 были также записаны Ведущему устройству 2 двоичный журнал так, чтобы они могли тогда быть тиражированы в истинные ведомые устройства.
Ведомое устройство 1, Ведомое устройство 2, и Ведомое устройство, 3 действия как ведомые устройства Ведущего устройства 2, и тиражируют информацию от Ведущего устройства 2, который фактически состоит из обновлений, входило в систему Ведущее устройство 1.

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

Если Ваши ведомые устройства испытывают затруднения, не отстающие от процесса репликации на ведущем устройстве, есть много доступных опций:

Если возможный, помещает релейные журналы и файлы данных на различных физических дисках. Чтобы сделать это, используйте --relay-log опция, чтобы определить расположение релейного журнала.
Если ведомые устройства значительно медленнее чем ведущее устройство, можно хотеть разделить ответственность за тиражирование различных баз данных в различные ведомые устройства. См. Раздел 16.3.4, "Тиражируя Различные Базы данных в Различные Ведомые устройства".
Если Ваше ведущее устройство использует транзакции, и Вы не обеспокоены поддержкой транзакции на Ваших ведомых устройствах, используете MyISAM или другой нетранзакционный механизм на ведомых устройствах. См. Раздел 16.3.2, "Используя Репликацию с Различными Основными и Ведомыми Механизмами Хранения".
Если Ваши ведомые устройства не действуют как ведущие устройства, и у Вас есть потенциальное решение на месте, чтобы гарантировать, что можно перевести ведущее устройство в рабочее состояние в случае отказа, то можно выключить --log-slave-updates. Это предотвращает "немые" ведомые устройства от также журналирования событий, которые они выполнили в их собственный двоичный журнал.