Compartilhar via


Manutenção agendada no Banco de Dados do Azure para MySQL

O Banco de Dados do Azure para MySQL executa manutenção periódica para ajudar a manter seu banco de dados gerenciado seguro, estável e atualizado. Durante as manutenções, o servidor obtém novos recursos, atualizações e patches.

Importante

Evite todas as operações do servidor (modificações, alterações de configuração, iniciando/parando) durante a manutenção do Banco de Dados do Azure para MySQL. O envolvimento nessas atividades pode levar a resultados imprevisíveis que podem afetar o desempenho e a estabilidade do servidor. Aguarde até que a manutenção seja concluída para realizar operações de servidor.

Ciclo de manutenção

As seções a seguir descrevem os tipos de manutenção. Para obter detalhes específicos sobre o que cada atualização de manutenção envolve, consulte as notas de versão. Essas anotações fornecem informações abrangentes sobre as atualizações aplicadas durante a manutenção, para que você possa entender e se preparar para quaisquer alterações que afetem seu ambiente.

Observação

Nem todos os servidores necessariamente passam por manutenção durante as atualizações agendadas, sejam elas rotineiras ou críticas. A equipe do MySQL do Azure emprega critérios específicos para determinar quais servidores exigem manutenção. Essa abordagem seletiva garante que a manutenção seja eficiente e essencial, seja adaptada às necessidades exclusivas de cada ambiente de servidor e minimize o tempo de inatividade de produção.

Manutenção de rotina

Nosso ciclo de manutenção padrão não é menos frequente do que a cada 30 dias. Esse período ajuda a garantir a estabilidade e o desempenho do sistema, minimizando a interrupção em seus serviços.

Manutenção crítica

Em determinados cenários, como a necessidade de implantar correções de segurança ou atualizações urgentes que são essenciais para manter a disponibilidade e a integridade dos dados, podemos realizar a manutenção com mais frequência. Essas exceções ajudam a proteger seus dados e garantir a operação contínua de seus serviços.

Manutenção de canário virtual

O Canário Virtual é um programa de manutenção experimental que oferece acesso antecipado às atualizações. Ele permite que os clientes testem a compatibilidade da carga de trabalho com novas versões do Banco de Dados do Azure para MySQL e forneçam comentários sobre novos recursos.

Ao contrário da manutenção de rotina, o Canário Virtual não segue o intervalo mínimo de 30 dias ou o período de notificação de 7 dias. Este programa ajuda os clientes a validar proativamente novos recursos e contribuir com comentários preliminares para aprimoramentos de produtos. Os servidores com capacidade de intermitência, normalmente usados nos ambientes de não produção, são registrados automaticamente no programa Canário Virtual.

Registro do Canário Virtual

O Banco de Dados do Azure para MySQL oferece flexibilidade para que os clientes gerenciem sua participação no programa Canário Virtual. Os clientes podem optar por entrar ou sair do programa conforme necessário para o alinhamento com seus requisitos operacionais.

Para verificar se o servidor está registrado no programa Canário Virtual, use o comando a seguir. Se o resultado incluir "patchStrategy": "VirtualCanary", o servidor será registrado no programa.

az mysql flexible-server show --resource-group {resourcegroupname} --name {servername} --query "maintenancePolicy"

Para registrar um servidor no programa Canário Virtual, execute o seguinte comando:

az mysql flexible-server update --resource-group {resourcegroupname} --name {servername} --maintenance-policy-patch-strategy VirtualCanary

Para deixar o programa Canário Virtual e reverter para a política de manutenção padrão, use este comando:

az mysql flexible-server update --resource-group {resourcegroupname} --name {servername} --maintenance-policy-patch-strategy Regular

Janelas de manutenção

Você pode agendar uma manutenção durante um dia específico da semana e um período dentro desse dia. Ou pode permitir que o sistema escolha um dia e um período para você automaticamente. De qualquer forma, o sistema alerta você sete dias antes de executar qualquer manutenção. O sistema também informa quando a manutenção é iniciada e quando é concluída com êxito.

