Tengo una pequeña instancia RDS de MySQL como parte de mi sistema de producción y quiero actualizarla a una instancia mediana con IOPS provisto.

Como DBA de la vieja escuela, conozco el método "agregar esclavo; promover a maestro; cambiar clientes", pero AWS promete proporcionar una ruta mágica de actualización con un clic, es decir, "instancia de actualización", "agregar IOPS provisto".

Intenté esto en la instancia de prueba de RDS, el tiempo de inactividad es demasiado largo, en mi humilde opinión: aproximadamente 5 minutos para la actualización pequeña-> media, y 30 minutos (!!!) para cambiar a IOPS proporcionados.

• ¿Es este comportamiento normal?
• ¿Hay alguna forma de ejecutar la actualización en producción RDS sin tiempo de inactividad?
• ¿Recomienda "detener; crear una instantánea; restaurar de una instantánea a una instancia de mayor tamaño"?

Actualizar una instancia en RDS significa que RDS migrará físicamente la base de datos a una nueva instancia, probablemente en un host físico diferente, por lo que el tiempo de inactividad no sería evitable. Migrar a IOPS aprovisionados probablemente significaría que sus datos se migrarían a un nuevo volumen EBS (y el servidor también podría migrarse a una nueva instancia con este cambio, dependiendo de si, internamente, las máquinas capaces de acceder a los volúmenes EBS con IOPS aprovisionado son físicamente segregado de las máquinas que no lo están, para que puedan estar en una clase diferente de hardware de red), por lo que el tiempo de inactividad volvería a ser inevitable.

Parece que hay una manera de evitar esta interrupción: una implementación Multi-AZ, que crea una réplica invisible e inaccesible (para usted) en otra zona de disponibilidad dentro de la región.

En el caso de las actualizaciones del sistema, como el parcheo del sistema operativo o el escalado de la instancia de base de datos, estas operaciones se aplican primero en el modo de espera, antes de la conmutación por error automática. Como resultado, su impacto en la disponibilidad se limita solo al tiempo requerido para que se complete la conmutación por error automática.

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

Eso debería proporcionar una ruta de migración rápida y sin problemas, aunque no he tenido la oportunidad de probar esta capacidad. "Modificar" en la consola parece permitirle convertir una instancia a Multi-AZ. Presumiblemente, esto provocaría una breve congelación de E / S a medida que se clona la instancia, por lo que, por supuesto, recomendaría probar toda esta funcionalidad antes de probarla.

Alternativamente, RDS admite un mecanismo interno que debería permitirle emular la operación "agregar esclavo; promover a maestro; cambiar clientes", y esto también debería permitirle lograr una conversión de tiempo de inactividad cercano a cero:

• Cree una réplica de lectura RDS real de su base de datos con la clase de instancia deseada
• Espere a que la réplica se conecte y se sincronice con el maestro
• Modifique la configuración de la réplica para agregar IOPS aprovisionados
• Espere a que la réplica se conecte y se sincronice con el maestro
• Verifique que ambos sistemas tengan datos idénticos utilizando herramientas de terceros
• Desconecta tu aplicación del viejo maestro
• Verifique las coordenadas de binlog coincidentes en el maestro y la réplica para asegurarse de que todas las escrituras de la aplicación se hayan replicado
• Divida los sistemas con "Promover réplica de lectura" en la nueva réplica en RDS
• Conecte su aplicación al nuevo maestro

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

Incluso con un entorno multi-AZ, tendrá una interrupción de 60 a 120 s. Este fue el caso cuando golpeé repetidamente nuestras instancias RDS mientras realizaba una actualización de un PostgreSQL db.m3.medium a un db.m3.large.

También es POSIBLE evitar cualquier tiempo de inactividad durante la actualización. La forma de hacerlo es iniciar brevemente un nuevo RDS desde una instantánea de réplica de lectura y configurarlo como replicación de maestro a maestro activo / activo. Una vez configurado, puede cambiar el tráfico de aplicaciones de un servidor de aplicaciones a la vez sin ningún tiempo de inactividad. Utilizamos el enfoque cada vez que AWS anuncia mantenimientos RDS para evitar el tiempo de inactividad, así como durante nuestros mantenimientos programados.

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

Aquí están los detalles:

M1 - Maestro original

R1 - Leer réplica del M1

SNAP1 - Instantánea del R1

M2 - Nuevo maestro

Secuencia de creación de M2: M1 → R1 → SNAP1 → M2

• Como no podemos usar el privilegio SUPER en RDS, no usamos mysqldump con la — master_data2opción en el M1. En su lugar, lanzamos R1 para obtener la posición binlog del M1 a partir de él. Luego cree una instantánea (SNAP1) desde el R1 y luego inicie M2 desde el SNAP1.

• Cree dos grupos de parámetros RDS separados con los siguientes desplazamientos para evitar conflictos PK:

  M1: auto_increment_ increment = 4 and auto_increment_offset = 1

  M2: auto_increment_ increment = 4 and auto_increment_offset = 2

• Crear usuario de replicación en M1

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

1. Crear R1 desde 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. Crear SNAP1 desde R1

• Cree M2 a partir de SNAP1 con los atributos obtenidos de M1

• Asigne un grupo de parámetros a M2 con un desplazamiento de aumento automático diferente de M1 para evitar conflictos de clave de replicación M / M

4. Configurar la replicación 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. Eliminar R1 y SNAP1 ya que ya no son necesarios

6. Actualice M2 a través de la consola de AWS

Utilice el procedimiento estándar para modificar la instancia según sus necesidades.

7. Realice la conmutación elegante a M2

A medida que la replicación M / M se configura con éxito, estamos listos para continuar con el mantenimiento de la base de datos sin tiempo de inactividad al cambiar con gracia los servidores de aplicaciones uno a la vez.

Aquí hay más detalles sobre cómo funciona.

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

Esto funcionaría, sin embargo, debe asegurarse de que los puntos finales de la instancia de RDS no estén configurados en su aplicación como una entrada estática. Intercambiar RDS cambiará los puntos finales.