Поделиться через

Чтение реплик в Базе данных Azure для MySQL

MySQL является популярным ядром базы данных для поддержки мобильных и веб-приложений в Интернете. Многие клиенты используют Базу данных Azure для MySQL для широкого спектра приложений, включая онлайн-образование, потоковую передачу видео, цифровые платежи, электронную коммерцию, игры, новостные порталы, государственные и медицинские веб-сайты. Эти службы должны иметь возможность обслуживать и масштабировать трафик в веб-приложении или мобильном приложении.

На стороне приложений разработчики обычно используют Java или PHP. Они переносят приложение для запуска в масштабируемых наборах виртуальных машин Azure, службах приложений Azure или контейнеризировать его для запуска в службе Azure Kubernetes (AKS). С помощью масштабируемого набора виртуальных машин, службы приложений или AKS в качестве базовой инфраструктуры масштабирование приложений упрощается путем мгновенной подготовки новых виртуальных машин и репликации компонентов без отслеживания состояния приложений для удовлетворения запросов. Однако база данных часто становится узким местом в качестве централизованного компонента с отслеживанием состояния.

Функция реплики чтения позволяет реплицировать данные из гибкого экземпляра Базы данных Azure для MySQL на сервер только для чтения. Вы можете реплицировать данные с исходного сервера максимум на 10 реплик. Реплики обновляются асинхронно с помощью собственной технологии репликации файлов на основе двоичных журналов (binlog) ядра MySQL. Дополнительные сведения о репликации binlog MySQL см. в этой статье.

Вы управляете репликами как новые серверы, как и исходные экземпляры гибкого сервера Базы данных Azure для MySQL. Плата за выставление счетов за каждую реплику чтения взимается на основе подготовленных вычислений в виртуальных ядрах и хранилище в ГБ в месяц. Дополнительные сведения см. на странице цен.

Функция реплики чтения доступна только для экземпляров гибкого сервера базы данных Azure для MySQL в ценовых категориях "Общее назначение" или "Оптимизированная по памяти". Убедитесь, что исходный сервер находится в одной из этих ценовых категорий.

Дополнительные сведения о функциях и проблемах репликации MySQL см. в документации по репликации MySQL.

Примечание.

Эта статья содержит упоминания термина slave (ведомый) . Корпорация Майкрософт больше не использует его. При удалении термина из программного обеспечения мы удаляем его из этой статьи.

Распространенные варианты использования для реплики чтения

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

Ниже приведены распространенные сценарии.

  • Масштабирование рабочих нагрузок чтения, поступающих из приложения, с помощью упрощенного прокси-сервера подключения, такого как ProxySQL , или с помощью шаблона на основе микрослужб для масштабирования запросов на чтение из приложения для чтения реплик
  • Использование реплик чтения в качестве источника данных для рабочих нагрузок бизнес-аналитики или аналитических отчетов
  • Прием данных телеметрии в ядро СУБД MySQL при использовании нескольких реплик чтения для создания отчетов о данных в сценариях Интернета вещей или производства

Так как реплики доступны только для чтения, они напрямую не снимают с источника нагрузку, связанную с записью Эта функция не нацелена на рабочие нагрузки с большим объемом операций записи.

В реплике чтения используется асинхронная репликация MySQL. Этот компонент также не предназначен для сценариев синхронной репликации. Существует измеримая задержка между источником и репликой. Данные на реплике и на источнике в итоге будут согласованы. Используйте этот компонент только для таких рабочих нагрузок, которым не страшна такая задержка.

Репликация между регионами

Регион размещения реплики чтения может отличаться от региона для исходного сервера. Репликация между регионами полезна для таких сценариев, как планирование аварийного восстановления или перенос данных ближе к пользователям. Гибкий сервер Базы данных Azure для MySQL позволяет подготовить реплику чтения в любых поддерживаемых регионах Azure , где доступна гибкая база данных Azure для MySQL. С помощью этой функции исходный сервер может иметь реплику в парном регионе или в регионах универсальной реплики. Ознакомьтесь со списком регионов Azure, где сейчас доступен гибкий сервер Базы данных Azure для MySQL.

Создание реплики

При запуске рабочего процесса создания реплики создается пустой экземпляр гибкого сервера Базы данных Azure для MySQL. Новый сервер содержит данные, которые находились на исходном сервере. Время создания зависит от объема данных на исходном сервере и времени, прошедшего с момента последнего еженедельного полного резервного копирования. Время может варьироваться от нескольких минут до нескольких часов.

Примечание.

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

Дополнительные сведения о создании реплики чтения на портале Azure см. здесь.

Подключение к реплике

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

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