As notificações sobre as próximas manutenções agendadas podem ser:

  • Enviadas por email para um endereço específico.
  • Enviadas por email para uma função do Azure Resource Manager.
  • Enviado em uma mensagem de texto (SMS) para dispositivos móveis.
  • Enviadas por push como notificação para um aplicativo do Azure.
  • Entregue como mensagem de voz.

Ao especificar preferências para o agendamento de manutenção, você pode escolher um dia da semana e uma janela de tempo. Se você não especificar preferências, o sistema escolherá horários entre 23h e 7h no horário da região do servidor. Você pode definir agendamentos diferentes para cada servidor flexível em sua assinatura do Azure.

Você pode atualizar as configurações de agendamento a qualquer momento. Se uma manutenção estiver programada para o seu servidor flexível e você atualizar as preferências de agendamento, a distribuição atual prosseguirá conforme o planejado. A alteração nas configurações de agendamento torna-se efetiva após sua conclusão bem-sucedida para a próxima manutenção agendada.

Você pode definir uma agenda gerenciada pelo sistema ou uma agenda personalizada para cada servidor flexível em sua assinatura do Azure:

  • Com um agendamento personalizado, você pode especificar sua janela de manutenção para o servidor escolhendo o dia da semana e uma janela de tempo de uma hora.
  • Com um agendamento gerenciado pelo sistema, o sistema escolhe qualquer janela de uma hora entre 23h e 7h no horário da região do servidor.

Importante

A partir de 31 de agosto de 2024, o Banco de Dados do Azure para MySQL não dá mais suporte a janelas de manutenção personalizadas para instâncias da camada Burstable. Essa alteração ajuda a simplificar os processos de manutenção e garantir o desempenho ideal. Além disso, nossa análise indicou que o número de usuários que usam janelas de manutenção personalizada em camadas Burstable é mínimo.

Instâncias existentes com capacidade de intermitência com janelas de manutenção personalizadas não são afetadas. No entanto, os usuários não podem mais modificar essas configurações para janelas de manutenção personalizadas.

Para clientes que precisam de janelas de manutenção personalizadas, é recomendável atualizar para a camada Uso Geral ou Comercialmente Crítico.

Em casos raros, um evento de manutenção pode ser cancelado pelo sistema ou pode não ser concluído com êxito. Se um evento de manutenção falhar, a atualização será revertida e a versão anterior dos binários será restaurada. Em cenários de atualizações com falha, você ainda pode experimentar uma reinicialização do servidor durante a janela de manutenção.

Se um evento de manutenção for cancelado ou falhar, o sistema enviará uma notificação. A próxima tentativa de executar a manutenção é agendada de acordo com suas configurações atuais. Você recebe uma notificação sobre a próxima tentativa com cinco dias de antecedência.

Manutenção de tempo de inatividade quase zero (versão prévia)

O recurso de manutenção de tempo de inatividade quase zero do Banco de Dados do Azure para MySQL é um desenvolvimento inovador para servidores de alta disponibilidade. Esse recurso foi projetado para reduzir significativamente o tempo de inatividade durante a manutenção. Essa funcionalidade é fundamental para empresas que exigem alta disponibilidade e interrupção mínima em suas operações de banco de dados.

Expectativas precisas de tempo de inatividade

  • Duração do tempo de inatividade: na maioria dos casos, o tempo de inatividade durante a manutenção varia de 10 a 30 segundos.
  • Considerações adicionais: após um evento de failover, há um período de TTL (vida útil) de DNS inerente de aproximadamente 30 segundos. Esse período não é controlado diretamente pelo processo de manutenção, mas é uma parte padrão do comportamento DNS. Portanto, do ponto de vista do cliente, o tempo de inatividade total experimentado durante a manutenção pode ser de 40 a 60 segundos.

Condições e limitações

