Migración de PostgreSQL a la nube:comparación de soluciones de Amazon, Google y Microsoft

A vista de pájaro, parecería que cuando se trata de migrar las cargas de trabajo de PostgreSQL a la nube, la elección del proveedor de la nube no debería marcar ninguna diferencia. Listo para usar, PostgreSQL facilita la replicación de datos, sin tiempo de inactividad, a través de la replicación lógica, aunque con algunas restricciones. Con el fin de hacer que su oferta de servicios sea más atractiva, los proveedores de la nube pueden resolver algunas de esas restricciones. A medida que comenzamos a pensar en las diferencias en las versiones disponibles de PostgreSQL, la compatibilidad, los límites, las limitaciones y el rendimiento, queda claro que los servicios de migración son factores clave en la oferta general de servicios. Ya no se trata de “lo ofrecemos, lo migramos”. Se ha vuelto más como "lo ofrecemos, lo migramos, con las menores limitaciones".

La migración es importante tanto para las organizaciones pequeñas como para las grandes. No se trata tanto del tamaño del clúster de PostgreSQL, sino del tiempo de inactividad aceptable y el esfuerzo posterior a la migración.

Selección de una estrategia

La estrategia de migración debe tener en cuenta el tamaño de la base de datos, el enlace de red entre el origen y el destino, así como las herramientas de migración que ofrece el proveedor de la nube.

¿Hardware o software?

Al igual que enviar por correo llaves USB y DVD en los primeros días de Internet, en los casos en que el ancho de banda de la red no es suficiente para transferir datos a la velocidad deseada, los proveedores de la nube ofrecen soluciones de hardware capaces transportar hasta cientos de petabytes de datos. A continuación se muestran las soluciones actuales de cada uno de los tres grandes:

Una tabla útil proporcionada por Google que muestra las opciones disponibles:

El dispositivo GCP es un dispositivo de transferencia

Una recomendación similar de Azure basada en el tamaño de los datos frente al ancho de banda de la red:

El dispositivo Azure es una caja de datos

Hacia el final de su página de migraciones de datos, AWS brinda un vistazo de lo que podemos esperar, junto con su recomendación de la solución:

En los casos en que el tamaño de la base de datos supere los 100 GB y el ancho de banda de la red sea limitado, AWS sugiere una solución de hardware.

El dispositivo de AWS es Snowball Edge

Exportación/Importación de datos

Las organizaciones que toleran el tiempo de inactividad pueden beneficiarse de la simplicidad de las herramientas comunes proporcionadas por PostgreSQL listas para usar. Sin embargo, al migrar datos de un proveedor de nube (o alojamiento) a otro proveedor de nube, tenga cuidado con el costo de salida.

AWS

Para probar las migraciones, utilicé una instalación local de mi base de datos Nextcloud que se ejecuta en uno de los servidores de mi red doméstica:

postgres=# select pg_size_pretty(pg_database_size('nextcloud_prod'));

pg_size_pretty

----------------

58 MB

(1 row)



nextcloud_prod=# \dt

                     List of relations

Schema |             Name | Type  | Owner

--------+-------------------------------+-------+-----------

public | awsdms_ddl_audit              | table | s9sdemo

public | oc_accounts                   | table | nextcloud

public | oc_activity                   | table | nextcloud

public | oc_activity_mq                | table | nextcloud

public | oc_addressbookchanges         | table | nextcloud

public | oc_addressbooks               | table | nextcloud

public | oc_appconfig                  | table | nextcloud

public | oc_authtoken                  | table | nextcloud

public | oc_bruteforce_attempts        | table | nextcloud

public | oc_calendar_invitations       | table | nextcloud

public | oc_calendar_reminders         | table | nextcloud

public | oc_calendar_resources         | table | nextcloud

public | oc_calendar_resources_md      | table | nextcloud

public | oc_calendar_rooms             | table | nextcloud

public | oc_calendar_rooms_md          | table | nextcloud

...

public | oc_termsofservice_terms       | table | nextcloud

public | oc_text_documents             | table | nextcloud

