Como trabalhar com clusters de vários mestres do Aurora - Amazon Aurora
Visão geral de clusters de vários mestres do Como criar um cluster de vários mestresComo gerenciar clusters de vários mestres do Considerações sobre aplicaçõesConsiderações sobre performanceAbordagens para os clusters de vários mestres do

Como trabalhar com clusters de vários mestres do Aurora

Importante

A Amazon anunciou uma política de fim de vida útil para o Amazon Aurora edição compatível com MySQL v1. Para obter detalhes sobre quanto tempo o Aurora MySQL versão 1 permanecerá disponível e como migrar para uma versão mais recente do Aurora MySQL, consulte Preparar para o fim da vida útil do Amazon Aurora, edição compatível com MySQL versão 1.

A seguir, você pode saber mais sobre os clusters de vários mestres do Aurora. Em um cluster de vários mestres, todas as instâncias de banco de dados possuem o recurso de leitura/gravação. Os clusters de vários mestres têm diferentes características de disponibilidade, suporte para recursos de banco de dados e procedimentos para monitoramento e solução de problemas em comparação com os clusters de mestre único.

Visão geral de clusters de vários mestres do Aurora

Use as informações básicas a seguir para escolher um cluster de vários mestres ou mestre único ao configurar um novo cluster do Aurora. Para fazer uma escolha informada, recomendamos que você primeiro entenda como pretende adaptar o design do esquema e a lógica da aplicação para funcionar melhor com um cluster de vários mestres.

Para cada novo cluster do Amazon Aurora, você pode escolher se deseja criar um cluster de mestre único ou vários mestres.

A maioria dos tipos de clusters do Aurora consiste em clusters de mestre único. Por exemplo, clusters provisionados, do Aurora Serverless, de consulta paralela e do Global Database são todos clusters de mestre único. Em um cluster de mestre único, uma única instância de banco de dados executa todas as operações de gravação e quaisquer outras instâncias de banco de dados são somente leitura. Se a instância de banco de dados do gravador ficar indisponível, um mecanismo de failover promoverá uma das instâncias somente leitura à condição de novo gravador.

Em um cluster de vários mestres, todas as instâncias de banco de dados podem executar operações de gravação. As noções de uma única instância primária de leitura/gravação e várias réplicas somente leitura do Aurora não se aplicam. Não há failover quando uma instância de banco de dados do gravador fica indisponível, já que outra instância de banco de dados do gravador torna-se imediatamente disponível para assumir o trabalho da instância com falha. Chamamos esse tipo de disponibilidade de disponibilidade contínua, para diferenciá-la da alta disponibilidade (com breve tempo de inatividade durante o failover) oferecida por um cluster de mestre único.

Clusters de vários mestres funcionam de diferentes maneiras dos vários outros tipos de clusters do Aurora, como clusters provisionados, do Aurora Serverless e de consulta paralela. Com os clusters de vários mestres, é necessário considerar diferentes fatores em áreas como alta disponibilidade, monitoramento, gerenciamento de conexão e recursos de banco de dados. Por exemplo, em aplicações nas quais você não pode arcar com nem mesmo um tempo de inatividade curto durante operações de gravação de banco de dados, um cluster de vários mestres pode ajudar a evitar uma interrupção quando uma instância do gravador torna-se indisponível. O cluster de vários mestres não usa o mecanismo de failover, pois não precisa promover outra instância de banco de dados para ter o recurso de leitura/gravação. Com um cluster de vários mestres, é preciso examinar métricas relacionadas a taxa de transferência, latência e deadlocks de DML para todas as instâncias de banco de dados em vez de uma única instância principal.

Atualmente, os clusters de vários mestres requerem o Aurora MySQL versão 1, que é compatível com o MySQL 5.6. Ao especificar a versão do mecanismo de banco de dados no AWS Management Console, na AWS CLI ou na API do RDS, escolha 5.6.10a.

Para criar um cluster de vários mestres, é preciso escolher Multiple writers (Vários gravadores) em Database features (Recursos do banco de dados) durante a criação do cluster. Isso permite um comportamento diferente para replicação entre instâncias de banco de dados, disponibilidade e desempenho em comparação com outros tipos de clusters do Aurora. Essa escolha permanece em vigor durante a vida útil do cluster. Entenda os casos de uso especializados que são apropriados para clusters de vários mestres.

Terminologia de clusters de vários mestres

Você pode entender a terminologia sobre clusters de vários mestres aprendendo as definições a seguir. Estes termos são usados em toda a documentação para clusters de vários mestres.

Gravador

Uma instância de banco de dados que pode executar operações de gravação. Em um cluster de vários mestres do Aurora, todas as instâncias de banco de dados são gravadores. Trata-se de uma diferença significativa dos clusters de mestre único do Aurora, em que apenas uma instância de banco de dados pode atuar como gravador. Com um cluster de mestre único, se o gravador ficar indisponível, o mecanismo de failover promoverá outra instância de banco de dados à condição de novo gravador. Com um cluster de vários mestres, sua aplicação pode redirecionar operações de gravação da instância de banco de dados com falha para qualquer outra instância de banco de dados no cluster.

Vários mestres

Uma arquitetura para clusters do Aurora em que cada instância de banco de dados pode executar operações de leitura e gravação. Compare isso com mestre único. Os clusters de vários mestres são mais adequados para cargas de trabalho segmentadas, como as de aplicações de vários locatários.

Mestre único

A arquitetura padrão para clusters do Aurora. Uma única instância de banco de dados (a instância primária) executa gravações. Todas as outras instâncias de banco de dados (as réplicas do Aurora) manipulam o tráfego de consulta somente leitura. Compare isso com vários mestres. Essa arquitetura é apropriada para aplicações de uso geral. Em tais aplicações, uma única instância de banco de dados pode manipular todas as instruções DML (data manipulation language, linguagem de manipulação de dados) e DDL (data definition language, linguagem de definição de dados). Os problemas de escalabilidade envolvem principalmente consultas SELECT.

Conflito de gravação

Uma situação que ocorre quando diferentes instâncias de banco de dados tentam modificar a mesma página de dados ao mesmo tempo. O Aurora informa um conflito de gravação à aplicação como um erro de impasse. Essa condição de erro faz com que a transação seja revertida. Sua aplicação deve detectar o código de erro e tentar novamente a transação.

A principal consideração de design e objetivo de ajuste de desempenho com clusters de vários mestres do Aurora é dividir suas operações de gravação entre instâncias de banco de dados de modo a minimizar conflitos de gravação. É por isso que os clusters de vários mestres são adequados para aplicações fragmentadas. Para obter detalhes sobre o mecanismo de conflito de gravação, consulte Resolução de conflitos para clusters de vários mestres.

Fragmentação

Uma classe específica de cargas de trabalho segmentadas. Os dados são fisicamente divididos em várias partições, tabelas, bancos de dados ou até mesmo clusters separados. Os contêineres para partes específicas dos dados são conhecidos como fragmentos. Em um cluster de vários mestres do Aurora, cada fragmento é gerenciado por uma instância de banco de dados específica, e uma instância de banco de dados pode ser responsável por vários fragmentos. Um design de esquema fragmentado mapeia bem a maneira como você gerencia conexões em um cluster de vários mestres do Aurora.

Fragmento

A unidade de granularidade dentro de uma implantação fragmentada. Pode ser uma tabela, um conjunto de tabelas relacionadas, um banco de dados, uma partição ou até mesmo um cluster inteiro. Com os clusters de vários mestres do Aurora, você pode consolidar os dados de uma aplicação fragmentada em um único volume de armazenamento compartilhado do Aurora, tornando o banco de dados continuamente disponível e os dados fáceis de gerenciar. Decida quais fragmentos são gerenciados por cada instância de banco de dados. Você pode alterar esse mapeamento a qualquer momento, sem reorganizar fisicamente os dados.

Refragmentação

Reorganização física de dados fragmentados para que instâncias de banco de dados diferentes possam manipular tabelas ou banco de dados específicos. Você não precisa reorganizar fisicamente os dados dentro dos clusters de vários mestres do Aurora em resposta à alteração da workload ou a falhas de instâncias de banco de dados. Você pode evitar operações de fragmentação porque todas as instâncias de banco de dados em um cluster podem acessar todos os bancos de dados e tabelas por meio do volume de armazenamento compartilhado.

Multilocatário

Uma classe específica de cargas de trabalho segmentadas. Os dados de cada cliente ou usuário são mantidos em uma tabela ou um banco de dados separado. Esse design garante isolamento e ajuda você a gerenciar capacidade e recursos no nível de usuários individuais.

BYOS (Bring-your-own-shard, trazer seu próprio fragmento)

Uma situação em que você já possui um esquema de banco de dados e aplicações associadas que usam fragmentação. Você pode transferir essas implantações com relativa facilidade para clusters de vários mestres do Aurora. Nesse caso, você pode concentrar seus esforços em investigar os benefícios do Aurora, como a consolidação do servidor e a alta disponibilidade. Não é preciso criar outra lógica da aplicação para lidar com várias conexões para solicitações de gravação.

GRAW (Global read-after-write, leitura após gravação global)

Uma configuração que apresenta a sincronização para que qualquer operação de leitura sempre veja o estado mais atual dos dados. Por padrão, os dados vistos por uma operação de leitura em um cluster de vários mestres estão sujeitos a atraso de replicação, geralmente alguns milissegundos. Durante esse breve intervalo, uma consulta em uma instância de banco de dados pode recuperar dados obsoletos se os mesmos dados forem modificados ao mesmo tempo por uma instância de banco de dados diferente. Para habilitar essa configuração, altere aurora_mm_session_consistency_level em sua configuração padrão de INSTANCE_RAW para REGIONAL_RAW. Isso garante a consistência em todo o cluster para operações de leitura, independentemente das instâncias de banco de dados que executam as leituras e gravações. Para detalhes sobre o modo GRAW, consulte Modelo de consistência para clusters de vários mestres.

Arquitetura de clusters de vários mestres