Вы можете подключиться к реплике с помощью имени узла и допустимой учетной записи пользователя, так как в обычном экземпляре гибкого сервера База данных Azure для MySQL. Для сервера с именем myreplica с именем администратора myadmin можно подключиться к реплике с помощью интерфейса командной строки MySQL:

mysql -h myreplica.mysql.database.azure.com -u myadmin -p

При появлении запроса введите пароль для учетной записи пользователя.

Мониторинг репликации

Служба "База данных Azure для гибкого сервера MySQL" также предоставляет для Azure Monitor метрику Задержка репликации в секундах. Эта метрика доступна только для реплик. Azure Monitor вычисляет эту метрику с помощью метрики в команде seconds_behind_master MySQL SHOW SLAVE STATUS . Задайте оповещение, чтобы уведомить вас, когда задержка репликации превышает неприемлемое пороговое значение для рабочей нагрузки.

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

Внимание

Реплика чтения использует технологию репликации на основе хранилища, которая больше не использует метрику, доступную SLAVE_IO_RUNNING/REPLICA_IO_RUNNING в команде MySQL.SHOW SLAVESTATUS'/'SHOWREPLICA STATUS Это значение всегда отображается как "Нет" и не указывает на состояние репликации. Чтобы узнать правильное состояние репликации, перейдите к метрикам репликации — IO на странице мониторинга.

Остановить репликацию

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

При остановке репликации на сервер-реплике сервер реплики теряет все ссылки на предыдущий исходный сервер и другие серверы-реплики. Автоматическая отработка отказа между исходным сервером и его серверами-репликами отсутствует.

Внимание

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

Дополнительные сведения см. в статье об остановке репликации в реплике.

Отработка отказа

Автоматическая отработка отказа между исходным сервером и серверами реплики не выполняется.

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

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

Совет

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

После отработки отказа в реплику выполните следующие действия:

  1. Остановите репликацию на реплику.

    Необходимо остановить репликацию, чтобы сервер реплики мог принимать записи. Этот процесс удаляет связь сервера-реплики с источника. После запуска остановки репликации серверный процесс обычно занимает около двух минут. Сведения о влиянии этого действия см. в разделе Остановка репликации этой статьи.

  2. Направьте приложение на реплику (бывшую).

    У каждого сервера уникальная строка подключения. Обновите приложение так, чтобы оно указывало на реплику (бывшую), а не на источник.

Когда приложение успешно обрабатывает операции чтения и записи, выполняется отработка отказа. Время простоя приложения зависит от обнаружения проблемы и выполнения шагов 1 и 2.

Глобальный идентификатор транзакции (GTID)

Глобальный идентификатор транзакции (GTID) — это уникальный идентификатор, создаваемый исходным сервером с каждой зафиксированной транзакцией. Гибкий сервер Базы данных Azure для MySQL по умолчанию отключает GTID. Версии 5.7 и 8.0 поддерживают GTID. Дополнительные сведения об GTID и его использовании см. в документации по Репликации MySQL с помощью GTID .

Чтобы настроить GTID, используйте следующие параметры сервера:

Параметр сервера Описание Значение по умолчанию Значения
gtid_mode Указывает, используются ли идентификаторы GTID для обнаружения транзакций. Изменения между режимами можно выполнить только один шаг за раз в порядке возрастания (например, OFF - ->OFF_PERMISSIVE>ON_PERMISSIVE -)>ON OFF* OFF: новые транзакции и транзакции репликации должны быть анонимными.
OFF_PERMISSIVE: новые транзакции являются анонимными. Реплицированные транзакции могут быть либо анонимными транзакциями, либо транзакциями GTID.
ON_PERMISSIVE: новые транзакции являются транзакциями GTID. Реплицированные транзакции могут быть либо анонимными транзакциями, либо транзакциями GTID.
ON: новые транзакции и транзакции репликации должны быть транзакциями GTID.
enforce_gtid_consistency Обеспечивает согласованность GTID, разрешая выполнение только тех инструкций, которые могут быть зарегистрированы транзакционно безопасным образом. Задайте значение ON перед включением репликации GTID. OFF* OFF: всем транзакциям разрешено нарушать требования к согласованности GTID.
ON: всем транзакциям запрещено нарушать требования к согласованности GTID.
WARN: всем транзакциям разрешено нарушать требования к согласованности GTID, но будет отображаться предупреждение.

Примечание.

Для экземпляров гибкого сервера Базы данных Azure для MySQL, имеющих функцию высокой доступности, по умолчанию задано ONзначение по умолчанию.

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

Идентификаторы GTID можно изменить с одного значения на другое только один шаг за раз в порядке возрастания режимов. Например, если gtid_mode в данный момент задано OFF_PERMISSIVEзначение, его можно изменить на ON_PERMISSIVE нее ON.

