¿Cuál es la forma óptima de actualizar la instancia de producción RDS?
33
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.
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
Michael, muchas gracias por la respuesta detallada! Vitaly
Vitaly
promocionar una réplica de lectura a master provocará tiempo de inactividad (ya que la instancia deberá informar)
Mahmoud Khateeb
@MahmoudKhateeb gracias. Eso es correcto. Aunque no hay una razón técnica por la que esto sea necesario, RDS reinicia una instancia cuando la promociona a maestro. De hecho, he aprendido mucho más sobre cómo funciona RDS en los casi 4 años (¿??) Desde que lo escribí originalmente. Haré ediciones.
Michael - sqlbot
Estoy haciendo esto en Producción el lunes, así que podría tener algunas cosas que agregar. Básicamente, cambiaré la réplica para convertirla en lectura / escritura, luego señalaré todos mis servicios y luego actualizaré el maestro.
Mahmoud Khateeb
@MahmoudKhateeb con RDS, cuando promociona una réplica, la conexión con el maestro se corta permanentemente. No puede volver a usar el viejo maestro como maestro nuevamente. La vieja réplica ahora es una maestra y debe permanecer así. Cree una réplica de la réplica existente, ahora (RDS admite cascadas) ... luego actualice la nueva réplica y la réplica anterior según sea necesario ... luego comience a usar la nueva réplica como la réplica de producción ... luego promueva su réplica original y comienza a usarlo como el nuevo maestro. Tira al viejo maestro.
Michael - sqlbot
4
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.
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.
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.
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.
fuente
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 → M2Como 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 = 1M2: auto_increment_ increment = 4 and auto_increment_offset = 2Crear usuario de replicación en M1
GRANT EXECUTE, REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO ‘repl’@’%’ IDENTIFIED BY PASSWORD <secret>;1. Crear R1 desde M1
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
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
fuente
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.
fuente