Eles podem ter mudado devido a manutenção. Há um upgrade pendente para o Aurora 1.7.1 de 2016-09-20 mostrando para um dos meus clusters Aurora agora (em 2016-10-15, SELECT @@AURORA_VERSION; mostra 1.6). Isso faria sentido se as réplicas fossem atualizadas primeiro, em seguida, um evento de failover seria acionado e, em seguida, o mestre seria atualizado, mas estou especulando - não consigo encontrar isso explicitamente declarado na documentação.
Ou pode ter havido uma falha do mestre original, que resultou em um failover seguido pela recuperação do mestre original.
De qualquer forma, você deve encontrar evidências de alguma coisa nos logs de eventos da instância, supondo que seja recente - veja "Eventos" no lado esquerdo do console do RDS.
Mas o motivo pelo qual eles mudaram e depois não voltaram é uma questão que é potencialmente mais fácil de responder - não acredito que haja uma razão para esperar que eles mudem de volta.
A qualquer momento, uma de suas instâncias é o "mestre" - mas, ao contrário da replicação nativa do MySQL / MariaDB, chamá-lo de "mestre" não é realmente preciso, porque as instâncias de um cluster Aurora compartilham Backing Store comum - eles não têm cópias individuais dos dados, todos eles estão acessando um back-end de armazenamento compartilhado e replicado. Em vez de mestre e escravos / réplicas, um deles é um escritor (pode ler e escrever) e os outros (se existirem, um único cluster "instância" é válido) são leitores (somente leitura), mas qualquer uma das instâncias pode se tornar o gravador devido a um evento de failover (que pode ser acionado por outras razões que não uma falha real). É possível priorizar as instâncias para que o failover cause uma mudança para uma instância preferida (as instâncias em um cluster Aurora não precisam ser a mesma classe de instância), mas isso só parece relevante quando o número de nós é maior que dois. / p>
Fundamentalmente, porém, o design do Aurora parece ser tal que você não deveria estar pensando em suas instâncias como se um deles específico fosse o mestre ... e a infra-estrutura fornece uma maneira de não importar.
Um cluster Aurora tem um nome de cluster atribuído por você e um identificador de cluster alfanumérico atribuído pelo sistema, e cada instância no cluster tem um nome atribuído por você.
Aurora, como é o comportamento padrão do RDS, cria um nome de host no DNS para cada instância com base no nome atribuído à instância e ao identificador de cluster, mas um cluster Aurora tem dois nomes de host adicionais criados - um que conectará você para o escritor, e outro que irá conectá-lo a um dos leitores (ou, ele também irá conectá-lo ao único membro do cluster, que é de fato o escritor, quando o cluster tem apenas um membro).
Digamos que o nome do cluster seja prod-db , digamos que o identificador atribuído ao sistema seja xyzzyexample e digamos que os nós criados por você sejam denominados node-1 e node-2 ... e a região seja us-east-1 .
Os nomes de host das instâncias são assim:
node-1.xyzzyexample.us-east-1.rds.amazonaws.com # instance 1
node-2.xyzzyexample.us-east-1.rds.amazonaws.com # instance 2
Mas os nomes de host que você deve usar para acessar o Aurora não são esses.
Os que você deve usar, a menos que tenha um motivo específico para fazer o contrário, como fixar um trabalho em uma réplica específica, fique assim:
prod-db.cluster-xyzzyexample.us-east-1.rds.amazonaws.com # writer
prod-db.cluster-ro-xyzzyexample.us-east-1.rds.amazonaws.com # reader
Eles são implementados como CNAMEs no DNS, gerenciados pelo RDS, portanto, toda vez que você se conectar, receberá uma resposta apropriada para a configuração atual do cluster. Os TTLs são 5 segundos no endereço do gravador e 1 segundo no endereço do leitor, então as chances são boas de que a resposta esteja correta. Ao usar esses endereços para se conectar, você não precisa se preocupar com as funções de troca de máquinas.