Manutenção agendada no Banco de Dados do Azure para MySQL - Servidor Flexível
O Banco de Dados do Azure para Servidor Flexível MySQL realiza manutenção periódica para manter seu banco de dados gerenciado seguro, estável e atualizado. Durante a manutenção, o servidor obtém novas funcionalidades, atualizações e patches.
Importante
Evite todas as operações do servidor (modificações, alterações de configuração, iniciar/parar o servidor) durante a manutenção do Servidor Flexível do Banco de Dados do Azure para MySQL. 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 as operações do 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 cada 30 dias. Este período permite-nos 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 implantar correções de segurança urgentes ou atualizações críticas para manter a disponibilidade e a integridade dos dados, a manutenção pode ser realizada com mais frequência. Estas exceções são feitas para salvaguardar os seus dados e garantir o funcionamento contínuo dos seus serviços.
Localizar detalhes de manutenção
Para obter detalhes específicos sobre o que cada atualização de manutenção implica, consulte nossas notas de versão. Estas notas fornecem informações abrangentes sobre as atualizações aplicadas durante a manutenção, permitindo que você compreenda e se prepare para quaisquer alterações que afetem seu ambiente.
Nota
Nem todos os servidores passarão necessariamente por manutenção durante as atualizações programadas, sejam elas de rotina ou críticas. A equipe do Azure MySQL emprega critérios específicos para determinar quais servidores precisam de 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 de sua produção.
Selecione uma janela de manutenção
Pode agendar a manutenção durante um dia específico da semana e uma janela de tempo nesse dia. Ou você pode deixar o sistema escolher um dia e um horário para você automaticamente. De qualquer forma, o sistema irá alertá-lo sete dias antes de executar qualquer manutenção. O sistema também informará quando a manutenção for iniciada e quando ela for concluída com sucesso.
As notificações sobre a próxima manutenção programada podem ser:
- Enviado por e-mail para um endereço específico
- Enviado por e-mail para uma função do Azure Resource Manager
- Enviado em uma mensagem de texto (SMS) para dispositivos móveis
- Push como uma notificação para uma aplicação do Azure
- Entrega como uma mensagem de voz
Ao especificar preferências para o agendamento de manutenção, pode escolher um dia da semana e uma janela de tempo. Se não especificar, o sistema escolherá os horários entre 23:00 e as 07:00 no horário da região do servidor. Você pode definir agendas 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 prosseguirá conforme programado e a alteração das configurações de agendamento entrará em vigor 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 o 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 a programação gerenciada 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 dará mais suporte a janelas de manutenção personalizadas para instâncias de SKU burstable. Essa mudança se deve à necessidade de simplificar os processos de manutenção, garantindo um desempenho ideal, e nossa análise indica que o número de usuários que utilizam janelas de manutenção personalizadas em SKUs burstable é mínimo. As instâncias de SKU burstable existentes com configurações de janela de manutenção personalizadas permanecerão inalteradas; no entanto, os usuários não poderão modificar essas configurações de janela de manutenção personalizada no futuro.
Para clientes que precisam de janelas de manutenção personalizadas, recomendamos atualizar para SKUs de uso geral ou críticos para os negócios para continuar usando esse 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, a atualização será revertida e a versão anterior dos binários será restaurada. Nesses cenários de falha de atualização, você ainda pode experimentar a reinicialização do servidor durante a janela de manutenção. Se a atualização for cancelada ou falhar, o sistema criará uma notificação sobre o evento de manutenção cancelado ou com falha, respectivamente, notificando-o. A próxima tentativa de realizar a manutenção será agendada de acordo com suas configurações de agendamento atuais e você receberá uma notificação sobre isso com 5 dias de antecedência.
Manutenção com tempo de inatividade quase nulo (visualização pública)
O recurso "Manutenção de tempo de inatividade quase zero" do Banco de Dados do Azure para MySQL Flexible Server é um desenvolvimento inovador para servidores habilitados para HA (Alta Disponibilidade). 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 seja esperado entre 40 e 60 segundos. Esse recurso é 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 inerente de tempo de vida útil (TTL) do DNS de aproximadamente 30 segundos. Esse período não é controlado diretamente pelo processo de manutenção, mas é uma parte padrão do comportamento do DNS. Assim, do ponto de vista do cliente, o tempo total de inatividade experimentado durante a manutenção pode estar na faixa de 40 a 60 segundos.
Limitações e pré-requisitos
Para alcançar o desempenho ideal prometido por este recurso, certas 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.
- Baixa carga de trabalho durante os tempos de manutenção: os períodos de manutenção devem coincidir com os períodos de baixa carga de trabalho no servidor para garantir que o tempo de inatividade permaneça mínimo. 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 de manutenção o mais baixo possível, não garantimos que será sempre inferior a 60 segundos em todas as circunstâncias. Vários fatores, como alta carga de trabalho ou configurações específicas do servidor, podem levar a um tempo de inatividade mais longo. No pior cenário, o tempo de inatividade pode ser semelhante ao de um servidor autônomo.
Reprogramação da manutenção
O recurso de reagendamento de manutenção concede maior controle sobre o tempo das atividades de manutenção em sua instância do Servidor Flexível do Banco de Dados do Azure para MySQL. Depois de receber uma notificação de manutenção, você pode reprogramá-la para um horário mais conveniente, independentemente de ter sido gerenciada pelo sistema ou personalizada.
Reagendar parâmetros e notificações
O reagendamento não se limita a horários fixos; Depende dos primeiros e últimos tempos permitidos no ciclo de manutenção atual, que normalmente se estende do primeiro ao último dia da janela de manutenção para a 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
Tenha em atenção o seguinte ao utilizar esta funcionalidade:
- Restrições de demanda: sua manutenção reprogramada pode ser cancelada devido a um grande número de atividades de manutenção que ocorrem 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 programado para manter a confiabilidade do serviço.
- Reagendar aceleração Se muitos servidores na mesma região estiverem agendados para manutenção durante o mesmo tempo, as solicitações de reagendamento poderão falhar. Os usuários receberão uma notificação de erro se isso ocorrer e são aconselhados a escolher um intervalo de tempo alternativo. É improvável que a manutenção reprogramada com êxito seja cancelada.
Não há limitação de quantas vezes uma manutenção pode ser reprogramada, desde que a manutenção não tenha entrado no estado "Em preparação", você sempre pode reprogramar sua manutenção para outro momento.
Nota
Recomendamos monitorar as notificações de perto durante o estágio de visualização para acomodar possíveis ajustes.
Use esse recurso para evitar interrupções durante operações críticas do banco de dados. Encorajamos os seus comentários à medida que continuamos a desenvolver esta funcionalidade.
FAQ
P: Porque é que alguns dos meus servidores receberam notificações de manutenção enquanto outros não?
R: Os tempos de início da manutenção diferem entre regiões, pelo que os servidores em regiões diferentes podem receber notificações de manutenção em momentos diferentes.
P: Por que alguns servidores na mesma região receberam notificações de manutenção enquanto outros não?
R: Isso pode ser porque os servidores que não receberam notificações foram criados mais recentemente, e o sistema determinou que eles ainda não precisam de manutenção.
P: Posso optar por não receber a manutenção programada?
R: Não, não é permitido optar por não participar na manutenção programada. No entanto, você pode usar o recurso de reprogramação de manutenção para ajustar o tempo ou habilitar o recurso de alta disponibilidade (HA) para minimizar o tempo de inatividade. Como um produto de banco de dados PaaS, é essencial realizar uma manutenção oportuna para garantir a segurança e a confiabilidade do seu banco de dados.