sql >> Base de Datos >  >> RDS >> PostgreSQL

Una descripción general de las ofertas de Amazon RDS y Aurora para PostgreSQL

Los servicios de AWS PostgreSQL se encuentran bajo el paraguas de RDS, que es la oferta de DaaS de Amazon para todos los motores de bases de datos conocidos.

Los servicios de bases de datos administradas ofrecen ciertas ventajas que son atractivas para el cliente que busca independencia del mantenimiento de la infraestructura y configuraciones de alta disponibilidad. Como siempre, no hay una solución única para todos. Las opciones actualmente disponibles se destacan a continuación:

Aurora PostgreSQL

La página de preguntas frecuentes de Amazon Aurora proporciona detalles importantes que deben tenerse en cuenta antes de sumergirse en el producto. Por ejemplo, nos enteramos de que la capa de almacenamiento está virtualizada y se encuentra en un sistema de almacenamiento virtualizado patentado respaldado por SSD.

Precio

En términos de precios, se debe tener en cuenta que Aurora PostgreSQL no está disponible en la capa gratuita de AWS.

Compatibilidad

La misma página de preguntas frecuentes deja en claro que Amazon no afirma ser 100 % compatible con PostgreSQL. La mayoría (mi énfasis) de las aplicaciones estará bien, p. el sabor de AWS PostgreSQL es compatible con cables con PostgreSQL 9.6. Como resultado, Wireshark PostgreSQL Dissector funcionará bien.

Rendimiento

El rendimiento también está vinculado al tipo de instancia, por ejemplo, la cantidad máxima de conexiones se configura de forma predeterminada en función del tamaño de la instancia.

También es importante cuando se trata de compatibilidad el tamaño de página que se ha mantenido en 8KiB, que es el tamaño de página predeterminado de PostgreSQL. Hablando de páginas, vale la pena citar las preguntas frecuentes:“A diferencia de los motores de bases de datos tradicionales, Amazon Aurora nunca envía páginas de bases de datos modificadas a la capa de almacenamiento, lo que genera más ahorros en el consumo de E/S. Esto es posible porque Amazon cambió la forma en que se administra el caché de la página, lo que le permite permanecer en la memoria en caso de falla de la base de datos. Esta característica también beneficia el reinicio de la base de datos después de un bloqueo, lo que permite que la recuperación se realice mucho más rápido que en el método tradicional de reproducción de registros.

De acuerdo con las preguntas frecuentes mencionadas anteriormente, Aurora PostgreSQL ofrece tres veces el rendimiento de PostgreSQL en las operaciones SELECT y UPDATE. Según el White Paper de PostgreSQL Benchmark de Amazon, las herramientas utilizadas para medir el rendimiento fueron pgbench y sysbench. Notable es la dependencia del rendimiento del tipo de instancia, la selección de la región y el rendimiento de la red. ¿Se pregunta por qué no se menciona INSERTAR? Esto se debe a que el cumplimiento de PostgreSQL ACID (la "C") requiere que se cree un registro actualizado usando una eliminación seguida de una inserción.

Para aprovechar al máximo las mejoras de rendimiento, Amazon recomienda que las aplicaciones estén diseñadas para interactuar con la base de datos mediante gran cantidad de consultas y transacciones simultáneas . Este factor importante, a menudo se pasa por alto, lo que lleva a un rendimiento deficiente que se atribuye a la implementación.

Límites

Hay algunas limitaciones a tener en cuenta al planificar la migración:

  • las páginas enormes no se pueden modificar, sin embargo, están activadas de forma predeterminada:

    template1=> select aurora_version();
 aurora_version
----------------
 1.0.11
(1 row)

template1=> show huge_pages ;
 huge_pages
------------
 on
