16.3.6 Improving Replication Performance — MySQL 5.7

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

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

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

Один из способов улучшить производительность процесса репликации — создать более глубокую структуру репликации, которая позволит источнику выполнять репликацию только с одной репликой, а остальные реплики будут подключаться к этой основной реплике для своих индивидуальных требований к репликации. Пример такой структуры показан на рис. 16.3 «Использование дополнительного источника репликации для повышения производительности».

Рисунок 16.3 Использование дополнительного источника репликации для повышения производительности

The server MySQL Source 1 replicates to the server MySQL Source 2, which in turn replicates to the servers MySQL Replica 1, MySQL Replica 2, and MySQL Replica 3.

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

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

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

Если ваши реплики испытывают проблемы с поддержанием процесса репликации в источнике, доступно несколько вариантов:

Если это возможно, поместите журналы пересылки и файлы данных на разные физические диски. Для этого установите системную переменную relay_log для указания расположения журнала пересылки.
Если реплики значительно медленнее источника, вы можете разделить ответственность за репликацию различных баз данных на разные реплики. См. раздел 16.3.5 «Репликация различных баз данных на разные реплики».
Если ваш источник использует транзакции, и вас не беспокоит поддержка транзакций на ваших репликах, используйте MyISAM или другой нетранзакционный движок на репликах. См. раздел 16.3.3 «Использование репликации с различными движками хранения источника и реплики».
Если ваши реплики не действуют как источники, и у вас есть потенциальное решение, чтобы обеспечить возможность запустить источник в случае сбоя, то вы можете отключить системную переменную log_slave_updates на репликах. Это предотвращает, чтобы «глупые» реплики также записывали события, которые они выполнили, в свой собственный двоичный лог.