Compartilhar via

Manutenção agendada no Banco de Dados do Azure para MySQL – Servidor Flexível

  • Artigo

APLICA-SE A: Banco de Dados do Azure para MySQL – Servidor flexível

O Servidor Flexível do Banco de Dados do Azure para MySQL executa manutenção periódica para 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, inicialização/parada do servidor) durante a manutenção do Banco de Dados do Azure para MySQL Flexible Server. O envolvimento nessas atividades pode levar a resultados imprevisíveis, possivelmente afetando o desempenho e a estabilidade do servidor. Aguarde até que a manutenção seja concluída antes de realizar operações de servidor.

Ciclo de Manutenção

Manutenção de Rotina

Nosso ciclo de manutenção padrão é programado com uma frequência não inferior a 30 dias. Esse período nos permite garantir a estabilidade e o desempenho do sistema, minimizando a interrupção dos seus serviços.

Manutenção Crítica

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

Localizar os detalhes de manutenção

Para obter detalhes específicos sobre o que cada atualização de manutenção envolve, consulte nossas notas de versão. Essas notas fornecem informações abrangentes sobre as atualizações aplicadas durante a manutenção, permitindo que você entenda e se prepare para quaisquer alterações que afetem seu ambiente.

Observação

Nem todos os servidores necessariamente passarão 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, adaptada às necessidades exclusivas de cada ambiente de servidor e minimize o tempo de inatividade da produção.

Selecionar uma janela 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 alertará você sete dias antes de executar qualquer manutenção. O sistema também avisará quando a manutenção for iniciada e quando for 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
  • Enviadas em um SMS (mensagem de texto) para dispositivos móveis
  • Envio 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, o sistema escolherá os 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 houver uma manutenção agendada para seu Servidor flexível e você atualizar as preferências de agendamento, a distribuição atual continuará conforme agendado e a alteração das configurações de agendamento entrará em vigor após sua conclusão bem-sucedida na próxima manutenção agendada.

Você pode definir agendamento gerenciado pelo sistema ou agendamento personalizado para cada Servidor Flexível em sua assinatura do Azure.

  • Com o agendamento personalizado, você pode especificar a janela de manutenção para o servidor escolhendo o dia da semana e uma janela de uma hora.
  • Com o agendamento gerenciado pelo sistema, o sistema escolherá 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 oferecerá mais suporte a janelas de manutenção personalizadas para instâncias de SKU com capacidade de intermitência. Essa alteração ocorre devido à necessidade de simplificar os processos de manutenção, garantir o desempenho ideal e nossa análise indicando que o número de usuários que utilizam janelas de manutenção personalizada em SKUs com capacidade de intermitência é mínimo. As instâncias de SKU com capacidade de intermitência existentes com configurações personalizadas da janela de manutenção permanecerão inalteradas; no entanto, os usuários não poderão modificar essas configurações personalizadas da janela de manutenção no futuro.

Para clientes que exigem janelas de manutenção personalizadas, recomendamos atualizar para Uso Geral ou SKUs Comercialmente Críticos para continuar usando este recurso.

Em casos raros, o evento de manutenção pode ser cancelado pelo sistema ou pode não ser concluído com êxito. Se a atualização falhar, ela será revertida e a versão anterior dos binários será restaurada. Em tais cenários de atualização com falha, você ainda poderá experimentar a reinicialização do servidor durante a janela de manutenção. Se a atualização for cancelada ou falhar, o sistema criará e enviará uma notificação para você sobre o evento de manutenção cancelado ou com falha. A próxima tentativa de executar a manutenção será agendada de acordo com as configurações de agendamento atuais e você receberá uma notificação sobre isso com cinco dias de antecedência.

Manutenção com quase zero tempo de inatividade (versão prévia pública)

O recurso "Manutenção com quase zero tempo de inatividade" do Servidor Flexível do Banco de Dados do Azure para MySQL é um desenvolvimento inovador para servidores habilitados para alta disponibilidade (HA). Este recurso foi projetado para reduzir substancialmente o tempo de inatividade da manutenção, garantindo que, na maioria dos casos, o tempo de inatividade da manutenção fique entre 40 e 60 segundos. 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 vida útil (TTL) 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 estar no intervalo de 40 a 60 segundos.

Limitações e pré-requisitos

Para obter o desempenho ideal prometido por esse recurso, determinadas condições e limitações devem ser observadas:

  • 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, afetando o tempo de inatividade.
  • Carga de trabalho baixa durante os horários de manutenção: os períodos de manutenção devem coincidir com os horários de baixa carga de trabalho no servidor para minimizar o tempo de inatividade. Recomendamos que você use o recurso de 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 devido a manutenções o mais baixo possível, não garantimos que ele sempre será menor que 60 segundos em todas as circunstâncias. Vários fatores, como alta carga de trabalho ou configurações de servidor específicas, podem levar a um tempo de inatividade mais longo. 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 concede maior controle sobre o tempo de atividades de manutenção em sua instância de 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, independentemente de ser um reagendamento gerenciado pelo sistema ou personalizado.

Parâmetros e notificações do reagendamento

O reagendamento não está restrito a intervalos de tempo fixos. Ele depende dos tempos mais antigos e mais recentes permitidos no ciclo de manutenção atual, o que normalmente vai do primeiro ao último dia da janela de manutenção da região. Após o reagendamento, uma notificação será enviada para confirmar as alterações, seguindo as políticas de notificação padrão.

Considerações e limitações

Ao usar esse recurso, lembre-se do seguinte:

  • Restrições de demanda: Sua manutenção reagendada pode ser cancelada devido a um alto número de atividades de manutenção ocorrendo simultaneamente na mesma região.
  • Período de bloqueio: O reagendamento não estará 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 período, as solicitações de reagendamento poderão falhar. Os usuários receberão uma notificação de erro se isso ocorrer e serão aconselhados a escolher outro horário. É improvável que a manutenção reprogramada com sucesso seja cancelada.

Não há nenhuma limitação em quantas vezes uma manutenção pode ser reagendada; desde que a manutenção não tenha entrado no estado "Em preparação", você sempre poderá reagendar sua manutenção para outra hora.

Observação

Recomendamos monitorar as notificações de perto durante a fase de visualização para acomodar possíveis ajustes.

Use esse recurso para evitar interrupções durante operações críticas de banco de dados. Incentivamos seus comentários enquanto continuamos a desenvolver essa funcionalidade.

Perguntas frequentes

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

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

Q: Por que alguns servidores na mesma região receberam notificações de manutenção e outros não?

A: Isso pode ocorrer porque os servidores que não receberam notificações foram criados mais recentemente e o sistema determinou que ainda não necessitam de manutenção.

Q: Posso cancelar a manutenção programada?

A: Não, não é permitido cancelar a manutenção programada. No entanto, você pode usar o recurso de reprogramação de manutenção para ajustar o tempo ou habilitar o recurso Alta Disponibilidade (HA) para minimizar o tempo de inatividade. Como um produto de banco de dados PaaS, é essencial realizar manutenção oportuna para garantir a segurança e a confiabilidade do seu banco de dados.

Próximas etapas