Clusters de vários mestres têm uma arquitetura diferente de outros tipos de clusters do Aurora. Em clusters de vários mestres, todas as instâncias de banco de dados possuem capacidade de leitura/gravação. Outros tipos de clusters do Aurora possuem uma única instância de banco de dados dedicada que executa todas as operações de gravação, enquanto todas as outras instâncias de banco de dados são somente leitura e manipulam apenas consultas SELECT. Os clusters de vários mestres não possuem uma instância primária ou réplicas somente leitura do Aurora.

Sua aplicação controla quais solicitações de gravação são manipuladas por qual instância do banco de dados. Assim, com um cluster de vários mestres, você se conecta a endpoints de instância individuais para emitir instruções DML e DDL. Isso é diferente de outros tipos de clusters do Aurora, nos quais você geralmente direciona todas as operações de gravação para o endpoint de cluster único e todas as operações de leitura para o endpoint de leitor único.

O armazenamento subjacente para clusters de vários mestres do Aurora é semelhante ao armazenamento para clusters de mestre único. Seus dados ainda estão armazenados em um volume de armazenamento compartilhado altamente confiável que cresce automaticamente. A principal diferença está no número e no tipo de instâncias do banco de dados. Nos clusters de vários mestres, existem N nós de leitura/gravação. Atualmente, o máximo de N é 4.

Os clusters de vários mestres não possuem nós dedicados somente leitura. Assim, os procedimentos e diretrizes do Aurora sobre réplicas do Aurora não se aplicam a clusters de vários mestres. De forma temporária, você pode fazer com que uma instância de banco de dados somente leitura distribua cargas de trabalho de leitura e gravação em diferentes instâncias de banco de dados. Para fazer isto, consulte Como usar o modo somente leitura da instância.

Os nós de cluster de vários mestres são conectados usando a replicação do Aurora de baixa latência e pouco atraso. Os clusters de vários mestres usam a replicação completa ponto a ponto. A replicação funciona diretamente entre os gravadores. Todo gravador replica suas mudanças para todos os outros gravadores.

Instâncias de banco de dados em um cluster de vários mestres manipulam a reinicialização e a recuperação de forma independente. Se um gravador for reiniciado, não será necessário que outros gravadores também reiniciem. Para obter mais detalhes, consulte Considerações sobre alta disponibilidade para clusters de vários mestres do Aurora.

Os clusters de vários mestres acompanham todas as alterações nos dados em todas as instâncias de banco de dados. A unidade de medida é a página de dados, que tem um tamanho fixo de 16 KB. Essas alterações incluem modificações nos dados da tabela, índices secundários e tabelas do sistema. As alterações também podem ser resultado de tarefas internas de limpeza do Aurora. O Aurora garante consistência entre as várias cópias físicas que o Aurora mantém para cada página de dados no volume de armazenamento compartilhado e na memória nas instâncias de banco de dados.

Se duas instâncias de banco de dados tentam modificar a mesma página de dados quase no mesmo instante, ocorre um conflito de gravação. A solicitação de alteração mais antiga é aprovada usando um mecanismo de votação de quorum. Essa alteração é salva no armazenamento permanente. A instância de banco de dados cuja alteração não é aprovada reverte toda a transação que contém a tentativa de alteração. Reverter a transação garante que os dados sejam mantidos em um estado consistente e que as aplicações sempre tenham uma visualização previsível dos dados. Sua aplicação pode detectar a condição de deadlock e tentar novamente a transação inteira.

Para obter detalhes sobre como minimizar conflitos de gravação e sobrecarga de desempenho associada, consulte Resolução de conflitos para clusters de vários mestres.

Cargas de trabalho recomendadas para clusters de vários mestres

Os clusters de vários mestres funcionam melhor com certos tipos de cargas de trabalho.

Cargas de trabalho ativas/passivas

Com uma workload ativa-passiva, você executa todas as operações de leitura e gravação em uma instância de banco de dados por vez. Você mantém quaisquer outras instâncias de banco de dados no cluster do Aurora na reserva. Se a instância de banco de dados ativa original ficar indisponível, você imediatamente alternará todas as operações de leitura e gravação para a outra instância de banco de dados. Com essa configuração, você minimiza qualquer tempo de inatividade para operações de gravação. A outra instância de banco de dados pode assumir todo o processamento para sua aplicação sem executar um failover.

Cargas de trabalho ativas-ativas

Com uma workload ativa-ativa, você realiza operações de leitura e gravação em todas as instâncias de banco de dados ao mesmo tempo. Nesta configuração, você normalmente segmenta a workload para que as diferentes instâncias de banco de dados não modifiquem os mesmos dados subjacentes ao mesmo tempo. Isso minimiza a chance de conflitos de gravação.

Os clusters de vários mestres funcionam bem com a lógica de aplicação projetada para uma workload segmentada. Nesse tipo de workload, você divide operações de gravação por instância de banco de dados, banco de dados, tabela ou partição de tabela. Por exemplo, você pode executar várias aplicações no mesmo cluster, cada uma atribuídoa a uma instância de banco de dados específica. Como alternativa, você pode executar uma aplicação que usa várias tabelas pequenas, como uma tabela para cada usuário de um serviço on-line. O ideal é que você crie seu esquema para que as operações de gravação de instâncias de banco de dados diferentes não executem atualizações simultâneas de linhas sobrepostas nas mesmas tabelas. Aplicações fragmentadas são um exemplo desse tipo de arquitetura.

Para obter exemplos de designs para cargas de trabalho ativas-ativas, consulte Como usar um cluster de vários mestres para um banco de dados fragmentado.

Vantagens dos clusters de vários mestres

Você pode aproveitar os benefícios a seguir com clusters de vários mestres do Aurora:

  • Clusters de vários mestres melhoram a já alta disponibilidade do Aurora. É possível reiniciar uma instância de banco de dados de leitura/gravação sem fazer com que outras instâncias de banco de dados no cluster sejam reiniciadas. Não há processo de failover e atraso associado quando uma instância de banco de dados de leitura/gravação fica indisponível.

  • Os clusters de vários mestres são adequados para aplicações fragmentadas ou com vários locatários. Ao gerenciar os dados, é possível evitar operações complexas de refragmentação. Você pode consolidar aplicações fragmentadas com um número menor de clusters ou instâncias de banco de dados. Para obter mais detalhes, consulte Como usar um cluster de vários mestres para um banco de dados fragmentado.

  • O Aurora detecta conflitos de gravação imediatamente, não quando a transação é confirmada. Para obter detalhes sobre o mecanismo de conflito de gravação, consulte Resolução de conflitos para clusters de vários mestres.

Limitações dos clusters de vários mestres

nota

Clusters de vários mestres do Aurora estão disponíveis apenas para o Amazon Aurora edição compatível com MySQL v1. A Amazon anunciou uma política de fim de vida para essa versão principal do Aurora MySQL.

Para obter detalhes sobre quanto tempo o Aurora MySQL versão 1 permanecerá disponível e como migrar para uma versão mais recente do Aurora MySQL, consulte Preparar para o fim da vida útil do Amazon Aurora, edição compatível com MySQL versão 1.

Limitações da AWS e do Aurora

As limitações a seguir se aplicam atualmente aos recursos da AWS e do Aurora que você pode usar com clusters de vários mestres:

  • No momento, você pode ter no máximo duas instâncias de banco de dados em um cluster de vários mestres.

  • No momento, todas as instâncias de banco de dados em um cluster de vários mestres devem estar na mesma região da AWS.

  • As únicas classes de instância de banco de dados compatíveis sãodb.r4.2xlarge e db.r4.16xlarge.

  • Não é possível habilitar réplicas entre regiões de clusters de vários mestres.

  • Os clusters de vários mestres estão disponíveis nas seguintes regiões da AWS:

    • Região Leste dos EUA (N. da Virgínia)

    • Região Leste dos EUA (Ohio)

    • Região Oeste dos EUA (Oregon)

    • Região Ásia-Pacífico (Mumbai)

    • Região Ásia-Pacífico (Seul)

    • Região Ásia-Pacífico (Tóquio)

    • Região Europa (Frankfurt)

    • Região Europa (Irlanda)

  • A ação Stop não está disponível para clusters de vários mestres.

  • O cache da página possível de recuperar do Aurora, também conhecido como grupo de buffer possível de recuperar, não é compatível com clusters de vários mestres.

  • Um cluster de vários mestres não faz nenhum balanceamento de carga para conexões. Sua aplicação deve implementar sua própria lógica de gerenciamento de conexões para distribuir operações de leitura e gravação entre vários endpoints da instância de banco de dados. Em geral, em uma aplicação BYOS (bring-your-own-shard), você já tem lógica para mapear cada fragmento para uma conexão específica. Para saber como adaptar a lógica de gerenciamento de conexão em sua aplicação, consulte Gerenciamento de conexão para clusters de vários mestres.

  • Os clusters de vários mestres do Aurora são altamente especializados para casos de uso de disponibilidade contínua. Sendo assim, esses clusters podem não ser geralmente aplicáveis a todas as cargas de trabalho. Seus requisitos de desempenho, escalabilidade e disponibilidade podem ser satisfeitos por meio de uma classe de instância de banco de dados maior com um cluster de mestre único do Aurora. Nesse caso, considere usar um cluster provisionado ou Aurora Serverless.

  • Os clusters de vários mestres apresentam processamento e sobrecarga de rede para a coordenação entre instâncias de banco de dados. Essa sobrecarga tem as seguintes consequências para aplicações com uso intenso de leitura e gravação:

    • Benefícios de taxa de transferência são mais óbvios em clusters ocupados com várias operações de gravação simultâneas. Em muitos casos, um cluster do Aurora tradicional com uma única instância primária pode manipular o tráfego de gravação de um cluster. Nesses casos, os benefícios dos clusters de vários mestres são principalmente para alta disponibilidade e não para desempenho.

    • O desempenho de uma consulta única costuma ser inferior ao de um cluster de mestre único equivalente.

  • Não é possível obter um snapshot criado em um cluster de mestre único e restaurá-lo em um cluster de vários mestres ou o contrário. Em vez disso, para transferir todos os dados de um tipo de cluster para outro, use um despejo lógico produzido por uma ferramenta, como o AWS Database Migration Service (AWS DMS) ou o comando mysqldump.

  • Ao restaurar um snapshot criado em um cluster de vários mestres, inclua a opção --engine-mode multimaster. Se você não usar essa opção, será exibido um erro.

  • Você não pode usar os recursos de consulta paralela, do Aurora Serverless ou do Global Database em um cluster de vários mestres.

    A proporção de vários mestres é uma escolha permanente para um cluster. Não é possível alternar cluster do Aurora existente entre um cluster de vários mestres e outro tipo, como Aurora Serverless ou de consulta paralela.

  • Os recursos de aplicação de patches com tempo de inatividade zero (ZDP) e a reinicialização com tempo de inatividade zero (ZDR) não estão disponíveis para clusters de vários mestres.

  • A integração com outros produtos da AWS, como o AWS Lambda, o Amazon S3 e o AWS Identity and Access Management, não está disponível para clusters de vários mestres.

  • O recurso Insights de Performance não está disponível para clusters de vários mestres.

  • Não é possível clonar um cluster de vários mestres.

  • Não é possível habilitar o recurso de retrocesso para clusters de vários mestres.

