Заметка
Доступ к этой странице требует авторизации. Вы можете попробовать войти в систему или изменить каталог.
Доступ к этой странице требует авторизации. Вы можете попробовать сменить директорию.
Высокий уровень доступности — это ключевая функция Базы данных Azure для MySQL, предназначенная для минимизации простоя и обеспечения доступности приложений даже во время планового обслуживания или непредвиденных сбоев. В этой статье рассматриваются распространенные вопросы о вариантах высокого уровня доступности, выставлении счетов, процессах отработки отказа, влиянии на производительность и рекомендации по принятию обоснованных решений для рабочих нагрузок MySQL в Azure.
Какие соглашения об уровне обслуживания существуют для локально-избыточных и зонально-избыточных гибких серверов с поддержкой высокой доступности?
Сведения об уровне обслуживания для гибкого сервера Базы данных Azure для MySQL можно найти в SLA для Базы данных Azure для MySQL.
Как выставляются счета за высокодоступные серверы (HA)?
Серверы, включенные с высокой доступности, имеют первичную и вторичную реплику. Вторичная реплика может находиться в одной зоне или избыточной зоне. Плата взимается за подготовленные вычислительные ресурсы и хранилище как для первичной, так и для вторичной реплики. Например, если у вас есть основной ресурс с 4 виртуальными ядрами вычислительных ресурсов и 512 ГБ подготовленного хранилища, вторичная реплика имеет 4 виртуальных ядер и 512 ГБ подготовленного хранилища.
Сервер высокой доступности, избыточный между зонами, взимается плата за 8 виртуальных ядер и 1024 ГБ хранилища. В зависимости от тома хранилища резервных копий также может взиматься плата за хранилище резервных копий.
Можно ли использовать резервную реплику для операций чтения или записи?
Резервный сервер недоступен для операций чтения и записи. Это пассивный резервный режим для быстрого отработки отказа.
Будет ли у меня потеря данных при отработки отказа?
К журналам в хранилище, избыточном между зонами, открывается доступ, когда основной сервер недоступен. Эта доступность помогает гарантировать отсутствие потери данных. После активации резервной реплики и применения двоичных журналов она принимает роль первичного сервера.
Нужно ли предпринять какие-либо действия после отработки отказа?
Отработка отказа полностью прозрачна из клиентского приложения. Вам не нужно предпринимать никаких действий. Приложения должны использовать логику повторных попыток для своих подключений.
Что происходит, если не выбрать определенную зону для резервной реплики? Можно ли изменить зону позже?
Если вы не выбираете зону, она выбирается случайным образом. Он используется для основного сервера. Чтобы изменить зону позже, можно задать для высокой доступности значение "Отключено " на панели "Высокий уровень доступности ", а затем вернуть его в " Избыточность зоны" и выбрать зону.
Синхронная репликация между основными и резервными репликами?
Репликация между основным и резервным режимом аналогична полусинхронному режиму в MySQL. Если транзакция зафиксирована, она не обязательно фиксируется в резервном режиме. Но если основной объект недоступен, резервная служба реплицирует все изменения данных из первичной, чтобы убедиться, что потери данных отсутствуют.
Существует ли отработка отказа на резервную реплику для всех незапланированных сбоев?
При сбое базы данных или сбое узла виртуальная машина гибкого сервера перезапускается на том же узле. В то же время активируется автоматическая отработка отказа. Если перезагрузка виртуальной машины гибкого сервера выполнена успешно до завершения отработки отказа, операция отработки отказа отменяется. Определение сервера, используемого в качестве основной реплики, зависит от процесса, завершающегося первым.
Влияет ли производительность при использовании высокой доступности?
Для высокой доступности, избыточной между зонами, в то время как не оказывает большого влияния на производительность рабочих нагрузок чтения в зонах доступности, может потребоваться до 40 процентов задержки запросов на запись. Увеличение задержки записи происходит из-за синхронной репликации в пределах зоны доступности. Влияние задержки записи в два раза превышает избыточность между зонами по сравнению с той же зоной высокой доступности. Для локально избыточной системы высокой доступности, так как основная и резервная реплики находятся в той же зоне, задержка репликации и, следовательно, задержка синхронной записи ниже.
В итоге, если задержка записи для вас важнее, чем доступность, вы можете выбрать локально-избыточную HA. Но если доступность и устойчивость ваших данных важнее за счет снижения задержки записи, необходимо выбрать зонально-избыточную HA. Чтобы оценить точное влияние снижения задержки в настройке высокого уровня доступности, рекомендуется выполнить тестирование производительности для рабочей нагрузки, чтобы принять обоснованное решение.
Как выполняется обслуживание сервера высокого уровня доступности?
Запланированные события, такие как масштабирование вычислений и дополнительных обновлений версий, происходят в исходном резервном экземпляре, а затем активируют плановую операцию отработки отказа, а затем работают с исходным первичным экземпляром. Вы можете задать запланированное время обслуживания для серверов высокого уровня доступности, как и для гибких серверов. Время простоя совпадает с временем простоя для экземпляра гибкого сервера Базы данных Azure для MySQL при отключении высокой доступности.
Можно ли выполнить восстановление на определенный момент времени (PITR) сервера высокой доступности?
Вы можете сделать PITR для экземпляра гибкого сервера с поддержкой высокой доступности Базы данных Azure для MySQL в новом экземпляре Гибкого сервера Базы данных Azure для MySQL, который отключен высокой доступности. Если исходный сервер был создан с зонально-избыточной системой высокой доступности, можно включить зонально-избыточную или локально-избыточную высокую доступность на восстановленном сервере позже. Если исходный сервер был создан с локальной избыточной высокой доступностью, можно включить только локальную избыточную высокую доступность на восстановленном сервере.
Можно ли включить высокий уровень доступности на сервере после создания сервера?
Во время создания сервера необходимо включить избыточное между зонами высокий уровень доступности. После создания сервера можно включить локальную избыточность для высокой доступности (HA), но убедитесь, что параметры сервера enforce_gtid_consistency и gtid_mode установлены на ON, прежде чем продолжить.
Можно ли отключить высокий уровень доступности для сервера после его создания?
Вы можете отключить высокий уровень доступности на сервере после его создания. Выставление счетов останавливается немедленно.
Как устранить простои?
Вы должны быть в состоянии снизить время простоя приложения, даже если вы не используете высокий уровень доступности. Время простоя службы, например запланированных исправлений, дополнительных обновлений версий или операций, инициированных клиентом, например масштабирование вычислений, можно выполнять во время запланированных периодов обслуживания. Чтобы снизить влияние приложений на задачи обслуживания, инициированные Azure, вы можете запланировать их в день недели и времени, что сводит к минимуму влияние на приложение.
Можно ли использовать реплику чтения для сервера с поддержкой высокой доступности?
Да, реплики чтения поддерживаются для серверов высокой доступности.
Можно ли использовать репликацию данных для серверов высокой доступности?
Поддержка репликации данных для сервера с поддержкой высокой доступности (HA) доступна только через репликацию на основе GTID.
Хранимая процедура репликации с помощью GTID доступна на всех серверах с поддержкой высокого уровня доступности по имени mysql.az_replication_with_gtid.
Чтобы сократить время простоя, можно ли выполнить отработку отказа на резервный сервер во время перезапуска сервера или во время масштабирования вверх или вниз?
В настоящее время гибкий сервер Базы данных Azure для MySQL использовал плановую отработку отказа для оптимизации операций высокой доступности, включая увеличение или уменьшение масштаба и плановое обслуживание, чтобы сократить время простоя.
При запуске таких операций сначала он будет работать на исходном резервном экземпляре, а затем активировать плановую операцию отработки отказа, а затем работать с исходным первичным экземпляром.
Можно ли изменить режим доступности (зонально-избыточная высокая доступность / локально-избыточная) сервера**
Если вы создаете сервер с включенным режимом Zone-redundant HA, вы можете менять его с режима Zone-redundant на Local-redundant и обратно.
Чтобы изменить режим Высокой доступности, установите значение Отключено на панели Высокая доступность, а затем выберите Избыточность по зонам или Локальная избыточность и выберите Режим высокой доступности.