¿Cómo puedo actualizar sin problemas la versión principal de una base de datos postgres de AWS RDS?

Esta mañana estuve involucrado en la actualización de una base de datos PostgreSQL en AWS RDS. Queríamos pasar de la versión 9.3.3 a la versión 9.4.4. Habíamos "probado" la actualización en una base de datos provisional, pero la base de datos provisional es mucho más pequeña y no utiliza Multi-AZ. Resultó que esta prueba era bastante inadecuada.

Nuestra base de datos de producción utiliza Multi-AZ. Hemos realizado actualizaciones menores de versiones en el pasado, y en esos casos RDS actualizará primero el modo de espera y luego lo promocionará a maestro. Por lo tanto, el único tiempo de inactividad incurrido es de ~ 60 s durante la conmutación por error.

Asumimos que sucedería lo mismo para la actualización de la versión principal, pero qué equivocados estábamos.

Algunos detalles sobre nuestra configuración:

• db.m3.large
• IOPS aprovisionados (SSD)
• 300 GB de almacenamiento, de los cuales se usan 139 GB
• Tuvimos excelentes actualizaciones del sistema operativo RDS, queríamos combinar con esta actualización para minimizar el tiempo de inactividad

Estos son los eventos RDS registrados mientras realizamos la actualización:

La CPU de la base de datos se maximizó entre las 08:44 y las 10:27. Gran parte de este tiempo parecía estar ocupado por RDS tomando una instantánea previa y posterior a la actualización.

Los documentos de AWS no advierten sobre tales repercusiones, aunque al leerlos queda claro que una falla obvia en nuestro enfoque es que no creamos una copia de la base de datos de producción en la configuración Multi-AZ e intentamos actualizarla como una prueba

En general, fue muy frustrante porque RDS nos dio muy poca información sobre lo que estaba haciendo y cuánto tiempo podría tomar. (Nuevamente, hacer una ejecución de prueba hubiera ayudado ...)

Aparte de eso, queremos aprender de este incidente, así que aquí están nuestras preguntas:

• ¿Es normal este tipo de cosas cuando se realiza una actualización de versión principal en RDS?
• Si quisiéramos hacer una actualización importante de la versión en el futuro con un tiempo de inactividad mínimo, ¿cómo lo haríamos? ¿Hay algún tipo de forma inteligente de usar la replicación para que sea más fluida?

Esta es una buena pregunta, a
veces es complicado trabajar en un entorno en la nube.

Puede usar el pg_dumpall -f dump.sqlcomando, que volcará toda su base de datos a un formato de archivo SQL, de manera que pueda reconstruirla desde cero apuntando a otro punto final. Usando psql -h endpoint-host.com.br -f dump.sqlpara abreviar.

Pero para hacer eso, necesitará alguna instancia de EC2 con un espacio razonable en el disco (para adaptarse a su volcado de base de datos). Además, deberá instalar yum install postgresql94.x86_64para poder ejecutar comandos de volcado y restauración.

Ver ejemplos en PG Dumpall DOC .

Recuerde que para mantener la integridad de sus datos, se recomienda (en algunos casos será obligatorio) que apague los sistemas que se conectan a la base de datos durante esta ventana de mantenimiento.

Además, si necesita acelerar las cosas, considerar el uso de pg_dumpsu lugar pg_dumpall, aprovechando el paralelismo ( -j njobsparámetro), cuando se determina el número de CPU involucrado en el proceso, por ejemplo -j 8utilizará hasta 8 CPU. Por defecto, el comportamiento de pg_dumpallo pg_dumpes usar solo 1. La única ventaja de usar en su pg_dumplugar pg_dumpalles que necesitará ejecutar el comando para cada base de datos que tenga, y también volcar los ROLES (grupos y usuarios) separados.

Ver ejemplos en PG Dump DOC y PG Restore DOC .