Limitações do mecanismo de banco de dados

As seguintes limitações se aplicam aos recursos do mecanismo de banco de dados que você pode usar com um cluster de vários mestres:

  • Não é possível executar a replicação de log binário para ou de um cluster de vários mestres. Essa limitação significa que você também não pode usar a replicação de ID de transação global (GTID) em um cluster de vários mestres.

  • O programador de eventos não está disponível para clusters de vários mestres.

  • A otimização de junção hash não está habilitada em clusters de vários mestres.

  • O cache de consulta não está disponível em clusters de vários mestres.

  • Não é possível usar certos recursos da linguagem SQL em clusters de vários mestres. Para obter a lista completa de diferenças de SQL e instruções sobre como adaptar seu código SQL para lidar com essas limitações, consulte Considerações sobre SQL para clusters de vários mestres.

Migrar de clusters de vários mestres

A migração de um cluster de vários mestres do Aurora significa voltar para um cluster de banco de dados de um mestre do Aurora. Use um despejo lógico produzido por uma ferramenta como o AWS Database Migration Service (AWS DMS) ou o comando mysqldump.

Como criar um cluster de vários mestres do Aurora

Você não pode mais criar um cluster de banco de dados multimestre do Aurora usando AWS Management Console. Use a AWS CLI ou a API do RDS. Caso você ainda não tenha criado um cluster do Aurora, é possível entender o procedimento geral em Criar um cluster de bancos de dados do Amazon Aurora.

Para criar um cluster de vários mestres com a AWS CLI, execute o comando create-db-cluster da AWS CLI e inclua a opção --engine-mode com o valor multimaster.

O comando a seguir mostra a sintaxe para criar um cluster do Aurora com replicação de vários mestres. Para entender o procedimento geral para criar um cluster do Aurora, consulte Criar um cluster de banco de dados.

Para Linux, macOS ou Unix:

aws rds create-db-cluster --db-cluster-identifier sample-cluster --engine aurora \
    --engine-version 5.6.10a --master-username user_name --master-user-password password \
    --db-subnet-group-name my_subnet_group --vpc-security-group-ids my_vpc_id \
    --engine-mode multimaster

Para Windows:

aws rds create-db-cluster --db-cluster-identifier sample-cluster --engine aurora ^
    --engine-version 5.6.10a --master-username user_name --master-user-password password ^
    --db-subnet-group-name my_subnet_group --vpc-security-group-ids my_vpc_id ^
    --engine-mode multimaster

Após a criação do cluster multimestre, você pode adicionar instâncias de banco de dados de gravador a ele. Para obter mais informações, consulte Adicionar instâncias de banco de dados a um cluster multimestre do Aurora.

Para criar um cluster de vários mestres com a API do RDS, execute a operação CreateDBCluster. Especifique o valor multimaster do parâmetro EngineMode. Para entender o procedimento geral para criar um cluster do Aurora, consulte Criar um cluster de banco de dados.

Após a criação do cluster multimestre, você pode adicionar instâncias de banco de dados de gravador a ele. Para obter mais informações, consulte Adicionar instâncias de banco de dados a um cluster multimestre do Aurora.

Adicionar instâncias de banco de dados a um cluster multimestre do Aurora

Você precisa de mais de uma instância de banco de dados para ver os benefícios de um cluster multimestre do Aurora. Depois de criar a primeira instância, é possível criar até no máximo quatro instâncias de banco de dados. A diferença para clusters de vários mestres é que as novas instâncias de banco de dados possui capacidade de leitura/gravação em vez de uma réplica somente leitura do Aurora.

Console

Você pode usar o AWS Management Console para adicionar duas instâncias de banco de dados de gravador iniciais ao cluster de banco de dados multimestre ao mesmo tempo. As instâncias de banco de dados subsequentes são adicionadas individualmente.

Como adicionar instâncias de banco de dados a um cluster de banco de dados multimestre

  1. Na página Databases (Bancos de dados), selecione o cluster de banco de dados.

  2. Em Actions (Ações), escolha Add DB instance (Adicionar instância de banco de dados).

  3. (Opcional) Dê um nome à sua instância de banco de dados e selecione uma zona de disponibilidade.

  4. Para DB instance class (Classe de instância de banco de dados), selecione Include previous generation classes (Incluir classes da geração anterior) e selecione uma classe de instância de banco de dados db.r4.

  5. Selecione Add DB instance (Adicionar instância de banco de dados).

AWS CLI ou API do RDS

Usar a AWS CLI ou a API do RDS adiciona uma instância de banco de dados de gravador por vez. Siga o procedimento geral em Adicionar réplicas do Aurora a um cluster de banco de dados.

A AWS CLI de exemplo a seguir adiciona uma instância de banco de dados de gravador a um cluster de banco de dados multimestre do Aurora.

Para Linux, macOS ou Unix:

aws rds create-db-instance \
    --db-instance-identifier mm-cluster2-instance \
    --db-cluster-identifier mm-cluster2 \
    --db-instance-class db.r4.2xlarge \
    --engine aurora

Para Windows:

aws rds create-db-instance ^
    --db-instance-identifier mm-cluster2-instance ^
    --db-cluster-identifier mm-cluster2 ^
    --db-instance-class db.r4.2xlarge ^
    --engine aurora

Como gerenciar clusters de vários mestres do Aurora

A maior parte do gerenciamento e da administração de clusters de vários mestres do Aurora é realizada da mesma forma que outros tipos de clusters do Aurora. As seções a seguir explicam as diferenças e os recursos exclusivos dos clusters de vários mestres para administração e gerenciamento.

Como monitorar clusters de vários mestres do Aurora

A maioria dos recursos de monitoramento e diagnóstico compatíveis com os clusters de mestre único do MySQL e do Aurora também são compatíveis com clusters de vários mestres:

  • Logs de erro do MySQL, logs gerais e logs de consulta lenta.

  • Recursos de diagnóstico integrados do MySQL, como comandos SHOW, variáveis de status, tabelas de status de tempo de execução do InnoDB e assim por diante.

  • Esquema de desempenho do MySQL.

  • Auditoria avançada.

  • Métricas do CloudWatch.

  • Monitoramento avançado.

Os clusters de vários mestres do Aurora atualmente não são compatíveis com os seguintes recursos de monitoramento:

  • Performance Insights.

Performance do consumo de dados para clusters de vários mestres

Uma prática recomendada para operações DML em um cluster de vários mestres consiste em manter transações pequenas e breves. Além disso, roteie operações de gravação para uma tabela ou banco de dados específico para uma instância de banco de dados específica. Fazer uma importação em massa pode exigir o relaxamento da orientação em relação ao tamanho da transação. No entanto, você ainda pode distribuir as operações de gravação para minimizar a chance de conflitos de gravação.

Para distribuir a workload de gravação de uma importação em massa

  1. Emita um comando mysqldump separado para cada banco de dados, tabela ou outro objeto em seu esquema. Armazene os resultados de cada mysqldump em um arquivo cujo nome reflete o objeto sendo descartado. Se preferir, você pode usar uma ferramenta especializada de despejo e importação que pode despejar automaticamente várias tabelas em paralelo, como mydumper.

  2. Execute uma sessão mysql separada para cada arquivo de dados, conectando-se ao endpoint de instância apropriado que manipula o objeto de esquema correspondente. Novamente, se preferir, você pode usar um comando especializado de importação paralela, como myloader.

  3. Execute as sessões de importação em paralelo nas instâncias de banco de dados no cluster de vários mestres, em vez de esperar que cada uma termine antes de iniciar a próxima.

Você pode usar as seguintes técnicas para importar dados para um cluster de vários mestres do Aurora:

  • É possível importar despejos lógicos (formato SQL) de outros servidores compatíveis com o MySQL para clusters de vários mestres do Aurora, se as instruções não usarem nenhum recurso que não seja compatível com o Aurora. Por exemplo, um despejo lógico de uma tabela contendo índices de pesquisa de texto completo (Full-Text Search, FTS) do MySQL não funciona porque o recurso de FTS não é compatível com clusters de vários mestres.

  • Você pode usar serviços gerenciados, como o DMS, para migrar dados para um cluster de vários mestres do Aurora.

  • Nas migrações para um cluster de vários mestres do Aurora usando um servidor que não é compatível com o MySQL, siga as instruções existentes para migrações do Aurora heterogêneas.

  • Os clusters de vários mestres do Aurora podem produzir despejos lógicos compatíveis com o MySQL no formato SQL. Qualquer ferramenta de migração (por exemplo, o AWS DMS) que possa compreender esse formato pode consumir despejos de dados dos clusters de vários mestres do Aurora.

  • O Aurora não é compatível com o log binário usando o cluster de vários mestres como mestre ou operador do log binário. Você não pode usar ferramentas de CDC baseadas em log binário com clusters de vários mestres.

  • Ao migrar usando servidores não compatíveis com o MySQL, você pode replicar em um cluster de vários mestres usando o recurso de captura de dados de alteração (CDC) contínua do AWS DMS. Como esse tipo de replicação transmite instruções SQL para o cluster de destino, a restrição na replicação de log binário não se aplica.

