Eu tenho uma instância pequena do MySQL RDS como parte do meu sistema de produção e quero atualizá-la para uma instância média com IOPS fornecido.

Como DBA da velha escola, conheço o método "adicionar escravo; promover para dominar; trocar de cliente", mas a AWS promete fornecer um caminho mágico de atualização com um clique, ou seja, "instância de atualização", "adicionar IOPS fornecidas".

Tentei isso na instância do RDS de teste, o tempo de inatividade é muito longo, IMHO: cerca de 5 minutos para pequenas -> atualizações médias e 30 minutos (!!!) para mudar para o IOPS fornecido.

• Esse comportamento é normal?
• Existe alguma maneira de executar a atualização no RDS de produção sem tempo de inatividade?
• Você recomenda "parar; criar um instantâneo; restaurar do instantâneo para uma instância maior"?

Atualizar uma instância no RDS significa que o RDS estará migrando fisicamente o banco de dados para uma nova instância, provavelmente em um host físico diferente, portanto o tempo de inatividade não seria evitável. A migração para IOPS provisionado provavelmente significaria que seus dados seriam migrados para um novo volume EBS (e o servidor também poderá ser migrado para uma nova instância com essa alteração, dependendo se, internamente, as máquinas capazes de acessar volumes EBS com IOPS provisionado são segregados fisicamente das máquinas que não são, para que possam estar em uma classe diferente de hardware de rede), para que o tempo de inatividade seja novamente inevitável.

Parece haver uma maneira de evitar essa interrupção: uma implantação Multi-AZ, que cria uma réplica invisível e inacessível (para você) em outra zona de disponibilidade na região.

No caso de atualizações do sistema, como correções do SO ou dimensionamento da instância do banco de dados, essas operações são aplicadas primeiro no modo de espera, antes do failover automático. Como resultado, seu impacto na disponibilidade é limitado apenas ao tempo necessário para a conclusão do failover automático.

^{- http://aws.amazon.com/rds/multi-az/}

Isso deve fornecer um caminho de migração rápido e contínuo, embora eu não tenha tido ocasião de testar esse recurso. "Modificar" no console aparece para permitir a conversão de uma instância em Multi-AZ. Presumivelmente, isso resultaria em um breve congelamento de E / S à medida que a instância é clonada, portanto, é claro que eu recomendaria testar toda essa funcionalidade antes de tentar.

Como alternativa, o RDS suporta um mecanismo interno que deve emular a operação "adicionar escravo; promover ao mestre; alternar clientes", e isso também deve permitir uma conversão de tempo de inatividade quase zero:

• Crie uma réplica de leitura RDS real do seu banco de dados com a classe de instância desejada
• Aguarde a réplica ficar online e ser sincronizada com o mestre
• Modifique a configuração da réplica para adicionar IOPS provisionado
• Aguarde a réplica ficar online e ser sincronizada com o mestre
• Verifique se os dois sistemas têm dados idênticos usando ferramentas de terceiros
• Desconecte seu aplicativo do antigo mestre
• Verifique as coordenadas binlog correspondentes no mestre e na réplica para garantir que todas as gravações do aplicativo sejam replicadas
• Divida os sistemas com "Promover réplica de leitura" na nova réplica no RDS
• Conecte seu aplicativo ao novo mestre

http://aws.amazon.com/about-aws/whats-new/2012/10/11/amazon-rds-mysql-rr-promotion/

Mesmo com um ambiente multi-AZ, você terá uma interrupção de 60-120s. Esse foi o caso quando eu bati repetidamente em nossas instâncias RDS enquanto realizava uma atualização de um db.m3.medium do PostgreSQL para um db.m3.large.

Também é possível evitar tempo de inatividade durante a atualização. A maneira de fazer isso é iniciando brevemente um novo RDS a partir de um instantâneo de réplica de leitura e configurando-o como replicação de mestre para mestre ativo / ativo. Depois de configurado, você pode alternar o tráfego de aplicativos em um servidor APP por vez, sem tempo de inatividade. Usamos a abordagem toda vez que a AWS anuncia manutenções do RDS para evitar tempo de inatividade e durante as manutenções programadas.

https://workmarket.tech/zero-downtime-maintenances-on-mysql-rds-ba13b51103c2

Aqui estão os detalhes:

M1 - Mestre Orignal

R1 - Leia a réplica do M1

SNAP1 - Instantâneo do R1

M2 - Novo Mestre

Sequência de criação M2: M1 → R1 → SNAP1 → M2

• Como não podemos usar o privilégio SUPER no RDS, não usamos o mysqldump com a — master_data2opção no M1. Em vez disso, lançamos o R1 para obter dele a posição no binlog do M1 . Em seguida, crie um instantâneo (SNAP1) a partir do R1 e inicie o M2 a partir do SNAP1.

• Crie dois grupos de parâmetros RDS separados com os seguintes deslocamentos para evitar conflitos de PK:

  M1: auto_increment_ increment = 4 and auto_increment_offset = 1

  M2: auto_increment_ increment = 4 and auto_increment_offset = 2

• Criar usuário de replicação no M1

  GRANT EXECUTE, REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO ‘repl’@’%’ IDENTIFIED BY PASSWORD <secret>;

1. Crie R1 a partir de M1

-- Connect to the R1 and stop replication
   CALL mysql.rds_stop_replication;
-- Obtain M1’s (!!) current binlog file and position 
        `mysql> show slave status\G
             Master_Log_File: mysql-bin.000622
             Exec_Master_Log_Pos: 9135555

2. Crie SNAP1 a partir de R1

• Crie M2 do SNAP1 com os atributos obtidos do M1

• Atribua um grupo de parâmetros a M2 com um deslocamento automático de incremento_ diferente de M1 para evitar conflitos de chave de replicação de M / M

4. Configure a replicação M / M

-- Configure M2 as a slave of M1
CALL mysql.rds_set_external_master (‘m1.xyxy24.us-east-1.rds.amazonaws.com’, 3306, ‘repl’, ‘mypassword’, ‘mysql-bin.000622, 9135555, 0);
CALL mysql.rds_start_replication;
-- Connect to M2 and obtain its current binlog file and position
         mysql> show master status\G
            File: mysql-bin.004444
            Position: 6666622
-- Connect to M1 and configure it to be a slave of the M2
CALL mysql.rds_set_external_master (‘m2.xyxy24.us-east-1.rds.amazonaws.com’, 3306 , ‘repl’, ‘mypassword’, ‘mysql-bin.004444, 6666622, 0);
CALL mysql.rds_start_replication;

5. Exclua R1 e SNAP1, pois eles não são mais necessários

6. Atualize o M2 via AWS Console

Use o procedimento padrão para modificar a instância conforme suas necessidades.

7. Execute a transição graciosa para o M2

Como a replicação M / M é configurada com sucesso, estamos prontos para continuar com a manutenção do banco de dados sem tempo de inatividade, alternando normalmente os servidores de aplicativos um por vez.

Aqui estão mais detalhes sobre como ele funciona.

https://workmarket.tech/zero-downtime-maintenances-on-mysql-rds-ba13b51103c2

Isso funcionaria, no entanto, você deve verificar se os pontos de extremidade da instância do RDS não estão configurados no seu aplicativo como uma entrada estática. Trocar RDS mudará os pontos finais.