public | oc_text_sessions              | table | nextcloud

public | oc_text_steps                 | table | nextcloud

public | oc_trusted_servers            | table | nextcloud

public | oc_twofactor_backupcodes      | table | nextcloud

public | oc_twofactor_providers        | table | nextcloud

public | oc_users                      | table | nextcloud

public | oc_vcategory                  | table | nextcloud

public | oc_vcategory_to_object        | table | nextcloud

public | oc_whats_new                  | table | nextcloud

(84 rows)

The database is running PostgreSQL version 11.5:

postgres=# select version();

                                                version

------------------------------------------------------------------------------------------------------------

PostgreSQL 11.5 on x86_64-redhat-linux-gnu, compiled by gcc (GCC) 9.1.1 20190503 (Red Hat 9.1.1-1), 64-bit

(1 row)

También he creado un usuario de PostgreSQL para que lo utilice AWS DMS, que es el servicio de Amazon para importar PostgreSQL a Amazon RDS:

postgres=# \du s9sdemo

            List of roles

Role name | Attributes |  Member of

-----------+------------+-------------

s9sdemo   |   | {nextcloud}

AWS DMS ofrece muchas ventajas, tal como esperaríamos de una solución administrada en la nube:

escalado automático (solo almacenamiento, ya que la instancia informática debe tener el tamaño adecuado)
aprovisionamiento automático
modelo de pago por uso
conmutación por error automática

Sin embargo, mantener la consistencia de los datos para una base de datos en vivo es un gran esfuerzo. Solo se logra una consistencia del 100 % cuando la base de datos está en modo de solo lectura; esa es una consecuencia de cómo se capturan los cambios en la tabla.

En otras palabras, las tablas tienen un cambio de punto en el tiempo diferente:

Al igual que con todo en la nube, hay un costo asociado con la servicio de migración.

Para crear el entorno de migración, siga la guía de introducción para configurar una instancia de replicación, un origen, un punto final de destino y una o más tareas.

Instancia de replicación

La creación de la instancia de replicación es sencilla para cualquiera que esté familiarizado con las instancias EC2 en AWS:

El único cambio con respecto a los valores predeterminados fue seleccionar AWS DMS 3.3.0 o más tarde debido a que mi motor PostgreSQL local es 11.5:

Y aquí está la lista de versiones de AWS DMS actualmente disponibles:

Las instalaciones grandes también deben tener en cuenta los límites de AWS DMS:

También existe un conjunto de limitaciones que son consecuencia de la replicación lógica de PostgreSQL restricciones Por ejemplo, AWS DMS no migrará objetos secundarios:

Vale la pena mencionar que en PostgreSQL todos los índices son índices secundarios y que no es algo malo, como se indica en esta discusión más detallada.

Punto final de origen

Siga el asistente para crear el punto final de origen:

En el escenario de configuración Configuración de una red a una VPC mediante Internet mi La red doméstica requirió algunos ajustes para permitir que la dirección IP del punto final de origen accediera a mi servidor interno. Primero, creé un reenvío de puertos en el enrutador de borde (173.180.222.170) para enviar tráfico en el puerto 30485 a mi puerta de enlace interna (10.11.11.241) en el puerto 5432 donde puedo ajustar el acceso según la dirección IP de origen a través de las reglas de iptables. Desde allí, el tráfico de red fluye a través de un túnel SSH hasta el servidor web que ejecuta la base de datos PostgreSQL. Con la configuración descrita, client_addr en la salida de pg_stat_activity se mostrará como 127.0.0.1.

Antes de permitir el tráfico entrante, los registros de iptables muestran 12 intentos desde la instancia de replicación en ip=3.227.167.58):

Jan 19 17:35:28 mha.can.local kernel: filter/INPUT: IN=enp0s29f7u2 OUT= MAC=00:24:9b:17:3a:fa:9c:1e:95:e5:ad:b0:08:00 SRC=3.227.167.58 DST=10.11.11.241 LEN=60 TOS=0x00 PREC=0x00 TTL=39 ID=23973 DF PROTO=TCP SPT=54662 DPT=5432 WINDOW=26880 RES=0x00 SYN URGP=0