Para ver uma discussão detalhada sobre as técnicas e recomendações de migração, consulte o whitepaper da AWS Amazon Aurora migration handbook (Guia de migração do Amazon Aurora) Alguns dos métodos de migração listados no manual podem não se aplicar aos clusters de vários mestres do Aurora, mas o documento é uma ótima fonte geral de conhecimento sobre os tópicos de migração do Aurora.

Como exportar dados de um cluster de vários mestres

É possível salvar um snapshot de um cluster de vários mestres e restaurá-lo em outro cluster de vários mestres. Atualmente, não é possível restaurar um snapshot de cluster de vários mestres em um cluster de mestre único.

Para migrar dados de um cluster de vários mestres para um cluster de mestre único, use um despejo lógico e restaure com uma ferramenta como mysqldump.

Você não pode usar um cluster de vários mestres como a origem ou o destino da replicação de log binário.

Considerações sobre alta disponibilidade para clusters de vários mestres do Aurora

Em um cluster de vários mestres do Aurora, qualquer instância de banco de dados pode ser reiniciada sem que nenhuma outra instância seja reiniciada. Esse comportamento fornece um nível mais alto de disponibilidade para conexões de leitura/gravação e somente leitura que o de clusters de mestre único do Aurora. Chamamos esse nível de disponibilidade como disponibilidade contínua. Em clusters de vários mestres, não há tempo de inatividade para a disponibilidade de gravação quando uma instância de banco de dados do gravador falha. Clusters de vários mestres não usam o mecanismo de failover, porque todas as instâncias do cluster são graváveis. Se uma instância de banco de dados falhar em um cluster de vários mestres, sua aplicação poderá redirecionar a workload para as instâncias íntegras restantes.

Em um cluster de mestre único, a reinicialização da instância primária torna as operações de gravação indisponíveis até que o mecanismo de failover promova uma nova instância primária. As operações somente leitura também sofrem um breve tempo de inatividade porque todas as réplicas do Aurora no cluster são reiniciadas.

Para minimizar o tempo de inatividade das aplicações em um cluster de vários mestres, implemente verificações de integridade frequentes no nível de SQL. Se uma instância de banco de dados em um cluster de vários mestres ficar indisponível, você poderá decidir o que fazer com base na duração esperada da interrupção e na urgência das operações de gravação na workload. Se a sua expectativa é que a interrupção seja breve e as operações de gravação não sejam urgentes, aguarde a recuperação da instância de banco de dados antes de retomar a workload geralmente tratada por essa instância de banco de dados. Como alternativa, você pode redirecionar essa workload para uma instância de banco de dados diferente. Os dados subjacentes permanecem disponíveis a todo momento para todas as instâncias de banco de dados no cluster. O volume de armazenamento altamente distribuído do Aurora mantém os dados continuamente disponíveis, mesmo no caso improvável de uma falha afetar um AZ inteiro. Para obter informações sobre as considerações de prazo para alternar as operações de gravação de uma instância de banco de dados indisponível, consulte Como usar um cluster de vários mestres como uma espera ativa.

Replicação entre clusters de vários mestres e outros clusters

Os clusters de vários mestres não permitem a replicação de log binário de entrada ou saída.

Como atualizar um cluster de vários mestres

Os clusters de vários mestres do Aurora usam o mesmo esquema de numeração de versão, com números de versão principais e secundários, como outros tipos de clusters do Aurora. Contudo, a configuração Enable auto minor version upgrade (Habilitar atualização de versão secundária automática) não se aplica a clusters de vários mestres.

Quando você atualiza um cluster de vários mestres do Aurora, o procedimento de atualização costuma transferir o mecanismo do banco de dados da versão atual para a próxima versão posterior. Se você atualizar para uma versão do Aurora que aumenta o número da versão em mais de um, a atualização usa uma abordagem de várias etapas. Cada instância de banco de dados é atualizada para a próxima versão posterior, depois para a próxima e assim por diante até atingir a versão de atualização especificada.

A abordagem é diferente, dependendo de haver alterações incompatíveis com versões anteriores e antigas. Por exemplo, as atualizações no esquema do sistema são consideradas alterações incompatíveis com versões anteriores. Você pode verificar se uma versão específica contém alterações incompatíveis com versões anteriores consultando as notas de release.

Se não houver alterações incompatíveis entre as versões antiga e nova, cada instância de banco de dados será atualizada e reiniciada individualmente. As atualizações são alternadas para que o cluster geral não tenha nenhum tempo de inatividade. Pelo menos uma instância de banco de dados fica disponível a qualquer momento durante o processo de atualização.

Caso haja alterações incompatíveis entre as versões antiga e nova, o Aurora executa a atualização no modo offline. Todos os nós do cluster são atualizados e reiniciados ao mesmo tempo. O cluster apresenta algum tempo de inatividade, para evitar que um mecanismo mais antigo grave em tabelas de sistema mais recentes.

A aplicação de patches com tempo de inatividade zero (ZDP) não é compatível com clusters de vários mestres do Aurora.

Considerações sobre aplicações para clusters de vários mestres do Aurora

A seguir, você entenderá as alterações necessárias em suas aplicação por causa de diferenças no suporte de recursos ou comportamento entre clusters de vários mestres e mestre único.

Considerações sobre SQL para clusters de vários mestres

Veja a seguir as principais limitações que se aplicam aos recursos da linguagem SQL que você pode usar com um cluster de vários mestres:

  • Em um cluster de vários mestres, você não pode usar determinadas configurações ou tipos de coluna que alteram o layout da linha. Você não pode habilitar a opção de configuração innodb_large_prefix. Você não pode usar os tipos de coluna MEDIUMTEXT, MEDIUMBLOB, LONGTEXT ou LONGBLOB.

  • Você não pode usar a cláusula CASCADE com nenhuma coluna de chave estrangeira em um cluster de vários mestres.

  • Os clusters de vários mestres não podem conter nenhuma tabela com índices de pesquisa de texto completo (FTS). Essas tabelas não podem ser criadas ou importadas em clusters de vários mestres.

  • A DDL funciona de forma diferente em clusters de vários mestres e mestre único. Por exemplo, o mecanismo de DDL rápido não está disponível para clusters de vários mestres. Não é possível gravar em uma tabela de um cluster de vários mestres enquanto a tabela está passando por DDL. Para obter detalhes completos sobre diferenças de DDL, consulte Como executar operações de DDL em um cluster de vários mestres.

  • Não é possível usar o nível de isolamento da transação SERIALIZABLE em clusters de vários mestres. Nos clusters de mestre único do Aurora, você pode usar esse nível de isolamento na instância primária.

  • As colunas de incremento automático são processadas usando os parâmetros auto_increment_increment e auto_increment_offset. Os valores dos parâmetros são predeterminados e não configuráveis. O parâmetro auto_increment_increment é definido como 16, que é o número máximo de instâncias em qualquer cluster do Aurora. Contudo, no momento, os clusters de vários mestres têm um limite inferior no número de instâncias do banco de dados. Para obter mais detalhes, consulte Como usar colunas de incremento automático.

Ao adaptar uma aplicação para um cluster de vários mestres do Aurora, aborde essa atividade da mesma forma que uma migração. Talvez você tenha que parar de usar determinados recursos do SQL e alterar a lógica da aplicação para outros recursos do SQL:

  • Em suas instruções CREATE TABLE, altere qualquer coluna definida como MEDIUMTEXT, MEDIUMBLOB, LONGTEXT ou LONGBLOB para tipos mais curtos que não requeiram armazenamento fora da página.

  • Em suas instruções CREATE TABLE, remova a cláusula CASCADE de qualquer declaração de chave externa. Adicione a lógica da aplicação, se necessário, para emular os efeitos CASCADE por meio de instruções INSERT ou DELETE.

  • Remova qualquer uso dos índices de pesquisa de texto completo (FTS) do InnoDB. Verifique o código-fonte dos operadores MATCH() nas instruções SELECT e nas palavras-chave FULLTEXT nas instruções DDL. Verifique se algum nome de tabela na tabela do sistema INFORMATION_SCHEMA.INNODB_SYS_TABLES contém a string FTS_.

  • Verifique a frequência das operações de DDL, como CREATE TABLE e DROP TABLE em sua aplicação. Como as operações DDL têm mais sobrecarga nos clusters de vários mestres, evite executar muitas instruções DDL pequenas. Por exemplo, procure oportunidades para criar tabelas necessárias com antecedência. Para obter informações sobre diferenças de DDL com clusters de vários mestres, consulte Como executar operações de DDL em um cluster de vários mestres.

  • Examine seu uso de colunas de incremento automático. As sequências de valores para colunas de incremento automático são diferentes para clusters de vários mestres que outros tipos de clusters do Aurora. Verifique a palavra-chave AUTO_INCREMENT nas instruções DDL, o nome da função last_insert_id() nas instruções SELECT e o nome innodb_autoinc_lock_mode nas configurações personalizadas. Para obter detalhes sobre as diferenças e como tratá-las, consulte Como usar colunas de incremento automático.

  • Verifique seu código para a palavra-chave SERIALIZABLE. Não é possível usar esse nível de isolamento de transação com um cluster de vários mestres.

Gerenciamento de conexão para clusters de vários mestres

A principal consideração de conectividade para clusters de vários mestres é o número e o tipo de endpoints do DNS disponíveis. Com clusters de vários mestres, você geralmente usa os endpoints da instância, que raramente são usados em outros tipos de clusters do Aurora.

Os clusters de vários mestres do Aurora possuem os seguintes tipos de endpoints:

Endpoint do cluster

Esse tipo de endpoint sempre indica uma instância de banco de dados com capacidade de leitura/gravação. Todos os clusters de vários mestres possuem um endpoint de cluster.

