¿Qué tan profundo debemos ir con esto? Comenzaré diciendo que, al momento de escribir este artículo, solo pude ubicar 3 libros en Amazon sobre PostgreSQL en la nube y 117 discusiones en listas de correo de PostgreSQL sobre Aurora PostgreSQL. Eso no parece mucho, y me deja a mí, el curioso usuario final de PostgreSQL, con la documentación oficial como el único lugar donde realmente podría aprender un poco más. Como no tengo la capacidad ni el conocimiento para aventurarme mucho más, existe AWS re:Invent 2018 para aquellos que buscan ese tipo de emoción. Puedo conformarme con el artículo de Werner sobre los quórumes.
Para calentarme, comencé desde la página de inicio de Aurora PostgreSQL, donde noté que el punto de referencia que muestra que Aurora PostgreSQL es tres veces más rápido que un PostgreSQL estándar que se ejecuta en el mismo hardware se remonta a PostgreSQL 9.6. Como aprendí más adelante, 9.6.9 es actualmente la opción predeterminada al configurar un nuevo clúster. Esa es una muy buena noticia para aquellos que no quieren o no pueden actualizar de inmediato. ¿Y por qué solo el 99,99% de disponibilidad? Se puede encontrar una explicación en el artículo de Bruce Momjian.
Compatibilidad
Según AWS, Aurora PostgreSQL es un reemplazo directo de PostgreSQL y la documentación indica:
El código, las herramientas y las aplicaciones que usa hoy con sus bases de datos MySQL y PostgreSQL existentes se pueden usar con Aurora.
Esto se ve reforzado por las preguntas frecuentes de Aurora:
Significa que la mayoría del código, las aplicaciones, los controladores y las herramientas que ya usa con sus bases de datos de PostgreSQL se pueden usar con Aurora con poco o ningún cambio. El motor de base de datos de Amazon Aurora está diseñado para ser compatible por cable con PostgreSQL 9.6 y 10, y admite el mismo conjunto de extensiones de PostgreSQL que son compatibles con RDS para PostgreSQL 9.6 y 10, lo que facilita el traslado de aplicaciones entre los dos motores.
"la mayoría" en el texto anterior sugiere que no hay una garantía del 100 %, en cuyo caso aquellos que buscan certeza deberían considerar comprar soporte técnico de AWS Professional Services o de los socios de Aamazon Aurora. Como nota al margen, me di cuenta de que ninguno de los proveedores de hospedaje profesionales de PostgreSQL que emplean a colaboradores principales de la comunidad está en esa lista.
En la página de Preguntas frecuentes de Aurora también sabemos que Aurora PostgreSQL admite las mismas extensiones que RDS, que a su vez enumera la mayoría de las extensiones de la comunidad y algunas extras.
Conceptos
Como parte de Amazon RDS, Aurora PostgreSQL viene con su propia terminología:
- Cluster:una instancia de base de datos principal en modo de lectura/escritura y cero o más réplicas de Aurora. La base de datos principal a menudo se etiqueta como Maestra en `diagramas de AWS`_ o Escritor en la consola de AWS. Basándonos en el diagrama de referencia podemos hacer una observación interesante:Aurora escribe tres veces. Como la latencia entre las zonas de disponibilidad suele ser más alta que dentro de la misma zona de disponibilidad, la transacción se considera confirmada tan pronto como se escribe en la copia de datos dentro de la misma zona de disponibilidad; de lo contrario, la latencia y las posibles interrupciones entre las zonas de disponibilidad.
- Volumen de clúster:volumen de almacenamiento de base de datos virtual que abarca varias zonas de disponibilidad.
- URL de Aurora:un par `host:puerto`.
- Extremo del clúster:URL de Aurora para la base de datos principal. Hay un extremo de clúster.
- Extremo del lector:URL de Aurora para el conjunto de réplicas. Para hacer una analogía con DNS, es un alias (CNAME). Las solicitudes de lectura tienen una carga equilibrada entre las réplicas disponibles.
- Punto de conexión personalizado:URL de Aurora a un grupo que consta de una o más instancias de base de datos.
- Punto final de instancia:URL de Aurora a una instancia de base de datos específica.
- Versión Aurora:versión del producto devuelta por `SELECT AURORA_VERSION();`.
Supervisión y rendimiento de PostgreSQL en AWS Aurora
Tamaño
Aurora PostgreSQL aplica una configuración de mejor suposición que se basa en el tamaño de la instancia de la base de datos y la capacidad de almacenamiento, lo que deja más ajustes al DBA mediante el uso de grupos de parámetros de la base de datos.
Al seleccionar la instancia de base de datos, base su selección en el valor deseado para max_connections.
Escalado
Aurora PostgreSQL cuenta con escalado automático y manual. El escalado horizontal de las réplicas de lectura se automatiza mediante el uso de métricas de rendimiento. El escalado vertical se puede automatizar mediante API.
El escalado horizontal lo desconecta durante unos minutos mientras reemplaza el motor de cómputo y realiza cualquier operación de mantenimiento (actualizaciones, parches). Por lo tanto, AWS recomienda realizar dichas operaciones durante las ventanas de mantenimiento.
Escalar en ambas direcciones es muy sencillo:
Escalado vertical:modificando la clase de instancia 
Escalado horizontal:agregando una réplica del lector. A nivel de almacenamiento, el espacio se agrega en incrementos de 10G. El almacenamiento asignado nunca se reclama; consulte a continuación cómo abordar esta limitación.
Almacenamiento
Como se mencionó anteriormente, Aurora PostgreSQL se diseñó para aprovechar los quórumes a fin de mejorar la consistencia del rendimiento.
Dado que el almacenamiento subyacente lo comparten todas las instancias de base de datos dentro del mismo clúster, no se requieren escrituras adicionales en los nodos en espera. Además, agregar o eliminar instancias de base de datos no cambia los datos subyacentes.
Me pregunto qué harán esos IO unidades significan en la factura mensual? Aurora FAQs vuelve al rescate para explicar qué es un IO es decir, en el contexto de seguimiento y facturación. Una E/S de lectura como el equivalente a una lectura de página de base de datos de 8 KiB y una E/S de escritura como el equivalente a 4 KiB escritos en la capa de almacenamiento.
Alta simultaneidad
Para aprovechar al máximo el diseño de alta concurrencia de Aurora, se recomienda que las aplicaciones estén configuradas para impulsar una gran cantidad de consultas y transacciones simultáneas.
Las aplicaciones diseñadas para dirigir las consultas de lectura y escritura a los nodos de base de datos principal y en espera, respectivamente, se beneficiarán del extremo de réplica del lector de Aurora PostgreSQL.
Las conexiones tienen equilibrio de carga entre las réplicas de lectura.
El uso de instancias de base de datos de puntos finales personalizados con más capacidad se puede agrupar para ejecutar una carga de trabajo intensiva como análisis.
Los puntos finales de la instancia de base de datos se pueden usar para el equilibrio de carga detallado o la conmutación por error rápida.
Tenga en cuenta que para que Reader Endpoints equilibre la carga de consultas individuales, cada consulta debe enviarse como una nueva conexión.
Almacenamiento en caché
Aurora PostgreSQL utiliza una técnica Survivable Cache Warming que garantiza que se conserve la fecha en la memoria caché del búfer, lo que elimina la necesidad de volver a llenar o calentar la memoria caché después de reiniciar la base de datos.
Replicación
El tiempo de retraso de la replicación entre réplicas se mantiene dentro de un milisegundo de un solo dígito. Aunque no está disponible para PostgreSQL, es bueno saber que el retraso de la replicación entre regiones se mantiene dentro de decenas de milisegundos.
Según la documentación, el retraso de la réplica aumenta durante los períodos de muchas solicitudes de escritura.
Planes de ejecución de consultas
Basado en la suposición de que el rendimiento de las consultas se degrada con el tiempo debido a varios cambios en la base de datos, la función de este componente de Aurora PostgreSQL es mantener una lista de planes de ejecución de consultas aprobados o rechazados.
Los planes se aprueban o rechazan mediante métodos proactivos o reactivos.
Cuando un plan de ejecución se marca como rechazado, el Plan de ejecución de consultas anula las decisiones del optimizador de PostgreSQL y evita que se ejecute el plan "malo".
Esta función requiere Aurora 2.1.0 o posterior.
Alta disponibilidad y replicación de PostgreSQL en AWS Aurora
En la capa de almacenamiento, Aurora PostgreSQL garantiza la durabilidad mediante la replicación de cada 10 GB de volumen de almacenamiento, seis veces en 3 AZ (cada región consta normalmente de 3 AZ) mediante la replicación síncrona física. Eso hace posible que las escrituras de la base de datos continúen funcionando incluso cuando se pierden 2 copias de datos. La disponibilidad de lectura sobrevive a la pérdida de 3 copias de datos.
Las réplicas de lectura garantizan que una instancia principal fallida se pueda reemplazar rápidamente mediante la promoción de una de las 15 réplicas disponibles. Al seleccionar una implementación multi-AZ, se crea automáticamente una réplica de lectura. La conmutación por error no requiere la intervención del usuario y las operaciones de la base de datos se reanudan en menos de 30 segundos.
Para las implementaciones de una sola zona de disponibilidad, el procedimiento de recuperación incluye una restauración desde la última copia de seguridad buena conocida. Según las preguntas frecuentes de Aurora, el proceso se completa en menos de 15 minutos si es necesario restaurar la base de datos en una zona de disponibilidad diferente. La documentación no es tan específica y afirma que se tarda menos de 10 minutos en completar el proceso de restauración.
No se requiere ningún cambio en el lado de la aplicación para conectarse a la nueva instancia de base de datos, ya que el extremo del clúster no cambia durante una promoción de réplica o restauración de instancia.
Paso 1:elimine la instancia principal para forzar una conmutación por error:
Conmutación por error automática Paso 1:eliminar principal Paso 2:conmutación automática por error completada
Conmutación por error automática Paso 2:conmutación por error completada. Para las bases de datos ocupadas, el tiempo de recuperación luego de un reinicio o bloqueo se reduce drásticamente ya que Aurora PostgreSQL no necesita reproducir los registros de transacciones.
Como parte del servicio totalmente administrado, los bloques de datos y discos defectuosos se reemplazan automáticamente.
La conmutación por error cuando existen réplicas tarda hasta 120 segundos y, a menudo, el tiempo es inferior a 60 segundos. Se pueden lograr tiempos de recuperación más rápidos cuando las condiciones de conmutación por error están predeterminadas, en cuyo caso se pueden asignar prioridades de conmutación por error a las réplicas.
Aurora PostgreSQL funciona bien con Amazon RDS:una instancia de Aurora puede actuar como una réplica de lectura para una instancia de RDS principal.
Aurora PostgreSQL admite la replicación lógica que, al igual que en la versión comunitaria, se puede usar para superar las limitaciones de replicación integradas. No hay automatización ni interfaz de consola de AWS.
Seguridad para PostgreSQL en AWS Aurora
A nivel de red, Aurora PostgreSQL aprovecha los componentes principales de AWS, la VPC para el aislamiento de la red en la nube y los grupos de seguridad para el control de acceso a la red.
No hay acceso de superusuario. Al crear un clúster, Aurora PostgreSQL crea una cuenta maestra con un subconjunto de permisos de superusuario:
[email protected]:5432 postgres> \du+ postgres
List of roles
Role name | Attributes | Member of | Description
-----------+-------------------------------+-----------------+-------------
postgres | Create role, Create DB +| {rds_superuser} |
| Password valid until infinity | |Para proteger los datos en tránsito, Aurora PostgreSQL proporciona compatibilidad nativa con SSL/TLS que se puede configurar por instancia de base de datos.
Todos los datos en reposo se pueden cifrar con un impacto mínimo en el rendimiento. Esto también se aplica a copias de seguridad, instantáneas y réplicas.
Cifrado en reposo. La autenticación está controlada por las políticas de IAM, y el etiquetado permite un mayor control sobre lo que los usuarios pueden hacer y sobre qué recursos.
Las llamadas API utilizadas por todos los servicios en la nube se registran en CloudTrail.
La gestión de contraseñas restringidas del lado del cliente está disponible a través del parámetro rds.restrict_password_commands.
Copia de seguridad y recuperación de PostgreSQL en AWS Aurora
Las copias de seguridad están habilitadas de manera predeterminada y no se pueden deshabilitar. Proporcionan recuperación de un punto en el tiempo utilizando una instantánea diaria completa como copia de seguridad base.
La restauración desde una copia de seguridad automática tiene un par de desventajas:el tiempo de restauración puede ser de varias horas y la pérdida de datos puede ser de hasta 5 minutos antes de la interrupción. Las implementaciones Multi-AZ de Amazon RDS resuelven este problema al promover una réplica de lectura a principal, sin pérdida de datos.
Las instantáneas de la base de datos son rápidas y no afectan el rendimiento del clúster. Se pueden copiar o compartir con otros usuarios.
Tomar una instantánea es casi instantáneo:
Hora de la instantánea. Restaurar una instantánea también es rápido. Comparar con PITR:
Las copias de seguridad y las instantáneas se almacenan en S3, que ofrece once 9 de durabilidad.
Además de las copias de seguridad y las instantáneas, Aurora PostgreSQL permite la clonación de bases de datos. Este es un método eficiente para crear copias de grandes conjuntos de datos. Por ejemplo, la clonación de varios terabytes de datos lleva solo unos minutos y no tiene impacto en el rendimiento.
Aurora PostgreSQL:demostración de recuperación en un momento dado
Conectando al clúster:
~ $ export PGUSER=postgres PGPASSWORD=postgres PGHOST=s9s-us-east-1.cluster-ctfirtyhadgr.us-east-1.rds.amazonaws.com
~ $ psql
Pager usage is off.
psql (11.3, server 10.7)
SSL connection (protocol: TLSv1.2, cipher: ECDHE-RSA-AES256-GCM-SHA384, bits: 256, compression: off)
Type "help" for help.Rellene una tabla con datos:
[email protected]:5432 postgres> create table s9s (id serial not null, msg text, created timestamptz not null default now());
CREATE TABLE
[email protected]:5432 postgres> select * from s9s;
id | msg | created
----+------+-------------------------------
1 | test | 2019-06-25 07:57:40.022125+00
2 | test | 2019-06-25 07:57:57.666222+00
3 | test | 2019-06-25 07:58:05.593214+00
4 | test | 2019-06-25 07:58:08.212324+00
5 | test | 2019-06-25 07:58:10.156834+00
6 | test | 2019-06-25 07:59:58.573371+00
7 | test | 2019-06-25 07:59:59.5233+00
8 | test | 2019-06-25 08:00:00.318474+00
9 | test | 2019-06-25 08:00:11.153298+00
10 | test | 2019-06-25 08:00:12.287245+00
(10 rows)Iniciar la restauración:
Recuperación en un punto en el tiempo:iniciar la restauración. 
Una vez que se complete la restauración, inicie sesión y verifique:
~ $ psql -h pg107-dbt3medium-restored-cluster.cluster-ctfirtyhadgr.us-east-1.rds.amazonaws.com
Pager usage is off.
psql (11.3, server 10.7)
SSL connection (protocol: TLSv1.2, cipher: ECDHE-RSA-AES256-GCM-SHA384, bits: 256, compression: off)
Type "help" for help.
[email protected]:5432 postgres> select * from s9s;
id | msg | created
----+------+-------------------------------
1 | test | 2019-06-25 07:57:40.022125+00
2 | test | 2019-06-25 07:57:57.666222+00
3 | test | 2019-06-25 07:58:05.593214+00
4 | test | 2019-06-25 07:58:08.212324+00
5 | test | 2019-06-25 07:58:10.156834+00
6 | test | 2019-06-25 07:59:58.573371+00
(6 rows)Mejores prácticas
Monitoreo y Auditoría
- Integre los flujos de actividad de la base de datos con el monitoreo de terceros para monitorear la actividad de la base de datos para el cumplimiento y los requisitos reglamentarios.
- Un servicio de base de datos completamente administrado no significa falta de responsabilidad:defina métricas para monitorear la CPU, la RAM, el espacio en disco, la red y las conexiones de la base de datos.
- Aurora PostgreSQL se integra con la herramienta de monitoreo estándar de AWS, CloudWatch, además de proporcionar monitores adicionales para Aurora Metrics, Aurora Enhanced Metrics, Performance Insight Counters, Aurora PostgreSQL Replication y también para RDS Metrics que se pueden agrupar por dimensiones de RDS.
- Supervise la carga promedio de la base de datos de las sesiones activas esperando signos de sobrecarga de conexiones, consultas SQL que necesitan ajuste, contención de recursos o una clase de instancia de base de datos de tamaño insuficiente.
- Configurar notificaciones de eventos.
- Configure los parámetros del registro de errores.
- Supervise los cambios de configuración en los componentes del clúster de la base de datos:instancias, grupos de subredes, instantáneas, grupos de seguridad.
Replicación
- Utilice el particionamiento de tablas nativas para las cargas de trabajo que excedan la clase de instancia de base de datos y la capacidad de almacenamiento máximas
Cifrado
- La base de datos cifrada debe tener copias de seguridad habilitadas para garantizar que los datos se puedan restaurar en caso de que se revoque la clave de cifrado.
Cuenta Maestra
- No use psql para cambiar la contraseña del usuario maestro.
Tamaño
- Considere usar diferentes clases de instancias en un clúster para reducir costos.
Grupos de parámetros
- Perfeccione el uso de grupos de parámetros para ahorrar $$$.
Demostración de grupos de parámetros
Configuración actual:
[email protected]:5432 postgres> show shared_buffers ;
shared_buffers
----------------
10112136kB
(1 row)Cree un nuevo grupo de parámetros y establezca el nuevo valor para todo el clúster:
Actualización de shared_buffers en todo el clúster. Asocie el grupo de parámetros personalizados con el clúster:
Reinicie el escritor y verifique el valor:
[email protected]:5432 postgres> show shared_buffers ;
shared_buffers
----------------
1GB
(1 row)- Establecer la zona horaria local
De forma predeterminada, la zona horaria está en UTC:
[email protected]:5432 postgres> show timezone;
TimeZone
----------
UTC
(1 row)Configuración de la nueva zona horaria:
Configuración de zona horaria Y luego verifique:
[email protected]:5432 postgres> show timezone;
TimeZone
------------
US/Pacific
(1 row)Tenga en cuenta que la lista de valores de zona horaria aceptados por Amazon Aurora no son los conjuntos de zonas horarias que se encuentran en el nivel superior de PostgreSQL.
- Revise los parámetros de la instancia que están anulados por los parámetros del clúster
- Utilice la herramienta de comparación de grupos de parámetros.
Instantáneas
- Evite cargos de almacenamiento adicionales compartiendo las instantáneas con otras cuentas para permitir la restauración en sus respectivos entornos.
Mantenimiento
- Cambie la ventana de mantenimiento predeterminada de acuerdo con el cronograma de la organización.
Conmutación por error
- Mejore el tiempo de recuperación configurando la administración de caché de clúster.
- Reduzca los valores keepalive de TCP del kernel en el cliente y configure la caché de DNS de la aplicación y las cadenas de conexión TTL y PostgreSQL.
DBA ¡Cuidado!
Además de las limitaciones conocidas, evite o tenga en cuenta lo siguiente:
Cifrado
- Una vez que se ha creado una base de datos, el estado de cifrado no se puede cambiar.
Aurora sin servidor
- En este momento, la versión PostgreSQL de Aurora Serverless solo está disponible en versión preliminar limitada.
Consulta paralela
- Amazon Parallel Query no está disponible, aunque la característica con el mismo nombre está disponible desde PostgreSQL 9.6.
Puntos finales
Desde Administración de conexión de Amazon:
- 5 puntos finales personalizados por clúster
- Los nombres de puntos finales personalizados no pueden superar los 63 caracteres
- Los nombres de los extremos del clúster son únicos dentro de la misma región
- Como se ve en la captura de pantalla anterior (aurora-custom-endpoint-details) READER y CUALQUIER tipo de punto de conexión personalizado no están disponibles, utilice la CLI
- Los terminales personalizados no saben que las réplicas dejan de estar disponibles temporalmente
Replicación
- Al promocionar una Réplica a Principal, las conexiones a través del Extremo del Lector pueden seguir dirigiéndose durante un breve tiempo a la Réplica promocionada.
- Las réplicas entre regiones no son compatibles
- Aunque se lanzó a fines de noviembre de 2017, la versión preliminar de Amazon Aurora Multi-Master todavía no está disponible para PostgreSQL
- Observe la degradación del rendimiento cuando la replicación lógica está habilitada en el clúster.
- La replicación lógica requiere un motor PostgreSQL en ejecución publicado 10.6 o posterior.
Almacenamiento
- El almacenamiento máximo asignado no se reduce cuando se eliminan los datos, ni se recupera el espacio al restaurar desde instantáneas. La única forma de recuperar espacio es realizando un volcado lógico en un nuevo clúster.
Copia de seguridad y recuperación
- La retención de copias de seguridad no se extiende mientras el clúster está detenido.
- El período de retención máximo es de 35 días:use instantáneas manuales para un período de retención más largo.
- Restauraciones de recuperación a un momento dado en un nuevo clúster de base de datos.
- breve interrupción de las lecturas durante la conmutación por error a las réplicas.
- Los escenarios de recuperación ante desastres no están disponibles entre regiones.
Instantáneas
- La restauración desde una instantánea crea un nuevo punto final (las instantáneas solo se pueden restaurar en un nuevo clúster).
- Después de una restauración de instantánea, se deben volver a crear puntos finales personalizados.
- La restauración a partir de instantáneas restablece la zona horaria local a UTC.
- La restauración a partir de instantáneas no conserva los grupos de seguridad personalizados.
- Las instantáneas se pueden compartir con un máximo de 20 ID de cuenta de AWS.
- Las instantáneas no se pueden compartir entre regiones.
- Las instantáneas incrementales siempre se copian como instantáneas completas, entre regiones y dentro de la misma región.
- Copiar instantáneas entre regiones no conserva los grupos de parámetros no predeterminados.
Facturación
- La factura de 10 minutos se aplica a las instancias nuevas, así como a los cambios de capacidad (informática o almacenamiento).
Autenticación
- El uso de la autenticación de la base de datos de IAM impone un límite en la cantidad de conexiones por segundo.
- La cuenta maestra tiene ciertos privilegios de superusuario revocados.
Iniciar y detener
De Descripción general de cómo detener y iniciar un clúster de base de datos de Aurora:
- Los clústeres no se pueden dejar detenidos indefinidamente, ya que se inician automáticamente después de 7 días.
- Las instancias de bases de datos individuales no se pueden detener.
Actualizaciones
- No se admiten actualizaciones de versiones principales in situ.
- Los cambios en el grupo de parámetros tanto para la instancia de base de datos como para el clúster de base de datos tardan al menos cinco minutos en propagarse.
Clonación
- 15 clones por base de datos (original o copia).
- Los clones no se eliminan al eliminar la base de datos de origen.
Escalado
- Auto-Scaling requiere que todas las réplicas estén disponibles.
- Solo puede haber `una política de escalado automático`_ por métrica por clúster.
- El escalado horizontal de la instancia de base de datos principal (clase de instancia) no es totalmente automático. Antes de escalar, el clúster activa una conmutación por error automática a una de las réplicas. Una vez que se completa el escalado, la nueva instancia debe promoverse manualmente de lector a escritor:
Nueva instancia en modo lector después del cambio de clase de instancia de base de datos.
Monitoreo
- La publicación de registros de PostgreSQL en CloudWatch requiere una versión mínima del motor de base de datos de 9.6.6 y 10.4.
- Solo algunas métricas de Aurora están disponibles en RDS Console y otras métricas tienen diferentes nombres y unidades de medida.
- De forma predeterminada, los registros de Supervisión mejorada se guardan en CloudWatch durante 30 días.
- Las métricas de Cloudwatch y Enhanced Monitoring serán diferentes, ya que recopilan datos del hipervisor y, respectivamente, del agente que se ejecuta en la instancia.
- Performance Insights_ agrega las métricas de todas las bases de datos dentro de una instancia de base de datos.
- Las declaraciones SQL están limitadas a 500 caracteres cuando se visualizan con la API y la CLI de AWS Performance Insights.
Migración
- Solo las instantáneas de base de datos RDS sin cifrar se pueden cifrar en reposo.
- Las migraciones que utilizan la técnica de réplica de lectura de Aurora tardan varias horas por TiB.
Tamaño
- La clase de instancia más pequeña disponible es db.t3.medium y la más grande db.r5.24xlarge. A modo de comparación, el motor de MySQL ofrece db.t2.small y db.t2.medium, sin embargo, no db.r5.24xlarge en el rango superior.
- el límite superior de max_connections es 262.143.
Gestión de Planes de Consulta
- Las declaraciones dentro de las funciones PL/pgSQL no son compatibles.
Migración
Aurora PostgreSQL no proporciona servicios de migración directa, sino que la tarea se transfiere a un producto de AWS especializado, a saber, AWS DMS.
Conclusión
Como reemplazo directo totalmente administrado para el PostgreSQL ascendente, Amazon Aurora PostgreSQL aprovecha las tecnologías que impulsan la nube de AWS para eliminar la complejidad requerida para configurar servicios como el escalado automático, el equilibrio de carga de consultas y los datos de bajo nivel. replicación, copias de seguridad incrementales y cifrado.
La arquitectura y un enfoque conservador para actualizar el motor de PostgreSQL brindan el rendimiento y la estabilidad que buscan las organizaciones, desde pequeñas hasta grandes.
Las limitaciones inherentes son solo una prueba de que crear una base de datos como servicio a gran escala es una tarea compleja, lo que deja a los proveedores de alojamiento de PostgreSQL altamente especializados con un nicho de mercado al que pueden acceder.