Jan 19 17:35:29 mha.can.local kernel: filter/INPUT: IN=enp0s29f7u2 OUT= MAC=00:24:9b:17:3a:fa:9c:1e:95:e5:ad:b0:08:00 SRC=3.227.167.58 DST=10.11.11.241 LEN=60 TOS=0x00 PREC=0x00 TTL=39 ID=23974 DF PROTO=TCP SPT=54662 DPT=5432 WINDOW=26880 RES=0x00 SYN URGP=0

Jan 19 17:35:31 mha.can.local kernel: filter/INPUT: IN=enp0s29f7u2 OUT= MAC=00:24:9b:17:3a:fa:9c:1e:95:e5:ad:b0:08:00 SRC=3.227.167.58 DST=10.11.11.241 LEN=60 TOS=0x00 PREC=0x00 TTL=39 ID=23975 DF PROTO=TCP SPT=54662 DPT=5432 WINDOW=26880 RES=0x00 SYN URGP=0

Jan 19 17:35:35 mha.can.local kernel: filter/INPUT: IN=enp0s29f7u2 OUT= MAC=00:24:9b:17:3a:fa:9c:1e:95:e5:ad:b0:08:00 SRC=3.227.167.58 DST=10.11.11.241 LEN=60 TOS=0x00 PREC=0x00 TTL=39 ID=23976 DF PROTO=TCP SPT=54662 DPT=5432 WINDOW=26880 RES=0x00 SYN URGP=0

Jan 19 17:35:48 mha.can.local kernel: filter/INPUT: IN=enp0s29f7u2 OUT= MAC=00:24:9b:17:3a:fa:9c:1e:95:e5:ad:b0:08:00 SRC=3.227.167.58 DST=10.11.11.241 LEN=60 TOS=0x00 PREC=0x00 TTL=39 ID=4328 DF PROTO=TCP SPT=54667 DPT=5432 WINDOW=26880 RES=0x00 SYN URGP=0

Jan 19 17:35:49 mha.can.local kernel: filter/INPUT: IN=enp0s29f7u2 OUT= MAC=00:24:9b:17:3a:fa:9c:1e:95:e5:ad:b0:08:00 SRC=3.227.167.58 DST=10.11.11.241 LEN=60 TOS=0x00 PREC=0x00 TTL=39 ID=4329 DF PROTO=TCP SPT=54667 DPT=5432 WINDOW=26880 RES=0x00 SYN URGP=0

Jan 19 17:35:51 mha.can.local kernel: filter/INPUT: IN=enp0s29f7u2 OUT= MAC=00:24:9b:17:3a:fa:9c:1e:95:e5:ad:b0:08:00 SRC=3.227.167.58 DST=10.11.11.241 LEN=60 TOS=0x00 PREC=0x00 TTL=39 ID=4330 DF PROTO=TCP SPT=54667 DPT=5432 WINDOW=26880 RES=0x00 SYN URGP=0

Jan 19 17:35:55 mha.can.local kernel: filter/INPUT: IN=enp0s29f7u2 OUT= MAC=00:24:9b:17:3a:fa:9c:1e:95:e5:ad:b0:08:00 SRC=3.227.167.58 DST=10.11.11.241 LEN=60 TOS=0x00 PREC=0x00 TTL=39 ID=4331 DF PROTO=TCP SPT=54667 DPT=5432 WINDOW=26880 RES=0x00 SYN URGP=0

Jan 19 17:36:08 mha.can.local kernel: filter/INPUT: IN=enp0s29f7u2 OUT= MAC=00:24:9b:17:3a:fa:9c:1e:95:e5:ad:b0:08:00 SRC=3.227.167.58 DST=10.11.11.241 LEN=60 TOS=0x00 PREC=0x00 TTL=39 ID=8298 DF PROTO=TCP SPT=54670 DPT=5432 WINDOW=26880 RES=0x00 SYN URGP=0