Como as aplicações em clusters de vários mestres geralmente incluem a lógica para gerenciar conexões com instâncias de banco de dados específicas, raramente é necessário usar esse endpoint. É mais útil para se conectar a um cluster de vários mestres para realizar a administração.

Você também pode se conectar a esse endpoint para examinar a topologia do cluster quando não souber o status das instâncias de banco de dados no cluster. Para saber mais sobre esse procedimento, consulte Como descrever a topologia do cluster.

Endpoint da instância de banco de dados

Esse tipo de endpoint se conecta a instâncias de banco de dados nomeadas específicas. Para clusters de vários mestres do Aurora, sua aplicação geralmente usa os endpoints da instância de banco de dados para todas ou quase todas as conexões. Você decide qual instância de banco de dados usar em cada instrução SQL com base no mapeamento entre seus fragmentos e as instâncias de banco de dados no cluster. Cada instância do banco de dados possui um desses endpoints. Assim, o cluster de vários mestres possui um ou mais desses endpoints, e o número muda à medida que as instâncias de banco de dados são adicionadas ou removidas de um cluster de vários mestres.

A maneira como você usa endpoints de instância de banco de dados é diferente entre clusters de mestre único e vários mestres. Em clusters de mestre único, você geralmente não usa esse endpoint com frequência.

Endpoint personalizado

Esse tipo de endpoint é opcional. Você pode criar um ou mais endpoints personalizados para agrupar instâncias de banco de dados para uma finalidade específica. Quando você se conecta ao endpoint, o Aurora retorna o endereço IP de uma instância de banco de dados diferente a cada vez. Em clusters de vários mestres, você geralmente usa endpoints personalizados para designar um conjunto de instâncias de banco de dados a serem usadas principalmente em operações de leitura. Recomendamos que você não use endpoints personalizados com clusters de vários mestres para realizar o balanceamento de carga de operações de gravação, pois isso aumenta a chance de conflitos de gravação.

Clusters de vários mestres não possuem endpoints de leitores. Quando for possível, emita consultas SELECT usando o mesmo endpoint da instância de banco de dados que geralmente é gravado na mesma tabela. Isso permite o uso mais efetivo dos dados em cache do grupo de buffer e evita possíveis problemas com dados obsoletos por causa do atraso de replicação dentro do cluster. Se você não localizar instruções SELECT nas mesmas instâncias de banco de dados que são gravados nas mesmas tabelas e precisar de uma leitura estrita após a garantia de gravação para determinadas consultas, considere a execução dessas consultas usando o mecanismo global de leitura após gravação (GRAW) descrito em Modelo de consistência para clusters de vários mestres.

Para conhecer as práticas gerais recomendadas do Aurora e do gerenciamento de conexão do MySQL, consulte o whitepaper Amazon Aurora migration handbook (Guia de migração do Amazon Aurora) da AWS.

Para obter informações sobre como emular instâncias de banco de dados somente leitura em clusters de banco de dados de vários mestres, consulte Como usar o modo somente leitura da instância.

Siga estas diretrizes ao criar endpoints DNS personalizados e criar drivers e conectores para clusters de vários mestres do Aurora:

  • Para instruções DDL, DML e DCL, não use endpoints nem técnicas de roteamento de conexão que operem em modo de ida e volta ou aleatório.

  • Evite consultas de gravação de longa execução e transações de gravação longas, a menos que seja garantido que essas transações não entrem em conflito com outro tráfego de gravação no cluster.

  • Prefira usar transações confirmadas automaticamente. Quando for possível, evite configurações autocommit=0 no nível global ou de sessão. Ao usar um conector de banco de dados ou uma estrutura de banco de dados na sua linguagem de programação, verifique se autocommit está ativado para aplicações que usam o conector ou a estrutura. Se necessário, adicione instruções COMMIT em pontos lógicos em todo o seu código para garantir que as transações sejam breves.

  • Quando a consistência de leitura global ou a garantia de leitura após gravação for necessária, siga as recomendações para leitura após gravação (GRAW) global descritas em Modelo de consistência para clusters de vários mestres.

  • Use o endpoint do cluster para instruções DDL e DCL quando possível. O endpoint do cluster ajuda a minimizar a dependência dos nomes de host das instâncias de banco de dados individuais. Você não precisa dividir as instruções DDL e DCL por tabela ou banco de dados, como nas instruções DML.

Modelo de consistência para clusters de vários mestres

Os clusters de vários mestres do Aurora permitem um modo de leitura após gravação global (GRAW) que é configurável no nível da sessão. Essa configuração apresenta sincronização extra para criar uma visualização de leitura consistente para cada consulta. Dessa forma, as consultas sempre veem os dados mais recentes. Por padrão, o atraso de replicação em um cluster de vários mestres significa que uma instância de banco de dados pode ver dados antigos por alguns milissegundos após a atualização dos dados. Habilite esse recurso se sua aplicação depender de consultas que vejam as alterações de dados mais recentes feitas por qualquer outra instância de banco de dados, mesmo que a consulta tenha que esperar como resultado.

nota

O atraso de replicação não afeta os resultados da consulta se você gravar e ler os dados usando a mesma instância de banco de dados. Assim, o recurso GRAW se aplica principalmente a aplicações que emitem várias operações de gravação simultâneas por meio de diferentes instâncias de banco de dados.

Ao usar o modo GRAW, não o habilite em todas as consultas por padrão. Leituras globalmente consistentes são visivelmente mais lentas que as leituras locais. Sendo assim, use o GRAW seletivamente para consultas que o requeiram.

Esteja ciente dessas considerações ao usar o GRAW:

  • O GRAW envolve sobrecarga de desempenho por causa do custo de estabelecer uma visualização de leitura consistente em todo o cluster. A transação deve primeiro determinar um ponto no tempo consistente em todo o cluster, e a replicação deve chegar a esse ponto. O atraso total depende da workload, mas costuma estar no intervalo de dezenas de milissegundos.

  • Você não pode alterar o modo GRAW dentro de uma transação.

  • Ao usar o GRAW sem transações explícitas, cada consulta individual incorre na sobrecarga de desempenho ao estabelecer uma visualização de leitura globalmente consistente.

  • Com o GRAW habilitado, a penalidade de desempenho se aplica a leituras e gravações.

  • Ao usar o GRAW em transações explícitas, a sobrecarga de estabelecer uma visão globalmente consistente se aplica uma vez para cada transação, quando a transação é iniciada. Consultas executadas posteriormente na transação são tão rápidas como se fossem executadas sem GRAW. Se várias instruções sucessivas puderem usar a mesma visualização de leitura, você poderá incluí-las em uma única transação para um melhor desempenho geral. Dessa forma, a penalidade é paga apenas uma vez por transação, em vez de por consulta.

Transações e clusters de vários mestres

A orientação padrão do Aurora MySQL se aplica aos clusters de vários mestres do Aurora. O mecanismo de banco de dados do Aurora MySQL é otimizado para instruções SQL de curta duração. Esses são os tipos de instruções geralmente associadas às aplicações de processamento de transações on-line (online transaction processing, OLTP).

Em particular, encurte suas transações de gravação o máximo possível. Isso reduz a janela de oportunidade para conflitos de gravação. O mecanismo de resolução de conflitos é otimista, ou seja, ele funciona melhor quando conflitos de gravação são raros. A desvantagem é que a ocorrência de conflitos resulta em sobrecargas substanciais.

Há determinadas cargas de trabalho que se beneficiam com grandes transações. Por exemplo, as importações de dados em massa são significativamente mais rápidas quando executadas por meio de transações de vários megabytes, em vez de transações com instruções únicas. Se você observar um número inaceitável de conflitos durante a execução de tais cargas de trabalho, considere as seguintes opções:

  • Reduza o tamanho da transação.

  • Reprograme ou reorganize os trabalhos em lote para que eles não se sobreponham e não provoquem conflitos com outras cargas de trabalho. Se possível, reprograme os trabalhos em lote para que eles sejam executados fora do horário de pico.

  • Refatore os trabalhos em lote para que eles sejam executados na mesma instância do gravador que as outras transações que causam conflitos. Quando transações conflitantes são executadas na mesma instância, o mecanismo transacional gerencia o acesso às linhas. Nesse caso, não ocorrem conflitos de gravação no nível de armazenamento.

Conflitos de gravação e deadlocks em clusters de vários mestres

Um aspecto de desempenho importante para clusters de vários mestres é a frequência de conflitos de gravação. Quando esse problema ocorre no subsistema de armazenamento do Aurora, sua aplicação recebe um erro de deadlock e executa o tratamento de erro usual para condições de deadlock. O Aurora usa um algoritmo otimista sem bloqueio que tem melhor performance quando esse conflitos são raros.

Em um cluster de vários mestres, todas as instâncias de banco de dados podem ser gravadas no volume de armazenamento compartilhado. Para cada página de dados que você modifica, o Aurora distribui automaticamente várias cópias em várias zonas de disponibilidade (AZs). Um conflito de gravação pode ocorrer quando várias instâncias do banco de dados tentam modificar a mesma página de dados em um tempo muito curto. O subsistema de armazenamento do Aurora detecta que as mudanças se sobrepõem e executam resolução de conflitos antes de finalizar a operação de gravação.

O Aurora detecta conflitos de gravação no nível das páginas de dados físicos, que têm um tamanho fixo de 16 KiB. Assim, um conflito pode ocorrer mesmo para alterações que afetam linhas diferentes, se as linhas estiverem na mesma página de dados.

Quando ocorrem conflitos, a operação de limpeza requer trabalho extra para desfazer as alterações de uma das instâncias do banco de dados. Da perspectiva da aplicação, a transação que causou o conflito encontra um deadlock e o Aurora reverte toda a transação. Sua aplicação recebe o código de erro 1213.

