Реплики чтения в Базе данных Azure для MySQL — гибкий сервер
ОБЛАСТЬ ПРИМЕНЕНИЯ: 
База данных Azure для MySQL — гибкий сервер
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 подключение будет выполняться с помощью CLI mysql:
mysql -h myreplica.mysql.database.azure.com -u myadmin -p
При появлении запроса введите пароль для учетной записи пользователя.
Мониторинг репликации
гибкий сервер База данных Azure для MySQL предоставляет Задержка репликации в секундах в Azure Monitor. Эта метрика доступна только для реплик. Эта метрика вычисляется на основе метрики seconds_behind_master, которую можно получить с помощью команды MySQL SHOW SLAVE STATUS. Настройте отправку предупреждений о достижении недопустимого для вашей рабочей нагрузки значения задержки репликации.
Если вы заметили увеличенную задержку репликации, см. статью Устранение неполадок репликации для устранения неполадок и выявления возможных причин.
Внимание
Реплика чтения использует технологию репликации на основе хранилища, которая больше не использует метрику "SLAVE_IO_RUNNING"/"REPLICA_IO_RUNNING", доступную в команде MySQL "SHOW SLAVE STATUS" /SHOW REPLICA STATUS. Это значение всегда отображается как "Нет" и не указывает на состояние репликации. Чтобы узнать правильное состояние репликации, обратитесь к метрикам репликации— состояние реплики ввода-вывода и состояние SQL-реплики в колонке "Мониторинг".
Остановить репликацию
Репликацию между исходным сервером и репликой можно остановить. После остановки репликации между исходным сервером и репликой чтения реплика становится отдельным сервером. На отдельном сервере сохраняются все данные, которые существовали на нем на момент запуска команды "Остановить репликацию". Данные на отдельном сервере не синхронизируются с исходным сервером.
Когда вы прекратите репликацию в определенную реплику, она утратит все ссылки на исходный сервер и другие реплики. Автоматическая отработка отказа между исходным сервером и его репликой не выполняется.
Внимание
Это сервер нельзя снова преобразовать в реплику. Прежде, чем останавливать репликацию в реплике чтения убедитесь, что реплика содержит все необходимые данные.
Процесс остановки репликации описан в этой статье.
Отработка отказа
Автоматическая отработка отказа между исходным сервером и серверами реплики не выполняется.
Реплики чтения предназначены для масштабирования интенсивных рабочих нагрузок чтения и не предназначены для обеспечения высокого уровня доступности сервера. Остановка репликации на реплике чтения для перевода ее в оперативный режим в режиме чтения и записи — это средства, с помощью которых выполняется переход на другой ресурс вручную.
Так как репликация является асинхронной, между источником и репликой возникает задержка. На задержку сети может повлиять множество факторов, например размер рабочей нагрузки, выполняемой на исходном сервере, и задержка между центрами обработки данных. В большинстве случаев задержка реплики составляет от нескольких секунд до пары минут. Отслеживать фактическую задержку репликации можно с помощью метрики Задержка реплики, доступной для каждой реплики. Эта метрика показывает время с момента последнего воспроизведения транзакций. Мы рекомендуем определять среднюю задержку, наблюдая за задержкой реплики в течение определенного времени. Вы можете настроить оповещение о задержке реплики, чтобы можно было принять меры, если задержка выйдет за пределы ожидаемого диапазона.
Совет
При отработке отказа на реплику задержка во время удаления реплики из источника указывает, сколько данных потеряно.
После того как вы решили выполнить отработку отказа в реплику, выполните следующие действия.
Остановите репликацию на реплику.
Этот шаг необходим для того, чтобы сервер реплики мог принимать операции записи. В рамках этого процесса сервер реплики будет удален из источника. После подачи команды к остановке репликации внутренний процесс обычно занимает около 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. Чтобы убедиться, что репликация согласована, 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. |