Jan 19 17:36:09 mha.can.local kernel: filter/INPUT: IN=enp0s29f7u2 OUT= MAC=00:24:9b:17:3a:fa:9c:1e:95:e5:ad:b0:08:00 SRC=3.227.167.58 DST=10.11.11.241 LEN=60 TOS=0x00 PREC=0x00 TTL=39 ID=8299 DF PROTO=TCP SPT=54670 DPT=5432 WINDOW=26880 RES=0x00 SYN URGP=0

Jan 19 17:36:11 mha.can.local kernel: filter/INPUT: IN=enp0s29f7u2 OUT= MAC=00:24:9b:17:3a:fa:9c:1e:95:e5:ad:b0:08:00 SRC=3.227.167.58 DST=10.11.11.241 LEN=60 TOS=0x00 PREC=0x00 TTL=39 ID=8300 DF PROTO=TCP SPT=54670 DPT=5432 WINDOW=26880 RES=0x00 SYN URGP=0

Jan 19 17:36:16 mha.can.local kernel: filter/INPUT: IN=enp0s29f7u2 OUT= MAC=00:24:9b:17:3a:fa:9c:1e:95:e5:ad:b0:08:00 SRC=3.227.167.58 DST=10.11.11.241 LEN=60 TOS=0x00 PREC=0x00 TTL=39 ID=8301 DF PROTO=TCP SPT=54670 DPT=5432 WINDOW=26880 RES=0x00 SYN URGP=0

Una vez que se permite la dirección IP del punto final de origen (3.227.167.58), la prueba de conexión tiene éxito y la configuración del punto final de origen está completa. También disponemos de conexión SSL para encriptar el tráfico a través de redes públicas. Esto se puede confirmar en el servidor PostgreSQL utilizando la consulta a continuación, así como en la consola de AWS:

postgres=# SELECT datname, usename, client_addr, ssl, cipher, query, query_start FROM pg_stat_activity a, pg_stat_ssl s where a.pid=s.pid and usename = 's9sdemo';

datname | usename | client_addr | ssl | cipher | query | query_start

---------+---------+-------------+-----+--------+-------+-------------

(0 rows)

…y luego mire mientras ejecuta la conexión desde la consola de AWS. Los resultados deberían ser similares a los siguientes:

postgres=# \watch



                                                                           Sun 19 Jan 2020 06:50:51 PM PST (every 2s)



    datname     | usename | client_addr | ssl |           cipher |                 query | query_start

----------------+---------+-------------+-----+-----------------------------+------------------------------------------------------------------------------------+-------------------------------

 nextcloud_prod | s9sdemo | 127.0.0.1   | t | ECDHE-RSA-AES256-GCM-SHA384 | select cast(setting as integer) from pg_settings where name = 'server_version_num' | 2020-01-19 18:50:51.463496-08

(1 row)

…mientras que la consola de AWS debería reportar un éxito:

Como se indica en la sección de requisitos previos, si elegimos la opción de migración Carga completa , replicación en curso, necesitaremos modificar los permisos para el usuario de PostgreSQL. Esta opción de migración requiere privilegios de superusuario, por lo que ajusté la configuración para el usuario de PostgreSQL creado anteriormente:

nextcloud_prod=# \du s9sdemo

         List of roles

Role name | Attributes | Member of

-----------+------------+-----------

s9sdemo   | Superuser  | {}

El mismo documento contiene instrucciones para modificar postgresql.conf. Aquí hay una diferencia con el original:

--- a/var/lib/pgsql/data/postgresql.conf

+++ b/var/lib/pgsql/data/postgresql.conf

@@ -95,7 +95,7 @@ max_connections = 100                 # (change requires restart)



# - SSL -



-#ssl = off

+ssl = on

#ssl_ca_file = ''

#ssl_cert_file = 'server.crt'

#ssl_crl_file = ''

@@ -181,6 +181,7 @@ dynamic_shared_memory_type = posix  # the default is the first option



# - Settings -



+wal_level = logical