Desfazer a transação pode requerer a modificação de muitas outras páginas de dados cujas alterações já foram aplicadas ao subsistema de armazenamento do Aurora. Dependendo da quantidade de dados alterados pela transação, desfazer isso pode levar a uma sobrecarga substancial. Portanto, minimizar o potencial de conflitos de gravação é uma consideração de design essencial para um cluster de vários mestres do Aurora.

Alguns conflitos resultam de alterações que você inicia. Essas alterações incluem instruções SQL, transações e reversões de transação. Você pode minimizar esses tipos de conflitos por meio do design do esquema e da lógica de gerenciamento de conexão em sua aplicação.

Outros conflitos ocorrem por causa de alterações simultâneas em uma instrução SQL e em um thread interno do servidor. Esses conflitos são difíceis de prever porque dependem da atividade interna do servidor da qual você talvez não esteja ciente. Os dois principais tipos de atividade interna que causam esses conflitos são a coleta de lixo (conhecida como limpeza [purge]) e as reversões de transação executadas automaticamente pelo Aurora. Por exemplo, o Aurora executa reversões automaticamente durante a recuperação de falhas ou se uma conexão do cliente for perdida.

Uma reversão de transação reverte fisicamente as alterações de página que já foram feitas. Uma reversão produz alterações de página exatamente como a transação original faz. Uma reversão leva tempo, tanto quanto a transação original. Durante a reversão, as alterações produzidas podem entrar em conflito com suas transações.

A coleta de lixo tem a ver com o controle de concorrência multiversão (MVCC), que é o método de controle de concorrência usado pelo mecanismo transacional do Aurora MySQL. Com o MVCC, as mutações de dados criam versões de linha e o banco de dados mantém várias versões de linhas para obter isolamento de transação, permitindo acesso simultâneo aos dados. As versões de linha são removidas (limpas [purged]) quando não são mais necessárias. Aqui, outra vez, o processo de limpeza produz alterações de página, que podem entrar em conflito com suas transações. Dependendo da workload, o banco de dados pode desenvolver um atraso de limpeza: uma fila de alterações aguardando coleta de lixo. Se o atraso aumentar substancialmente, pode ser que o banco de dados precise de um tempo considerável para concluir a limpeza, mesmo se você interromper o envio de instruções SQL.

Se um thread interno do servidor encontrar um conflito de gravação, o Aurora tentará novamente de forma automática. Entretanto, sua aplicação deve manipular a lógica de repetição para quaisquer transações que encontrem conflitos.

Quando várias transações da mesma instância de banco de dados causam esses tipos de sobreposição de alterações, o Aurora usa as regras de concorrência de transação padrão. Por exemplo, se duas transações na mesma instância de banco de dados modificarem a mesma linha, uma delas aguardará. Se a espera for maior que o tempo limite configurado (innodb_lock_wait_timeout, por padrão, 50 segundos), a transação em espera será interrompida com uma mensagem "Lock wait timeout exceeded" (Tempo limite de espera de bloqueio excedido).

Clusters de vários mestres e leituras de bloqueio

Os clusters de vários mestres do Aurora permitem leituras de bloqueio nos seguintes formulários. 

SELECT ... FOR UPDATE
SELECT ... LOCK IN SHARE MODE

Para obter mais informações sobre leituras de bloqueio, consulte o Guia de referência do MySQL.

As operações de leitura de bloqueio recebem suporte em todos os nós, mas o escopo de bloqueio é local para o nó no qual o comando foi executado. Uma leitura de bloqueio executada em um gravador não impede que outros gravadores acessem ou modifiquem as linhas bloqueadas. Apesar dessa limitação, você ainda pode trabalhar com leituras de bloqueio em casos de uso que garantem a separação estrita do escopo da workload entre os gravadores, como em bancos de dados compartilhados ou com vários locatários.

Considere as seguintes diretrizes:

  • Lembre-se de que um nó sempre pode ver suas próprias alterações imediatamente e sem atraso. Quando possível, você pode colocar leituras e gravações no mesmo nó para eliminar o requisito de GRAW.

  • Se as consultas somente leitura tiverem que ser executadas com resultados globalmente consistentes, use GRAW.

  • Se as consultas somente leitura se preocuparem com a visibilidade dos dados, mas não com a consistência global, use GRAW ou apresente uma espera cronometrada antes de cada leitura. Por exemplo, um único encadeamento de aplicação pode manter conexões C1 e C2 em dois nós diferentes. A aplicação é gravada em C1 e lido em C2. Nesse caso, a aplicação pode emitir uma leitura imediatamente usando GRAW ou pode ficar suspensa antes de emitir uma leitura. O tempo de suspensão deve ser igual ou maior que o atraso de replicação (normalmente, aproximadamente 20–30 ms).

O recurso de leitura após gravação é controlado usando a variável de sessão aurora_mm_session_consistency_level. Os valores válidos são INSTANCE_RAW para o modo de consistência local (padrão) e REGIONAL_RAW para a consistência em todo o cluster:

Como executar operações de DDL em um cluster de vários mestres

As instruções Data Definition Language (DDL) do SQL têm considerações especiais para clusters de vários mestres. Às vezes, essas instruções causam uma reorganização substancial dos dados subjacentes. Essas mudanças de grande escala afetam potencialmente muitas páginas de dados no volume de armazenamento compartilhado. As definições de tabelas e outros objetos de esquema são mantidas nas tabelas INFORMATION_SCHEMA. O Aurora manipula as alterações nessas tabelas principalmente para evitar conflitos de gravação quando várias instâncias de banco de dados executam instruções DDL ao mesmo tempo.

Para instruções DDL, o Aurora delega automaticamente o processamento de instrução para um processo especial do servidor no cluster. Como o Aurora centraliza as alterações nas tabelas INFORMATION_SCHEMA, esse mecanismo evita o potencial de conflitos de gravação entre instruções DDL.

As operações de DDL impedem gravações simultâneas nessa tabela. Durante uma operação de DDL em uma tabela, todas as instâncias de banco de dados no cluster de vários mestres são limitadas ao acesso somente leitura a essa tabela até que a instrução DDL seja concluída.

Os seguintes comportamentos de DDL são os mesmos em clusters de mestre único e vários mestres do Aurora:

  • Uma DDL executada em uma instância de banco de dados faz com que outras instâncias encerrem qualquer conexão ativamente usando a tabela.

  • Tabelas temporárias no nível da sessão podem ser criadas em qualquer nó usando os mecanismos de armazenamento MyISAM ou MEMORY.

  • As operações de DDL em tabelas muito grandes podem falhar se a instância de banco de dados não tiver armazenamento temporário local suficiente.

Observe as seguintes considerações de desempenho de DDL em clusters de vários mestres:

  • Tente evitar emitir um grande número de instruções DDL curtas em sua aplicação. Crie bancos de dados, tabelas, partições, colunas e assim por diante, com antecedência, quando possível. A sobrecarga de replicação pode impor uma sobrecarga significativa de desempenho para instruções DDL simples que são geralmente muito rápidas. A instrução não é concluída até que as alterações sejam replicadas em todas as instâncias do banco de dados no cluster. Por exemplo, clusters de vários mestres demoram mais que outros clusters do Aurora para criar tabelas vazias, descartar tabelas ou descartar esquemas contendo muitas tabelas.

    Se você precisar executar um grande conjunto de operações de DDL, poderá reduzir a sobrecarga de rede e coordenação, emitindo as instruções em paralelo por meio de vários threads.

  • Instruções DDL de longa duração são menos afetadas, pois o atraso de replicação é apenas uma pequena fração do tempo total da instrução DDL.

  • O desempenho de DDLs em tabelas temporárias em nível de sessão deve ser aproximadamente equivalente em clusters do Aurora de mestre único e vários mestres. Operações em tabelas temporárias acontecem localmente e não estão sujeitas a sobrecarga de replicação síncrona.

Como usar a alteração de esquema on-line do Percona com clusters de vários mestres

A ferramenta pt-online-schema-change trabalha com clusters de vários mestres. Você pode usá-la caso a prioridade seja executar modificações de tabela da forma com menos bloqueio. Contudo, esteja ciente das implicações de conflito de gravação do processo de mudança de esquema.

Em um nível alto, a ferramenta pt-online-schema-change funciona da seguinte maneira:

  1. Cria uma tabela vazia com a estrutura desejada.

  2. Cria os gatilhos DELETE, INSERT e UPDATE na tabela original para refazer qualquer alteração de dados na tabela original na parte superior da nova tabela.

  3. Move as linhas existentes para a nova tabela usando pequenos trechos enquanto as alterações da tabela em andamento são tratadas automaticamente por meio dos gatilhos.

  4. Após a remoção de todos os dados, ela descarta os gatilhos e alterna as tabelas renomeando-os.

O possível ponto de contenção ocorre enquanto os dados estão sendo transferidos para a nova tabela. Quando a nova tabela é criada no início, ela fica completamente vazia e, portanto, pode se tornar um hotpoint de bloqueio. O mesmo se aplica a outros tipos de sistemas de banco de dados. Como os gatilhos são síncronos, o impacto do hotpoint pode se propagar de volta para suas consultas.

Nos clusters de vários mestres, o impacto pode ser mais visível. Essa visibilidade se dá porque a nova tabela não somente provoca a contenção de bloqueios, como também aumenta a probabilidade de conflitos de gravação. A princípio, a tabela tem poucas páginas, o que significa que as gravações são altamente localizadas e, portanto, propensas a conflitos. Após o aumento da tabela, as gravações devem se propagar e os conflitos de gravação não devem mais ser um problema.

Você pode usar a ferramenta de mudança de esquema on-line com clusters de vários mestres. No entanto, isso pode exigir testes mais cuidadosos e seus efeitos na workload em andamento podem ficar um pouco mais visíveis nos primeiros minutos da operação.

Como usar colunas de incremento automático

Os clusters de vários mestres do Aurora manipulam colunas de incremento automático usando os parâmetros de configuração existentes auto_increment_increment e auto_increment_offset. Para obter mais informações, consulte o Guia de referência do MySQL.