(1 row)
  • pg_hba no se puede usar ya que requiere reiniciar el servidor. Como nota al margen, debe ser un error tipográfico en la documentación de Amazon, ya que PostgreSQL solo necesita recargarse. En lugar de confiar en pg_hba, los administradores deberán usar los grupos de seguridad de AWS y PostgreSQL GRANT.
  • La granularidad de PITR es de 5 minutos.
  • La replicación entre regiones no está disponible actualmente para PostgreSQL.
  • El tamaño máximo de las tablas es de 64 TiB
  • Hasta 15 réplicas de lectura

Escalabilidad

Actualmente, escalar hacia arriba y hacia abajo la instancia de la base de datos es un proceso manual, que se puede realizar a través de la consola de AWS o la CLI, aunque el escalado automático está en marcha; sin embargo, según las preguntas frecuentes de Amazon Aurora, solo estará disponible para MySQL.

Registro de eventos escalando recursos informáticos

Para escalar horizontalmente, las aplicaciones deben aprovechar las API del SDK de AWS, por ejemplo, para lograr una conmutación por error rápida.

Alta disponibilidad

Pasando a la alta disponibilidad, en caso de falla del nodo principal, Aurora PostgreSQL proporciona un punto final de clúster como un registro DNS A, que se actualiza automáticamente internamente para apuntar a la réplica seleccionada para convertirse en principal.

Copias de seguridad

Vale la pena mencionar que si se elimina la base de datos, se mantendrán las instantáneas de respaldo manuales, mientras que se eliminarán las instantáneas automáticas.

Replicación

Dado que las réplicas comparten el mismo almacenamiento subyacente que la instancia principal, el retraso de la replicación es, en teoría, del orden de milisegundos.

Amazon recomienda leer réplicas para reducir la duración de la conmutación por error. Con una réplica de lectura en espera, el proceso de conmutación por error tarda unos 30 segundos, mientras que sin una réplica se esperan hasta 15 minutos.

Otra buena noticia es que también se admite la replicación lógica, como se muestra en la página 22.

Aunque las preguntas frecuentes de Amazon Aurora no brindan detalles sobre la replicación como lo hacen con MySQL, las mejores prácticas de Aurora PostgreSQL brindan una consulta útil para verificar el estado de la replicación:

select server_id, session_id, highest_lsn_rcvd,
cur_replay_latency_in_usec, now(), last_update_timestamp from
aurora_replica_status();

La consulta anterior produce:

-[ RECORD 1 ]--------------+-------------------------------------
server_id                  | testdb
session_id                 | 9e268c62-9392-11e8-87fc-a926fa8340fe
highest_lsn_rcvd           | 46640889
cur_replay_latency_in_usec | 8830
now                        | 2018-07-29 20:14:55.434701-07
last_update_timestamp      | 2018-07-29 20:14:54-07
-[ RECORD 2 ]--------------+-------------------------------------
server_id                  | testdb-us-east-1b
session_id                 | MASTER_SESSION_ID
highest_lsn_rcvd           |
cur_replay_latency_in_usec |
now                        | 2018-07-29 20:14:55.434701-07
last_update_timestamp      | 2018-07-29 20:14:55-07

Dado que la replicación es un tema tan importante, valió la pena configurar la prueba pgbench como se describe en el documento técnico de referencia mencionado anteriormente:

[[email protected] ~]$ whoami
ec2-user

[[email protected] ~]$ tail -n 2 .bashrc
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/pgsql/lib
export PATH=$PATH:/usr/local/pgsql/bin/

[[email protected] ~]$ which pgbench
/usr/local/pgsql/bin/pgbench
[[email protected] ~]$ pgbench --version
pgbench (PostgreSQL) 9.6.8

Sugerencia: Evite escribir innecesariamente creando un archivo pgpass y exportando el host, la base de datos y las variables de entorno del usuario, por ejemplo:

[[email protected] ~]#  tail -n 3 ~/.bashrc export
PGUSER=dbadmin
export PGHOST=c1.cluster-ctfirtyhadgr.us-east-1.rds.amazonaws.com
export PGDATABASE=template1

