The problem is that the AWS RDS MySQL read-replica mechanism requires that the two schemas be exact.
A replicação, em geral, exige isso.
Mas, se a sua definição de "próximo o suficiente" estiver perto o suficiente, isso pode ser feito no RDS para MySQL da mesma maneira que você sempre faria.
create a DB instance ... and SET it to be the replica.
Bem, não será assim que você faz.
Não é assim que você faz isso fora do RDS. Você sempre tem que começar com uma réplica idêntica, e depois alterá-la, porque a replicação, por definição, depende de um momento específico conhecido no qual os conjuntos de dados e os esquemas são idênticos, após o que as mudanças se tornam possíveis na medida em que o MySQL realmente considera eles "perto o suficiente".
Exemplos de "perto o suficiente" podem incluir uma réplica com mais índices ou menos ... mas obviamente não são coisas como uma nova chave única ou restrição de chave estrangeira na réplica onde os dados no mestre violam a restrição ... e uma alteração de agrupamento pode fazer com que uma restrição existente seja violada sem qualquer alteração real de dados. (Ou não, se você trocou de maiúsculas e minúsculas para binário).
Adicionar tabelas à réplica é bom, não é possível descartar tabelas, e é até possível adicionar colunas ou descartar colunas de tabelas, se e somente se as colunas restantes por posição ordinal começando na primeira coluna forem idênticas. Ou seja, você pode adicionar colunas ou remover colunas da borda direita da tabela; você não pode alterar a ordem das colunas, mas pode alterar os tipos de dados se a coerção for possível, como aumentar o comprimento de um VARCHAR . Você pode renomear colunas desde que BINLOG_FORMAT no mestre esteja definido como ROW , o que geralmente será a melhor escolha ao tentar tais alterações. No caso do RDS, a única alternativa é MIXED . Eles sabiamente evitam a replicação estritamente baseada em STATEMENT . Observe que BINLOG_FORMAT na réplica é irrelevante para as conversões de escravos.
O MySQL geralmente tenta implicitamente digitar conversões durante a replicação. Veja também Replicação com diferentes definições de tabela no mestre e escravo para a perspectiva geral do MySQL sobre isso.
Você pode, de fato, se safar do que você está planejando. Se não, você deve descobrir rapidamente.
Mas pelo menos com o RDS, é fácil tentar novamente se você o quebrar ... e a integridade e o desempenho do mestre não são afetados por uma réplica quebrada.
Aqui está sua correção:
Read Replicas are designed to support read queries, but you might need occasional updates, such as adding an index to speed the specific types of queries accessing the replica. You can enable updates by setting the
read_onlyparameter to 0 in the DB parameter group for the Read Replica.http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html#USER_ReadRepl.MySQL
A menos que seja sua única réplica, copie o grupo de parâmetros para um novo, aplique-o à réplica e altere a configuração do novo grupo. Deixar outras réplicas graváveis como efeito colateral é uma receita para problemas.
Quando isso é feito e entra em vigor, a réplica é gravável. Se as alterações propostas forem de fato "próximas o suficiente", depois de fazer login na réplica diretamente, usando as mesmas credenciais que você usaria para o mestre e fazer as alterações, elas continuarão sendo replicadas.
Ou, se não, a replicação será interrompida.
Não há necessidade de pausar a replicação ao fazer alterações de esquema em uma réplica, porque o MySQL automaticamente suspende a execução de eventos de replicação usando mecanismos de bloqueio normais (como bloqueios de metadados de tabela) enquanto as operações DDL estão em andamento na réplica envolvendo objetos aos quais o próximo evento de replicação requer acesso.
A instrução SHOW SLAVE STATUS funciona de maneira idêntica ao MySQL padrão, no RDS. Se Slave_IO_Running e Slave_SQL_Running mostrarem Yes e Seconds_Behind_Master não for NULL , a réplica não será quebrada; se Seconds_Behind_Master = 0, a réplica está sincronizada em tempo real com o mestre (> 0 significa que está atrasada, tentando recuperar o atraso).
Question: would a loooonngggg change (recollating the column will take on the order of an hour) cause problems on the master? I am thinking of massively backed up replication journals, and hour of traffic blocked on a lock in the read-only replica.
Isso não será um problema com o RDS, por dois motivos.
A razão mais significativa é que a replicação do MySQL usa dois threads - um para receber os logs do master (o thread de E / S) e um para executá-los (o thread SQL) - estes são os threads cuja "execução "status que mencionei acima. Quando a réplica está bloqueando a execução de eventos, devido a alterações locais, ela continua a recebê-los. Contanto que a réplica não fique sem armazenamento, tudo continua como esperado quando os bloqueios são liberados.
Além disso, embora não seja muito significativo neste contexto, uma vez que o encadeamento de E / S continuará em execução, o RDS não usa o padrão expire_logs_days variável de sistema para limpar log binários antigos do mestre. Em vez disso, ele as remove - assim que nenhuma de suas réplicas precisar, mas não antes -, pois elas contam com a alocação de armazenamento. (Você também pode configurar o RDS para deixá-los lá por mais tempo, se desejar ). Eu parei a replicação do RDS por mais de 24 horas e reiniciei o sistema sem problemas.