Ei, pessoal.
E bem-vindo de volta.
Agora, neste vídeo com uma visão geral de alto nível, vamos discutir sobre as idéias da Amazônia, as implantações
em zonas de multi-disponibilidade também chamadas de implantações múltiplas.
Agora, antes de discutirmos mais detalhes sobre isso, vamos analisar um desafio típico.
Portanto, vamos supor que você tenha um banco de dados que esteja rodando na zona de disponibilidade, número um.
Agora, por alguma razão, se esta zona de disponibilidade cair ou talvez o hardware no qual o banco de dados
estava rodando cair, então toda sua aplicação irá cair porque o coração da aplicação
onde os dados estão armazenados é o banco de dados.
Se o banco de dados estiver em baixo, então todo o site pode cair.
E isto é algo que você realmente não quer para os ambientes de produção.
E esta é a razão pela qual é muito importante que sempre que você usar idéias para a produção, você evite
as implantações baseadas em uma única zona de disponibilidade.
E a melhor arquitetura é a utilização de uma zona de disponibilidade múltipla.
Portanto, em uma arquitetura de implantação baseada em múltiplos AC, o que acontece é que você tem o banco de
dados primário aqui e tem um banco de dados secundário que está funcionando em uma zona de disponibilidade diferente
da mesma região e há uma replicação que acontece entre esses dois bancos de dados.
Agora, devido a algum motivo, digamos que o banco de dados primário desce em tais casos, as idéias redirecionarão
todos os pedidos para o stand by instance.
Muito bem.
Portanto, este é o processo automatizado.
Como usuário ou como aplicação, você não precisa realmente se preocupar com isso.
Agora, uma das perguntas que vem aqui é: em que cenário esse failover automatizado ocorre da instância
primária à instância de espera?
Agora, antes de olharmos para o campo de condições, vamos rapidamente revisar isso no caso de haver uma interrupção
planejada ou não planejada de sua instância de banco de dados, então isto muda automaticamente para a réplica em espera em outra zona
de disponibilidade nas implantações AC múltiplas.
Isto é algo que já vimos.
Agora vamos analisar algumas das condições.
Primeiro é que se houver uma perda de disponibilidade na zona de disponibilidade primária.
Segundo, se houver uma perda de conectividade de rede para a instância primária, se houver uma falha da unidade
de computação na instância primária, novamente, a condição de failover ocorrerá.
Se houver uma falha de armazenamento no banco de dados primário em tais casos, também ocorre o failover automatizado.
E quando olhamos para o tempo de falha, ele normalmente varia de 60 a 1 a 20 segundos.
Agora, vamos fazer uma coisa.
Vamos em frente e entendamos isso do ponto de vista da demonstração para que nosso conceito seja claro.
Agora, para a demonstração de hoje, eu tenho um banco de dados que é criado com base na implantação de multi AC.
O nome do banco de dados é Demo DB, Multi AC.
Agora, se você olhar para este banco de dados específico, deixe-me ir para a configuração.
Vamos um pouco mais abaixo.
Você vê que ele afirma que o multi AC está habilitado, então ele está afirmando como sim.
Portanto, vamos em frente e ver como ele funciona exatamente.
Portanto, vamos para a conectividade aqui.
Deixe-me copiar o ponto final da instância de IDs.
E vamos rapidamente fazer uma pesquisa para ver qual é o endereço IP que é devolvido aqui.
O endereço IP é um 7231 37. 32.
Portanto, nesta fase, se eu tiver que mostrar isto em termos de diagrama, você pode considerar que este
endereço IP que foi devolvido é o da instância primária aqui.
Agora, para uma perspectiva de demonstração, faremos um failover e veremos como o endereço IP muda para o da instância
secundária.
Portanto, vamos fazer uma coisa.
Vamos em frente e reinicializar a instância do banco de dados.
Agora, sempre que você reiniciar, você tem uma opção de reiniciar com Failover.
Portanto, vamos em frente e façamos uma confirmação.
Portanto, esta é apenas uma maneira simples de identificar como funciona a implantação multi AC em cenários do mundo real.
Caso haja algum problema relacionado à rede e toda a falha aconteça automaticamente, você não precisa realmente
se preocupar com isso.
Portanto, deixe-me rapidamente fazer uma confirmação.
Muito bem.
Portanto, a reconstrução está ocorrendo.
Por isso, vamos esperar um momento rapidamente aqui.
Assim, na atualização, nosso status está agora disponível.
Agora, nesta fase, se você fizer a pesquisa NSS novamente para encontrar o endereço IP associado à instância do
banco de dados, desta vez você verá que o endereço IP é diferente.
Antes era um 7231 3732, agora é um 7231 79. 1 47.
Assim, nos bastidores, a RDC redirecionou automaticamente o pedido para a instância de espera aqui.
Agora, uma coisa importante que precisa ser notada é que o URL do ponto final que estamos discutindo
aqui, isto continua sendo o mesmo.
Assim, mesmo se o banco de dados primário cair e se as solicitações forem para este ponto final, as idéias irão automaticamente
direcionar a solicitação para a instância de espera.
E esta é a razão pela qual a alta disponibilidade oral funciona em uma arquitetura baseada em múltiplos AC.