Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
O Banco de Dados do Azure para MySQL servidor flexível permite recursos de continuidade de negócios que protegem seus bancos de dados no caso de uma interrupção planejada e não planejada. Recursos como backups automatizados e alta disponibilidade resolvem diferentes níveis de proteção contra falhas com diferentes de tempo de recuperação e exposição a perda de dados. Ao arquitetar seu aplicativo para proteger contra falhas, deverá considerar o RTO (objetivo de tempo de recuperação) e o RPO (objetivo de ponto de recuperação) para cada aplicativo. O RTO é a tolerância a tempo de inatividade e o RPO é a tolerância à perda de dados após uma interrupção no serviço de banco de dados.
A tabela a seguir ilustra os recursos oferecidos pelo Banco de Dados do Azure para MySQL - Servidor Flexível.
| Recurso | Descrição | Restrições |
|---|---|---|
| Backup & Recuperação | O serviço executa automaticamente backups diários de seus arquivos de banco de dados e faz backup contínuo dos logs de transações. Os backups podem ser retidos por qualquer período entre 1 e 35 dias. Você pode restaurar o servidor de banco de dados para qualquer ponto no tempo dentro do período de retenção do backup. O tempo de recuperação depende do tamanho dos dados a serem restaurados, além do tempo necessário para realizar a recuperação dos logs. Consulte Backup e recuperação no Banco de Dados do Azure para MySQL - Servidor Flexível para ver mais detalhes. | Os dados de backup permanecem dentro da região |
| Backup redundante local | Os backups de serviço são armazenados de modo automático e seguro em um armazenamento com redundância local em uma região e na mesma zona de disponibilidade. Os backups com redundância local replicam os arquivos de dados de backup do servidor três vezes em um único local físico na região primária. O armazenamento de backup localmente redundante fornece pelo menos 99,999999999% (11 noves) de durabilidade dos objetos em um determinado ano. Consulte Backup e recuperação no Banco de Dados do Azure para MySQL - Servidor Flexível para ver mais detalhes. | Aplicável em todas as regiões |
| Backup georredundante | Os backups de serviço podem ser configurados com redundância geográfica no momento da criação. A habilitação da redundância geográfica replica os arquivos de dados de backup do servidor na região primária emparelhada para fornecer resiliência regional. O armazenamento de backup com redundância geográfica fornece pelo menos 99,99999999999999% (16 noves) de durabilidade dos objetos em um determinado ano. Consulte Backup e recuperação no Banco de Dados do Azure para MySQL - Servidor Flexível para ver mais detalhes. | Disponível em todas as regiões emparelhadas do Azure |
| Alta disponibilidade redundante de zona | O serviço pode ser implantado no modo de alta disponibilidade, que implanta servidores primários e em espera em duas zonas de disponibilidade diferentes em uma região. A alta disponibilidade redundante por zona protege contra falhas em nível de zona e também ajuda a reduzir o tempo de inatividade do aplicativo durante eventos de inatividade planejados e não planejados. Os dados do servidor primário são replicados de maneira síncrona para a réplica em espera. Durante qualquer evento de tempo de inatividade, o servidor de banco de dados faz failover automaticamente para a réplica em espera. Consulte Conceitos – alta disponibilidade para obter mais detalhes. | Compatível com camadas de computação de uso geral e otimizadas para memória. Disponível apenas em regiões em que há várias zonas disponíveis. |
| Compartilhamento de arquivos premium | Os arquivos de bancos de dados são armazenados em compartilhamentos de arquivos do Azure Premium altamente duráveis e confiáveis, que fornecem redundância de dados com três cópias de réplica, armazenadas em uma zona de disponibilidade com recursos de recuperação automática de dados. Consulte Compartilhamentos de arquivos Premium para obter mais detalhes. | Dados armazenados em uma zona de disponibilidade |
Mitigação de tempo de inatividade planejada
Aqui estão alguns cenários de manutenção planejada que incorrem em tempo de inatividade:
| Cenário | Processo |
|---|---|
| Escalabilidade computacional (Usuário) | Quando é executada a operação de dimensionamento de computação, um novo servidor flexível é provisionado usando a configuração de computação dimensionada. No servidor de banco de dados existente, os pontos de verificação ativos têm permissão para serem concluídos, as conexões de cliente são descarregadas, todas as transações não confirmadas são canceladas e o servidor é desligado. O armazenamento é então conectado ao novo servidor e o banco de dados é iniciado, realizando a recuperação, se necessário, antes de aceitar conexões de clientes. |
| Nova implantação de software (Azure) | Novos recursos de distribuição ou correções de bugs ocorrem automaticamente como parte da manutenção planejada do serviço, e é possível agendar quando essas atividades devem ocorrer. Para saber mais, consulte a documentação e também verifique o portal |
| Atualizações de versão secundária (Azure) | O Banco de Dados do Azure para MySQL - Servidor Flexível aplica patches automaticamente aos servidores de banco de dados para a versão secundária determinada pelo Azure. Isso acontece como parte da manutenção planejada do serviço. Isso causará em alguns segundos de tempo de inatividade e o servidor de banco de dados será reiniciado automaticamente com a nova versão secundária. Para saber mais, consulte a documentação e também verifique o portal. |
Quando o servidor flexível é configurado com alta disponibilidade com redundância de zona, o servidor flexível executa operações no servidor em espera primeiro e, em seguida, no servidor primário sem um failover. Consulte os conceitos de alta disponibilidade no Banco de Dados do Azure para MySQL - Servidor Flexível para obter mais detalhes.
Mitigação de tempo de inatividade não planejada
Tempos de inatividade não planejados podem ocorrer como resultado de falhas imprevistas, incluindo falhas de hardware subjacentes, problemas de rede e bugs de software. Se o servidor de banco de dados ficar inativo inesperadamente, e tiver sido configurado com alta disponibilidade [HA], então será ativada a réplica em espera. Caso contrário, será provisionado automaticamente um novo servidor de banco de dados. Embora uma interrupção não planejada seja inevitável, o servidor flexível atenua esse tempo de inatividade executando automaticamente operações de recuperação nas camadas do servidor de banco de dados e de armazenamento, sem necessidade de intervenção humana.
Tempo de inatividade não planejado: cenários de falha e recuperação de serviço
Seguem alguns cenários de falha não planejados e o processo de recuperação:
| Cenário | Processo de recuperação [não-HA] | Processo de recuperação [HA] |
|---|---|---|
| Falha no servidor de banco de dados | Se o servidor de banco de dados estiver inoperante devido a alguma falha de hardware subjacente, as conexões ativas serão removidas e todas as transações em andamento serão anuladas. O Azure tenta reiniciar o servidor de banco de dados. Se tiver êxito, a recuperação do banco de dados será executada. Se a reinicialização falhar, a reinicialização do servidor de banco de dados será tentada em outro nó físico. O tempo de recuperação (RTO) depende de vários fatores, incluindo a atividade no momento da falha, como grandes transações, e a quantidade de recuperação a ser realizada durante o processo de inicialização do servidor de banco de dados. O RPO é zero, pois não se espera perda de dados para as transações confirmadas. Os aplicativos que usam os bancos de dados do MySQL precisam ser criados de forma que detectem e repitam as conexões e as transações com falha. Quando o aplicativo tentar novamente, as conexões serão direcionadas para o servidor de banco de dados recém-criado. Outras opções disponíveis incluem a restauração do backup. Você pode usar o PITR ou a restauração geográfica de uma região emparelhada. PITR : RTO: Varia, RPO=0seg Restauração geográfica: RTO: Varia RPO <1 h. Você também pode usar a réplica de leitura como solução de DR. Você pode interromper a replicação, o que torna a réplica de leitura e gravação (autônoma e, em seguida, redireciona o tráfego do aplicativo para este banco de dados). O RTO, na maioria dos casos, é de alguns minutos e o RPO < de 1 hora. Em alguns casos, os valores de RTO e RPO podem ser muito maiores, dependendo de vários fatores, incluindo a latência entre os sites, a quantidade de dados a serem transmitidos e, principalmente, a carga de trabalho de gravação do banco de dados principal. |
Caso sejam detectadas falhas no servidor de banco de dados ou erros irrecuperáveis, o servidor de banco de dados em espera é ativado, reduzindo assim o tempo de inatividade. Consulte a página de conceitos de HA para obter mais detalhes. Espera-se que o RTO seja de 60 a 120 segundos, com RPO = 0. Nota:As opções para o processo de recuperação [não-HA] também são aplicáveis aqui. |
| Falha de armazenamento | Os aplicativos não detectam impactos relacionados aos problemas de armazenamento, como uma falha de disco ou uma corrupção do bloco físico. À medida que os dados são armazenados em três cópias, a cópia dos dados é atendida pelo armazenamento sobrevivente. As corrupções de bloco são corrigidas automaticamente. Se uma cópia dos dados for perdida, uma nova cópia dos dados será criada automaticamente. Em um cenário raro ou de pior caso, se todas as cópias estiverem corrompidas, podemos usar a restauração geográfica (região emparelhada). O RPO seria de < 1 hora e o RTO variaria. Você também pode usar a réplica de leitura como solução de DR, conforme detalhado acima. |
Para esse cenário, as opções são as mesmas do processo de recuperação [não relacionado à alta disponibilidade]. |
| Erros lógicos/do usuário | A recuperação de erros do usuário, como tabelas removidas por acidente ou dados atualizados incorretamente, envolve a execução de uma PITR (recuperação pontual), que restaura e recupera os dados até o momento anterior da ocorrência do erro. É possível recuperar um recurso de servidor flexível excluído dentro de cinco dias a partir do momento da exclusão do servidor. Para obter um guia detalhado sobre como restaurar um servidor excluído, [consulte as etapas documentadas] (../flexible-server/how-to-restore-dropped-server.md). Para proteger recursos do servidor contra a exclusão acidental ou alterações inesperadas, após as implantações, os Administradores podem usar bloqueios de gerenciamento. |
Esses erros de usuário não são protegidos com alta disponibilidade, pois todas as operações de usuário também são replicadas para o estado em espera. Para esse cenário, as opções são as mesmas do processo de recuperação [não relacionado à alta disponibilidade] |
| Falha na zona de disponibilidade | Embora seja um evento raro, se você quiser se recuperar de uma falha no nível da zona, poderá executar a restauração geográfica em uma região emparelhada. O RPO seria de <1 hora e o RTO variaria. Você também pode usar a réplica de leitura como solução de DR criando a réplica em outra zona de disponibilidade. O RTO\RPO é como detalhado acima. |
Caso tenha habilitado a alta disponibilidade com redundância de zona, o servidor flexível executará o failover automático para o site em espera. Consulte os conceitos de alta disponibilidade no Banco de Dados do Azure para MySQL - Servidor Flexível para obter mais detalhes. Espera-se que o RTO seja de 60 a 120 segundos, com RPO = 0. Outras opções disponíveis incluem a restauração do backup. Você pode usar o PITR ou a restauração geográfica de uma região emparelhada. PITR : RTO: Varia, RPO=0 seg Restauração geográfica: RTO: Varia RPO <1 h Nota:Se você tiver o HA na mesma zona ativado, as opções são as mesmas que para o processo de recuperação [sem HA]. |
| Falha regional | Embora seja um evento raro, se você quiser se recuperar de uma falha no nível de região, poderá executar a recuperação do banco de dados criando um novo servidor usando o backup com redundância geográfica mais recente disponível na mesma assinatura para obter os dados mais recentes. Um novo servidor flexível é implantado na região selecionada. O tempo necessário para a restauração depende do backup anterior e do número de logs de transações a ser recuperados. Na maioria dos casos, o RPO seria de <1 hora e o RTO variaria. | Para esse cenário, as opções são as mesmas do processo de recuperação [não relacionado à alta disponibilidade]. |
Requisitos e limitações
Residência de dados regionais
Por padrão, o Banco de Dados do Azure para MySQL - Servidor Flexível não move nem armazena dados do cliente fora da região em que está implantado. No entanto, os clientes podem optar por ativar backups georredundantes ou configurar a replicação entre regiões para armazenar dados em outra região.