Usar bancos de dados globais do Amazon Aurora - Amazon Aurora

Usar bancos de dados globais do Amazon Aurora

Os bancos de dados globais do Amazon Aurora abrangem várias Regiões da AWS, permitindo leituras globais de baixa latência e fornecendo recuperação rápida de qualquer interrupção que possa afetar toda uma Região da AWS. Um banco de dados global Aurora tem um cluster de banco de dados primário em uma região e até cinco clusters de banco de dados secundários em diferentes regiões.

Visão geral de bancos de dados globais do Amazon Aurora

Ao usar um Amazon Aurora Global Database, você pode executar suas aplicações distribuídas globalmente usando um único banco de dados Aurora que abrange várias Regiões da AWS.

Um Aurora Global Database consiste em uma Região da AWS principal, onde seus dados são utilizados, e até cinco Regiões da AWS secundárias apenas para leitura. Você emite operações de gravação diretamente ao cluster de banco de dados primário na Região da AWS principal. O Aurora replica dados para as Regiões da AWS que usam infraestrutura dedicada, com latência normalmente abaixo de um segundo.

O diagrama a seguir mostra um exemplo de Aurora Global Database que abrange duas Regiões da AWS.


        Um banco de dados Aurora global tem um único cluster de bancos de dados Aurora primário e pelo menos um secundário.

Expanda cada cluster secundário de maneira independente adicionando uma ou mais instâncias réplicas de Aurora (instâncias de bancos de dados Aurora somente leitura) para atender workloads somente leitura.

Somente o cluster primário realiza operações de gravação. Os clientes que realizam operações de gravação se conectam ao endpoint do cluster de banco de dados do cluster de banco de dados primário. Como mostrado no diagrama, o banco de dados global de Aurora usa o volume de armazenamento de cluster e não o mecanismo de banco de dados para replicação. Para saber mais, consulte Visão geral do armazenamento do Amazon Aurora.

O banco de dados global Aurora foi criado para aplicações com uma presença mundial. Os clusters de banco de dados secundários somente leitura (Regiões da AWS) permitem que você ofereça suporte a operações de leitura mais próximas dos usuários do aplicação. Ao usar o recurso de encaminhamento de gravação, você também pode configurar um banco de dados global Aurora para que os clusters secundários enviem dados para o primário. Para ter mais informações, consulte Como usar o encaminhamento de gravação em um banco de dados global Amazon Aurora.

O banco de dados global do Aurora comporta duas operações diferentes para alterar a região do cluster de banco de dados principal, dependendo do cenário: transição de banco de dados global e failover de banco de dados global.

  • Para procedimentos operacionais planejados, como alternância regional, use transição de banco de dados global (anteriormente chamada de “failover planejado gerenciado”). Com esse recurso, você pode realocar o cluster principal de um banco de dados global Aurora íntegro para uma de suas regiões secundárias sem perda de dados. Para saber mais, consulte Realizar transições para o Amazon Aurora Global Database.

  • Para recuperar seu banco de dados global do Aurora após uma interrupção na região principal, use o failover de banco de dados global. Com esse recurso, você faz o failover do cluster de banco de dados da região principal para outra (failover entre regiões). Para saber mais, consulte Failovers planejados gerenciados para o Aurora Global Database.

Vantagens de bancos de dados globais do Amazon Aurora

Usando bancos de dados globaisAurora, você pode obter as seguintes vantagens:

  • Leitura global com latência local: se você tem escritórios em todo o mundo, é possível usar um Aurora Global Database para manter suas principais fontes de informações atualizadas na Região da AWS principal. Escritórios em outras regiões podem acessar as informações em sua própria região com latência local.

  • Clusters de banco de dados secundários do Aurora escaláveis: é possível escalar seus clusters secundários adicionando mais instâncias apenas para leitura (réplicas do Aurora) a uma Região da AWS secundária. O cluster secundário é somente leitura, portanto, pode oferecer suporte a até 16 instâncias somente leitura da réplica do Aurora em vez do limite usual de 15 para um único cluster do Aurora.

  • Replicação rápida de clusters de banco de dados de Aurora primários para secundários: a replicação realizada por um banco de dados Aurora global tem pouco impacto na performance no cluster de banco de dados primário. Os recursos das instâncias de banco de dados são totalmente dedicados para atender as workloads de leitura e gravação.

  • Recuperar interrupções em toda a região: os clusters secundários permitem que você torne um Aurora Global Database disponível em uma nova Região da AWS principal mais rapidamente (menor RTO) e com menos perda de dados (menor RPO) do que as soluções tradicionais de replicação.

Disponibilidade de região e versão

A disponibilidade e a compatibilidade de recursos variam entre versões específicas de cada mecanismo de banco de dados do Aurora e entre Regiões da AWS. Para ter mais informações sobre a disponibilidade de versões e regiões com o Aurora e bancos de dados globais, consulte Bancos de dados globais do Aurora.

Limitações dos bancos de dados globais do Amazon Aurora

