19.4.7 Improving Replication Performance — MySQL 8.4

19.4.7 Повышение производительности репликации

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

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

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

Рисунок 19.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-replica-updates (по умолчанию). С этим параметром инструкции репликации из Источника 1 также записываются в двоичный лог Источника 2, чтобы затем они могли быть скопированы в реальные реплики.
Реплика 1, Реплика 2 и Реплика 3 действуют как реплики Источника 2 и копируют информацию из Источника 2, которая фактически состоит из обновлений, зарегистрированных в Источнике 1.

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

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

Если возможно, поместите файлы журналов реле и данные на разные физические диски. Для этого установите системную переменную relay_log для указания расположения файла журнала реле.
Если проблема заключается в высокой активности ввода-вывода диска при чтении файла двоичного лога и файлов журнала реле, рассмотрите возможность увеличения значения системной переменной rpl_read_size. Эта системная переменная контролирует минимальный объем данных, считываемых из файлов логов, и его увеличение может уменьшить чтение файлов и задержки ввода-вывода, когда данные файла не кэшируются операционной системой. Обратите внимание, что для каждого потока, читающего файлы двоичного лога и журнала реле, включая потоки дампов на источниках и координационные потоки на репликах, выделяется буфер размером этого значения. Поэтому установка большого значения может повлиять на потребление памяти серверами.
Если реплики значительно медленнее источника, вы можете разделить ответственность за репликацию различных баз данных на различные реплики. См. Раздел 19.4.6, «Репликация разных баз данных на разных репликах».
Если ваш источник использует транзакции, и вы не беспокоитесь о поддержке транзакций на ваших репликах, используйте MyISAM или другой нетранзакционный движок на репликах. См. Раздел 19.4.4, «Использование репликации с разными движками хранилища источника и реплики».
Если ваши реплики не выступают в качестве источников и у вас есть потенциальное решение, чтобы обеспечить возможность запустить источник в случае сбоя, вы можете отключить log_replica_updates. Это предотвращает, чтобы «глупые» реплики также регистрировали события, которые они выполнили, в свой собственный двоичный лог.