Para obter o desempenho ideal oferecido por esse recurso, observe estas condições e limitações:

  • Chaves primárias em todas as tabelas: garantir que cada tabela tenha uma chave primária é fundamental. A falta de chaves primárias pode aumentar significativamente o atraso de replicação e afetar o tempo de inatividade.
  • Carga de trabalho baixa durante os tempos de manutenção: os períodos de manutenção devem coincidir com os tempos de baixa carga de trabalho no servidor para minimizar o tempo de inatividade. Recomendamos que você use a janela de manutenção personalizada para agendar a manutenção fora do horário de pico.
  • Garantias de tempo de inatividade: Embora nos esforcemos para manter o tempo de inatividade de manutenção o mais baixo possível, não garantimos que será menos de 60 segundos em todas as circunstâncias. Vários fatores, como alta carga de trabalho ou configurações de servidor específicas, podem aumentar o tempo de inatividade. Na pior das hipóteses, o tempo de inatividade pode ser semelhante ao de um servidor autônomo.

Reagendamento de manutenção

O recurso de reagendamento de manutenção oferece maior controle sobre o tempo de atividades de manutenção no servidor flexível do Banco de Dados do Azure para MySQL. Depois de receber uma notificação de manutenção, você pode reagendá-la para um momento mais conveniente, seja ela gerenciada pelo sistema ou personalizada.

Use esse recurso para evitar interrupções durante operações críticas de banco de dados. Incentivamos que você nos envie os seus comentários à medida que continuamos a desenvolver essa funcionalidade.

Reagendando parâmetros e notificações

O reagendamento não se limita a intervalos de tempo fixos. Depende dos tempos permitidos mais antigos e mais recentes no ciclo de manutenção atual. O ciclo normalmente se estende do primeiro dia até o último dia da janela de manutenção da região. Ao reagendar, você recebe uma notificação para confirmar as alterações, de acordo com as políticas de notificação padrão.

Considerações e limitações

Lembre-se dos seguintes pontos sobre o recurso:

  • Disponibilidade da camada: o reagendamento de manutenção não está disponível para a camada de computação intermitível. Esse recurso destina-se a servidores no ambiente de produção, enquanto a camada Burstable foi projetada para fins de não produção.
  • Restrições de demanda: sua manutenção reagendada poderá ser cancelada se um alto número de atividades de manutenção ocorrer simultaneamente na mesma região.
  • Período de bloqueio: o reagendamento não está disponível 15 minutos antes do tempo de manutenção inicialmente agendado, para manter a confiabilidade do serviço.
  • Limitação de reagendamento: se muitos servidores na mesma região estiverem agendados para manutenção durante o mesmo tempo, as solicitações de reagendamento poderão falhar. Se essa falha ocorrer, você receberá uma notificação de erro que aconselha você a escolher um intervalo de tempo alternativo. É improvável que a manutenção reagendada com sucesso seja cancelada.

Não há nenhuma limitação em quantas vezes um evento de manutenção pode ser reagendado. Desde que um evento de manutenção não tenha entrado no estado em preparação , você sempre poderá reagendá-lo para outra hora.

Observação

Recomendamos que você monitore as notificações de perto durante o estágio de visualização para acomodar possíveis ajustes.

Perguntas frequentes

Por que alguns dos meus servidores receberam notificações de manutenção enquanto outros não receberam?

Os horários de início da manutenção diferem entre regiões. Servidores em regiões diferentes podem receber notificações de manutenção em horários diferentes.

Por que alguns servidores da mesma região receberam notificações de manutenção enquanto outros não receberam?

É possível que os servidores que não receberam notificações tenham sido criados mais recentemente e o sistema determinou que eles ainda não precisam de manutenção.

Posso recusar a manutenção agendada?

Não, não é permitido recusar a manutenção agendada. No entanto, você pode usar o recurso de reagendamento de manutenção para ajustar o tempo. Ou você pode habilitar o recurso de alta disponibilidade para minimizar o tempo de inatividade. Como o Banco de Dados do Azure para MySQL é um produto de banco de dados paaS (plataforma como serviço), a execução de manutenção oportuna ajuda a garantir a segurança e a confiabilidade do banco de dados.