[[email protected] ~]# cat ~/.pgpass
*:*:*:dbadmin:password

Ejecute el comando de inicialización de datos:

[[email protected] ~]$ pgbench -i --fillfactor=90 --scale=10000 postgres

Mientras se ejecuta la inicialización de datos, capture el retraso de replicación utilizando el SQL anterior llamado desde el siguiente script:

while : ; do
   psql -t -q \
      -c 'select server_id, session_id, highest_lsn_rcvd,
                 cur_replay_latency_in_usec, now(), last_update_timestamp
                 from aurora_replica_status();' postgres
   sleep 1
done

Filtrando la salida del registro de pantalla a través del siguiente comando:

[[email protected] ~]# awk -F '|' '{print $4,$5,$6}' screenlog.2 | sort -k1,1 -n | tail
                     513116   2018-07-30 04:30:44.394729+00   2018-07-30 04:30:43+00
                     529294   2018-07-30 04:20:54.261741+00   2018-07-30 04:20:53+00
                     544139   2018-07-30 04:41:57.538566+00   2018-07-30 04:41:57+00
                    1001902   2018-07-30 04:42:54.80136+00   2018-07-30 04:42:53+00
                    2376951   2018-07-30 04:38:06.621681+00   2018-07-30 04:38:06+00
                    2376951   2018-07-30 04:38:07.672919+00   2018-07-30 04:38:07+00
                    5365719   2018-07-30 04:36:51.608983+00   2018-07-30 04:36:50+00
                    5365719   2018-07-30 04:36:52.912731+00   2018-07-30 04:36:51+00
                    6308586   2018-07-30 04:45:22.951966+00   2018-07-30 04:45:21+00
                    8210986   2018-07-30 04:46:14.575385+00   2018-07-30 04:46:13+00

¡Resulta que la replicación se retrasó hasta 8 segundos!

En una nota relacionada, la métrica de AWS CloudWatch AuroraReplicaLagMaximum no está de acuerdo con los resultados del comando SQL anterior. Me gustaría saber por qué, así que se agradecen mucho los comentarios.

Gráfico de retraso máximo de réplica de RDS CloudWatch

Seguridad

  • El cifrado está disponible y debe habilitarse cuando se crea la base de datos, ya que no se puede cambiar después.

Resolución de problemas

Esta breve sección es importante. Asegúrese de que PostgreSQL work_mem esté ajustado correctamente para que las operaciones de clasificación no escriban datos en el disco.

Configuración

Simplemente siga el asistente de configuración en la consola de AWS:

  1. Abra el Amazon RDS consola de administración.

    Consola de administración de RDS

  2. Seleccione Amazon Aurora y PostgreSQL edición.

    Asistente de Aurora PostgreSQL

  3. Especifique los detalles de la base de datos y tenga en cuenta las limitaciones de la contraseña de Aurora PostgreSQL:

    Master Password must be at least eight characters long, as in