#wal_level = replica                   # minimal, replica, or logical

                                       # (change requires restart)

#fsync = on                            # flush data to disk for crash safety

@@ -239,6 +240,7 @@ min_wal_size = 80MB

#max_wal_senders = 10          # max number of walsender processes

                              # (change requires restart)

#wal_keep_segments = 0         # in logfile segments; 0 disables

+wal_sender_timeout = 0

#wal_sender_timeout = 60s      # in milliseconds; 0 disables



#max_replication_slots = 10    # max number of replication slots

@@ -451,6 +453,7 @@ log_rotation_size = 0                       # Automatic rotation of logfiles will

#log_duration = off

#log_error_verbosity = default         # terse, default, or verbose messages

Por último, no olvide ajustar la configuración de pg_hba.conf para permitir la conexión SSL desde la dirección IP de la instancia de replicación.

Ahora estamos listos para el siguiente paso.

Punto final de destino

Siga el asistente para crear el punto final de destino:

Este paso asume que la instancia de RDS con el punto final especificado ya existe junto con la base de datos vacía nextcloud_awsdms. La base de datos se puede crear durante la configuración de la instancia de RDS.

En este punto, si la red de AWS está configurada correctamente, deberíamos estar listos para ejecutar la prueba de conexión:

Con el entorno en su lugar, ahora es el momento de crear la tarea de migración :

Tarea de migración

Una vez que el asistente completó la configuración se ve así:

...y la segunda parte de la misma vista:

Una vez que se inicia la tarea, podemos monitorear el progreso:abrir la tarea detalles y desplácese hacia abajo hasta Estadísticas de la tabla:

AWS DMS utiliza el esquema en caché para migrar las tablas de la base de datos. Mientras avanza la migración, podemos seguir "observando" las consultas en la base de datos de origen y el registro de errores de PostgreSQL, además de la consola de AWS:

En caso de errores, el estado de falla se muestra en la consola:

Un lugar para buscar pistas es CloudWatch, aunque durante mis pruebas los registros no terminó siendo publicado, lo que probablemente podría ser solo otra falla en la versión beta de AWS DMS 3.3.0, como resultó ser hacia el final de este ejercicio:

El progreso de la migración se muestra muy bien en la consola de AWS DMS:

Una vez completada la migración, revisando una vez más, el registro de errores de PostgreSQL , revela un mensaje sorprendente:

Lo que parece suceder es que en PostgreSQL 9.6, 10 la tabla pg_class contiene la columna nombrada relhaspkey, pero ese no es el caso en 11. Y esa es la falla en la versión beta de AWS DMS 3.3.0 a la que me refería anteriormente.

PCG

El enfoque de Google se basa en la herramienta de código abierto PgBouncer. La emoción duró poco, ya que la documentación oficial habla sobre la migración de PostgreSQL a un entorno de motor de cómputo.

Fallaron otros intentos de encontrar una solución de migración a Cloud SQL que se asemeje a AWS DMS. Las estrategias de migración de la base de datos no contienen ninguna referencia a PostgreSQL:

Las instalaciones locales de PostgreSQL se pueden migrar a Cloud SQL mediante los servicios de uno de los socios de Google Cloud.

Una solución potencial puede ser PgBouncer para Cloud SQL, pero eso no está dentro del alcance de este blog.

Servicios en la nube de Microsoft (Azure)

Con el fin de facilitar la migración de las cargas de trabajo de PostgreSQL desde las instalaciones a Azure Database para PostgreSQL administrado, Microsoft proporciona Azure DMS que, según la documentación, se puede usar para migrar con un tiempo de inactividad mínimo. El tutorial Migración de PostgreSQL a Azure Database for PostgreSQL en línea mediante DMS describe estos pasos en detalle.

La documentación de Azure DMS analiza en gran detalle los problemas y limitaciones asociados con la migración de las cargas de trabajo de PostgreSQL a Azure.

Una diferencia notable con AWS DMS es el requisito de crear manualmente el esquema:

Una demostración de esto será el tema de un futuro blog. Estén atentos.