Реплики чтения в Базе данных Azure для MySQL — гибкий сервер

ОБЛАСТЬ ПРИМЕНЕНИЯ: База данных Azure для MySQL — гибкий сервер

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

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

Функция чтения реплика позволяет реплика te данные из гибкого экземпляра сервера База данных 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 подключение будет выполняться с помощью CLI mysql:

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

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

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

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

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

Важно!

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

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

Репликацию между исходным сервером и репликой можно остановить. После остановки репликации между исходным сервером и репликой чтения реплика становится отдельным сервером. На отдельном сервере сохраняются все данные, которые существовали на нем на момент запуска команды "Остановить репликацию". Данные на отдельном сервере не синхронизируются с исходным сервером.

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

Важно!

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

Процесс остановки репликации описан в этой статье.

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

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

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

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

Совет

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

После того как вы решили выполнить отработку отказа на реплика:

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

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

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

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

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

Для настройки GTID доступны следующие параметры сервера.

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

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

Примечание.

• После включения GTID эту функцию невозможно отключить. Если вам нужно отключить GTID, обратитесь в службу поддержки.
• Идентификаторы GTID можно изменить с одного значения на другое только один шаг за раз в порядке возрастания режимов. Например, если в настоящее время для gtid_mode задано значение OFF_PERMISSIVE, можно изменить ON_PERMISSIVE, но не на ON.
• Чтобы обеспечить согласованность реплика, его нельзя обновить для главного или реплика сервера.
• Перед настройкой gtid_mode=ON рекомендуется задать значение SET enforce_gtid_consistency gtid_mode=ON.

Чтобы включить GTID и настроить поведение согласованности, обновите gtid_mode параметры и enforce_gtid_consistency параметры сервера с помощью портал Azure или Azure CLI.

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

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

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

Следующие шаги

• Узнайте, как создавать реплики чтения и управлять ими с помощью портала Azure.
• Узнайте, как создавать реплики чтения и управлять ими с помощью Azure CLI.