Os valores dos parâmetros são predeterminados e você não pode alterá-los. Especificamente, o parâmetro auto_increment_increment é codificado para 16, que é o número máximo de instâncias de banco de dados em qualquer tipo de cluster do Aurora.

Por causa da configuração de incremento codificada, os valores de incremento automático são consumidos muito mais rapidamente que nos clusters de mestre único. Isso é verdade mesmo que uma determinada tabela seja modificada apenas por uma única instância do banco de dados. Para obter melhores resultados, sempre use um tipo de dados BIGINT em vez de INT para suas colunas de incremento automático.

Em um cluster de vários mestres, a lógica da aplicação deve estar preparada para tolerar as colunas de incremento automático que possuem as seguintes propriedades:

  • Os valores são não contíguos.

  • Os valores podem não começar de 1 em uma tabela vazia.

  • Os valores aumentam em incrementos maiores que 1.

  • Os valores são consumidos de forma significativamente mais rápida que em um cluster de mestre único.

O exemplo a seguir mostra como a sequência de valores de incremento automático em um cluster de vários mestres pode ser diferente do esperado. 


mysql> create table autoinc (id bigint not null auto_increment, s varchar(64), primary key (id));

mysql> insert into autoinc (s) values ('row 1'), ('row 2'), ('row 3');
Query OK, 3 rows affected (0.02 sec)

mysql> select * from autoinc order by id;
+----+-------+
| id | s     |
+----+-------+
|  2 | row 1 |
| 18 | row 2 |
| 34 | row 3 |
+----+-------+
3 rows in set (0.00 sec)

É possível alterar a propriedade da tabela AUTO_INCREMENT. Usar um valor não padrão só funciona de forma confiável se esse valor for maior que qualquer um dos valores de chave primária já existentes na tabela. Você não pode usar valores menores para preencher um intervalo vazio na tabela. Caso isso seja feito, a alteração entrará em vigor temporariamente ou não. Esse comportamento é herdado do MySQL 5.6 e não é específico da implementação do Aurora.

Referência de recurso de clusters de vários mestres

A seguir, você poderá encontrar uma referência rápida dos comandos, procedimentos e variáveis de status específicas dos clusters de vários mestres do Aurora.

Como usar a leitura após gravação

O recurso de leitura após gravação é controlado usando a variável de sessão aurora_mm_session_consistency_level. Os valores válidos são INSTANCE_RAW para o modo de consistência local (padrão) e REGIONAL_RAW para a consistência em todo o cluster.

Veja a seguir um exemplo. 

mysql> select @@aurora_mm_session_consistency_level;
+---------------------------------------+
| @@aurora_mm_session_consistency_level |
+---------------------------------------+
| INSTANCE_RAW                          |
+---------------------------------------+
1 row in set (0.01 sec)
mysql> set session aurora_mm_session_consistency_level = 'REGIONAL_RAW';
Query OK, 0 rows affected (0.00 sec)
mysql> select @@aurora_mm_session_consistency_level;
+---------------------------------------+
| @@aurora_mm_session_consistency_level |
+---------------------------------------+
| REGIONAL_RAW                          |
+---------------------------------------+
1 row in set (0.03 sec)

Como verificar o modo de leitura/gravação da instância de banco de dados

Nos clusters de vários mestres, todos os nós operam no modo de leitura/gravação. A variável innodb_read_only sempre retorna zero. O exemplo a seguir mostra que, quando você se conecta a qualquer instância de banco de dados em um cluster de vários mestres, a instância de banco de dados relata que possui capacidade de leitura/gravação. 

$ mysql -h mysql -A -h multi-master-instance-1.example123.us-east-1.rds.amazonaws.com
mysql> select @@innodb_read_only;
+--------------------+
| @@innodb_read_only |
+--------------------+
|                  0 |
+--------------------+
mysql> quit;
Bye

$ mysql -h mysql -A -h multi-master-instance-2.example123.us-east-1.rds.amazonaws.com
mysql> select @@innodb_read_only;
+--------------------+
| @@innodb_read_only |
+--------------------+
|                  0 |
+--------------------+

Como verificar o nome e a função do nó

Você pode verificar o nome da instância de banco de dados à qual está conectado atualmente usando a variável de status aurora_server_id. O exemplo a seguir mostra como. 

mysql> select @@aurora_server_id;
+----------------------+
| @@aurora_server_id   |
+----------------------+
| mmr-demo-test-mm-3-1 |
+----------------------+
1 row in set (0.00 sec)

Para localizar essas informações de todas as instâncias de banco de dados em um cluster de vários mestres, consulte Como descrever a topologia do cluster.

Como descrever a topologia do cluster

Você pode descrever a topologia do cluster de vários mestres selecionando na tabela information_schema.replica_host_status. Os clusters de vários mestres têm as seguintes diferenças dos clusters de mestre único:

  • A coluna has_primary identifica a função do nó. Em clusters de vários mestres, esse valor é verdadeiro para a instância de banco de dados que manipula todas as instruções DDL e DCL. O Aurora encaminha essas solicitações a uma das instâncias de banco de dados em um cluster de vários mestres.

  • A coluna replica_lag_in_milliseconds relata o atraso de replicação em todas as instâncias do banco de dados.

  • A coluna last_reported_status reporta o status da instância do banco de dados. Ela pode ser: Online, Recovery ou Offline.

Veja a seguir um exemplo. 

mysql> select server_id, has_primary, replica_lag_in_milliseconds, last_reported_status
    -> from information_schema.replica_host_status;
+----------------------+-------------+-----------------------------+----------------------+
| server_id            | has_primary | replica_lag_in_milliseconds | last_reported_status |
+----------------------+------------------+------------------------+----------------------+
| mmr-demo-test-mm-3-1 | true        |                      37.302 | Online               |
| mmr-demo-test-mm-3-2 | false       |                      39.907 | Online               |
+----------------------+-------------+-----------------------------+----------------------+

Como usar o modo somente leitura da instância

Nos clusters de vários mestres do Aurora, você geralmente emite instruções SELECT para a instância de banco de dados específica que executa operações de gravação nas tabelas associadas. Isso evita problemas de consistência por atraso de replicação e maximiza a reutilização de dados de tabela e índice do grupo de buffer.

Caso você precise executar uma workload de consulta intensiva em várias tabelas, poderá designar uma ou mais instâncias de banco de dados em um cluster de vários mestres como somente leitura.

Para colocar uma instância de banco de dados inteira em modo somente leitura no tempo de execução, chame o procedimento armazenado mysql.rds_set_read_only. 

mysql> select @@read_only;
+-------------+
| @@read_only |
+-------------+
|           0 |
+-------------+
1 row in set (0.00 sec)
mysql> call mysql.rds_set_read_only(1);
Query OK, 0 rows affected (0.00 sec)
mysql> select @@read_only;
+-------------+
| @@read_only |
+-------------+
|           1 |
+-------------+
1 row in set (0.00 sec)
mysql> call mysql.rds_set_read_only(0);
Query OK, 0 rows affected (0.00 sec)
mysql> select @@read_only;
+-------------+
| @@read_only |
+-------------+
|           0 |
+-------------+
1 row in set (0.00 sec)

Chamar o procedimento armazenado é equivalente a executar SET GLOBAL read_only = 0|1. Essa configuração ocorre apenas no tempo de execução e não sobrevive a uma reinicialização do mecanismo. Você pode definir permanentemente a instância de banco de dados como somente leitura definindo o parâmetro read_only como true no grupo de parâmetros da sua instância de banco de dados.

Considerações sobre performance para clusters de vários mestres do Aurora

Em clusters de mestre único e vários mestres, o mecanismo do Aurora é otimizado para cargas de trabalho de OLTP. As aplicações de OLTP consistem principalmente em transações de curta duração com consultas de acesso aleatório altamente seletivas. Você obtém o máximo de vantagem do Aurora com cargas de trabalho que executam muitas dessas operações simultaneamente.

Evite a execução constante com 100% de utilização. Isso permite que o Aurora mantenha o trabalho de manutenção interna. Para saber como medir o grau de ocupação de um cluster de vários mestres e de trabalho de manutenção necessário, consulte Como monitorar clusters de vários mestres do Aurora.

Performance de consulta para clusters de vários mestres

Os clusters de vários mestres não fornecem nós dedicados somente leitura ou endpoints de DNS somente leitura, mas é possível criar grupos de instâncias de banco de dados somente leitura e usá-los para o propósito pretendido. Para obter mais informações, consulte Como usar o modo somente leitura da instância.

Você pode usar as abordagens a seguir para otimizar a performance da consulta de um cluster de vários mestres:

  • Execute instruções SELECT na instância de banco de dados que manipula o fragmento que contém a tabela, o banco de dados ou outros objetos de esquema associados envolvidos na consulta. Essa técnica maximiza a reutilização de dados no grupo de buffer. Isso também evita que os mesmos dados sejam armazenados em cache em mais de uma instância de banco de dados. Para obter mais detalhes sobre essa técnica, consulte Como otimizar um grupo de buffer e o uso do cache de dicionário.

  • Se você precisar de isolamento de workload de leitura/gravação, designe uma ou mais instâncias de banco de dados como somente leitura, conforme descrito em Como usar o modo somente leitura da instância. Você pode direcionar sessões somente leitura para essas instâncias de banco de dados, conectando-se aos endpoints da instância correspondentes ou definindo um endpoint personalizado associado a todas as instâncias somente leitura.

  • Propague consultas somente leitura em todas as instâncias do banco de dados. Essa abordagem é a menos eficiente. Use uma das outras abordagens quando possível, especialmente ao passar da fase de desenvolvimento e teste para a produção.

Resolução de conflitos para clusters de vários mestres