No momento, as seguintes limitações se aplicam aos bancos de dados globais do Aurora:

  • O banco de dados global do Aurora está disponível em determinadas Regiões da AWS e somente para versões específicas do Aurora MySQL e do Aurora PostgreSQL . Para ter mais informações, consulte Bancos de dados globais do Aurora.

  • Os bancos de dados globais do Aurora têm requisitos específicos de configuração para classes de instância de banco de dados do Aurora compatíveis, número máximo de Regiões da AWS e assim por diante. Para ter mais informações, consulte Requisitos de configuração do banco de dados do Amazon Aurora global.

  • Para compatibilidade do Aurora MySQL com MySQL 5.7, as transições do banco de dados global do Aurora exigem a versão 2.09.1 ou posterior.

  • Você só poderá realizar transições ou failovers gerenciados entre regiões em um banco de dados global do Aurora se os clusters de banco de dados primário e secundário tiverem as mesmas versões principal, secundária e nível de patch do mecanismo. No entanto, os níveis de patch poderão ser diferentes se as versões secundárias do mecanismo forem uma das seguintes.

    Mecanismo do banco de dados Versões secundárias do mecanismo

    Aurora PostgreSQL

    • Versão 14.5 ou versões secundárias superiores

    • Versão 13.8 ou versões secundárias superiores

    • Versão 12.12 ou versões secundárias superiores

    • Versão 11.17 ou versões secundárias superiores

    Para ter mais informações, consulte Compatibilidade em nível de patch para transições e failovers gerenciados entre regiões.

  • Atualmente, os bancos de dados Aurora globais não suportam os seguintes recursos Aurora:

    • Aurora Serverless v1

    • Retroceder no Aurora

  • Para saber as limitações do uso do recurso RDS Proxy com bancos de dados globais, consulte Limitações do RDS Proxy com bancos de dados globais.

  • A atualização automática da versão secundária não se aplica a clusters do Aurora MySQL e do Aurora PostgreSQL que fazem parte de um banco de dados global Aurora. Observe que você pode especificar essa configuração para uma instância de banco de dados que faz parte de um cluster de banco de dados global, mas a configuração não tem qualquer efeito.

  • No momento, os bancos de dados globais Aurora não oferecem suporte ao Aurora Auto Scaling para clusters de banco de dados secundários.

  • Para usar fluxos de atividades de banco de dados em bancos de dados globais do Aurora que executam o Aurora MySQL 5.7, a versão do mecanismo deve ser 2.08 ou posterior. Para obter informações sobre fluxos de atividades do banco de dados, consulte Monitorar o Amazon Aurora com o recurso Database Activity Streams.

  • No momento, as seguintes limitações se aplicam aos bancos de dados globais do Aurora:

    • Você não pode aplicar um grupo de parâmetros personalizado ao cluster de banco de dados global enquanto estiver executando uma atualização de versão principal desse banco de dados global do Aurora. Crie seus grupos de parâmetros personalizados em cada região do cluster global e, depois, aplique-os manualmente aos clusters regionais após a atualização.

    • Com um banco de dados Aurora global baseado no Aurora MySQL, você não poderá executar uma atualização no local do Aurora MySQL versão 2 para a versão 3 se o parâmetro lower_case_table_names estiver ativado. Para ter mais informações sobre os métodos que você pode usar, consulte Atualizações de versão principal.

    • Com um banco de dados global Aurora baseado no Aurora PostgreSQL, você não poderá executar uma atualização de versão principal do mecanismo de banco de dados Aurora se o recurso do objetivo de ponto de recuperação (RPO) estiver ativado. Para ter mais informações sobre o recurso RPO, consulte Gerenciamento de RPOs para bancos de dados globais baseados em Aurora PostgreSQL–.

    • Com um banco de dados Aurora global baseado no Aurora MySQL, não é possível executar uma atualização de versão secundária das versões 3.01 ou 3.02 para as versões 3.03 ou superiores usando o processo padrão. Para obter detalhes sobre processo que deve ser utilizado, consulte Atualizar o Aurora MySQL modificando a versão do mecanismo.

    Para obter informações sobre como atualizar um Aurora Global Database, consulte Atualizar um Amazon Aurora Global Database.

  • Você não pode interromper ou iniciar os clusters de bancos de dados Aurora em seu banco de dados Aurora global individualmente. Para saber mais, consulte Interromper e iniciar um cluster de banco de dados do Amazon Aurora.

  • Réplicas do Aurora anexadas ao cluster de banco de dados Aurora primário podem ser reiniciadas em determinadas circunstâncias. Se a instância de banco de dados da Região da AWS principal for reiniciada ou sofrer failover, as réplicas do Aurora dessa região também serão reiniciadas. O cluster fica indisponível até que todas as réplicas estejam novamente sincronizadas com a instância do gravador do cluster de banco de dados primário. O comportamento do cluster primário durante a reinicialização ou o failover é o mesmo de um cluster de banco de dados único e não global. Para ter mais informações, consulte Replicação com o Amazon Aurora.

    Certifique-se de entender os impactos no seu banco de dados global Aurora antes de fazer alterações no cluster de banco de dados primário. Para saber mais, consulte Recuperar um banco de dados global Amazon Aurora de uma interrupção não planejada.

  • No momento, os bancos de dados globais do Aurora não comportam o status inaccessible-encryption-credentials-recoverable quando o Amazon Aurora perde o acesso à chave AWS KMS do cluster de banco de dados. Nesses casos, o cluster de banco de dados criptografado entra diretamente no estado terminal inaccessible-encryption-credentials. Para mais informações sobre esses estados, consulte Visualizar o status do cluster do banco de dados.

  • Os clusters de banco de dados baseados em Aurora PostgreSQL– em execução em um banco de dados Aurora global têm as seguintes limitações:

    • Não há suporte ao gerenciamento de cache de cluster para clusters de banco de dados Aurora PostgreSQL que fazem parte de bancos de dados globais do Aurora.

    • Se o cluster de banco de dados primário do seu banco de dados global Aurora for baseado em uma réplica de uma instância PostgreSQL de Amazon RDS, você não poderá criar um cluster secundário. Não tente criar um secundário a partir desse cluster usando a operação AWS Management Console, AWS CLI ou API da CreateDBCluster. As tentativas de fazer isso expiram e o cluster secundário não é criado.

Recomendamos que você crie clusters de banco de dados secundários para seus bancos de dados Aurora globais usando a mesma versão do mecanismo de banco de dados do Aurora como primário. Para ter mais informações, consulte Criar um banco de dados global do Amazon Aurora.