Реплики чтения в базе данных Azure для MySQL
ОБЛАСТЬ ПРИМЕНЕНИЯ:
База данных Azure для MySQL — отдельный сервер
Важно!
База данных Azure для MySQL один сервер находится на пути выхода на пенсию. Настоятельно рекомендуется выполнить обновление до База данных Azure для MySQL гибкого сервера. Дополнительные сведения о миграции на гибкий сервер База данных Azure для MySQL см. в статье "Что происходит с одним сервером База данных Azure для MySQL?"
Компонент "Реплика чтения" позволяет реплицировать данные с сервера службы "База данных Azure для MySQL" на сервер только для чтения. Вы можете реплицировать данные с исходного сервера на несколько реплик (до пяти). Реплики чтения асинхронно обновляются с помощью технологии репликации на основе позиции файла собственного двоичного журнала (binlog) ядра MySQL. Дополнительные сведения о репликации binlog MySQL см. в этой статье.
Реплики — это новые серверы, которыми вы управляете как обычными серверами службы "База данных Azure для MySQL". За каждую реплику чтения выставляется счет с учетом подготовленных вычислительных ресурсов (количество виртуальных ядер) и хранилища (ГБ/месяц).
Дополнительные сведения о функциях и проблемах репликации MySQL см. в документации по репликации MySQL.
Примечание.
Эта статья содержит упоминания термина slave (ведомый) . Корпорация Майкрософт больше не использует его. Когда этот термин будет удален из программного обеспечения, мы удалим его из статьи.
Использование реплик чтения
Компонент "Реплика чтения" помогает повысить производительность и масштабируемость рабочих нагрузок с высокой интенсивностью чтения. Рабочие нагрузки чтения можно изолировать в реплики, направив рабочие нагрузки записи на источник.
К типичным сценариям относится ситуация, когда рабочие нагрузки бизнес-аналитики и анализа используют реплику чтения в качестве источника данных для отчетов.
Так как реплики доступны только для чтения, они напрямую не снимают с источника нагрузку, связанную с записью Эта функция не нацелена на рабочие нагрузки с большим объемом операций записи.
В реплике чтения используется асинхронная репликация MySQL. Этот компонент также не предназначен для сценариев синхронной репликации. Между источником и репликой будет некоторая задержка. Данные на реплике и на источнике в итоге будут согласованы. Используйте этот компонент только для таких рабочих нагрузок, которым не страшна такая задержка.
Репликация между регионами
Регион размещения реплики чтения может отличаться от региона для исходного сервера. Репликация между регионами полезна для таких сценариев, как планирование аварийного восстановления или перенос данных ближе к пользователям.
Исходный сервер может размещаться в любом регионе Базы данных Azure для MySQL. Исходный сервер может иметь реплику в парном регионе или в универсальных регионах реплики. На изображении ниже представлена доступность регионов реплики в зависимости от региона исходного сервера.
Универсальные регионы реплики
Реплику чтения можно создать в любом из следующих регионов при любом расположении исходного сервера. Поддерживаются следующие универсальные регионы реплики:
| Регион | Доступность реплики |
|---|---|
| Восточная Австралия | ✔️ |
| Юго-восточная часть Австралии | ✔️ |
| Южная Бразилия | ✔️ |
| Центральная Канада | ✔️ |
| Восточная Канада | ✔️ |
| Центральная часть США | ✔️ |
| Восточная часть США | ✔️ |
| Восточная часть США 2 | ✔️ |
| Восточная Азия | ✔️ |
| Восточная Япония | ✔️ |
| Западная Япония | ✔️ |
| Республика Корея, центральный регион | ✔️ |
| Корея (юг) | ✔️ |
| Северная Европа | ✔️ |
| Центрально-северная часть США | ✔️ |
| Центрально-южная часть США | ✔️ |
| Юго-Восточная Азия | ✔️ |
| Северная Швейцария | ✔️ |
| Южная часть Соединенного Королевства | ✔️ |
| западная часть Соединенного Королевства | ✔️ |
| Центрально-западная часть США | ✔️ |
| Западная часть США | ✔️ |
| Западная часть США 2 | ✔️ |
| Западная Европа | ✔️ |
| Центральная Индия* | ✔️ |
| Центральная Франция* | ✔️ |
| Северная часть ОАЭ* | ✔️ |
| Северная часть ЮАР* | ✔️ |
Примечание.
*Регионы, в которых База данных Azure для MySQL имеет хранилище общего назначения версии 2 в общедоступной предварительной версии
* В случае этих регионов Azure можно будет создать сервер в хранилище общего назначения как версии 1, так и версии 2. Для серверов, созданных с использованием общедоступной предварительной версии хранилища общего назначения версии 2, вы можете создавать сервер реплики только в регионах Azure, которые поддерживают хранилище общего назначения версии 2.
Пары регионов
В дополнение к универсальным регионам реплики поддерживается создание реплики чтения в парном регионе Azure для региона исходного сервера. Если вы не знаете, какой регион является парным, изучите эту статью.
Если вы настраиваете репликацию между регионами в рамках планирования аварийного восстановления, мы рекомендуем создавать реплику именно в парном регионе, а не в одном из других. Для парных регионов не допускаются одновременные обновления, отслеживаются приоритеты по физической изоляции и месту расположения данных.
Но есть и некоторые ограничения:
Доступность по регионам. База данных Azure для MySQL доступна в следующих регионах: "Центральная Франция", "Северная часть ОАЭ", "Центральная Германия". Но недоступны регионы, которые являются для них парными.
Однонаправленные пары: некоторые регионы Azure объединяются только в одном направлении. К ним относятся: "Западная Индия", "Южная Бразилия" и US Gov (Вирджиния). Это означает, что для размещенного в Западной Индии исходного сервера можно создать реплику в Южной Индии, но для размещенного в Южной Индии исходного сервера невозможно создать реплику в Западной Индии. Это связано с тем, что для региона "Западная Индия" дополнительным регионом является "Южная Индия", но для региона "Южная Индия" дополнительный регион отличается от региона "Западная Индия".
Создание реплики
Важно!
- Функция создания реплики чтения доступна только для серверов базы данных Azure для MySQL в ценовой категории "Общее назначение" или "Оптимизированная для операций в памяти". Убедитесь, что исходный сервер находится в одной из этих ценовых категорий.
- Если для исходного сервера нет серверов реплики, для подготовки к репликации может потребоваться перезагрузка исходного сервера в зависимости от используемого хранилища (v1/v2). Перезапускать сервер и выполнять эту операцию рекомендуется в часы наименьшей нагрузки. Дополнительные сведения см. в разделе Перезапуск исходного сервера.
При запуске рабочего процесса создания реплики создается пустой сервер службы "База данных Azure для MySQL". Новый сервер заполняется данными, которые были на исходном сервере. Время создания зависит от объема данных на исходном сервере и времени, прошедшего с момента последнего еженедельного полного резервного копирования. Время может варьироваться от нескольких минут до нескольких часов. Сервер реплики всегда создается в той же группе ресурсов и в той же подписке, что и исходный сервер. Если вы хотите создать сервер реплики для другой группы ресурсов или другой подписки, можно переместить сервер реплики после создания.
Для каждой реплики включается автоматическое увеличение хранилища. Возможность автоматического увеличения позволяет реплике без сбоев обрабатывать реплицируемые данные и не прерывать репликацию даже в тех случаях, когда не хватает объема хранилища.
Дополнительные сведения о создании реплики чтения на портале Azure см. здесь.
Подключение к реплике
При создании реплика наследует правила брандмауэра от исходного сервера. Но с этого момента правила считаются независимыми от исходного сервера.
Реплика наследует от исходного сервера учетную запись администратора. Также на реплики чтения копируются все учетные записи пользователей с исходного сервера. К реплике чтения можно подключиться только с помощью учетных записей пользователей, доступных на исходном сервере.
Вы можете подключиться к реплике, используя имя узла и действительную учетную запись, как к обычному серверу службы "База данных Azure для MySQL". Например, для сервера с именем myreplica и именем пользователя с правами администратора myadmin подключение будет выполняться с помощью CLI mysql:
mysql -h myreplica.mysql.database.azure.com -u myadmin@myreplica -p
При появлении запроса введите пароль для учетной записи пользователя.
Мониторинг репликации
Служба "База данных Azure для MySQL" также предоставляет для Azure Monitor метрику Replication lag in seconds (Задержка репликации в секундах). Эта метрика доступна только для реплик. Эта метрика вычисляется на основе метрики seconds_behind_master, которую можно получить с помощью команды MySQL SHOW SLAVE STATUS. Настройте отправку предупреждений о достижении недопустимого для вашей рабочей нагрузки значения задержки репликации.
Если вы заметили увеличенную задержку репликации, см. статью Устранение неполадок репликации для устранения неполадок и выявления возможных причин.
Остановить репликацию
Репликацию между исходным сервером и репликой можно остановить. После остановки репликации между исходным сервером и репликой чтения реплика становится отдельным сервером. На отдельном сервере сохраняются все данные, которые существовали на нем на момент запуска команды "Остановить репликацию". Данные на отдельном сервере не синхронизируются с исходным сервером.
Когда вы прекратите репликацию в определенную реплику, она утратит все ссылки на исходный сервер и другие реплики. Автоматическая отработка отказа между исходным сервером и его репликой не выполняется.
Важно!
Это сервер нельзя снова преобразовать в реплику. Прежде, чем останавливать репликацию в реплике чтения убедитесь, что реплика содержит все необходимые данные.
Процесс остановки репликации описан в этой статье.
Отработка отказа
Автоматическая отработка отказа между исходным сервером и серверами реплики не выполняется.
Так как репликация является асинхронной, между источником и репликой возникает задержка. На задержку сети может повлиять множество факторов, например размер рабочей нагрузки, выполняемой на исходном сервере, и задержка между центрами обработки данных. В большинстве случаев задержка реплики составляет от нескольких секунд до пары минут. Отслеживать фактическую задержку репликации можно с помощью метрики Задержка реплики, доступной для каждой реплики. Эта метрика показывает время с момента последнего воспроизведения транзакций. Мы рекомендуем определять среднюю задержку, наблюдая за задержкой реплики в течение определенного времени. Вы можете настроить оповещение о задержке реплики, чтобы можно было принять меры, если задержка выйдет за пределы ожидаемого диапазона.
Совет
Если выполняется отработка отказа в реплике, задержка во время отсоединения реплики от источника будет указывать на количество потерянных данных.
После того как вы решили выполнить отработку отказа в реплике:
Остановите репликацию на реплику.
Этот шаг необходим для того, чтобы сервер реплики мог принимать операции записи. В рамках этого процесса сервер реплики будет отсоединен от источника. После подачи команды к остановке репликации внутренний процесс обычно занимает около 2 минут. Сведения о влиянии этого действия см. в разделе Остановка репликации этой статьи.Направьте приложение на реплику (бывшую).
У каждого сервера уникальная строка подключения. Обновите приложение так, чтобы оно указывало на реплику (бывшую), а не на источник.
Если ваше приложение успешно обрабатывает операции чтения и записи, значит, отработка отказа выполнена. Время простоя вашего приложения зависит от того, когда обнаружится ошибка и будут выполнены шаги 1 и 2, описанные выше.
Глобальный идентификатор транзакции (GTID)
Глобальный идентификатор транзакции (GTID) — это уникальный идентификатор, создаваемый для каждой зафиксированной транзакции на исходном сервере. Эта функция отключена по умолчанию в Базе данных Azure для MySQL. GTID поддерживается в версиях 5.7 и 8.0 и только на серверах, поддерживающих хранилище объемом до 16 ТБ (хранилище данных общего назначения версии 2). Дополнительные сведения о GTID и его использовании при репликации приведены в документации MySQL по репликации с помощью GTID.
MySQL поддерживает два типа транзакций: транзакции GTID (идентифицируемые по GTID) и анонимные транзакции (которым не присвоен 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, но будет отображаться предупреждение. |
Примечание.
После включения GTID эту функцию невозможно отключить. Если вам нужно отключить GTID, обратитесь в службу поддержки.
Режимы GTID можно менять только пошагово в порядке их возрастания. Например, если gtid_mode в текущий момент имеет значение OFF_PERMISSIVE, его можно изменить на ON_PERMISSIVE, но не на ON.
Чтобы обеспечить согласованность репликации, этот параметр невозможно изменить для главного сервера или сервера-реплики.
Прежде чем задавать gtid_mode=ON, рекомендуется установить для enforce_gtid_consistency значение ON.
Чтобы включить GTID и настроить режим согласованности, обновите параметры сервера gtid_mode и enforce_gtid_consistency с помощью портала Azure, Azure CLI или PowerShell.
Если GTID включен на исходном сервере (gtid_mode = ON), для только что созданных реплик также будет включена функция GTID и будет применяться репликация GTID. Чтобы обеспечить согласованность репликации, параметр gtid_mode невозможно изменить после создания главного сервера или сервера-реплики с включенной функцией GTID.
Рекомендации и ограничения
Ценовые категории
Реплики чтения сейчас доступны только в ценовых категориях "Общее назначение" и "Оптимизировано для памяти".
Примечание.
Стоимость работы сервера реплики зависит от региона, в котором он работает.
Перезапуск исходного сервера
На сервере с хранилищем общего назначения версии 1 параметр log_bin будет отключен по умолчанию. Значение будет включено при создании первой реплики чтения. Если для исходного сервера нет существующих реплик чтения, то он сначала перезапустится, чтобы подготовиться к репликации. Перезапускать сервер и выполнять эту операцию рекомендуется в часы наименьшей нагрузки.
Для исходного сервера с хранилищем общего назначения версии 2 параметр log_bin будет включен по умолчанию, поэтому не требуется перезагрузка при добавлении реплики чтения.
Новые реплики
Реплики чтения создаются как новые серверы службы "База данных Azure для MySQL". Существующий сервер нельзя снова преобразовать в реплику. Невозможно создать реплику другой реплики чтения.
Конфигурация реплики
Реплика создается с той же конфигурацией сервера, что и у исходного сервера. После создания реплики вы можете независимо от исходного сервера изменять следующие ее параметры: поколение вычислительных ресурсов, число виртуальных ядер, объем хранилища и период хранения резервных копий. Изменить также можно ценовую категорию (за исключением уровня "Базовый").
Важно!
Прежде чем изменить параметры конфигурации на исходном сервере, установите на каждой реплике такие же или более высокие значения. Это позволит реплике справляться с нагрузкой, соответствующей новым параметрам исходного сервера.
Правила брандмауэра и параметры конфигурации реплика наследует от исходного сервера при создании реплики. После этого правила реплики будут независимыми.
Остановленные реплики
Если вы прекратите репликацию между исходным сервером и репликой чтения, остановленная реплика станет отдельным сервером и начнет выполнять операции чтения и записи. Это сервер нельзя снова преобразовать в реплику.
Удаленные исходный и отдельный серверы
При удалении исходного сервера репликация останавливается для всех реплик чтения. Реплики чтения автоматически становятся автономными серверами и могут выполнять операции чтения и записи. Удаляется сам исходный сервер.
Учетные записи пользователей
Пользователи на исходном сервере реплицируются в реплики чтения. К реплике чтения можно подключиться только с помощью учетных записей пользователей, доступных на исходном сервере.
Параметры сервера
Чтобы предотвратить синхронизацию данных и избежать их возможной потери, при использовании реплики чтения некоторые параметры сервера блокируются.
На исходном сервере и сервере реплики блокируются следующие параметры сервера:
Параметр event_scheduler заблокирован на серверах реплик.
Чтобы обновить один из заблокированных параметров на исходном сервере, удалите серверы реплики, обновите значение параметра на исходном сервере и повторно создайте реплики.
GTID
GTID поддерживается в:
- MySQL версий 5.7 и 8.0.
- Серверах, поддерживающих хранилище объемом до 16 ТБ. Полный список регионов, поддерживающих хранилище объемом в 16 ТБ, приведен в статье о ценовых категориях.
По умолчанию функция GTID отключена. После включения GTID эту функцию невозможно отключить. Если вам нужно отключить GTID, обратитесь в службу поддержки.
Если GTID включен на исходном сервере, для только что созданных реплик также будет включена функция GTID и будет применяться репликация GTID. В целях обеспечения синхронизации репликации невозможно обновить gtid_mode на исходном или серверах реплики.
Другие
- Создание реплики для реплики не поддерживается.
- Таблицы в памяти могут привести к тому, что реплика перестают синхронизироваться. Это ограничение технологии реплика tion MySQL. Дополнительные сведения см. в справочной документации по MySQL.
- Убедитесь, что у таблиц исходного сервера есть первичные ключи. Отсутствие первичных ключей может привести к задержке репликации между исходным сервером и репликами.
- Полный список ограничений репликации MySQL см. в документации по MySQL.