Muitas práticas recomendadas para clusters de vários mestres se concentram em reduzir a chance de conflitos de gravação. Resolver conflitos de gravação envolve sobrecarga de rede. Sua aplicações também devem manipular condições de erro e tentar transações novamente. Sempre que possível, tente minimizar essas consequências indesejáveis:

  • Sempre que possível, faça todas as alterações em uma tabela específica e seus índices associados usando a mesma instância de banco de dados. Se apenas uma instância de banco de dados modificar uma página de dados, a alteração dessa página não poderá levar a qualquer conflito de gravação. Esse padrão de acesso é comum em implementações de banco de dados fragmentadas ou com vários locatários. Portanto, é relativamente fácil alternar essas implementações para usar clusters de vários mestres.

  • Um cluster de vários mestres não possui um endpoint de leitor. O endpoint de leitura equilibra as conexões de entrada, o que poupa você de ter que saber qual instância de banco de dados está manipulando uma conexão específica. Em um cluster de vários mestres, o gerenciamento de conexões envolve estar ciente de qual instância de banco de dados é usada para cada conexão. Dessa forma, as modificações em um banco de dados ou tabela específico sempre podem ser roteadas para a mesma instância de banco de dados.

  • Um conflito de gravação de uma pequena quantidade de dados (uma página de 16 KB) pode acionar uma quantidade substancial de trabalho para reverter toda a transação. Assim, o ideal é que você mantenha as transações de um cluster de vários mestres relativamente breve e pequeno. Essa prática recomendada para aplicações de OLTP é especialmente importante para clusters de vários mestres do Aurora.

Conflitos são detectados no nível da página. Um conflito pode ocorrer porque as alterações propostas de diferentes instâncias de banco de dados modificam linhas diferentes na página. Todas as alterações de página apresentadas no sistema estão sujeitas à detecção de conflitos. Essa regra se aplica independentemente de a origem ser uma transação do usuário ou um processo em segundo plano do servidor. Também se aplica se a página de dados é de uma tabela, índice secundário, espaço de desfazer e assim por diante.

Você pode dividir as operações de gravação para que cada instância de banco de dados manipule todas as operações de gravação para um conjunto de objetos de esquema. Nesse caso, todas as alterações em cada página de dados são feitas por uma instância específica.

Como otimizar um grupo de buffer e o uso do cache de dicionário

Cada instância de banco de dados em um cluster de vários mestres mantém buffers e caches separados na memória, como o grupo de buffer, o cache do manipulador de tabelas e o cache de dicionário de tabelas. Em cada instância de banco de dados, o conteúdo e a quantidade de rotatividade dos buffers e caches dependem das instruções SQL processadas por essa instância.

O uso eficiente da memória pode contribuir para a performance de clusters de vários mestres e reduzir o custo de E/S. Use um design fragmentado para separar fisicamente os dados e gravar em cada fragmento de uma instância de banco de dados específica. Isso permite realizar o mais eficiente uso do cache de buffer em cada instância do banco de dados. Tente atribuir instruções SELECT para uma tabela à mesma instância de banco de dados que executa operações de gravação para essa tabela. Isso ajuda essas consultas a reutilizar os dados armazenados em cache nessa instância de banco de dados. Se você tiver um grande número de tabelas ou partições, essa técnica também reduz o número de manipuladores de tabela exclusivos e objetos de dicionário mantidos na memória por cada instância de banco de dados.

Abordagens para os clusters de vários mestres do Aurora

Nas seções a seguir, você poderá encontrar abordagens a serem adotadas em implantações específicas que são adequadas para clusters de vários mestres. Essas abordagens incluem formas de dividir a workload para que as instâncias de banco de dados executem operações de gravação para partes dos dados que não se sobrepõem. Isso minimiza as chances de conflitos de gravação. Conflitos de gravação são o foco principal do ajuste de performance e solução de problemas para um cluster de vários mestres.

Como usar um cluster de vários mestres para um banco de dados fragmentado

A fragmentação é um tipo conhecido de design de esquema que funciona bem em clusters de vários mestres do Aurora. Em uma arquitetura fragmentada, cada instância de banco de dados é atribuída para atualizar um grupo específico de objetos de esquema. Dessa forma, várias instâncias de banco de dados podem gravar no mesmo volume de armazenamento fragmentado sem conflitos decorrentes de alterações simultâneas. Cada instância de banco de dados pode manipular operações de gravação para vários fragmentos. É possível alterar o mapeamento de instâncias de banco de dados para fragmentos a qualquer momento, atualizando a configuração da aplicação. Não é preciso reorganizar seu armazenamento de banco de dados ou reconfigurar instâncias de banco de dados ao fazer isso.

Aplicativos que usam um design de esquema fragmentado são bons candidatos para uso com clusters de vários mestres do Aurora. A forma como os dados são divididos fisicamente em um sistema particionado ajuda a evitar conflitos de gravação. Mapeie cada fragmento para um objeto de esquema, como uma partição, uma tabela ou um banco de dados. A aplicação direciona todas as operações de gravação de um fragmento específico para a instância de banco de dados apropriada.

O BYOS (Bring-your-own-shard) descreve um caso de uso em que você já possui um banco de dados fragmentado/particionado e uma aplicação capaz de acessá-lo. Os fragmentos já estão fisicamente separados. Assim, você pode mover facilmente a workload para clusters de vários mestres do Aurora sem alterar o design do esquema. O mesmo caminho de migração simples se aplica aos bancos de dados com vários locatários, em que cada locatário usa uma tabela dedicada, um conjunto de tabelas ou um banco de dados inteiro.

Mapeie fragmentos ou locatários para instâncias de banco de dados de um para um ou muitos para um. Cada instância do banco de dados manipula um ou mais fragmentos. O design fragmentado se aplica principalmente a operações de gravação. Você pode emitir consultas SELECT para qualquer fragmento de qualquer instância de banco de dados com performance equivalente.

Suponha que você tenha usado um cluster de vários mestres para uma aplicação de jogos fragmentados. Você pode distribuir o trabalho para que as atualizações do banco de dados sejam executadas por instâncias de banco de dados específicas, dependendo do nome de usuário do jogador. Sua aplicação lida com a lógica de mapear cada jogador para a instância de banco de dados apropriada e se conectar ao endpoint dessa instância. Cada instância de banco de dados pode lidar com operações de gravação para vários fragmentos. Você pode enviar consultas para qualquer instância de banco de dados, porque só podem surgir conflitos durante as operações de gravação. Você pode designar uma instância de banco de dados para executar todas as consultas do SELECT para minimizar a sobrecarga nas instâncias de banco de dados que executam operações de gravação.

Suponha que, com o tempo, um dos fragmentos se torne muito mais ativo. Para reequilibrar a workload, você pode alternar qual instância de banco de dados responsável por esse fragmento. Em um sistema que não pertence ao Aurora, talvez você tenha que mover fisicamente os dados para um servidor diferente. Com um cluster de vários mestres do Aurora, você pode realizar a fragmentação dessa forma, direcionando todas as operações de gravação do fragmento para alguma outra instância de banco de dados que tenha capacidade computacional não utilizada. O modelo de armazenamento fragmentado do Aurora evita a necessidade de reorganizar fisicamente os dados.

Como usar um cluster de vários mestres sem fragmentação

Se o design do esquema não subdividir os dados em contêineres fisicamente separados, como bancos de dados, tabelas ou partições, você ainda poderá dividir operações de gravação, como instruções DML entre as instâncias de banco de dados em um cluster de vários mestres.

Talvez você perceba alguma sobrecarga de performance, e sua aplicação pode ter que lidar com reversões de transação ocasionais quando os conflitos de gravação são tratados como condições de conflito. Conflitos de gravação são mais prováveis ​​durante operações de gravação de pequenas tabelas. Se uma tabela contiver poucas páginas de dados, as linhas de diferentes partes do intervalo de chaves primárias poderão estar na mesma página de dados. Essa sobreposição pode levar a conflitos de gravação se tais linhas forem alteradas simultaneamente por diferentes instâncias de banco de dados.

Você também deve minimizar o número de índices secundários nesse caso. Quando você faz uma alteração nas colunas indexadas em uma tabela, o Aurora torna as alterações correspondentes nos índices secundários associados. Uma alteração em um índice pode causar um conflito de gravação porque a ordem e o agrupamento das linhas é diferente entre um índice secundário e a tabela associada.

Como você ainda pode enfrentar alguns conflitos de gravação ao usar essa técnica, a Amazon recomenda usar uma abordagem diferente, se possível. Verifique se você pode usar um design de banco de dados alternativo que subdivide os dados em diferentes objetos de esquema.

Como usar um cluster de vários mestres como uma espera ativa

Uma espera ativa é uma instância de banco de dados que é mantida em sincronia com outra instância de banco de dados e está pronta para assumi-la rapidamente. Essa configuração ajuda com a alta disponibilidade em situações em que uma única instância de banco de dados pode manipular a workload completa.

É possível usar clusters de vários mestres em uma configuração de espera ativa direcionando todo o tráfego, tanto de leitura quanto de gravação, para uma única instância de banco de dados. Se essa instância de banco de dados ficar indisponível, sua aplicação deverá detectar o problema e alternar todas as conexões para uma instância de banco de dados diferente. Nesse caso, o Aurora não executará nenhum failover porque a outra instância do banco de dados já está disponível para aceitar conexões de leitura/gravação. Ao gravar somente em uma única instância de banco de dados a qualquer momento, você evita conflitos de gravação. Portanto, você não precisa ter um esquema de banco de dados fragmentado para usar clusters de vários mestres dessa maneira.

dica

Se a aplicação conseguir aceitar uma breve pausa, você precisará aguardar alguns segundos depois que a instância de banco de dados ficar indisponível para redirecionar o tráfego de gravação para outra instância. Quando uma instância se torna indisponível por causa de uma reinicialização, ela se torna disponível novamente após aproximadamente de 10 a 20 segundos. Se a instância não puder ser reiniciada rapidamente, o Aurora poderá iniciar a recuperação para essa instância. Quando uma instância é encerrada, ela executa algumas atividades de limpeza adicionais como parte do desligamento. Se você começar a gravar em uma instância diferente enquanto a instância estiver reiniciando, passando por recuperação ou sendo encerrada, poderá enfrentar conflitos de gravação. Os conflitos podem ocorrer entre instruções SQL na nova instância e operações de recuperação, como reversão e limpeza na instância reiniciada ou encerrada.