"mypassword". Can be any printable ASCII character except "/", """, or "@".
    Detalles de la base de datos del asistente Aurora PostgreSQL

  4. Configure las opciones de la base de datos:

    • Al momento de escribir este artículo, solo está disponible PostgreSQL 9.6. Utilice PostgreSQL en Amazon RDS si necesita soporte para versiones más recientes, incluidas versiones preliminares beta.

  5. Configure la prioridad de conmutación por error y seleccione la cantidad de réplicas.

    Descripción de la foto

  6. Configure la retención de la copia de seguridad (el máximo es 35 días).

    Retención de copia de seguridad del asistente Aurora PostgreSQL

  7. Seleccione el programa de mantenimiento. Las actualizaciones automáticas de versiones secundarias están disponibles; sin embargo, es importante verificar con el soporte de AWS si su programa de parches se puede acelerar o no en caso de que el proyecto PostgreSQL publique actualizaciones urgentes. Por ejemplo, AWS tardó más de dos meses en publicar las actualizaciones del 2018-05-10.

    Programa de mantenimiento del asistente Aurora PostgreSQL

  8. Si la base de datos se ha creado correctamente, se mostrará un enlace a las instrucciones sobre cómo conectarse:

    Configuración completa del asistente de Aurora PostgreSQL

Conectando a la base de datos

Revise las instrucciones detalladas para las opciones de conexión disponibles, según la configuración de la infraestructura. En el escenario más simple, la conexión se realiza a través de una instancia EC2 pública.

Nota:el cliente debe ser compatible con PostgreSQL 9.6.3 o superior. 

[[email protected] ~]# psql -U dbadmin -h c1.cluster-ctfirtyhadgr.us-east-1.rds.amazonaws.com template1
Password for user dbadmin:
psql (9.6.8, server 9.6.3)
SSL connection (protocol: TLSv1.2, cipher: DHE-RSA-AES256-GCM-SHA384, bits: 256, compression: off)
Type "help" for help.

Monitoreo

Amazon proporciona varias métricas para monitorear la base de datos, un ejemplo a continuación muestra métricas de instancia:

Métricas de instancias de RDSDescargue el documento técnico hoy Administración y automatización de PostgreSQL con ClusterControlObtenga información sobre lo que necesita saber para implementar, monitorear, gestionar y escalar PostgreSQLDescargar el Whitepaper

RDS para PostgreSQL

Esta es una oferta que permite más granularidad en términos de opciones de configuración. Por ejemplo, a diferencia de Aurora, que utiliza un sistema de almacenamiento patentado, RDS ofrece almacenamiento configurable mediante volúmenes de EBS que pueden ser SSD de uso general (GP2), IOPS provisionadas o magnético (no recomendado).

Para ayudar a las grandes instalaciones, que requieren una personalización que no está disponible en la oferta de Aurora, Amazon ha publicado recientemente las recomendaciones de mejores prácticas, solo disponibles para RDS.

La alta disponibilidad debe configurarse manualmente (o automatizarse con cualquiera de las herramientas conocidas de AWS) y se recomienda configurar una implementación Multi-AZ.

La replicación se implementa utilizando la replicación nativa de PostgreSQL.

Hay algunos límites para las instancias de bases de datos de PostgreSQL que deben tenerse en cuenta.

Con las notas anteriores en mente, aquí hay un tutorial para configurar un entorno RDS PostgreSQL Multi-AZ:

  1. Desde la Consola de administración de RDS iniciar el asistente

    Asistente RDS PostgreSQL

  2. Elija entre una configuración de producción y una de desarrollo.

    Selección de caso de uso de la base de datos del asistente RDS PostgreSQL

  3. Ingrese los detalles sobre su nuevo clúster de base de datos.

    Detalles de la base de datos del asistente RDS PostgreSQL Configuración de la base de datos del asistente RDS PostgreSQL

  4. En la página siguiente, configure la red, la seguridad y el programa de mantenimiento:

    Configuración avanzada del asistente RDS PostgreSQL Seguridad y mantenimiento del asistente RDS PostgreSQL

Conclusión

Los servicios de Amazon RDS para PostgreSQL incluyen RDS PostgreSQL y Aurora PostgreSQL, y ambos son ofertas DaaS administradas. Equipados con muchas funciones y un sólido almacenamiento de back-end, tienen algunas limitaciones con respecto a la configuración tradicional; sin embargo, con una planificación cuidadosa, estas ofertas pueden proporcionar una relación costo-funcionalidad bien equilibrada. Amazon RDS para PostgreSQL está dirigido a usuarios que requieren más opciones para configurar sus entornos y, en general, es más costoso. La mayoría de los usuarios se beneficiarán al comenzar con Aurora PostgreSQL y avanzar hacia configuraciones más complejas.