Чтобы обеспечить согласованность репликации, его нельзя обновить для основного сервера или сервера-реплики.

Установите значение enforce_gtid_consistency перед параметром ONgtid_modeON .

Чтобы включить GTID и настроить поведение согласованности, обновите gtid_mode параметры и enforce_gtid_consistency параметры сервера. Используйте параметры сервера в базе данных Azure для MySQL — гибкий сервер с помощью портала Azure или настройки параметров сервера в Базе данных Azure для MySQL — гибкий сервер с помощью Azure CLI.

Если исходный сервер включает GTID (gtid_mode = ON), только что созданные реплики также позволяют включить GTID и использовать репликацию GTID. Чтобы обеспечить согласованность репликации, невозможно изменить gtid_mode после создания первичных или реплик серверов с включенным GTID.

Рекомендации и ограничения

Сценарий Ограничения и рекомендации
Реплика на сервере в ценовой категории с увеличивающейся производительностью Не поддерживается
Цены Стоимость запуска сервера-реплики зависит от региона, на котором выполняется сервер реплики.
Время простоя исходного сервера и перезапуск При создании реплики чтения не требуется перезапуск или простой. Эта операция является оперативной операцией.
Новые реплики Вы создаете реплику чтения в качестве нового экземпляра гибкого сервера Базы данных Azure для MySQL. Вы не можете сделать существующий сервер в реплику. Невозможно создать реплику другой реплики чтения.
Конфигурация реплики Создайте реплику с помощью той же конфигурации сервера, что и источник. После создания реплики можно изменить несколько параметров независимо от исходного сервера: создание вычислительных ресурсов, виртуальные ядра, хранилище и период хранения резервных копий. Вы также можете самостоятельно изменить уровень вычислений.

ВАЖНО. Перед обновлением конфигурации исходного сервера до новых значений обновите конфигурацию реплики до равных или более больших значений. Это позволит реплике справляться с нагрузкой, соответствующей новым параметрам исходного сервера.
Метод подключения и параметры параметров наследуются от исходного сервера к реплике при создании реплики. После этого правила реплики будут независимыми.
Остановленные реплики Если вы прекратите репликацию между исходным сервером и репликой чтения, остановленная реплика станет отдельным сервером и начнет выполнять операции чтения и записи. Вы не можете снова сделать автономный сервер в реплику.
Удаленные исходные серверы При удалении исходного сервера репликация останавливается на всех репликах чтения. Реплики чтения автоматически становятся автономными серверами и могут выполнять операции чтения и записи. Удаляется сам исходный сервер.
Учетные записи пользователей Пользователи на исходном сервере реплицируются в реплики чтения. Вы можете подключиться только к реплике чтения с помощью учетных записей пользователей, доступных на исходном сервере.
Параметры сервера Чтобы предотвратить синхронизацию данных и избежать их возможной потери, при использовании реплики чтения некоторые параметры сервера блокируются.
На исходном сервере и сервере реплики блокируются следующие параметры сервера:
- innodb_file_per_table
- log_bin_trust_function_creators
Параметр event_scheduler заблокирован на серверах реплик.
Чтобы обновить один из предыдущих параметров на исходном сервере, удалите серверы реплики, обновите значение параметра в источнике и повторно создайте реплики.
Параметры уровня сеанса При настройке параметров уровня сеанса, таких как "foreign_keys_checks" на реплике чтения, убедитесь, что значения параметров, заданные на реплике чтения, согласованы с параметрами исходного сервера.
Добавление столбца первичного ключа AUTO_INCREMENT в существующую таблицу на исходном сервере Мы не рекомендуем изменять таблицу AUTO_INCREMENT после создания реплики чтения, так как это действие прерывает репликацию. Если вы хотите добавить столбец автоматического увеличения после создания сервера реплики, рассмотрите следующие подходы:
— создайте новую таблицу с той же схемой, что и таблица, которую вы хотите изменить. В новой таблице измените столбец с AUTO_INCREMENTпомощью и восстановите данные из исходной таблицы. Удалите старую таблицу и переименуйте ее в источнике; Этот подход не требует удаления сервера-реплики, но может потребоваться большая стоимость вставки для создания резервной таблицы.
— повторно создайте реплику после добавления всех столбцов автоматического увеличения.
Другие — Создание реплики реплики не поддерживается.
— Таблицы в памяти могут привести к тому, что реплики не будут синхронизированы. Это ограничение связано с технологией репликации MySQL. Дополнительные сведения см. в справочной документации по MySQL.
- Убедитесь, что у таблиц исходного сервера есть первичные ключи. Отсутствие первичных ключей может привести к задержке репликации между источником и репликами.
— Просмотрите полный список ограничений репликации MySQL в документации по MySQL.

Связанный контент

  • Last updated on