Aurora Ug

Amazon Aurora
Guía del usuario de Aurora

Versión de API 2014-10-31
Amazon Aurora Guía del usuario de Aurora
Amazon Aurora: Guía del usuario de Aurora

Copyright © 2019 Amazon Web Services, Inc. and/or its affiliates. All rights reserved.
Amazon's trademarks and trade dress may not be used in connection with any product or service that is not Amazon's,
in any manner that is likely to cause confusion among customers, or in any manner that disparages or discredits
Amazon. All other trademarks not owned by Amazon are the property of their respective owners, who may or may not
be affiliated with, connected to, or sponsored by Amazon.
Table of Contents
¿Qué es Aurora? ................................................................................................................................ 1
Clústeres de base de datos Aurora ............................................................................................... 2
Administración de conexiones de Aurora ........................................................................................ 3
Tipos de puntos de enlace de Aurora .................................................................................... 3
Visualización de puntos de enlace ........................................................................................ 5
Uso del punto de enlace de clúster ....................................................................................... 5
Uso del punto de enlace del lector ........................................................................................ 6
Uso de puntos de enlace personalizados ............................................................................... 6
Uso de los puntos de enlace de instancia ............................................................................ 23
Puntos de enlace y alta disponibilidad ................................................................................. 24
Almacenamiento y fiabilidad de Aurora ......................................................................................... 24
Información general del almacenamiento de Aurora ............................................................... 25
Contenido del volumen del clúster ....................................................................................... 25
Crecimiento del almacenamiento ......................................................................................... 25
Facturación de datos ......................................................................................................... 25
Fiabilidad ......................................................................................................................... 26
Seguridad de Aurora ................................................................................................................. 27
Uso de SSL con clústeres de base de datos de Aurora .......................................................... 28
Alta disponibilidad para Aurora ................................................................................................... 28
Aurora Global Database ............................................................................................................. 29
Información general sobre Global Database .......................................................................... 29
Creación de una base de datos global ................................................................................. 31
Añadir una región de AWS a una base de datos global de Aurora ............................................ 36
Eliminación de un clúster de una base de datos global de Aurora ............................................. 38
Eliminación de una base de datos global de Aurora ............................................................... 40
Importación de datos en una base de datos global ................................................................ 42
Administración de una base de datos global de Aurora ........................................................... 43
Configuración de una base de datos global de Aurora ............................................................ 43
Conexión a una base de datos global de Aurora ................................................................... 45
Conmutación por error para bases de datos globales ............................................................. 45
Performance Insights para base de datos global .................................................................... 46
Uso de base de datos global con otros servicios de AWS ....................................................... 46
Replicación con Aurora .............................................................................................................. 48
Réplicas de Aurora ........................................................................................................... 48
Aurora MySQL ................................................................................................................. 48
Aurora PostgreSQL ........................................................................................................... 49
Configuración del entorno .................................................................................................................. 50
Inscripción en AWS ................................................................................................................... 50
Creación de un usuario de IAM .................................................................................................. 50
Determinar las necesidades ....................................................................................................... 52
Proporcionar acceso al clúster de base de datos en la VPC mediante la creación de un grupo de
seguridad ................................................................................................................................. 53
Introducción ..................................................................................................................................... 55
Creación de un clúster de Aurora y conectarse a él ....................................................................... 55
Crear un clúster de base de datos ...................................................................................... 55
Conectarse a una instancia en un clúster de base de datos .................................................... 58
Elimine el clúster de base de datos de ejemplo, el grupo de subred de base de datos y la VPC ...... 60
Configuración de su clúster de base de datos Aurora ............................................................................. 61
Selección de la clase de instancia de base de datos ...................................................................... 61
Tipos de clase de instancia de base de datos ....................................................................... 61
Terminología .................................................................................................................... 62
Especificaciones de hardware ............................................................................................. 62
Elección de Regiones y zonas de disponibilidad ............................................................................ 64
Disponibilidad ................................................................................................................... 65

iii
Zona horaria local para los clústeres de base de datos ........................................................... 68

Facturación de instancia de base de datos para Aurora ................................................................. 71
Instancias de base de datos bajo demanda .......................................................................... 72
Instancias de base de datos reservadas ............................................................................... 73
Creación de un clúster de base de datos ..................................................................................... 85
Requisitos previos ............................................................................................................. 86
Creación de un clúster de base de datos ............................................................................. 87
Uso de Aurora Serverless ........................................................................................................ 100
Beneficios de Aurora Serverless ........................................................................................ 100
Casos de uso de Aurora Serverless ................................................................................... 101
Limitaciones de Aurora Serverless ..................................................................................... 101
Uso de TLS/SSL con Aurora Serverless ............................................................................. 102
Funcionamiento de Aurora Serverless ................................................................................ 103
Creación de un clúster de base de datos de Aurora Serverless .............................................. 109
Restauración de un clúster de base de datos de Aurora Serverless ......................................... 115
Modificación de un clúster de base de datos de Aurora Serverless .......................................... 118
Configuración de la capacidad de un clúster de base de datos de Aurora Serverless .................. 120
Visualización de clústeres de base de datos Aurora Serverless .............................................. 122
Uso de la API de datos ................................................................................................... 125
Uso del editor de consultas .............................................................................................. 144
Conexión a un clúster de base de datos ..................................................................................... 148
Aurora MySQL ................................................................................................................ 149
Aurora PostgreSQL ......................................................................................................... 152
Solución de problemas ..................................................................................................... 154
Migración de datos a un clúster de base de datos ....................................................................... 154
Aurora MySQL ................................................................................................................ 154
Seguridad ...................................................................................................................................... 156
Protección de los datos ............................................................................................................ 157
Cifrado de datos ............................................................................................................. 158
Privacidad del tráfico entre redes ...................................................................................... 162
Identity and Access Management .............................................................................................. 163
Público .......................................................................................................................... 163
Autenticación con identidades ........................................................................................... 163
Administración de acceso mediante políticas ....................................................................... 165
Funcionamiento de Amazon Aurora con IAM ....................................................................... 167
Ejemplos de políticas basadas en identidad ........................................................................ 170
Autenticación de bases de datos de IAM ............................................................................ 180
Solución de problemas ..................................................................................................... 197
Registro y monitorización ......................................................................................................... 199
Validación de la conformidad .................................................................................................... 201
Resiliencia .............................................................................................................................. 201
Copia de seguridad y restauración ..................................................................................... 202
Replicación ..................................................................................................................... 202
Conmutación por error ..................................................................................................... 202
Seguridad de la infraestructura .................................................................................................. 203
Grupos de seguridad ....................................................................................................... 203
Public accessibility (Accesibilidad pública) ........................................................................... 203
Prácticas recomendadas de seguridad ....................................................................................... 204
Control de acceso con grupos de seguridad ................................................................................ 204
Grupos de seguridad de la VPC ........................................................................................ 205
Escenario de grupos de seguridad ..................................................................................... 205
Creación de un grupo de seguridad de VPC ....................................................................... 206
Asociación con una instancia de base de datos ................................................................... 206
Asociación con un clúster de base de datos ........................................................................ 206
Privilegios de la cuenta de usuario maestro ................................................................................ 207
Roles vinculados a servicios ..................................................................................................... 207

iv
Permisos de roles vinculados a servicios para Amazon Aurora ............................................... 208

Creación de una función vinculada a servicios para Amazon Aurora ........................................ 209
Edición de un rol vinculado a un servicio para Amazon Aurora ............................................... 209
Eliminación de un rol vinculado a un servicio para Amazon Aurora .......................................... 209
Uso de Amazon Aurora con Amazon VPC .................................................................................. 211
Creación de una VPC para Aurora .................................................................................... 211
Escenarios para el acceso a una instancia de base de datos situada en una VPC ...................... 218
Uso de una instancia de base de datos en una VPC ............................................................ 222
Tutorial: Creación de una Amazon VPC para utilizarla con una instancia de base de datos .......... 227
Administración de un clúster de base de datos de Aurora ..................................................................... 232
Detención e inicio de un clúster ................................................................................................ 232
Información general de detención e inicio de un clúster ......................................................... 233
Limitaciones ................................................................................................................... 233
Detención de un clúster de base de datos .......................................................................... 233
Mientras un clúster de base de datos está detenido ............................................................. 234
Inicio de un clúster .......................................................................................................... 235
Modificación de un clúster de base de datos Aurora ..................................................................... 235
Modificación del clúster de base de datos con la consola, CLI y API ........................................ 236
Modificar una instancia de base de datos en un clúster de base de datos ................................. 237
Opciones disponibles ....................................................................................................... 239
Configuración no aplicable ................................................................................................ 253
Adición de réplicas de Aurora ................................................................................................... 254
Gestión del desempeño y el escalado ........................................................................................ 257
Escalado del almacenamiento ........................................................................................... 258
Escalado de instancia ...................................................................................................... 258
Escalado de lectura ......................................................................................................... 258
Administración de conexiones ........................................................................................... 259
Administración de planes de ejecución de consultas ............................................................. 259
Trabajo con los grupos de parámetros ....................................................................................... 259
Parámetros del clúster de base de datos y la instancia de base de datos ................................. 261
Creación de un grupo de parámetros de base de datos ........................................................ 262
Creación de un grupo de parámetros de clúster de base de datos .......................................... 264
Modificación de parámetros de un grupo de parámetros de base de datos ............................... 265
Modificación de parámetros de un grupo de parámetros de clúster de base de datos .................. 269
Copia de un grupo de parámetros de base de datos ............................................................ 271
Copia de un grupo de parámetros de clúster de base de datos .............................................. 273
Obtención de la lista de grupos de parámetros de base de datos ............................................ 274
Lista de grupos de parámetros de clúster de base de datos ................................................... 276
Visualización de los valores de los parámetros de un grupo de parámetros de base de datos ....... 277
Visualización de los valores de los parámetros de un grupo de parámetros de clúster de base de
datos ............................................................................................................................. 278
Comparación de grupos de parámetros .............................................................................. 279
Valores de los parámetros de base de datos ....................................................................... 279
Clonación de bases de datos en un clúster de bases de datos de Aurora ......................................... 282
Limitaciones ................................................................................................................... 282
Protocolo de copia en escritura para la clonación de bases de datos ....................................... 283
Eliminación de bases de datos de origen ............................................................................ 284
Clonación mediante la Consola de administración de AWS .................................................... 285
Clonación mediante la CLI ................................................................................................ 285
Clonación entre cuentas ................................................................................................... 286
Integración con los servicios de AWS ........................................................................................ 297
Aurora MySQL ................................................................................................................ 297
Uso de Auto Scaling con réplicas de Aurora ....................................................................... 297
Temas relacionados ........................................................................................................ 314
Backup y restauración de un clúster de base de datos de Aurora ................................................... 314
Información general de copias de seguridad y restauración ................................................... 314

v
Almacenamiento de copia de seguridad .............................................................................. 316

Creación de una instantánea de clúster de base de datos ..................................................... 317
Restauración de una instantánea de clúster de base de datos ................................................ 319
Copia de una instantánea ................................................................................................. 321
Cómo compartir una instantánea ....................................................................................... 332
Recuperación a un momento dado .................................................................................... 338
Eliminación de una instantánea ......................................................................................... 339
Mantenimiento de un clúster de base de datos de Aurora .............................................................. 340
Aplicación de actualizaciones ............................................................................................ 342
La ventana de mantenimiento ........................................................................................... 344
Ajuste de la ventana de mantenimiento para un clúster de base de datos ................................. 345
Reinicio de una instancia de base de datos ................................................................................ 347
Eliminación de una instancia de base de datos ............................................................................ 348
Uso de la consola, la CLI y la API ..................................................................................... 349
Etiquetado de recursos de RDS ................................................................................................ 349
Información general ......................................................................................................... 350
Uso de ARN ........................................................................................................................... 354
Creación de un nombre ARN ............................................................................................ 354
Obtención de un ARN existente ........................................................................................ 357
Actualizaciones de Aurora ........................................................................................................ 361
Versiones ....................................................................................................................... 361
Monitorización de un clúster de base de datos de Aurora ...................................................................... 363
Información general sobre la monitorización ................................................................................ 363
Herramientas de monitorización ......................................................................................... 364
Monitorización con CloudWatch ......................................................................................... 366
Publicación en CloudWatch Logs ....................................................................................... 372
Visualización de un clúster de base de datos .............................................................................. 375
Consola de administración de AWS ................................................................................... 375
CLI ................................................................................................................................ 377
API ............................................................................................................................... 379
.................................................................................................................................... 380
Estado del clúster de base de datos .......................................................................................... 380
Estado de la instancia de base de datos .................................................................................... 381
Monitorización de las métricas de un clúster de base de datos Aurora ............................................. 384
Métricas de Aurora MySQL ............................................................................................... 384
Consulta de métricas en la consola de Amazon RDS ........................................................... 390
Métricas de Aurora disponibles en la consola de Amazon RDS .............................................. 392
Monitorización mejorada ........................................................................................................... 395
Diferencias entre métricas de monitorización mejorada y CloudWatch ...................................... 395
Configuración y habilitación de la monitorización mejorada .................................................... 395
Visualización de la monitorización mejorada ........................................................................ 397
Visualización de la monitorización mejorada con CloudWatch Logs ......................................... 399
Performance Insights ............................................................................................................... 402
Activación de Performance Insights .................................................................................... 404
Control de acceso de Performance Insights ........................................................................ 408
Uso del panel de Performance Insights .............................................................................. 409
Características adicionales de la interfaz de usuario ............................................................. 419
API de Performance Insights ............................................................................................ 420
Métricas publicadas en CloudWatch ................................................................................... 432
Contadores de Performance Insights .................................................................................. 433
Registro de operaciones de Performance Insights mediante AWS CloudTrail ............................ 440
Uso de recomendaciones de Amazon Aurora .............................................................................. 440
Respuesta a las recomendaciones ..................................................................................... 443
Uso de secuencias de actividades de la base de datos ................................................................. 446
Inicio de una secuencia de actividades de la base de datos ................................................... 447

vi
Uso de secuencias de actividades de la base de datos ......................................................... 449

Detención de una secuencia de actividades de la base de datos ............................................ 449
Monitorización de secuencias de actividades de la base de datos ........................................... 450
Administración del acceso a secuencias de actividades de base de datos ................................ 463
Uso de las notificaciones de eventos de Amazon RDS ................................................................. 465
Categorías y mensajes de eventos de Amazon RDS ............................................................ 466
Suscripción a notificaciones de eventos de Amazon RDS ...................................................... 473
Mostrar las suscripciones de notificación de eventos de Amazon RDS ..................................... 475
Modificación de una suscripción a notificaciones de eventos de Amazon RDS ........................... 476
Añadir un identificador de origen a una suscripción de notificación de eventos de Amazon RDS .... 477
Quitar un identificador de origen de una suscripción de notificación de eventos de Amazon RDS .. 478
Obtención de la lista de categorías de notificaciones de eventos de Amazon RDS ..................... 479
Eliminar una suscripción de notificación de eventos de Amazon RDS ...................................... 480
Consulta de eventos de Amazon RDS ....................................................................................... 481
Consola de administración de AWS ................................................................................... 481
CLI ................................................................................................................................ 481
API ............................................................................................................................... 482
.................................................................................................................................... 482
Archivos de registro de base de datos ....................................................................................... 482
Visualización y listado de archivos de registro de base de datos ............................................. 482
Descarga de un archivo de registro de base de datos ........................................................... 483
Monitorizar un archivo de registro de base de datos ............................................................. 484
Publicación en CloudWatch Logs ....................................................................................... 484
Lectura del contenido del archivo de registro mediante REST ................................................ 485
Archivos de registro de base de datos de MySQL ................................................................ 485
Archivos de registro de base de datos de PostgreSQL .......................................................... 491
Registro de llamadas al API de Amazon RDS con AWS CloudTrail ................................................. 492
Información de Amazon RDS en CloudTrail ........................................................................ 493
Descripción de las entradas de archivos de registro de Amazon RDS ...................................... 493
Uso de Aurora MySQL ..................................................................................................................... 496
Información general de Aurora MySQL ....................................................................................... 496
Mejoras de desempeño de Amazon Aurora MySQL .............................................................. 496
Aurora MySQL y los datos espaciales ................................................................................ 497
Comparación de Aurora MySQL 5.6 y Aurora MySQL 5.7 ...................................................... 498
Comparación de Aurora MySQL 5.7 y MySQL 5.7 ................................................................ 498
Seguridad con Aurora MySQL ................................................................................................... 499
Privilegios de la cuenta de usuario maestro con Aurora MySQL .............................................. 500
Uso de SSL con clústeres de base de datos de Aurora MySQL .............................................. 501
Migración de datos a Aurora MySQL ......................................................................................... 502
Migración de una base de datos MySQL externa a Aurora MySQL .......................................... 504
Migración desde una instancia de base de datos MySQL a Aurora MySQL ............................... 526
Administración de Aurora MySQL .............................................................................................. 544
Administración del desempeño y el escalado para Amazon Aurora MySQL ............................... 544
Búsqueda de datos anteriores de un clúster de base de datos ............................................... 546
Pruebas de Amazon Aurora por medio de consultas de inserción de errores ............................. 561
Modificación de las tablas de Amazon Aurora con operaciones DDL rápidas ............................. 564
Visualización del estado del volumen para un clúster de base de datos de Aurora ..................... 565
Consulta paralela para Aurora MySQL ....................................................................................... 566
Información general de Consultas en paralelo ..................................................................... 566
Administración ................................................................................................................ 569
Actualización de Consultas en paralelo ............................................................................... 569
Creación de un clúster de consultas en paralelo .................................................................. 570
Habilitar y deshabilitar Consultas en paralelo ....................................................................... 574
Ajuste del desempeño ..................................................................................................... 576
Creación de objetos de esquema ...................................................................................... 576
Verificación del uso de Consultas en paralelo ...................................................................... 576
Monitorización ................................................................................................................. 579

vii
Consultas en paralelo y constructos de SQL ....................................................................... 581

Auditoría avanzada con Aurora MySQL ...................................................................................... 593
Habilitar la auditoría avanzada .......................................................................................... 594
Visualización de registros de auditoría ................................................................................ 595
Detalles de los logs de auditoría ....................................................................................... 595
Replicación con Aurora MySQL ................................................................................................. 596
Réplicas de Aurora .......................................................................................................... 597
Opciones ....................................................................................................................... 597
Rendimiento ................................................................................................................... 598
Alta disponibilidad ........................................................................................................... 598
Monitorización ................................................................................................................. 599
Replicación de clústeres de base de datos Amazon Aurora MySQL entre distintas regiones de
AWS ............................................................................................................................. 599
Replicación entre Aurora y MySQL o entre Aurora y otro clúster de base de datos Aurora ........... 610
Uso de la replicación basada en GTID ............................................................................... 625
Integración de Aurora MySQL con los servicios de AWS ............................................................... 629
Autorización a Aurora MySQL a obtener acceso a otros servicios de AWS ............................... 629
Carga de datos desde archivos de texto en Amazon S3 ........................................................ 641
Almacenamiento de datos en archivos de texto en Amazon S3 .............................................. 649
Invocación de una función Lambda desde Aurora MySQL ..................................................... 655
Publicación de registros de Aurora MySQL en CloudWatch Logs ............................................ 662
Modo lab de Aurora MySQL ..................................................................................................... 665
Características del modo lab de Aurora .............................................................................. 666
Prácticas recomendadas con Amazon Aurora MySQL ................................................................... 667
Determinar a qué instancia de base de datos está conectado ................................................ 667
Uso de instancias T2 ....................................................................................................... 667
Invocar una función de AWS Lambda ................................................................................ 668
Uso de la captura previa de clave asíncrona ....................................................................... 669
Uso de esclavos de replicación con varios subprocesos en Amazon Aurora MySQL ................... 671
Uso de Amazon Aurora para escalar las lecturas de una base de datos de MySQL .................... 671
Uso de Amazon Aurora para la recuperación de desastres con sus bases de datos de MySQL ..... 674
Migración de MySQL a Amazon Aurora MySQL con un tiempo de inactividad reducido ............... 675
Uso de transacciones de XA con Amazon Aurora MySQL ..................................................... 675
Trabajo con combinaciones hash ....................................................................................... 675
Uso de claves externas .................................................................................................... 677
Referencia de Aurora MySQL ................................................................................................... 677
Parámetros ..................................................................................................................... 678
Parámetros y variables de estado de MySQL inaplicables ..................................................... 689
Eventos de Aurora MySQL ............................................................................................... 690
Procedimientos almacenados ............................................................................................ 692
Actualizaciones de Aurora MySQL ............................................................................................. 695
Versiones de Aurora MySQL ............................................................................................ 696
Versiones del motor de Aurora MySQL .............................................................................. 696
Actualizaciones de la base de datos y parches para Amazon Aurora MySQL ............................ 697
Aplicación de parches sin tiempo de inactividad ................................................................... 698
Actualizaciones del motor de base de datos para Amazon Aurora MySQL 2.0 ........................... 699
Actualizaciones del motor de base de datos para Amazon Aurora MySQL 1.1 ........................... 721
Errores de MySQL corregidos en las actualizaciones de Aurora MySQL ................................... 759
Uso de Aurora PostgreSQL .............................................................................................................. 770
Seguridad con Aurora PostgreSQL ............................................................................................ 770
Restricción de la administración de contraseñas .................................................................. 771
Migración de datos a Aurora PostgreSQL ................................................................................... 772
Migración de una instantánea de base de datos PostgreSQL de RDS ..................................... 773
Migración de una instancia de base de datos PostgreSQL de RDS mediante una réplica de
lectura de Aurora ............................................................................................................ 775

viii
Importación de datos S3 en Aurora PostgreSQL .................................................................. 784

Administración de Aurora PostgreSQL ........................................................................................ 795
Escalado de las instancias de base de datos Aurora PostgreSQL ........................................... 795
Número máximo de conexiones ........................................................................................ 795
Replicación con Aurora PostgreSQL .......................................................................................... 796
Réplicas de Aurora .......................................................................................................... 796
Monitorización de la replicación ......................................................................................... 797
Uso de la replicación lógica .............................................................................................. 797
Integración de Aurora PostgreSQL con los servicios de AWS ......................................................... 802
Administración de planes de ejecución de consultas para Aurora PostgreSQL ................................... 802
Habilitar la administración de planes de consultas ................................................................ 803
Habilitación de la administración de planes de consultas ....................................................... 804
Conceptos básicos .......................................................................................................... 804
Prácticas recomendadas para la administración de planes de consultas ................................... 807
Examinar planes en la vista dba_plans ............................................................................... 808
Capturar planes de ejecución ............................................................................................ 811
Uso de planes administrados ............................................................................................ 814
Mantenimiento de planes de ejecución ............................................................................... 817
Referencia de parámetros para la administración de planes de consultas ................................. 822
Referencia de funciones para la administración de planes de consultas ................................... 826
Recuperación rápida después de una conmutación por error ......................................................... 831
Configuración de la administración de la caché del clúster ..................................................... 831
Supervisión de la caché del búfer ...................................................................................... 834
Actualización de la versión del motor ......................................................................................... 835
Actualización manual de la versión del motor ...................................................................... 836
Actualización automática de la versión secundaria del motor .................................................. 837
Prácticas recomendadas con Aurora PostgreSQL ........................................................................ 838
Conmutación por error rápida ........................................................................................... 838
Solución de problemas de almacenamiento ......................................................................... 846
Referencia de Aurora PostgreSQL ............................................................................................. 846
Parámetros ..................................................................................................................... 846
Eventos de Amazon Aurora PostgreSQL ............................................................................ 855
Actualizaciones de Aurora PostgreSQL ...................................................................................... 856
Identificación de la versión ............................................................................................... 856
Actualización .................................................................................................................. 857
Versiones del motor de Aurora PostgreSQL ........................................................................ 857
Prácticas recomendadas con Aurora .................................................................................................. 872
Directrices operativas básicas de Amazon Aurora ....................................................................... 872
Recomendaciones de RAM de las instancias de base de datos ..................................................... 873
Monitorización de Amazon Aurora ............................................................................................ 873
Trabajo con los grupos de parámetros de base de datos y grupos de parámetros de clúster de base
de datos ................................................................................................................................ 873
Vídeo de presentación de las prácticas recomendadas de Amazon Aurora ....................................... 874
Ejecución de una prueba de concepto de Aurora ................................................................................. 875
Información general de una prueba de concepto de Aurora ........................................................... 875
1. Identifique sus objetivos ....................................................................................................... 875
2. Conozca las características de su carga de trabajo ................................................................... 876
3. Practique con la consola o la CLI .......................................................................................... 877
Practique con la consola .................................................................................................. 877
Practique con la CLI ........................................................................................................ 878
4. Cree su clúster de Aurora ..................................................................................................... 878
5. Configure el esquema .......................................................................................................... 879
6. Importe los datos ................................................................................................................ 880
7. Migre su código SQL ........................................................................................................... 880
8. Especifique las opciones de configuración ............................................................................... 881
9. Conéctese a Aurora ............................................................................................................. 881

ix
10. Ejecute la carga de trabajo ................................................................................................. 883

11. Medición del rendimiento .................................................................................................... 883
12. Pruebe la alta disponibilidad de Aurora ................................................................................. 885
13. Qué hacer a continuación ................................................................................................... 887
Límites ........................................................................................................................................... 889
Límites en Amazon Aurora ....................................................................................................... 889
Restricciones de la nomenclatura en Amazon Aurora ................................................................... 890
Límites de tamaño de archivo de Amazon Aurora ........................................................................ 891
Solución de problemas ..................................................................................................................... 892
No puede conectarse a la instancia de base de datos .................................................................. 892
Comprobar la conexión a la instancia de base de datos ........................................................ 893
Solución de problemas de autenticación de conexión ........................................................... 893
Problemas de seguridad ........................................................................................................... 893
Mensaje de error "No se pudieron recuperar los atributos de cuenta. Determinadas funciones de
la consola pueden estar deterioradas". ............................................................................... 894
Restablecimiento de la contraseña del rol del propietario de la instancia de base de datos .................. 894
Interrupción o reinicio de una instancia de base de datos .............................................................. 894
Los cambios de parámetros no surten efecto .............................................................................. 895
Problemas de memoria insuficiente de Aurora MySQL .................................................................. 895
Problemas de replicación de Aurora MySQL ............................................................................... 896
Diagnóstico y resolución de retardos entre réplicas de lectura ................................................ 896
Diagnóstico y resolución de un error de replicación de lectura de MySQL o MariaDB .................. 897
Error Slave Down or Disabled ........................................................................................... 898
Error de falta de espacio en el dispositivo ................................................................................... 899
Referencia de la API de Amazon RDS ............................................................................................... 900
Uso de la API de consulta ........................................................................................................ 900
Parámetros de consulta ................................................................................................... 900
Autenticación de solicitudes de consulta ............................................................................. 901
Solución de problemas de aplicaciones ...................................................................................... 901
Recuperación de errores .................................................................................................. 901
Consejos para la solución de problemas ............................................................................. 901
Historial de revisión ......................................................................................................................... 903

x
¿Qué es Amazon Aurora?

Amazon Aurora (Aurora) es un motor de base de datos relacional completamente administrado compatible
con MySQL y PostgreSQL. Ya sabe cómo MySQL y PostgreSQL combinan la velocidad y la fiabilidad de
las bases de datos comerciales de gama alta con la sencillez y la rentabilidad de las bases de datos de
código abierto. El código, las herramientas y las aplicaciones que se utilizan actualmente con las bases
de datos MySQL y PostgreSQL se pueden usar con Aurora. Con algunas cargas de trabajo, Aurora puede
proporcionar hasta cinco veces el rendimiento de MySQL y hasta tres veces el rendimiento de PostgreSQL
sin requerir cambios en la mayoría de las aplicaciones existentes.
Aurora incluye un subsistema de almacenamiento de alto rendimiento. Sus motores de base de datos
compatibles con MySQL y PostgreSQL están personalizados para aprovechar su almacenamiento de
rápida distribución. El almacenamiento subyacente aumenta de manera automática según se requiera,
hasta 64 terabytes. Aurora también automatiza y estandariza la agrupación en clústeres y la replicación,
que suelen ser algunos de los aspectos más problemáticos de la configuración y administración de las
bases de datos.
Aurora forma parte del servicio de bases de datos administradas Amazon Relational Database Service
(Amazon RDS). Amazon RDS es un servicio web que facilita las tareas de configuración, operación y
escalado de una base de datos relacional en la nube. Si no está familiarizado con Amazon RDS, consulte
la Guía del usuario de Amazon Relational Database Service.
En los siguientes puntos se ilustra la relación de Aurora con los motores de MySQL y PostgreSQL
estándares disponibles en Amazon RDS:
• Se debe elegir Aurora como opción del motor de base de datos al configurar nuevos servidores de base
de datos mediante Amazon RDS.
• Aurora aprovecha las características conocidas de Amazon Relational Database Service (Amazon RDS)
para la gestión y administración. Aurora usa la interfaz de la Consola de administración de AWS de
Amazon RDS, los comandos de la AWS CLI y las operaciones API para gestionar las tareas de base
de datos rutinarias como el aprovisionamiento, la aplicación de parches, las copias de seguridad, la
recuperación, la detección de errores y la reparación.
• Las operaciones de administración de Aurora normalmente afectan a clústeres completos de servidores
de base de datos sincronizados mediante replicación, en lugar de instancias de base de datos
individuales. La agrupación en clústeres, la replicación y la asignación de almacenamiento automáticas
simplifica y hace rentable configurar, usar y escalar las implementaciones de MySQL y PostgreSQL de
mayor tamaño.
• Puede trasladar datos de Amazon RDS para MySQL y de Amazon RDS para PostgreSQL a Aurora
creando y restaurando instantáneas, o bien configurando una replicación en un sentido. Puede usar
herramientas de migración que le permiten convertir sus aplicaciones de Amazon RDS para MySQL y de
Amazon RDS para PostgreSQL a Aurora con un solo botón.
Antes de usar Amazon Aurora, debe completar los pasos que figuran en Configuración del entorno para
Amazon Aurora (p. 50) y, después, revisar los conceptos y las características de Aurora que aparecen
en Clústeres de base de datos Amazon Aurora (p. 2).
Temas
• Clústeres de base de datos Amazon Aurora (p. 2)
• Administración de conexiones de Amazon Aurora (p. 3)
• Almacenamiento y fiabilidad de Amazon Aurora (p. 24)
• Seguridad de Amazon Aurora (p. 27)
• Alta disponibilidad para Aurora (p. 28)

1
Clústeres de base de datos Aurora
• Uso de Amazon Aurora Global Database (p. 29)

• Replicación con Amazon Aurora (p. 48)
Clústeres de base de datos Amazon Aurora

Un clúster de base de datos de Amazon Aurora se compone de una o varias instancias de base de datos
y de un volumen de clúster que administra los datos de esas instancias de base de datos. Un volumen de
clúster de Aurora es un volumen de almacenamiento de base de datos virtual que abarca varias zonas de
disponibilidad, de modo que una de esas zonas tiene una copia de los datos del clúster de base de datos.
Un clúster de base de datos Aurora se compone de dos tipos de instancias de base de datos:
• Instancia de base de datos principal: admite operaciones de lectura y escritura y realiza todas las
modificaciones de los datos en el volumen de clúster. Cada clúster de base de datos Aurora tiene una
instancia de base de datos principal.
• Réplica de Aurora: se conecta con el mismo volumen de almacenamiento que la instancia de base
de datos principal y solo admite operaciones de lectura. Cada clúster de base de datos Aurora puede
tener hasta 15 réplicas de Aurora, además de la instancia de base de datos principal. Puede mantener
una alta disponibilidad colocando réplicas de Aurora en zonas de disponibilidad separadas. Aurora
conmuta por error automáticamente a una réplica de Aurora en caso de que la instancia de base de
datos principal no esté disponible. Puede especificar la prioridad de conmutación por error para réplicas
de Aurora. Las réplicas de Aurora también pueden descargar las cargas de trabajo de lectura desde la
instancia de base de datos principal.
En el siguiente diagrama se ilustra la relación entre el volumen de clúster, la instancia de base de datos
principal y las réplicas de Aurora en un clúster de base de datos Aurora.
El clúster de Aurora muestra la separación de la capacidad informática y almacenamiento. Por ejemplo,

una configuración de Aurora con solo una instancia de base de datos sigue siendo un clúster, pero el
volumen de almacenamiento subyacente implica que haya varios nodos de almacenamiento distribuidos
en varias zonas de disponibilidad (AZ).

2
Administración de conexiones de Aurora
Administración de conexiones de Amazon Aurora

Amazon Aurora suele implicar un clúster de instancias de base de datos en lugar de una sola instancia.
Una instancia de base de datos específica gestiona cada conexión. Al conectarse a un clúster de Aurora,
el nombre de host y el puerto especificados apuntan a un controlador intermedio denominado punto
de enlace. Aurora usa el mecanismo de punto de enlace para abstraer estas conexiones. Por tanto, no
tiene que codificar todos los nombres de host o escribir su propia lógica para el equilibrio de carga y la
redirección de conexiones cuando algunas instancias de base de datos no están disponibles.
En determinadas tareas de Aurora, las diversas instancias o grupos de instancias desempeñan diferentes
roles. Por ejemplo, la instancia principal gestiona todas las instrucciones de lenguaje de definición de datos
(DDL) y de lenguaje de manipulación de datos (DML). Hasta 15 réplicas de Aurora gestionan el tráfico de
consultas de solo lectura.
Al usar puntos de enlace puede asignar cada conexión a la instancia o grupo de instancias adecuados en
función de su caso de uso. Por ejemplo, para realizar instrucciones DDL puede conectarse a la instancia
que sea la instancia principal. Para realizar consultas, puede conectarse al punto de enlace del lector,
con Aurora llevando a cabo de forma automática el equilibrio de carga entre todas las réplicas de Aurora.
En el caso de clústeres con instancias de base de datos de diferentes capacidades o configuraciones,
puede conectarse a puntos de enlace personalizados asociados a diversos subconjuntos de instancias de
base de datos. En el caso de diagnóstico o ajuste, puede conectarse a un punto de enlace de instancia
específico para examinar los detalles de una instancia de base de datos específica.
Temas
• Tipos de puntos de enlace de Aurora (p. 3)
• Visualización de los puntos de enlace para un clúster de Aurora (p. 5)
• Uso del punto de enlace de clúster (p. 5)
• Uso del punto de enlace del lector (p. 6)
• Uso de puntos de enlace personalizados (p. 6)
• Uso de los puntos de enlace de instancia (p. 23)
• Cómo funcionan los puntos de enlace de Aurora con la alta disponibilidad (p. 24)
Tipos de puntos de enlace de Aurora

Un punto de enlace se representa como URL específica de Aurora que contiene una dirección de host y un
puerto. Los siguientes tipos de puntos de enlace están disponibles en un clúster de base de datos Aurora.
Punto de enlace de clúster
Un punto de enlace de clúster de un clúster de base de datos Aurora que se conecta a la instancia de
base de datos principal actual de ese clúster de base de datos. Este punto de enlace es el único que
puede realizar operaciones de escritura como instrucciones DDL. Por este motivo, el punto de enlace
del clúster es el punto al que se conecta la primera vez que configura un clúster o bien si su clúster
solo contiene una única instancia de base de datos.
Cada clúster de base de datos de Aurora tiene un punto de enlace de clúster y una instancia de base
de datos principal.
Utilice el punto de enlace del clúster para todas las operaciones de escritura en el clúster de la base
de datos, incluidos inserciones, actualizaciones, eliminaciones y cambios de DDL. También puede
usar el punto de enlace del clúster para operaciones de lectura, como por ejemplo consultas.
El punto de enlace del clúster proporciona soporte de conmutación por error para conexiones de
lectura/escritura al clúster de base de datos. Si se produce un error en la instancia de base de datos

3
Tipos de puntos de enlace de Aurora
principal actual de un clúster de base de datos, Aurora conmuta por error automáticamente a una
nueva instancia de base de datos principal. Durante una conmutación por error, el clúster de base de
datos continúa atendiendo solicitudes de conexión al punto de enlace del clúster de la nueva instancia
de base de datos principal, con una interrupción del servicio mínima.
En el siguiente ejemplo se ilustra un punto de enlace del clúster de un clúster de base de datos Aurora
MySQL.
mydbcluster.cluster-123456789012.us-east-1.rds.amazonaws.com:3306
Punto de enlace del lector
Un punto de enlace del lector de un clúster de base de datos Aurora se conecta a una de las réplicas
de Aurora disponibles de ese clúster de base de datos. Cada clúster de base de datos Aurora tiene
un punto de enlace del lector. Si hay más de una réplica de Aurora, el punto de enlace del lector dirige
cada solicitud de conexión a una de las réplicas de Aurora.
El punto de enlace del lector proporciona soporte de equilibrio de carga para conexiones de solo
lectura al clúster de base de datos. Utilice el punto de enlace del lector para operaciones de lectura,
como por ejemplo consultas. No puede utilizar el punto de enlace del lector para las operaciones de
escritura.
El clúster de base de datos distribuye las solicitudes de conexión al punto de enlace del lector entre
las réplicas de Aurora disponibles. Si el clúster de base de datos contiene solo una instancia de base
de datos principal, el punto de enlace del lector atiende solicitudes de conexión de la instancia de base
de datos principal. Si se crean una o varias réplicas de Aurora para ese clúster de base de datos, la
carga de las conexiones posteriores al punto de enlace del lector se equilibra entre las réplicas.
En el siguiente ejemplo se ilustra un punto de enlace del lector de un clúster de base de datos Aurora
MySQL.
mydbcluster.cluster-ro-123456789012.us-east-1.rds.amazonaws.com:3306
Punto de enlace personalizado
Un punto de enlace personalizado de un clúster de Aurora representa un conjunto de instancias de

base de datos que ha elegido. Al conectarse al punto de enlace, Aurora realiza el equilibrio de carga y
elige una de las instancias del grupo para gestionar la conexión. Defina las instancias a las que hace
referencia este punto de enlace y decida el objetivo de este.
Un clúster de base de datos Aurora no tiene puntos de enlace personalizados hasta que crea uno.
Puede crear hasta cinco puntos de enlace personalizados para cada clúster de Aurora aprovisionado.
No puede usar puntos de enlace personalizados para clústeres de Aurora Serverless.
El punto de enlace personalizado proporciona conexiones de base de datos con equilibrio de carga en
función de otros criterios aparte de la capacidad de solo lectura o de lectura-escritura de las instancias
de base de datos. Por ejemplo, podría definir un punto de enlace personalizado para conectarse a
instancias que usan una clase de instancia de AWS particular o un grupo de parámetros de base de
datos particular. A continuación, podría informar a grupos de usuarios particulares acerca de este
punto de enlace personalizado. Por ejemplo, podría dirigir a los usuarios internos a instancias de baja
capacidad para la generación de informes o de consultas ad hoc (de una vez). También podría dirigir
el tráfico de producción a instancias de alta capacidad.
Dado que la conexión puede ir a cualquier instancia de base de datos que se asocie al punto de
enlace personalizado, recomendamos que se asegure de que todas las instancias de base de datos
de ese grupo comparten alguna característica similar. De esta forma se garantiza que el rendimiento,
la capacidad de memoria, etc. sean coherentes para todo aquel que se conecte a ese punto de
enlace.
Esta característica está destinada a usuarios avanzados con tipos de cargas de trabajo especializados
donde no resulta práctico que todas las réplicas de Aurora del clúster sean idénticas. Con los puntos

4
Visualización de puntos de enlace
de enlace personalizados, puede predecir la capacidad de la instancia de base de datos usada para
cada conexión. Al usar puntos de enlace personalizados, normalmente no usa el punto de enlace del
lector de ese clúster.
En el siguiente ejemplo se ilustra un punto de enlace personalizado de una instancia de base de datos
de un clúster de base de datos de Aurora MySQL.
myendpoint.cluster-custom-123456789012.us-east-1.rds.amazonaws.com:3306
Punto de enlace de instancia
Un punto de enlace de una instancia se conecta a una instancia de base de datos específica de un
clúster de Aurora. Cada instancia de base de datos de un clúster de base de datos tiene su propio
punto de enlace de instancia único. Así que hay un punto de enlace de instancia para la actual
instancia de base de datos principal del clúster de base de datos y un punto de enlace de instancia
para cada una de las réplicas de Aurora en el clúster de la base de datos.
El punto de enlace de la instancia proporciona un control directo sobre las conexiones al clúster de
base de datos, en los casos en los que el uso del punto de enlace del clúster o del lector puede no
ser adecuado. Por ejemplo, su aplicación cliente podría necesitar un balanceo de carga más detallado
en función del tipo de carga de trabajo. En este caso, puede configurar varios clientes para que se
conecten a distintas réplicas de Aurora de un clúster de base de datos con el fin de distribuir las
cargas de trabajo de lectura. Si quiere ver un ejemplo donde se usen puntos de enlace de la instancia
para mejorar la velocidad de conexión tras una conmutación por error de Aurora PostgreSQL, consulte
Conmutación por error rápida con Amazon Aurora PostgreSQL (p. 838). Si quiere ver un ejemplo
donde se usen puntos de enlace de la instancia para mejorar la velocidad de conexión tras una
conmutación por error de Aurora MySQL, consulte MariaDB Connector/J failover support – case
Amazon Aurora.
En el siguiente ejemplo se ilustra un punto de enlace de la instancia de una instancia de base de datos
de un clúster de base de datos Aurora MySQL.
mydbinstance.123456789012.us-east-1.rds.amazonaws.com:3306
Visualización de los puntos de enlace para un clúster

de Aurora
En la Consola de administración de AWS, verá el punto de enlace del clúster, el punto de enlace del lector
y cualquier punto de enlace personalizado en la página de detalles de cada clúster. Verá el punto de
enlace de instancia en la página de detalles de cada instancia. Al conectarse, debe añadir el número de
puerto asociado, tras el signo de dos puntos, al nombre de punto de enlace que se muestra en esta página
de detalles.
Con la AWS CLI, verá los puntos de enlace en la salida del comando describe-db-clusters.
Con la API de Amazon RDS, recuperará los puntos de enlace llamando a la función
DescribeDbClusterEndpoints.
Uso del punto de enlace de clúster

Como cada clúster de Aurora tiene un solo punto de enlace del clúster integrado cuyo nombre y otros
atributos se administran mediante Aurora, no puede crear, eliminar o modificar este tipo de punto de
enlace.
Use el punto de enlace del clúster al administrar su clúster, realizar la extracción, transformar, cargar
operaciones (ETL) o desarrollar y probar aplicaciones. El punto de enlace de clúster se conecta a la

5
Uso del punto de enlace del lector
instancia principal del clúster. La instancia principal es la única instancia de base de datos donde puede
crear tablas e índices, ejecutar instrucciones INSERT y realizar otras operaciones de DDL y DML.
La dirección IP física a la que apunta el punto de enlace del clúster cambia cuando el mecanismo de
conmutación por error promueve una nueva instancia de base de datos para que sea la instancia principal
de lectura-escritura del clúster. Si usa cualquier forma de grupos de conexiones u otros multiplexados,
prepárese para vaciar o reducir el tiempo de vida de cualquier información de DNS almacenada en caché.
De esta forma se garantiza que no intente establecer una conexión de lectura-escritura en una instancia de
base de datos que deje de estar disponible o sea ahora de solo lectura tras una conmutación por error.
Uso del punto de enlace del lector

Use el punto de enlace del lector para conexiones de solo lectura para su clúster de Aurora. Este punto de
enlace usa un mecanismo de equilibrio de carga para ayudar a su clúster a gestionar una carga de trabajo
con uso intensivo de consultas. El punto de enlace del lector es el punto de enlace que proporciona a las
aplicaciones que realizan informes u otras operaciones de solo lectura en el clúster.
El punto de enlace del lector solo balancea la carga de las conexiones con las réplicas de Aurora
disponibles de un clúster de base de datos Aurora. No equilibra la carga de consultas individuales. Si
desea equilibrar la carga de cada consulta para distribuir la carga de trabajo de lectura de un clúster de
base de datos, abra una nueva conexión al punto de enlace del lector para cada consulta.
Cada clúster de Aurora tiene un solo punto de enlace del lector integrado cuyo nombre y otros atributos se
administran mediante Aurora. No puede crear, eliminar o modificar este tipo de punto de enlace.
Uso de puntos de enlace personalizados

Puede usar puntos de enlace personalizados para simplificar la administración de la conexión si su clúster
contiene instancias de base de datos con diferentes capacidades y ajustes de configuración.
Anteriormente, podría haber usado el mecanismo CNAMES para configurar alias del servicio de nombres
de dominio (DNS) desde su propio dominio para lograr resultados similares. Al usar puntos de enlace
personalizados, puede evitar actualizar registros CNAME al aumentar o disminuir su clúster. Los puntos de
enlace personalizados también significan que puede usar conexiones Transport Layer Security/de capa de
conexión segura (TLS/SSL).
En lugar de usar una instancia de base de datos para cada propósito especializado y conectarse a su
punto de enlace de instancia, puede tener varios grupos de instancias de base de datos especializadas.
En este caso, cada grupo tiene su propio punto de enlace personalizado. De esta forma, Aurora puede
realizar el equilibrio de carga entre todas las instancias dedicadas a tareas como la creación de informes
o la gestión de consultas de producción o internas. Los puntos de enlace personalizados proporcionan
equilibrio de carga y alta disponibilidad para cada grupo de instancias de base de datos dentro de su
clúster. Si una de las instancias de base de datos dentro de un grupo deja de estar disponible, Aurora
dirige conexiones de punto de enlace personalizado posteriores a una de las otras instancias de base de
datos asociadas al mismo punto de enlace.
Temas
• Especificación de propiedades para puntos de enlace personalizados (p. 7)
• Reglas de afiliación para puntos de enlace personalizados (p. 7)
• Administración de puntos de enlace personalizados (p. 8)
• Creación de un punto de enlace personalizado (p. 9)
• Visualización de puntos de enlace personalizados (p. 11)
• Edición de un punto de enlace personalizado (p. 16)
• Eliminación de un punto de enlace personalizado (p. 18)

6
• Ejemplo de AWS CLI integral para puntos de enlace personalizados (p. 19)
Especificación de propiedades para puntos de enlace

personalizados
La longitud máxima de un nombre de punto de enlace personalizado es 63 caracteres. Puede ver el
formato de nombre a continuación:
endpointName.cluster-custom-customerDnsIdentifier.dnsSuffix
Dado que los nombres de punto de enlace personalizado no incluyen el nombre de su clúster, no tiene que
cambiar esos nombres si cambia el nombre de un clúster. No puede volver a usar el mismo nombre de
punto de enlace personalizado para más de un clúster en la misma región. Especifique un nombre para
cada punto de enlace personalizado que sea único en los clústeres que pertenecen a su ID de usuario
dentro de una región particular.
Cada punto de enlace personalizado tiene un tipo asociado que determina qué instancias de base de datos
cumplen los requisitos para asociarse a ese punto de enlace. En la actualidad, el tipo puede ser READER o
ANY. Las siguientes consideraciones se aplican a los tipos de punto de enlace personalizado:
• Solo las instancias de base de datos que son réplicas de Aurora de solo lectura pueden formar parte de
un punto de enlace personalizado READER. El tipo READER se aplica solo a aquellos clústeres que usan
un modelo de replicación maestro único, ya que esos clústeres pueden incluir varias instancias de base
de datos de solo lectura.
• Tanto las réplicas de Aurora de solo lectura como la instancia principal de lectura-escritura pueden
formar parte de un punto de enlace personalizado ANY. Aurora dirige las conexiones a puntos de enlace
del clúster con tipo ANY a cualquier instancia de base de datos asociada con la misma probabilidad.
Como no puede determinar con antelación si se conecta a la instancia principal de una réplica de Aurora
de solo lectura, use este tipo de punto de enlace solo para conexiones de solo lectura. El tipo ANY se
aplica a los clústeres que usan cualquier topología de replicación.
• Si intenta crear un punto de enlace personalizado con un tipo que no es adecuado en función de la
configuración de replicación para un clúster, Aurora devuelve un error.
Reglas de afiliación para puntos de enlace personalizados

Al añadir una instancia de base de datos a un punto de enlace personalizado o quitarla de un punto de
enlace personalizado, cualquier conexión existente a esa instancia de base de datos permanece activa.
Puede definir una lista de instancias de base de datos que se incluirán en un punto de enlace
personalizado o se excluirán de este. Nos referimos a estas listas como listas estáticas y de exclusión,
respectivamente. Puede usar el mecanismo de inclusión/exclusión para seguir subdividiendo los grupos
de instancias de base de datos y asegurarse de que el conjunto de puntos de enlace personalizados cubre
todas las instancias de base de datos en el clúster. Cada punto de enlace personalizado puede contener
solo uno de estos tipos de lista.
En la Consola de administración de AWS, la casilla Attach future instances added to this cluster (Asociar
futuras instancias añadidas a este clúster) representa la opción. Al dejar la casilla desactivada, el
punto de enlace personalizado usa una lista estática que contiene solo las instancias de base de datos
especificadas en el cuadro de diálogo. Al activar la casilla, el punto de enlace personalizado usa una lista
de exclusión. En este caso, el punto de enlace personalizado representa todas las instancias de base de
datos del clúster (incluidas las añadidas en el futuro), excepto las que se han dejado desactivadas en el
cuadro de diálogo. Las API de AWS CLI y Amazon RDS tienen parámetros que representan cada tipo de
lista. Al usar las API de AWS CLI o Amazon RDS, no puede añadir o quitar miembros individuales a las
listas; especifique siempre la nueva lista al completo.

7
Aurora no cambia las instancias de base de datos especificadas en estas listas cuando las instancias
de base de datos cambian los roles entre la instancia principal y la réplica de Aurora debido a una
conmutación por error o a una promoción. Por ejemplo, un punto de enlace personalizado con tipo
READER podría incluir una instancia de base de datos que era una réplica de Aurora y, a continuación,
se promocionó a una instancia principal. Sin embargo, solo puede conectarse a una instancia de base
de datos a través de un punto de enlace personalizado si esa instancia de base de datos tiene un rol
compatible con el tipo del punto de enlace personalizado (READER o ANY).
Puede asociar una instancia de base de datos a más de un punto de enlace personalizado. Por ejemplo,
supongamos que añade una nueva instancia de base de datos a un clúster, o que Aurora añade una
instancia de base de datos automáticamente a través del mecanismo de Auto Scaling. En estos casos, la
instancia de base de datos se añade a todos los puntos de enlace personalizados para los que cumple
los requisitos. A qué puntos de enlace se añade la instancia de base de datos se basa en el tipo de punto
de enlace personalizado de READER o ANY, más cualquier lista estática o de exclusión definida para cada
punto de enlace. Por ejemplo, si el punto de enlace incluye una lista estática de instancias de base de
datos, las réplicas de Aurora recién añadidas no se añaden a ese punto de enlace. Por el contrario, si el
punto de enlace tiene una lista de exclusión, las réplicas de Aurora recién añadidas se añaden al punto
de enlace, si no se menciona en la lista de exclusión y sus roles coinciden con el tipo del punto de enlace
personalizado.
Si una réplica de Aurora deja de estar disponible, permanece asociada a cualquier punto de enlace
personalizado. Por ejemplo, sigue formando parte del punto de enlace personalizado si está en mal estado,
se detiene, se reinicia, etc. Sin embargo, no podrá conectarse a ella a través de esos puntos de enlace
hasta que vuelva a estar disponible.
Administración de puntos de enlace personalizados

Dado que los clústeres de Aurora recién creados no tienen ningún punto de enlace personalizado, debe
crear y administrar estos objetos usted mismo. Para ello, use la API de Consola de administración de
AWS, AWS CLI o Amazon RDS.
Note
También debe crear y administrar puntos de enlace personalizados para clústeres de Aurora
restaurados a partir de instantáneas. Los puntos de enlace personalizados no se incluyen en la
instantánea. Vuélvalos a crear tras la restauración y elija nuevos nombres de punto de enlace si el
clúster restaurado está en la misma región que el original.
Para trabajar con puntos de enlace personalizados desde la Consola de administración de AWS, vaya a la
página de detalles para su clúster de Aurora y use los controles de la sección Custom Endpoints (Puntos
de enlace personalizados).
Para trabajar con puntos de enlace personalizados desde la AWS CLI, puede usar estas operaciones:
• create-db-cluster-endpoint
• describe-db-cluster-endpoints
• modify-db-cluster-endpoint
• delete-db-cluster-endpoint
Para trabajar con puntos de enlace personalizados a través de la API de Amazon RDS, puede usar las
siguientes funciones:
• CreateDBClusterEndpoint
• DescribeDBClusterEndpoints
• ModifyDBClusterEndpoint
• DeleteDBClusterEndpoint

8
Creación de un punto de enlace personalizado

Consola de administración de AWS
Para crear un punto de enlace personalizado con la Consola de administración de AWS, vaya a la página
de detalles del clúster y elija la acción Create custom endpoint en la sección Endpoints (Puntos de
enlace). Elija un nombre para el punto de enlace personalizado, único para su ID de usuario y región. Para
elegir una lista de instancias de base de datos que se conserve igual incluso a medida que se amplía el
clúster, deje la casilla Attach future instances added to this cluster (Asociar futuras instancias añadidas a
este clúster). Al activar esa casilla, el punto de enlace personalizado añade de forma dinámica cualquier
nueva instancia a medida que se añaden al clúster.

9

10
No puede seleccionar el tipo de punto de enlace personalizado de ANY o READER en la Consola de

administración de AWS. Todos los puntos de enlace personalizados que crea a través de la Consola de
administración de AWS tienen un tipo de ANY.
AWS CLI
Para crear un punto de enlace personalizado con la AWS CLI, ejecute el comando create-db-cluster-
endpoint.
El siguiente comando crea un punto de enlace personalizado asociado a un clúster específico. En un

primer momento, el punto de enlace se asocia a todas las instancias de réplica de Aurora del clúster. Un
comando posterior lo asocia a un conjunto específico de instancias de base de datos del clúster.
Para Linux, OS X o Unix:
aws rds create-db-cluster-endpoint --db-cluster-endpoint-identifier custom-endpoint-doc-

sample \
--endpoint-type reader \
--db-cluster-identifier cluster_id
aws rds modify-db-cluster-endpoint --db-cluster-endpoint-identifier custom-endpoint-doc-

sample \
--static-members instance_name_1 instance_name_2
Para Windows:
aws rds create-db-cluster-endpoint --db-cluster-endpoint-identifier custom-endpoint-doc-

sample ^
--endpoint-type reader ^
aws rds modify-db-cluster-endpoint --db-cluster-endpoint-identifier custom-endpoint-doc-

sample ^
--static-members instance_name_1 instance_name_2
API de RDS
Para crear un punto de enlace personalizado con la API de RDS, ejecute la acción
CreateDBClusterEndpoint.
Visualización de puntos de enlace personalizados

Para ver puntos de enlace personalizados con la Consola de administración de AWS, vaya a la
página de detalles del clúster y busque en la sección Endpoints (Puntos de enlace). Esta sección solo
contiene información sobre puntos de enlace personalizados. Los detalles de los puntos de enlace
integrados aparecen en la sección Details (Detalles) principal. Para ver los detalles de un punto de enlace
personalizado específico, seleccione su nombre para abrir la página de detalles para ese punto de enlace.
En la siguiente captura de pantalla se muestra cómo la lista de puntos de enlace personalizados para un
clúster de Aurora está inicialmente vacía.

11
Tras crear algunos puntos de enlace personalizados para ese clúster, se muestran en la sección Endpoints
(Puntos de enlace).

12
Al hacer clic en la página de detalles se muestran las instancias de base de datos a las que se asocia el
punto de enlace actualmente.

13

14
Para ver el detalle adicional de si las nuevas instancias de base de datos añadidas al clúster se añaden
automáticamente al punto de enlace también, abra el cuadro de diálogo Edit (Editar) para el punto de
enlace.
AWS CLI
Para ver puntos de enlace personalizados con la AWS CLI, ejecute el comando describe-db-cluster-
endpoints.
El siguiente comando muestra los puntos de enlace personalizados asociados a un clúster especificado
en una región especificada. La salida incluye los puntos de enlace integrados y cualquier punto de enlace
personalizado.
aws rds describe-db-cluster-endpoints --region region_name \

Para Windows:
aws rds describe-db-cluster-endpoints --region region_name ^

A continuación, se muestran algunos resultados de ejemplo de un comando describe-db-cluster-

endpoints. El EndpointType de WRITER o READER denota los puntos de enlace de lectura-escritura
integrados y de solo lectura para el clúster. El EndpointType de CUSTOM denota los puntos de enlace
que crea y elija las instancias de base de datos asociadas. Uno de los puntos de enlace tiene un campo
StaticMembers no vacío, lo que denota que se asocia a un conjunto preciso de instancias de base
de datos. El otro punto de enlace tiene un campo ExcludedMembers no vacío, lo que denota que
el punto de enlace se asocia a todas las instancias de base de datos que no sean las que figuran en
ExcludedMembers. Este segundo tipo de punto de enlace personalizado aumenta para incorporar nuevas
instancias a medida que se añaden al clúster.
{
"DBClusterEndpoints": [
{
"Endpoint": "custom-endpoint-demo.cluster-123456789012.ca-central-1.rds.amazonaws.com",
"Status": "available",
"DBClusterIdentifier": "custom-endpoint-demo",
"EndpointType": "WRITER"
},
{
"Endpoint": "custom-endpoint-demo.cluster-ro-123456789012.ca-
central-1.rds.amazonaws.com",
"EndpointType": "READER"
},
{
"CustomEndpointType": "ANY",
"DBClusterEndpointIdentifier": "powers-of-2",
"ExcludedMembers": [],
"EndpointType": "CUSTOM",
"Endpoint": "powers-of-2.cluster-custom-123456789012.ca-central-1.rds.amazonaws.com",

15
"StaticMembers": [
"custom-endpoint-demo-04",
"custom-endpoint-demo-02"
],
"DBClusterEndpointResourceIdentifier": "cluster-endpoint-W7PE3TLLFNSHXQKFU6J6NV5FHU",
"DBClusterEndpointArn": "arn:aws:rds:ca-central-1:111122223333:cluster-endpoint:powers-
of-2"
},
{
"DBClusterEndpointIdentifier": "eight-and-higher",
"ExcludedMembers": [
],
"Endpoint": "eight-and-higher.cluster-custom-123456789012.ca-
"StaticMembers": [],
"DBClusterEndpointResourceIdentifier": "cluster-endpoint-W7PE3TLLFNSHYQKFU6J6NV5FHU",
"DBClusterEndpointArn": "arn:aws:rds:ca-central-1:111122223333:cluster-endpoint:eight-
and-higher"
}
]
}
API de RDS
Para ver puntos de enlace personalizados con la API de RDS, ejecute la acción
DescribeDBClusterEndpoints.html.
Edición de un punto de enlace personalizado

Puede editar las propiedades de un punto de enlace personalizado para cambiar las instancias de base de
datos asociadas al punto de enlace. También puede cambiar un punto de enlace entre una lista estática y
una lista de exclusión. Si necesita más detalles acerca de estas propiedades de punto de enlace, consulte
Reglas de afiliación para puntos de enlace personalizados (p. 7).
No puede conectarse a un punto de enlace personalizado o usarlo mientras los cambios de una acción de
edición están en curso. Podrían pasar algunos minutos hasta que el estado del punto de enlace vuelva a
ser Available (Disponible) y usted pueda volver a conectarse.
Para editar un punto de enlace personalizado con la Consola de administración de AWS, puede
seleccionar el punto de enlace en la página de detalles del clúster o abrir la página de detalles para el
punto de enlace y elegir la acción Edit (Editar).

16

17
AWS CLI
Para editar un punto de enlace personalizado con la AWS CLI, ejecute el comando modify-db-cluster-
endpoint.
Los siguientes comandos cambian el conjunto de instancias de base de datos que se aplican a un punto
de enlace personalizado y, de forma opcional, se alterna entre el comportamiento de una lista estática o de
exclusión. Los parámetros --static-members y --excluded-members toman una lista separada por
espacios de identificadores de instancias de bases de datos.
aws rds modify-db-cluster-endpoint --db-cluster-endpoint-identifier my-custom-endpoint \

--static-members db-instance-id-1 db-instance-id-2 db-instance-id-3 \
--region region_name
aws rds modify-db-cluster-endpoint --db-cluster-endpoint-identifier my-custom-endpoint \

--excluded-members db-instance-id-4 db-instance-id-5 \
Para Windows:
aws rds modify-db-cluster-endpoint --db-cluster-endpoint-identifier my-custom-endpoint ^

--static-members db-instance-id-1 db-instance-id-2 db-instance-id-3 ^
aws rds modify-db-cluster-endpoint --db-cluster-endpoint-identifier my-custom-endpoint ^

--excluded-members db-instance-id-4 db-instance-id-5 ^
API de RDS
Para editar un punto de enlace personalizado con la API de RDS, ejecute la acción
ModifyDBClusterEndpoint.html.
Eliminación de un punto de enlace personalizado

Para eliminar un punto de enlace personalizado con la Consola de administración de AWS, vaya a la
página de detalles del clúster, seleccione el punto de enlace personalizado adecuado y seleccione la
acción Delete (Eliminar).

18
AWS CLI
Para eliminar un punto de enlace personalizado con la AWS CLI, ejecute el comando delete-db-cluster-
endpoint.
El siguiente comando elimina un punto de enlace personalizado. No tiene que especificar el clúster
asociado, pero debe especificar la región.
aws rds delete-db-cluster-endpoint --db-cluster-endpoint-identifier custom-end-point-id \

Para Windows:
aws rds delete-db-cluster-endpoint --db-cluster-endpoint-identifier custom-end-point-id ^

API de RDS
Para eliminar un punto de enlace personalizado con la API de RDS, ejecute la acción
DeleteDBClusterEndpoint.
Ejemplo de AWS CLI integral para puntos de enlace

personalizados
En el siguiente tutorial se usan ejemplos de AWS CLI con sintaxis de shell Unix para mostrar que podría
definir un clúster con varias instancias de base de datos "pequeñas" y algunas instancias de base de
datos "grandes", además de crear puntos de enlace personalizados para conectarse a cada conjunto
de instancias de base de datos. Para ejecutar comandos similares en su propio sistema, debe estar
suficientemente familiarizado con los aspectos básicos de trabajar con los clústeres de Aurora y el uso
de la AWS CLI para proporcionar sus propios valores para parámetros como región, grupo de subredes y
grupo de seguridad de VPC.
En este ejemplo se muestran los pasos de configuración iniciales: creación de un clúster de Aurora y
adición de instancias de base de datos a este. Este es un clúster heterogéneo, lo que significa que no
todas las instancias de base de datos tienen la misma capacidad. La mayoría de las instancias usan la
clase de instancia de AWS db.r4.4xlarge, pero las dos últimas instancias de base de datos usan
db.r4.16xlarge. Cada uno de estos comandos create-db-instance de ejemplo muestra su
resultado en la pantalla y ahorra una copia del JSON en un archivo para su posterior inspección.
aws rds create-db-cluster --db-cluster-identifier custom-endpoint-demo --engine aurora \

--engine-version 5.6.10a --master-username $MASTER_USER --master-user-password
$MASTER_PW \
--db-subnet-group-name $SUBNET_GROUP --vpc-security-group-ids $VPC_SECURITY_GROUP \
--region $REGION
for i in 01 02 03 04 05 06 07 08
do
aws rds create-db-instance --db-instance-identifier custom-endpoint-demo-${i} \
--engine aurora --db-cluster-identifier custom-endpoint-demo --db-instance-class
db.r4.4xlarge \
--region $REGION \
| tee custom-endpoint-demo-${i}.json

19
done
for i in 09 10
do
aws rds create-db-instance --db-instance-identifier custom-endpoint-demo-${i} \
--engine aurora --db-cluster-identifier custom-endpoint-demo --db-instance-class
db.r4.16xlarge \
--region $REGION \
| tee custom-endpoint-demo-${i}.json
done
Las instancias más grandes están reservadas para tipos especializados de consultas de informes. Para
que sea poco probable que se conviertan en la instancia principal, en el siguiente ejemplo la prioridad de
su nivel de promoción pasa a ser la más baja.
for i in 09 10
do
aws rds modify-db-instance --db-instance-id custom-endpoint-demo-${i} \
--region $REGION --promotion-tier 15
done
Supongamos que desea usar las dos instancias "más grandes" solo para las consultas que más recursos
consumen. Puede crear un punto de enlace de solo lectura personalizado y, a continuación, añadir una
lista estática de miembros para que el punto de enlace se conecte solo a esas instancias de base de
datos. El nivel de promoción de esas instancias ya es el más bajo, lo que reduce la probabilidad de que
cualquiera de ellas se convierta alguna vez en la instancia principal. Si una de ellas se convirtiera en la
instancia principal, resultaría inaccesible a través de este punto de enlace, ya que especificamos el tipo
READER en lugar del tipo ANY. En el siguiente ejemplo se muestran los comandos de punto de enlace de
creación y modificación, así como la salida JSON de ejemplo que muestra el estado inicial y modificado del
punto de enlace personalizado.
$ aws rds create-db-cluster-endpoint --region $REGION \

--db-cluster-identifier custom-endpoint-demo \
--db-cluster-endpoint-identifier big-instances --endpoint-type reader
{
"Endpoint": "big-instances.cluster-custom-123456789012.ca-central-1.rds.amazonaws.com",
"DBClusterEndpointIdentifier": "big-instances",
"CustomEndpointType": "READER",
"Status": "creating",
"DBClusterEndpointArn": "arn:aws:rds:ca-central-1:111122223333:cluster-endpoint:big-
instances"
}
$ aws rds modify-db-cluster-endpoint --db-cluster-endpoint-identifier big-instances \

--static-members custom-endpoint-demo-09 custom-endpoint-demo-10 --region $REGION
{
"DBClusterEndpointArn": "arn:aws:rds:ca-central-1:111122223333:cluster-endpoint:big-
instances",
"StaticMembers": [

20
],
"Status": "modifying",
"Endpoint": "big-instances.cluster-custom-123456789012.ca-central-1.rds.amazonaws.com",
"DBClusterIdentifier": "custom-endpoint-demo"
}
El punto de enlace READER predeterminado del clúster puede conectarse a las instancias de base de
datos "pequeñas" o "grandes", lo que hace poco práctico predecir el rendimiento y la escalabilidad de las
consultas cuando el clúster está ocupado. Para dividir la carga de trabajo limpiamente entre los conjuntos
de instancias de base de datos, puede omitir el punto de enlace READER predeterminado y crear un
segundo punto de enlace personalizado que se conecte a las demás instancias de base de datos. El
siguiente ejemplo lo hace creando un punto de enlace personalizado y, a continuación, añadiendo una lista
de exclusión. Cualquier otra instancia de base de datos que añada al clúster posteriormente se añadirá a
este punto de enlace automáticamente. El tipo ANY significa que este punto de enlace se asocia a ocho
instancias en total: la instancia principal y otras siete réplicas de Aurora. Si en el ejemplo se usó el tipo
READER, el punto de enlace personalizado solo se asociaría a las siete réplicas de Aurora.
$ aws rds create-db-cluster-endpoint --region $REGION --db-cluster-identifier custom-

endpoint-demo \
--db-cluster-endpoint-identifier small-instances --endpoint-type any
{
"Status": "creating",
"DBClusterEndpointIdentifier": "small-instances",
"Endpoint": "small-instances.cluster-custom-123456789012.ca-
"DBClusterEndpointArn": "arn:aws:rds:ca-central-1:111122223333:cluster-endpoint:small-
instances",
"DBClusterEndpointResourceIdentifier": "cluster-endpoint-6RDDXQOC3AKKZT2PRD7ST37BMY"
}
$ aws rds modify-db-cluster-endpoint --db-cluster-endpoint-identifier small-instances \

--excluded-members custom-endpoint-demo-09 custom-endpoint-demo-10 --region $REGION
{
"DBClusterEndpointArn": "arn:aws:rds:ca-central-1:111122223333:cluster-endpoint:small-
instances",
"DBClusterEndpointResourceIdentifier": "cluster-endpoint-6RDDXQOC3AKKZT2PRD7ST37BMY",
],
"Status": "modifying"
}
En el siguiente ejemplo se comprueba el estado de los puntos de enlace de este clúster. El clúster aún
tiene su punto de enlace del clúster original, con EndPointType de WRITER, que aún usaría para la
administración, ETL y otras operaciones de escritura. Aún tiene su punto de enlace READER original,
que no usaría porque cada conexión a este podría dirigirse a una instancia de base de datos "pequeña"
o "grande". Los puntos de enlace personalizados hacen que este comportamiento sea predecible, con

21
conexiones garantizadas para usar una de las instancias de base de datos "pequeñas" o "grandes" en
función del punto de enlace que especifique.
$ aws rds describe-db-cluster-endpoints --region $REGION

{
"DBClusterEndpoints": [
{
"EndpointType": "WRITER",
"Endpoint": "custom-endpoint-demo.cluster-123456789012.ca-
},
{
"EndpointType": "READER",
"Endpoint": "custom-endpoint-demo.cluster-ro-123456789012.ca-
},
{
"DBClusterEndpointArn": "arn:aws:rds:ca-central-1:111122223333:cluster-
endpoint:small-instances",
],
"DBClusterEndpointResourceIdentifier": "cluster-
endpoint-6RDDXQOC3AKKZT2PRD7ST37BMY",
"Status": "modifying"
},
{
"Endpoint": "big-instances.cluster-custom-123456789012.ca-
"DBClusterEndpointArn": "arn:aws:rds:ca-central-1:111122223333:cluster-
endpoint:big-instances",
"DBClusterEndpointResourceIdentifier": "cluster-endpoint-
W7PE3TLLFNSHXQKFU6J6NV5FHU",
"StaticMembers": [
],
"Status": "available"
}
]
}
En el ejemplo final se muestra cómo conexiones de base de datos sucesivas a los puntos de enlace
personalizados se conectan a las diversas instancias de base de datos del clúster de Aurora. El punto de
enlace small-instances siempre se conecta a las instancias de base de datos db.r4.4xlarge, que
son los hosts con la numeración más baja de este clúster.

22
Uso de los puntos de enlace de instancia
$ mysql -h small-instances.cluster-custom-123456789012.ca-central-1.rds.amazonaws.com -u
$MYUSER -p
mysql> select @@aurora_server_id;
+-------------------------+
| @@aurora_server_id |
+-------------------------+
| custom-endpoint-demo-02 |
+-------------------------+
$MYUSER -p
+-------------------------+
+-------------------------+
+-------------------------+
$MYUSER -p
+-------------------------+
+-------------------------+
+-------------------------+
El punto de enlace big-instances siempre se conecta a las instancias de base de datos

db.r4.16xlarge, que son los dos hosts con la numeración más alta de este clúster.
$ mysql -h big-instances.cluster-custom-123456789012.ca-central-1.rds.amazonaws.com -u
$MYUSER -p
+-------------------------+
+-------------------------+
+-------------------------+
$ mysql -h big-instances.cluster-custom-123456789012.ca-central-1.rds.amazonaws.com -u
$MYUSER -p
+-------------------------+
+-------------------------+
+-------------------------+
Uso de los puntos de enlace de instancia

En las operaciones diarias, su forma principal de uso de los puntos de enlace de instancia consiste en
diagnosticar los problemas de rendimiento o capacidad que afectan a una instancia específica de un
clúster de Aurora. Mientras se conecta a una instancia específica, puede examinar sus variables de
estado, métricas, etc. Hacer esto puede ayudarle a determinar qué sucede con esa instancia que es
distinto de lo que ocurre con otras instancias del clúster.
En los casos de uso avanzados, podría configurar algunas instancias de base de datos de manera
distinta a otras. En este caso, use el punto de enlace de instancia para conectarse directamente a una
instancia que sea más pequeña, más grande o que, de otro modo, tenga características distintas del

23
Puntos de enlace y alta disponibilidad
resto. Asimismo, configure la prioridad de conmutación por error para que esta instancia de base de datos
especial sea la última opción para hacerse cargo como instancia principal. Recomendamos que use puntos
de enlace personalizados en lugar del punto de enlace de instancia en estos casos. Al hacerlo se simplifica
la administración de la conexión y la alta disponibilidad a medida que añade más instancias de base de
datos a su clúster.
Cada instancia de base de datos en un clúster de Aurora tiene su propio punto de enlace de instancia
integrado, cuyo nombre y otros atributos administra Aurora. No puede crear, eliminar o modificar este tipo
de punto de enlace.
Cómo funcionan los puntos de enlace de Aurora con

la alta disponibilidad
Para clústeres en los que la alta disponibilidad es importante, cuando sea factible, use el punto de enlace
del clúster para conexiones de lectura-escritura y el punto de enlace del lector para conexiones de solo
lectura. Estos tipos de conexiones administran la conmutación por error de la instancia de base de datos
mejor de lo que lo hacen los puntos de enlace de instancia. Los puntos de enlace de instancia se conectan
a una instancia de base de datos específica en un clúster de base de datos, lo que requiere lógica en
su aplicación para elegir un punto de enlace diferente si la instancia de base de datos deja de estar
disponible.
Si se produce un error en la instancia de base de datos principal de un clúster de base de datos,

Aurora conmuta por error automáticamente a una nueva instancia de base de datos principal. Lo hace
promoviendo una réplica de Aurora existente a una nueva instancia de base de datos principal o creando
una instancia de base de datos principal. Si se produce una conmutación por error, puede usar el punto
de enlace del clúster para volver a conectarse a la instancia de base de datos recién promovida o creada,
o bien usar el punto de enlace del lector para volver a conectarse a una de las réplicas de Aurora del
clúster de base de datos. Durante una conmutación por error, el punto de enlace del lector podría dirigir
las conexiones a la nueva instancia de base de datos principal de un clúster de base de datos durante un
breve periodo tras convertirse una réplica de Aurora en la nueva instancia de base de datos principal.
Si diseña su propia lógica de aplicación para administrar conexiones a puntos de enlace de instancia,
puede, manualmente o mediante programación, encontrar el conjunto resultante de instancias de base de
datos disponibles en el clúster de base de datos. Luego puede confirmar sus clases de instancia tras la
conmutación por error y conectarse a un punto de enlace de instancia adecuado.
Para obtener más información acerca de las conmutaciones por error, consulte Tolerancia a errores para
un clúster de base de datos de Aurora (p. 314).
Almacenamiento y fiabilidad de Amazon Aurora

A continuación, puede obtener información sobre el subsistema de almacenamiento de Aurora. Aurora
usa una arquitectura de almacenamiento distribuida y compartida que es un factor importante en el
rendimiento, la escalabilidad y la fiabilidad para los clústeres de Aurora.
Temas
• Información general del almacenamiento de Aurora (p. 25)
• Qué contiene el volumen del clúster (p. 25)
• Cómo aumenta el almacenamiento de Aurora (p. 25)
• Cómo se factura el almacenamiento de datos de Aurora (p. 25)
• Fiabilidad de Amazon Aurora (p. 26)

24
Información general del almacenamiento de Aurora
Información general del almacenamiento de Aurora

Los datos de Aurora se almacenan en el volumen del clúster, que es un volumen único y virtual que
usa unidades de estado sólido (SSD). Un volumen de clúster se compone de copias de los datos
repartidas entre varias zonas de disponibilidad de una sola región de AWS. Como los datos se replican
automáticamente entre las distintas zonas de disponibilidad, tienen una larga duración y se reduce el
riesgo de pérdida de datos. Esta replicación también garantiza que su base de datos esté más disponible
durante una conmutación por error. Esto es así porque las copias de datos ya existen en las otras zonas
de disponibilidad y continúan respondiendo a las solicitudes de datos de las instancias de base de datos
de su clúster de base de datos. La cantidad de réplicas es independiente del número de instancias de base
de datos de su clúster.
Qué contiene el volumen del clúster

El volumen del clúster de Aurora contiene todos sus datos de usuario, objetos de esquema y metadatos
internos como las tablas del sistema y el registro binario. Por ejemplo, Aurora almacena todas las tablas,
índices, objetos binarios grandes (BLOB), procedimientos almacenados, etc. para un clúster de Aurora en
el volumen del clúster.
La arquitectura de almacenamiento compartida de Aurora hace que sus datos sean independientes de
las instancias de base de datos del clúster. Por ejemplo, puede añadir una instancia de base de datos
rápidamente, ya que Aurora no hace una nueva copia de los datos de la tabla. En su lugar, la instancia
de base de datos se conecta al volumen compartido que ya contiene todos sus datos. Puede quitar una
instancia de base de datos de un clúster sin quitar los datos subyacentes del clúster. Solo al eliminar todo
el clúster, Aurora elimina los datos.
Cómo aumenta el almacenamiento de Aurora

Los volúmenes de clúster de Aurora crecen automáticamente a medida que se incrementa la cantidad de
datos de la base de datos. Un volumen de clúster de Aurora puede crecer hasta un tamaño máximo de
64 tebibytes (TiB). El tamaño de la tabla viene limitado por el tamaño del volumen del clúster. Es decir, el
tamaño máximo de una tabla de un clúster de base de datos Aurora es de 64 TiB.
Este escalado de almacenamiento automático, en combinación con el alto rendimiento y el subsistema

de almacenamiento altamente distribuido, hace que Aurora sea una buena opción para sus datos
empresariales importantes cuando sus objetivos principales son la fiabilidad y la alta disponibilidad.
Consulte las siguientes secciones en busca de formas de cuadrar los costos de almacenamiento con estas
otras prioridades.
Cómo se factura el almacenamiento de datos de

Aurora
Aunque un volumen de clúster de Aurora puede aumentar hasta 64 TiB, solo se cobra por el espacio que
se utiliza en un volumen de clúster de Aurora. Cuando se eliminan datos de Aurora, como por ejemplo
al suprimir una tabla o partición, el espacio asignado general sigue siendo el mismo. El espacio libre se
reutiliza automáticamente cuando el volumen de datos aumenta en el futuro.
Note
Dado que los costos de almacenamiento se basan en el "nivel máximo de crecimiento" (la
cantidad máxima que se asignó para el clúster de Aurora en cualquier momento), puede
administrar costos evitando prácticas de ETL que crean grandes volúmenes de información
temporal o que cargan grandes volúmenes de datos nuevos antes de eliminar datos más antiguos
que ya no se necesitan.

25
Fiabilidad
Si la eliminación de datos de un clúster de Aurora produce una cantidad sustancial de espacio asignado
pero que no se utiliza, el restablecimiento del nivel máximo de crecimiento exige realizar el volcado de
datos lógicos y restablecerlo a un clúster nuevo, con una herramienta como mysqldump. La creación y
restauración de una instantánea no reduce el almacenamiento asignado debido a que la distribución física
del almacenamiento subyacente no se verá modificada en la instantánea restaurada.
Para obtener información acerca del almacenamiento de datos de Aurora, consulte Amazon RDS for
Aurora Pricing.
Fiabilidad de Amazon Aurora

Aurora se ha diseñado para ofrecer fiabilidad, durabilidad y tolerancia a errores. Puede diseñar la
arquitectura de su clúster de base de datos Aurora para mejorar la disponibilidad por medio de acciones
como añadir réplicas de Aurora y situarlas en distintas zonas de disponibilidad, y Aurora incluye también
varias características automáticas que la convierten en una solución de base de datos confianza.
Temas
• Reparación automática del almacenamiento (p. 26)
• Calentamiento de caché que puede sobrevivir (p. 26)
• Recuperación de bloqueos (p. 26)
Reparación automática del almacenamiento

Dado que Aurora mantiene varias copias de sus datos en tres zonas de disponibilidad, el riesgo de perder
datos como resultado de un error de disco se reduce sustancialmente. Aurora detecta automáticamente
los errores de los volúmenes de disco que componen el volumen de clúster. Cuando se produce un error
en un segmento de un volumen de disco, Aurora repara inmediatamente el segmento. Cuando Aurora
repara el segmento de disco, utiliza los datos de los otros volúmenes que componen el volumen de
clúster para garantizar que los datos del segmento reparado están actualizados. Como resultado, Aurora
evita las pérdidas de datos y reduce la necesidad de realizar una restauración a un momento dado para
recuperarse cuando se produce un error del disco.
Calentamiento de caché que puede sobrevivir

Aurora "calienta" la caché del grupo del búfer cuando una base de datos se inicia después de apagarse
o reiniciarse tras un error. Es decir, Aurora precarga el grupo del búfer con las páginas de las consultas
frecuentes conocidas que están almacenadas en una caché de páginas en memoria. Esto proporciona un
aumento del desempeño, ya que evita la necesidad de que el grupo del búfer realice un "calentamiento"
desde el uso normal de la base de datos.
La caché de la página de Aurora se administra en un proceso independiente de la base de datos, lo que

permite a la caché de páginas sobrevivir con independencia de la base de datos. En el improbable caso
de que se produzca un error de la base de datos, la caché de páginas permanece en la memoria, lo que
garantiza que el grupo del búfer se ha calentado con el estado más actualizado al reiniciar la base de
datos.
Recuperación de bloqueos
Aurora se ha diseñado para recuperarse de un bloqueo casi instantáneamente y continuar sirviendo
sus datos de aplicación sin el registro binario. Aurora realiza las recuperaciones de bloqueos de manera
asíncrona en subprocesos paralelos, de forma que su base de datos permanece abierta y disponible
inmediatamente después de un bloqueo.
Para obtener más información acerca de la recuperación de bloqueo, consulte Tolerancia a errores para un
clúster de base de datos de Aurora (p. 314).

26
Seguridad de Aurora
A continuación se indican consideraciones para registro binario y recuperación de bloqueo en Aurora

MySQL:
• Habilitar el registro binario en Aurora afecta directamente al tiempo de recuperación tras un bloqueo, ya
que fuerza a la instancia de base de datos a realizar la recuperación de log binario.
• El tipo de registro binario utilizado afecta al tamaño y a la eficiencia del registro. Para la misma cantidad
de actividad de base de datos, algunos formatos registran más información que otros en los logs
binarios. La siguiente configuración del parámetro binlog_format da lugar a distintas cantidades de
datos de log:
• ROW: la mayor cantidad de datos de registro
• STATEMENT: la menor cantidad de datos de registro
• MIXED: una cantidad moderada de datos de registro que habitualmente ofrece la mejor combinación
de integridad de datos y rendimiento
La cantidad de datos de log binario afecta al tiempo de recuperación. Si hay más datos registrados en
los logs binarios, la instancia de base de datos debe procesar más datos durante la recuperación, lo que
aumenta el tiempo de recuperación.
• Aurora no necesita que los logs binarios repliquen datos dentro de un clúster de base de datos o que
realicen una restauración a un momento dado (PITR).
• Si no necesita el log binario para replicación externa (o un flujo de log binario externo), le recomendamos
que establezca el parámetro binlog_format en OFF para deshabilitar el registro binario. Al hacerlo se
reduce el tiempo de recuperación.
Para obtener más información sobre el registro binario de Aurora y la replicación, consulte Replicación con
Amazon Aurora (p. 48). Para obtener más información acerca de las implicaciones de distintos tipos
de replicación de MySQL, consulte Advantages and Disadvantages of Statement-Based and Row-Based
Replication en la documentación de MySQL.
Seguridad de Amazon Aurora

La seguridad de Amazon Aurora se administra en tres niveles:
• Para controlar quién puede realizar acciones de administración de Amazon RDS en clústeres de base
de datos e instancias de base de datos Aurora, se usa AWS Identity and Access Management (IAM).
Cuando se conecta a AWS con credenciales de IAM, la cuenta de IAM debe tener políticas de IAM que
otorguen los permisos necesarios para realizar operaciones de administración de Amazon RDS. Para
obtener más información, consulte Administración de identidad y acceso en Amazon Aurora (p. 163).
Si está usando una cuenta de IAM para obtener acceso a la consola de Amazon RDS, debe iniciar
sesión primero en la Consola de administración de AWS con su cuenta de IAM y, a continuación, ir a la
consola de Amazon RDS en https://console.aws.amazon.com/rds.
• Los clústeres de base de datos Aurora se deben crear en una Amazon Virtual Private Cloud (VPC). Para
controlar qué dispositivos e instancias Amazon EC2 pueden abrir conexiones al punto de enlace y al
puerto de la instancia de base de datos los clústeres de base de datos Aurora en una VPC, debe usar un
grupo de seguridad de VPC. Puede establecer estas conexiones de puerto y punto de enlace mediante
Transport Layer Security (TLS) / Capa de conexión segura (SSL). Además, las reglas del firewall de su
compañía pueden controlar si los dispositivos que se ejecutan en ella pueden abrir conexiones a una
instancia de base de datos. Para obtener más información acerca de las VPC, consulte VPC Amazon
Virtual Private Cloud y Amazon Aurora (p. 211).
• Para autenticar los inicios de sesión y los permisos de un clúster de base de datos Amazon Aurora,
puede usar cualquiera de los siguientes procedimientos o una combinación de ellos.
• Puede seguir el mismo procedimiento que con una instancia de base de datos independiente de
MySQL o PostgreSQL.

27
Uso de SSL con clústeres de base de datos de Aurora
Las técnicas de autenticación de inicios de sesión y permisos para instancias de base de datos
independientes de MySQL o PostgreSQL como, por ejemplo, el uso de los comandos SQL o la
modificación de las tablas de los esquemas de las bases de datos, también funcionan con Aurora.
Para obtener más información, consulte Seguridad con Amazon Aurora MySQL (p. 499) o Seguridad
con Amazon Aurora PostgreSQL (p. 770).
• También puede utilizar la autenticación de base de datos de IAM para Aurora MySQL.
Con la autenticación de bases de datos de IAM, debe autenticarse en el clúster de base de datos de
Aurora MySQL con un usuario o un rol de IAM y un token de autenticación. Un token de autenticación
es un valor único que se genera utilizando el proceso de firma Signature Version 4. Al utilizar la
autenticación de base de datos de IAM, puede usar las mismas credenciales para controlar el acceso
a los recursos de AWS y a sus bases de datos. Para obtener más información, consulte Autenticación
de bases de datos de IAM (p. 180).
Para obtener información acerca de la configuración de seguridad, consulte Seguridad en Amazon

Aurora (p. 156).

Los clústeres de base de datos Amazon Aurora admiten conexiones de Capa de conexión segura (SSL)
desde aplicaciones con el mismo proceso y la misma clave pública que las instancias de base de datos de
Amazon RDS. Para obtener más información, consulte Seguridad con Amazon Aurora MySQL (p. 499),
Seguridad con Amazon Aurora PostgreSQL (p. 770) o Uso de TLS/SSL con Aurora Serverless (p. 102).
Alta disponibilidad para Aurora

Aurora almacena copias de los datos en un clúster de base de datos en varias zonas de disponibilidad
de una sola región de AWS, con independencia de si las instancias del clúster de base de datos abarcan
varias zonas de disponibilidad. Para obtener más información acerca de Amazon Aurora, consulte
Administración de un clúster de base de datos de Amazon Aurora (p. 232).
Al crear réplicas de Aurora entre zonas de disponibilidad, Amazon RDS las aprovisiona automáticamente
y las mantiene de forma síncrona. La instancia de base de datos principal se replica de forma síncrona en
distintas zonas de disponibilidad en réplicas de Aurora para proporcionar redundancia de datos, eliminar
las congelaciones de E/S y minimizar los picos de latencia durante las copias de seguridad del sistema.
Ejecutar una instancia de base de datos con alta disponibilidad puede mejorar la disponibilidad durante
el mantenimiento de sistema planificado y ayuda a proteger las bases de datos contra los errores y las
interrupciones de las zonas de disponibilidad. Para obtener más información acerca de las zonas de
disponibilidad, consulte Elección de Regiones y zonas de disponibilidad (p. 64).
Con la consola RDS, puede crear una implementación Multi-AZ especificando Multi-AZ al crear una
instancia de clúster de base de datos. Si un clúster de base de datos se encuentra en una única zona de
disponibilidad, puede convertirlo en un clúster de base de datos Multi-AZ añadiendo una réplica de Aurora
en una zona de disponibilidad diferente.
Puede especificar un despliegue Multi-AZ usando también la CLI. Use el comando describe-db-instances
de la AWS CLI o la acción DescribeDBInstances de la API de Amazon RDS para mostrar la zona de
disponibilidad de la réplica en espera (denominada zona de disponibilidad secundaria).
Después de crear la instancia principal de un clúster de base de datos, puede crear un máximo de 15
réplicas de Aurora al clúster de base de datos para permitir las consultas de solo lectura. Es recomendable
que distribuya la instancia principal y las réplicas de Aurora del clúster de base de datos entre varias
zonas de disponibilidad para mejorar la disponibilidad del clúster de base de datos. Para obtener más
información, consulte Disponibilidad (p. 65). Llame al comando create-db-instance de la AWS CLI para

28
Aurora Global Database
crear una réplica de Aurora en el clúster de base de datos. Incluya el nombre del clúster de base de datos
como valor del parámetro --db-cluster-identifier. Opcionalmente, puede especificar una zona de
disponibilidad para la réplica de Aurora con el parámetro --availability-zone.
Para obtener más información acerca de las conmutaciones por error a réplicas de Aurora, consulte
Administración de conexiones de Amazon Aurora (p. 3). Para obtener más información acerca de la
creación de un clúster de base de datos, consulte Creación de un clúster de base de datos de Amazon
Aurora (p. 85).
Uso de Amazon Aurora Global Database

A continuación, encontrará una descripción de Amazon Aurora Global Database. Las bases de datos
globales de Aurora abarcan varias regiones de AWS, lo que permite lecturas globales de baja latencia y la
recuperación de desastres de interrupciones regionales.
Temas
• Información general sobre Aurora Global Database (p. 29)
• Creación de una base de datos global de Aurora (p. 31)
• Añadir una región de AWS a una base de datos global de Aurora (p. 36)
• Eliminación de un clúster de una base de datos global de Aurora (p. 38)
• Eliminación de una base de datos global de Aurora (p. 40)
• Importación de datos en una base de datos global de Aurora (p. 42)
• Administración de una base de datos global de Aurora (p. 43)
• Configuración de una base de datos global de Aurora (p. 43)
• Conexión a una base de datos global de Aurora (p. 45)
• Conmutación por error para bases de datos globales de Aurora (p. 45)
• Performance Insights para base de datos global de Aurora (p. 46)
• Uso de base de datos global de Aurora con otros servicios de AWS (p. 46)
Información general sobre Aurora Global Database

Una base de datos global de Aurora consiste en una región principal de AWS en la que se controlan los
datos, y una región de AWS secundaria de solo lectura. Aurora replica los datos en la región de AWS
secundaria con una latencia típica de menos de un segundo. Ejecute operaciones de lectura directamente
en la instancia de base de datos principal en la región de AWS principal. Una base de datos global de
Aurora utiliza una infraestructura dedicada para replicar sus datos y dejar los recursos de base de datos
disponibles al completo para ofrecer cargas de trabajo de la aplicación. Las aplicaciones con repercusión
mundial pueden utilizar instancias de lector en la región de AWS secundaria para lecturas con baja
latencia. En el caso poco probable de que su base de datos se encuentre aislada o degradada en una
región de AWS, puede promocionar su región secundaria de AWS para que asuma cargas totales de
lectura-escritura en menos de un minuto.
El clúster de Aurora en la región principal de AWS donde se controlan los datos realiza tanto operaciones
de escritura como de lectura. El clúster en la región secundaria permite lecturas de baja latencia. Puede
escalar el clúster secundario independientemente añadiendo una o varias instancias de base de datos
(réplicas de Aurora) para servir a cargas de trabajo de solo lectura. Para la recuperación de desastres,
puede eliminar y promover el clúster secundario para permitir operaciones completas de lectura y escritura.
Solo el clúster primario realiza operaciones de escritura. Los clientes que realizan operaciones de escritura
se conectan al punto de enlace del clúster de base de datos del clúster primario.

29
Información general sobre Global Database
Temas
• Ventajas de Aurora Global Database (p. 30)
• Limitaciones actuales de Aurora Global Database (p. 30)
Ventajas de Aurora Global Database

Aurora Global Database utiliza una infraestructura dedicada para replicar cambios entre el clúster de base
de datos principal y el clúster secundario. Aurora Global Database proporciona las siguientes ventajas:
• La replicación realizada por una base de datos global de Aurora tiene un impacto de limitado a nulo
sobre el clúster de base de datos primario. Los recursos de las instancias de bases de datos están
totalmente dedicados a servir a las cargas de trabajo de lectura y escritura.
• Los cambios se replican entre regiones de AWS con un retardo mínimo, normalmente de menos de 1
segundo.
• El clúster secundario habilita la conmutación por error rápida ante la recuperación de desastres.
Normalmente puede promover un clúster secundario y ponerlo a disposición para la escritura en menos
de un minuto.
• Las aplicaciones en regiones de AWS remotas experimentan una menor latencia de consultas cuando
leen desde un clúster secundario.
• Puede añadir hasta 16 réplicas de Aurora al clúster secundario, lo que le permite escalar las lecturas
más allá de la capacidad de un único clúster de Aurora.
Limitaciones actuales de Aurora Global Database

Las limitaciones siguientes se aplican actualmente a Aurora Global Database:
• Aurora Global Database solo está disponible para Aurora con compatibilidad con MySQL 5.6.
• No puede utilizar clases de instancia db.t2 o db.t3 para una base de datos global de Aurora. Puede
elegir las clases de instancia db.r4 o db.r5.
• Actualmente, Aurora Global Database no está disponible en las regiones UE Estocolmo y Asia Pacífico
(Hong Kong).
• El clúster secundario debe estar en una región de AWS diferente a la del primario.
• No puede crear una réplica de lectura entre varias regiones a partir del clúster principal en la misma
región que el secundario. Consulte Replicación de clústeres de base de datos Amazon Aurora MySQL
entre distintas regiones de AWS (p. 599) para obtener información sobre las réplicas de lectura entre
regiones.
• Las siguientes características no son compatibles para Aurora Global Database:
• Clonación. Consulte Clonación de bases de datos en un clúster de bases de datos de
Aurora (p. 282) para obtener información sobre la clonación.
• Búsqueda de datos anteriores. Consulte Búsqueda de datos anteriores de un clúster de base de datos
de Aurora (p. 546) para obtener información sobre las búsquedas de datos anteriores.
• Consulta paralela. Consulte Trabajar con Consultas en paralelo de Amazon Aurora MySQL (p. 566)
para obtener información sobre las consultas paralelas.
• Aurora Serverless. Para obtener información acerca de Aurora Serverless, consulte Uso de Amazon
Aurora Serverless (p. 100).
• Detención e inicio de los clústeres de base de datos dentro de la base de datos global. Consulte
Detención e inicio de un clúster de base de datos Amazon Aurora (p. 232) para obtener información
sobre la detención e inicio de clústeres de Aurora.

30
Creación de una base de datos global
Creación de una base de datos global de Aurora

Una base de datos global de Aurora se extiende por varias regiones de AWS. Puede crear la base de
datos global en sí junto con el clúster primario de lectura-escritura. A continuación, creará un clúster
secundario de solo lectura en otra región de AWS.
• Para crear una nueva base de datos global, cree la base de datos global y el clúster primario que
contiene, y después añada un clúster secundario.
• Si tiene un clúster de Aurora existente, puede tomar una instantánea y restaurarla en una nueva base de
datos global de Aurora. Para ello, siga el procedimiento indicado en Importación de datos en una base
de datos global de Aurora (p. 42).
Al especificar nombres para el clúster primario y secundario, seleccione nombres que sean diferentes a los
de los clústeres de Aurora existentes, incluso si están en otras regiones de AWS.
Important
Antes de crear una base de datos global de Aurora, complete las tareas de configuración para
su cuenta, red y configuración de seguridad en Configuración para Amazon RDS en la Guía del
usuario de Amazon Relational Database Service.
Note
Si crea un clúster de Aurora mediante la AWS CLI o la API de RDS y pretende añadirlo
posteriormente a una base de datos global de Aurora, debe usar el valor global para el
parámetro del modo del motor.
Consola
Para crear una base de datos global de Aurora utilizando la Consola de administración de AWS
1. Inicie sesión en la Consola de administración de AWS y abra la consola de Amazon RDS para una
región en la que estén disponibles las bases de datos globales de Aurora.
2. Elija Create Database (Crear base de datos).
3. En la página Select engine (Seleccionar motor), seleccione el motor de Aurora compatible con MySQL
5.6 y Global para Database location (Ubicación de base de datos). Para ver un ejemplo, consulte las
siguientes imágenes.
Note
Asegúrese de que la opción Quick create (Creación rápida) no esté seleccionada. Si
desactiva Quick create (Creación rápida), quedarán visibles las opciones necesarias para
bases de datos globales de Aurora.
a. Elija Aurora como motor:

31
b. Seleccione la compatibilidad con MySQL 5.6:
c. Seleccione Global para la ubicación:
Note
Al seleccionar Global, se configura la base de datos global y el clúster de Aurora

principal. Una vez que la base de datos global se ha creado y está disponible, puede
añadir la región de AWS secundaria.
4. Rellene el resto de los ajustes siguiendo el mismo proceso de decisión que para el resto de clústeres
de Aurora. Para obtener más información acerca de la creación de un clúster de base de datos Aurora,
consulte Creación de un clúster de base de datos de Amazon Aurora (p. 85).
5. Seleccione Create.

32
Cuando se crea el clúster de base de datos principal y está disponible, puede crear un clúster secundario
siguiendo los pasos de Añadir una región de AWS a una base de datos global de Aurora (p. 36).
AWS CLI
Para crear una base de datos global de Aurora utilizando la CLI
1. Cree una base de datos global de Aurora y añada una región de AWS principal y una instancia de
base de datos en dicha región de AWS.
a. Cree la base de datos global de Aurora en sí. Inicialmente, no hay ningún clúster asociado a ella.
aws rds create-global-cluster \

--global-cluster-identifier global_database_id \
--engine aurora \
--engine-version 5.6.10a
Para Windows:
aws rds create-global-cluster ^

--global-cluster-identifier global_database_id ^
--engine aurora ^
Para obtener más información acerca de las opciones adicionales, consulte create-global-
cluster.
b. Compruebe que la base de datos global de Aurora ha pasado a estar disponible para su uso
mediante el comando describe-global-clusters de la AWS CLI, como se muestra en el
siguiente ejemplo.
aws rds --region primary_region \

describe-global-clusters \
--global-cluster-identifier global_database_id # optional
c. Cuando el resultado describe-global-clusters muestre un estado de available, cree el

clúster principal para la base de datos global de Aurora. Para ello, utilice el comando create-
db-cluster de la AWS CLI. Especifique aurora para el parámetro --engine, 5.6.10a para
el parámetro --engine-version y global para el parámetro --engine-mode. Especifique
el mismo valor --global-cluster-identifier que al crear la base de datos global. El
siguiente ejemplo muestra cómo.
aws rds create-db-cluster \

--region primary_region \
--db-cluster-identifier db_cluster_id \
--master-username master_userid \
--master-user-password master_password \
--engine aurora \
--engine-version 5.6.10a \
--engine-mode global \
--global-cluster-identifier global_database_id

33
Para Windows:
aws rds create-db-cluster ^

--region primary_region ^
--db-cluster-identifier db_cluster_id ^
--master-username master_userid ^
--master-user-password master_password ^
--engine aurora ^
--engine-version 5.6.10a ^
--engine-mode global ^
base de datos global.
Para obtener más información acerca de las opciones adicionales, consulte create-db-
cluster.
d. Compruebe que el clúster de Aurora está disponible para su uso con el comando describe-db-
clusters de la AWS CLI, como se muestra en el siguiente ejemplo.

describe-db-clusters \
--db-cluster-identifier db_cluster_id # optional
e. Cuando el resultado describe-db-clusters muestre un estado de available, cree la

instancia de base de datos para el clúster principal. Para ello, utilice el comando create-db-
instance de la AWS CLI. Especifique aurora para el parámetro --engine, 5.6.10a para
el parámetro --engine-version y global para el parámetro --engine-mode. El siguiente
ejemplo muestra cómo.
aws rds create-db-instance \

--db-cluster-identifier db_cluster_id \
--db-instance-class instance_class \
--db-instance-identifier db_instance_id \
--engine aurora \
Para Windows:
aws rds create-db-instance ^

--db-cluster-identifier db_cluster_id ^
--db-instance-class instance_class ^
--db-instance-identifier db_instance_id ^
--engine aurora ^
No tiene que incluir los parámetros --master-username y --master-user-password,

porque esos valores se toman del clúster de base de datos principal.
Para obtener más información acerca de las opciones adicionales, consulte create-db-
instance.

34
2. Compruebe que el clúster principal de la base de datos global de Aurora ha pasado a estar disponible
para su uso mediante el comando describe-db-clusters de la AWS CLI, como se muestra en el
siguiente ejemplo.
aws rds describe-db-clusters --db-cluster-identifier sample-global-cluster
Cuando los resultados de describe-db-clusters muestren el estado available, cree la

instancia principal del clúster principal para que pueda comenzar la replicación. Para ello, utilice el
comando create-db-instance de la AWS CLI como se muestra en el siguiente ejemplo.

--db-cluster-identifier sample-global-cluster \
--db-instance-identifier sample-replica-instance \
--engine aurora
Para Windows:

--db-cluster-identifier sample-global-cluster ^
--db-instance-identifier sample-replica-instance ^
--engine aurora
Cuando la instancia de base de datos se ha creado y está disponible, comienza la replicación. Puede
determinar si la instancia de base de datos está disponible llamando al comando describe-db-
instances de la AWS CLI.
3. Como alternativa, puede crear el clúster principal en primer lugar y posteriormente crear la base de
datos global, especificando qué clúster utilizar como clúster principal:
a. Cree un clúster de Aurora vacío con el modo de motor global y una instancia de base de datos
dentro de ese clúster. El modo de motor global supone que podrá añadir este clúster a una
base de datos de Aurora global.

create-db-cluster \
--db-cluster-identifier primary_cluster_id \
--master-username master_userid \
--master-user-password master_password \
--engine aurora \
--engine-version 5.6.10a \
--engine-mode global

create-db-instance \
--db-cluster-identifier primary_cluster_id \
--engine aurora
Para Windows:

35
Añadir una región de AWS a una
base de datos global de Aurora
aws rds --region primary_region ^

create-db-cluster ^
--db-cluster-identifier primary_cluster_id ^
--master-username master_userid ^
--master-user-password master_password ^
--engine aurora ^
--engine-version 5.6.10a ^
--engine-mode global

create-db-instance ^
--db-cluster-identifier primary_cluster_id ^
--engine aurora
b. Cuando el clúster de base de datos principal y la instancia de base de datos estén creados y
disponibles, cree la base de datos global de Aurora llamando al comando create-global-
cluster de la AWS CLI en la región de AWS en la que quiera crear la base de datos global de
Aurora.
aws rds create-global-cluster \

--source-db-cluster-identifier primary_cluster_ARN
Para Windows:
aws rds create-global-cluster ^

--global-cluster-identifier global_database_id ^
--source-db-cluster-identifier primary_cluster_ARN
API de RDS
Para crear una base de datos de Aurora global con la API de RDS, ejecute la acción CreateGlobalCluster.
Añadir una región de AWS a una base de datos global

de Aurora
Tras crear una base de datos global de Aurora y su clúster principal, puede aumentar su presencia global
añadiendo una nueva región de AWS. Este proceso implica asociar un clúster de Aurora secundario. El
clúster secundario debe estar en una región de AWS diferente a la del primario.
Note
En la actualidad, el número máximo de clústeres secundarios de Aurora que puede asociar a una
base de datos global de Aurora es uno.

36
Añadir una región de AWS a una
Consola
Para añadir una región de AWS a una base de datos global de Aurora con la Consola de
administración de AWS, realice el siguiente procedimiento:
1. En la esquina superior derecha de la Consola de administración de AWS, seleccione cualquier región

de AWS en la que estén disponibles las bases de datos globales de Aurora.
2. En el panel de navegación, seleccione Databases (Bases de datos).
3. Seleccione la casilla de verificación para la base de datos global de Aurora para la que quiera crear un
clúster secundario. Si el clúster primario o las instancias de bases de datos que contiene siguen en el
estado Creating, espere hasta que estén todos Available.
4. En Actions (Acciones), elija Add region (Añadir región).
5. En la página Add a region (Añadir una región), seleccione la región de AWS secundaria.
6. Complete los campos restantes para el clúster de Aurora en la nueva región de AWS y, a
continuación, seleccione Create (Crear).

37
Eliminación de un clúster de una
AWS CLI
Para añadir una región de AWS a una base de datos global de Aurora con la AWS CLI, ejecute el comando
create-db-cluster.
Los siguientes comandos crean un nuevo clúster de Aurora. Asócielo a una base de datos global como
clúster secundario de solo lectura y, después, añada una instancia de base de datos al nuevo clúster. La
opción --global-cluster-identifier para el comando create-db-cluster especifica la base de
datos global a la que adjuntar el nuevo clúster.
Para un clúster cifrado, especifique la opción --source-region con un valor que coincida con la región
de AWS principal.
aws rds --region secondary_region \

create-db-cluster \
--db-cluster-identifier secondary_cluster_id \
--engine aurora

create-db-instance \
--db-cluster-identifier secondary_cluster_id \
--engine aurora
Para Windows:
aws rds --region secondary_region ^

create-db-cluster ^
--db-cluster-identifier secondary_cluster_id ^
--global-cluster-identifier global_database_id_id ^
--engine aurora

create-db-instance ^
--db-cluster-identifier secondary_cluster_id ^
--engine aurora
API de RDS
Para añadir una nueva región de AWS a una base de datos de Aurora global con la API de RDS, ejecute la
acción CreateGlobalCluster.
Eliminación de un clúster de una base de datos global

de Aurora
La eliminación de un clúster de Aurora de una base de datos global de Aurora la devuelve a un clúster
regional, con capacidad plena de lectura y escritura y sin sincronización con el clúster principal.
Puede eliminar un clúster de Aurora de una base de datos global en caso de que el clúster principal se
degrade o quede aislado. La realización de una conmutación por error para una base de datos global de

38
Eliminación de un clúster de una
Aurora implica eliminar el clúster secundario de la base de datos global original y, después, utilizarlo como
clúster principal en una nueva base de datos global de Aurora.
Si ya no necesita la base de datos global, debe eliminar el clúster secundario y después el principal, antes
de borrar la base de datos en sí. Posteriormente, puede borrar uno o los dos clústeres que ha eliminado o
seguir usando uno o los dos como clústeres de Aurora de región única.
Consola
Para eliminar un clúster de Aurora desde una base de datos global de Aurora con Consola de
administración de AWS, elija el clúster en la página Databases (Base de datos). En Actions (Acciones),
elija Remove from Global (Eliminar desde global). El clúster eliminado pasa a ser un clúster de Aurora
normal con capacidades de lectura y escritura plenas. Ya no estará sincronizado con el clúster principal.
Si un clúster secundario sigue asociado con la base de datos global, no podrá eliminar el clúster principal.
Tras eliminar o borrar el clúster secundario, podrá eliminar el clúster principal del mismo modo.
Después de que los clústeres se eliminen de una base de datos global de Aurora, seguirá viéndolos en
la página Databases (Bases de datos), pero sin las etiquetas Global, Primary (Principal) y Secondary
(Secundario).
AWS CLI
Para eliminar un clúster de Aurora de una base de datos global de Aurora con la AWS CLI, ejecute el
comando remove-from-global-cluster.
Los siguientes comandos eliminan un clúster secundario y, después, el clúster primario de una base
de datos global de Aurora. Los clústeres que se deben eliminar están identificados por el parámetro --
db-cluster-identifier en cada caso. La base de datos global de Aurora está identificada por el
parámetro --global-cluster-identifier.

39
Eliminación de una base de datos global de Aurora

remove-from-global-cluster \
--db-cluster-identifier secondary_cluster_ARN \

remove-from-global-cluster \
--db-cluster-identifier primary_cluster_ARN \
Para Windows:

remove-from-global-cluster ^
--db-cluster-identifier secondary_cluster_ARN ^

remove-from-global-cluster ^
--db-cluster-identifier primary_cluster_ARN ^
API de RDS
Para eliminar un clúster de Aurora de una base de datos global de Aurora con la API de RDS, ejecute la
acción RemoveFromGlobalCluster.

Antes de poder eliminar una base de datos global de Aurora, debe eliminar o borrar el clúster secundario
y el principal asociados con la base de datos global. Consulte Eliminación de un clúster de una base de
datos global de Aurora (p. 38) para ver el procedimiento de eliminación de un clúster de la base de
datos global y convertirlo de nuevo en un clúster de Aurora independiente.
Consola
Para eliminar una base de datos global de Aurora utilizando la Consola de administración de AWS
Para eliminar un clúster que sea parte de una base de datos global de Aurora con la Consola de
administración de AWS, elimine o borre cualquier clúster secundario asociado con la base de datos
global, elimine el clúster principal y después elimine la propia base de datos global. Dado que una base
de datos global suele contener datos empresariales esenciales, no puede eliminar la base de datos
global y los clústeres asociados en un único paso. Consulte Eliminación de un clúster de una base de
datos global de Aurora (p. 38) para ver instrucciones sobre cómo eliminar clústeres de una base de
datos global. Consulte Eliminación de una instancia de base de datos en un clúster de base de datos de
Aurora (p. 348) para ver el procedimiento de borrado de clústeres tras haberlos eliminado. La eliminación
de la instancia primaria de un clúster de Aurora eliminar el propio clúster.
1. Confirme que todos los demás clústeres se han borrado de la base de datos global de Aurora.
Si la base de datos global incluye clústeres anidados subyacentes, como en la siguiente captura de
pantalla, no podrá eliminar aún la base de datos global. Siga el procedimiento de Eliminación de un
clúster de una base de datos global de Aurora (p. 38) para cada clúster asociado con la base de
datos global.

40
Cuando la base de datos global no tenga ya clústeres asociados, puede proceder a eliminarla. En la
siguiente captura de pantalla se muestra cómo el clúster global-db-demo ya no está asociado con
la base de datos global tras eliminarlo.
2. En la página Databases (Bases de datos), o en la página de detalles para la base de datos global,
seleccione Actions (Acciones) y después haga clic en Delete (Eliminar).
AWS CLI
Para eliminar un clúster que forme parte de una base de datos global de Aurora con la AWS CLI, ejecute el
comando delete-global-cluster.
El siguiente comando elimina la base de datos global de Aurora con el ID de clúster global especificado:

delete-global-cluster \
Para Windows:

41
Importación de datos en una base de datos global

delete-global-cluster ^
API de RDS
Para eliminar un clúster que forme parte de una base de datos global de Aurora con la API de RDS,
ejecute la operación DeleteGlobalCluster.
Importación de datos en una base de datos global de

Aurora
Para importar datos en una base de datos global de Aurora, utilice una de las siguientes técnicas:
• Cree una instantánea de un clúster de Aurora MySQL o una instancia de base de datos MySQL de
Amazon RDS y restáurela al clúster principal de una base de datos global de Aurora. En la actualidad,
cualquier instantánea debe proceder de un origen compatible con MySQL 5.6.
• Utilice la restauración al último momento restaurable para restaurar los datos del clúster a un estado
anterior.
• Utilice una técnica de importación lógica, como la preparación de los datos con el comando mysqldump
y su carga mediante el comando mysql.
La distinción crucial para una base de datos global de Aurora es que siempre importa los datos al clúster
que designa como clúster principal. Puede realizar la importación de datos inicial antes o después de

42
Administración de una base de datos global de Aurora
añadir el clúster a la base de datos global de Aurora. Todos los datos del clúster principal se replican
automáticamente al clúster secundario.
Administración de una base de datos global de Aurora

Puede realizar la mayor parte de las operaciones de administración en los clústeres individuales que
componen una base de datos global de Aurora. Al seleccionar Group related resources (Recursos
relacionados con grupos) en la página Databases (Bases de datos) de la consola, verá el clúster primario y
el secundario agrupados bajo el objeto de base de datos global asociado.
Para ver las propiedades que se aplican a toda una base de datos global de Aurora, seleccione esa base
de datos global.
Configuración de una base de datos global de Aurora

La página Databases (Bases de datos) de la Consola de administración de AWS se enumeran todas sus
bases de datos globales de Aurora y el clúster principal y secundario para cada una de ellas. La base

43
Configuración de una base de datos global de Aurora
de datos global de Aurora es un objeto que tiene sus propios ajustes de configuración, en especial las
regiones de AWS asociadas con el clúster principal y secundario.
Puede seleccionar una base de datos global de Aurora y modificar su configuración, como se muestra en
la siguiente captura de pantalla:
Puede configurar los grupos de parámetros independientemente para cada clúster de Aurora dentro
de la base de datos global de Aurora. La mayoría de parámetros funcionan igual que para otros tipos
de clústeres de Aurora. Los ajustes de configuración aurora_enable_repl_bin_log_filtering
y aurora_enable_replica_log_compression no tienen efecto. Recomendamos mantener
configuración coherente entre todos los clústeres en una base de datos global con el fin de evitar cambios
inesperados en el comportamiento si promueve un clúster secundario para ser el principal. Por ejemplo,

44
Conexión a una base de datos global de Aurora
utilice la misma configuración de zonas horarias y conjuntos de caracteres para evitar un comportamiento
incoherente si un clúster diferente asume la función del clúster principal.
Conexión a una base de datos global de Aurora

Para el tráfico de consultas de solo lectura, se debe conectar al punto de enlace del lector para el clúster
de Aurora en su región de AWS.
Para ejecutar instrucciones en lenguaje de manipulación de datos (DML) o lenguaje de definición de datos
(DDL), conecte el punto de enlace del clúster para el clúster principal. Este punto de enlace podría estar en
una región de AWS distinta a su aplicación.
Cuando vea la base de datos global de Aurora en la Consola de administración de AWS, verá todos los
puntos de enlace de uso general asociados con todos sus clústeres, como se muestra en la siguiente
captura de pantalla. Hay un único punto de enlace de clúster, asociado con el clúster principal, que utilizará
para las operaciones de escritura. El clúster principal y cada uno de los clústeres secundarios tienen un
punto de enlace de lector, que utilizará para consultas de solo lectura. Seleccione el punto de enlace de
lector que esté en su región de AWS o en la región de AWS que tenga más cerca, para reducir al mínimo
la latencia.
Conmutación por error para bases de datos globales

de Aurora
Las bases de datos globales de Aurora introducen un mayor nivel en la capacidad de conmutación por
error que un clúster de Aurora predeterminado. Si todo un clúster de una región de AWS deja de estar
disponible, podrá promover otro clúster de la base de datos global para que tenga capacidad de lectura y
escritura.
Puede activar manualmente el mecanismo de conmutación por error si un clúster de una región de AWS
diferente es una mejor opción para ser el clúster principal. Por ejemplo, puede aumentar la capacidad del
clúster secundario y promoverlo para que sea el clúster principal. O también puede que la actividad entre
las regiones de AWS cambie, por lo que cambiar el clúster principal a una región de AWS diferente podría
ofrecer una menor latencia para las operaciones de escritura.
En los siguientes pasos se describe la secuencia de eventos para promover un clúster secundario en una
base de datos global de Aurora:
1. El clúster primario deja de estar disponible.

2. Elimine el clúster secundario de la base de datos global de Aurora. Al hacerlo, lo promueve y le da
capacidad de lectura y escritura completa. Para aprender a quitar un clúster de Aurora de una base de
datos global, consulte Eliminación de un clúster de una base de datos global de Aurora (p. 38).
3. Puede reconfigurar la aplicación para desviar el tráfico de escritura al clúster que acaba de promover.

45
Performance Insights para base de datos global
Important
En este punto, deje de enviar instrucciones DML u otras operaciones de escritura al clúster que
ha dejado de estar disponible. Para evitar incoherencias entre los clústeres, conocidas como
un escenario "split-brain", evite escribir en el antiguo clúster principal, incluso aunque vuelva a
estar online.
4. Puede crear una nueva base de datos global de Aurora con el clúster recién promovido como clúster
principal. Para aprender a crear una base de datos global de Aurora, consulte Creación de una base de
datos global de Aurora (p. 31).
5. Añada a la base de datos global de Aurora la región de AWS del clúster que haya encontrado el
problema. Ahora, esa región de AWS contiene un nuevo clúster secundario. Para aprender a añadir una
nueva región de AWS a una base de datos global de Aurora, consulte Añadir una región de AWS a una
base de datos global de Aurora (p. 36).
6. Cuando se haya resuelto la interrupción y esté listo para asignar su región de AWS como clúster
principal de nuevo, realice los mismos pasos en orden inverso:
a. Elimine el clúster secundario de la base de datos global de Aurora.
b. Haga que ese clúster sea el clúster principal de una nueva base de datos global de Aurora en la
región de AWS original.
c. Redirija todo el tráfico de escritura del clúster principal en la región de AWS original.
d. Añada una región de AWS para configurar un clúster secundario en la misma región de AWS que
antes.
Performance Insights para base de datos global de

Aurora
Puede utilizar Amazon RDS Performance Insights y Aurora Global Database juntos. En ese caso, los
informes de Performance Insights se aplican a cada clúster en la base de datos global individualmente.
Puede habilitar o desactivar Performance Insights para cada clúster que forma parte de la base de datos
global. Cuando añada una nueva región secundaria en una base de datos global que ya está utilizando
Performance Insights, debe habilitar Performance Insights en el clúster recién añadido. No hereda la
configuración de Performance Insights de la base de datos global existente.
Puede cambiar las regiones de AWS mientras ve la página de Performance Insights para una instancia
de base de datos que está conectada a una base de datos global. Sin embargo, es posible que no vea la
información de rendimiento de inmediato después de cambiar regiones de AWS. Aunque las instancias de
base de datos pueden tener nombres idénticos en cada región de AWS, la URL de Performance Insights
asociada es distinta para cada instancia de base de datos. Después de cambiar regiones de AWS, elija el
nombre de la instancia de base de datos de nuevo en el panel de navegación de Performance Insights.
Para las instancias de base de datos asociadas a una base de datos global, los factores que afectan al
rendimiento pueden ser distintos en cada región de AWS. Por ejemplo, las instancias de base de datos en
cada región pueden tener una capacidad diferente.
Para obtener más información sobre el uso de Performance Insights, consulte Uso de Performance
Insights de Amazon RDS (p. 402).
Uso de base de datos global de Aurora con otros

servicios de AWS
En algunos casos, podrá acceder a otros servicios de AWS en combinación con una base de datos global
de Aurora. En dichos casos, necesitará los mismos privilegios, funciones externas, etc. en las regiones de

46
Uso de base de datos global con otros servicios de AWS
AWS correspondientes para todos los clústeres asociados. Aunque un clúster de Aurora en una base de
datos global podría empezar como un objetivo de replicación de solo lectura, es posible que después lo
promueva a clúster principal. Para prepararse ante esa posibilidad, configure los privilegios de escritura
necesarios para otros servicios con antelación para todos los clústeres de Aurora en la base de datos
global.
En la siguiente lista se resumen las acciones que se han de emprender para cada servicio de AWS.
Invocación de funciones de Lambda
Para los clústeres de Aurora que componen la base de datos global de Aurora, realice los
procedimientos de Invocación de una función de Lambda desde un clúster de base de datos Amazon
Aurora MySQL (p. 655).
Para cada clúster de la base de datos global de Aurora, configure el parámetro del clúster
aws_default_lambda_role con el Nombre de recurso de Amazon (ARN) del nuevo rol de IAM.
Para permitir que los usuarios de una base de datos global de Aurora invoquen funciones Lambda,
asocie el rol que ha creado en Creación de un rol de IAM que permita a Amazon Aurora acceder a los
servicios de AWS (p. 635) con cada clúster en la base de datos global de Aurora.
Configure cada clúster de la base de datos global de Aurora para permitir conexiones salientes hacia
Lambda. Para obtener instrucciones, consulte Habilitación de la comunicación de red de Amazon
Aurora MySQL con otros servicios de AWS (p. 640).
Carga de datos desde S3
procedimientos de Carga de datos en un clúster de base de datos Amazon Aurora MySQL desde
archivos de texto en un bucket de Amazon S3 (p. 641).
Para cada clúster de la base de datos global de Aurora, configure o bien el parámetro del clúster
de la base de datos aurora_load_from_s3_role o el aws_default_s3_role con el Nombre
de recurso de Amazon (ARN) del nuevo rol de IAM. Si no se ha especificado un rol de IAM para
aurora_load_from_s3_role, Aurora utilizará el rol de IAM especificado en el parámetro
aws_default_s3_role.
Para permitir que los usuarios de una base de datos global de Aurora accedan a Amazon S3, asocie el
rol que ha creado en Creación de un rol de IAM que permita a Amazon Aurora acceder a los servicios
de AWS (p. 635) con cada clúster de Aurora en la base de datos global.
Amazon S3. Para obtener instrucciones, consulte Habilitación de la comunicación de red de Amazon
Guardar datos de consulta en S3
procedimientos de Grabación de datos desde un clúster de base de datos Amazon Aurora MySQL en
archivos de texto de un bucket de Amazon S3 (p. 649).
Para cada clúster de la base de datos global de Aurora, configure o bien el parámetro del clúster de
la base de datos aurora_select_into_s3_role o el aws_default_s3_role con el Nombre
de recurso de Amazon (ARN) del nuevo rol de IAM. Si no se ha especificado un rol de IAM para
aurora_select_into_s3_role, Aurora utilizará el rol de IAM especificado en el parámetro
Para permitir que los usuarios de una base de datos global de Aurora accedan a Amazon S3, asocie el
rol que ha creado en Creación de un rol de IAM que permita a Amazon Aurora acceder a los servicios
de AWS (p. 635) con cada clúster de Aurora en la base de datos global.

47
Replicación con Aurora
Amazon S3. Para obtener instrucciones, consulte Habilitación de la comunicación de red de Amazon
Replicación con Amazon Aurora

Existen varias opciones de replicación con Aurora. En las siguientes secciones se explica cómo y cuándo
elegir cada técnica.
Réplicas de Aurora
Las réplicas de Aurora son puntos de enlace independientes de un clúster de base de datos Aurora
que se utilizan preferentemente para ajustar la escala de las operaciones de lectura e incrementar la
disponibilidad. Se puede distribuir un máximo de 15 réplicas de Aurora entre las distintas zonas de
disponibilidad que abarca un clúster de base de datosntro de una región de AWS. El volumen del clúster
de base de datos consta de varias copias de los datos del clúster de base de datos. Sin embargo, los datos
del volumen del clúster se representan como un único volumen lógico para la instancia principal y para las
réplicas de Aurora del clúster de base de datos.
Como resultado, todas las réplicas de Aurora devuelven los mismos datos para los resultados de las
consultas con un retardo de réplica mínimo, normalmente muy inferior a 100 milisegundos una vez que la
instancia principal ha escrito una actualización. El retardo de la réplica varía en función de la velocidad de
cambio de la base de datos. Es decir, durante los periodos en los que se produce una gran cantidad de
operaciones de escritura en la base de datos, puede registrarse un aumento del retardo de la réplica.
Las réplicas de Aurora funcionan bien para el escalado de lectura porque están totalmente dedicadas a
las operaciones de lectura en el volumen del clúster. Las operaciones de escritura se administran en la
instancia principal. Como el volumen del clúster se comparte entre todas las instancias de base de datos
del clúster de base de datos, se requiere un trabajo adicional mínimo para replicar una copia de los datos
para cada réplica de Aurora.
Para incrementar la disponibilidad, puede usar las réplicas de Aurora como objetivos de conmutación por
error. Es decir, que si la instancia principal da error, una réplica de Aurora se convierte en la instancia
principal. En este proceso se produce una breve interrupción durante la cual las solicitudes de escritura y
lectura realizadas a la instancia principal generan errores con una excepción, y las réplicas de Aurora se
reinician. Si su clúster de base de datos Aurora no incluye ninguna réplica de Aurora, el clúster de base de
datos no estará disponible durante el tiempo que tarda la instancia de base de datos en recuperarse del
evento de error. Sin embargo, promover una réplica de Aurora es mucho más rápido que volver a crear la
instancia principal. Para escenarios de alta disponibilidad, le recomendamos que cree una o más réplicas
de Aurora. Dichas réplicas deberían ser de la misma clase de instancia de base de datos que la instancia
principal y de zonas de disponibilidad distintas para el clúster de base de datos Aurora. Para obtener más
información acerca de las réplicas de Aurora como objetivos de conmutación por error, consulte Tolerancia
a errores para un clúster de base de datos de Aurora (p. 314).
Note
No puede crear una réplica de Aurora cifrada para un clúster de base de datos de Aurora sin
cifrar. No puede crear una réplica de Aurora sin cifrar para un clúster de base de datos de Aurora
cifrado.
Para obtener información detallada acerca de la forma de crear una réplica de Aurora, consulte Adición de
réplicas de Aurora a un clúster de base de datos (p. 254).
Replicación con Aurora MySQL

Además de las réplicas de Aurora, dispone de las siguientes opciones para replicar con Aurora MySQL:

48
Aurora PostgreSQL
• Dos clústeres de base de datos Aurora MySQL de diferentes regiones de AWS mediante la creación de
una réplica de lectura de Aurora de un clúster de base de datos Aurora MySQL en una región de AWS
distinta.
• Dos clústeres de base de datos Aurora MySQL en la misma región mediante la utilización de la
replicación del log binario (binlog) de MySQL.
• Una instancia de base de datos MySQL maestra en Amazon RDS y un clúster de base de datos Aurora
MySQL mediante la creación de una réplica de lectura de Aurora de una instancia de base de datos
MySQL en Amazon RDS. Normalmente, este método se usa para la migración de Aurora MySQL y no
para una replicación continua.
Para obtener más información sobre cómo replicar con Aurora MySQL, consulte Replicación con Amazon
Replicación con Aurora PostgreSQL

Además de las réplicas de Aurora, puede configurar la replicación entre una instancia de base de datos
maestra de PostgreSQL de Amazon RDS y un clúster de base de datos Aurora PostgreSQL. Para ello
deberá crear una réplica de lectura de Aurora de una instancia de base de datos PostgreSQL de Amazon
RDS.
Para obtener más información sobre cómo replicar con Aurora PostgreSQL, consulte Replicación con
Amazon Aurora PostgreSQL (p. 796).

49
Inscripción en AWS
Configuración del entorno para

Amazon Aurora
Antes de usar Amazon Aurora por primera vez, realice las siguientes tareas:
1. Inscripción en AWS (p. 50)

2. Creación de un usuario de IAM (p. 50)
3. Determinar las necesidades (p. 52)
4. Proporcionar acceso al clúster de base de datos en la VPC mediante la creación de un grupo de
seguridad (p. 53)
Inscripción en AWS
Al inscribirse en Amazon RDS (AWS), su cuenta de AWS se inscribe automáticamente en todos los
servicios de AWS, incluido Amazon RDS. Solo se le cobrará por los servicios que utilice.
Con Amazon RDS, paga solo por los recursos que usa. El clúster de base de datos de Amazon RDS que
crea se ejecuta en un entorno real (no en un entorno de pruebas). Deberá pagar las tarifas de uso estándar
de Amazon RDS para el clúster hasta que lo elimine. Para obtener más información sobre las tarifas de
uso de Amazon RDS, consulte la página del producto de Amazon RDS. Si es un cliente nuevo de AWS,
puede comenzar a utilizar Amazon RDS de forma gratuita. Para obtener más información, consulte la
sección sobre la capa gratuita de AWS.
Si ya dispone de una cuenta de AWS, pase a la siguiente tarea. Si no dispone de una cuenta de AWS,
utilice el siguiente procedimiento para crear una.
Para crear una cuenta de AWS
1. Abra https://portal.aws.amazon.com/billing/signup.
2. Siga las instrucciones en línea.
Parte del procedimiento de inscripción consiste en recibir una llamada telefónica e indicar un código de
verificación en el teclado del teléfono.
Anote su número de cuenta de AWS porque lo necesitará en la siguiente tarea.
Creación de un usuario de IAM

Cuando obtenga acceso a los servicios de AWS, como Amazon RDS, debe proporcionar las credenciales
para que estos puedan determinar si tiene permiso de acceso a sus recursos. La consola requiere que
especifique la contraseña. Puede crear claves de acceso para su cuenta de AWS para tener acceso a la
interfaz de línea de comandos o API. No obstante, no recomendamos que tenga acceso a AWS con las
credenciales de su cuenta de AWS; es mejor que utilice AWS Identity and Access Management (IAM) en
su lugar. Cree un usuario de IAM y añádalo a un grupo de IAM con permisos administrativos, o conceda al
usuario permisos administrativos. A continuación, puede tener acceso a AWS mediante una dirección URL
especial y las credenciales del usuario de IAM.

50
Creación de un usuario de IAM
Si se ha inscrito en AWS, pero no ha creado un usuario de IAM para usted, puede crearlo en la consola de
IAM.
Para crearse usted mismo un usuario administrador y agregarlo a un grupo de administradores

(consola)
1. Utilice la dirección de correo electrónico y la contraseña de su cuenta de AWS para iniciar sesión
como Usuario de la cuenta raíz de AWS en la consola de IAM en https://console.aws.amazon.com/
iam/.
Note
Le recomendamos que siga la práctica recomendada de utilizar el usuario de IAM

Administrator como se indica a continuación y guardar de forma segura las credenciales
de usuario raíz. Inicie sesión como usuario raíz únicamente para realizar algunas tareas de
administración de servicios y de cuentas.
2. En el panel de navegación, elija Users (Usuarios) y, a continuación, elija Add user (Añadir usuario).
3. En User name (Nombre de usuario), escriba Administrator.
4. Marque la casilla situada junto a Consola de administración de AWS access (Acceso a la Consola de
administración de AWS). A continuación, seleccione Custom password (Contraseña personalizada) y
luego escriba la nueva contraseña en el cuadro de texto.
5. (Opcional) De forma predeterminada, AWS requiere al nuevo usuario que cree una nueva contraseña
la primera vez que inicia sesión. Puede quitar la marca de selección de la casilla de verificación
situada junto a User must create a new password at next sign-in (El usuario debe crear una nueva
contraseña en el siguiente inicio de sesión) para permitir al nuevo usuario restablecer su contraseña
después de iniciar sesión.
6. Elija Next: Permissions.
7. En Set permissions (Establecer persmisos), elija Add user to group (Añadir usuario a grupo).
8. Elija Create group (Crear grupo).
9. En el cuadro de diálogo Create group (Crear grupo), en Group name (Nombre del grupo) escriba
Administrators.
10. Elija Filter policies (Filtrar políticas) y, a continuación, seleccione AWS managed -job function (Función
de trabajo administrada por AWS) para filtrar el contenido de la tabla.
11. En la lista de políticas, active la casilla de verificación AdministratorAccess. A continuación, elija
Create group (Crear grupo).
Note
Debe activar el acceso de usuarios y roles de IAM a Facturación para poder utilizar la los
permisos AdministratorAccess para el acceso a la consola de AWS Billing and Cost
Management. Para ello, siga las instrucciones que se indican en el paso 1 del tutorial sobre
cómo delegar el acceso a la consola de facturación.
12. Retroceda a la lista de grupos y active la casilla de verificación del nuevo grupo. Elija Refresh si es
necesario para ver el grupo en la lista.
13. Elija Next: Tags (Siguiente: Etiquetas).
14. (Opcional) Añadir metadatos al rol asociando las etiquetas como pares de clave-valor. Para obtener
más información sobre el uso de etiquetas en IAM, consulte Etiquetado de entidades de IAM en la
Guía del usuario de IAM.
15. Elija Next: Review para ver la lista de suscripciones a grupos que se van a añadir al nuevo usuario.
Cuando esté listo para continuar, elija Create user (Crear usuario).
Puede usar este mismo proceso para crear más grupos y usuarios y para conceder a los usuarios acceso
a los recursos de la cuenta de AWS. Para obtener información sobre cómo usar las políticas que restringen
51
Determinar las necesidades
los permisos de los usuarios a recursos de AWS específicos, consulte Administración de acceso y Políticas
de ejemplo.
Para iniciar sesión como este nuevo usuario de IAM, cierre la sesión de la consola de AWS y después
utilice la siguiente dirección URL, donde su_id_de_cuenta_de_aws es su número de cuenta de AWS sin
los guiones (por ejemplo, si su número de cuenta de AWS es 1234-5678-9012, su ID de cuenta de AWS
será 123456789012):
https://your_aws_account_id.signin.aws.amazon.com/console/
Escriba el nombre y la contraseña del usuario de IAM que acaba de crear. Cuando haya iniciado sesión, en
la barra de navegación se mostrará "su_nombre_de_usuario @ su_id_de_cuenta_de_aws".
Si no desea que la dirección URL de la página de inicio de sesión contenga el ID de su cuenta de AWS,
puede crear un alias de cuenta. En el panel IAM, seleccione Customize (Personalizar) y especifique un
alias, como el nombre de su empresa. Para iniciar sesión después de crear un alias de cuenta, use la
siguiente dirección URL:
https://your_account_alias.signin.aws.amazon.com/console/
Para comprobar el enlace de inicio de sesión de los usuarios de IAM de su cuenta, abra la consola de IAM
y compruebe el campo AWS Account Alias (Alias de cuenta de AWS) en el panel.
Determinar las necesidades

El componente básico de Aurora es el clúster de base de datos. Una o más instancias de base de datos
pueden pertenecer a un clúster de base de datos. Un clúster de base de datos proporciona una dirección
de red llamada punto de enlace del clúster. Sus aplicaciones se conectan al punto de enlace del clúster
expuesto por el clúster de base de datos siempre que necesitan acceso a las bases de datos creadas en
ese clúster de base de datos. La información especificada al crear el clúster de base de datos controla
elementos de configuración como la memoria, el motor de base de datos y la versión, la configuración de
red, la seguridad y los periodos de mantenimiento.
Debe conocer su clúster de base de datos y las necesidades de la red antes de crear un grupo de
seguridad y un clúster de base de datos. Por ejemplo, debe saber lo siguiente:
• ¿Cuáles son los requisitos de memoria y de procesador para su aplicación o su servicio? Usará esta
configuración cuando determine la clase de instancia de base de datos que se usará al crear el clúster
de base de datos. Para conocer las especificaciones de las clases de instancia de base de datos,
consulte Selección de la clase de instancia de base de datos (p. 61).
• Su clúster de base de datos es una nube virtual privada (VPC). Debe configurar reglas de grupo de
seguridad para conectarse a un clúster de base de datos. En la siguiente lista se describen las reglas de
cada opción de VPC:
• VPC predeterminada: si su cuenta de AWS tiene una VPC predeterminada en la región, esa VPC
se configura de modo que sea compatible con los clústeres de base de datos. Si especifica la VPC
predeterminada al crear el clúster de base de datos:
• Debe crear un grupo de seguridad de VPC que autorice las conexiones desde la aplicación o el
servicio al clúster de base de datos Aurora con la base de datos. Tenga en cuenta que debe utilizar
la API de Amazon EC2 o la opción Security Group (Grupo de seguridad) de la consola de VPC para
crear grupos de seguridad de VPC. Para obtener información, consulte Paso 4: Crear un grupo de
seguridad de VPC (p. 226).
• Debe especificar el grupo de subredes de base de datos predeterminado. Si este es el primer
clúster de base de datos que ha creado en la región, Amazon RDS creará el grupo de subredes de
base de datos predeterminado cuando cree el clúster de base de datos.

52
Proporcionar acceso al clúster de base de datos en la
VPC mediante la creación de un grupo de seguridad
• VPC definida por el usuario: si desea especificar una VPC definida por el usuario al crear un clúster de
base de datos:
• Debe crear un grupo de seguridad de VPC que autorice las conexiones desde la aplicación o el
servicio al clúster de base de datos Aurora con la base de datos. Tenga en cuenta que debe utilizar
la API de Amazon EC2 o la opción Security Group (Grupo de seguridad) de la consola de VPC para
crear grupos de seguridad de VPC. Para obtener información, consulte Paso 4: Crear un grupo de
seguridad de VPC (p. 226)..
• La VPC debe cumplir algunos requisitos para alojar los clústeres de base de datos, como tener al
menos dos subredes, cada una en una zona de disponibilidad diferente. Para obtener información,
consulte VPC Amazon Virtual Private Cloud y Amazon Aurora (p. 211).
• Debe especificar un grupo de subredes de base de datos que defina qué subredes de esa VPC
puede usar el clúster de base de datos. Para obtener información, consulte la sección DB Subnet
Group de Uso de una instancia de base de datos en una VPC (p. 222).
• ¿Necesita compatibilidad con la conmutación por error? En Aurora, una implementación Multi-AZ crea
una instancia primaria y réplicas de Aurora. Puede configurar la instancia primaria y las réplicas de
Aurora para que estén en zonas de disponibilidad diferentes para permitir la conmutación por error.
Es recomendable usar implementaciones Multi-AZ para las cargas de trabajo de producción con
el objeto de mantener una alta disponibilidad. Para fines de desarrollo y de pruebas, puede utilizar
una implementación no Multi-AZ. Para obtener más información, consulte Alta disponibilidad para
Aurora (p. 28).
• ¿Tiene su cuenta de AWS políticas que concedan los permisos necesarios para realizar las operaciones
de Amazon RDS? Si se conecta a AWS con credenciales de IAM, la cuenta de IAM debe tener políticas
de IAM que otorguen los permisos necesarios para realizar operaciones de Amazon RDS. Para obtener
más información, consulte Administración de identidad y acceso en Amazon Aurora (p. 163).
• ¿En qué puerto TCP/IP escuchará la base de datos? Los firewalls de algunas compañías pueden
bloquear las conexiones al puerto predeterminado para el motor de base de datos. Si el firewall de su
compañía bloquea el puerto predeterminado, elija otro puerto para el nuevo clúster de base de datos.
Una vez que cree un clúster de base de datos que escuche en un puerto especificado, puede cambiar el
puerto modificando el clúster de base de datos.
• ¿En qué región desea que esté su base de datos? Tener la base de datos cerca de la aplicación o el
servicio web podría reducir la latencia de la red.
Una vez que tenga la información que necesita para crear el grupo de seguridad y el clúster de base de
datos, vaya al siguiente paso.
Proporcionar acceso al clúster de base de datos

en la VPC mediante la creación de un grupo de
seguridad
Lo más probable es que su clúster de base de datos se cree en una VPC. Los grupos de seguridad
proporcionan acceso al clúster de base de datos en la VPC. Actúan como firewall para el clúster de
base de datos asociado y controlan el tráfico entrante y saliente en el nivel del clúster. Por ejemplo, los
clústeres de base de datos se crean de manera predeterminada con un firewall y un grupo de seguridad
predeterminado que impide el acceso al clúster de base de datos. Por tanto, debe agregar reglas a un
grupo de seguridad que le permita conectarse al clúster de base de datos. Use la información de red y
de configuración que determinó en el paso anterior para crear reglas que permitan el acceso al clúster de
base de datos.
El grupo de seguridad que tiene que crear es un grupo de seguridad de VPC, a menos que tenga un
clúster de base de datos heredada que no esté en una VPC y que requiera un grupo de seguridad de base

53
Proporcionar acceso al clúster de base de datos en la
VPC mediante la creación de un grupo de seguridad
de datos. Si creó su cuenta de AWS después de marzo de 2013, hay muchas probabilidades de que tenga
una VPC predeterminada y el clúster de base de datos se creará en esa VPC. Los clústeres de base de
datos de una VPC requieren la adición de reglas a un grupo de seguridad de VPC para permitir el acceso
al clúster.
Por ejemplo, si tiene una aplicación que obtendrá acceso a una base de datos de su clúster de base de
datos en una VPC, debe añadir una regla de TCP personalizada que especifique el rango de puertos y
direcciones IP que la aplicación usará para obtener acceso a la base de datos. Si tiene una aplicación en
un clúster de Amazon EC2, puede usar el grupo de seguridad de VPC o EC2 que configuró para el clúster
de Amazon EC2.
Para crear un grupo de seguridad de VPC
1. Inicie sesión en la Consola de administración de AWS y abra la consola de Amazon VPC en https://
console.aws.amazon.com/vpc.
2. En la esquina superior derecha de la Consola de administración de AWS, seleccione la región en la
que desea crear el grupo de seguridad de VPC y el clúster de base de datos. La lista de recursos de
Amazon VPC para esa región debería mostrar que tiene al menos una VPC y varias subredes. Si no
es así, no tiene una VPC predeterminada en esa región.
3. En el panel de navegación, elija Security Groups.
4. Elija Create Security Group.
5. En la ventana Create Security Group, escriba los valores de Name tag, Group name y Description
correspondientes a su grupo de seguridad. Seleccione la VPC en la que desea crear su clúster de
base de datos. Elija Yes, Create.
6. El grupo de seguridad de VPC que ha creado debería seguir seleccionado. El panel de detalles de
la parte inferior de la ventana de la consola muestra los detalles del grupo de seguridad, junto con
pestañas que permiten trabajar con las reglas de entrada y salida. Elija la pestaña Inbound Rules
(Reglas entrantes).
7. En la pestaña Inbound Rules, elija Edit. Seleccione Custom TCP Rule en la lista Type. Escriba el
valor del puerto que usará para el clúster de base de datos en el cuadro de texto Port Range (Rango
de puertos) y, a continuación, escriba el intervalo de direcciones IP (valor de CIDR) desde el que
accederá al clúster o seleccione el nombre de un grupo de seguridad en el cuadro de texto Source
(Origen).
8. Si necesita añadir más direcciones IP o diferentes rangos de puertos, elija Add another rule (Añadir
otra regla).
9. Si lo necesita, puede utilizar la pestaña Outbound Rules para añadir reglas para el tráfico saliente.
10. Cuando haya terminado, haga clic en Save (Guardar) en cada pestaña que contenga cambios.
Usará el grupo de seguridad de VPC que acaba de crear como grupo de seguridad del clúster de base
de datos cuando lo cree.
Por último, una nota rápida acerca de las subredes de VPC: si se usa una VPC predeterminada, ya
se habrá creado un grupo de subredes predeterminado que abarca todas las subredes de la VPC.
Al crear un clúster de base de datos, puede seleccionar la VPC predeterminada y usar default (valor
predeterminado) para DB Subnet Group (Grupo de subred de base de datos).
Una vez que haya completado los requisitos de configuración, puede usar sus requisitos y el grupo de
seguridad que ha creado para lanzar un clúster de base de datos. Para obtener información acerca
de la creación de un clúster de base de datos, consulte la documentación relacionada en la siguiente
tabla:
Una vez configurado, puede crear un clúster de base de datos Amazon Aurora de prueba. Para
obtener instrucciones, consulte Crear un clúster de base de datos y conectarse a una base de datos
en un clúster de base de datos Amazon Aurora (p. 55).

54
Creación de un clúster de Aurora y conectarse a él
Introducción a Amazon Aurora

Esta sección le muestra cómo crear un clúster de base de datos Aurora con Amazon RDS y cómo
conectarse a él.
Este procedimiento es un tutorial que muestra los aspectos básicos de la introducción a Aurora. Las
siguientes secciones presentan procedimientos y conceptos de Aurora más avanzados, como los
diferentes tipos de puntos de enlace y cómo escalar clústeres de Aurora para ampliarlos o reducirlos.
Important
Debe completar las tareas de la sección Configuración del entorno para Amazon Aurora (p. 50)
para poder crear un clúster de base de datos.
Crear un clúster de base de datos y conectarse a

una base de datos en un clúster de base de datos
Amazon Aurora
La forma más sencilla de crear un clúster de base de datos Amazon Aurora es mediante la consola de
Amazon RDS. Una vez que haya creado el clúster de base de datos, puede utilizar utilidades MySQL
estándar, como MySQL Workbench o utilidades PostgreSQL, como pgAdmin, para conectarse a una base
de datos en el clúster.
Temas
• Crear un clúster de base de datos (p. 55)
• Conectarse a una instancia en un clúster de base de datos (p. 58)
• Elimine el clúster de base de datos de ejemplo, el grupo de subred de base de datos y la
VPC (p. 60)
Crear un clúster de base de datos

Antes de crear un clúster de base de datos, en primer lugar debe tener una Amazon Virtual Private Cloud
(VPC) y un grupo de subred de base de datos de Amazon RDS. Su VPC debe tener al menos una subred
en al menos dos zonas de disponibilidad. Puede utilizar la VPC predeterminada para su cuenta de AWS,
o bien puede crear su propia VPC. La consola de Amazon RDS facilita la creación de su propia VPC para
utilizarla con Amazon Aurora o utilizar una VPC existente con el clúster de base de datos Aurora.
Si desea crear una VPC y un grupo de subred de base de datos para utilizarlos con el clúster de base de
datos Amazon Aurora, en lugar de hacer que Amazon RDS cree la VPC y el grupo de subred de base de
datos por usted, a continuación siga las instrucciones que podrá encontrar en Cómo crear una VPC para
el uso con Amazon Aurora (p. 211). De lo contrario, siga las instrucciones que se incluyen en este tema
para crear su clúster de base de datos y haga que Amazon RDS cree una VPC y un grupo de subred de
base de datos automáticamente.
Note
Aurora no está disponible en todas las regiones de AWS. Para obtener una lista de las regiones
de AWS en las que está disponible Aurora, consulte Disponibilidad (p. 65).
Para lanzar un clúster de base de datos Aurora MySQL

55
1. Inicie sesión en la Consola de administración de AWS y abra la consola de Amazon RDS en https://
console.aws.amazon.com/rds/.
2. En la esquina superior derecha de la Consola de administración de AWS, elija la región de AWS en la
que desea crear el clúster de base de datos. Para obtener una lista de las regiones de AWS en las que
está disponible Aurora, consulte Disponibilidad (p. 65).
3. En el panel de navegación, seleccione Instances (Instancias).
Si el panel de navegación está cerrado, elija el icono de menú en la parte superior izquierda para abrirlo.
4. Elija Create database (Crear base de datos) para abrir la página Select engine (Seleccionar motor).
5. En la página Select engine (Seleccionar motor) elija Amazon Aurora y la edición compatible con MySQL
6. Seleccione Next (Siguiente).

7. Defina los siguientes valores en la página Specify DB details:
• DB instance class: db.r3.large
• identificador de instancias de bases de datos: gs-db-instance1
• Master username: escriba con caracteres alfanuméricos un nombre de usuario maestro, que se
utilizará para iniciar sesión en sus instancias de base de datos en el clúster de base de datos.

56
• Master password y Confirm Password: escriba una contraseña en el cuadro Master Password
que contiene entre 8 y 41 caracteres ASCII imprimibles (excepto /, " y @) para su contraseña de
usuario maestro, utilizada para iniciar sesión en su base de datos. A continuación, vuelva a escribir la
contraseña en el cuadro Confirm Password.
8. Elija Next y defina los siguientes valores en la página Configure Advanced Settings:
• Virtual Private Cloud (VPC): si ya dispone de una VPC, puede utilizarla con su clúster de base de
datos de Amazon Aurora seleccionando el identificador de la VPC, por ejemplo, vpc-a464d1c1.
Para obtener información acerca del uso de una VPC, consulte Cómo crear una VPC para el uso con
Amazon Aurora (p. 211).

57
Conectarse a una instancia en un clúster de base de datos
De lo contrario, puede optar por hacer que Amazon RDS cree una VPC por usted eligiendo Create a
new VPC (Crear una VPC nueva). Este ejemplo utiliza la opción Create a new VPC.
• Subnet Group (Grupo de subred): si dispone de un grupo de subred existente, puede utilizarlo con su
clúster de base de datos Amazon Aurora eligiendo el identificador del grupo de subred, por ejemplo,
gs-subnet-group1.
De lo contrario, puede optar por hacer que Amazon RDS cree un grupo de subred eligiendo Create
a new subnet group (Crear un grupo de subred nuevo). Este ejemplo utiliza la opción Create a new
subnet group.
• Public accessibility: Yes
Note
No es necesario que su clúster de base de datos de producción esté en una subred pública,
ya que solo los servidores de su aplicación necesitan acceso a su clúster de base de datos.
Si no es necesario que su clúster de base de datos esté en una subred pública, defina
Publicly Accessible como No.
• Availability zone: No Preference
• VPC security groups (Grupos de seguridad de VPC): si dispone de uno o más grupos de seguridad de
VPC, puede utilizar uno o varios grupos con su clúster de base de datos Amazon Aurora eligiendo los
identificadores del grupo de seguridad de VPC, por ejemplo, gs-security-group1.
De lo contrario, puede optar por hacer que Amazon RDS cree un grupo de seguridad de VPC por
usted eligiendo Create a new Security group (Crear un grupo de seguridad nuevo). Este ejemplo
utiliza la opción Create a new Security group.
• DB Cluster Identifier: gs-db-cluster1
• Nombre de base de datos: sampledb
Note
Esto crea la base de datos predeterminada. Para crear otras bases de datos, conéctese al
clúster de base de datos y use el comando SQL CREATE DATABASE.
• Database port: 3306
Note
Es posible que se encuentre detrás del firewall de una compañía que no permite obtener
acceso a puertos predeterminados, como el puerto 3306 de Aurora MySQL. En este caso,
proporcione un valor de puerto permitido por el firewall corporativo. Recuerde el valor del
puerto cuando se conecte más adelante al clúster de base de datos de Aurora.
9. Deje el resto de los valores como valores predeterminados y elija Create database (Crear base de
datos) para crear el clúster de base de datos y la instancia principal.
Conectarse a una instancia en un clúster de base de

datos
Una vez que Amazon RDS aprovisione el clúster de base de datos y cree la instancia principal, puede
usar cualquier aplicación cliente SQL estándar para conectarse a una base de datos del clúster. En este
ejemplo, se conecta a una base de datos en el clúster de base de datos de Aurora MySQL mediante los
comandos del monitor de MySQL. MySQL Workbench es una de las aplicaciones basadas en interfaz
gráfica de usuario (GUI) que puede utilizar para conectarse. Para obtener más información, vaya a la
página Download MySQL Workbench.

58
Conectarse a una instancia en un clúster de base de datos
Para conectarse a una base de datos en un clúster de base de datos Aurora MySQL mediante el
monitor de MySQL, realice el siguiente procedimiento:
2. Elija Databases (Bases de datos) y, a continuación, elija el clúster de base de datos para mostrar los
detalles de dicho clúster. En la página de detalles, copie el valor correspondiente a Cluster endpoint.
3. Escriba el siguiente comando en el símbolo del sistema de un equipo cliente para conectarse a una
base de datos en un clúster de base de datos de Aurora MySQL con el monitor de MySQL. Utilice el
punto de enlace del clúster para conectarse a la instancia principal y el nombre de usuario maestro

59
Elimine el clúster de base de datos de ejemplo,
el grupo de subred de base de datos y la VPC
que creó anteriormente (se le pedirá que escriba una contraseña). Si proporcionó un valor para el
puerto distinto de 3306, utilícelo en el parámetro -P.
PROMPT> mysql -h <cluster endpoint> -P 3306 -u <mymasteruser> -p
Debería ver un resultado similar a este.
Welcome to the MySQL monitor. Commands end with ; or \g.

Your MySQL connection id is 350
Server version: 5.6.10-log MySQL Community Server (GPL)
Type 'help;' or '\h' for help. Type '\c' to clear the buffer.
mysql>
Para obtener más información acerca de la conexión al clúster de base de datos, consulte Conexión a un
clúster de base de datos Amazon Aurora (p. 148).
Elimine el clúster de base de datos de ejemplo, el

grupo de subred de base de datos y la VPC
Una vez que se haya conectado al clúster de base de datos de ejemplo que creó, puede eliminar el clúster
de base de datos, el grupo de subred de base de datos y la VPC (si creó una).
Para eliminar un clúster de base de datos
2. Elija Instances y, a continuación, elija la instancia de base de datos gs-db-instance1.
3. En Actions (Acciones), elija Delete (Eliminar).
4. Elija Eliminar.
Para eliminar un grupo de subred de base de datos
2. Elija Subnet groups y, a continuación, el grupo de subredes de base de datos gs-subnet-group1.
3. Elija Eliminar.
4. Elija Eliminar.
Para eliminar un VPC
console.aws.amazon.com/vpc/.
2. Elija Your VPCs y, a continuación, elija la VPC que se creó para este procedimiento.
3. En Actions (Acciones), elija Delete VPC (Eliminar VPC).
4. Elija Eliminar.

60
Selección de la clase de instancia de base de datos
Configuración de su clúster de base

de datos Amazon Aurora
En esta sección se muestra cómo configurar un clúster de base de datos Aurora. Antes de crear un clúster
de base de datos Aurora, decida qué clase de instancia de base de datos ejecutará el clúster de base de
datos. Además, decida dónde se ejecutará el clúster de base de datos seleccinando una región de AWS. A
continuación, cree el clúster de base de datos. Si tiene datos fuera de Aurora, puede migrar los datos a un
clúster de base de datos Aurora.
Temas
• Selección de la clase de instancia de base de datos (p. 61)
• Elección de Regiones y zonas de disponibilidad (p. 64)
• Facturación de instancia de base de datos para Aurora (p. 71)
• Creación de un clúster de base de datos de Amazon Aurora (p. 85)
• Uso de Amazon Aurora Serverless (p. 100)
• Conexión a un clúster de base de datos Amazon Aurora (p. 148)
• Migración de datos a un clúster de base de datos Amazon Aurora (p. 154)
Selección de la clase de instancia de base de datos

La clase de instancia de base de datos determina la capacidad de cómputo y de memoria de una instancia
de base de datos Amazon RDS. La clase de instancia de base de datos que necesita depende de la
potencia de procesamiento y de los requisitos de memoria.
Para obtener más información acerca de los precios de las clases de instancias, consulte Precios de
Amazon RDS.
Temas
• Tipos de clase de instancia de base de datos (p. 61)
• Terminología para especificaciones de hardware de clase de instancia de base de datos (p. 62)
• Especificaciones de hardware para todas las clases de instancia de base de datos disponibles para
Aurora (p. 62)
Tipos de clase de instancia de base de datos

Amazon Aurora admite dos tipos de clases de instancia: optimizada para memoria y desempeño por
ráfagas. Para obtener más información sobre los tipos de instancias Amazon EC2, consulte Tipo de
instancia en la documentación de Amazon EC2.
A continuación se indican las clases de instancias de bases de datos optimizadas para memoria:
• db.r5: clases de instancias de última generación optimizadas para las aplicaciones que hacen un uso
intensivo de la memoria. Ofrecen un rendimiento mejorado de redes. Con tecnología del nuevo sistema
Nitro de AWS, una combinación de hardware dedicado e hipervisor ligero.

61
Terminología
• db.r4: clases de instancias de la generación actual optimizadas para las aplicaciones que hacen un uso
intensivo de la memoria. Ofrece un rendimiento mejorado de redes y de .
• db.r3: clases de instancia de generación anterior que mejoran la optimización de memoria. Las clases de
instancia de db.r3 no están disponibles para la región UE (París).
A continuación se indican las clases de instancias de bases de datos de desempeño por ráfagas:
• db.t3: clases de instancias de última generación que proporcionan un nivel de desempeño de referencia
con la capacidad de transmitir ráfagas que usen la totalidad de la CPU. Las clases de instancia
proporcionan más capacidad de computación que las clases de instancia db.t2 anteriores.
• db.t2: clases de instancias de generación actual que proporcionan un nivel de desempeño de referencia
con la capacidad de transmitir ráfagas que usen la totalidad de la CPU. Recomendamos que se usen
estas clases de instancia solo para los servidores de desarrollo y de pruebas, o para otros servidores
que no se utilicen para la producción.
Terminología para especificaciones de hardware de

clase de instancia de base de datos
La siguiente terminología se utiliza para describir las especificaciones de hardware para clases de
instancia de base de datos:
• vCPU: es la cantidad de unidades de procesamiento central (CPU) virtuales. Una CPU virtual es una
unidad de capacidad que se puede usar para comparar clases de instancia de base de datos. En
lugar de comprar o arrendar un procesamiento concreto para usarlo durante varios meses o años, la
capacidad se alquila por horas. Nuestro objetivo es proporcionar una cantidad constante y específica de
capacidad de CPU dentro de los límites del hardware subyacente real.
• ECU: la medida relativa de la potencia de procesamiento íntegra de una instancia Amazon EC2. Para
facilitar a los desarrolladores la comparación de la capacidad de la CPU entre distintas clases de
instancia, hemos definido una unidad de computación Amazon EC2. La cantidad de CPU asignada a
una instancia concreta se expresa en términos de estas unidades informáticas EC2. Actualmente, una
ECU proporciona capacidad de CPU equivalente a un procesador 2007 Opteron o 2007 Xeon de 1,0–1,2
GHz.
• Memoria (GiB): la memoria RAM, en gibibytes, asignada a la instancia de base de datos. A menudo, hay
una relación coherente entre memoria y vCPU. Como ejemplo, seleccione la clase de instancia db.r4,
que dispone de una memoria en la relación de vCPU similar a la clase de instancia db.r5. Sin embargo,
para la mayoría de casos de uso, la clase de instancia db.r5 proporciona un mejor rendimiento y más
coherente que la clase de instancia db.r4.
• Rendimiento máx. (Mbps): el ancho de banda máximo en megabits por segundo. Divídalo entre 8 para
obtener el rendimiento esperado en megabytes por segundo.
• Desempeño de red: la velocidad de red relativa a otras clases de instancia de base de datos.
Especificaciones de hardware para todas las clases

de instancia de base de datos disponibles para Aurora
En la siguiente tabla, podrá encontrar detalles sobre las clases de instancia de base de datos de Amazon
RDS disponibles para Amazon Aurora. Para obtener una explicación detallada de la terminología de
columna de la tabla, consulte Terminología para especificaciones de hardware de clase de instancia de
base de datos (p. 62).
A continuación se muestran las consideraciones del motor de base de datos para las clases de instancia
de base de datos:

62
Especificaciones de hardware
• Compatibilidad de Aurora con db.r5: todas las versiones de Aurora MySQL admiten las clases de
instancia db.r5, excepto la case de instancia db.r5.24xlarge. Para Aurora PostgreSQL, solo las versiones
compatibles con PostgreSQL 10.6 o versiones posteriores admiten las clases de instancia db.r5. Estas
clases de instancia están disponibles en todas las regiones de Aurora, excepto en AWS GovCloud (US-
West), AWS GovCloud (EE.UU. Este) y China (Pekín).
• Compatibilidad de Aurora con db.t3: Aurora MySQL admite las clases de instancia db.t3.medium y
db.t3.small para Aurora MySQL 1.15 y versiones posteriores, y todas las versiones Aurora MySQL
2.*. Estas clases de instancia están disponibles para Aurora MySQL en todas las regiones de Aurora,
excepto AWS GovCloud (US-West), AWS GovCloud (EE.UU. Este) y China (Pekín).
Clase de instancia vCPU ECU Memoria Rendimiento Rendimiento Aurora Aurora

(GiB) Ancho de la red MySQL PostgreSQL
de banda
(Mbps)
db.r5: clases de instancia con optimización de memoria de última generación
db.r5.24xlarge 96 347 768 14 000 25 Gbps No Sí
db.r5.12xlarge 48 173 384 7000 10 Gbps Sí Sí
db.r5.4xlarge 16 71 128 3500 Hasta 10 Sí Sí

Gbps
db.r5.2xlarge 8 38 64 Hasta Hasta 10 Sí Sí

3500 Gbps
db.r5.xlarge 4 19 32 Hasta Hasta 10 Sí Sí

3500 Gbps
db.r5.large 2 10 16 Hasta Hasta 10 Sí Sí

3500 Gbps
db.r4: clases de instancias con optimización de memoria de la generación actual
db.r4.16xlarge 64 195 488 14 000 25 Gbps 1.14.4 Sí

y
versiones
posteriores
db.r4.8xlarge 32 99 244 7000 10 Gbps 1.14.4 Sí

y
versiones
posteriores
db.r4.4xlarge 16 53 122 3500 Hasta 10 1.14.4 Sí

Gbps y
versiones
posteriores
db.r4.2xlarge 8 27 61 1.750 Hasta 10 1.14.4 Sí

Gbps y
versiones
posteriores
db.r4.xlarge 4 13.5 30.5 875 Hasta 10 1.14.4 Sí

Gbps y

63
Elección de Regiones y zonas de disponibilidad
versiones
posteriores
db.r4.large 2 7 15.25 437 Hasta 10 1.14.4 Sí

Gbps y
versiones
posteriores
db.r3: clases de instancia con optimización de memoria de generación anterior
db.r3.8xlarge 32 104 244 — 10 Gbps Sí No
db.r3.4xlarge 16 52 122 2,000 Alta Sí No
db.r3.2xlarge 8 26 61 1 000 Alta Sí No
db.r3.xlarge 4 13 30.5 500 Moderado Sí No
db.r3.large 2 6.5 15.25 — Moderado Sí No
Clase de instancia vCPU ECU Memoria Rendimiento Rendimiento Aurora Aurora

(GiB) Ancho de la red MySQL PostgreSQL
de banda
(Mbps)
db.t3: clases de instancia de rendimiento ampliable de última generación
db.t3.2xlarge 8 Variable 32 2050 Hasta No No

5 gigabits
db.t3.xlarge 4 Variable 16 2050 Hasta No No

5 gigabits
db.t3.large 2 Variable 8 2050 Hasta No No

5 gigabits
db.t3.medium 2 Variable 4 1500 Hasta Sí Sí

5 gigabits
db.t3.small 2 Variable 2 1500 Hasta Sí No

5 gigabits
db.t3.micro 2 Variable 1 1500 Hasta No No

5 gigabits
db.t2: clases de instancia con desempeño por ráfagas de generación actual
db.t2.medium 2 Variable 4 — Moderado Sí No
db.t2.small 1 Variable 2 — Baja Sí No
Elección de Regiones y zonas de disponibilidad

Los recursos de informática en la nube de Amazon están alojados en varias ubicaciones de todo el mundo.
Dichas ubicaciones se componen de regiones y zonas de disponibilidad de AWS. Cada región de AWS es
un área geográfica independiente. Cada región de AWS tiene varias ubicaciones aisladas conocidas como
zonas de disponibilidad. Amazon RDS ofrece la posibilidad de colocar recursos, como instancias y datos,
en varias ubicaciones. Los recursos no se replican en las regiones de AWS, a menos que usted decida
hacerlo específicamente.

64
Disponibilidad
Amazon opera centros de datos de alta disponibilidad con tecnología de vanguardia. Aunque es
infrecuente, puede suceder que se produzcan errores que afecten a la disponibilidad de las instancias que
están en la misma ubicación. Si hospeda todas las instancias en una misma ubicación y se produce un
error en ella, ninguna de las instancias estaría disponible.
Es importante recordar que cada región de AWS es completamente independiente. Cualquier actividad de
Amazon RDS que se inicie (por ejemplo, la creación de instancias de base de datos o la enumeración de
las instancias de base de datos disponibles) se ejecuta solo en la región de AWS predeterminada actual.
La región de AWS predeterminada se puede modificar en la consola definiendo la variable de entorno
EC2_REGION o se puede anular usando el parámetro --region con la AWS Command Line Interface.
Consulte Configuración de la AWS Command Line Interface, en particular, las secciones relativas a las
variables de entorno y las opciones de la línea de comandos, para obtener más información.
Amazon RDS admite una región de AWS especial llamada AWS GovCloud (US-West) que se ha diseñado
para permitir a los clientes y los organismos gubernamentales de Estados Unidos mover cargas de
trabajo más confidenciales a la nube. AWS GovCloud (US-West) gestiona sus requisitos normativos y de
conformidad específicos del gobierno de Estados Unidos. Para obtener más información acerca de AWS
GovCloud (US-West), consulte ¿Qué es AWS GovCloud (US-West)?
Para crear una instancia de base de datos de Amazon RDS o trabajar con ella en una región de AWS
concreta, use el punto de enlace de servicio regional correspondiente.
Disponibilidad
En la siguiente tabla se muestran las regiones en las que Aurora MySQL está disponible actualmente.
Region Region Endpoint Protocol

Name
EE.UU. us-east-2 rds.us-east-2.amazonaws.com HTTPS

Este
(Ohio)

Este
(Norte de
Virginia)
EE.UU. us-west-1 rds.us-west-1.amazonaws.com HTTPS

Oeste
(Norte de
California)

65
Disponibilidad

Name

Oeste
(Oregón)
Asia ap-east-1 rds.ap-east-1.amazonaws.com HTTPS

Pacífico
(Hong
Kong)
Asia ap-south-1 rds.ap-south-1.amazonaws.com HTTPS

Pacífico
(Mumbai)
Asia ap- rds.ap-northeast-2.amazonaws.com HTTPS

Pacífico northeast-2
(Seúl)
Asia ap- rds.ap-southeast-1.amazonaws.com HTTPS

Pacífico southeast-1
(Singapur)

(Sídney)

(Tokio)
Canadá ca- rds.ca-central-1.amazonaws.com HTTPS

(Central) central-1
China cn- rds.cn-northwest-1.amazonaws.com.cn HTTPS

(Ningxia) northwest-1
UE eu- rds.eu-central-1.amazonaws.com HTTPS

(Fráncfort) central-1
UE eu-west-1 rds.eu-west-1.amazonaws.com HTTPS

(Irlanda)

(Londres)
UE (París) eu-west-3 rds.eu-west-3.amazonaws.com HTTPS
UE eu-north-1 rds.eu-north-1.amazonaws.com HTTPS

(Estocolmo)
Medio me- rds.me-south-1.amazonaws.com HTTPS

Oriente south-1
(Baréin)
AWS us-gov- rds.us-gov-east-1.amazonaws.com HTTPS

GovCloud east-1
(US-East)

66
Disponibilidad

Name
AWS us-gov- rds.us-gov-west-1.amazonaws.com HTTPS

GovCloud west-1
(EE.UU.)
En la siguiente tabla se muestran las regiones en las que Aurora PostgreSQL está disponible actualmente.

Name

Este
(Ohio)

Este
(Norte de
Virginia)

Oeste
(Norte de
California)

Oeste
(Oregón)

Pacífico
(Hong
Kong)

Pacífico
(Mumbai)

(Seúl)

(Singapur)

(Sídney)

(Tokio)

(Central) central-1

67
Zona horaria local para los clústeres de base de datos

Name



(Irlanda)

(Londres)

(Estocolmo)

Oriente south-1
(Baréin)

GovCloud east-1
(US-East)

GovCloud west-1
(EE.UU.)

Amazon Aurora
De manera predeterminada, la zona horaria del clúster de base de datos Amazon Aurora es el horario
universal coordinado (UTC). En su lugar, puede definir la zona horaria de las instancias del clúster de base
de datos en la zona horaria local de su aplicación.
Para definir la zona horaria local para un clúster de base de datos, configure el parámetro time_zone del
grupo de parámetros del clúster de base de datos en uno de los valores admitidos que se enumeran más
adelante en esta sección. Cuando se define el parámetro time_zone para un clúster de base de datos,
todas las instancias de ese clúster de base de datos cambian para usar la nueva zona horaria local. Si
otros clústeres de base de datos Aurora están usando el mismo grupo de parámetros de clúster, todas
las instancias de esos clústeres de base de datos cambiarán para usar también la nueva zona horaria
local. Para obtener más información acerca de los parámetros de nivel de clúster, consulte Parámetros del
clúster de base de datos y la instancia de base de datos Amazon Aurora (p. 261).
Después de definir la zona horaria local, todas las conexiones nuevas con la base de datos reflejarán el
cambio. Si tiene alguna conexión con la base de datos abierta al cambiar la zona horaria local, no verá la
actualización de la zona horaria local hasta que cierre la conexión y abra una nueva conexión.
Si está replicando entre regiones de AWS, el clúster de base de datos maestro de la replicación y la réplica
usarán distintos grupos de parámetros (los grupos de parámetros son únicos para una región de AWS). Si
desea usar la misma zona horaria local para cada instancia, debe configurar el parámetro time_zone de
los grupos de parámetros tanto del maestro de replicación como de la réplica.

68
Cuando se restaura un clúster de base de datos desde una instantánea de clúster de base de datos, la
zona horaria local se define como UTC. Podrá actualizar la zona horaria a su zona horaria local una vez
que se haya completado la restauración. Si restaura un clúster de base de datos a un momento dado,
la zona horaria local del clúster de base de datos restaurado será el ajuste de zona horaria del grupo de
parámetros del clúster de base de datos restaurado.
Puede definir su zona horaria local en uno de los valores que se muestran en la siguiente tabla. Para
algunas zonas horarias, los valores de horas de determinados rangos de fechas pueden indicarse de un
modo incorrecto, como se muestra en la tabla. Para algunas zonas horarias de Australia, la abreviatura de
zona devuelta es un valor obsoleto, como se muestra en la tabla.
Zona horaria Notas
Africa/Harare Este ajuste de zona horaria puede devolver valores incorrectos del 28 de
febrero de 1903 a las 21:49:40 GMT hasta el 28 de febrero de 1903 a las
21:55:48 GMT.
Africa/Monrovia
Africa/Nairobi Este ajuste de zona horaria puede devolver valores incorrectos del 31 de
diciembre de 1939 a las 21:30:00 GMT hasta el 31 de diciembre de 1959 a las
21:15:15 GMT.
Africa/Windhoek
America/Bogota Este ajuste de zona horaria puede devolver valores incorrectos del 23 de
noviembre de 1914 a las 04:56:16 GMT hasta el 23 de noviembre de 1914 a
las 04:56:20 GMT.
America/Caracas
America/Chihuahua
America/Cuiaba
America/Denver
America/Fortaleza
America/Guatemala
America/Halifax Este ajuste de zona horaria puede devolver valores incorrectos del 27 de
octubre de 1918 a las 05:00:00 GMT hasta el 31 de octubre de 1918 a las
05:00:00 GMT.
America/Manaus
America/Matamoros
America/Monterrey
America/Montevideo
America/Phoenix
America/Tijuana
Asia/Ashgabat
Asia/Baghdad

69
Zona horaria Notas
Asia/Baku
Asia/Bangkok
Asia/Beirut
Asia/Calcutta
Asia/Kabul
Asia/Karachi
Asia/Kathmandu
Asia/Muscat Este ajuste de zona horaria puede devolver valores incorrectos del 31 de
diciembre de 1919 a las 20:05:36 GMT hasta el 31 de diciembre de 1919 a las
20:05:40 GMT.
Asia/Riyadh Este ajuste de zona horaria puede devolver valores incorrectos del 13 de
marzo de 1947 a las 20:53:08 GMT hasta el 31 de diciembre de 1949 a las
20:53:08 GMT.
Asia/Seoul Este ajuste de zona horaria puede devolver valores incorrectos del 30 de
noviembre de 1904 a las 15:30:00 GMT hasta el 7 de septiembre de 1945 a
las 15:00:00 GMT.
Asia/Shanghai Este ajuste de zona horaria puede devolver valores incorrectos del 31 de
diciembre de 1927 a las 15:54:08 GMT hasta el 2 de junio de 1940 a las
16:00:00 GMT.
Asia/Singapore
Asia/Taipei Este ajuste de zona horaria puede devolver valores incorrectos del 30 de
septiembre de 1937 a las 16:00:00 GMT hasta el 29 de septiembre de 1979 a
las 15:00:00 GMT.
Asia/Tehran
Asia/Tokyo Este ajuste de zona horaria puede devolver valores incorrectos del 30 de
septiembre de 1937 a las 15:00:00 GMT hasta el 31 de diciembre de 1937 a
las 15:00:00 GMT.
Asia/Ulaanbaatar
Atlantic/Azores Este ajuste de zona horaria puede devolver valores incorrectos del 24 de
mayo de 1911 a las 01:54:32 GMT hasta el 1 de enero de 1912 a las 01:54:32
GMT.
Australia/Adelaide La abreviatura de esta zona horaria aparece como CST en lugar de ACDT/
ACST.
Australia/Brisbane La abreviatura de esta zona horaria aparece como EST en lugar de AEDT/
AEST.
Australia/Darwin La abreviatura de esta zona horaria aparece como CST en lugar de ACDT/
ACST.
Australia/Hobart La abreviatura de esta zona horaria aparece como EST en lugar de AEDT/
AEST.

70
Facturación de instancia de base de datos para Aurora
Zona horaria Notas
Australia/Perth La abreviatura de esta zona horaria aparece como WST en lugar de AWDT/
AWST.
Australia/Sydney La abreviatura de esta zona horaria aparece como EST en lugar de AEDT/
AEST.
Brazil/East
Canada/ Este ajuste de zona horaria puede devolver valores incorrectos del 27 de
Saskatchewan octubre de 1918 a las 08:00:00 GMT hasta el 31 de octubre de 1918 a las
08:00:00 GMT.
Europe/Amsterdam
Europe/Athens
Europe/Dublin
Europe/Helsinki Este ajuste de zona horaria puede devolver valores incorrectos del 30 de abril
de 1921 a las 22:20:08 GMT hasta el 30 de abril de 1921 a las 22:20:11 GMT.
Europe/Paris
Europe/Prague
Europe/Sarajevo
Pacific/Auckland
Pacific/Guam
Pacific/Honolulu Este ajuste de zona horaria puede devolver valores incorrectos del 21 de
mayo de 1933 a las 11:30:00 GMT hasta el 30 de septiembre de 1945 a las
11:30:00 GMT.
Pacific/Samoa Este ajuste de zona horaria puede devolver valores incorrectos del 1 de enero
de 1911 a las 11:22:48 GMT hasta el 1 de enero de 1950 a las 11:30:00 GMT.
US/Alaska
US/Central
US/Eastern
US/East-Indiana
US/Pacific
UTC
Facturación de instancia de base de datos para

Aurora
Las instancias de Amazon RDS en un clúster de Aurora se facturan en función de los siguientes
componentes:

71
Instancias de base de datos bajo demanda
• Horas de instancia de base de datos (por hora): en función de la clase de instancia de base de datos
(por ejemplo, db.t2.small o db.m4.large). Los precios se muestran por hora, pero las facturas se ajustan
hasta el segundo y muestran las horas en formato decimal. El uso de RDS se factura por incrementos
de un segundo, con un mínimo de 10 minutos. Para obtener más información, consulte Selección de la
clase de instancia de base de datos (p. 61).
• Solicitudes de E/S (por millón de solicitudes al mes): número total de solicitudes de E/S de
almacenamiento realizadas en un ciclo de facturación.
• Almacenamiento de copias de seguridad (por GiB al mes): el almacenamiento de copias de seguridad
es el almacenamiento asociado a copias de seguridad de base de datos automatizadas y cualquier
instantánea de base de datos activa que haya realizado. Aumentar el período de retención de copia
de seguridad u obtener instantáneas de base de datos adicionales aumenta el almacenamiento de
copias de seguridad consumido por su base de datos. La facturación por segundo no se aplica al
almacenamiento de copia de seguridad (medido en GB/mes).
Para obtener más información, consulte Backup y restauración de un clúster de base de datos de
• Transferencia de datos (por GB): las transferencias de datos de entrada y de salida de Internet y otras
regiones de AWS.
Amazon RDS proporciona las siguientes opciones de compra para que pueda optimizar los costos en
función de sus necesidades:
• On-Demand Instances (Instancias bajo demanda): pague por las horas de instancia de base de datos
que use. Los precios se muestran por hora, pero las facturas se ajustan hasta el segundo y muestran
las horas en formato decimal. El uso de RDS se factura ahora por incrementos de un segundo, con un
mínimo de 10 minutos.
• Reserved Instances (Instancias reservadas): reserve una instancia de base de datos durante un plazo
de uno a tres años y obtenga descuentos importantes en comparación con los precios de instancias
de base de datos bajo demanda. Cuando use instancias reservadas, podrá lanzar, eliminar, iniciar o
detener varias instancias dentro de una misma hora y obtener el beneficio de instancia reservada para
todas las instancias.
Para obtener información acerca de los precios de Aurora, consulte la página de precios de Aurora.
Temas
• Instancias de base de datos bajo demanda (p. 72)
• Instancias de base de datos reservadas (p. 73)
Instancias de base de datos bajo demanda

Las instancias de base de datos bajo demanda de Amazon RDS se facturan en función de la clase de
instancia de base de datos (por ejemplo, db.t2.small o db.m4.large). Las horas de instancia de base de
datos parciales consumidas se facturan como horas completas. Para obtener información acerca de los
precios de Amazon RDS, consulte la página del producto de Amazon RDS.
La facturación de una instancia de base de datos comienza en cuanto la instancia está disponible. Los
precios se muestran por hora, pero las facturas se ajustan hasta el segundo y muestran las horas en
formato decimal. El uso de Amazon RDS se factura por incrementos de un segundo, con un mínimo de 10
minutos. En caso de un cambio de configuración facturable, como el escalado informático o la capacidad
de almacenamiento, se le cobrará un mínimo de 10 minutos. La facturación continúa hasta que se termina
la instancia de base de datos, lo que tiene lugar cuando se elimina la instancia de base de datos o produce
un error.

72
Instancias de base de datos reservadas
Si ya no desea que se le cobre por su instancia de base de datos, debe detenerla o eliminarla para evitar
que se le cobren horas de instancia de base de datos adicionales. Para obtener más información acerca
de los estados de instancias de base de datos que se le cobran, consulte Estado de la instancia de base
de datos (p. 381).
Instancias de base de datos detenidas

Mientras la instancia de base de datos está detenida, se le cobra el almacenamiento provisionado,
incluidas las IOPS provisionadas. También se le cobra el almacenamiento de copias de seguridad, incluido
el almacenamiento de las instantáneas manuales y las copias de seguridad automatizadas en el periodo
de retención especificado. No se le cobrarán las horas de instancia de base de datos.
Instancias de base de datos Multi-AZ

Si especifica que su instancia de base de datos debe ser una implementación Multi-AZ, se le facturará de
acuerdo con el precio de Multi-AZ publicado en la página de precios de Amazon RDS.

Puede reservar una instancia de base de datos durante un periodo de un año o de tres años mediante
instancias de base de datos reservadas. Las instancias de base de datos reservadas ofrecen un
descuento importante en comparación con los precios de las instancias de base de datos bajo demanda.
Las instancias de base de datos reservadas no son instancias físicas sino más bien un descuento de
facturación que se aplica al uso de determinadas instancias de base de datos bajo demanda en su cuenta.
Los descuentos para instancias de base de datos reservadas están vinculados al tipo de instancia y a la
región de AWS.
El proceso general de trabajo con instancias de base de datos reservadas es el siguiente: en primer lugar,
obtener información sobre las ofertas de instancias de base de datos reservadas; en segundo lugar,
comprar una oferta y, por último, obtener información sobre las instancias de base de datos reservadas.
Información general sobre instancias de base de datos

reservadas
Cuando adquiere una instancia de base de datos reservada en Amazon RDS, adquiere un compromiso
para obtener una tarifa con descuento en un tipo de instancia de base de datos específico durante el
periodo de duración de la instancia de base de datos reservada. Para usar una instancia de base de
datos reservada de Amazon RDS, debe crear una instancia de base de datos nueva, tal como haría para
una instancia bajo demanda. La instancia de base de datos nueva que cree deberá tener las mismas
especificaciones que la instancia de base de datos reservada. Si las especificaciones de la nueva instancia
de base de datos nueva coinciden con una instancia reservada existente para su cuenta, se le facturará
con la tarifa con descuento ofrecida para la instancia reservada. De lo contrario, la instancia de base de
datos se factura con una tarifa bajo demanda.
Para obtener más información acerca de las instancias de base de datos reservadas, incluidos los precios,
consulte Instancias reservadas de Amazon RDS.
Tipos de ofertas
Las instancias de base de datos reservadas están disponibles en tres variedades (sin pago inicial, pago
inicial parcial y pago inicial total), lo cual le permite optimizar sus costos de Amazon RDS en función del
uso previsto.
Sin pago inicial
Esta opción proporciona acceso a una instancia de base de datos reservada sin que haya que hacer
un pago inicial. Su instancia de base de datos reservada sin pago inicial le cobra una tarifa por hora

73
con descuento por cada hora dentro del plazo, independientemente del uso. No es necesario realizar
ningún pago inicial. Esta opción solo está disponible en la modalidad de reserva de un año.
Pago inicial parcial
Esta opción exige que parte de la instancia de base de datos reservada se pague por adelantado. Las
horas restantes del plazo se cobran a una tarifa por hora con descuento, independientemente del uso
que haga. Esta opción sustituye la anterior opción de utilización intensa.
Pago inicial total
Se realiza un pago total al comienzo del plazo, y no se aplicará ningún otro costo el resto del plazo,
independientemente del número de horas de uso.
Si está utilizando la facturación unificada, todas las cuentas de la organización se tratan como una sola.
Esto quiere decir que todas las cuentas de la organización pueden beneficiarse del precio por hora
reducido de las instancias de base de datos reservadas adquiridas por otra cuenta. Para obtener más
información sobre la facturación unificada, consulte Instancias de base de datos reservadas de Amazon
RDS en la Guía del usuario de Administración de costos y facturación de AWS.
Flexibilidad del tamaño de las instancias de base de datos reservadas

Al comprar una instancia de base de datos reservada, una de las cosas que especifica es la clase de
instancia, por ejemplo, db.m4.large. Para obtener más información sobre las clases de instancias, consulte
Selección de la clase de instancia de base de datos (p. 61).
Si tiene una instancia de base de datos y debe escalarla para aumentar la capacidad, la instancia de base
de datos reservada se aplica automáticamente a la instancia de base de datos escalada. Es decir que las
instancias de base de datos reservadas se aplican automáticamente entre todos los tamaños de clase de
instancia de base de datos. Las instancias de base de datos reservadas con flexibilidad de tamaño están
disponibles para las instancias de base de datos de la misma región de AWS y motor de base de datos.
Las instancias de base de datos reservadas con flexibilidad de tamaño solo se pueden escalar en su tipo
de clase de instancia. Por ejemplo, una instancia de base de datos reservada para una db.m4.large se
puede aplicar a una db.m4.xlarge, pero no a una db.m5.large, porque db.m4 y db.m5 son tipo de clases de
instancia diferentes. Otro de los beneficios de las instancias de base de datos reservadas es que también
se aplican a las configuraciones Multi-AZ y Single-AZ.
Puede comparar el uso de diferentes tamaños de instancias de base de datos reservadas utilizando
unidades normalizadas. Por ejemplo, una unidad de uso en dos instancias de base de datos db.m3.large
equivale a ocho unidades de uso normalizadas en una db.m3.small. En la tabla siguiente se muestra el
número de unidades normalizadas por cada tamaño de instancia de base de datos.
Tamaño de instancia Unidades normalizadas de Unidades normalizadas de Multi-

Single-AZ AZ
micro 0,5 1
small 1 2
medium 2 4
large 4 8
xlarge 8 16
2xlarge 16 32
4xlarge 32 64
8xlarge 64 128

74
Tamaño de instancia Unidades normalizadas de Unidades normalizadas de Multi-

Single-AZ AZ
10xlarge 80 160
16xlarge 128 256
Por ejemplo, suponga que adquiere una instancia de base de datos reservada db.t2.medium y tiene dos
instancias de base de datos db.t2.small en ejecución en su cuenta en la misma región de AWS. En
este caso, el beneficio de facturación se aplica en su totalidad a las dos instancias.
De forma alternativa, si tiene una instancia db.t2.large en ejecución en su cuenta en la misma región
de AWS, el beneficio de facturación se aplica al 50 % del uso de la instancia de base de datos.
Ejemplo de facturación de una instancia de base de datos reservada

El precio de una instancia de base de datos reservada no incluye los costos habituales asociados con
el almacenamiento, las copias de seguridad y las E/S. En el siguiente ejemplo se ilustra el costo total
mensual de una instancia de base de datos reservada:
• Una clase de instancia de base de datos reservada db.r4.large Single-AZ de Aurora MySQL en EE.UU.
Este (Norte de Virginia) con un costo de 0,19 USD por hora o de 138,70 USD al mes

75
• Almacenamiento de Aurora con un costo de 0,10 USD por GiB al mes (asuma 45,60 USD al mes para
este ejemplo)
• E/S de Aurora con un costo de 0,20 USD por 1 millón de solicitudes (asuma 20 USD al mes para este
ejemplo)
• Almacenamiento de copia de seguridad de Aurora con un costo de 0,021 USD por GiB al mes (asuma
30 USD al mes para este ejemplo)
Sume todas estas opciones (138,70 USD + 45,60 USD + 20 USD + 30 USD) a la instancia de base de
datos reservada y el costo total mensual es de 234.30 USD.
Si decide utilizar una instancia de base de datos bajo demanda en lugar de una instancia de base de datos
reservada, una clase de instancia de base de datos reservada db.r4.large Single-AZ de Aurora MySQL en
EE.UU. Este (Norte de Virginia) cuesta 0,29 USD por hora 217,50 USD al mes. Así que para una instancia
de base de datos bajo demanda, sume todas estas opciones (217,50 USD + 45,60 USD + 20 USD +
30 USD) y el costo total mensual es de 313,10 USD.
Note
Los precios de este ejemplo son precios de ejemplo y podrían no coincidir con los precios reales.
Para obtener información acerca de los precios de Aurora, consulte la página de precios de
Aurora.
Eliminación de una instancia de base de datos reservada

Los términos de una instancia de base de datos reservada implican un compromiso de un año o de tres
años. No tiene autorización para cancelar una instancia de base de datos reservada. Sin embargo, puede
eliminar una instancia de base de datos que tenga un descuento de instancia de base de datos reservada.
El proceso para eliminar una instancia de base de datos con un descuento de instancia de base de datos
reservada es el mismo que para cualquier otra instancia de base de datos.
Su pago inicial de una instancia de base de datos reservada reserva los recursos para que los utilice. Dado
que estos recursos están reservados para usted, se le cobra por los recursos, tanto si los usa como si no.
Si elimina una instancia de base de datos con un descuento de instancia de base de datos reservada,
puede lanzar otra instancia de base de datos con especificaciones compatibles. En este caso, sigue
disfrutando de la tarifa de descuento mientras dure la reserva (de uno o tres años).
Consola
Puede utilizar la Consola de administración de AWS para trabajar con instancias de base de datos
reservadas, tal como se muestra en los siguientes procedimientos.
Para obtener precios e información sobre ofertas de instancias de base de datos reservadas
disponibles
2. En el panel de navegación, elija Reserved instances (Instancias reservadas).
3. Elija Purchase Reserved DB Instance.
4. En Product description (Descripción de producto), elija el motor de base de datos y el tipo de licencia.
5. En DB instance class (Clase de instancia de base de datos), elija la clase de instancia de base de
datos.
6. En Multi-AZ deployment (Implementación Multi-AZ), elija si quiere o no un despliegue Multi-AZ.

76
Note
Las instancias reservadas de Amazon Aurora siempre tienen la opción Multi-AZ deployment
(Implementación Multi-AZ) establecida en No. Si crea un clúster de base de datos Amazon
Aurora a partir de su instancia de base de datos reservada, el clúster de base de datos se
crea automáticamente como Multi-AZ.
7. En Term, elija el tiempo durante el cual desea que se reserve la instancia de base de datos.
8. En Offering type (Tipo de oferta), elija el tipo de oferta.
Después de seleccionar el tipo de oferta, podrá ver la información sobre los precios.
Important
Elija Cancel (Cancelar) para evitar comprar la instancia de base de datos reservada y generar
cargos.
Después de recibir la información sobre las ofertas disponibles de instancias de base de datos reservadas,
podrá utilizar dicha información para adquirir una oferta, tal como se explica a continuación.
Para comprar una instancia de base de datos reservada
2. En el panel de navegación, elija Reserved instances (Instancias reservadas).
3. Elija Purchase Reserved DB Instance.
4. En Product description (Descripción de producto), elija el motor de base de datos y el tipo de licencia.
5. En DB instance class (Clase de instancia de base de datos), elija la clase de instancia de base de
datos.
6. En Multi-AZ deployment (Implementación Multi-AZ), elija si quiere o no un despliegue Multi-AZ.
Note
Las instancias reservadas de Amazon Aurora siempre tienen la opción Multi-AZ deployment
(Implementación Multi-AZ) establecida en No. Si crea un clúster de base de datos Amazon
Aurora a partir de su instancia de base de datos reservada, el clúster de base de datos se
crea automáticamente como Multi-AZ.
7. En Term, elija el tiempo durante el cual desea que se reserve la instancia de base de datos.
8. En Offering type (Tipo de oferta), elija el tipo de oferta.
Después de elegir el tipo de oferta, podrá ver la información sobre los precios, tal como se muestra a
continuación.

77

78
9. (Opcional) Puede asignar su propio identificador a las instancias de base de datos reservadas que
adquiera para poder realizar un seguimiento de estas. En Reserved Id, escriba un identificador para la
instancia de base de datos reservada.
10. Elija Continue.
Aparece el cuadro de diálogo Purchase Reserved DB Instance, que muestra un resumen de los
atributos de la instancia de base de datos reservada que ha seleccionado y el pago adeudado, como
en la captura que sigue.

79
11. En la página de confirmación, revise la instancia de base de datos reservada. Si la información es

correcta, elija Purchase para adquirir la instancia de base de datos reservada.
De forma alternativa, elija Back para editar la instancia de base de datos reservada.

80
Después de adquirir las instancias de base de datos reservadas, podrá obtener información sobre las
instancias de base de datos reservadas, tal como se muestra a continuación.
Para obtener información sobre instancias de base de datos reservadas para su cuenta de AWS
2. En el panel Navigation (Navegación), elija Reserved instances (Instancias reservadas).
Aparecerán las instancias de base de datos reservadas de la cuenta. Para ver información detallada
sobre la instancia de base de datos reservada particular, elija dicha instancia de la lista. Entonces,
podrá ver información detallada sobre esa instancia en el panel de detalles ubicado en la parte inferior
de la consola.
AWS CLI
Puede utilizar la AWS CLI para trabajar con instancias de base de datos reservadas, tal como se muestra
en los siguientes ejemplos.
Example Obtener ofertas disponibles de instancias de base de datos reservadas

Para obtener información sobre las ofertas disponibles de instancias de base de datos reservadas, llame al
comando describe-reserved-db-instances-offerings de la AWS CLI.
aws rds describe-reserved-db-instances-offerings
Esta llamada devuelve un resultado similar al siguiente:
OFFERING OfferingId Class Multi-AZ Duration Fixed

Price Usage Price Description Offering Type
OFFERING 438012d3-4052-4cc7-b2e3-8d3372e0e706 db.m1.large y 1y 1820.00
USD 0.368 USD mysql Partial Upfront
OFFERING 649fd0c8-cf6d-47a0-bfa6-060f8e75e95f db.m1.small n 1y 227.50
USD 0.046 USD mysql Partial Upfront
OFFERING 123456cd-ab1c-47a0-bfa6-12345667232f db.m1.small n 1y 162.00
USD 0.00 USD mysql All Upfront
Recurring Charges: Amount Currency Frequency
Recurring Charges: 0.123 USD Hourly
OFFERING 123456cd-ab1c-37a0-bfa6-12345667232d db.m1.large y 1y 700.00
USD 0.00 USD mysql All Upfront
Recurring Charges: Amount Currency Frequency
Recurring Charges: 1.25 USD Hourly
OFFERING 123456cd-ab1c-17d0-bfa6-12345667234e db.m1.xlarge n 1y 4242.00
USD 2.42 USD mysql No Upfront
podrá utilizar dicha información para adquirir una oferta, tal como se muestra en el siguiente ejemplo.
Example Comprar una instancia de base de datos reservada

Para adquirir una instancia de base de datos reservada, use el comando purchase-reserved-db-
instances-offering de la AWS CLI con los siguientes parámetros:
• --reserved-db-instances-offering-id: es el ID de la oferta que quiere adquirir. Consulte el

ejemplo anterior para obtener el ID de la oferta.
• --reserved-db-instance-id: puede asignar su propio identificador a las instancias de base de
datos reservadas que adquiera para poder realizar un seguimiento de estas.

81
El siguiente ejemplo adquiere la oferta de instancia de base de datos reservada con el ID 649fd0c8-
cf6d-47a0-bfa6-060f8e75e95f y le asigna el identificador MyReservation.
aws rds purchase-reserved-db-instances-offering \

--reserved-db-instances-offering-id 649fd0c8-cf6d-47a0-bfa6-060f8e75e95f \
--reserved-db-instance-id MyReservation
Para Windows:
aws rds purchase-reserved-db-instances-offering ^

--reserved-db-instances-offering-id 649fd0c8-cf6d-47a0-bfa6-060f8e75e95f ^
--reserved-db-instance-id MyReservation
El comando devuelve un resultado similar al siguiente:
RESERVATION ReservationId Class Multi-AZ Start Time Duration

Fixed Price Usage Price Count State Description Offering Type
RESERVATION MyReservation db.m1.small y 2011-12-19T00:30:23.247Z 1y
455.00 USD 0.092 USD 1 payment-pending mysql Partial Upfront
instancias de base de datos reservadas, tal como se muestra en el siguiente ejemplo.
Example Obtener las instancias de base de datos reservadas
Para obtener información sobre instancias de base de datos reservadas para su cuenta de AWS, llame al
comando describe-reserved-db-instances de la AWS CLI.
aws rds describe-reserved-db-instances
El comando devuelve un resultado similar al siguiente:
RESERVATION ReservationId Class Multi-AZ Start Time Duration

Fixed Price Usage Price Count State Description Offering Type
RESERVATION MyReservation db.m1.small y 2011-12-09T23:37:44.720Z 1y
455.00 USD 0.092 USD 1 retired mysql Partial Upfront
API de RDS
Puede utilizar la API de RDS para trabajar con instancias de base de datos reservadas, tal como se
muestra en los siguientes ejemplos.
Example Obtener ofertas disponibles de instancias de base de datos reservadas
Para obtener información sobre ofertas de instancias de base de datos reservadas disponibles, llame a la
función DescribeReservedDBInstancesOfferings de la API de Amazon RDS.
https://rds.us-east-1.amazonaws.com/
?Action=DescribeReservedDBInstancesOfferings
&SignatureMethod=HmacSHA256
&SignatureVersion=4
&Version=2014-09-01
&X-Amz-Algorithm=AWS4-HMAC-SHA256

82
&X-Amz-Credential=AKIADQKE4SARGYLE/20140411/us-east-1/rds/aws4_request
&X-Amz-Date=20140411T203327Z
&X-Amz-SignedHeaders=content-type;host;user-agent;x-amz-content-sha256;x-amz-date
&X-Amz-Signature=545f04acffeb4b80d2e778526b1c9da79d0b3097151c24f28e83e851d65422e2
<DescribeReservedDBInstancesOfferingsResponse xmlns="http://rds.amazonaws.com/
doc/2014-10-31/">
<DescribeReservedDBInstancesOfferingsResult>
<ReservedDBInstancesOfferings>
<ReservedDBInstancesOffering>
<Duration>31536000</Duration>
<OfferingType>Partial Upfront</OfferingType>
<CurrencyCode>USD</CurrencyCode>
<RecurringCharges/>
<FixedPrice>1820.0</FixedPrice>
<ProductDescription>mysql</ProductDescription>
<UsagePrice>0.368</UsagePrice>
<MultiAZ>true</MultiAZ>
<ReservedDBInstancesOfferingId>438012d3-4052-4cc7-b2e3-8d3372e0e706</
ReservedDBInstancesOfferingId>
<DBInstanceClass>db.m1.large</DBInstanceClass>
</ReservedDBInstancesOffering>
<ReservedDBInstancesOffering>
<RecurringCharges/>
<MultiAZ>false</MultiAZ>
<ReservedDBInstancesOfferingId>649fd0c8-cf6d-47a0-bfa6-060f8e75e95f</
<DBInstanceClass>db.m1.small</DBInstanceClass>
</ReservedDBInstancesOffering>
</ReservedDBInstancesOfferings>
</DescribeReservedDBInstancesOfferingsResult>
<ResponseMetadata>
<RequestId>5e4ec40b-2978-11e1-9e6d-771388d6ed6b</RequestId>
</ResponseMetadata>
</DescribeReservedDBInstancesOfferingsResponse>
podrá utilizar dicha información para adquirir una oferta, tal como se muestra en el siguiente ejemplo.
Example Comprar una instancia de base de datos reservada

Para adquirir una instancia de base de datos reservada, llame a la acción
PurchaseReservedDBInstancesOffering de la API de Amazon RDS con los siguientes parámetros:
• --reserved-db-instances-offering-id: es el ID de la oferta que quiere adquirir. Consulte el

ejemplo anterior para obtener el ID de la oferta.
• --reserved-db-instance-id: puede asignar su propio identificador a las instancias de base de
datos reservadas que adquiera para poder realizar un seguimiento de estas.
El siguiente ejemplo adquiere la oferta de instancia de base de datos reservada con el ID 649fd0c8-
cf6d-47a0-bfa6-060f8e75e95f y le asigna el identificador MyReservation.

83
?Action=PurchaseReservedDBInstancesOffering
&ReservedDBInstanceId=MyReservation
&ReservedDBInstancesOfferingId=438012d3-4052-4cc7-b2e3-8d3372e0e706
&DBInstanceCount=10
&SignatureVersion=4
&Version=2014-09-01
&X-Amz-Date=20140415T232655Z
&X-Amz-Signature=c2ac761e8c8f54a8c0727f5a87ad0a766fbb0024510b9aa34ea6d1f7df52fb11
<PurchaseReservedDBInstancesOfferingResponse xmlns="http://rds.amazonaws.com/
doc/2014-10-31/">
<PurchaseReservedDBInstancesOfferingResult>
<ReservedDBInstance>
<RecurringCharges/>
<MultiAZ>true</MultiAZ>
<State>payment-pending</State>
<ReservedDBInstanceId>MyReservation</ReservedDBInstanceId>
<DBInstanceCount>10</DBInstanceCount>
<StartTime>2011-12-18T23:24:56.577Z</StartTime>
</ReservedDBInstance>
</PurchaseReservedDBInstancesOfferingResult>
<ResponseMetadata>
<RequestId>7f099901-29cf-11e1-bd06-6fe008f046c3</RequestId>
</ResponseMetadata>
</PurchaseReservedDBInstancesOfferingResponse>
instancias de base de datos reservadas, tal como se muestra en el siguiente ejemplo.
Example Obtener las instancias de base de datos reservadas
Para obtener información sobre instancias de base de datos reservadas para su cuenta de AWS, llame a la
acción DescribeReservedDBInstances de la API de Amazon RDS.
https://rds.us-west-2.amazonaws.com/
?Action=DescribeReservedDBInstances
&SignatureVersion=4
&Version=2014-09-01
&X-Amz-Credential=AKIADQKE4SARGYLE/20140420/us-west-2/rds/aws4_request
&X-Amz-Date=20140420T162211Z
&X-Amz-Signature=3312d17a4c43bcd209bc22a0778dd23e73f8434254abbd7ac53b89ade3dae88e
La API devuelve un resultado similar al siguiente:

84
Creación de un clúster de base de datos
<DescribeReservedDBInstancesResponse xmlns="http://rds.amazonaws.com/doc/2014-10-31/">
<DescribeReservedDBInstancesResult>
<ReservedDBInstances>
<RecurringCharges/>
<State>payment-failed</State>
<RecurringCharges/>
<State>payment-failed</State>
</ReservedDBInstances>
</DescribeReservedDBInstancesResult>
<ResponseMetadata>
<RequestId>23400d50-2978-11e1-9e6d-771388d6ed6b</RequestId>
</ResponseMetadata>
</DescribeReservedDBInstancesResponse>
Creación de un clúster de base de datos de

Amazon Aurora
Un clúster de base de datos Amazon Aurora se compone de una instancia de base de datos compatible
con MySQL o PostgreSQL y de un volumen de clúster que representa los datos del clúster de base de
datos, copiado en tres zonas de disponibilidad como un único volumen virtual. El clúster de base de
datos contiene una instancia de base de datos de escritor y, opcionalmente, hasta 15 réplicas de Aurora
(instancias de base de datos de lector). Para obtener más información acerca de los clústeres de base de
datos Aurora, consulte Clústeres de base de datos Amazon Aurora (p. 2).
En este tema se describe cómo puede crear un clúster de base de datos de Aurora. Para comenzar,
primero vea Requisitos previos de clúster de base de datos (p. 86).
Para obtener instrucciones sencillas para conectarse al clúster de base de datos Aurora, consulte
Conexión a un clúster de base de datos Amazon Aurora (p. 148).

85
Requisitos previos
Requisitos previos de clúster de base de datos

Important
Debe completar las tareas de la sección Configuración del entorno para Amazon Aurora (p. 50)
para poder crear un clúster de base de datos Aurora.
A continuación se describen los requisitos previos para crear un clúster de base de datos.
VPC
Solo es posible crear un clúster de base de datos Amazon Aurora en una Virtual Private Cloud (VPC),
en una región de AWS que tenga al menos dos zonas de disponibilidad. El grupo de subred de base de
datos que elija para el clúster de base de datos debe abarcar al menos dos zonas de disponibilidad. Esta
configuración garantiza que su clúster de base de datos siempre tenga al menos una instancia de base de
datos disponible ante una conmutación por error, en el caso improbable de que se produzca un error en
una zona de disponibilidad.
Si usa la Consola de administración de AWS para crear un clúster de base de datos Aurora, puede hacer
que Amazon RDS cree automáticamente una VPC. Como alternativa, puede usar una VPC ya existente o
crear una nueva VPC para su clúster de base de datos de Aurora. La VPC debe tener como mínimo una
subred en al menos dos de las zonas de disponibilidad para que la use con un clúster de base de datos
Amazon Aurora. Para obtener más información, consulte Cómo crear una VPC para el uso con Amazon
Aurora (p. 211). Para obtener información acerca de las VPC, consulte VPC Amazon Virtual Private
Cloud y Amazon Aurora (p. 211).
Note
Puede comunicarse con una instancia EC2 que no esté en una VPC y con un clúster de base de
datos de Amazon Aurora usando ClassicLink. Para obtener más información, consulte Acceso a
una instancia de base de datos situada en una VPC desde una instancia EC2 que no está en una
VPC (p. 220).
Si no tiene una VPC predeterminada o no ha creado una VPC, puede hacer que Amazon RDS cree
automáticamente una VPC cuando se cree un clúster de base de datos Aurora usando la Consola de
administración de AWS. De lo contrario, tendrá que hacer lo siguiente:
• Cree una VPC que tenga como mínimo una subred en al menos dos de las zonas de disponibilidad de la
región de AWS en la que desea implementar su clúster de base de datos. Para obtener más información,
consulte Cómo crear una VPC para el uso con Amazon Aurora (p. 211).
• Especifique un grupo de seguridad de VPC que autorice las conexiones con su clúster de base de
datos de Aurora. Para obtener más información, consulte Uso de una instancia de base de datos en una
VPC (p. 222).
• Especifique un grupo de subredes de base de datos de RDS que defina al menos dos subredes de la
VPC que pueda usar el clúster de base de datos de Aurora. Para obtener más información, consulte Uso
de los grupos de subredes de base de datos (p. 223).
Requisitos previos adicionales

• Si se conecta a AWS con credenciales de IAM, la cuenta de IAM debe tener políticas de IAM que
otorguen los permisos necesarios para realizar operaciones de Amazon RDS. Para obtener más
información, consulte Administración de identidad y acceso en Amazon Aurora (p. 163).
consola de Amazon RDS en https://console.aws.amazon.com/rds/.

86
• Si desea adaptar los parámetros de configuración para su clúster de base de datos, debe especificar
un grupo de parámetros de clúster de base de datos y un grupo de parámetros de base de datos con la
configuración de parámetros requerida. Para obtener información acerca de cómo crear o modificar un
grupo de parámetros de clúster de base de datos o un grupo de parámetros de base de datos, consulte
Trabajo con los grupos de parámetros de base de datos y grupos de parámetros de clúster de base de
datos (p. 259).
• Debe determinar el número de puerto de TCP/IP que especificará para el clúster de base de datos.
Los firewalls de algunas compañías bloquean las conexiones a los puertos predeterminados (3306
para MySQL, 5432 para PostgreSQL) de Aurora. Si el firewall de su compañía bloquea el puerto
predeterminado, elija otro puerto para el clúster de base de datos. Todas las instancias de un clúster de
base de datos usan el mismo puerto.

Puede crear un clúster de base de datos Aurora usando la Consola de administración de AWS, la AWS CLI
o la API de RDS.
Consola
Para crear un clúster de base de datos Aurora mediante la Consola de administración de AWS
2. En la esquina superior derecha de la Consola de administración de AWS, seleccione la región de AWS
en la que desea crear el clúster de base de datos Aurora.
Si el panel de navegación está cerrado, elija el icono de menú en la parte superior izquierda para
abrirlo.
4. Elija Create database (Crear base de datos) para abrir la página Select engine (Seleccionar motor).
5. En la página Select engine (Seleccionar motor), elija una edición de Aurora. Elija una edición
compatible con MySQL 5.6, con MySQL 5.7 o con PostgreSQL.

87
6. Seleccione Next (Siguiente).

7. En la página Specify DB Details (Especificar detalles de base de datos), especifique la información de
la instancia de base de datos. La siguiente tabla muestra la configuración de una instancia de base de
datos.
Para esta opción Haga lo siguiente
Capacity type (Tipo de capacidad) Elija Provisioned (Aprovisionado) para administrar

manualmente la capacidad de la instancia de base de
datos. Es posible que tenga que cambiar la clase de la
instancia de base de datos si cambia la carga de trabajo.
Elija Serverless (Sin servidor) para que Aurora administre

automáticamente la capacidad disponible para la instancia
de base de datos. Para obtener más información, consulte
Uso de Amazon Aurora Serverless (p. 100).

88
DB engine version (Versión del motor Solo se aplica al tipo de capacidad aprovisionada. Elija el
de base de datos) número de versión del motor de base de datos.
DB instance class Solo se aplica al tipo de capacidad aprovisionada. Elija

una clase de instancia de base de datos que defina
los requisitos de procesamiento y memoria para cada
instancia en el clúster de base de datos. Para obtener más
información acerca de las clases de instancias de bases de
datos, consulte Selección de la clase de instancia de base
de datos (p. 61).
Multi-AZ Deployment (Implementación Solo se aplica al tipo de capacidad aprovisionada.

Multi-AZ) Determine si desea crear réplicas de Aurora en otras zonas
de disponibilidad para permitir la conmutación por error.
Si selecciona Create Replica in Different Zone (Crear
réplica en otra zona), Amazon RDS crea una réplica de
Aurora en su clúster de base de datos en una zona de
disponibilidad diferente de la zona de disponibilidad de
la instancia principal del clúster de base de datos. Para
obtener más información acerca del uso de varias zonas
de disponibilidad, consulte Elección de Regiones y zonas
de disponibilidad (p. 64).
DB instance identifier (Identificador de Escriba un nombre para la instancia principal de su

instancias de bases de datos) clúster de base de datos. Este identificador se utiliza en la
dirección del punto de enlace de la instancia principal de su
clúster de base de datos.
El identificador de instancias de bases de datos tiene las

siguientes limitaciones:
• Debe contener de 1 a 63 caracteres alfanuméricos o

guiones.
• El primer carácter debe ser una letra.
• No puede terminar con un guion ni contener dos guiones
consecutivos.
• Debe ser único para todas las instancias de base de
datos por cada cuenta de AWS y por región de AWS.
Master username Escriba un nombre con caracteres alfanuméricos para

utilizarlo como nombre de usuario maestro para iniciar
sesión en su clúster de base de datos.
Contraseña maestra Escriba una contraseña que contenga entre 8 y 41

caracteres ASCII imprimibles (excepto /, " y @) para su
contraseña de usuario maestro.
Una página Specify DB details (Especificar detalles de la base de datos) típica tiene un aspecto similar
al siguiente.

89
8. Confirme su contraseña maestra y, a continuación, elija Next (Siguiente).

9. En la página Configure Advanced Settings (Configurar ajustes avanzados), puede personalizar la
configuración adicional para su clúster de base de datos de Aurora. La siguiente tabla muestra la
configuración avanzada de un clúster de base de datos.
Para esta opción... Haga lo siguiente
Virtual Private Cloud (VPC) Seleccione la VPC que alojará el clúster de base de datos.
Seleccione Create a New VPC (Crear una nueva VPC)

90

para que Amazon RDS cree una VPC. Para obtener más
información, consulte la sección Requisitos previos de
clúster de base de datos (p. 86) que se ha expuesto
anteriormente en este tema.
Subnet group (Grupo de subredes) Seleccione el grupo de subredes de base de datos que
desea utilizar para el clúster de base de datos. Para
obtener más información, consulte la sección Requisitos
previos de clúster de base de datos (p. 86) que se ha
expuesto anteriormente en este tema.
Public accessibility (Accesibilidad Seleccione Yes para asignar al clúster de base de datos
pública) una dirección IP pública; de lo contrario, seleccione No.
Las instancias del clúster de base de datos pueden ser
una combinación de instancias de base de datos públicas
y privadas. Para obtener más información acerca del modo
de ocultar instancias al acceso público, consulte Cómo
ocultar una instancia de base de datos en una VPC desde
Internet. (p. 223).
Availability zone Determine si desea especificar una zona de disponibilidad

concreta. Para obtener más información acerca de las
zonas de disponibilidad, consulte Elección de Regiones y
zonas de disponibilidad (p. 64).
VPC security groups Seleccione Create new VPC security group (Crear nuevo
grupo de seguridad de VPC) para que Amazon RDS
cree un grupo de seguridad de VPC. O seleccione Select
existing VPC security groups (Seleccionar grupos de
seguridad de VPC existentes) y especifique uno o varios
grupos de seguridad de VPC para proteger el acceso de
red al clúster de base de datos.
Al seleccionar Create new VPC security group (Crear

nuevo grupo de seguridad de VPC) en la consola de RDS,
se crea un nuevo grupo de seguridad con una regla de
entrada que permite el acceso a la instancia de base de
datos desde la dirección IP detectada en su navegador.
Para obtener más información, consulte la sección

Requisitos previos de clúster de base de datos (p. 86)
que se ha expuesto anteriormente en este tema.

91
DB Cluster Identifier (Identificador de Escriba un nombre para el clúster de base de datos que
clúster de base de datos) sea exclusivo para su cuenta en la región de AWS que
haya seleccionado. Este identificador se utilizará en la
dirección del punto de enlace del clúster para su clúster
de base de datos. Para obtener información acerca del
punto de enlace del clúster, consulte Administración de
conexiones de Amazon Aurora (p. 3).
El identificador del clúster de base de datos tiene las


guiones.
consecutivos.
• Debe ser único para todos los clústeres de base de
datos por cuenta de AWS y región de AWS.
Nombre de base de datos Escriba un nombre de hasta 64 caracteres alfanuméricos

para la base de datos predeterminada. Si no proporciona
un nombre, Amazon RDS no creará una base de datos en
el clúster de base de datos que está creando.
Para crear otras bases de datos, conéctese al clúster

de base de datos y use el comando SQL CREATE
DATABASE. Para obtener más información acerca de la
conexión al clúster de base de datos, consulte Conexión a
un clúster de base de datos Amazon Aurora (p. 148).
Puerto Especifique el puerto que deben usar las aplicaciones y

las utilidades para obtener acceso a la base de datos. Los
clústeres de base de datos Aurora MySQL usan de forma
predeterminada el puerto MySQL, 3306 y los clústeres
de base de datos Aurora PostgreSQL usan de forma
predeterminada el puerto PostgreSQL, 5432. Los firewalls
de algunas compañías bloquean las conexiones a estos
puertos predeterminados. Si el firewall de su compañía
bloquea el puerto predeterminado, elija otro puerto para el
nuevo clúster de base de datos.
DB Parameter Group (Grupo de Seleccione un grupo de parámetros. Aurora cuenta con

parámetros de base de datos) un grupo de parámetros predeterminado que puede
utilizar. Si lo prefiere, puede crear su propio grupo de
parámetros. Para obtener más información acerca de los
grupos de parámetros, consulte Trabajo con los grupos de
parámetros de base de datos y grupos de parámetros de
clúster de base de datos (p. 259).

92
DB cluster parameter group (Grupo Seleccione un grupo de parámetros de clúster de base

de parámetros de clúster de base de de datos. Aurora cuenta con un grupo de parámetros
datos) de clúster de base de datos predeterminado que puede
parámetros de clúster de base de datos. Para obtener
más información acerca de los grupos de parámetros de
clúster de base de datos, consulte Trabajo con los grupos
de parámetros de base de datos y grupos de parámetros
de clúster de base de datos (p. 259).
Option group (Grupo de opciones) Aurora tiene un grupo de opciones predeterminado.
IAM DB authentication Seleccione Enable IAM DB authentication (Habilitar la

autenticación de base de datos IAM) para habilitar la
autenticación de base de datos IAM. Para obtener más
información, consulte Autenticación de bases de datos de
IAM (p. 180).
Encryption (Cifrado) Seleccione Enable encryption para habilitar el cifrado

en reposo para este clúster de base de datos. Para obtener
más información, consulte Cifrado de recursos de Amazon
Aurora (p. 158).
Clave maestra Solo está disponible si Encryption (Cifrado) se establece en

Enable encryption (Habilitar cifrado). Seleccione la clave
maestra que se va a usar para el cifrado de este clúster
Cifrado de recursos de Amazon Aurora (p. 158).
Prioridad Elija una prioridad de conmutación por error para

la instancia. Si no selecciona un valor, el ajuste
predeterminado es tier-1. Esta prioridad determina el
orden en que se promueven las réplicas de Aurora
cuando el sistema se recupera de un error en la instancia
principal. Para obtener más información, consulte
Tolerancia a errores para un clúster de base de datos de
Aurora (p. 314).
Backup retention period Seleccione el tiempo (entre 1 y 35 días) durante el

que Aurora conservará las copias de backup de la
base de datos. Los backups se pueden utilizar para las
restauraciones a un momento dado (PITR) de la base de
datos con una precisión de segundos.
Copy Tags To Snapshots (Copiar Selecciónelo para especificar qué etiquetas definidas
etiquetas en instantáneas) para este clúster de base de datos se copian en las
instantáneas de base de datos creadas desde este clúster
Etiquetado de recursos de Amazon RDS (p. 349).

93
Backtrack Se aplica solo a Aurora MySQL. Seleccione Enable

Backtrack (Habilitar Backtrack) para habilitar la búsqueda
de datos anteriores o Disable Backtrack (Deshabilitar
Backtrack) para deshabilitarla. Utilizando la búsqueda
de datos anteriores puede rebobinar un clúster de
base de datos a un momento específico, sin crear un
nuevo clúster de base de datos. Está deshabilitado de
forma predeterminada. Si habilita la búsqueda de datos
anteriores, especifique también la cantidad de tiempo que
desea poder realizar la búsqueda de datos anteriores en su
clúster de base de datos (la ventana de búsqueda de datos
anteriores de destino). Para obtener más información,
consulte Búsqueda de datos anteriores de un clúster de
base de datos de Aurora (p. 546).
Enhanced Monitoring (Monitorización Elija Enable enhanced monitoring (Habilitar monitorización

mejorada) mejorada) a fin de habilitar la recopilación de métricas en
tiempo real para el sistema operativo en el que se ejecuta
su clúster de base de datos. Para obtener más información,
consulte Monitorización mejorada (p. 395).
Monitoring Role Solo está disponible si Enhanced Monitoring

(Monitorización mejorada) se establece en Enable
enhanced monitoring (Habilitar monitorización mejorada).
Elija la función de IAM que ha creado para permitir que
Amazon RDS se comunique con Amazon CloudWatch
Logs, o bien elija Default (Predeterminado) para que
RDS cree un rol denominado rds-monitoring-role.
Para obtener más información, consulte Monitorización
mejorada (p. 395).
Granularity (Grado de detalle) Solo está disponible si Enhanced Monitoring

Defina el intervalo, en segundos, en el que se recopilan las
métricas para el clúster de base de datos.
Performance Insights Esto no se aplica a MySQL 5.6. Seleccione Enable

Performance Insights (Habilitar Performance Insights)
si desea utilizar Amazon RDS Performance Insights
para supervisar su carga de clúster de base de datos de
Amazon Aurora. Para obtener más información acerca
de Performance Insights, consulte Uso de Performance
Insights de Amazon RDS (p. 402).
Período de retención Esto no se aplica a MySQL 5.6. Elija el tiempo durante el

que se conservan los datos de Performance Insights.
Clave maestra Esto no se aplica a MySQL 5.6. Especifique su clave de

AWS Key Management Service (AWS KMS). Performance
Insights cifra todos los datos potencialmente confidenciales
con su propia clave de AWS KMS. Para obtener más
información, consulte Cifrado de recursos de Amazon
Aurora (p. 158).

94
Selección de los tipos de registro que Se aplica solo a Aurora MySQL. En la sección Logs
publicar en Amazon CloudWatch Logs exports (Exportaciones de registros), elija los registros
que desea comenzar a publicar en Amazon CloudWatch
Logs. Para obtener más información sobre la publicación
en CloudWatch Logs, consulte Publicación de registros
de Amazon Aurora MySQL en Amazon CloudWatch
Logs (p. 662).
Auto minor version upgrade Seleccione Enable auto minor version upgrade (Habilitar
(Actualización automática de actualización automática de versiones secundarias) si
versiones secundarias) desea habilitar su clúster de base de datos Aurora para
recibir actualizaciones de las versiones secundarias
preferidas del motor de base de datos automáticamente
cuando estén disponibles.
El ajuste Auto minor version upgrade (Actualización

automática a versiones secundarias) solo se aplica a los
clústeres de base de datos Aurora PostgreSQL.
Para obtener más información acerca de las

actualizaciones de motor de Aurora PostgreSQL, consulte
Actualizaciones del motor de base de datos para Amazon
Aurora PostgreSQL (p. 856).

actualizaciones de motor de Aurora MySQL, consulte
Maintenance window (Periodo de Seleccione Select window (Seleccionar periodo) y

mantenimiento) especifique el intervalo de tiempo semanal durante el
que se puede llevar a cabo el mantenimiento del sistema.
O, seleccione No preference (Sin preferencia) para que
Amazon RDS asigne un período aleatoriamente.
Enable deletion protection (Habilitar la Seleccione Enable deletion protection (Habilitar la

protección contra la eliminación) protección contra la eliminación) para evitar que se elimine
el clúster de base de datos. Si crea un clúster de base de
datos de producción con la consola, se habilita de forma
predeterminada la protección contra la eliminación.
10. Elija Create database (Crear base de datos) para crear el clúster de base de datos Aurora y, a
continuación, elija Close (Cerrar).
En la consola de Amazon RDS, el nuevo clúster de base de datos aparece en la lista de clústeres
de base de datos. El clúster de base de datos tendrá el estado creating hasta que se cree y esté
listo para el uso. Cuando el estado cambie a available, podrá conectarse a la instancia de escritor
para su clúster de base de datos. Dependiendo de la clase de instancia clúster y del almacenamiento
asignado, es posible que el nuevo clúster tarde varios minutos en estar disponible.
Para ver el clúster recién creado, elija la vista Databases (Bases de datos) en la consola de Amazon
RDS y elija el clúster de base de datos para mostrar los detalles del clúster de base de datos.
Para obtener más información, consulte Visualización de un clúster de base de datos de Amazon
Aurora (p. 375).

95
Anote los puertos y los puntos de enlace del clúster. Utilice el punto de enlace y el puerto del clúster
de base de datos de escritor en sus cadenas de conexión JDBC y ODBC para cualquier aplicación
que realice operaciones de lectura o escritura.
AWS CLI
Utilice AWS CLI para crear un clúster de base de datos de Aurora.

96
Note
Para poder crear un clúster de base de datos Aurora a través de la AWS CLI, debe cumplir los
requisitos previos, como crear una VPC y un grupo de subred de base de datos de RDS. Para
obtener más información, consulte Requisitos previos de clúster de base de datos (p. 86).
Para crear un clúster de base de datos Aurora mediante la AWS CLI, realice el siguiente
procedimiento:
Cuando cree una instancia o un clúster de base de datos de Aurora, asegúrese de que especifica el valor
correcto para la opción --engine.
• Al crear un clúster o una instancia de base de datos Aurora MySQL 5.6, debe especificar aurora para la
opción --engine.
• Al crear un clúster o una instancia de base de datos Aurora MySQL 5.7, debe especificar aurora-
mysql para la opción --engine.
• Al crear un clúster o una instancia de base de datos Aurora PostgreSQL, debe especificar aurora-
postgresql para la opción --engine.
Realice los pasos siguientes:
1. Identifique el identificador del grupo de subred de base de datos y el grupo de seguridad de la VPC
para el nuevo clúster de base de datos y, a continuación, llame al comando de la AWS CLI create-db-
cluster para crear el clúster de base de datos de Aurora.
Example Creación de un nuevo clúster de base de datos compatible con MySQL 5.6
El comando siguiente crea un nuevo clúster de base de datos compatible con MySQL 5.6 llamado
sample-cluster.
aws rds create-db-cluster --db-cluster-identifier sample-cluster --engine aurora \

--engine-version 5.6.10a --master-username user-name --master-user-
password password \
--db-subnet-group-name mysubnetgroup --vpc-security-group-ids sg-c7e5b0d2
Para Windows:
aws rds create-db-cluster --db-cluster-identifier sample-cluster --engine aurora ^

--engine-version 5.6.10a --master-username user-name --master-user-
password password ^
Example Creación de un nuevo clúster de base de datos compatible con MySQL 5.7
El comando siguiente crea un nuevo clúster de base de datos compatible con MySQL 5.7 denominado
sample-cluster.
aws rds create-db-cluster --db-cluster-identifier sample-cluster --engine aurora-mysql

\
--engine-version 5.7.12 --master-username user-name --master-user-
password password \

97
Para Windows:
aws rds create-db-cluster --db-cluster-identifier sample-cluster --engine aurora-mysql

^
--engine-version 5.7.12 --master-username user-name --master-user-password password
^
Example Creación de un nuevo clúster de base de datos compatible con Aurora PostgreSQL
El comando siguiente crea un nuevo clúster de base de datos de PostgreSQL denominado sample-
cluster.
aws rds create-db-cluster --db-cluster-identifier sample-cluster --engine aurora-

postgresql \
--master-username user-name --master-user-password password \
Para Windows:
aws rds create-db-cluster --db-cluster-identifier sample-cluster --engine aurora-

postgresql ^
--master-username user-name --master-user-password password ^
2. Cree la instancia de base de datos (escritor) principal.
La instancia de base de datos de escritor es la primera instancia que se crea en un clúster de base de
datos. Si usa la consola para crear un clúster de base de datos, Amazon RDS crea automáticamente
la instancia de base de datos de escritor del clúster de base de datos. Si usa la AWS CLI para crear
un clúster de base de datos, debe crear expresamente la instancia de base de datos de escritor para
el clúster de base de datos.
Invoque el comando create-db-instance de la AWS CLI para crear la instancia de escritor para el
clúster de base de datos. Incluya el nombre del clúster de base de datos como valor de la opción --
db-cluster-identifier.
Example Creación de una nueva instancia de base de datos compatible con MySQL 5.6
El comando siguiente crea una nueva instancia de base de datos compatible con MySQL 5.6 llamada
sample-instance.
aws rds create-db-instance --db-instance-identifier sample-instance \

--db-cluster-identifier sample-cluster --engine aurora --db-instance-class
db.r4.large
Para Windows:
aws rds create-db-instance --db-instance-identifier sample-instance ^

--db-cluster-identifier sample-cluster --engine aurora --db-instance-class
db.r4.large

98
Example Creación de una nueva instancia de base de datos compatible con MySQL 5.7
El comando siguiente crea una nueva instancia de base de datos compatible con MySQL 5.7
denominada sample-instance.
aws rds create-db-instance --db-instance-identifier sample-instance \

--db-cluster-identifier sample-cluster --engine aurora-mysql --db-instance-class
db.r4.large
Para Windows:

db.r4.large
Example Creación de una nueva instancia de base de datos compatible con PostgreSQL
El comando siguiente crea un nuevo clúster de base de datos compatible con PostgreSQL.
aws rds create-db-instance --db-instance-identifier sample-instance named sample-

instance.
--db-cluster-identifier sample-cluster --engine aurora-postgresql --db-instance-
class db.r4.large
Para Windows:

--db-cluster-identifier sample-cluster --engine aurora-postgresql --db-instance-
class db.r4.large
API de RDS
Note
Para poder crear un clúster de base de datos Aurora a través de la API de RDS, debe cumplir los
requisitos previos, como crear una VPC y un grupo de subred de base de datos de RDS. Para
obtener más información, consulte Requisitos previos de clúster de base de datos (p. 86).
Identifique el identificador del grupo de subred de base de datos y el grupo de seguridad de la VPC para el
nuevo clúster de base de datos y, a continuación, llame a la acción CreateDBInstance para crear el clúster
de base de datos.
Cuando cree una instancia o un clúster de base de datos de Aurora, asegúrese de que especifica el valor
correcto para el parámetro Engine.
• Para crear un clúster o una instancia de base de datos de Aurora MySQL 5.6, debe especificar aurora
para el parámetro Engine.
• Para crear un clúster o una instancia de base de datos de Aurora MySQL 5.7, debe especificar aurora-
mysql para el parámetro Engine.
• Para crear un clúster o una instancia de base de datos de Aurora PostgreSQL, debe especificar
aurora-postgresql para el parámetro Engine.

99
Uso de Aurora Serverless
Uso de Amazon Aurora Serverless

Amazon Aurora Serverless es una configuración de escalado automático bajo demanda para Amazon
Aurora. Un clúster de base de datos de Aurora Serverless es un clúster de base de datos que se
inicia, se cierra y escala automáticamente su capacidad computacional en función de las necesidades
de la aplicación. Aurora Serverless proporciona una opción rentable y relativamente sencilla para
cargas de trabajo infrecuentes, intermitentes o imprevisibles. Esto es posible porque se inicia, escala
automáticamente la capacidad computacional en función del uso de la aplicación y se cierra cuando no se
utiliza.
Note
Un clúster de base de datos que no es Serverless para Aurora se denomina clúster de base de
datos aprovisionado. Los clústeres Aurora Serverless y los clústeres aprovisionados tienen el
mismo tipo de volumen de almacenamiento de alta capacidad, distribuido y de alta disponibilidad.
Temas
• Beneficios de Aurora Serverless (p. 100)
• Casos de uso de Aurora Serverless (p. 101)
• Limitaciones de Aurora Serverless (p. 101)
• Uso de TLS/SSL con Aurora Serverless (p. 102)
• Funcionamiento de Aurora Serverless (p. 103)
• Creación de un clúster de base de datos de Aurora Serverless (p. 109)
• Restauración de un clúster de base de datos de Aurora Serverless (p. 115)
• Modificación de un clúster de base de datos de Aurora Serverless (p. 118)
• Configuración de la capacidad de un clúster de base de datos de Aurora Serverless (p. 120)
• Visualización de clústeres de base de datos Aurora Serverless (p. 122)
• Uso de la API de datos para Aurora Serverless (p. 125)
• Uso del editor de consultas de Aurora Serverless (p. 144)
Beneficios de Aurora Serverless

Aurora Serverless ofrece los siguientes beneficios:
Sencillez
Aurora Serverless elimina gran parte de la complejidad de la administración de las instancias de base
de datos y la capacidad.
Escalabilidad
Aurora Serverless escala de forma transparente la capacidad de memoria y de computación según se

necesita, sin interrumpir las conexiones del cliente.
Rentabilidad
Cuando se utiliza Aurora Serverless, únicamente se paga por los recursos de base de datos que se
consumen, por segundos.
Almacenamiento altamente disponible
Aurora Serverless utiliza el mismo sistema de almacenamiento distribuido, con tolerancia a errores y
con replicación de seis vías que Aurora para proteger contra la pérdida de datos.

100
Casos de uso de Aurora Serverless
Casos de uso de Aurora Serverless

Aurora Serverless se ha diseñado para los casos de uso siguientes:
Aplicaciones de uso infrecuente
Tiene una aplicación que solo se utiliza durante unos minutos varias veces al día o a la semana, como
una página de blog de bajo volumen. Con Aurora Serverless, únicamente se paga por los recursos de
base de datos que se consumen, por segundos.
Aplicaciones nuevas
Está implementando una nueva aplicación y no está seguro de qué tamaño de instancia necesita.
Con Aurora Serverless, puede crear un punto de enlace de base de datos y que esta última se escale
automáticamente según los requisitos de capacidad de la aplicación.
Cargas de trabajo variables
Tiene una aplicación que usa poco y que tiene picos de entre 30 minutos y varias horas algunas
veces al día o varias veces al año. Este es el caso, por ejemplo, de las aplicaciones de recursos
humanos, presupuestos y generación de informes operativos. Con Aurora Serverless, ya no tiene que
aprovisionar la capacidad de los picos ni de la carga media.
Cargas de trabajo imprevisibles
Usted ejecuta cargas de trabajo en las que la base de datos se utiliza durante todo el día, pero
también se generan picos de actividad difíciles de predecir. Un ejemplo de ello sería un sitio dedicado
al tráfico, que experimenta un aumento repentino de la actividad cuando comienza a llover. Con
Aurora Serverless, la capacidad de la base de datos se escala automáticamente para satisfacer las
necesidades de la carga de la aplicación en los picos y vuelve a escalarse en sentido descendente
cuando el aumento de actividad ha pasado.
Bases de datos de desarrollo y pruebas
Los desarrolladores utilizan las bases de datos durante el horario laboral, pero no las necesitan por
la noche ni en fin de semana. Con Aurora Serverless, la base de datos se cierra automáticamente
cuando no se utiliza.
Aplicaciones de varios inquilinos
Con Aurora Serverless, no es preciso administrar individualmente la capacidad de base de datos de

cada aplicación de la flota. Aurora Serverless administra la capacidad de base de datos individual
automáticamente.
Limitaciones de Aurora Serverless

Las limitaciones siguientes son aplicables a Aurora Serverless:
• Aurora Serverless solo está disponible para los siguientes:

• Aurora con compatibilidad con MySQL versión 5.6
• Aurora con compatibilidad con PostgreSQL versión 10.7.
• El número de puerto para las conexiones debe ser:
• 3306 para Aurora MySQL
• 5432 para Aurora PostgreSQL
• No se puede asignar una dirección IP pública a un clúster de base de datos de Aurora Serverless. Puede
obtener acceso a un clúster de base de datos Aurora Serverless desde una Virtual Private Cloud (VPC)
basada en el servicio Amazon VPC.
• Cada clúster de base de datos de Aurora Serverless requiere dos puntos de enlace de AWS PrivateLink.
Si llega al límite de puntos de enlace de PrivateLink dentro de su VPC, ya no podrá crear más clústeres

101
Uso de TLS/SSL con Aurora Serverless
de Aurora Serverless en dicha VPC. Para obtener información acerca de cómo comprobar y cambiar los
límites en los puntos de enlace de una VPC, consulte Límites de Amazon VPC.
• No se puede obtener acceso a un punto de enlace de un clúster de base de datos de Aurora Serverless
a través de una conexión de AWS VPN ni de una interconexión de VPC entre regiones. Existen
limitaciones al obtener acceso al punto de enlace de un clúster a través de una interconexión de VPC
intrarregional; para obtener más información, consulte Puntos de enlace de la VPC de interfaz (AWS
PrivateLink) en la Guía del usuario de VPC. Sin embargo, sí puede obtener acceso a un punto de enlace
de un clúster de base de datos Aurora Serverless a través de una conexión de AWS Direct Connect.
• Un grupo de subred de base de datos utilizado por Aurora Serverless no puede tener más de una subred
en la misma zona de disponibilidad.
• Los cambios realizados a un grupo de subred utilizado por un clúster de base de datos Aurora
Serverless no se aplican al clúster.
• Aurora Serverless no admite las siguientes características:
• Carga de datos desde un bucket de Amazon S3 (p. 641)
• Guardar datos en un bucket de Amazon S3 (p. 649)
• Invocación de una función AWS Lambda con una función nativa de Aurora MySQL (p. 656)
• Auditoría avanzada (p. 593)
• Réplicas de Aurora (p. 596)
• Backtrack (p. 546)
• Clonación de base de datos (p. 282)
• Autenticación de base de datos IAM (p. 180)
• Réplicas de lectura entre regiones (p. 599)
• Restauración de una instantánea a partir de una instancia de base de datos MySQL (p. 526)
• Migración de archivos de copia de seguridad de Amazon S3 (p. 504)
• Amazon RDS Performance Insights (p. 402)
Note
Puede obtener acceso a un clúster de base de datos Aurora Serverless desde AWS Lambda.
Para obtener más información sobre el uso de AWS Lambda, consulte Configuración de
una función de Lambda para acceder a los recursos de una Amazon VPC en la Guía para
desarrolladores de AWS Lambda.
Uso de TLS/SSL con Aurora Serverless

Puede conectarse a Aurora Serverless con el protocolo Transport Layer Security/Capa de conexión segura
(TLS/SSL). Para ello, utilice el procedimiento general descrito en el tema Conexión a un clúster de base de
datos Amazon Aurora (p. 148). Utilice certificados de AWS Certificate Manager (ACM). Para obtener más
información, consulte la Guía del usuario de AWS Certificate Manager.
Note
El soporte TLS para clústeres Aurora Serverless actualmente no está disponible en la región de
AWS China (Pekín).
Protocolo TLS, versión 1.0, 1.1 o 1.2. Sin embargo, no necesita configurar la base de datos de Aurora
Serverless para TLS. En particular, no use la cláusula REQUIRE en sus privilegios de usuario de base de
datos para SSL. Si lo hace, evitará que ese usuario se conecte.
Aurora Serverless puede garantizar que su sesión utiliza TLS entre su cliente y el punto de enlace de la
VPC de Aurora Serverless. Para que Aurora Serverless realice esa acción, especifique el requisito del lado
del cliente con el parámetro --ssl-mode.
102
Funcionamiento de Aurora Serverless
De forma predeterminada, los programas del cliente establecerá una conexión cifrada con Aurora
Serverless, con un mayor control disponible mediante la opción --ssl-mode. Desde el lado del cliente,
Aurora Serverless es compatible con todos los modos de SSL.
Para el cliente mysql y psql, los modos SSL son los siguientes:
PREFERRED
SSL es la primera opción, pero no es necesaria.

DISABLED
No se permite SSL.
REQUIRED
Obliga a usar SSL.

VERIFY_CA
Implemente SSL y verifique la entidad de certificación (CA).

VERIFY_IDENTITY
Obliga a usar SSL y comprueba CA y el nombre de host de CA.
Cuando se utiliza un cliente mysql o psql con --ssl-modeVERIFY_CA o VERIFY_IDENTITY,

especifique la opción --ssl-ca que se dirige a una CA en formato .pem. Para un archivo .pem que pueda
utilizar, descargue el almacén de confianza Amazon Root CA 1 de Amazon Trust Services.
Aurora Serverless utiliza certificados comodín. Si utiliza el cliente mysql para conectarse, actualmente
deberá usar el comando mysql compatible con MySQL 8.0.

Cuando se utiliza Amazon Aurora sin Aurora Serverless (clústeres DB aprovisionados), es posible elegir
el tamaño de clase de instancia de base de datos y crear réplicas de Aurora para aumentar el desempeño
de lectura. Si la carga de trabajo cambia, se puede modificar el tamaño de la clase de instancia de base de
datos y modificar el número de réplicas de Aurora. Este modelo funciona bien cuando la carga de trabajo
de la base de datos es previsible, porque se puede ajustar la capacidad manualmente en función de la
carga de trabajo prevista.
Sin embargo, en algunos entornos, las cargas de trabajo pueden ser intermitentes e impredecibles. Puede
haber periodos de intensas cargas de trabajo que duren desde solo unos minutos hasta horas, o largos
periodos de poca o ninguna actividad. Ejemplos de ello son los sitios web comerciales con eventos de
ventas intermitentes, las bases de datos de generación de informes que producen informes cuando se
necesitan, los entornos de desarrollo y pruebas o las aplicaciones nuevas cuyos requisitos son inciertos.
En estos casos y muchos otros, puede ser difícil configurar justo la capacidad correcta en el momento
oportuno. Esto puede dar lugar a costos más elevados si hay que pagar por una capacidad que no se ha
utilizado.
Con Aurora Serverless, puede crear un punto de enlace de base de datos sin especificar el tamaño de la
clase de instancia de base de datos. Usted define la capacidad mínima y máxima. Con Aurora Serverless,
el punto de enlace de la base de datos se conecta a una flota de proxies que dirige la carga de trabajo a
una flota de recursos que se escalan automáticamente. Gracias a la flota de proxies, las conexiones se
mantienen mientras Aurora Serverless escala los recursos automáticamente en función de la capacidad
mínima y máxima especificada. Las aplicaciones cliente de base de datos no requieren cambiar para
usar la flota de proxies. Aurora Serverless administra las conexiones automáticamente. El escalado
es rápido porque utiliza un grupo de recursos activos que están siempre listos para las solicitudes de

103
servicio. El almacenamiento y el procesamiento son procesos distintos, lo que le permite escalar hasta un
procesamiento cero y pagar solo por el almacenamiento.
Aurora Serverless presenta un nuevo modo de motor de base de datos serverless para clústeres de
base de datos Aurora. Los clústeres de base de datos que no son Serverless usan el modo de motor de
base de datos provisioned.
Arquitectura de Aurora Serverless

En la imagen siguiente se proporciona información general sobre la arquitectura de Aurora Serverless.
En lugar de aprovisionar y administrar los servidores de base de datos, se especifican unidades de

capacidad de Aurora (ACU). Cada ACU es una combinación de capacidad de procesamiento y memoria.
El almacenamiento de base de datos escala automáticamente de 10 GiB a 64 TiB, al igual que el
almacenamiento en un clúster de base de datos de Aurora estándar.
Puede especificar las ACU mínima y máxima. La unidad de capacidad de Aurora mínima es la ACU más
baja a la que puede escalarse el clúster de base de datos al reducir la capacidad. La unidad de capacidad
de Aurora máxima es la ACU más baja a la que puede escalarse el clúster de base de datos al aumentar
la capacidad. En función de la configuración, Aurora Serverless crea automáticamente reglas de escalado
para los umbrales de utilización de la CPU, conexiones y memoria disponible.
Aurora Serverless administra el grupo activo de recursos de una región de AWS para minimizar el tiempo
de escalado. Cuando Aurora Serverless agrega nuevos recursos al clúster de base de datos Aurora, utiliza
la flota de proxies para trasladar las conexiones de clientes activas a los nuevos recursos. En cualquier
momento dado, solo se le cobrarán las ACU que se estén utilizando activamente en su clúster de base de
datos de Aurora.
Escalado automático para Aurora Serverless

La capacidad asignada al clúster de base de datos de Aurora Serverless se escala en sentido ascendente
y descendente en función de la carga (la utilización de la CPU y el número de conexiones) generada por la

104
aplicación cliente. También se escala a capacidad cero cuando no hay conexiones durante un periodo de
5 minutos.
Se realiza el escalado ascendente de Aurora Serverless cuando se detectan restricciones de capacidad

en la CPU, las conexiones o la memoria. También se realiza el escalado ascendente cuando detecta
problemas de rendimiento que pueden resolverse mediante el escalado ascendente.
Después del escalado ascendente, el periodo de recuperación para el escalado descendente es de 15

minutos. Después del escalado descendente de nuevo es de 310 segundos.
Note
No hay ningún periodo de recuperación para el escalado ascendente. Se puede realizar el

escalado ascendente de Aurora cuando sea necesario, incluido el momento justo después del
escalado ascendente y descendente.
Un punto de escalado es un momento en el que la base de datos puede iniciar sin problemas la operación
de escalado. En las condiciones siguientes, Aurora Serverless podría no ser capaz de encontrar un punto
de escalado:
• Hay en curso consultas o transacciones de ejecución prolongada

• Se están utilizando tablas temporales o bloqueos de tabla.
En dichos casos, Aurora Serverless sigue intentando buscar un punto de escalado para poder iniciar la
operación de escalado. Seguirá actuando así mientras determine que el clúster de base de datos tiene que
escalarse.
Puede consultar los eventos de escalado en los detalles de un clúster de base de datos en la Consola de
administración de AWS. También puede monitorizar la capacidad actual asignada al clúster de base de
datos utilizando la métrica ServerlessDatabaseCapacity de Amazon CloudWatch.
Pausa y reanudación automáticas en Aurora Serverless

Puede optar por poner en pausa el clúster de base de datos de Aurora Serverless transcurrido un tiempo
determinado sin actividad. Usted especifica el periodo sin actividad que deberá transcurrir antes de poner
en pausa el clúster de base de datos. El valor predeterminado es de cinco minutos. También puede
deshabilitar la pausa del clúster de base de datos.
Cuando el clúster de base de datos está en pausa, no se produce ningún tipo de actividad de computación
ni de memoria y solamente se le cobra el almacenamiento. Si se solicitan conexiones a la base de
datos mientras un clúster de base de datos de Aurora Serverless está en pausa, este se reanuda
automáticamente y atiende las solicitudes de conexión.
Note
Si un clúster de base de datos está en pausa durante más de siete días, puede hacerse una
copia de seguridad de él mediante una instantánea. En este caso, el clúster de base de datos se
restaurará cuando haya una solicitud de conectarse a él.
Acción de tiempo de espera para cambios de capacidad

Puede cambiar la capacidad de un clúster de base de datos de Aurora Serverless. Cuando cambie la
capacidad, Aurora Serverless intentará buscar un punto de escalado para el cambio. Si Aurora Serverless
no puede buscar un punto de escalado, se agota el tiempo de espera. Puede especificar la realización de
una de las siguientes acciones cuando se agote el tiempo de espera de un cambio de capacidad:
• Forzar el cambio de capacidad: establezca la capacidad en el valor especificado lo antes posible.

105
• Revierta el cambio de capacidad: cancele el cambio de capacidad.
Important
Si fuerza el cambio de capacidad, podrían interrumpirse las conexiones que impidan que Aurora
Serverless encuentre un punto de escalado.
Para obtener más información sobre cómo cambiar la capacidad, consulte Modificación de un clúster de
base de datos de Aurora Serverless (p. 118).
Aurora Serverless y grupos de parámetros

Los grupos de parámetros funcionan de forma distinta para los clústeres de base de datos de Serverless
en comparación con los clústeres de base de datos aprovisionados. En concreto, las instancias de base
de datos en un clúster de Aurora Serverless solo tienen grupos de parámetros del clúster de base de
datos asociados, no grupos de parámetros de base de datos. Los clústeres de Serverless se basan en los
grupos de parámetros del clúster de base de datos porque las instancias de base de datos no se asocian
de forma permanente a los clústeres de Aurora Serverless. Aurora añade y elimina las instancias de base
de datos automáticamente según sea necesario.
Para personalizar los ajustes de configuración para un clúster de Aurora Serverless, puede definir su
propio grupo de parámetros del clúster de base de datos y modificar los parámetros que contiene. Puede
modificar cambios parámetros de nivel del clúster y los parámetros que se aplican en el nivel de instancia
en otros tipos de clústeres de Aurora. Sin embargo, cuando modifica un grupo de parámetros del clúster
de base de datos que se asocia a un clúster de base de datos de Aurora Serverless, se aplican las
modificaciones de forma distinta a otros grupos de parámetros del clúster de base de datos.
Cuando guarda los cambios en un grupo de parámetros del clúster de base de datos para un clúster de
base de datos de Aurora Serverless, se aplican los cambios de inmediato. Para ello, Aurora Serverless
ignora los siguientes ajustes:
• Cuando se modifica el clúster de base de datos en su conjunto, Aurora Serverless ignora lo siguiente:
• La configuración Apply Immediately (Aplicar inmediatamente) en la Consola de administración de
AWS.
• La opción --apply-immediately|--no-apply-immediately en el comando de la AWS CLI
modify-db-cluster.
• El parámetro ApplyImmediately en la operación de la API de RDS ModifyDBCluster
• Cuando se modifican los parámetros, Aurora Serverless ignora el valor ApplyMethod en la lista de
parámetros en los comandos de la AWS CLI modify-db-cluster-parameter-group y reset-db-cluster-
parameter-group.
• Cuando se modifican los parámetros, Aurora Serverless ignora el valor ApplyMethod en la
lista de parámetros en las operaciones de la API de RDS ModifyDBClusterParameterGroup y
ResetDBClusterParameterGroup.
• Aurora Serverless hace caso omiso al estado del grupo de parámetros de clúster de base de datos
pending-reboot.
Para aplicar un cambio a un grupo de parámetros de clúster de base de datos, Aurora Serverless inicia una
escalabilidad perfecta con la actual capacidad si el clúster de base de datos está activo. Reanuda el clúster
de base de datos si está pausado.
Para ver el modo del motor compatible para los parámetros de nivel de clúster, ejecute
el comando describe-engine-default-cluster-parameters o la acción de la API de RDS
DescribeEngineDefaultClusterParameters. Por ejemplo, el siguiente comando de Linux extrae los nombres
de los parámetros que puede establecer para clústeres de Aurora MySQL Serverless, a partir de un grupo
de parámetros de clúster de base de datos predeterminado de aurora5.6.

106
aws rds describe-engine-default-cluster-parameters \

--db-parameter-group-family aurora5.6 \
--query 'EngineDefaults.Parameters[*].{ParameterName:ParameterName, \
SupportedEngineModes:SupportedEngineModes} \
| [?contains(SupportedEngineModes, `serverless`) == `true`] \
| [*].{param:ParameterName}' \
--output text
Por ejemplo, el siguiente comando de Linux extrae los nombres de los parámetros que puede establecer
para clústeres Aurora PostgreSQL Serverless, a partir de un grupo de parámetros de clúster de base de
datos predeterminado de aurora-postgresql10.
aws rds describe-engine-default-cluster-parameters \

--db-parameter-group-family aurora-postgresql10 \
--query 'EngineDefaults.Parameters[*].{ParameterName:ParameterName, \
SupportedEngineModes:SupportedEngineModes} \
| [?contains(SupportedEngineModes, `serverless`) == `true`] \
--output text
El siguiente comando de Linux extrae los nombres de los parámetros que puede establecer para clústeres
de Serverless a partir del grupo de parámetros de clúster de base de datos que ha creado.
aws rds describe-db-cluster-parameters \

--db-cluster-parameter-group-name my_cluster_param_group_name \
--query 'Parameters[*].{ParameterName:ParameterName,
SupportedEngineModes:SupportedEngineModes}
| [?contains(SupportedEngineModes, `serverless`) == `true`]
--output text
Para obtener más información acerca de los grupos de parámetros, consulte Trabajo con los grupos de
parámetros de base de datos y grupos de parámetros de clúster de base de datos (p. 259).
Con un clúster de base de datos de Aurora MySQL Serverless, puede modificar solo los siguientes
parámetros. Para los demás parámetros de configuración, los clústeres de Aurora MySQL Serverless
utilizan los valores predeterminados.
• character_set_server.
• collation_server.
• general_log. Esta configuración estaba anteriormente solo en el grupo de parámetros de la instancia
de base de datos.
• innodb_file_format. Esta configuración estaba anteriormente solo en el grupo de parámetros de la
instancia de base de datos.
• innodb_file_per_table.
• innodb_large_prefix. Esta configuración estaba anteriormente solo en el grupo de parámetros de la
• innodb_lock_wait_timeout. Esta configuración estaba anteriormente solo en el grupo de
parámetros de la instancia de base de datos.
• innodb_monitor_disable. Esta configuración estaba anteriormente solo en el grupo de parámetros
de la instancia de base de datos.
• innodb_monitor_enable. Esta configuración estaba anteriormente solo en el grupo de parámetros de
la instancia de base de datos.

107
• innodb_monitor_reset. Esta configuración estaba anteriormente solo en el grupo de parámetros de

• innodb_monitor_reset_all. Esta configuración estaba anteriormente solo en el grupo de
• innodb_print_all_deadlocks. Esta configuración estaba anteriormente solo en el grupo de
• lc_time_names.
• log_output. Esta configuración estaba anteriormente solo en el grupo de parámetros de la instancia
de base de datos. Esta configuración tiene un valor predeterminado de FILE. No puede cambiar ese
valor.
• log_queries_not_using_indexes. Esta configuración estaba anteriormente solo en el grupo de
• log_warnings. Esta configuración estaba anteriormente solo en el grupo de parámetros de la instancia
de base de datos.
• long_query_time. Esta configuración estaba anteriormente solo en el grupo de parámetros de la
• lower_case_table_names.
• net_read_timeout. Esta configuración estaba anteriormente solo en el grupo de parámetros de la
• net_retry_count. Esta configuración estaba anteriormente solo en el grupo de parámetros de la
• net_write_timeout. Esta configuración estaba anteriormente solo en el grupo de parámetros de la
• server_audit_logging.
• server_audit_events.
• server_audit_excl_users.
• server_audit_incl_users.
• slow_query_log. Esta configuración estaba anteriormente solo en el grupo de parámetros de la
• sql_mode. Esta configuración estaba anteriormente solo en el grupo de parámetros de la instancia de
base de datos.
• time_zone.
• tx_isolation. Esta configuración estaba anteriormente solo en el grupo de parámetros de la instancia
de base de datos.
Aurora Serverless y mantenimiento

Aurora Serverless realiza un mantenimiento regular para que su clúster de base de datos tenga las últimas
funciones, correcciones y actualizaciones de seguridad. Aurora Serverless realiza el mantenimiento de una
manera no disruptiva siempre que sea posible. Si están en curso transacciones de larga ejecución, o se
utilizan tablas temporales o bloqueos de tabas, el mantenimiento podría provocar la caída momentánea de
las conexiones utilizadas activamente.
Para aplicar mantenimiento, Aurora Serverless debe encontrar un punto de escalado. Para obtener
más información acerca de los puntos de escalado, consulte Escalado automático para Aurora
Serverless (p. 104).
Si se requiere mantenimiento par aun clúster de base de datos Aurora Serverless, el clúster de base de
datos intenta encontrar un punto de escalado para aplicar el mantenimiento durante un día. Si después de
un día no se puede encontrar ningún punto de escalado, Aurora Serverless crea un evento de escalado

108
Creación de un clúster de base
de datos de Aurora Serverless
para notificarle que debe escalar para aplicar el mantenimiento. La notificación incluye la cantidad
de tiempo que tiene que forzar el escalado de su clúster de base de datos. Después de recibir esta
notificación, puede controlar el tiempo de escalado y el mantenimiento se aplica en ese momento. Aurora
Serverless intenta aplicar el mantenimiento sin problemas durante el tiempo especificado en el evento.
Una vez que pase ese periodo de tiempo, Aurora Serverless deja caer las conexiones para aplicar el
mantenimiento.
Note
Las ventanas de mantenimiento no se aplican a Aurora Serverless.
Aurora Serverless y conmutación por error

En la actualidad, la instancia de BD de un clúster de base de datos Aurora Serverless se crea en una
zona de disponibilidad (AZ) individual. Si la interfaz de base de datos o la AZ deja de estar disponible,
Aurora recrea la instancia de base de datos en una AZ diferente. Nos referimos a esta capacidad como
conmutación por error automática multi-AZ.
El mecanismo de conmutación por error tarda más que para un clúster aprovisionado de Aurora. El tiempo
de conmutación por error de Aurora Serverless está sin definir en estos momentos porque depende de la
demanda y de la disponibilidad de capacidad en otras zonas de disponibilidad dentro de la región de AWS
dada.
Debido a que Aurora separa la capacidad de computación y el almacenamiento, el volumen de

almacenamiento para el clúster se distribuye por varias AZ. Sus datos permanecen disponibles si alguna
interrupción afecta la instancia de base de datos o la AZ asociada.
Aurora Serverless e instantáneas

El volumen del clúster para un clúster Aurora Serverless siempre está cifrado. Puede elegir la clave de
cifrado pero no es posible desactivar el cifrado. Para copiar o compartir una instantánea de un clúster de
Aurora Serverless, cifre la instantánea mediante su propia clave de KMS.
Creación de un clúster de base de datos de Aurora

Serverless
Cuando se crea un clúster de base de datos de Aurora Serverless, puede establecer la capacidad mínima
y máxima del clúster. Cada unidad de capacidad equivale a una configuración de computación y memoria
específica. Aurora Serverless crea automáticamente reglas de escalado para los umbrales de utilización
de la CPU, conexiones y memoria disponible. También puede establecer si Aurora Serverless pondrá en
pausa la base de datos cuando no haya actividad y la reanudará cuando vuelva a haberla.
Puede establecer los valores específicos siguientes:
• Minimum Aurora capacity unit (Unidad de capacidad de Aurora mínima): Aurora Serverless puede
reducir la capacidad hasta esta unidad de capacidad.
• Maximum Aurora capacity unit (Unidad de capacidad de Aurora máxima): Aurora Serverless puede
aumentar la capacidad hasta esta unidad de capacidad.
• Timeout action (Acción de tiempo de espera): la acción que realizar cuando se agota el tiempo de espera
de la modificación de capacidad porque no se detecta el punto de escalado. Aurora puede forzar el
cambio de capacidad para establecer la capacidad en el valor especificado lo antes posible. También
puede revertir el cambio de capacidad para cancelarla. Para obtener más información, consulte Acción
de tiempo de espera para cambios de capacidad (p. 105).
• Pause after inactivity (Pausa tras inactividad): el tiempo sin tráfico de base de datos que ha de transcurrir
para escalar hasta la capacidad de procesamiento cero. Cuando se reanude el tráfico de la base de

109
datos, Aurora reanudará automáticamente la capacidad de procesamiento y se escalará para controlar el

tráfico.
Puede crear un clúster de base de datos Aurora Serverless mediante la Consola de administración de
AWS, la AWS CLI o la API de RDS.
Para obtener información general acerca de cómo crear un clúster de base de datos, consulte Creación de
un clúster de base de datos de Amazon Aurora (p. 85).
Note
Aurora Serverless actualmente no está disponible en todas las regiones de AWS. Para obtener
más información sobre Aurora Serverless, consulte Precios.
El volumen de un clúster de Aurora Serverless siempre está cifrado. Puede elegir la clave de
cifrado pero no es posible desactivar el cifrado. Por tanto, no puede realizar operaciones que
no estén permitidas para instantáneas cifradas Por ejemplo, no puede copiar instantáneas de
clústeres Aurora Serverless a una región de AWS diferente.
Consola
Para crear un nuevo clúster de base de datos Aurora Serverless mediante la Consola de administración de
AWS, especifique Serverless (Sin servidor) en Capacity type (Tipo de capacidad) en la página Specify DB
details (Especificar detalles de base de datos).
Ejemplo deAurora MySQL
En la imagen siguiente se muestra la página Specify DB details (Especificar detalles de base de datos) con
la opción Serverless (Sin servidor) seleccionada al crear un clúster de base de datos para el motor Aurora
MySQL.
Puede establecer la configuración de escalado del clúster de base de datos Aurora Serverless ajustando
los valores en la sección Capacity settings (Ajustes de capacidad) de la página Configure advanced
settings (Configurar ajustes avanzados).

110
En la imagen siguiente se muestran los Capacity settings (Ajustes de capacidad) que puede ajustar para el
clúster de base de datos Aurora MySQL Serverless.
También puede habilitar la API de datos para el clúster de base de datos de Aurora MySQL Serverless.
Para obtener más información, consulte Uso de la API de datos para Aurora Serverless (p. 125).
Ejemplo deAurora PostgreSQL
Para el motor Aurora PostgreSQL, elija primero la versión de motor de base de datos para Aurora
PostgreSQL que es compatible con PostgreSQL, versión 10.7. A continuación elija Serverless para
Capacity type (Tipo de capacidad).

111
Puede establecer la configuración de escalado del clúster de base de datos Aurora Serverless ajustando
los valores en la sección Capacity settings (Ajustes de capacidad) de la página Configure advanced
settings (Configurar ajustes avanzados).
En la imagen siguiente se muestran los Capacity settings (Ajustes de capacidad) que puede ajustar para el
clúster de base de datos Aurora PostgreSQL Serverless.

112
Para obtener información adicional acerca de cómo crear un clúster de base de datos de Aurora mediante
la Consola de administración de AWS, consulte Creación de un clúster de base de datos de Amazon
Aurora (p. 85).
Para conectarse a un clúster de base de datos de Aurora Serverless, use el punto de enlace de base de
datos. Para obtener información más detallada, consulte las instrucciones que se describen en Conexión a
Note
Si aparece el siguiente mensaje de error, significa que su cuenta requiere permisos adicionales:
Unable to create the resource. Verify that you have permission to create
service linked role. Otherwise wait and try again later.
Para obtener más información, consulte Uso de roles vinculados a servicios en Amazon
Aurora (p. 207).
AWS CLI
Para crear un nuevo clúster de base de datos de Aurora Serverless mediante la AWS CLI, ejecute el
comando create-db-cluster y especifique serverless en la opción --engine-mode.
Si lo desea, puede especificar la opción --scaling-configuration para configurar la capacidad

mínima, la capacidad máxima y la pausa automática cuando no haya conexiones.
Los siguientes ejemplos de comandos crean un nuevo clúster de base de datos Serverless estableciendo
la opción --engine-mode en serverless. Los ejemplos también especifican valores para la opción --
scaling-configuration.
Ejemplo de Aurora MySQL
El comando siguiente crea un nuevo clúster de base de datos Serverless compatible con MySQL 5.6. Los
valores de capacidad válidos para Aurora MySQL son 1, 2, 4, 8, 16, 32, 64, 128 y 256.

113
aws rds create-db-cluster --db-cluster-identifier sample-cluster --engine aurora --engine-

version 5.6.10a \
--engine-mode serverless --scaling-configuration
MinCapacity=4,MaxCapacity=32,SecondsUntilAutoPause=1000,AutoPause=true \
Para Windows:

version 5.6.10a ^
MinCapacity=4,MaxCapacity=32,SecondsUntilAutoPause=1000,AutoPause=true ^
Ejemplo de Aurora PostgreSQL
El comando siguiente crea un nuevo clúster de base de datos Serverless compatible con PostgreSQL. El
valor válido --engine-version es 2.3, que es compatible con PostgreSQL versión 10.7. Los valores de
capacidad válidos para Aurora PostgreSQL son 8, 16, 32, 64, 192 y 384.

version 2.3 \
MinCapacity=8,MaxCapacity=64,SecondsUntilAutoPause=1000,AutoPause=true \
Para Windows:

version 2.3 ^
MinCapacity=8,MaxCapacity=64,SecondsUntilAutoPause=1000,AutoPause=true ^
API de RDS
Para crear un nuevo clúster de base de datos de Aurora Serverless mediante la API de RDS, ejecute la
acción CreateDBCluster y especifique serverless en el parámetro EngineMode.
Si lo desea, puede especificar el parámetro ScalingConfiguration para configurar la capacidad

mínima, la capacidad máxima y la pausa automática cuando no haya conexiones. Entre los valores de
capacidad válidos se incluyen los siguientes:

114
Restauración de un clúster de base
• Aurora MySQL: 1, 2, 4, 8, 16, 32, 64, 128 y 256.

• Aurora PostgreSQL: 8, 16, 32, 64, 192 y 384.
Restauración de un clúster de base de datos de

Aurora Serverless
Puede configurar un clúster de base de datos Aurora Serverless al restaurar una instantánea de clúster
de base de datos aprovisionada mediante la Consola de administración de AWS, la AWS CLI o la API de
RDS.
Cuando restaure una instantánea en un clúster de base de datos de Aurora Serverless, podrá establecer
los siguientes valores específicos:
tráfico.
Para obtener información general acerca de cómo restaurar un clúster de base de datos a partir de una
instantánea, consulte Restauración de una instantánea de clúster de base de datos (p. 319).
Consola
Puede restaurar una instantánea de un clúster de base de datos en un clúster de base de datos Aurora con
la Consola de administración de AWS.
Para restaurar una instantánea de clúster de base de datos en un clúster de base de datos de
Aurora
que aloja el clúster de base de datos de origen.
3. En el panel de navegación, elija Snapshots (Instantáneas) y, a continuación, seleccione la instantánea
del clúster de base de datos que desea restaurar.
4. En Actions (Acciones), seleccione Restore Snapshot (Restaurar instantánea).
5. En la página Restore DB Cluster (Restaurar clúster de base de datos), elija Serverless (Sin servidor)
en Capacity type (Tipo de capacidad).

115
6. En el campo DB cluster Identifier (Identificador de clúster de base de datos), escriba el nombre del
clúster de base de datos restaurado; a continuación, rellene los demás campos.
7. En la sección Capacity settings (Configuración de capacidad), modifique la configuración de escalado.
8. Elija Restore DB Cluster (Restaurar clúster de base de datos).
datos. Para obtener información más detallada, consulte las instrucciones que se describen en Conexión a

116
Note
Si aparece el siguiente mensaje de error, significa que su cuenta requiere permisos adicionales:
Unable to create the resource. Verify that you have permission to create
service linked role. Otherwise wait and try again later.
Para obtener más información, consulte Uso de roles vinculados a servicios en Amazon
Aurora (p. 207).
AWS CLI
Para configurar un clúster de base de datos de Aurora Serverless cuando realiza una restauración a partir
de un clúster de base de datos mediante la AWS CLI, ejecute el comando de la CLI restore-db-cluster-
from-snapshot y especifique serverless para la opción --engine-mode.
Si lo desea, puede especificar la opción --scaling-configuration para configurar la capacidad

• Aurora MySQL: 1, 2, 4, 8, 16, 32, 64, 128 y 256.

En el ejemplo siguiente, se restaura desde una instantánea de clúster de base de datos creada
previamente con el nombre mydbclustersnapshot. La restauración se hace en un nuevo clúster de
base de datos denominado mynewdbcluster. Para restaurar el clúster de base de datos como clúster de
base de datos Aurora Serverless, establezca la opción --engine-mode en serverless. En el ejemplo
también se especifican valores para la opción --scaling-configuration.
aws rds restore-db-cluster-from-snapshot \

--db-cluster-identifier mynewdbcluster \
--snapshot-identifier mydbclustersnapshot \
MinCapacity=8,MaxCapacity=64,TimeoutAction='ForceApplyCapacityChange',SecondsUntilAutoPause=1000,AutoP
Para Windows:
aws rds restore-db-cluster-from-snapshot ^

--db-instance-identifier mynewdbcluster ^
--db-snapshot-identifier mydbclustersnapshot ^
MinCapacity=8,MaxCapacity=64,TimeoutAction='ForceApplyCapacityChange',SecondsUntilAutoPause=1000,AutoP
API de RDS
Para configurar un clúster de base de datos de Aurora Serverless al restaurar a partir de un clúster de
base de datos mediante la API de RDS, ejecute la acción RestoreDBClusterFromSnapshot y especifique
serverless en el parámetro EngineMode.
Si lo desea, puede especificar el parámetro ScalingConfiguration para configurar la capacidad


117
Modificación de un clúster de base
• Aurora MySQL: 1, 2, 4, 8, 16, 32, 64, 128 y 256.

Modificación de un clúster de base de datos de Aurora

Serverless
Después de configurar un clúster de base de datos Aurora Serverless, puede modificar su configuración de
escalado mediante la Consola de administración de AWS, la AWS CLI o la API de RDS.
Puede establecer la capacidad mínima y máxima del clúster de base de datos. Cada unidad de
capacidad equivale a una configuración de computación y memoria específica. Aurora Serverless crea
automáticamente reglas de escalado para los umbrales de utilización de la CPU, conexiones y memoria
disponible. También puede establecer si Aurora Serverless pondrá en pausa la base de datos cuando no
haya actividad y la reanudará cuando vuelva a haberla.
Puede establecer los valores específicos siguientes:
tráfico.
Consola
Puede modificar la configuración de escalado de un clúster de base de datos Aurora mediante la Consola
de administración de AWS.
Para modificar un clúster de base de datos de Aurora Serverless
1. Abra la consola de Amazon RDS en https://console.aws.amazon.com/rds/.

3. Elija el clúster de base de datos de Aurora Serverless que desee modificar.
4. Para Actions (Acciones), elija Modify cluster (Modificar clúster).
5. En la sección Capacity settings (Configuración de capacidad), modifique la configuración de escalado.

118
Modificación de un clúster de base
6. Elija Continue.
7. Elija Modify Cluster (Modificar clúster).
El cambio se aplica inmediatamente.
AWS CLI
Para modificar la configuración de escalado de un clúster de base de datos de Aurora Serverless mediante
la AWS CLI, ejecute el comando modify-db-cluster de la AWS CLI. Especifique la opción --scaling-
configuration para configurar la capacidad mínima, la capacidad máxima y la pausa automática
cuando no haya conexiones. Entre los valores de capacidad válidos se incluyen los siguientes:
• Aurora MySQL: 1, 2, 4, 8, 16, 32, 64, 128 y 256.

En este ejemplo, se modifica la configuración de escalado de un clúster de base de datos Aurora

Serverless denominado sample-cluster.
aws rds modify-db-cluster --db-cluster-identifier sample-cluster \

--scaling-configuration
MinCapacity=8,MaxCapacity=64,SecondsUntilAutoPause=500,TimeoutAction='ForceApplyCapacityChange',AutoPa
Para Windows:
aws rds modify-db-cluster --db-cluster-identifier sample-cluster ^

--scaling-configuration
MinCapacity=8,MaxCapacity=64,SecondsUntilAutoPause=500,TimeoutAction='ForceApplyCapacityChange',AutoPa

119
Configuración de la capacidad de un clúster
de base de datos de Aurora Serverless
API de RDS
Puede modificar la configuración de escalado de un clúster de base de datos de Aurora mediante la
acción ModifyDBCluster de la API. Especifique el parámetro ScalingConfiguration para configurar
la capacidad mínima, la capacidad máxima y la pausa automática cuando no haya conexiones. Entre los
valores de capacidad válidos se incluyen los siguientes:
• Aurora MySQL: 1, 2, 4, 8, 16, 32, 64, 128 y 256.

Configuración de la capacidad de un clúster de base

Puede establecer la capacidad de un clúster de base de datos Aurora Serverless en un valor específico
mediante la Consola de administración de AWS, la AWS CLI o el API de RDS.
Aurora Serverless se escala de forma transparente en función de la carga de trabajo del clúster de base de
datos. En algunos casos, la capacidad podría no escalarse a la velocidad suficiente para cubrir un cambio
repentino de la carga de trabajo, por ejemplo, si se produce gran cantidad de transacciones nuevas. En
estos casos, puede establecer la capacidad de manera explícita. Después de establecer la capacidad
explícitamente, Aurora Serverless puede escalar automáticamente el clúster de base de datos. Realiza la
acción según el periodo de recuperación del escalado descendente.
Consola
Puede establecer la capacidad de un clúster de base de datos Aurora mediante la Consola de
administración de AWS.
Para modificar un clúster de base de datos de Aurora Serverless

3. Elija el clúster de base de datos de Aurora Serverless que desee modificar.
4. En Actions (Acciones), elija Set capacity (Establecer capacidad).
5. En la ventana Scale database capacity (Escalar capacidad de base de datos), establezca la
capacidad, la capacidad a la que se debe escalar el clúster de base de datos.

120
Configuración de la capacidad de un clúster
de base de datos de Aurora Serverless
6. Habilite o deshabilite la opción para forzar la escala de capacidad. Si la habilita, especifique el tiempo
para buscar un punto de escalado. Aurora Serverless intenta buscar un punto de escalado antes de
que se agote el tiempo de espera. Si se alcanza el tiempo de espera, Aurora Serverless realiza una de
las siguientes acciones:
• Si se marca, Aurora Serverless forzará la capacidad de escalado para continuar después del tiempo
de espera.
• Si no se marca, Aurora Serverless realizará el cambio de capacidad de escalado después del
tiempo de espera.
Important
Cuando la opción está habilitada, podrían interrumpirse las conexiones que impidan que
Aurora Serverless encuentre un punto de escalado. Para obtener más información sobre
los puntos de escalado y los periodos de recuperación, consulte Escalado automático para
7. Seleccione Apply.
AWS CLI
Para establecer la capacidad de un clúster de base de datos de Aurora Serverless mediante la AWS
CLI, ejecute el comando modify-current-db-cluster-capacity de la AWS CLI y especifique la opción --
capacity. Entre los valores de capacidad válidos se incluyen los siguientes:
• Aurora MySQL: 1, 2, 4, 8, 16, 32, 64, 128 y 256.


121
Visualización de clústeres de
base de datos Aurora Serverless
En este ejemplo, se establece la capacidad de un clúster de base de datos Aurora Serverless denominado
sample-cluster en 64.
aws rds modify-current-db-cluster-capacity --db-cluster-identifier sample-cluster --

capacity 64
API de RDS
Puede establecer la capacidad de un clúster de base de datos de Aurora mediante la acción
ModifyCurrentDBClusterCapacity de la API. Especifique el parámetro Capacity. Entre los valores de
• Aurora MySQL: 1, 2, 4, 8, 16, 32, 64, 128 y 256.

Visualización de clústeres de base de datos Aurora

Serverless
Después de crear uno o varios clústeres de base de datos de Aurora Serverless, puede consultar cuáles
de ellos son de tipo Serverless (Sin servidor) y cuáles son de tipo Instance (Instancia). También puede ver
el número actual de unidades de capacidad de Aurora (ACU) que cada clúster de base de datos de Aurora
Serverless utiliza. Cada ACU es una combinación de capacidad de procesamiento y memoria.
Para ver los clústeres de base de datos de Aurora Serverless
que creó los clústeres de base de datos Aurora Serverless.
Puede ver el tipo de cada clúster de base de datos en el campo Role (Rol). Los clústeres de base de
datos de Aurora Serverless muestran Serverless para el tipo. Puede consultar la capacidad actual de
un clúster de base de datos Aurora Serverless en el campo Size (Tamaño).
4. Elija el nombre para que el clúster de base de datos de Aurora Serverless DB muestre los detalles.

122
En la pestaña Connectivity & security (Conectividad y seguridad), anote el punto de enlace de la base
de datos, ya que es necesaria la conexión al clúster de base de datos.
Elija la pestaña Configuration (Configuración) para ver la configuración de la capacidad.

123
Se genera un evento de escalado cada vez que un clúster de base de datos se escala para ampliarlo
o para reducirlo, se pone en pausa o se reanuda. Elija la pestaña Logs & events (Registros y eventos)
para ver los eventos recientes. En la imagen siguiente se muestran ejemplos de estos eventos.
También puede monitorizar el clúster de base de datos Aurora Serverless en CloudWatch. En

concreto, puede monitorizar la capacidad asignada al clúster de base de datos utilizando la métrica
ServerlessDatabaseCapacity. También puede monitorizar todas las métricas estándar de
CloudWatch para Aurora, como CPUUtilization, DatabaseConnections, Queries, etc. Para obtener
información sobre cómo monitorizar clústeres de Aurora a través de CloudWatch, consulte Publicación de
registros de Amazon Aurora MySQL en Amazon CloudWatch Logs (p. 662).
Puede hacer que Aurora publica algunos registros de base de datos o todos en CloudWatch.
Seleccione qué registros publicar habilitando los parámetros de configuración como general_log
y slow_query_log en el grupo de parámetros de clúster de base de datos asociado al clúster de
Serverless. A diferencia de los clústeres aprovisionados, los clústeres de Serverless no requieren que
especifique en la configuración del clúster los tipos de registros que cargar en CloudWatch. Los clústeres
de Serverless cargan automáticamente todos los registros disponibles. Para obtener información sobre
la habilitación de los parámetros de configuración del registro para clústeres de Serverless, consulte

124
Uso de la API de datos
Aurora Serverless y grupos de parámetros (p. 106). Para obtener información sobre la supervisión de
clústeres de Aurora a través de CloudWatch, consulte Publicación de registros de Amazon Aurora MySQL
en Amazon CloudWatch Logs (p. 662).
datos. Siga las instrucciones de Conexión a un clúster de base de datos Amazon Aurora (p. 148) para
conectarse al clúster de base de datos Aurora Serverless.
Note
Con Aurora Serverless, no es posible conectarse directamente a instancias de base de datos

específicas en el clúster de base de datos.
Uso de la API de datos para Aurora Serverless

También puede acceder a su clúster de base de datos de Aurora Serverless con la API de datos integrada.
Al utilizar esta API, puede acceder a Aurora Serverless con aplicaciones web basadas en servicios web,
incluidas AWS Lambda, AWS AppSync y AWS Cloud9. Para obtener más información acerca de estas
aplicaciones, consulte los detalles en AWS Lambda, AWS AppSync y AWS Cloud9.
Note
La API de datos solo está actualmente disponible para Aurora MySQL y no para Aurora
PostgreSQL.
La API de datos no requiere una conexión persistente al clúster de base de datos. En su lugar,
proporciona un punto de enlace HTTP seguro e integración con los AWS SDK. Puede usar el punto
de enlace para ejecutar instrucciones SQL sin administrar conexiones. Todas las llamadas a la API
de datos son síncronas. De forma predeterminada, el tiempo de espera de una llamada se agota y
dicha llamada se termina en un minuto si no ha acabado de procesarse. Puede utilizar el parámetro
continueAfterTimeout para seguir ejecutando la instrucción SQL después de que se agote el tiempo
de espera de la llamada.
La API utiliza las credenciales de base de datos almacenadas en AWS Secrets Manager, para que usted
no tenga que transmitir las credenciales en las llamadas a la API. La API también proporciona una forma
más segura de usar AWS Lambda. Le habilita para que obtenga acceso a su clúster de base de datos sin
tener que configurar una función Lambda para obtener acceso a recursos de una Virtual Private Cloud
(VPC). Para obtener más información acerca de AWS Secrets Manager, consulte ¿Qué es AWS Secrets
Manager? en la Guía del usuario de AWS Secrets Manager.
Note
Cuando habilita la API de datos, también puede usar el editor de consultas para Aurora
Serverless. Para obtener más información, consulte Uso del editor de consultas de Aurora
Disponibilidad de la API de datos

La API de datos solo está disponible para clústeres de base de datos de Aurora Serverless compatibles
con MySQL 5.6.
En la tabla siguiente se muestran las regiones de AWS donde la API de datos está disponible actualmente
para Aurora Serverless. Utilice el protocolo HTTPS para obtener acceso a la API de datos de estas
regiones de AWS.
Región Enlace
US East (N. Virginia). rds-data.us-east-1.amazonaws.com

125
Región Enlace
EE.UU. Este (Ohio) rds-data.us-east-2.amazonaws.com
EE.UU. Oeste (Oregón) rds-data.us-west-2.amazonaws.com
UE (Irlanda) rds-data.eu-west-1.amazonaws.com
Asia Pacífico (Tokio) rds-data.ap-northeast-1.amazonaws.com
Autorización de acceso a la API de datos

Para poder obtener acceso a la API de datos, el usuario tiene que estar autorizado. Puede autorizar a
un usuario a obtener acceso a la API de datos, añadiendo la política AmazonRDSDataFullAccess, una
política AWS Identity and Access Management (IAM) definida previamente, a dicho usuario.
También puede crear una política de IAM que conceda acceso a la API de datos. Tras crear la política,
añádala a todos los usuarios que tengan que obtener acceso a la API de datos.
La siguiente política proporciona los permisos mínimos necesarios para que un usuario obtenga acceso a
la API de datos.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "SecretsManagerDbCredentialsAccess",
"Effect": "Allow",
"Action": [
"secretsmanager:GetSecretValue",
"secretsmanager:PutResourcePolicy",
"secretsmanager:PutSecretValue",
"secretsmanager:DeleteSecret",
"secretsmanager:DescribeSecret",
"secretsmanager:TagResource"
],
"Resource": "arn:aws:secretsmanager:*:*:secret:rds-db-credentials/*"
},
{
"Sid": "RDSDataServiceAccess",
"Effect": "Allow",
"Action": [
"secretsmanager:CreateSecret",
"secretsmanager:ListSecrets",
"secretsmanager:GetRandomPassword",
"tag:GetResources",
"rds-data:BatchExecuteStatement",
"rds-data:BeginTransaction",
"rds-data:CommitTransaction",
"rds-data:ExecuteStatement",
"rds-data:RollbackTransaction"
],
"Resource": "*"
}
]
}
Para obtener información acerca de cómo crear una política de IAM, consulte Creación de políticas de IAM
en la Guía del usuario de IAM.

126
Para obtener información sobre cómo añadir una política de IAM a un usuario, consulte Adición y
eliminación de permisos de identidad de IAM en la Guía del usuario de IAM.
Habilitar la API de datos

Para utilizar la API de datos, habilítela para su clúster de base de datos de Aurora Serverless. Puede
habilitar la API de datos cuando modifica el clúster de base de datos.
Consola
Puede habilitar la API de datos utilizando la consola de RDS al modificar un clúster de base de datos de
Aurora Serverless. Para ello, habilite la API de datos en la sección Network & Security (Red y seguridad)
de la consola de RDS.
La siguiente captura de pantalla muestra la Data API (API de datos) habilitada.
Para obtener instrucciones, consulte Modificación de un clúster de base de datos de Aurora

AWS CLI
Cuando modifica un clúster de base de datos de Aurora Serverless ejecutando el comando modify-db-
cluster de la AWS CLI, la API de datos se habilita cuando especifica --enable-http-endpoint.
Para modificar un clúster de base de datos de Aurora Serverless utilizando la AWS CLI
• Llame al comando modify-db-cluster de la CLI y suministre los siguientes valores:
• --db-cluster-identifier: el nombre del clúster de base de datos.

• --enable-http-endpoint
En el siguiente ejemplo, se habilita la API de datos de sample-cluster.
aws rds modify-db-cluster \

--db-cluster-identifier sample-cluster \
--enable-http-endpoint

127
Para Windows:
aws rds modify-db-cluster ^

--db-cluster-identifier sample-cluster ^
--enable-http-endpoint
API de RDS
Cuando modifica un clúster de base de datos de Aurora Serverless ejecutando la operación de API de
RDS ModifyDBCluster, habilita la API de datos estableciendo el valor EnableHttpEndpoint en true.
Almacenamiento de credenciales de base de datos en AWS

Secrets Manager
Al llamar a la API de datos, puede pasar credenciales para el clúster de base de datos de Aurora
Serverless utilizando un secreto en AWS Secrets Manager. Para pasar credenciales mediante este
método, especifique el nombre del secreto o el Nombre de recurso de Amazon (ARN) del secreto.
Para almacenar las credenciales de clúster de base de datos en un secreto
1. Utilice AWS Secrets Manager para crear un secreto que contenga credenciales para el clúster de base
de datos de Aurora.
Para obtener instrucciones, consulte Creación de un secreto básico en la Guía del usuario de AWS
Secrets Manager.
2. Utilice la consola de AWS Secrets Manager para ver los detalles del secreto que ha creado, o ejecute
el comando de la AWS CLI aws secretsmanager describe-secret.
Anote el nombre y el ARN del secreto. Puede utilizarlos en llamadas a la API de datos.
Llamadas a la API de datos

Tras habilitar la API de datos de un clúster de base de datos de Aurora Serverless, puede llamar a la API
de datos o la AWS CLI para que ejecute instrucciones SQL para el clúster de base de datos.
La API de datos proporciona las operaciones siguientes para ejecutar instrucciones SQL.
Acción de API Comando de AWS CLI Descripción

de datos
ExecuteStatement
aws rds-data execute- Ejecuta una instrucción SQL en una base de datos.
statement
BatchExecuteStatement
aws rds-data batch- Ejecuta una instrucción SQL por lotes en una
execute-statement matriz de datos para operaciones de inserción
y actualización masivas. Puede ejecutar una
instrucción DML con una matriz de conjuntos
de parámetros. Una instrucción SQL por lotes
puede proporcionar una mejora significativa del
rendimiento en comparación con las instrucciones
de actualización e inserción individuales.

128
Puede ejecutar ambas operaciones para ejecutar una instrucción SQL de forma atómica, o bien puede
ejecutarlas en una sola transacción. La API de datos proporciona las operaciones siguientes para dar
soporte a las transacciones.
Acción de API Comando de AWS CLI Descripción

de datos
BeginTransaction
aws rds-data begin- Inicia una transacción SQL.
transaction
CommitTransaction
aws rds-data commit- Finaliza una transacción SQL y confirma los
transaction cambios.
RollbackTransaction
aws rds-data rollback- Ejecuta una restauración de una transacción.
transaction
Las operaciones para ejecutar instrucciones SQL y darle soporte a transacciones tienen los siguientes
parámetros de la API de datos y opciones de AWS CLI comunes. Algunas operaciones dan soporte a otros
parámetros u opciones.
Parámetro Opción de comando de la Obligatorio Descripción

de acción AWS CLI
de la API de
datos
resourceArn --resource-arn Sí Nombre de recurso de Amazon (ARN)

del clúster de base de datos de Aurora
Serverless.
secretArn --secret-arn Sí Nombre o ARN del secreto que permite el

acceso al clúster de base de datos.
Puede usar parámetros en las llamadas a la API de datos para ExecuteStatement y

BatchExecuteStatement, y cuando ejecuta los comandos de la AWS CLI execute-statement y
batch-execute-statement. Para utilizar un parámetro, especifique un par de nombre-valor en el tipo
de datos SqlParameter. Especifique el valor con el tipo de datos Field. En la tabla siguiente se mapean
los tipos de datos de Java Database Connectivity (JDBC) con los tipos de datos que especifica en las
llamadas a la API de datos.
Tipo de datos JDBC Tipo de datos de la API de datos
INTEGER, TINYINT, SMALLINT, BIGINT LONG
FLOAT, REAL, DOUBLE DOUBLE
DECIMAL LONG si la escala es 0, DOUBLE para otros valores
BOOLEAN, BIT BOOLEAN
BLOB, BINARY, LONGVARBINARY, VARBINARY BLOB
CLOB STRING
Otros tipos (incluidos los tipos relacionados con la STRING

fecha y hora)

129
Temas
• Llamadas a la API de datos con la AWS CLI (p. 130)
• Llamadas a la API de datos desde una aplicación Python (p. 137)
• Llamadas a la API de datos desde una aplicación Java (p. 140)
Llamadas a la API de datos con la AWS CLI

Puede llamar a la API de datos utilizando la AWS Command Line Interface (AWS CLI).
En los siguientes ejemplos se utiliza la AWS CLI para la API de datos. Para obtener más información,
consulte la referencia de AWS Command Line Interface de la API de datos.
En cada ejemplo, sustituya el ARN del clúster de base de datos por el ARN de su clúster de base de datos
de Aurora Serverless. Reemplace también el ARN del secreto por el ARN del secreto de AWS Secrets
Manager que permite obtener acceso al clúster de base de datos.
Temas
• Inicio de una transacción SQL (p. 130)
• Ejecución de una instrucción SQL (p. 131)
• Ejecución de una instrucción SQL por lotes en una matriz de datos (p. 134)
• Confirmación de una transacción SQL (p. 135)
• Restauración de una transacción SQL (p. 136)
Inicio de una transacción SQL
Puede iniciar una transacción SQL ejecutando el comando de la CLI aws rds-data begin-
transaction. La llamada devuelve un identificador de transacción.
Important
Una transacción puede ejecutarse durante un máximo de 24 horas. Una vez que hayan
transcurrido 24 horas, la transacción se terminará y se revertirá automáticamente.
El tiempo de la transacción se agota si no hay llamadas que usen su ID de transacción en
un período de tres minutos. Si una transacción agota su tiempo antes de que se confirme, se
revertirá automáticamente.
Las instrucciones DDL contenidas en una transacción generan una confirmación implícita.
Recomendamos que ejecute cada instrucción DDL en un comando execute-statement
independiente con la opción --continue-after-timeout.
Además de las opciones habituales, especifique la opción siguiente:
• --database (opcional): el nombre de la base de datos.
Por ejemplo, el comando de la CLI siguiente inicia una transacción SQL.
aws rds-data begin-transaction --resource-arn "arn:aws:rds:us-

east-1:123456789012:cluster:mydbcluster" \
--database "mydb" --secret-arn "arn:aws:secretsmanager:us-
east-1:123456789012:secret:mysecret"
Para Windows:

130
aws rds-data begin-transaction --resource-arn "arn:aws:rds:us-

east-1:123456789012:cluster:mydbcluster" ^
east-1:123456789012:secret:mysecret"
A continuación se muestra un ejemplo de respuesta.
{
"transactionId": "ABC1234567890xyz"
}
Ejecución de una instrucción SQL

Puede ejecutar una instrucción SQL usando el comando de la CLI aws rds-data execute-
statement.
Puede ejecutar la instrucción SQL en una transacción especificando el identificador de transacción con la
opción --transaction-id. Puede iniciar una transacción ejecutando el comando de la CLI aws rds-
data begin-transaction. Puede finalizar y confirmar una transacción ejecutando el comando de la
CLI aws rds-data commit-transaction.
Important
Si no especifica la opción --transaction-id, los cambios que se generan a partir de la

llamada se confirman automáticamente.
Además de las opciones habituales, especifique las opciones siguientes:
• --sql (obligatorio): instrucción SQL que debe ejecutarse en el clúster de base de datos.
• --transaction-id (opcional): identificador de una transacción que se inició mediante el comando
begin-transaction de la CLI. Especifique el ID de la transacción en la que desea incluir la
instrucción SQL.
• --parameters (opcional): parámetros de la instrucción SQL.
• --include-result-metadata | --no-include-result-metadata (opcional): valor que indica
si deben incluirse o no metadatos en los resultados. El valor predeterminado es --include-result-
metadata.
• --continue-after-timeout | --no-continue-after-timeout (opcional): valor que indica
si se seguirá o no ejecutando la instrucción después de que se agote el tiempo de la llamada. El valor
predeterminado es --no-continue-after-timeout.
Para las instrucciones en lenguaje de definición de datos (DDL), recomendamos seguir ejecutando la
instrucción después de que se agote el tiempo de la llamada, a fin de evitar errores y la posibilidad de
que las estructuras de datos se dañen.
El clúster de base de datos devuelve una respuesta para la llamada.

Note
El límite de tamaño de respuesta es de 1 MB o 1000 registros. Si la respuesta devuelve más de 1

MB de datos de respuesta o más de 1000 registros, se terminará.
Por ejemplo, el siguiente comando de la CLI ejecuta una única instrucción SQL y especifica --no-
include-result-metadata para omitir los metadatos en los resultados.

131
aws rds-data execute-statement --resource-arn "arn:aws:rds:us-

east-1:123456789012:secret:mysecret" \
--sql "select * from mytable" --no-include-result-metadata
Para Windows:

east-1:123456789012:secret:mysecret" ^
--sql "select * from mytable" --no-include-result-metadata
{
"numberOfRecordsUpdated": 0,
"records": [
[
{
"longValue": 1
},
{
"stringValue": "ValueOne"
}
],
[
{
"longValue": 2
},
{
"stringValue": "ValueTwo"
}
],
[
{
"longValue": 3
},
{
"stringValue": "ValueThree"
}
]
]
}
El siguiente comando de la CLI ejecuta una única instrucción SQL en una transacción mediante la opción
--transaction-id.


132

--sql "update mytable set quantity=5 where id=201" --transaction-id "ABC1234567890xyz"
Para Windows:

--sql "update mytable set quantity=5 where id=201" --transaction-id "ABC1234567890xyz"
{
"numberOfRecordsUpdated": 1
}
El siguiente comando de la CLI ejecuta una única instrucción SQL con parámetros.

--sql "insert into mytable values (:id, :val)" --parameters "[{\"name\": \"id\", \"value\":
{\"longValue\": 1}},{\"name\": \"val\", \"value\": {\"stringValue\": \"value1\"}}]"
Para Windows:

--sql "insert into mytable values (:id, :val)" --parameters "[{\"name\": \"id\", \"value\":
{\"longValue\": 1}},{\"name\": \"val\", \"value\": {\"stringValue\": \"value1\"}}]"
{
}
El siguiente comando de la CLI ejecuta una instrucción SQL de lenguaje de definición de datos (DDL). La
instrucción DDL cambia el nombre de la columna job por la columna role.

133
Important
Para las instrucciones DDL, recomendamos seguir ejecutando la instrucción después de que se
agote el tiempo de la llamada. Cuando se termina una instrucción DDL antes de que acabe de
ejecutarse, pueden generarse errores y es posible que las estructuras de datos se dañen. Para
seguir ejecutando una instrucción después de que se agote el tiempo de una llamada, especifique
la opción --continue-after-timeout.

--sql "alter table mytable change column job role varchar(100)" --continue-after-timeout
Para Windows:

--sql "alter table mytable change column job role varchar(100)" --continue-after-timeout
{
"generatedFields": [],
}
Ejecución de una instrucción SQL por lotes en una matriz de datos

Puede ejecutar una instrucción SQL por lotes en una matriz de datos ejecutando el comando aws rds-
data batch-execute-statement de la CLI. Puede utilizar este comando para realizar una operación
de actualización o importación masiva.
Puede ejecutar la instrucción SQL en una transacción especificando el identificador de transacción con la
opción --transaction-id. Puede iniciar una transacción ejecutando el comando de la CLI aws rds-
data begin-transaction. Puede finalizar y confirmar una transacción mediante el comando aws
rds-data commit-transaction de la CLI.
Important
Si no especifica la opción --transaction-id, los cambios que se generan a partir de la
llamada se confirman automáticamente.
Además de las opciones habituales, especifique las opciones siguientes:
• --sql (obligatorio): instrucción SQL que debe ejecutarse en el clúster de base de datos.
• --transaction-id (opcional): identificador de una transacción que se inició mediante el comando
begin-transaction de la CLI. Especifique el ID de la transacción en la que desea incluir la
instrucción SQL.
• --parameter-set (opcional): los conjuntos de parámetros para la operación por lotes.

134
El clúster de base de datos devuelve una respuesta a la llamada.

Note
El límite de tamaño de respuesta es de 1 MB o 1000 registros. Si la respuesta devuelve más de 1
MB de datos de respuesta o más de 1000 registros, se terminará.
Por ejemplo, el siguiente comando de la CLI ejecuta una instrucción SQL por lotes en una matriz de datos
con un conjunto de parámetros.
aws rds-data batch-execute-statement --resource-arn "arn:aws:rds:us-

--sql "insert into mytable values (:id, :val)" \
--parameter-sets "[[{\"name\": \"id\", \"value\": {\"longValue\": 1}},{\"name\": \"val\",
\"value\": {\"stringValue\": \"ValueOne\"}}],
[{\"name\": \"id\", \"value\": {\"longValue\": 2}},{\"name\": \"val\", \"value\":
{\"stringValue\": \"ValueTwo\"}}],
{\"stringValue\": \"ValueThree\"}}]]"
Para Windows:
aws rds-data batch-execute-statement --resource-arn "arn:aws:rds:us-

--sql "insert into mytable values (:id, :val)" ^
--parameter-sets "[[{\"name\": \"id\", \"value\": {\"longValue\": 1}},{\"name\": \"val\",
\"value\": {\"stringValue\": \"ValueOne\"}}],
{\"stringValue\": \"ValueTwo\"}}],
{\"stringValue\": \"ValueThree\"}}]]"
Note
No incluya saltos de línea en la opción --parameter-sets.
Confirmación de una transacción SQL

Con el comando aws rds-data commit-transaction de la CLI, puede finalizar una transacción SQL
que inició con aws rds-data begin-transaction y confirmar los cambios.
• --transaction-id (obligatorio): identificador de una transacción que se inició ejecutando el comando

begin-transaction de la CLI. Especifique el ID de la transacción que desea finalizar y confirmar.
Por ejemplo, el siguiente comando de la CLI finaliza una transacción SQL y confirma los cambios.

135
aws rds-data commit-transaction --resource-arn "arn:aws:rds:us-

--secret-arn "arn:aws:secretsmanager:us-east-1:123456789012:secret:mysecret" \
--transaction-id "ABC1234567890xyz"
Para Windows:
aws rds-data commit-transaction --resource-arn "arn:aws:rds:us-

--secret-arn "arn:aws:secretsmanager:us-east-1:123456789012:secret:mysecret" ^
{
"transactionStatus": "Transaction Committed"
}
Restauración de una transacción SQL

Con el comando aws rds-data rollback-transaction de la CLI, puede revertir una transacción
SQL que inició con aws rds-data begin-transaction. Si revierte una transacción, cancelará sus
cambios.
Important
Si el ID de la transacción ha vencido, la transacción se revertirá automáticamente. En este caso,

un comando aws rds-data rollback-transaction que especifique el ID de transacción
que ha vencido devolverá un error.
• --transaction-id (obligatorio): identificador de una transacción que se inició ejecutando el comando

begin-transaction de la CLI. Especifique el ID de la transacción que desea revertir.
Por ejemplo, el comando de la AWS CLI siguiente revierte una transacción SQL.
aws rds-data rollback-transaction --resource-arn "arn:aws:rds:us-

--secret-arn "arn:aws:secretsmanager:us-east-1:123456789012:secret:mysecret" \
Para Windows:
aws rds-data rollback-transaction --resource-arn "arn:aws:rds:us-

--secret-arn "arn:aws:secretsmanager:us-east-1:123456789012:secret:mysecret" ^

136
{
"transactionStatus": "Rollback Complete"
}
Llamadas a la API de datos desde una aplicación Python

Puede llamar a la API de datos desde una aplicación Python.
En los ejemplos siguientes se usa el AWS SDK para Python (Boto). Para obtener más información acerca
de Boto, consulte la documentación de AWS SDK para Python (Boto 3).
En cada ejemplo, sustituya el nombre de recurso de Amazon (ARN) del clúster de base de datos por el
ARN de su clúster de base de datos de Aurora Serverless. Reemplace también el ARN del secreto por el
ARN del secreto de AWS Secrets Manager que permite obtener acceso al clúster de base de datos.
Temas
• Ejecución de una consulta SQL (p. 137)
• Ejecución de una instrucción SQL DML (p. 138)
• Ejecución de una transacción SQL (p. 139)
Ejecución de una consulta SQL

Puede ejecutar una instrucción SELECT y recopilar los resultados con una aplicación Python.
En el ejemplo siguiente, se ejecuta una consulta SQL.
import boto3
rdsData = boto3.client('rds-data')
cluster_arn = 'arn:aws:rds:us-east-1:123456789012:cluster:mydbcluster'
secret_arn = 'arn:aws:secretsmanager:us-east-1:123456789012:secret:mysecret'
response1 = rdsData.execute_statement(
resourceArn = cluster_arn,
secretArn = secret_arn,
database = 'mydb',
sql = 'select * from employees limit 3')
print (response1['records'])
[
[
{
'longValue': 1
},
{
'stringValue': 'ROSALEZ'
},
{
'stringValue': 'ALEJANDRO'
},
{
'stringValue': '2016-02-15 04:34:33.0'
}

137
],
[
{
'longValue': 1
},
{
'stringValue': 'DOE'
},
{
'stringValue': 'JANE'
},
{
'stringValue': '2014-05-09 04:34:33.0'
}
],
[
{
'longValue': 1
},
{
'stringValue': 'STILES'
},
{
'stringValue': 'JOHN'
},
{
'stringValue': '2017-09-20 04:34:33.0'
}
]
]
Ejecución de una instrucción SQL DML

Puede ejecutar una instrucción de lenguaje de manipulación de datos (DML) para insertar, actualizar o
eliminar datos en su base de datos. También puede utilizar parámetros en instrucciones DML.
Important
Si una llamada no forma parte de una transacción porque no incluye el parámetro
transactionID, los cambios que se generen a partir de la llamada se confirmarán
automáticamente.
En el ejemplo siguiente se ejecuta una instrucción SQL de inserción y se utilizan parámetros.
import boto3
database = 'mydb',
sql = 'insert into employees(first_name, last_name)
VALUES(:firstname, :lastname)')
param1 = {'name':'firstname', 'value':{'stringValue': 'JACKSON'}}
param2 = {'name':'lastname', 'value':{'stringValue': 'MATEO'}}
paramSet = [param1, param2]

138
database = 'mydb',
parameters = paramSet,
sql = 'insert into employees(first_name, last_name)
VALUES(:firstname, :lastname)')
'numberOfRecordsUpdated': 1}
response2['numberOfRecordsUpdated']
1
Ejecución de una transacción SQL

Puede iniciar una transacción SQL, ejecutar una o varias instrucciones SQL y luego confirmar los cambios
con una aplicación Python.
Important
Si no especifica un ID de transacción, los cambios que se generen a partir de la llamada se
confirmarán automáticamente.
En el ejemplo siguiente se ejecuta una transacción SQL que inserta una fila en una tabla.
import boto3
tr = rdsData.begin_transaction(
database = 'mydb')
database = 'mydb',
sql = 'insert into employees(first_name, last_name) values('XIULAN', 'WANG')',
transactionId = tr)
cr = rdsData.commit_transaction(
transactionId = tr)
cr['transactionStatus']
'Transaction Committed'
response3['numberOfRecordsUpdated']
1
Note
Si ejecuta una instrucción de lenguaje de definición de datos (DDL), recomendamos que siga
ejecutando la instrucción después de que se agote el tiempo de la llamada. Cuando se termina

139
una instrucción DDL antes de que acabe de ejecutarse, pueden generarse errores y es posible
que las estructuras de datos se dañen. Para seguir ejecutando una instrucción después de que se
agote el tiempo de una llamada, establezca el parámetro continueAfterTimeout en true.
Llamadas a la API de datos desde una aplicación Java

Puede llamar a la API de datos desde una aplicación Java.
En los ejemplos siguientes se usa el AWS SDK para Java. Para obtener más información, consulte la AWS
SDK for Java Developer Guide.
En cada ejemplo, sustituya el nombre de recurso de Amazon (ARN) del clúster de base de datos por el
ARN de su clúster de base de datos de Aurora Serverless. Reemplace también el ARN del secreto por el
ARN del secreto de AWS Secrets Manager que permite obtener acceso al clúster de base de datos.
Temas
• Ejecución de una consulta SQL (p. 140)
• Ejecución de una transacción SQL (p. 141)
• Ejecución de una operación SQL por lotes (p. 142)
Ejecución de una consulta SQL
Puede ejecutar una instrucción SELECT y recopilar los resultados con una aplicación Java.
En el ejemplo siguiente, se ejecuta una consulta SQL.
package com.amazonaws.rdsdata.examples;
import com.amazonaws.services.rdsdata.AWSRDSData;
import com.amazonaws.services.rdsdata.AWSRDSDataClient;
import com.amazonaws.services.rdsdata.model.ExecuteStatementRequest;
import com.amazonaws.services.rdsdata.model.ExecuteStatementResult;
import com.amazonaws.services.rdsdata.model.Field;
import java.util.List;
public class FetchResultsExample {

public static final String RESOURCE_ARN = "arn:aws:rds:us-
east-1:123456789012:cluster:mydbcluster";
public static final String SECRET_ARN = "arn:aws:secretsmanager:us-
east-1:123456789012:secret:mysecret";
public static void main(String[] args) {

AWSRDSData rdsData = AWSRDSDataClient.builder().build();
ExecuteStatementRequest request = new ExecuteStatementRequest()

.withResourceArn(RESOURCE_ARN)
.withSecretArn(SECRET_ARN)
.withDatabase("mydb")
.withSql("select * from mytable");
ExecuteStatementResult result = rdsData.executeStatement(request);
for (List<Field> fields: result.getRecords()) {

String stringValue = fields.get(0).getStringValue();
long numberValue = fields.get(1).getLongValue();
System.out.println(String.format("Fetched row: string = %s, number = %d",

stringValue, numberValue));
}

140
}
}
Ejecución de una transacción SQL
Puede iniciar una transacción SQL, ejecutar una o varias instrucciones SQL y luego confirmar los cambios
con una aplicación Java.
Important
En el ejemplo siguiente, se ejecuta una transacción SQL.
import com.amazonaws.services.rdsdata.model.BeginTransactionRequest;
import com.amazonaws.services.rdsdata.model.BeginTransactionResult;
import com.amazonaws.services.rdsdata.model.CommitTransactionRequest;
import com.amazonaws.services.rdsdata.model.ExecuteStatementRequest;
public class TransactionExample {


BeginTransactionRequest beginTransactionRequest = new BeginTransactionRequest()

.withDatabase("mydb");
BeginTransactionResult beginTransactionResult =
rdsData.beginTransaction(beginTransactionRequest);
String transactionId = beginTransactionResult.getTransactionId();
ExecuteStatementRequest executeStatementRequest = new ExecuteStatementRequest()

.withTransactionId(transactionId)
.withSql("INSERT INTO test_table VALUES ('hello world!')");
rdsData.executeStatement(executeStatementRequest);
CommitTransactionRequest commitTransactionRequest = new CommitTransactionRequest()

.withTransactionId(transactionId)
.withSecretArn(SECRET_ARN);
rdsData.commitTransaction(commitTransactionRequest);
}
}

141
Note
Si ejecuta una instrucción de lenguaje de definición de datos (DDL), recomendamos que siga
ejecutando la instrucción después de que se agote el tiempo de la llamada. Cuando se termina
una instrucción DDL antes de que acabe de ejecutarse, pueden generarse errores y es posible
que las estructuras de datos se dañen. Para seguir ejecutando una instrucción después de que se
agote el tiempo de una llamada, establezca el parámetro continueAfterTimeout en true.
Ejecución de una operación SQL por lotes

Puede ejecutar operaciones de inserción y actualización masivas en una matriz de datos, con una
aplicación Java. Puede ejecutar una instrucción DML con una matriz de conjuntos de parámetros.
Important
En el siguiente ejemplo se ejecuta una operación de inserción por lotes.
import com.amazonaws.services.rdsdata.model.BatchExecuteStatementRequest;
import com.amazonaws.services.rdsdata.model.Field;
import com.amazonaws.services.rdsdata.model.SqlParameter;
import java.util.Arrays;
public class BatchExecuteExample {


BatchExecuteStatementRequest request = new BatchExecuteStatementRequest()

.withDatabase("test")
.withSql("INSERT INTO test_table2 VALUES (:string, :number)")
.withParameterSets(Arrays.asList(
Arrays.asList(
new SqlParameter().withName("string").withValue(new
Field().withStringValue("Hello")),
new SqlParameter().withName("number").withValue(new
Field().withLongValue(1L))
),
Arrays.asList(
new SqlParameter().withName("string").withValue(new
Field().withStringValue("World")),
new SqlParameter().withName("number").withValue(new
Field().withLongValue(2L))
)
));
rdsData.batchExecuteStatement(request);
}
}

142
Solución de problemas de la API de datos

Use las siguientes secciones, tituladas con mensajes de error comunes, para ayudar a solucionar
problemas que tenga con la API de datos.
Note
Si tiene preguntas o comentarios relacionados con la API de datos, envíe un correo electrónico a
Rds-data-api-feedback@amazon.com.
Temas
• No se ha encontrado la transacción <transaction_ID> (p. 143)
• El paquete de la consulta es demasiado grande (p. 143)
• La respuesta de la consulta ha superado el límite del número de registros (p. 143)
• Límite de tamaño superado de respuesta de base de datos (p. 143)
• HttpEndpoint no está habilitado para el clúster <cluster_ID> (p. 144)
No se ha encontrado la transacción <transaction_ID>

En este caso, el ID de transacción especificado en la API de datos no se ha podido encontrar. La causa de
este problema casi siempre es uno de los siguientes:
• El ID de transacción especificado no se creó con una llamada BeginTransaction.

• El ID de transacción especificado ha caducado.
Una transacción caduca si ninguna llamada utiliza el ID de transacción en un plazo de tres minutos.
Para resolver el problema, asegúrese de que su llamada tenga un ID de transacción válido. Asegúrese
también de que cada transacción se realice antes de que transcurran tres minutos con respecto a la última.
Para obtener más información acerca de la ejecución de transacciones, consulte Llamadas a la API de
datos (p. 128).
El paquete de la consulta es demasiado grande

En este caso, el conjunto de resultados devuelto para una fila era demasiado grande. El límite de tamaño
de la API de datos es 64 KB por fila en el conjunto de resultados devuelto por la base de datos.
Para solventar este problema, asegúrese de que cada fila en un conjunto de resultados sea 64 KB o
menos.
La respuesta de la consulta ha superado el límite del número de registros

En este caso, el número de filas del conjunto de resultados devuelto era demasiado grande. El límite de la
API de datos es 1000 filas en el conjunto de resultados devuelto por la base de datos.
Para resolver este problema, asegúrese de que las llamada a la API de datos devuelvan 1000 filas o
menos. Si necesita devolver más de 1000 filas, puede usar varias llamadas ExecuteStatement con la
cláusula LIMIT en la consulta.
Para obtener más información acerca de la cláusula LIMIT, consulte Sintáxis de SELECT Syntax en la
documentación de MySQL.
Límite de tamaño superado de respuesta de base de datos

En este caso, el tamaño del conjunto de resultados devuelto por la base de datos era demasiado grande.
El límite de la API de datos es 1 MB en el conjunto de resultados devuelto por la base de datos.

143
Uso del editor de consultas
Para resolver este problema, asegúrese de que las llamada a la API de datos devuelvan 1 MB o menos. Si
necesita devolver más de 1 MB, puede usar varias llamadas ExecuteStatement con la cláusula LIMIT
en la consulta.
Para obtener más información acerca de la cláusula LIMIT, consulte Sintáxis de SELECT Syntax en la
HttpEndpoint no está habilitado para el clúster <cluster_ID>

La causa de este problema casi siempre es uno de los siguientes:
• The API de datos no está habilitada para el clúster de base de datos de Aurora Serverless. Para utilizar
la API de datos con un clúster de base de datos Aurora Serverless, la API de datos debe estar habilitada
para el clúster de base de datos.
• Se cambió el nombre del clúster de base de datos después de que la API de datos se habilitara para él.
Si la API de datos no se ha habilitado para el clúster de base de datos, habilítela.
Si se cambió el nombre del clúster de base de datos después de que se habilitara la API de datos para el
clúster de base de datos, deshabilite la API de datos y, a continuación, habilítela de nuevo.
Para obtener más información sobre la habilitación de la API de datos, consulte Habilitar la API de
datos (p. 127).
Uso del editor de consultas de Aurora Serverless

Con el editor de consultas para Aurora Serverless, puede ejecutar consultas SQL en la consola de RDS.
Puede ejecutar cualquier instrucción SQL válida en el clúster de base de datos de Aurora Serverless,
incluidas las instrucciones de manipulación de datos y de definición de datos.
Note
El editor de consultas solo está actualmente disponible para Aurora MySQL y no para Aurora
PostgreSQL.
El editor de consultas requiere un clúster de base de datos de Aurora Serverless con la API de
datos habilitada. Para obtener más información acerca de cómo crear un clúster de base de datos
de Aurora Serverless con la API de datos habilitada, consulte Uso de la API de datos para Aurora
Autorizar el acceso al editor de consultas

Para ejecutar consultas en el editor de consultas, el usuario debe estar autorizado. Puede
autorizar a un usuario para que ejecute consultas en el editor de consultas añadiendo la política
AmazonRDSDataFullAccess, una política de AWS Identity and Access Management (IAM) predefinida, a
dicho usuario.
También puede crear una política de IAM que conceda acceso al editor de consultas. Tras crear la política,
añádala a cada usuario que necesite acceder al editor de consultas.
La siguiente política proporciona los permisos mínimos necesarios para que un usuario acceda al editor de
consultas.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "QueryEditor0",
"Effect": "Allow",

144
"Action": [
"secretsmanager:GetSecretValue",
"secretsmanager:PutResourcePolicy",
"secretsmanager:PutSecretValue",
"secretsmanager:DeleteSecret",
"secretsmanager:DescribeSecret",
"secretsmanager:TagResource"
],
"Resource": "arn:aws:secretsmanager:*:*:secret:rds-db-credentials/*"
},
{
"Sid": "QueryEditor1",
"Effect": "Allow",
"Action": [
"secretsmanager:GetRandomPassword",
"tag:GetResources",
"secretsmanager:CreateSecret",
"secretsmanager:ListSecrets",
"dbqms:CreateFavoriteQuery",
"dbqms:DescribeFavoriteQueries",
"dbqms:UpdateFavoriteQuery",
"dbqms:DeleteFavoriteQueries",
"dbqms:GetQueryString",
"dbqms:CreateQueryHistory",
"dbqms:UpdateQueryHistory",
"dbqms:DeleteQueryHistory",
"dbqms:DescribeQueryHistory",
"rds-data:BatchExecuteStatement",
"rds-data:BeginTransaction",
"rds-data:CommitTransaction",
"rds-data:ExecuteStatement",
"rds-data:RollbackTransaction"
],
"Resource": "*"
}
]
}
Para obtener información sobre cómo crear una política de IAM, consulte Creación de políticas de IAM en
la Guía del usuario de AWS Identity and Access Management.
Para obtener información sobre cómo añadir una política de IAM a un usuario, consulte Adición y
eliminación de permisos de identidad de IAM en la Guía del usuario de AWS Identity and Access
Management.
Ejecución de consultas en el editor de consultas

Puede ejecutar instrucciones SQL en un clúster de base de datos de Aurora Serverless en el editor de
consultas.
Para ejecutar una consulta en el editor de consultas
que creó los clústeres de base de datos Aurora Serverless a los que quiera consultar.
4. Elija el clúster de base de datos de Aurora Serverless para el que desee ejecutar consultas SQL.
5. En Actions (Acciones), seleccione Query (Consultar). Si no se ha conectado aún a la base de datos,
se abrirá la página Connect to database (Conectar a la base de datos).

145
6. Introduzca la información siguiente:
a. Para Database instance or cluster (Clúster o instancia de base de datos), elija el clúster de base
de datos de Aurora Serverless en el que desee ejecutar consultas SQL.
b. En Database username (Nombre de usuario de base de datos), seleccione el nombre de usuario
del usuario de la base de datos al que conectarse o elija Add new database credentials (Añadir
nuevas credenciales de base de datos). Si elige Add new database credentials (Añadir nuevas
credenciales de base de datos), especifique el nombre de usuario de las nuevas credenciales de
base de datos en Enter database username (Introducir nombre de usuario de base de datos).
c. En Enter database password (Introducir contraseña de base de datos), escriba la contraseña para
el usuario de la base de datos que ha elegido.
d. En la última casilla, introduzca el nombre de la base de datos o esquema que quiera usar para el
clúster de base de datos de Aurora.
e. Seleccione Connect to database (Conectar a base de datos).
Note
Si su conexión se establece correctamente, la información de conexión y autenticación

se almacenará en AWS Secrets Manager. No tendrá que volver a introducir la
información de conexión de nuevo.
7. En el editor de consultas, introduzca la consulta SQL que desea ejecutar en la base de datos.
146
Cada instrucción SQL puede confirmarse automáticamente, o bien puede ejecutar instrucciones SQL
en un script, como parte de una transacción. Para controlar este comportamiento, seleccione el icono
de engranaje que se encuentra en la ventana de consulta.
Se visualizará la ventana Query Editor Settings (Configuración del editor de consultas).

147
Conexión a un clúster de base de datos
Si elige Auto-commit (Confirmación automática), todas las instrucciones SQL se confirmarán

automáticamente. Si elige Transaction (Transacción), puede ejecutar un grupo de instrucciones
en un script y no se confirmarán automáticamente. Si se establece Transaction (Transacción), las
instrucciones del grupo se confirmarán cuando elija Run (Ejecutar). Por otra parte, puede elegir parar
un script que se está ejecutando si se produce un error, habilitando Stop on error (Parar al producirse
un error).
Note
En un grupo de instrucciones, las instrucciones de lenguaje de definición de datos (DDL)
pueden hacer que las instrucciones de lenguaje de manipulación de datos (DML) anteriores
se confirmen. También puede incluir instrucciones COMMIT y ROLLBACK en un grupo de
instrucciones de un script.
Después de elegir las opciones en la ventana Query Editor Settings (Configuración del editor de
consultas), elija Save (Guardar).
8. Elija Run (Ejecutar) o pulse Ctrl+Intro, y el editor de consultas mostrará los resultados de su consulta.
Tras ejecutar la consulta, guárdela en Saved queries (Consultas guardadas) seleccionando Save
(Guardar).
Exporte los resultados de la consulta al formato de hoja de cálculo seleccionando Export to csv
(Exportar a csv).
Puede encontrar, editar y volver a ejecutar consultas anteriores. Para ello, seleccione la pestaña Recent
(Reciente) o la pestaña Saved queries (Consultas guardadas), seleccione el texto de la consulta y después
elija Run (Ejecutar).
Para cambiar la base de datos, elija Change database (Cambiar base de datos).
Conexión a un clúster de base de datos Amazon

Aurora
Puede conectarse a una instancia de base de datos de un clúster de base de datos de Amazon Aurora con
las mismas herramientas que utiliza para conectarse a una base de datos de MySQL o PostgreSQL. Como
parte de este proceso, utiliza la misma clave pública para conexiones de Capa de conexión segura (SSL).

148
Aurora MySQL
Puede usar el punto de enlace y la información de puerto de la instancia principal o las réplicas de Aurora
del clúster de base de datos Aurora en la cadena de conexión de cualquier script, utilidad o aplicación que
se conecte a una instancia de base de datos MySQL o PostgreSQL. En la cadena de conexión, especifique
la dirección DNS del punto de enlace de la instancia principal o la réplica de Aurora como parámetro del
host. Especifique el número de puerto del punto de enlace como parámetro del puerto.

Aurora MySQL
Para autenticarse en el clúster de base de datos Aurora MySQL, puede usar la autenticación con nombre
de usuario y contraseña de MySQL o la autenticación de base de datos AWS Identity and Access
Management (IAM). Para obtener más información sobre el uso de la autenticación con nombre de usuario
y contraseña de MySQL, consulte Administración de cuentas de usuario en la documentación de MySQL.
Para obtener más información sobre cómo usar la autenticación de base de datos de IAM, consulte
Autenticación de bases de datos de IAM (p. 180).
Cuando tenga una conexión a su clúster de base de datos Amazon Aurora con compatibilidad con la
versión 5.6 de MySQL, podrá ejecutar cualquier comando de SQL que sea compatible con la versión
5.6 de MySQL. Para obtener más información sobre la sintaxis SQL de MySQL 5.6, consulte MySQL 5.6
Reference Manual.
Cuando tenga una conexión a su clúster de base de datos Amazon Aurora con compatibilidad con la
versión 5.7 de MySQL, podrá ejecutar cualquier comando de SQL que sea compatibles con la versión
5.7 de MySQL. Para obtener más información sobre la sintaxis SQL de MySQL 5.7, consulte MySQL 5.7
Reference Manual. Para obtener información sobre las limitaciones que se aplican a Aurora MySQL 5.7,
consulte Comparación de Aurora MySQL 5.7 y MySQL 5.7 (p. 498).
Note
Para obtener una guía detallada y práctica sobre la conexión a un clúster de base de datos
Amazon Aurora MySQL puede consultar el manual Aurora Connection Management.
En la vista de detalles del clúster de base de datos, puede encontrar el punto de enlace de clúster,
que se puede usar en la cadena de conexión de MySQL. El punto de enlace se compone del nombre
de dominio y el puerto del clúster de base de datos. Por ejemplo, si un valor de punto de enlace es
mycluster.cluster-123456789012.us-east-1.rds.amazonaws.com:3306, debe especificar los
siguientes valores en una cadena de conexión de MySQL:
• Para el host o el nombre del host, especifique mycluster.cluster-123456789012.us-

east-1.rds.amazonaws.com
• Para el puerto, especifique 3306 o el valor del puerto que utilizó al crear el clúster de base de datos
El punto de enlace de clúster le conecta a la instancia principal del clúster de base de datos. Puede realizar
operaciones de lectura y escritura con el punto de enlace de clúster. El clúster de base de datos también
puede tener hasta 15 réplicas de Aurora que admiten acceso de solo lectura a los datos de su clúster
de base de datos. La instancia principal y cada réplica de Aurora tienen un punto de enlace único que
es independiente del punto de enlace del clúster y que permite establecer conexión directamente con
una instancia de base de datos concreta del clúster. El punto de conexión del clúster apunta siempre a la
instancia principal. Si se produce un error en la instancia principal y se reemplaza, el punto de enlace del
clúster apunta a la nueva instancia principal.
Note
Si el clúster es un clúster de base de datos de Aurora Serverless, solo puede conectarse a su

punto de enlace de base de datos. Para obtener más información, consulte Uso de Amazon

149
Aurora MySQL
Para ver el punto de enlace del clúster, elija Databases (Bases de datos) en la consola de Amazon RDS y
elija el clúster de base de datos para mostrar los detalles del clúster de base de datos.
Utilidades de conexión para Aurora MySQL

A continuación se indican algunas de las utilidades de conexión que puede usar:
• Línea de comando: puede conectarse a un clúster de base de datos Amazon Aurora usando
herramientas como la utilidad de línea de comando de MySQL. Para obtener más información acerca del
uso de la utilidad de MySQL, consulte mysql - The MySQL Command Line Tool en la documentación de
MySQL.
• Interfaz gráfica de usuario (GUI): puede usar la utilidad MySQL Workbench para conectarse por medio
de una interfaz de usuario. Para obtener más información, consulte la página Download MySQL
Workbench.
• Aplicaciones: puede usar la utilidad MariaDB Connector/J para conectar sus aplicaciones a su clúster
de base de datos Aurora. Para obtener más información, consulte la página de descargas de MariaDB
Connector/J.
Note
Si utiliza la utilidad MariaDB Connector/J con un clúster de Aurora Serverless, use el prefijo
jdbc:mariadb:aurora// en su cadena de conexión. El parámetro mariadb:aurora

150
Aurora MySQL
evita el análisis DNS automático para los destinos de conmutación por error. El escaneo no es
necesario con clústeres de Aurora Serverless y provoca un retraso en el establecimiento de la
conexión.
Puede utilizar políticas el cifrado SSL en las conexiones a una instancia de base de datos de Amazon
Aurora. Para obtener información, consulte Uso de SSL con una instancia de base de datos de MySQL.
Note
Como puede crear un clúster de base de datos Amazon Aurora en una Amazon Virtual Private
Cloud (VPC), las conexiones con un clúster de base de datos Amazon Aurora desde instancias
de AWS que no están en una VPC deben usar la dirección del punto de enlace pública del clúster
de base de datos Amazon Aurora. Sin embargo, ahora puede comunicarse con una instancia
Amazon EC2 que no esté en una VPC y un clúster de base de datos Amazon Aurora usando
ClassicLink. Para obtener más información, consulte Acceso a una instancia de base de datos
situada en una VPC desde una instancia EC2 que no está en una VPC (p. 220).
Conexión con SSL para Aurora MySQL

Para conectarse con SSL, use la utilidad MySQL como se describe en el siguiente procedimiento. Si utiliza
la autenticación de base de datos de IAM, debe usar una conexión de SSL. Para obtener información,
consulte Autenticación de bases de datos de IAM (p. 180).
Note
Para conectarse al punto de enlace del clúster mediante SSL, la utilidad de conexión del cliente
debe ser compatible con los nombres alternativos de firmante (SAN). Si la utilidad de conexión
del cliente no admite SAN, puede conectarse directamente a las instancias del clúster de base
de datos de Aurora. Para obtener más información acerca de los puntos de enlace de Aurora,
consulte Administración de conexiones de Amazon Aurora (p. 3).
Para conectarse a un clúster de base de datos con SSL a través de la utilidad MySQL
1. Descargue la clave pública para el certificado de firma de Amazon RDS de https://s3.amazonaws.com/

rds-downloads/rds-combined-ca-bundle.pem. Al hacerlo, se descarga un archivo llamado rds-
combined-ca-bundle.pem.
2. Escriba el siguiente comando en un símbolo del sistema para conectarse a la instancia principal de
un clúster de base de datos con SSL a través de la utilidad MySQL. Para el parámetro -h, escriba el
nombre de DNS del punto de enlace de la instancia principal. Para el parámetro --ssl_ca, escriba el
nombre del archivo de certificado de SSL que desee. Escriba la contraseña del usuario maestro cuando
se le pida.
mysql -h mycluster-primary.123456789012.us-east-1.rds.amazonaws.com --ssl-

ca=[full path]rds-combined-ca-bundle.pem --ssl-verify-server-cert
Debería ver un resultado similar a este.
Welcome to the MySQL monitor. Commands end with ; or \g.

Your MySQL connection id is 350
Server version: 5.6.10-log MySQL Community Server (GPL)
Type 'help;' or '\h' for help. Type '\c' to clear the buffer.
mysql>
Para obtener instrucciones generales sobre la construcción de cadenas de conexión de Amazon RDS
MySQL y encontrar la clave pública para las conexiones SSL, consulte Conexión a una instancia de base
de datos que ejecuta el motor de base de datos de MySQL.

151
Aurora PostgreSQL

Aurora PostgreSQL
Puede conectarse a una instancia de base de datos del clúster de base de datos de Amazon Aurora
PostgreSQL con las mismas herramientas que utiliza para conectarse a una base de datos de
PostgreSQL. Como parte de este proceso, utiliza la misma clave pública para conexiones de Capa de
conexión segura (SSL). Puede usar el punto de enlace y la información de puerto de la instancia principal
o las réplicas de Aurora del clúster de base de datos Aurora PostgreSQL en la cadena de conexión de
cualquier script, utilidad o aplicación que se conecte a una instancia de base de datos PostgreSQL. En la
cadena de conexión, especifique la dirección DNS del punto de enlace de la instancia principal o la réplica
de Aurora como parámetro del host. Especifique el número de puerto del punto de enlace como parámetro
del puerto.
Cuando tenga una conexión a una instancia de base de datos de su clúster de base de datos de Amazon
Aurora PostgreSQL, podrá ejecutar cualquier comando de SQL que sea compatible con la versión 9.6.3 de
PostgreSQL.
Para obtener una guía detallada y práctica sobre la conexión a un clúster de base de datos Amazon Aurora
MySQL puede consultar el manual Aurora Connection Management.
En la vista de detalles del clúster de base de datos de Aurora PostgreSQL puede encontrar el punto de
enlace del clúster. Puede utilizar este punto de conexión en su cadena de conexión de PostgreSQL.
El punto de enlace se compone del nombre de dominio y el puerto del clúster de base de datos.
Por ejemplo, si un valor de punto de conexión es mycluster.cluster-123456789012.us-
east-1.rds.amazonaws.com:5432, debe especificar los siguientes valores en una cadena de conexión
de PostgreSQL:
• Para el host o el nombre del host, especifique mycluster.cluster-123456789012.us-

east-1.rds.amazonaws.com
• Para el puerto, especifique 5432 o el valor del puerto que utilizó al crear el clúster de base de datos
El punto de enlace de clúster le conecta a la instancia principal del clúster de base de datos. Puede realizar
operaciones de lectura y escritura con el punto de enlace de clúster. El clúster de base de datos también
puede tener hasta 15 réplicas de Aurora que admiten acceso de solo lectura a los datos de su clúster de
base de datos. Cada instancia de base de datos en el clúster de Aurora (esto es, la instancia principal y
cada réplica de Aurora) tiene un punto de enlace único independiente del punto de enlace del clúster. Este
punto de conexión le permite conectarse a una instancia de base de datos específica directamente en el
clúster. El punto de conexión del clúster apunta siempre a la instancia principal. Si se produce un error en
la instancia principal y se reemplaza, el punto de conexión del clúster apunta a la nueva instancia principal.
Para ver el punto de enlace del clúster, elija Databases (Bases de datos) en la consola de Amazon RDS y
elija el clúster de base de datos para mostrar los detalles del clúster de base de datos.

152
Aurora PostgreSQL
Utilidades de conexión para Aurora PostgreSQL

A continuación se indican algunas de las utilidades de conexión que puede usar:
• Línea de comando: puede conectarse a una instancia de base de datos Amazon Aurora PostgreSQL
usando herramientas como psql, el terminal interactivo de PostgreSQL. Para obtener más información
acerca del uso del terminal interactivo de PostgreSQL, consulte psql en la documentación de
PostgreSQL.
• Interfaz gráfica de usuario (GUI): puede usar la utilidad pgAdmin para conectarse a una instancia
de base de datos PostgreSQL por medio de una interfaz de usuario. Para obtener más información,
consulte la página Download en el sitio web de pgAdmin.
• Aplicaciones: puede usar el controlador PostgreSQL JDBC para conectar sus aplicaciones a su instancia
de base de datos PostgreSQL. Para obtener más información, consulte la página Download en el sitio
web del controlador PostgreSQL JDBC.
Note
Como puede crear un clúster de base de datos Amazon Aurora PostgreSQL en una Amazon
Virtual Private Cloud (VPC), las conexiones con un clúster de base de datos Aurora PostgreSQL
desde instancias de AWS que no están en una VPC deben usar la dirección del punto de
enlace pública del clúster de base de datos Aurora PostgreSQL. Sin embargo, ahora puede

153
Solución de problemas
comunicarse con una instancia Amazon EC2 que no esté en una VPC y un clúster de base de
datos Aurora PostgreSQL usando ClassicLink. Para obtener más información, consulte Acceso a
una instancia de base de datos situada en una VPC desde una instancia EC2 que no está en una
VPC (p. 220).
Solución de problemas de conexión de Aurora

Note
Para obtener una guía detallada y práctica sobre la conexión a un clúster de base de datos
Amazon Aurora MySQL puede consultar el manual Aurora Connection Management.
Las causas frecuentes de errores de conexión a un nuevo clúster de base de datos de Aurora son las
siguientes:
• El clúster de base de datos se creó usando una VPC que no permite las conexiones desde su
dispositivo. Para corregir este error, modifique la VPC para permitir conexiones desde su dispositivo o
cree una nueva VPC para el clúster de base de datos que permita las conexiones desde el dispositivo.
Para ver un ejemplo, consulte Creación de una VPC y de subredes (p. 212).
• El clúster de base de datos se creó con el puerto predeterminado y su compañía tiene reglas de firewall
que bloquean las conexiones a ese puerto desde los dispositivos de la red de la organización. Para
solucionar este error, vuelva a crear la instancia con un puerto diferente.
• Si desea usar la autenticación de base de datos de IAM, es posible que tenga que configurarla. Para
obtener información, consulte Autenticación de bases de datos de IAM (p. 180).
Migración de datos a un clúster de base de datos

Amazon Aurora
Tiene varias opciones para migrar datos desde una base de datos existente a un clúster de base de
datos de Amazon Aurora, en función de la compatibilidad con el motor de base de datos. Las opciones de
migración dependen también de la base de datos desde la que se realiza la migración y del tamaño de los
datos que se van a migrar.

Amazon Aurora MySQL
Puede migrar datos desde una de las siguientes fuentes a un clúster de base de datos de Amazon Aurora
MySQL.
• Una instancia de base de datos MySQL en Amazon RDS

• Una base de datos MySQL externa a Amazon RDS
• Una bases de datos que no sea compatible con MySQL
Para obtener más información, consulte Migración de datos a un clúster de base de datos de Amazon
Migración de datos a un clúster de base de datos de

Amazon Aurora PostgreSQL
Puede migrar datos desde una de las siguientes fuentes a un clúster de base de datos de Amazon Aurora
PostgreSQL.

154
Aurora PostgreSQL
• Una instancia de base de datos PostgreSQL en Amazon RDS

• Una base de datos que no sea compatible con PostgreSQL
Para obtener más información, consulte Migración de datos a Amazon Aurora con compatibilidad con
PostgreSQL (p. 772).

155
Seguridad en Amazon Aurora

La seguridad en la nube de AWS es la mayor prioridad. Como cliente de AWS, se beneficiará de una
arquitectura de red y un centro de datos que están diseñados para satisfacer los requisitos de seguridad de
las organizaciones más exigentes.
La seguridad es una responsabilidad compartida entre AWS y usted. El modelo de responsabilidad

compartida la describe como seguridad de la nube y seguridad en la nube:
• Seguridad de la nube: AWS es responsable de proteger la infraestructura que ejecuta servicios de

AWS en la nube de AWS. AWS también proporciona servicios que puede utilizar de forma segura.
Auditores externos prueban y verifican periódicamente la eficacia de nuestra seguridad en el marco
de los programas de conformidad de AWS. Para obtener más información acerca de los programas
de conformidad que se aplican a Amazon AuroraAurora, consulte Servicios de AWS en el ámbito del
programa de conformidad.
• Seguridad en la nube: su responsabilidad viene determinada por el servicio de AWS que utilice. Usted
también es responsable de otros factores incluida la confidencialidad de los datos, los requisitos de la
empresa y la legislación y los reglamentos aplicables.
Esta documentación le ayuda a comprender cómo aplicar el modelo de responsabilidad compartida cuando
se utiliza Amazon Aurora. En los siguientes temas, se le mostrará cómo configurar Amazon Aurora para
satisfacer sus objetivos de seguridad y conformidad. También puede aprender a utilizar otros servicios de
AWS que le ayudan a supervisar y proteger sus recursos de Amazon Aurora.
Es posible controlar el acceso a los recursos de Amazon Aurora y sus bases de datos en un clúster de
base de datos. El método que se utiliza para controlar el acceso depende del tipo de tarea que el usuario
necesite realizar con Amazon Aurora:
• Ejecute su clúster de base de datos en una nube privada virtual (VPC) basándose en el servicio de
Amazon VPC para el posible control de acceso de red más grande. Para obtener más información
acerca de la creación de un clúster de base de datos en una VPC, consulte VPC Amazon Virtual Private
Cloud y Amazon Aurora (p. 211).
• Utilice políticas de AWS Identity and Access Management (IAM) para asignar permisos que determinen
quién puede administrar los recursos de Amazon Aurora. Por ejemplo, puede utilizar IAM para
determinar quién tiene permiso para crear, describir, modificar y eliminar clústeres de bases de datos,
etiquetar recursos o modificar grupos de seguridad.
Para obtener información acerca de cómo configurar un usuario de IAM, consulte Creación de un usuario
de IAM (p. 50).
• Utilice grupos de seguridad para controlar las direcciones IP o instancias Amazon EC2 que pueden
conectarse a las bases de datos de un clúster de base de datos. Cuando se crea un clúster de base de
datos por primera vez, su firewall impide cualquier acceso a las bases de datos, salvo si se cumplen las
reglas especificadas por un grupo de seguridad asociado.
• Utilice conexiones SSL (Capa de conexión segura) con clústeres de base de datos que ejecuten Aurora
MySQL o Aurora PostgreSQL. Para obtener más información sobre el uso de SSL con un clúster de
base de datos, consulte Uso de SSL para cifrar una conexión a un clúster de base de datos (p. 161).
• Use cifrado Amazon Aurora para proteger sus clústeres de base de datos e instantáneas en reposo. El
cifrado de Amazon Aurora utiliza el algoritmo de cifrado AES-256 para cifrar sus datos en el servidor
que aloja su clúster de base de datos. Para obtener más información, consulte Cifrado de recursos de
• Utilice las características de seguridad del motor de base de datos para controlar quién puede iniciar
sesión en las bases de datos de un clúster de base de datos. Estas características funcionas de igual
forma que si la base de datos estuviera en su red local.

156
Protección de los datos
Para obtener información sobre seguridad con Aurora MySQL, consulte Seguridad con Amazon
Aurora MySQL (p. 499). Para obtener información sobre seguridad con Aurora PostgreSQL, consulte
Seguridad con Amazon Aurora PostgreSQL (p. 770).
Aurora forma parte del servicio de bases de datos administradas Amazon Relational Database Service
(Amazon RDS). Amazon RDS es un servicio web que facilita las tareas de configuración, operación y
escalado de una base de datos relacional en la nube. Si no está familiarizado con Amazon RDS, consulte
la Guía del usuario de Amazon RDS.
Aurora incluye un subsistema de almacenamiento de alto rendimiento. Sus motores de base de datos
compatibles con MySQL y PostgreSQL están personalizados para aprovechar su almacenamiento de
rápida distribución. Aurora también automatiza y estandariza la agrupación en clústeres y la replicación,
que suelen ser algunos de los aspectos más problemáticos de la configuración y administración de las
bases de datos.
En Amazon RDS y Aurora, Puede acceder mediante programación a l API de RDS y puede utilizar la AWS
CLI para acceder de forma interactiva a la API de RDS. Algunas acciones de API de RDS y comandos
de AWS CLI se aplican a Amazon RDS y Aurora, mientras qu otros se aplican a Amazon RDS o Aurora.
para obtener información sobre acciones de API de RDS, consulte Referencia de API de Amazon RDS.
Para obtener más información acerca de la AWS CLI, consulte la documentación de referencia de la AWS
Command Line Interface de Amazon RDS.
Note
Solo tiene que configurar la seguridad para sus casos de uso. No tiene que configurar el acceso
de seguridad para procesos que Amazon Aurora administra. Estos incluyen la creación de copias
de seguridad, la replicación de datos entre un maestro y una réplica de lectura, y otros procesos.
Para obtener más información acerca de la administración del acceso a los recursos de Amazon Aurora y
las bases de datos de un clúster de base de datos, consulte los siguientes temas.
Temas
• Protección de los datos en Amazon Aurora (p. 157)
• Administración de identidad y acceso en Amazon Aurora (p. 163)
• Registro y monitorización en Amazon Aurora (p. 199)
• Validación de la conformidad en Amazon Aurora (p. 201)
• Resiliencia en Amazon Aurora (p. 201)
• Seguridad de la infraestructura en Amazon Aurora (p. 203)
• Prácticas recomendadas de seguridad para Amazon Aurora (p. 204)
• Control de acceso con grupos de seguridad (p. 204)
• Privilegios de la cuenta de usuario maestro (p. 207)
• Uso de roles vinculados a servicios en Amazon Aurora (p. 207)
• VPC Amazon Virtual Private Cloud y Amazon Aurora (p. 211)
Protección de los datos en Amazon Aurora

Amazon Aurora cumple los requisitos del modelo de responsabilidad compartida de AWS, que
incluye reglamentos y directrices para la protección de los datos. AWS es responsable de proteger la
infraestructura global que ejecuta todos los servicios de AWS. AWS mantiene el control de los datos
alojados en esta infraestructura, incluidos los controles de configuración de la seguridad para el tratamiento
del contenido y los datos personales de los clientes. Los clientes de AWS y los socios de APN, que actúan
como controladores o procesadores de datos, son responsables de todos los datos personales que
colocan en la nube de AWS.

157
Cifrado de datos
Para la protección de datos, recomendamos que proteja las credenciales de la cuenta de AWS y configure
principales con AWS Identity and Access Management (IAM). Hacer esto significa que a cada usuario solo
se le otorgan los permisos necesarios para cumplir sus obligaciones laborales. También le recomendamos
proteger sus datos de las siguientes formas:
• Utilice la autenticación multifactor (MFA) con cada cuenta.

• Utilice SSL/TLS para comunicarse con los recursos de AWS.
• Configure la API y el registro de actividad del usuario con AWS CloudTrail.
• Utilice las soluciones de cifrado de AWS, junto con todos los controles de seguridad predeterminados
dentro de los servicios de AWS.
• Utilice los servicios de seguridad administrados avanzados como, por ejemplo, Amazon Macie, que
ayudan a detectar y proteger los datos personales almacenados en Amazon S3.
• En Aurora PostgreSQL, utilice las secuencias de actividad de su base de datos para monitorizar y
auditar la actividad de la base de datos para adoptar medidas de seguridad que protejan su base de
datos y cumplir los requisitos normativos y de cumplimiento.
Le recomendamos encarecidamente que nunca introduzca información de identificación confidencial,

como, por ejemplo, números de cuenta de sus clientes, en los campos de formato libre, como el campo
Name (Nombre). Esta recomendación incluye cuando trabaje con Amazon Aurora u otros servicios
de AWS a través de la consola, la API, la AWS CLI de AWS o los SDK de AWS. Cualquier dato que
escriba en Amazon Aurora o en otros servicios se puede incluir en los registros de diagnóstico. Cuando
proporcione una URL a un servidor externo, no incluya información de credenciales en la URL para validar
la solicitud para ese servidor.
Para obtener más información sobre la protección de datos, consulte la entrada de blog relativa al modelo
de responsabilidad compartida de AWS y GDPR en el blog de seguridad de AWS.
Temas
• Protección de datos mediante cifrado (p. 158)
• Privacidad del tráfico entre redes (p. 162)
Protección de datos mediante cifrado

Puede habilitar el cifrado para recursos de bases de datos. También puede cifrar conexiones a clústeres
de base de dato.
Temas
• Cifrado de recursos de Amazon Aurora (p. 158)
• Administración de claves (p. 160)
• Uso de SSL para cifrar una conexión a un clúster de base de datos (p. 161)
Cifrado de recursos de Amazon Aurora

Es posible cifrar los clústeres de bases de datos de Amazon Aurora y las instantáneas en reposo activando
la opción de cifrado para sus clústeres de bases de datos de Amazon Aurora. Los datos cifrados en
reposo incluyen el almacenamiento subyacente de clústeres de bases de datos, sus copias de seguridad
automatizadas, sus réplicas de lectura y sus instantáneas.
En los clústeres de bases de datos de Amazon Aurora con cifrado se utiliza el algoritmo de cifrado
AES-256 estándar del sector para cifrar los datos en el servidor que aloja clústeres de bases de datos de
Amazon Aurora. Una vez cifrados los datos, Amazon Aurora se encarga de la autenticación de acceso
y del descifrado de los datos de forma transparente, con un impacto mínimo en el desempeño. No es
necesario modificar las aplicaciones cliente de base de datos para utilizar el cifrado.

158
Cifrado de datos
Note
Para los clústeres de base de datos cifradas y no cifradas, los datos en tránsito entre el origen y
las réplicas de lectura están cifrados, incluso al replicar entre regiones de AWS.
Temas
• Información general del cifrado de los recursos de Amazon Aurora (p. 159)
• Habilitación del cifrado de Amazon Aurora para un clúster de base de datos (p. 159)
• Disponibilidad del cifrado de Amazon Aurora (p. 160)
• Limitaciones de Amazon Aurora clústeres con cifrado de bases de datos (p. 160)
Información general del cifrado de los recursos de Amazon Aurora

Los clústeres de bases de datos cifrados de Amazon Aurora proporcionan una capa adicional de
protección de datos al proteger los datos del acceso no autorizado al almacenamiento subyacente.
Puede utilizar el cifrado de Amazon Aurora para aumentar la protección de datos de las aplicaciones
implementadas en la nube y para cumplir con los requisitos de conformidad para el cifrado de datos en
reposo.
Para administrar las claves que se usan para cifrar y descifrar los recursos de Amazon Aurora, se utiliza
AWS Key Management Service (AWS KMS). AWS KMS combina hardware y software seguros y altamente
disponibles para ofrecer un sistema de administración de claves escalado para la nube. Si utiliza AWS
KMS, puede crear claves de cifrado y definir las políticas que controlan cómo se pueden utilizar dichas
claves. AWS KMS es compatible con CloudTrail, lo que permite auditar el uso de claves para comprobar
que las claves se utilizan de forma adecuada. Puede utilizar las claves de AWS KMS con Amazon Aurora
y con servicios de AWS compatibles, como Amazon S3, Amazon EBS y Amazon Redshift. Para obtener
una lista de los servicios compatibles con AWS KMS, consulte Servicios compatibles en la Guía para
desarrolladores de AWS Key Management Service.
Para un clúster de base de datos cifrado de Amazon Aurora, todos los registros, copias de seguridad e
instantáneas están cifrados. También puede cifrar una réplica de lectura de un clúster cifrado de Amazon
Aurora. El cifrado de la réplica de lectura se protege mediante la clave maestra KMS de la región de AWS.
Habilitación del cifrado de Amazon Aurora para un clúster de base de datos

Para habilitar el cifrado en un clúster de base de datos nuevo, elija Enable encryption (Habilitar cifrado) en
la consola. Para obtener más información acerca de la creación de un clúster de base de datos, consulte
Creación de un clúster de base de datos de Amazon Aurora (p. 85).
Si utiliza el comando create-db-cluster de la AWS CLI para crear un clúster de base de datos cifrado,
establezca el parámetro --storage-encrypted en true. Si utiliza la acción CreateDBCluster de la API,
establezca el parámetro StorageEncrypted en true.
Al crear un clúster de base de datos cifrado, también puede proporcionar el identificador de clave de AWS
KMS para la clave de cifrado. Si no especifica un identificador de clave de AWS KMS, Amazon Aurora
utiliza la clave de cifrado predeterminada para el nuevo clúster de base de datos. AWS KMS crea la clave
de cifrado predeterminada para Amazon Aurora para una cuenta de AWS. Cada cuenta de AWS dispone
de una clave de cifrado predeterminada diferente para cada región de AWS.
Una vez que cree un clúster de base de datos, no puede cambiar el tipo de clave de cifrado utilizada por
dicho clúster de base de datos. Por tanto, asegúrese de determinar los requisitos de clave de cifrado antes
de crear el clúster de base de datos cifrado.
Si utiliza el comando AWS CLI de la create-db-cluster para crear un clúster de base de datos cifrado,
configure el parámetro --kms-key-id con el Nombre de recurso de Amazon (ARN) de la clave de KMS
para el clúster de base de datos. Si utiliza la acción CreateDBCluster de la API de RDS, establezca el
parámetro KmsKeyId en el ARN de la clave de KMS del clúster de base de datos.

159
Cifrado de datos
Puede utilizar el ARN de una clave de otra cuenta para cifrar un clúster de base de datos. O bien, puede
crear un clúster de base de datos con la misma cuenta de AWS a la que pertenece la clave de cifrado de
KMS usada para cifrar ese clúster de base de datos nuevo. En este caso, el ID de clave de KMS que pasa
puede ser el alias de la clave de KMS en lugar del ARN de la clave.
Important
En algunos casos, Amazon Aurora puede perder acceso a la clave de cifrado de un clúster
de base de datos. Por ejemplo, Aurora pierde acceso cuando se revoca el acceso de RDS a
una clave. En estos casos, el clúster de base de datos cifrado pasa a un estado terminal y solo
puede restaurar el clúster de base de datos desde una copia de seguridad. Recomendamos que
siempre habilite las copias de seguridad para los clústeres de bases de datos cifrados con el fin
de protegerse contra la pérdida de los datos cifrados de dichas bases de datos.
Disponibilidad del cifrado de Amazon Aurora

El cifrado de Amazon Aurora está disponible para todos los motores de bases de datos y tipos de
almacenamiento. El cifrado Amazon Aurora no está disponible actualmente en la región China (Pekín).
Note
El cifrado de Amazon Aurora no está disponible para la clase de instancia de base de datos
sdb.t2.micro.
Limitaciones de Amazon Aurora clústeres con cifrado de bases de datos

Las siguientes limitaciones existen para clústeres con cifrado de base de datos de Amazon Aurora:
• Los clústeres de bases de datos que están cifrados no se pueden modificar para desactivar el cifrado.
• No puede convertir un clúster de base de datos cifrado en uno sin cifrar. Sin embargo, sí es posible
restaurar una instantánea de clúster de base de datos de Aurora sin cifrar en un clúster de base de datos
de Aurora cifrado. Para hacer esto, especifique una clave de cifrado KMS cuando restaure a partir de
una instantánea de clúster de base de datos sin cifrar.
• No puede crear una réplica de Aurora cifrada a partir de un clúster de base de datos de Aurora sin cifrar.
No puede crear una réplica de Aurora sin cifrar a partir de un clúster de base de datos de Aurora cifrado.
• Para copiar una instantánea cifrada de una región de AWS en otra, debe especificar el identificador de
clave de KMS de la región de AWS de destino. Esto se debe a que las claves de cifrado de KMS son
específicas de la región de AWS en la que se crean.
La instantánea de origen permanece cifrada durante todo el proceso de copia. AWS Key Management
Service utiliza el cifrado de sobre para proteger los datos durante el proceso de copia. Para obtener más
información acerca del cifrado de sobre, consulte Cifrado de sobre.
Administración de claves
Puede administrar las claves utilizadas para clústeres de bases de datos de Amazon Aurora utilizando
AWS Key Management Service (AWS KMS) en la consola de IAM. Si desea tener un control total sobre
una clave, debe crear una clave administrada por el cliente.
No puede eliminar, revocar ni rotar las claves predeterminadas aprovisionadas por AWS KMS. No se
puede compartir una instantánea que se ha cifrado utilizando la clave de cifrado predeterminada de AWS
KMS de la cuenta de AWS que compartió la instantánea.
Puede ver los registros de auditoría de cada acción realizada con una clave administrada por el cliente
mediante AWS CloudTrail.
Important
Si desactiva la clave de clústeres cifrados de base de datos, no podrá leer ni escribir en ese
clúster de base de datos. Cuando Aurora encuentra un clúster con cifrado de bases de datos

160
Cifrado de datos
con una clave a la que Aurora no tiene acceso, Aurora pone el clúster de base de datos en un
estado terminal. En dicho estado, el clúster de base de datos ya no está disponible y no es posible
recuperar su estado actual. Para restaurar el clúster de base de datos, debe volver a activar el
acceso a la clave de cifrado para Aurora y, a continuación, restaurar el clúster a partir de una
copia de seguridad.
Uso de SSL para cifrar una conexión a un clúster de base de

datos
Puede usar SSL desde su aplicación para cifrar un clúster de base de datos que ejecute Aurora MySQL
o Aurora PostgreSQL. Cada motor base de datos tiene su propio proceso para implementar SSL. Para
obtener información sobre cómo implementar SSL para un clúster de base de datos, utilice el enlace de la
siguiente lista que corresponda a su motor de base de datos:
• Seguridad con Amazon Aurora MySQL (p. 499)

• Seguridad con Amazon Aurora PostgreSQL (p. 770)
Un certificado raíz que funciona para todas las regiones de AWS se puede descargar en https://
s3.amazonaws.com/rds-downloads/rds-ca-2015-root.pem. Es la entidad raíz de confianza y debería
funcionar en la mayoría de los casos, pero podría fallar si la aplicación no acepta cadenas de certificados.
Si la aplicación no acepta cadenas de certificados, descargue el certificado específico de la región de AWS
de la lista de certificados intermedios que se encuentra más adelante en esta sección. Puede descargar
un certificado raíz para las regiones de AWS GovCloud en https://s3-us-gov-west-1.amazonaws.com/rds-
downloads/rds-GovCloud-Root-CA-2017.pem.
Note
Todos los certificados están disponibles solo para descarga con conexiones SSL.
Un paquete de certificados que contiene los certificados raíz intermedios se puede descargar en https://
s3.amazonaws.com/rds-downloads/rds-combined-ca-bundle.pem .
Un paquete de certificados que contiene los certificados raíz e intermedios para las regiones de AWS
GovCloud se puede descargar en https://s3-us-gov-west-1.amazonaws.com/rds-downloads/rds-combined-
ca-us-gov-bundle.pem.
Si l aplicación está en Microsoft Windows y requiere un archivo PKCS7, puede descargar el

paquete de certificados PKCS7. Este paquete contiene los certificados raíz e intermedios en https://
s3.amazonaws.com/rds-downloads/rds-combined-ca-bundle.p7b.
Certificados intermedios
Es posible que necesite utilizar un certificado intermedio para conectarse a su región de AWS. Por
ejemplo, debe utilizar un certificado intermedio para conectarse a la región AWS GovCloud (EE.UU. Oeste)
usando SSL. Si necesita un certificado intermedio para una región de AWS determinada, descárguelo de la
siguiente lista:
Asia Pacífico (Hong Kong)
Asia Pacífico (Mumbai)
Asia Pacífico (Tokio)
Asia Pacífico (Seúl)
Asia Pacífico (Osaka-local)
Asia Pacífico (Singapur)
Asia Pacífico (Sídney)

161
Privacidad del tráfico entre redes
Canadá (Central)
China (Pekín)
China (Ningxia)
UE (Fráncfort)
UE (Irlanda)
UE (Londres)
UE (París)
UE Estocolmo
América del Sur (São Paulo)
US East (N. Virginia)
EE.UU. Este (Ohio)
EE.UU. Oeste (Norte de California)
EE.UU. Oeste (Oregón)
AWS GovCloud (EE. UU.) Este (CA-2017)
AWS GovCloud (EE. UU.-Oeste) (CA-2017)
AWS GovCloud (EE. UU.-Oeste) (CA-2012)
Privacidad del tráfico entre redes

Las conexiones están protegidas entre Amazon Aurora y en aplicaciones locales y entre Amazon Aurora y
otros recursos de AWS dentro de la misma región de AWS.
Tráfico entre el servicio y aplicaciones y clientes locales

Tiene dos opciones de conectividad entre su red privada y AWS:
• Una conexión de Site-to-Site VPN de AWS. Para obtener más información, consulte ¿Qué es AWS Site-
to-Site VPN?
• Una conexión de AWS Direct Connect. Para obtener más información, consulte ¿Qué es AWS Direct
Connect?
El acceso a Amazon Aurora a través de la red se realiza mediante las API publicadas por AWS. Los
clientes deben admitir Transport Layer Security (TLS) 1.0. Nosotros recomendamos TLS 1.2. Los
clientes también deben admitir conjuntos de cifrado con confidencialidad directa total (PFS) tales como
Ephemeral Diffie-Hellman (DHE) o Elliptic Curve Diffie-Hellman Ephemeral (ECDHE). La mayoría de los
sistemas modernos como Java 7 y posteriores son compatibles con estos modos. Además, debe firmar
las solicitudes mediante un ID de clave de acceso y una clave de acceso secreta que estén asociados a
una entidad principal de IAM. También puede utilizar AWS Security Token Service (STS) para generar
credenciales de seguridad temporales para firmar solicitudes.
Tráfico entre recursos de AWS en la misma región

Un punto de enlace de Amazon Virtual Private Cloud (Amazon VPC) para Amazon Aurora es una entidad
lógica dentro de una VPC que únicamente permite la conectividad a Amazon Aurora. La Amazon VPC

162
Identity and Access Management
direcciona las solicitudes a Amazon Aurora y vuelve a direccionar las respuestas a la VPC. Para obtener
más información, consulte Puntos de enlace de la VPC en la Guía del usuario de Amazon VPC. Para
consultar ejemplos de políticas de bucket que puede utilizar para controlar el acceso a el clúster de base
de datos desde los puntos de enlace de la VPC, consulte Creación y uso de una política de IAM para el
acceso a bases de datos de IAM (p. 183).
Administración de identidad y acceso en Amazon

Aurora
AWS Identity and Access Management (IAM) es un servicio de AWS que ayuda a un administrador a
controlar de forma segura el acceso a los recursos de AWS. Los administradores de IAM controlan quién
puede ser autenticado (iniciar sesión) y estar autorizado (tener permisos) para utilizar los recursos de
Aurora. IAM es un servicio de AWS que se puede utilizar sin costo adicional.
Temas
• Público (p. 163)
• Autenticación con identidades (p. 163)
• Administración de acceso mediante políticas (p. 165)
• Funcionamiento de Amazon Aurora con IAM (p. 167)
• Ejemplos de políticas basadas en identidad de Amazon Aurora (p. 170)
• Autenticación de bases de datos de IAM (p. 180)
• Solución de problemas de identidad y acceso en Amazon Aurora (p. 197)
Público
La forma en que utilice AWS Identity and Access Management (IAM) difiere, en función del trabajo que
realice en Aurora.
Usuario de servicio: si utiliza el servicio Aurora para realizar su trabajo, su administrador le proporciona las
credenciales y los permisos que necesita. A medida que utilice más características de Aurora para realizar
su trabajo, es posible que necesite permisos adicionales. Entender cómo se administra el acceso puede
ayudarle a solicitar los permisos correctos a su administrador. Si no puede acceder a una característica en
Aurora, consulte Solución de problemas de identidad y acceso en Amazon Aurora (p. 197).
Administrador de servicio: si está a cargo de los recursos de –Aurora en su empresa, probablemente tenga
acceso completo a Aurora. Su trabajo consiste en determinar qué a características y recursos de Aurora
deben acceder sus empleados. A continuación, debe enviar solicitudes a su administrador de IAM para
cambiar los permisos de los usuarios de su servicio. Revise la información de esta página para conocer los
conceptos básicos de IAM. Para obtener más información sobre cómo su empresa puede utilizar IAM con
Aurora, consulte Funcionamiento de Amazon Aurora con IAM (p. 167).
Administrator de IAM: si es un administrador de IAM, es posible que quiera conocer información sobre
cómo escribir políticas para administrar el acceso a Aurora. Para ver ejemplos de políticas basadas en la
identidad de Aurora que puede utilizar en IAM, consulte Ejemplos de políticas basadas en identidad de
Autenticación con identidades

La autenticación es la manera de iniciar sesión en AWS mediante credenciales de identidad. Para obtener
más información acerca del inicio de sesión con la Consola de administración de AWS, consulte La
consola de IAM y la página de inicio de sesión en la Guía del usuario de IAM.

163
Autenticación con identidades
Debe estar autenticado (haber iniciado sesión en AWS) como Usuario de la cuenta raíz de AWS, usuario
de IAM o asumiendo un rol de IAM. También puede utilizar la autenticación de inicio de sesión único de
su empresa o incluso iniciar sesión con Google o Facebook. En estos casos, su administrador habrá
configurado previamente la federación de identidad mediante roles de IAM. Cuando obtiene acceso a AWS
mediante credenciales de otra empresa, asume un rol indirectamente.
Para iniciar sesión directamente en la Consola de administración de AWS, use su contraseña con su
correo electrónico usuario raíz o su nombre de usuario de IAM. Puede obtener acceso a AWS mediante
programación utilizando sus claves de acceso usuario raíz o de usuario de IAM. AWS proporciona SDK y
herramientas de línea de comandos para firmar criptográficamente su solicitud con sus credenciales. Si no
utiliza las herramientas de AWS, debe firmar usted mismo la solicitud. Para ello, utilice Signature Version
4, un protocolo para autenticar solicitudes de API de entrada. Para obtener más información acerca de la
autenticación de solicitudes, consulte Proceso de firma Signature Version 4 en la AWS General Reference.
Independientemente del método de autenticación que utilice, es posible que también deba proporcionar
información de seguridad adicional. Por ejemplo, AWS le recomienda el uso de la autenticación multifactor
(MFA) para aumentar la seguridad de su cuenta. Para obtener más información, consulte Uso de Multi-
Factor Authentication (MFA) en AWS en la Guía del usuario de IAM.
Usuario raíz de la cuenta de AWS

Cuando se crea por primera vez una cuenta de AWS, se comienza con una única identidad de inicio de
sesión que tiene acceso completo a todos los servicios y recursos de AWS de la cuenta. Esta identidad
recibe el nombre de AWS de la cuenta de usuario raíz y se obtiene acceso a ella iniciando sesión con la
dirección de correo electrónico y la contraseña que utilizó para crear la cuenta. Le recomendamos que
no utilice usuario raíz en sus tareas cotidianas, ni siquiera en las tareas administrativas. En lugar de ello,
es mejor ceñirse a la práctica recomendada de utilizar exclusivamente usuario raíz para crear el primer
usuario de IAM. A continuación, guarde las credenciales de usuario raíz en un lugar seguro y utilícelas
únicamente para algunas tareas de administración de cuentas y servicios.
Usuarios y grupos de IAM

Un usuario de IAM es una entidad de la cuenta de AWS que dispone de permisos específicos para una
sola persona o aplicación. Un usuario de IAM puede tener credenciales a largo plazo, como un nombre
de usuario y una contraseña o un conjunto de claves de acceso. Para obtener más información acerca de
cómo generar claves de acceso, consulte Administración de las claves de acceso de los usuarios de IAM
en la Guía del usuario de IAM. Al generar claves de acceso para un usuario de IAM, asegúrese de ver y
guardar de forma segura el par de claves. No puede recuperar la clave de acceso secreta en el futuro. En
su lugar, debe generar un nuevo par de claves de acceso.
Un grupo de IAM es una identidad que especifica un conjunto de usuarios de IAM. No puede iniciar sesión
como grupo. Puede usar los grupos para especificar permisos para varios usuarios a la vez. Los grupos
facilitan la administración de los permisos de grandes conjuntos de usuarios. Por ejemplo, podría tener un
grupo cuyo nombre fuese Administradores de IAM y conceder permisos a dicho grupo para administrar los
recursos de IAM.
Los usuarios son diferentes de los roles. Un usuario se asocia exclusivamente a una persona o aplicación,
pero la intención es que cualquier usuario pueda asumir un rol que necesite. Los usuarios tienen
credenciales permanentes a largo plazo y los roles proporcionan credenciales temporales. Para obtener
más información, consulte Cuándo crear un usuario de IAM (en lugar de un rol) en la Guía del usuario de
IAM.
Puede autenticar en si clúster de base de datos utilizando autenticación de base de datos de IAM.
La autenticación de base de datos de IAM funciona con Aurora. Para obtener más información sobre
la autenticación en su clúster de base de datos con IAM, consulte Autenticación de bases de datos de
IAM (p. 180).

164
Administración de acceso mediante políticas
Roles de IAM
Un rol de IAM es una entidad de la cuenta de AWS que dispone de permisos específicos. Es similar a
un usuario de IAM, pero no está asociado a una determinada persona. Puede asumir temporalmente un
rol de IAM en la Consola de administración de AWS cambiando de roles. Puede asumir un rol llamando
a una operación de la AWS CLI o de la API de AWS, o utilizando una URL personalizada. Para obtener
más información acerca de los métodos para el uso de roles, consulte Uso de roles de IAM en la Guía del
usuario de IAM.
Los roles de IAM con credenciales temporales son útiles en las siguientes situaciones:
• Permisos de usuario temporales de IAM: un usuario de IAM puede asumir un rol de IAM para recibir
temporalmente permisos distintos que le permitan realizar una tarea concreta.
• Acceso de usuario federado: En lugar de crear un usuario de IAM, puede utilizar identidades existentes
de AWS Directory Service, del directorio de usuarios de la empresa o de un proveedor de identidades
web. A estas identidades se les llama usuarios federados. AWS asigna una función a un usuario
federado cuando se solicita acceso a través de un proveedor de identidad. Para obtener más
información acerca de los usuarios federados, consulte Usuarios federados y roles en la Guía del
usuario de IAM.
• Acceso entre cuentas: puede utilizar un rol de IAM para permitir que alguien (una entidad principal de
confianza) de otra cuenta obtenga acceso a los recursos de su cuenta. Los roles son la forma principal
de conceder acceso entre cuentas. Sin embargo, con algunos servicios de AWS, puede asociar una
política directamente a un recurso (en lugar de utilizar un rol como proxy). Para obtener información
acerca de la diferencia entre los roles y las políticas basadas en recursos para el acceso entre cuentas,
consulte Cómo los roles de IAM difieren de las políticas basadas en recursos en la Guía del usuario de
IAM.
• Acceso a servicios de AWS: Un rol de servicio es un rol de IAM que un servicio asume para realizar
acciones en su cuenta en su nombre. Al configurar algunos de los entornos de los servicios de AWS,
debe definir un rol que el servicio asumirá. Este rol de servicio debe incluir todos los permisos que
son necesarios para que el servicio pueda acceder a los recursos de AWS que necesita. Los roles de
servicio varían de servicio a servicio, pero muchos le permiten elegir sus permisos, siempre y cuando
se cumplan los requisitos documentados para dicho servicio. Los roles de servicio ofrecen acceso solo
dentro de su cuenta y no se pueden utilizar para otorgar acceso a servicios en otras cuentas. Puede
crear, modificar y eliminar un rol de servicio desde IAM. Por ejemplo, puede crear un rol que permita
a Amazon Redshift tener acceso a un bucket de Amazon S3 en su nombre y, a continuación, cargar
los datos de ese bucket en un clúster de Amazon Redshift. Para obtener más información, consulte
Creación de un rol para delegar permisos a un servicio de AWS en la Guía del usuario de IAM.
• Aplicaciones que se ejecutan en Amazon EC2: Puede utilizar un rol de IAM para administrar
credenciales temporales para las aplicaciones que se ejecutan en una instancia EC2 y realizan
solicitudes de la AWS CLI o la API de AWS. Es preferible hacerlo de este modo a almacenar claves de
acceso en la instancia EC2. Para asignar un rol de AWS a una instancia EC2 y ponerla a disposición de
todas las aplicaciones, cree un perfil de instancia asociado a la misma. Un perfil de instancia contiene el
rol y permite a los programas que se ejecutan en la instancia EC2 obtener credenciales temporales. Para
obtener más información, consulte Uso de un rol de IAM para conceder permisos a aplicaciones que se
ejecutan en instancias Amazon EC2 en la Guía del usuario de IAM.
Para obtener información acerca del uso de los roles de IAM, consulte Cuándo crear un rol de IAM (en vez
de un usuario) en la Guía del usuario de IAM.

Para controlar el acceso en AWS, se crean políticas y se asocian a identidades de IAM o recursos de
AWS. Una política es un objeto de AWS que, cuando se asocia a una identidad o un recurso, define
sus permisos. AWS evalúa estas políticas cuando una entidad principal (usuario raíz, usuario de IAM o
rol de IAM) realiza una solicitud. Los permisos en las políticas determinan si la solicitud se permite o se

165
deniega. Las mayoría de las políticas se almacenan en AWS como documentos JSON. Para obtener
más información acerca de la estructura y el contenido de los documentos de política JSON, consulte
Información general de las políticas de JSON en la Guía del usuario de IAM.
Un administrador de IAM puede utilizar las políticas para especificar quién tiene acceso a los recursos de
AWS y qué acciones se pueden realizar en dichos recursos. Cada entidad de IAM (usuario o rol) comienza
sin permisos. En otras palabras, de forma predeterminada, los usuarios no pueden hacer nada, ni siquiera
cambiar sus propias contraseñas. Para conceder permiso a un usuario para hacer algo, el administrador
debe asociarle una política de permisos. O bien el administrador puede añadir al usuario a un grupo que
tenga los permisos necesarios. Cuando el administrador concede permisos a un grupo, todos los usuarios
de ese grupo obtienen los permisos.
Las políticas de IAM definen permisos para una acción independientemente del método que se utilice
para realizar la operación. Por ejemplo, suponga que dispone de una política que permite la acción
iam:GetRole. Un usuario con dicha política puede obtener información del usuario de la Consola de
administración de AWS, la AWS CLI o la API de AWS.
Políticas basadas en la identidad

Las políticas basadas en identidad son documentos de políticas de permisos JSON que puede asociar
a una identidad, como por ejemplo un usuario, un rol o un grupo de IAM. Estas políticas controlan qué
acciones puede realizar dicha identidad, en qué recursos y en qué condiciones. Para obtener más
información acerca de cómo crear una política basada en identidad, consulte Creación de políticas de IAM
Las políticas basadas en identidad pueden clasificarse además como políticas insertadas o políticas
administradas. Las políticas insertadas se integran directamente en un único usuario, grupo o rol. Las
políticas administradas son políticas independientes que puede asociar a varios usuarios, grupos y roles
de su cuenta de AWS. Las políticas administradas incluyen las políticas administradas por AWS y las
políticas administradas por el cliente. Para obtener más información acerca de cómo elegir una política
administrada o una política insertada, consulte Elegir entre políticas administradas y políticas insertadas en
la Guía del usuario de IAM.
Las siguientes políticas administradas por AWS, que puede asociar a los usuarios de su cuenta, son
específicas de Amazon Aurora:
• AmazonRDSReadOnlyAccess: concede acceso de solo lectura a todos los recursos de –Amazon Aurora
de la cuenta raíz de AWS especificada.
• AmazonRDSFullAccess: concede acceso completo a todos los recursos de –Amazon Aurora de la
cuenta raíz de AWS especificada.
Otros tipos de políticas

AWS admite otros tipos de políticas menos frecuentes. Estos tipos de políticas pueden establecer el
máximo de permisos que los tipos de políticas más frecuentes le otorgan.
• Límites de permisos: un límite de permisos es una característica avanzada que le permite definir los
permisos máximos que una política basada en identidad puede conceder a una entidad de IAM (usuario
o rol de IAM). Puede establecer un límite de permisos para una identidad. Los permisos resultantes son
la intersección de las políticas basadas en identidades de la entidad y los límites de sus permisos. Las
políticas basadas en recursos que especifiquen el usuario o rol en el campo Principal no estarán
restringidas por el límite de permisos. Una denegación explícita en cualquiera de estas políticas anulará
el permiso. Para obtener más información acerca de los límites de permisos, consulte see Límites de
permisos para las entidades de IAM en la Guía del usuario de IAM.
• Políticas de control de servicios (SCP): las SCP son políticas de JSON que especifican los permisos
máximos para una organización o unidad organizativa (OU) en AWS Organizations. AWS Organizations

166
Funcionamiento de Amazon Aurora con IAM
es un servicio que le permite agrupar y administrar de forma centralizada varias cuentas de AWS
que posee su negocio. Si habilita todas las funciones en una organización, entonces podrá aplicar
políticas de control de servicio (SCP) a una o todas sus cuentas. Una SCP limita los permisos para las
entidades de las cuentas de miembros, incluido cada Usuario de la cuenta raíz de AWS. Para obtener
más información acerca de Organizaciones y las SCP, consulte Funcionamiento de las SCP en la Guía
del usuario de AWS Organizations.
• Políticas de sesión: las políticas de sesión son políticas avanzadas que se pasan como parámetro
cuando se crea una sesión temporal mediante programación para un rol o un usuario federado. Los
permisos de la sesión resultantes son la intersección de las políticas basadas en identidades del rol y las
políticas de la sesión. Los permisos también pueden proceder de una política basada en recursos. Una
denegación explícita en cualquiera de estas políticas anulará el permiso. Para obtener más información,
consulte Políticas de sesión en la Guía del usuario de IAM.
Varios tipos de políticas

Cuando se aplican varios tipos de políticas a una solicitud, los permisos resultantes son más complicados
de entender. Para obtener información acerca de cómo AWS determina si permitir una solicitud cuando
hay varios tipos de políticas implicados, consulte Lógica de evaluación de políticas en la Guía del usuario
de IAM.
Para obtener más información acerca de la administración de identidades y acceso para Aurora, continúe
con las páginas siguientes:
• Funcionamiento de Amazon Aurora con IAM (p. 167)

• Solución de problemas de identidad y acceso en Amazon Aurora (p. 197)

Antes de utilizar IAM para administrar el acceso a Aurora, debe saber qué características de IAM están
disponibles para su uso con Aurora. Para obtener una perspectiva general de cómo Aurora y otros
servicios de AWS funcionan con IAM, consulte Servicios de AWS que funcionan con IAM en la Guía del
usuario de IAM.
Temas
• Políticas basadas en la identidad de Aurora (p. 167)
• Políticas basadas en recursos de Aurora (p. 169)
• Autorización basada en etiquetas de Aurora (p. 169)
• Roles de IAM de Aurora (p. 169)
Políticas basadas en la identidad de Aurora

Con las políticas basadas en identidad de IAM, puede especificar las acciones permitidas o denegadas y
los recursos además de las condiciones en las que se permiten o deniegan las acciones. Aurora admite
acciones, recursos y claves de condiciones específicos. Para obtener más información acerca de los
elementos que utiliza en una política de JSON, consulte Referencia de los elementos de las políticas de
JSON de IAM en la Guía del usuario de IAM.
Actions
El elemento Action de una política basada en la identidad de IAM describe la acción o las acciones
específicas que la política permitirá o denegará. Las acciones de la política generalmente tienen el mismo
nombre que la operación de API de AWS asociada. La acción se utiliza en una política para otorgar
permisos para realizar la operación asociada.

167
Las acciones de políticas de Aurora utilizan el siguiente prefijo antes de la acción: rds:. Por ejemplo,
para conceder a alguien permiso para eliminar un punto de enlace de Amazon RDS con la operación
de la API DescribeDBInstances de rds:DescribeDBInstances, incluya la acción en su política.
Las instrucciones de política deben incluir un elemento Action o NotAction. Aurora define su propio
conjunto de acciones que describen las tareas que se pueden realizar con este servicio.
Para especificar varias acciones en una única instrucción, sepárelas con comas del siguiente modo:
"Action": [
"rds:action1",
"rds:action2"
Puede utilizar caracteres comodín para especificar varias acciones (*). Por ejemplo, para especificar todas
las acciones que comiencen con la palabra Describe, incluya la siguiente acción:
"Action": "rds:Describe*"
Para ver una lista de acciones de Aurora en la Acciones definidas por Amazon RDSGuía del usuario de
IAM.
Recursos
El elemento Resource especifica el objeto u objetos a los que se aplica la acción. Las instrucciones deben
contener un elemento Resource o NotResource. Especifique un recurso con un ARN o el carácter
comodín (*) para indicar que la instrucción se aplica a todos los recursos.
El recurso de instancia de base de datos tiene el siguiente ARN:
arn:${Partition}:rds:${Region}:${Account}:{ResourceType}/${Resource}
Para obtener más información acerca del formato de los ARN, consulte Nombres de recursos de Amazon
(ARN) y espacios de nombres de servicios de AWS.
Por ejemplo, para especificar la instancia de base de datos dbtest en su instrucción, utilice el siguiente
ARN:
"Resource": "arn:aws:rds:us-west-2:123456789012:db:dbtest"
Para especificar todas las instancias de base de datos que pertenecen a una cuenta específica, utilice el
carácter comodín (*):
"Resource": "arn:aws:ec2:us-east-1:123456789012:db:*"
Algunas acciones de API de RDS, como las empleadas para la creación de recursos, no se pueden llevar a
cabo en un recurso específico. En dichos casos, debe utilizar el carácter comodín (*).
"Resource": "*"
En muchas acciones de la API de Amazon RDS se utilizan varios recursos. Por ejemplo,
CreateDBInstance crea una instancia de base de datos. Puede especificar que un usuario de IAM debe
usar un grupo de seguridad y un grupo de parámetros específicos al crear una instancia de base de datos.
Para especificar varios recursos en una única instrucción, separe los ARN con comas.
"Resource": [

168
"resource1",
"resource2"
Para ver una lista de los tipos de recursos de Aurora y sus ARN, consulte Recursos definidos por Amazon
RDS en la Guía del usuario de IAM. Para obtener información acerca de con qué acciones puede
especificar los ARN de cada recurso, consulte Acciones definidas por Amazon RDS.
Claves de condición
El elemento Condition (o bloque de Condition) permite especificar condiciones en las que entra en
vigor una instrucción. El elemento Condition es opcional. Puede crear expresiones condicionales que
utilizan operadores de condición, tales como igual o menor que, para que coincida la condición de la
política con valores de la solicitud.
Si especifica varios elementos de Condition en una instrucción o varias claves en un único elemento de
Condition, AWS las evalúa mediante una operación AND lógica. Si especifica varios valores para una
única clave de condición, AWS evalúa la condición con una operación lógica OR. Se deben cumplir todas
las condiciones antes de que se concedan los permisos de la instrucción.
También puede utilizar variables de marcador de posición al especificar condiciones. Por ejemplo, puede
conceder un permiso de usuario de IAM para acceder a un recurso solo si está etiquetado con su nombre
de usuario de IAM. Para obtener más información, consulte Elementos de la política de IAM: Variables y
etiquetas en la Guía del usuario de IAM.
Aurora define su propio conjunto de claves de condición y también admite el uso de algunas claves de
condición globales. Para ver todas las claves de condición globales de AWS, consulte Claves de contexto
de condición globales de AWS en la Guía del usuario de IAM.
Todas las acciones de API de RDS admiten la clave de condición aws:RequestedRegion.
Para ver una lista de claves de condición de Aurora, consulte Claves de condición de Amazon RDS en la
Guía del usuario de IAM. Para obtener más información acerca de las acciones y los recursos con los que
puede utilizar una clave de condición, consulte Acciones definidas por Amazon RDS.
Ejemplos
Para ver ejemplos de políticas basadas en identidad de Aurora, consulte Ejemplos de políticas basadas en
identidad de Amazon Aurora (p. 170).
Políticas basadas en recursos de Aurora

Aurora no admite las políticas basadas en recursos.
Autorización basada en etiquetas de Aurora

Puede adjuntar etiquetas a los recursos de Aurora o transferirlas en una solicitud a Aurora. Para
controlar el acceso según las etiquetas, debe proporcionar información de las etiquetas en el elemento
de condición de una política mediante las claves de condición rds:ResourceTag/key-name,
aws:RequestTag/key-name o aws:TagKeys. Para obtener más información acerca del etiquetado de
recursos de Aurora, consulte Especificación de condiciones: uso de etiquetas personalizadas (p. 177).
Para ver un ejemplo de política basada en la identidad para limitar el acceso a un recurso basado en las
etiquetas de dicho recurso, consulte Conceda permiso para acciones en un recurso con una etiqueta
específica con dos valores diferentes. (p. 175).
Roles de IAM de Aurora

Un rol de IAM es una entidad de la cuenta de AWS que dispone de permisos específicos.

169
Ejemplos de políticas basadas en identidad
Uso de credenciales temporales con Aurora

Puede utilizar credenciales temporales para iniciar sesión con federación, asumir un rol de IAM o asumir un
rol de acceso entre cuentas. Las credenciales de seguridad temporales se obtienen mediante una llamada
a operaciones de la API de AWS STS, como AssumeRole o GetFederationToken.
Aurora admite el uso de credenciales temporales.
Roles vinculados a servicios

Los roles vinculados a servicios permiten a los servicios de AWS obtener acceso a los recursos de otros
servicios para completar una acción en su nombre. Los roles vinculados a servicios aparecen en la cuenta
de IAM y son propiedad del servicio. Un administrador de IAM puede ver, pero no editar, los permisos de
los roles vinculados a servicios.
Aurora admite roles vinculados a servicios. Para obtener más información acerca de cómo crear o
administrar roles vinculados a servicios de Aurora, consulte Uso de roles vinculados a servicios en Amazon
Aurora (p. 207).
Roles de servicio
Esta característica permite que un servicio asuma un rol de servicio en nombre de usted. Este rol permite
que el servicio obtenga acceso a los recursos de otros servicios para completar una acción en su nombre.
Los roles de servicio aparecen en su cuenta de IAM y son propiedad de la cuenta. Esto significa que un
administrador de IAM puede cambiar los permisos de este rol. Sin embargo, hacerlo podría deteriorar la
funcionalidad del servicio.
Aurora admite roles de servicio.
Ejemplos de políticas basadas en identidad de

Amazon Aurora
De forma predeterminada, los usuarios y roles de IAM no tienen permiso para crear, ver ni modificar
recursos de Aurora. Tampoco pueden realizar tareas mediante la Consola de administración de AWS, la
AWS CLI, o la API de AWS. Un administrador de IAM debe crear políticas de IAM que concedan permisos
a los usuarios y a los roles para realizar operaciones de la API concretas en los recursos especificados
que necesiten. El administrador debe adjuntar esas políticas a los usuarios o grupos de IAM que necesiten
esos permisos.
Para obtener más información acerca de cómo crear una política basada en identidad de IAM con estos
documentos de políticas de JSON de ejemplo, consulte Creación de políticas en la pestaña JSON en la
Guía del usuario de IAM.
Temas
• Prácticas recomendadas relativas a políticas (p. 171)
• Mediante la consola de Aurora (p. 171)
• Permitir a los usuarios ver sus propios permisos (p. 171)
• Permitir a un usuario crear en instancias de base de datos en una cuenta de AWS (p. 172)
• Permisos necesarios para usar la consola (p. 173)
• Permitir que un usuario realice cualquier acción Describe con cualquier recurso de RDS (p. 174)
• Permitir que un usuario cree una instancia de base de datos que utiliza los grupos de seguridad y de
parámetros de base de datos especificados (p. 174)
• Conceda permiso para acciones en un recurso con una etiqueta específica con dos valores
diferentes. (p. 175)

170
• Evitar que un usuario elimine una instancia de base de datos (p. 175)
• Políticas de ejemplo: uso de claves de condición (p. 175)
• Especificación de condiciones: uso de etiquetas personalizadas (p. 177)
Prácticas recomendadas relativas a políticas

Las políticas basadas en identidad son muy eficaces. Determinan si alguien puede crear, acceder o
eliminar los recursos de Aurora de su cuenta. Estas acciones pueden generar costes adicionales para su
cuenta de AWS. Siga estas directrices y recomendaciones al crear o editar políticas basadas en identidad:
• Introducción sobre el uso de políticas administradas de AWS: para comenzar a utilizar Aurora
rápidamente, utilice las políticas administradas de AWS para proporcionar a los empleados los permisos
necesarios. Estas políticas ya están disponibles en su cuenta y las mantiene y actualiza AWS. Para
obtener más información, consulte Introducción sobre el uso de permisos con políticas administradas de
AWS en la Guía del usuario de IAM.
• Conceder privilegios mínimos: al crear políticas personalizadas, conceda solo los permisos necesarios
para llevar a cabo una tarea. Comience con un conjunto mínimo de permisos y conceda permisos
adicionales según sea necesario. Por lo general, es más seguro que comenzar con permisos que son
demasiado tolerantes e intentar hacerlos más severos más adelante. Para obtener más información,
consulte Conceder privilegios mínimos en la Guía del usuario de IAM.
• Habilitar MFA para operaciones confidenciales: para mayor seguridad, obligue a los usuarios de
IAM a que utilicen la autenticación multifactor (MFA) para acceder a recursos u operaciones de API
confidenciales. Para obtener más información, consulte Uso de Multi-Factor Authentication (MFA) en
AWS en la Guía del usuario de IAM.
• Utilizar condiciones de política para mayor seguridad: en la medida en que sea práctico, defina las
condiciones en las que sus políticas basadas en identidad permitan el acceso a un recurso. Por ejemplo,
puede escribir condiciones para especificar un rango de direcciones IP permitidas desde el que debe
proceder una solicitud. También puede escribir condiciones para permitir solicitudes solo en un intervalo
de hora o fecha especificado o para solicitar el uso de SSL o MFA. Para obtener más información,
consulte Elementos de la política de JSON de IAM: condición en la Guía del usuario de IAM.
Mediante la consola de Aurora

Para acceder a la consola de Amazon Aurora, debe tener un conjunto mínimo de permisos. Estos
permisos deben permitirle registrar y consultar los detalles sobre los recursos de Aurora en su cuenta
de AWS. Puede crear una política basada en identidades que sea más restrictiva que los permisos
mínimos requeridos. Sin embargo, si lo hace, la consola no funciona de la forma pretendida para entidades
(usuarios o roles de IAM) con dicha política.
Para asegurarse de que esas entidades puedan seguir usando la consola de Aurora, asocie también la
política administrada de AWS siguiente a las entidades. Para obtener más información, consulte Adición de
permisos a un usuario en la Guía del usuario de IAM:
AmazonRDSReadOnlyAccess
No es necesario que conceda permisos mínimos para la consola a los usuarios que solo realizan llamadas
a la AWS CLI o a la API de AWS. En su lugar, permite acceso únicamente a las acciones que coincidan
con la operación de API que intenta realizar.
Permitir a los usuarios ver sus propios permisos

En este ejemplo, se muestra cómo podría crear una política que permita a los usuarios de IAM ver las
políticas administradas e insertadas que se asocian a la identidad de sus usuarios. Esta política incluye

171
permisos para llevar a cabo esta acción en la consola o mediante programación con la AWS CLI o la API
de AWS.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "ViewOwnUserInfo",
"Effect": "Allow",
"Action": [
"iam:GetUserPolicy",
"iam:ListGroupsForUser",
"iam:ListAttachedUserPolicies",
"iam:ListUserPolicies",
"iam:GetUser"
],
"Resource": [
"arn:aws:iam::*:user/${aws:username}"
]
},
{
"Sid": "NavigateInConsole",
"Effect": "Allow",
"Action": [
"iam:GetGroupPolicy",
"iam:GetPolicyVersion",
"iam:GetPolicy",
"iam:ListAttachedGroupPolicies",
"iam:ListGroupPolicies",
"iam:ListPolicyVersions",
"iam:ListPolicies",
"iam:ListUsers"
],
"Resource": "*"
}
]
}
Permitir a un usuario crear en instancias de base de datos en una

cuenta de AWS
A continuación se muestra un ejemplo de una política que permite al usuario con el ID 123456789012
crear instancias de base de datos para una cuenta de AWS. La política requiere que el nombre de la nueva
instancia de base de datos comience por test. La nueva instancia de base de datos también debe utilizar
el motor de base de datos MySQL y la clase de instancia de base de datos db.t2.micro. Además, la
nueva instancia de base de datos debe usar un grupo de opciones y un grupo de parámetros de base de
datos que comience por default y debe utilizar el grupo de subred default.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowCreateDBInstanceOnly",
"Effect": "Allow",
"Action": [
"rds:CreateDBInstance"
],
"Resource": [
"arn:aws:rds:*:123456789012:db:test*",
"arn:aws:rds:*:123456789012:og:default*",

172
"arn:aws:rds:*:123456789012:pg:default*",
"arn:aws:rds:*:123456789012:subgrp:default"
],
"Condition": {
"StringEquals": {
"rds:DatabaseEngine": "mysql",
"rds:DatabaseClass": "db.t2.micro"
}
}
}
]
}
En la política se incluye una sola instrucción que especifica los siguientes permisos para el usuario de IAM:
• La política permite al usuario de IAM crear una instancia de base de datos utilizando la acción
CreateDBInstance de la API (esto también se aplica al comando create-db-instance de la AWS CLI y a la
Consola de administración de AWS).
• El elemento Resource especifica que el usuario puede realizar acciones en o con recursos. Puede
especificar los recursos mediante un nombre de recurso de Amazon (ARN). Este ARN incluye el nombre
del servicio al que pertenece el recurso (rds), la región de AWS (* indica cualquier región de este
ejemplo), el número de cuenta de usuario (123456789012 es el ID de usuario de este ejemplo) y el
tipo de recurso. Para obtener más información acerca de la creación de nombres ARN, consulte Uso de
nombres de recursos de Amazon (ARN) en Amazon RDS (p. 354).
El elemento Resource del ejemplo especifica las siguientes restricciones políticas en los recursos del
usuario:
• El identificador de instancias de bases de datos para la nueva instancia de base de datos debe
comenzar por test (por ejemplo, testCustomerData1, test-region2-data).
• El grupo de opciones de la nueva instancia de base de datos debe empezar por default.
• El grupo de parámetros de base de datos de la nueva instancia de base de datos debe empezar por
default.
• El grupo de subred de la nueva instancia de base de datos debe ser el grupo de subred default.
• El elemento Condition especifica que el motor de base de datos debe ser MySQL, mientras que la
clase de instancia de base de datos debe ser db.t2.micro. El elemento Condition especifica las
condiciones en las que se debe aplicar una política. Puede añadir permisos o restricciones adicionales
mediante el elemento Condition. Para obtener más información acerca de cómo especificar
condiciones, consulte Claves de condición (p. 169).
La política no especifica el elemento Principal, ya que en una política basada en la identidad no se

especifica el elemento principal que obtiene el permiso. Al asociar una política a un usuario, el usuario
es la entidad principal implícita. Cuando se asocia una política de permisos a un rol de IAM, la entidad
principal identificada en la política de confianza del rol obtiene los permisos.
IAM.
Permisos necesarios para usar la consola

Para que un usuario pueda trabajar con la consola, debe tener un conjunto mínimo de permisos. Estos
permisos dejan al usuario describir los recursos de Amazon Aurora de su cuenta de AWS y proporcionar
otra información relacionada, incluida información de red y seguridad de Amazon EC2.
Si crea una política de IAM que sea más restrictiva que el mínimo de permisos necesarios, la
consola no funciona del modo esperado para los usuarios con esa política de IAM. Para asegurarse
de que esos usuarios puedan seguir usando la consola, asocie también la política administrada

173
AmazonRDSReadOnlyAccess al usuario, según se explica en Administración de acceso mediante

políticas (p. 165).
No es necesario que conceda permisos mínimos para la consola a los usuarios que solo realizan llamadas
a la AWS CLI o a la API de Amazon RDS.
La siguiente política concede acceso completo a todos los recursos de Amazon Aurora para la cuenta de
AWS raíz:
AmazonRDSFullAccess
Permitir que un usuario realice cualquier acción Describe con

cualquier recurso de RDS
La siguiente política de permisos concede permisos a un usuario para ejecutar todas las acciones que
empiezan por Describe. Estas acciones muestran información acerca de un recurso de RDS, como una
instancia de base de datos. El carácter de comodín (*) en el elemento Resource indica que las acciones
están permitidas para todos los recursos de Amazon Aurora que pertenecen a la cuenta.
{
"Version":"2012-10-17",
"Statement":[
{
"Sid":"AllowRDSDescribe",
"Effect":"Allow",
"Action":"rds:Describe*",
"Resource":"*"
}
]
}
Permitir que un usuario cree una instancia de base de datos que

utiliza los grupos de seguridad y de parámetros de base de datos
especificados
La política de permisos siguiente concede permisos para permitir que un usuario solo pueda crear una
instancia de base de datos que utilice el grupo de parámetros de base de datos mysql-production y el
grupo de seguridad de base de datos db-production.
{
"Version":"2012-10-17",
"Statement":[
{
"Sid":"AllowMySQLProductionCreate",
"Effect":"Allow",
"Action":"rds:CreateDBInstance",
"Resource":[
"arn:aws:rds:us-west-2:123456789012:pg:mysql-production",
"arn:aws:rds:us-west-2:123456789012:secgrp:db-production"
]
}
]
}

174
Conceda permiso para acciones en un recurso con una etiqueta

específica con dos valores diferentes.
Puede utilizar las condiciones de su política basada en la identidad para controlar el acceso a los recursos
de Aurora basados en etiquetas. La siguiente política da permiso para aplicar las API ModifyDBInstance
y CreateDBSnapshot en instancias con la etiqueta stage establecida en development o en test.
{
"Version":"2012-10-17",
"Statement":[
{
"Sid":"AllowDevTestCreate",
"Effect":"Allow",
"Action":[
"rds:ModifyDBInstance",
"rds:CreateDBSnapshot"
],
"Resource":"*",
"Condition":{
"StringEquals":{
"rds:db-tag/stage":[
"development",
"test"
]
}
}
}
]
}
Evitar que un usuario elimine una instancia de base de datos

La siguiente política de permisos concede permisos para impedir que un usuario elimine una instancia de
base de datos específica. Por ejemplo, puede servir para impedir la eliminación de instancias de base de
datos de producción a cualquier usuario que no sea un administrador.
{
"Version":"2012-10-17",
"Statement":[
{
"Sid":"DenyDelete1",
"Effect":"Deny",
"Action":"rds:DeleteDBInstance",
"Resource":"arn:aws:rds:us-west-2:123456789012:db:my-mysql-instance"
}
]
}
Políticas de ejemplo: uso de claves de condición

Los siguientes ejemplos muestran cómo puede usar claves de condición en las políticas de permisos de
IAM para Amazon Aurora.
Ejemplo 1: conceda permiso para crear una instancia de base de datos que utilice
un motor de base de datos específico y no sea Multi-AZ.
La siguiente política utiliza una clave de condición de RDS y permite al usuario crear solamente instancias
de base de datos que utilizan el motor de base de datos MySQL y no utilizan Multi-AZ. El elemento
Condition indica el requisito de que el motor de base de datos sea MySQL.

175
"Version":"2012-10-17",
"Statement":[
{
"Sid":"AllowMySQLCreate",
"Effect":"Allow",
"Resource":"*",
"Condition":{
"StringEquals":{
"rds:DatabaseEngine":"mysql"
},
"Bool":{
"rds:MultiAz": false
}
}
}
]
}
Ejemplo 2: deniegue permiso explícitamente para crear instancias de base de

datos para determinadas clases de instancia de base de datos y crear instancias
de base de datos que utilizan IOPS provisionadas
La siguiente política deniega permiso explícitamente para crear instancias de base de datos que utilizan
las clases de instancia de base de datos r3.8xlarge y m4.10xlarge, que son las clases de instancia
de base de datos más costosas y de mayor tamaño. Esta política también evita que los usuarios creen
instancias de base de datos que utilizan IOPS provisionadas, las cuales tienen un costo adicional.
Al denegarse permiso explícitamente se sustituye a cualquier otro permiso concedido. Esto garantiza que
las identidades no obtengan accidentalmente permisos que el usuario no desee conceder nunca.
{
"Version":"2012-10-17",
"Statement":[
{
"Sid":"DenyLargeCreate",
"Effect":"Deny",
"Resource":"*",
"Condition":{
"StringEquals":{
"rds:DatabaseClass":[
"db.r3.8xlarge",
"db.m4.10xlarge"
]
}
}
},
{
"Sid":"DenyPIOPSCreate",
"Effect":"Deny",
"Resource":"*",
"Condition":{
"NumericNotEquals":{
"rds:Piops":"0"
}
}
}
]

176
Ejemplo 3: limitar el conjunto de claves y valores de etiquetas que se pueden usar

para etiquetar un recurso
En la siguiente política se usa una clave condicional de RDS y permite añadir una etiqueta con la clave
stage a un recurso con los valores test, qa y production.
{
"Version" : "2012-10-17",
"Statement" : [{
"Effect" : "Allow",
"Action" : [ "rds:AddTagsToResource", "rds:RemoveTagsFromResource"
],
"Resource" : "*",
"Condition" : { "streq" : { "rds:req-tag/stage" : [ "test", "qa",
"production" ] } }
}
]
}
}
Especificación de condiciones: uso de etiquetas personalizadas

Amazon Aurora admite la especificación de condiciones en una política de IAM que utiliza etiquetas
personalizadas.
Por ejemplo, suponga que añade una etiqueta con el nombre environment a sus instancias de base
de datos con valores como beta, staging, production, etc. Si lo hace, puede crear una política
que restrinja a ciertos usuarios en instancias de bases de datos basándose en el valor de la etiqueta
environment.
Note
Los identificadores de etiquetas personalizados distinguen entre mayúsculas y minúsculas.
En la tabla siguiente, se enumeran los identificadores de etiqueta de RDS que puede usar en un elemento
Condition.
Identificador de etiqueta de RDS Se aplica a
db-tag Instancias de base de datos, incluidas las réplicas

de lectura
snapshot-tag Instantáneas de base de datos
ri-tag Instancias de base de datos reservadas
secgrp-tag Grupos de seguridad de base de datos
og-tag Grupos de opciones de base de datos
pg-tag Grupos de parámetros de base de datos
subgrp-tag Grupos de subred de base de datos
es-tag Suscripciones de eventos

177
Identificador de etiqueta de RDS Se aplica a
cluster-tag Clústeres de base de datos
cluster-pg-tag Grupos de parámetros de clúster de base de datos
cluster-snapshot-tag Instantáneas de clúster de base de datos
La sintaxis de una condición de etiqueta personalizada es la siguiente:
"Condition":{"StringEquals":{"rds:rds-tag-identifier/tag-name": ["value"]} }
Por ejemplo, el elemento Condition siguiente se aplica a instancias de base de datos con una etiqueta
llamada environment y un valor de etiqueta production.
"Condition":{"StringEquals":{"rds:db-tag/environment": ["production"]} }
Para obtener información acerca de la creación etiquetas, consulte Etiquetado de recursos de Amazon
RDS (p. 349).
Important
Si administra el acceso a sus recursos de RDS mediante el etiquetado, recomendamos que
proteja el acceso a las etiquetas. Puede administrar el acceso a etiquetas creando políticas para
las acciones AddTagsToResource y RemoveTagsFromResource. Por ejemplo, la política
siguiente deniega a los usuarios la posibilidad de agregar o quitar etiquetas para todos los
recursos. A continuación, puede crear políticas para permitir que usuarios específicos agreguen o
quiten etiquetas.
{
"Version":"2012-10-17",
"Statement":[
{
"Sid":"DenyTagUpdates",
"Effect":"Deny",
"Action":[
"rds:AddTagsToResource",
"rds:RemoveTagsFromResource"
],
"Resource":"*"
}
]
}
IAM.
Políticas de ejemplo: uso de etiquetas personalizadas

Los siguientes ejemplos muestran cómo puede usar etiquetas personalizadas en las políticas de permisos
de IAM para Amazon Aurora. Para obtener más información sobre cómo agregar etiquetas a un recurso de
Amazon Aurora, consulte Uso de nombres de recursos de Amazon (ARN) en Amazon RDS (p. 354).
Note
Todos los ejemplos utilizan la región us-west-2 y contienen identificadores de cuenta ficticios.
Ejemplo 1: conceda permiso para acciones en un recurso con una etiqueta específica con dos
valores diferentes.
La siguiente política da permiso para aplicar las API ModifyDBInstance y CreateDBSnapshot en
instancias con la etiqueta stage establecida en development o en test.

178
{
"Version":"2012-10-17",
"Statement":[
{
"Sid":"AllowDevTestCreate",
"Effect":"Allow",
"Action":[
"rds:ModifyDBInstance",
"rds:CreateDBSnapshot"
],
"Resource":"*",
"Condition":{
"StringEquals":{
"rds:db-tag/stage":[
"development",
"test"
]
}
}
}
]
}
Ejemplo 2: deniegue explícitamente permiso para crear una instancia de base de datos que utilice
grupos de parámetros de base de datos especificados.
La siguiente política deniega explícitamente permiso para crear una instancia de base de datos que utilice
grupos de parámetros de base de datos con valores de etiqueta específicos. Podría aplicar esta política si
necesita que se utilice siempre un grupo de parámetros de base de datos específico, creado por el cliente,
al crear instancias de base de datos. Las políticas que utilizan Deny suelen aplicarse para restringir el
acceso concedido por una política más amplia.
Al denegarse permiso explícitamente se sustituye a cualquier otro permiso concedido. Esto garantiza que
las identidades no obtengan accidentalmente permisos que el usuario no desee conceder nunca.
{
"Version":"2012-10-17",
"Statement":[
{
"Sid":"DenyProductionCreate",
"Effect":"Deny",
"Resource":"*",
"Condition":{
"StringEquals":{
"rds:pg-tag/usage":"prod"
}
}
}
]
}
Ejemplo 3: conceda permiso para acciones en una instancia de base de datos con un nombre de
instancia cuyo prefijo sea un nombre de usuario.
La siguiente política da permiso para llamar a cualquier API (salvo AddTagsToResource o
RemoveTagsFromResource) en una instancia de base de datos cuyo prefijo sea un nombre de usuario y
que tenga una etiqueta llamada stage igual a devo o que no tenga ninguna etiqueta llamada stage.
La línea Resource en la política identifica un recurso por su nombre de recurso de Amazon (ARN). Para
obtener más información sobre el uso de ARN con recursos de Amazon Aurora, consulte Uso de nombres
de recursos de Amazon (ARN) en Amazon RDS (p. 354).

179
Autenticación de bases de datos de IAM
{
"Version":"2012-10-17",
"Statement":[
{
"Sid":"AllowFullDevAccessNoTags",
"Effect":"Allow",
"NotAction":[
"rds:AddTagsToResource",
"rds:RemoveTagsFromResource"
],
"Resource":"arn:aws:rds:*:123456789012:db:${aws:username}*",
"Condition":{
"StringEqualsIfExists":{
"rds:db-tag/stage":"devo"
}
}
}
]
}

Puede autenticarse en su clúster de base de datos utilizando la autenticación de base de datos de AWS
Identity and Access Management (IAM). La autenticación de base de datos de IAM funciona conAurora
MySQL y Aurora PostgreSQL. Con este método de autenticación, no es necesario usar una contraseña al
conectarse a un clúster de base de datos. En su lugar, puede usar un token de autenticación.
Un token de autenticación es una cadena única de caracteres que genera Amazon Aurora bajo demanda.
Los tokens de autenticación se generan mediante AWS Signature Version 4. Cada token tiene una
vida útil de 15 minutos. No es necesario almacenar credenciales de usuario en la base de datos, ya
que la autenticación se administra de forma externa mediante IAM. También puede seguir utilizando la
autenticación de base de datos estándar.
La autenticación de bases de datos de IAM proporciona los siguientes beneficios:
• El tráfico de red hacia y desde la base de datos se cifra mediante Capa de conexión segura (SSL).
• Puede usar IAM para administrar de forma centralizada el acceso a sus recursos de base de datos, en
lugar de administrar el acceso individualmente en cada clúster de base de datos.
• Para las aplicaciones que se ejecutan en Amazon EC2, puede usar las credenciales del perfil
específicas de la instancia EC2 para obtener acceso a su base de datos en lugar de una contraseña,
para mayor seguridad.
Temas
• Disponibilidad para la autenticación de bases de datos de IAM (p. 180)
• Limitaciones de MySQL a la autenticación de bases de datos de IAM (p. 181)
• Limitaciones de PostgreSQL a la autenticación de bases de datos de IAM (p. 181)
• Activación y desactivación de la autenticación de bases de datos de IAM (p. 181)
• Creación y uso de una política de IAM para el acceso a bases de datos de IAM (p. 183)
• Creación de cuentas de base de datos utilizando autenticación de IAM (p. 186)
• Conexión al clúster de base de datos con la autenticación de IAM (p. 187)
Disponibilidad para la autenticación de bases de datos de IAM

La autenticación de bases de datos de IAM está disponible para los siguientes motores de base de datos y
clases de instancia de base de datos:

180
• Compatibilidad de Aurora con MySQL versión 1.10 o superior. Todas las clases de instancia de base de
datos son compatibles, excepto db.t2.small y db.t3.small.
• Compatibilidad de Aurora con PostgreSQL, PostgreSQL versiones 9.6.9 y 10.4 o superior.
Limitaciones de MySQL a la autenticación de bases de datos de

IAM
Al usar la autenticación de bases de datos de IAM con MySQL, se puede crear un máximo de 256 nuevas
conexiones por segundo. .
Los motores de base de datos que funcionan con Amazon Aurora no imponen ninguna restricción a
los intentos de autenticación por segundo. Sin embargo, al usar la autenticación de bases de datos de
IAM, su aplicación debe generar un token de autenticación. A continuación, su aplicación usa ese token
para conectarse a el clúster de base de datos. Si supera el límite máximo de nuevas conexiones por
segundo, la sobrecarga adicional de la autenticación de bases de datos de IAM puede dar lugar a la
limitación controlada de las conexiones. La sobrecarga adicional incluso puede dar lugar incluso a la
caída de las conexiones existentes. Para obtener información acerca del máximo de conexiones totales
para Aurora MySQL, consulte Número máximo de conexiones a una instancia de base de datos Aurora
MySQL (p. 545).
Le recomendamos las siguientes prácticas al usar el motor MySQL:
• Use la autenticación de bases de datos de IAM como mecanismo para el acceso temporal y personal a
las bases de datos.
• Use la autenticación de bases de datos de IAM solo para las cargas de trabajo que se puedan reintentar
con facilidad.
• No use la autenticación de bases de datos de IAM si su aplicación requiere más de 256 nuevas
conexiones por segundo.
Limitaciones de PostgreSQL a la autenticación de bases de datos

de IAM
Al utilizar la autenticación de base de datos de IAM con PostgreSQL, tenga en cuenta la siguiente
limitación:
• El número máximo de conexiones por segundo para el clúster de la base de datos podría estar limitado
en función del tipo de clúster y su carga de trabajo.
Activación y desactivación de la autenticación de bases de datos

de IAM
De forma predeterminada, la autenticación de bases de datos de IAM está deshabilitada en los clústeres
de base de datos. Puede habilitar la autenticación de bases de datos de IAM (o deshabilitarla de nuevo)
mediante la Consola de administración de AWS, la AWS CLI o la API.

Para crear un clúster de base de datos con la autenticación de IAM mediante la consola, consulte Creación
de un clúster de base de datos de Amazon Aurora (p. 85).
Cada flujo de trabajo de creación tiene una página Configure Advanced Settings (Configurar las opciones
avanzadas), donde puede habilitar la autenticación de bases de datos de IAM. En la sección Database
Options de esa página, elija Yes para Enable IAM DB Authentication.

181
Para habilitar o deshabilitar la autenticación de IAM para un clúster de base de datos existente

3. Elija el clúster de base de datos que desea modificar.
4. Elija Modify.
5. En la sección Database options (Opciones de base de datos), en IAM DB authentication (Autenticación
de base de datos de IAM), elija Enable IAM DB authentication (Habilitar autenticación de base de
datos de IAM) o Disable (Deshabilitar) y, a continuación, elija Continue (Continuar).
6. Para aplicar los cambios inmediatamente, elija Apply immediately.
7. Elija Modify cluster (Modificar clúster).
Para restaurar un clúster de base de datos

2. En el panel de navegación, elija Snapshots (Instantáneas).
3. Elija la instantánea que desea restaurar y, a continuación, elija Restore Snapshot (Restaurar
instantánea) para Actions (Acciones).
4. En la sección Settings (Configuración), escriba un identificador para la instancia de base de datos para
DB Instance Identifier (Identificador de instancia de base de datos).
5. En la sección Database options (Opciones de base de datos), en IAM DB authentication (Autenticación
de base de datos de IAM), elija Enable IAM DB authentication (Habilitar autenticación de base de
datos de IAM) o Disable (Deshabilitar).
6. Elija Restore DB Instance (Restaurar instancia de base de datos).
AWS CLI
Para crear un clúster de base de datos nuevo con la autenticación de IAM mediante la AWS CLI, use el
comando create-db-cluster. Especifique la opción --enable-iam-database-authentication.
Para actualizar un clúster de base de datos existente para que tenga o no tenga autenticación de IAM,
utilice el comando modify-db-cluster de la AWS CLI. Especifique la opción --enable-iam-
database-authentication o --no-enable-iam-database-authentication, como proceda.
De forma predeterminada, Aurora realiza la modificación durante el siguiente periodo de mantenimiento.

Si desea invalidar esto y habilitar la autenticación de bases de datos de IAM lo antes posible, use el
parámetro --apply-immediately.
Si restaura un clúster de base de datos, use uno de los siguientes comandos de AWS CLI:
• restore-db-cluster-to-point-in-time
• restore-db-cluster-from-db-snapshot
De forma predeterminada, la configuración de la autenticación de bases de datos de IAM será la de la

instantánea de origen. Para cambiar esta configuración, establezca la opción --enable-iam-database-
authentication o --no-enable-iam-database-authentication, como proceda.
API de RDS
Para crear una instancia de base de datos nueva con la autenticación de IAM mediante la API, use la
operación CreateDBCluster de la API. Defina el parámetro EnableIAMDatabaseAuthentication
como true.

182
Para actualizar un clúster de base de datos existente para que tenga o no tenga autenticación
de IAM, utilice la operación ModifyDBCluster de la API. Establezca el parámetro
EnableIAMDatabaseAuthentication en true para habilitar la autenticación de IAM o en false para
deshabilitarla.
Si restaura un clúster de base de datos, use una de las siguientes acciones de la API:
• RestoreDBClusterToPointInTime
• RestoreDBClusterFromSnapshot
De forma predeterminada, la configuración de la autenticación de bases de datos de IAM

será la de la instantánea de origen. Para cambiar esta configuración, establezca el parámetro
EnableIAMDatabaseAuthentication en true para habilitar la autenticación de IAM o false para
deshabilitarla.
Creación y uso de una política de IAM para el acceso a bases de

datos de IAM
Para permitir a un usuario o rol de IAM conectarse a su clúster de base de datos, debe crear una política
de IAM. Después de eso, puede asociar la política a un usuario o rol de IAM.
Note
Para obtener más información acerca de las políticas de IAM, consulte Administración de
identidad y acceso en Amazon Aurora (p. 163).
La siguiente política de ejemplo permite a un usuario de IAM conectarse a un clúster de base de datos
mediante la autenticación de bases de datos de IAM.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"rds-db:connect"
],
"Resource": [
"arn:aws:rds-db:us-east-2:1234567890:dbuser:cluster-ABCDEFGHIJKL01234/db_user"
]
}
]
}
Note
No confunda el prefijo rds-db: con otros prefijos de acción de la API de RDS que empiezan por
rds:. Puede usar el prefijo rds-db: y la acción rds-db:connect solo para la autenticación de
bases de datos de IAM. No son válidos en ningún otro contexto.
Actualmente, la consola de IAM muestra un error para las políticas con la acción rds-
db:connect. Puede omitir este error.
La política de ejemplo incluye una sola instrucción con los siguientes elementos:
• Effect: especifique Allow para conceder acceso al clúster de base de datos. Si no permite el acceso
de forma explícita, el acceso se deniega de forma predeterminada.
• Action: especifique rds-db:connect para permitir las conexiones al clúster de base de datos.

183
• Resource: especifique un nombre de recurso de Amazon (ARN) que describa una cuenta de base de
datos en un clúster de base de datos. El formato del ARN es el siguiente.
arn:aws:rds-db:region:account-id:dbuser:DbClusterResourceId/db-user-name
En este formato, reemplace lo siguiente:

• region es la región de AWS para el clúster de base de datos. En la política de ejemplo, la región de
AWS es us-east-2.
• account-id es el número de cuenta de AWS para el clúster de base de datos. En la política de
ejemplo, el número de cuenta es 1234567890.
• DbClusterResourceId es el identificador del clúster de base de datos. Este identificador es único
para una región de AWS y nunca cambia. En la política de ejemplo, el identificador es cluster-
ABCDEFGHIJKL01234.
Para encontrar un ID de recurso de clúster de base de datos en la Consola de administración de AWS

para Amazon Aurora, seleccione el clúster de base de datos para ver sus detalles. A continuación,
elija la pestaña Configuration (Configuración). El Resource ID (ID de recurso) se muestra en la sección
Configuration (Configuración).
También puede usar el comando de la AWS CLI para enumerar los identificadores e ID de recurso
para todos sus clústeres de base de datos en la región de AWS actual, como se muestra a
continuación.
aws rds describe-db-clusters --query "DBClusters[*].

[DBClusterIdentifier,DbClusterResourceId]"
• db-user-name es el nombre de la cuenta de base de datos que se asociará a la autenticación de

IAM. En la política de ejemplo, la cuenta de base de datos es db_user.
Puede crear otros ARN que admitan diversos patrones de acceso. La siguiente política permite el acceso a
dos cuentas de base de datos diferentes en un cluster de base de datos.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"rds-db:connect"
],
"Resource": [
"arn:aws:rds-db:us-east-2:123456789012:dbuser:cluster-ABCDEFGHIJKL01234/
jane_doe",
"arn:aws:rds-db:us-east-2:123456789012:dbuser:cluster-ABCDEFGHIJKL01234/
mary_roe"
]
}
]
}
La siguiente política usa el carácter "*" para buscar coincidencias con todos los clústeres de base de datos
y cuentas de base de datos para una cuenta y una región de AWS determinadas.

184
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"rds-db:connect"
],
"Resource": [
"arn:aws:rds-db:us-east-2:1234567890:dbuser:*/*"
]
}
]
}
La siguiente política busca coincidencias con todos los clústeres de base de datos para una cuenta y una
región de AWS determinadas. Sin embargo, la política solo concede acceso a clústeres de base de datos
que tienen una cuenta de base de datos jane_doe.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"rds-db:connect"
],
"Resource": [
"arn:aws:rds-db:us-east-2:123456789012:dbuser:*/jane_doe"
]
}
]
}
El usuario o el rol de IAM solo tiene acceso a las mismas bases de datos que el usuario de la base de
datos. Por ejemplo, suponga que su clúster de base de datos tiene una base de datos denominada dev y
otra llamada test. Si el usuario de base de datos jane_doe solo tiene acceso a dev, cualquier usuario o
rol de IAM que obtenga acceso a ese clúster de base de datos con el usuario jane_doe también tendrá
acceso únicamente a dev. Esta restricción del acceso también se aplica a otros objetos de la base de
datos tales como tablas, vistas, etc.
Asociación de una política de IAM a un usuario o un rol de IAM

Tras crear una política de IAM que permita la autenticación de bases de datos, es necesario asociar la
política a un usuario o un rol de IAM. Para ver un tutorial acerca de este tema, consulte Crear y asociar su
primera política administrada por el cliente en la Guía del usuario de IAM.
Mientras realiza el tutorial, puede usar uno de los ejemplos de política mostrados en esta sección como
punto de partida y adaptarlo a sus necesidades. Al final del tutorial, tiene un usuario de IAM con una
política asociada que puede utilizar la acción rds-db:connect.
Note
Puede asignar varios usuarios o roles de IAM a la misma cuenta de usuario de base de datos. Por
ejemplo, suponga que su política de IAM ha especificado el siguiente ARN del recurso.

185
arn:aws:rds-db:us-east-2:123456789012:dbuser:cluster-12ABC34DEFG5HIJ6KLMNOP78QR/
jane_doe
Si asocia la política a los usuarios de IAM Jane, Bob y Diego, cada uno de dichos usuarios
puede conectarse al clúster de base de datos especificada mediante la cuenta de base de datos
jane_doe.
Creación de cuentas de base de datos utilizando autenticación de

IAM
Con la autenticación de bases de datos de IAM, no es necesario asignar contraseñas de la base de datos
a las cuentas de usuario creadas. Si quita un usuario de IAM asignado a una cuenta de base de datos,
también debe quitar la cuenta de base de datos con la instrucción DROP USER.
Uso de autenticación de IAM con PostgreSQL

Para usar la autenticación de IAM con PostgreSQL, conéctese a el clúster de base de datos, cree usuarios
de base de datos y, a continuación, concédales la función rds_iam como se muestra en el siguiente
ejemplo.
CREATE USER db_userx WITH LOGIN;

GRANT rds_iam TO db_userx;
Uso de autenticación IAM con MySQL

Con MySQL, la autenticación se gestiona mediante AWSAuthenticationPlugin, un complemento
proporcionado por AWS que funciona perfectamente con IAM para autenticar sus usuarios de IAM.
Conéctese al clúster de base de datos y emitir la instrucción CREATE USER, como se muestra en el
siguiente ejemplo.
CREATE USER jane_doe IDENTIFIED WITH AWSAuthenticationPlugin AS 'RDS';
La cláusula IDENTIFIED WITH permite a MySQL usar AWSAuthenticationPlugin para autenticar la

cuenta de base de datos (jane_doe). La cláusula AS 'RDS' hace referencia al método de autenticación
y la cuenta de base de datos especificada debe tener el mismo nombre que el usuario o la rol de IAM. En
este ejemplo, tanto la cuenta de base de datos como el usuario o la rol de IAM deben llamarse jane_doe.
Note
Si ve el siguiente mensaje, significa que el complemento proporcionado por AWS no está

disponible para el clúster de base de datos actual.
ERROR 1524 (HY000): Plugin 'AWSAuthenticationPlugin' is not loaded
Para identificar este error, verifique que usa una configuración admitida y que ha habilitado
la autenticación de bases de datos de IAM en su clúster de base de datos. Para obtener más
información, consulte Disponibilidad para la autenticación de bases de datos de IAM (p. 180) y
Activación y desactivación de la autenticación de bases de datos de IAM (p. 181).
Después de crear una cuenta mediante AWSAuthenticationPlugin, puede administrarla de la misma

forma que otras cuentas de base de datos. Por ejemplo, puede modificar los privilegios de cuenta con las
instrucciones GRANT y REVOKE, o bien modificar diversos atributos de cuenta con la instrucción ALTER
USER.

186
Conexión al clúster de base de datos con la autenticación de IAM

Con la autenticación de bases de datos de IAM, puede usar un token de autenticación al conectarse a su
clúster de base de datos. Un token de autenticación es una cadena de caracteres que usa en lugar de
una contraseña. Después de generar un token de autenticación, será válido durante 15 minutos antes de
caducar. Si intenta conectarse mediante un token caducado, la solicitud de conexión se deniega.
Todos los tokens de autenticación deben ir acompañados de una firma válida, mediante AWS Signature
Version 4 (Para obtener más información, consulte Proceso de firma Signature Version 4 en la AWS
General Reference.) La AWS CLI y AWS SDK for Java pueden firmar automáticamente cada token que se
cree.
Puede utilizar un token de autenticación cuando conecte a Amazon Aurora desde otro servicio de AWS,
como AWS Lambda. Al utilizar un token, puede evitar introducir una contraseña en el código. Además,
puede usar AWS SDK for Java para crear mediante programación un token de autenticación y firmarlo
también mediante programación.
Una vez que tenga un token de autenticación de IAM firmado, podrá conectarse a un clúster de base de
datos de Aurora. A continuación, puede aprender a hacer esto mediante una herramienta de línea de
comandos o el AWS SDK for Java.
Para obtener más información, consulte Use IAM authentication to connect with SQL Workbench/J to
Amazon Aurora MySQL or Amazon RDS for MySQL.
Temas
• Conexión de su clúster de base de datos desde la línea de comandos: AWS CLI y mysql
Client (p. 187)
• Conexión de su clúster de base de datos desde la línea de comandos: AWS CLI y psql Client (p. 189)
• Conexión al clúster de base de datos con la AWS SDK for Java (p. 190)
Conexión de su clúster de base de datos desde la línea de comandos: AWS CLI y

mysql Client
Puede conectarse desde la línea de comando a un clúster de base de datos de Auroracon la AWS CLI y la
herramienta de línea de comandos mysql como se describe a continuación.
Temas
• Generación de un token de autenticación de IAM (p. 187)
• Conexión a su clúster de base de datos (p. 188)
Generación de un token de autenticación de IAM
En el siguiente ejemplo se muestra cómo obtener un token de autenticación firmado mediante la AWS CLI.
aws rds generate-db-auth-token \

--hostname rdsmysql.cdgmuqiadpid.us-west-2.rds.amazonaws.com \
--port 3306 \
--region us-west-2 \
--username jane_doe
En el ejemplo, los parámetros son los siguientes:
• --hostname: el nombre de host del clúster de base de datos a los que desea obtener acceso.

187
• --port: el número de puerto usado para conectarse al clúster de base de datos.

• --region: la región de AWS donde se ejecuta el clúster de base de datos.
• --username: la cuenta de base de datos a la que desea obtener acceso.
Los primeros caracteres del token tienen un aspecto similar al siguiente.
rdsmysql.cdgmuqiadpid.us-west-2.rds.amazonaws.com:3306/?Action=connect&DBUser=jane_doe&X-
Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Expires=900...
Conexión a su clúster de base de datos
El formato general para conectarse se muestra a continuación.
mysql --host=hostName --port=portNumber --ssl-ca=[full path]rds-combined-ca-bundle.pem --

enable-cleartext-plugin --user=userName --password=authToken
Los parámetros son los siguientes:
• --host: el nombre de host del clúster de base de datos a los que desea obtener acceso.
• --port: el número de puerto usado para conectarse a su clúster de base de datos.
• --ssl-ca: el archivo de certificado de SSL que contiene la clave pública. Para obtener más
información, consulte Uso de SSL para cifrar una conexión a un clúster de base de datos (p. 161).
• --enable-cleartext-plugin: un valor que especifica que AWSAuthenticationPlugin debe
usarse para esta conexión.
• --user: la cuenta de base de datos a la que desea obtener acceso.
• --password: un token de autenticación de IAM firmado.
El token de autenticación consta de varios cientos de caracteres. Puede ser difícil de tratar en la línea de
comando. Una forma de solucionar esto es guardar el token en una variable de entorno y, a continuación,
usar esa variable al conectarse. En el siguiente ejemplo se muestra una forma de realizar esta alternativa.
RDSHOST="rdsmysql.cdgmuqiadpid.us-west-2.rds.amazonaws.com"
TOKEN="$(aws rds generate-db-auth-token --hostname $RDSHOST --port 3306 --region us-west-2
--username jane_doe )"
mysql --host=$RDSHOST --port=3306 --ssl-ca=/sample_dir/rds-combined-ca-bundle.pem --enable-

cleartext-plugin --user=jane_doe --password=$TOKEN
Al conectarse mediante AWSAuthenticationPlugin, la conexión está protegida mediante SSL. Para

verificar esto, escriba lo siguiente en el símbolo del sistema mysql>.
show status like 'Ssl%';
En las siguientes líneas de la salida aparecen más detalles.
+---------------+-------------+
| Variable_name | Value
|
+---------------+-------------+

188
| ... | ...
| Ssl_cipher | AES256-SHA
|
| ... | ...
| Ssl_version | TLSv1.1
|
| ... | ...
+-----------------------------+
Conexión de su clúster de base de datos desde la línea de comandos: AWS CLI y

psql Client
Puede conectarse desde la línea de comando a un clúster de base de datos de Aurora PostgreSQL con la
AWS CLI y la herramienta de línea de comandos psql como se describe a continuación.
Temas
• Conexión a un clúster de Aurora PostgreSQL (p. 189)
El token de autenticación consta de varios cientos de caracteres por que puede ser difícil de tratar en
la línea de comando. Una forma de solucionar esto es guardar el token en una variable de entorno y, a
continuación, usar esa variable al conectarse. En el siguiente ejemplo se muestra cómo usar la AWS CLI
para obtener un token de autenticación firmado mediante el comando generated-db-auth-token y
almacenarlo en una variable de entorno PGPASSWORD.
export RDSHOST="mypostgres-cluster.cluster-cdgmuqiadpid.us-west-2.rds.amazonaws.com"
export PGPASSWORD="$(aws rds generate-db-auth-token --hostname $RDSHOST --port 5432 --
region us-west-2 --username jane_doe )"
En el ejemplo, los parámetros para el comando generate-db-auth-token son los siguientes:
• --hostname: el nombre de host del clúster (punto de enlace del clúster) de base de datos a los que
desea obtener acceso.
• --port: el número de puerto usado para conectarse al clúster de base de datos.
• --region: la región de AWS donde se ejecuta el clúster de base de datos.
• --username: la cuenta de base de datos a la que desea obtener acceso.
Los primeros caracteres del token generado tienen un aspecto similar al siguiente.
mypostgres-cluster.cluster-cdgmuqiadpid.us-west-2.rds.amazonaws.com:5432/?
Action=connect&DBUser=jane_doe&X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Expires=900...
Conexión a un clúster de Aurora PostgreSQL
El formato general para usar psql para conectarse se muestra a continuación.
psql "host=hostName port=portNumber sslmode=verify-full sslrootcert=certificateFile

dbname=DBName user=userName"

189
• host: el nombre de host del clúster (punto de enlace del clúster) de base de datos a los que desea
obtener acceso.
• port: el número de puerto usado para conectarse al clúster de base de datos.
• sslmode: el modo de SSL que se debe utilizar. Cuando se utiliza sslmode=verify-full, la conexión
SSL verifica el punto de enlace del clúster de base de datos con respecto al punto de enlace del
certificado SSL.
• sslrootcert: el archivo de certificado de SSL que contiene la clave pública. Para obtener más
información, consulte Uso de SSL con una instancia de base de datos de PostgreSQL.
• dbname: la base de datos a la que desea obtener acceso.
• user: la cuenta de base de datos a la que desea obtener acceso.
El siguiente ejemplo muestra el uso del comando para la conexión. El ejemplo utiliza las variables de
entorno establecidas cuando se generó el token en la sección anterior.
psql "host=$RDSHOST port=5432 sslmode=verify-full sslrootcert=/sample_dir/rds-combined-ca-

bundle.pem dbname=DBName user=jane_doe"
Conexión al clúster de base de datos con la AWS SDK for Java

Puede conectarse desde la línea de comandos a una Aurora MySQL o a un clúster de base de datos
Aurora PostgreSQL con AWS SDK for Java como se describe a continuación.
Temas
• Creación manual de un token de autenticación de IAM (p. 191)
• Conexión a su clúster de base de datos (p. 194)
Si escribe programas mediante AWS SDK for Java, puede obtener un token de autenticación
firmado mediante la clase RdsIamAuthTokenGenerator. El uso de esta clase requiere que
proporcione las credenciales de AWS. Para hacer esto, puede crear una instancia de la clase
DefaultAWSCredentialsProviderChain. DefaultAWSCredentialsProviderChain usa
la primera clave de acceso y clave secreta de AWS que encuentra en la cadena predeterminada de
proveedores de credenciales. Para obtener más información acerca de las claves de acceso de AWS,
consulte Administración de las claves de acceso de los usuarios de IAM.
Tras crear una instancia de RdsIamAuthTokenGenerator, puede llamar al método getAuthToken

para obtener un token firmado. Proporcione la región de AWS, el nombre de host, el número de puerto y el
nombre de usuario. En el siguiente ejemplo de código se ilustra cómo hacerlo.
package com.amazonaws.codesamples;
import com.amazonaws.auth.DefaultAWSCredentialsProviderChain;
import com.amazonaws.services.rds.auth.GetIamAuthTokenRequest;
import com.amazonaws.services.rds.auth.RdsIamAuthTokenGenerator;
public class GenerateRDSAuthToken {

190
String region = "us-west-2";

String hostname = "rdsmysql.cdgmuqiadpid.us-west-2.rds.amazonaws.com";
String port = "3306";
String username = "jane_doe";
System.out.println(generateAuthToken(region, hostname, port, username));

}
static String generateAuthToken(String region, String hostName, String port, String

username) {
RdsIamAuthTokenGenerator generator = RdsIamAuthTokenGenerator.builder()

.credentials(new DefaultAWSCredentialsProviderChain())
.region(region)
.build();
String authToken = generator.getAuthToken(

GetIamAuthTokenRequest.builder()
.hostname(hostName)
.port(Integer.parseInt(port))
.userName(username)
.build());
return authToken;
}
Creación manual de un token de autenticación de IAM

En Java, la forma más sencilla de generar un token de autenticación es usar
RdsIamAuthTokenGenerator. Esta clase crea automáticamente un token de autenticación y, a
continuación, lo firma mediante AWS Signature Version 4. Para obtener más información, consulte Proceso
de firma Signature Version 4 en la AWS General Reference.
Sin embargo, también puede crear y firmar un token de autenticación manualmente, como se muestra en
el siguiente ejemplo de código.
package com.amazonaws.codesamples;
import com.amazonaws.SdkClientException;
import com.amazonaws.auth.SigningAlgorithm;
import com.amazonaws.util.BinaryUtils;
import org.apache.commons.lang3.StringUtils;
import javax.crypto.Mac;
import javax.crypto.spec.SecretKeySpec;
import java.nio.charset.Charset;
import java.security.MessageDigest;
import java.text.SimpleDateFormat;
import java.util.Date;
import java.util.SortedMap;
import java.util.TreeMap;
import static com.amazonaws.auth.internal.SignerConstants.AWS4_TERMINATOR;

import static com.amazonaws.util.StringUtils.UTF8;
public class CreateRDSAuthTokenManually {

public static String httpMethod = "GET";
public static String action = "connect";
public static String canonicalURIParameter = "/";
public static SortedMap<String, String> canonicalQueryParameters = new TreeMap();
public static String payload = StringUtils.EMPTY;

191
public static String signedHeader = "host";

public static String algorithm = "AWS4-HMAC-SHA256";
public static String serviceName = "rds-db";
public static String requestWithoutSignature;
public static void main(String[] args) throws Exception {
String region = "us-west-2";

String instanceName = "rdsmysql.cdgmuqiadpid.us-west-2.rds.amazonaws.com";
String port = "3306";
String username = "jane_doe";
Date now = new Date();

String date = new SimpleDateFormat("yyyyMMdd").format(now);
String dateTimeStamp = new SimpleDateFormat("yyyyMMdd'T'HHmmssZ").format(now);
DefaultAWSCredentialsProviderChain creds = new
DefaultAWSCredentialsProviderChain();
String awsAccessKey = creds.getCredentials().getAWSAccessKeyId();
String awsSecretKey = creds.getCredentials().getAWSSecretKey();
String expiryMinutes = "900";
System.out.println("Step 1: Create a canonical request:");

String canonicalString = createCanonicalString(username, awsAccessKey, date,
dateTimeStamp, region, expiryMinutes, instanceName, port);
System.out.println(canonicalString);
System.out.println();
System.out.println("Step 2: Create a string to sign:");

String stringToSign = createStringToSign(dateTimeStamp, canonicalString,
awsAccessKey, date, region);
System.out.println(stringToSign);
System.out.println("Step 3: Calculate the signature:");

String signature = BinaryUtils.toHex(calculateSignature(stringToSign,
newSigningKey(awsSecretKey, date, region, serviceName)));
System.out.println(signature);
System.out.println("Step 4: Add the signing info to the request");

System.out.println(appendSignature(signature));
//Step 1: Create a canonical request date should be in format YYYYMMDD and dateTime
should be in format YYYYMMDDTHHMMSSZ
public static String createCanonicalString(String user, String accessKey, String date,
String dateTime, String region, String expiryPeriod, String hostName, String port) throws
Exception {
canonicalQueryParameters.put("Action", action);
canonicalQueryParameters.put("DBUser", user);
canonicalQueryParameters.put("X-Amz-Algorithm", "AWS4-HMAC-SHA256");
canonicalQueryParameters.put("X-Amz-Credential", accessKey + "%2F" + date + "%2F" +
region + "%2F" + serviceName + "%2Faws4_request");
canonicalQueryParameters.put("X-Amz-Date", dateTime);
canonicalQueryParameters.put("X-Amz-Expires", expiryPeriod);
canonicalQueryParameters.put("X-Amz-SignedHeaders", signedHeader);
String canonicalQueryString = "";
while(!canonicalQueryParameters.isEmpty()) {
String currentQueryParameter = canonicalQueryParameters.firstKey();
String currentQueryParameterValue =
canonicalQueryParameters.remove(currentQueryParameter);
canonicalQueryString = canonicalQueryString + currentQueryParameter + "=" +
currentQueryParameterValue;
if (!currentQueryParameter.equals("X-Amz-SignedHeaders")) {

192
canonicalQueryString += "&";
}
}
String canonicalHeaders = "host:" + hostName + ":" + port + '\n';
requestWithoutSignature = hostName + ":" + port + "/?" + canonicalQueryString;
String hashedPayload = BinaryUtils.toHex(hash(payload));

return httpMethod + '\n' + canonicalURIParameter + '\n' + canonicalQueryString +
'\n' + canonicalHeaders + '\n' + signedHeader + '\n' + hashedPayload;
//Step 2: Create a string to sign using sig v4

public static String createStringToSign(String dateTime, String canonicalRequest,
String accessKey, String date, String region) throws Exception {
String credentialScope = date + "/" + region + "/" + serviceName + "/aws4_request";
return algorithm + '\n' + dateTime + '\n' + credentialScope + '\n' +
BinaryUtils.toHex(hash(canonicalRequest));
//Step 3: Calculate signature

/**
* Step 3 of the AWS Signature version 4 calculation. It involves deriving
* the signing key and computing the signature. Refer to
* http://docs.aws.amazon
* .com/general/latest/gr/sigv4-calculate-signature.html
*/
public static byte[] calculateSignature(String stringToSign,
byte[] signingKey) {
return sign(stringToSign.getBytes(Charset.forName("UTF-8")), signingKey,
SigningAlgorithm.HmacSHA256);
}
public static byte[] sign(byte[] data, byte[] key,

SigningAlgorithm algorithm) throws SdkClientException {
try {
Mac mac = algorithm.getMac();
mac.init(new SecretKeySpec(key, algorithm.toString()));
return mac.doFinal(data);
} catch (Exception e) {
throw new SdkClientException(
"Unable to calculate a request signature: "
+ e.getMessage(), e);
}
}
public static byte[] newSigningKey(String secretKey,

String dateStamp, String regionName, String serviceName)
{
byte[] kSecret = ("AWS4" + secretKey).getBytes(Charset.forName("UTF-8"));
byte[] kDate = sign(dateStamp, kSecret, SigningAlgorithm.HmacSHA256);
byte[] kRegion = sign(regionName, kDate, SigningAlgorithm.HmacSHA256);
byte[] kService = sign(serviceName, kRegion,
SigningAlgorithm.HmacSHA256);
return sign(AWS4_TERMINATOR, kService, SigningAlgorithm.HmacSHA256);
}
public static byte[] sign(String stringData, byte[] key,

SigningAlgorithm algorithm) throws SdkClientException {
try {
byte[] data = stringData.getBytes(UTF8);
return sign(data, key, algorithm);
"Unable to calculate a request signature: "

193
}
}
//Step 4: append the signature

public static String appendSignature(String signature) {
return requestWithoutSignature + "&X-Amz-Signature=" + signature;
}
public static byte[] hash(String s) throws Exception {

try {
MessageDigest md = MessageDigest.getInstance("SHA-256");
md.update(s.getBytes(UTF8));
return md.digest();
"Unable to compute hash while signing request: "
}
}
}
Conexión a su clúster de base de datos
En el siguiente ejemplo de código se muestra cómo generar un token de autenticación y, a continuación,

cómo usarlo para conectarse a un clúster que ejecuta MySQL.
Para ejecutar este ejemplo de código, necesita el AWS SDK for Java, que se encuentra en el sitio de AWS.
Además, necesitará lo siguiente:
• MySQL Connector/J. Este ejemplo de código se ha probado con mysql-connector-java-5.1.33-

bin.jar.
• Un certificado intermedio para Amazon Aurora que es específico de una región de AWS. (Para
obtener más información, consulte Uso de SSL para cifrar una conexión a un clúster de base de
datos (p. 161).) En tiempo de ejecución, el cargador de clases busca el certificado en el mismo
directorio que este ejemplo de código Java, de modo que el cargador de clases pueda encontrarlo.
• Modifique los valores de las siguientes variables según sea necesario:
• RDS_INSTANCE_HOSTNAME: el nombre de host del clúster de base de datos a los que desea obtener
acceso.
• RDS_INSTANCE_PORT: el número de puerto usado para conectarse al clúster de base de datos de
PostgreSQL.
• REGION_NAME: la región de AWS donde se ejecuta el clúster de base de datos.
• DB_USER: la cuenta de base de datos a la que desea obtener acceso.
• SSL_CERTIFICATE: un certificado SSL para Amazon Aurora que es específico de una
región de AWS. Para descargar un certificado para su región de AWS, consulte Certificados
intermedios (p. 161). Coloque el certificado SSL en el mismo directorio que este archivo de
programa Java, de modo que el cargador de clases pueda encontrar el certificado en tiempo de
ejecución.
En este ejemplo de código, se obtienen las credenciales de AWS de la cadena predeterminada de

proveedores de credenciales.
package com.amazonaws.samples;
import com.amazonaws.services.rds.auth.RdsIamAuthTokenGenerator;
import com.amazonaws.services.rds.auth.GetIamAuthTokenRequest;
import com.amazonaws.auth.BasicAWSCredentials;

194
import com.amazonaws.auth.AWSStaticCredentialsProvider;
import java.io.File;
import java.io.FileOutputStream;
import java.io.InputStream;
import java.security.KeyStore;
import java.security.cert.CertificateFactory;
import java.security.cert.X509Certificate;
import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.ResultSet;
import java.sql.Statement;
import java.util.Properties;
import java.net.URL;
public class IAMDatabaseAuthenticationTester {

//AWS Credentials of the IAM user with policy enabling IAM Database Authenticated
access to the db by the db user.
private static final DefaultAWSCredentialsProviderChain creds = new
DefaultAWSCredentialsProviderChain();
private static final String AWS_ACCESS_KEY =
creds.getCredentials().getAWSAccessKeyId();
private static final String AWS_SECRET_KEY = creds.getCredentials().getAWSSecretKey();
//Configuration parameters for the generation of the IAM Database Authentication token
private static final String RDS_INSTANCE_HOSTNAME = "rdsmysql.cdgmuqiadpid.us-
west-2.rds.amazonaws.com";
private static final int RDS_INSTANCE_PORT = 3306;
private static final String REGION_NAME = "us-west-2";
private static final String DB_USER = "jane_doe";
private static final String JDBC_URL = "jdbc:mysql://" + RDS_INSTANCE_HOSTNAME + ":" +
RDS_INSTANCE_PORT;
private static final String SSL_CERTIFICATE = "rds-ca-2015-us-west-2.pem";
private static final String KEY_STORE_TYPE = "JKS";

private static final String KEY_STORE_PROVIDER = "SUN";
private static final String KEY_STORE_FILE_PREFIX = "sys-connect-via-ssl-test-cacerts";
private static final String KEY_STORE_FILE_SUFFIX = ".jks";
private static final String DEFAULT_KEY_STORE_PASSWORD = "changeit";

//get the connection
Connection connection = getDBConnectionUsingIam();
//verify the connection is successful

Statement stmt= connection.createStatement();
ResultSet rs=stmt.executeQuery("SELECT 'Success!' FROM DUAL;");
while (rs.next()) {
String id = rs.getString(1);
System.out.println(id); //Should print "Success!"
}
//close the connection

stmt.close();
connection.close();
clearSslProperties();
/**
* This method returns a connection to the db instance authenticated using IAM Database
Authentication

195
* @return
* @throws Exception
*/
private static Connection getDBConnectionUsingIam() throws Exception {
setSslProperties();
return DriverManager.getConnection(JDBC_URL, setMySqlConnectionProperties());
}
/**
* This method sets the mysql connection properties which includes the IAM Database
Authentication token
* as the password. It also specifies that SSL verification is required.
* @return
*/
private static Properties setMySqlConnectionProperties() {
Properties mysqlConnectionProperties = new Properties();
mysqlConnectionProperties.setProperty("verifyServerCertificate","true");
mysqlConnectionProperties.setProperty("useSSL", "true");
mysqlConnectionProperties.setProperty("user",DB_USER);
mysqlConnectionProperties.setProperty("password",generateAuthToken());
return mysqlConnectionProperties;
}
/**
* This method generates the IAM Auth Token.
* An example IAM Auth Token would look like follows:
* btusi123.cmz7kenwo2ye.rds.cn-north-1.amazonaws.com.cn:3306/?
Action=connect&DBUser=iamtestuser&X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-
Date=20171003T010726Z&X-Amz-SignedHeaders=host&X-Amz-Expires=899&X-Amz-
Credential=AKIAPFXHGVDI5RNFO4AQ%2F20171003%2Fcn-north-1%2Frds-db%2Faws4_request&X-Amz-
Signature=f9f45ef96c1f770cdad11a53e33ffa4c3730bc03fdee820cfdf1322eed15483b
* @return
*/
private static String generateAuthToken() {
BasicAWSCredentials awsCredentials = new BasicAWSCredentials(AWS_ACCESS_KEY,
AWS_SECRET_KEY);
RdsIamAuthTokenGenerator generator = RdsIamAuthTokenGenerator.builder()

.credentials(new
AWSStaticCredentialsProvider(awsCredentials)).region(REGION_NAME).build();
return generator.getAuthToken(GetIamAuthTokenRequest.builder()
.hostname(RDS_INSTANCE_HOSTNAME).port(RDS_INSTANCE_PORT).userName(DB_USER).build());
}
/**
* This method sets the SSL properties which specify the key store file, its type and
password:
* @throws Exception
*/
private static void setSslProperties() throws Exception {
System.setProperty("javax.net.ssl.trustStore", createKeyStoreFile());
System.setProperty("javax.net.ssl.trustStoreType", KEY_STORE_TYPE);
System.setProperty("javax.net.ssl.trustStorePassword", DEFAULT_KEY_STORE_PASSWORD);
}
/**
* This method returns the path of the Key Store File needed for the SSL verification
during the IAM Database Authentication to
* the db instance.
* @return
* @throws Exception
*/
private static String createKeyStoreFile() throws Exception {
return createKeyStoreFile(createCertificate()).getPath();
}

196
/**
* This method generates the SSL certificate
* @return
* @throws Exception
*/
private static X509Certificate createCertificate() throws Exception {
CertificateFactory certFactory = CertificateFactory.getInstance("X.509");
URL url = new File(SSL_CERTIFICATE).toURI().toURL();
if (url == null) {
throw new Exception();
}
try (InputStream certInputStream = url.openStream()) {
return (X509Certificate) certFactory.generateCertificate(certInputStream);
}
}
/**
* This method creates the Key Store File
* @param rootX509Certificate - the SSL certificate to be stored in the KeyStore
* @return
* @throws Exception
*/
private static File createKeyStoreFile(X509Certificate rootX509Certificate) throws
Exception {
File keyStoreFile = File.createTempFile(KEY_STORE_FILE_PREFIX,
KEY_STORE_FILE_SUFFIX);
try (FileOutputStream fos = new FileOutputStream(keyStoreFile.getPath())) {
KeyStore ks = KeyStore.getInstance(KEY_STORE_TYPE, KEY_STORE_PROVIDER);
ks.load(null);
ks.setCertificateEntry("rootCaCertificate", rootX509Certificate);
ks.store(fos, DEFAULT_KEY_STORE_PASSWORD.toCharArray());
}
return keyStoreFile;
}
/**
* This method clears the SSL properties.
* @throws Exception
*/
private static void clearSslProperties() throws Exception {
System.clearProperty("javax.net.ssl.trustStore");
System.clearProperty("javax.net.ssl.trustStoreType");
System.clearProperty("javax.net.ssl.trustStorePassword");
}
Solución de problemas de identidad y acceso en

Amazon Aurora
Utilice la información siguiente para diagnosticar y solucionar los problemas comunes que puedan surgir
cuando trabaje con Aurora e IAM.
Temas
• No tengo autorización para realizar una acción en Aurora (p. 198)
• No tengo autorización para realizar la operación iam:PassRole (p. 198)
• Quiero ver mis claves de acceso (p. 198)
• Soy administrador y deseo permitir que otros obtengan acceso a Aurora (p. 199)
• Quiero permitir a personas externas a mi cuenta de AWS el acceso a mis recursos de Aurora (p. 199)

197
No tengo autorización para realizar una acción en Aurora

Si la Consola de administración de AWS le indica que no está autorizado para llevar a cabo una acción,
debe ponerse en contacto con su administrador para recibir ayuda. Su administrador es la persona que le
facilitó su nombre de usuario y contraseña.
En el siguiente ejemplo, el error se produce cuando el usuario mateojackson de IAM, intenta utilizar la
consola para ver detalles sobre un widget, pero no tiene permisos rds:GetWidget.
User: arn:aws:iam::123456789012:user/mateojackson is not authorized to perform:

rds:GetWidget on resource: my-example-widget
En este caso, Mateo pide a su administrador que actualice sus políticas de forma que pueda obtener
acceso al recurso my-example-widget mediante la acción rds:GetWidget.
No tengo autorización para realizar la operación iam:PassRole

Si recibe un error que indica que no está autorizado para llevar a cabo la acción iam:PassRole, debe
ponerse en contacto con su administrador para recibir ayuda. Su administrador es la persona que le facilitó
su nombre de usuario y contraseña. Pida a la persona que actualice sus políticas de forma que pueda
transferir un rol a Aurora.
Algunos servicios de AWS le permiten transferir un rol existente a dicho servicio en lugar de crear un nuevo
rol de servicio o uno vinculado al servicio. Para ello, debe tener permisos para transferir el rol al servicio.
En el siguiente ejemplo, el error se produce cuando un usuario de IAM denominado marymajor intenta
utilizar la consola para realizar una acción en Aurora. Sin embargo, la acción requiere que el servicio
cuente con permisos otorgados por un rol de servicio. Mary no tiene permisos para transferir el rol al
servicio.
User: arn:aws:iam::123456789012:user/marymajor is not authorized to perform: iam:PassRole
En este caso, Mary pide a su administrador que actualice sus políticas para que pueda realizar la acción
iam:PassRole.
Quiero ver mis claves de acceso

Después de crear sus claves de acceso de usuario de IAM, puede ver su ID de clave de acceso en
cualquier momento. Sin embargo, no puede volver a ver su clave de acceso secreta. Si pierde la clave de
acceso secreta, debe crear un nuevo par de claves de acceso.
Las claves de acceso se componen de dos partes: un ID de clave de acceso (por ejemplo,
AKIAIOSFODNN7EXAMPLE) y una clave de acceso secreta (por ejemplo, wJalrXUtnFEMI/K7MDENG/
bPxRfiCYEXAMPLEKEY). El ID de clave de acceso y la clave de acceso secreta se utilizan juntos, como un
nombre de usuario y contraseña, para autenticar sus solicitudes. Administre sus claves de acceso con el
mismo nivel de seguridad que para el nombre de usuario y la contraseña.
Important
No proporcione las claves de acceso a terceras personas, ni siquiera para que le ayuden a buscar
el ID de usuario canónico. Si lo hace, podría conceder a otra persona acceso permanente a su
cuenta.
Cuando cree un par de claves de acceso, se le pide que guarde el ID de clave de acceso y la clave de
acceso secreta en un lugar seguro. La clave de acceso secreta solo está disponible en el momento de su
creación. Si pierde la clave de acceso secreta, debe añadir nuevas claves de acceso a su usuario de IAM.
Puede tener un máximo de dos claves de acceso. Si ya cuenta con dos, debe eliminar un par de claves

198
Registro y monitorización
antes de crear uno nuevo. Para ver las instrucciones, consulte Administración de las claves de acceso en
la Guía del usuario de IAM.
Soy administrador y deseo permitir que otros obtengan acceso a

Aurora
Para permitir que otros obtengan acceso a Aurora, debe crear una entidad de IAM (usuario o rol) para
la persona o aplicación que necesita acceso. Ellas utilizarán las credenciales de la entidad para obtener
acceso a AWS. A continuación, debe asociar una política a la entidad que le conceda los permisos
correctos en Aurora.
Para comenzar de inmediato, consulte Creación del primer grupo y usuario delegado de IAM en la Guía del
usuario de IAM.
Quiero permitir a personas externas a mi cuenta de AWS el

acceso a mis recursos de Aurora
Puede crear un rol que los usuarios de otras cuentas o las personas externas a la organización puedan
utilizar para acceder a sus recursos. Puede especificar una persona de confianza para que asuma el rol.
En el caso de los servicios que admitan las políticas basadas en recursos o las listas de control de acceso
(ACL), puede utilizar dichas políticas para conceder a las personas acceso a sus recursos.
Para obtener más información, consulte lo siguiente:
• Para obtener información acerca de si Aurora admite estas características, consulte Funcionamiento de
Amazon Aurora con IAM (p. 167).
• Para aprender cómo proporcionar acceso a sus recursos en cuentas de AWS de su propiedad, consulte
Proporcionar acceso a un usuario de IAM a otra cuenta de AWS de la que es propietario en la Guía del
usuario de IAM.
• Para obtener información acerca de cómo ofrecer acceso a sus recursos a cuentas de AWS de terceros,
consulte Proporcionar acceso a las cuentas de AWS propiedad de terceros en la Guía del usuario de
IAM.
• Para obtener información acerca de cómo ofrecer acceso a la identidad federada, consulte Proporcionar
acceso a usuarios autenticados externamente (identidad federada) en la Guía del usuario de IAM.
• Para obtener información acerca de la diferencia entre utilizar los roles y las políticas basadas en
recursos para el acceso entre cuentas, consulte Cómo los roles de IAM difieren de las políticas basadas
en recursos en la Guía del usuario de IAM.
Registro y monitorización en Amazon Aurora

La monitorización es una parte importante del mantenimiento de la fiabilidad, la disponibilidad y el
rendimiento de Amazon Aurora y sus soluciones de AWS. Debe recopilar datos de monitorización de todas
las partes de su solución de AWS para que pueda depurar un error multipunto de una forma más fácil si
se produce. AWS proporciona varias herramientas para monitorizar sus recursos de Amazon Aurora y
responder a posibles incidentes:
Alarmas de Amazon CloudWatch
Con las alarmas de Amazon CloudWatch, puede ver una métrica determinada durante el periodo
especificado. Si la métrica supera un umbral determinado, se envía una notificación a un tema de
Amazon SNS o política de AWS Auto Scaling. Las alarmas de CloudWatch no invocan acciones por
tener un estado determinado. En su lugar, el estado debe haber cambiado y debe mantenerse durante
el número de periodos especificado. Para obtener más información, consulte Monitorización con
Amazon CloudWatch (p. 366).

199
Registro y monitorización
Registros de AWS CloudTrail
CloudTrail proporciona un registro de las acciones realizadas por un usuario, un rol o un servicio de
AWS en Amazon Aurora. CloudTrail captura todas las llamadas a la API de Amazon Aurora como
eventos, incluidas las llamadas procedentes de la consola y de las llamadas del código a las API de
Amazon RDS. Mediante la información que recopila CloudTrail, se puede determinar la solicitud que
se envió a Amazon Aurora, la dirección IP desde la que se realizó la solicitud, quién realizó la solicitud,
cuándo la realizó y detalles adicionales. Para obtener más información, consulte Registro de llamadas
al API de Amazon RDS con AWS CloudTrail (p. 492).
Monitorización mejorada
Amazon Aurora proporciona métricas en tiempo real para el sistema operativo (SO) en el que se
ejecuta el clúster de base de datos. Puede ver las métricas de su clúster de base de datos en la
consola o usar la salida JSON de la monitorización mejorada de Amazon CloudWatch Logs en el
sistema de monitorización que prefiera. Para obtener más información, consulte Monitorización
mejorada (p. 395).
Amazon RDS Performance Insights
La Información sobre rendimiento amplía las características de monitorización existentes de Amazon

Aurora para ilustrar el rendimiento de la base de datos y le ayuda a analizar cualquier problema que le
afecte. Con el panel de Performance Insights, puede visualizar la carga de la base de datos y filtrarla
por esperas, instrucciones SQL, hosts o usuarios. Para obtener más información, consulte Uso de
Performance Insights de Amazon RDS (p. 402).
Registros de la base de datos
Puede ver, descargar y monitorizar los registros de base de datos usando la Consola de
administración de AWS, la AWS CLI o la API de RDS. Para obtener más información, consulte
Archivos de registro de base de datos de Amazon RDS (p. 482).
Recomendaciones de Amazon Aurora
Amazon Aurora proporciona recomendaciones automatizadas de recursos de la base de datos. Estas

recomendaciones proporcionan instrucciones de las prácticas recomendadas analizando los datos
de rendimiento, el uso y la configuración de clúster de base de datos. Para obtener más información,
consulte Uso de recomendaciones de Amazon Aurora (p. 440).
Notificación de eventos de Amazon Aurora
Amazon Aurora usa la Amazon Simple Notification Service (Amazon SNS) para proporcionar una
notificación cuando se produce un evento deAmazon Aurora. Estas notificaciones pueden realizarse
con cualquier método que admita Amazon SNS para una región de AWS como, por ejemplo, un
mensaje de correo electrónico, un mensaje de texto o una llamada a un punto de enlace HTTP. Para
obtener más información, consulte Uso de las notificaciones de eventos de Amazon RDS (p. 465).
AWS Trusted Advisor
Trusted Advisor aprovecha las prácticas recomendadas aprendidas al atender a cientos de miles de
clientes de AWS. Trusted Advisor inspecciona su entorno de AWS y realiza recomendaciones cuando
surge la oportunidad de ahorrar dinero, mejorar el rendimiento y la disponibilidad del sistema o ayudar
a cerrar deficiencias de seguridad. Todos los clientes de AWS tienen acceso a cinco comprobaciones
de Trusted Advisor. Los clientes con un plan de soporte Business o Enterprise pueden ver todas las
comprobaciones de Trusted Advisor.
Trusted Advisor cuenta con las siguientes comprobaciones relacionadas con Amazon Aurora:
• Instancias de base de datos inactiva de Amazon Aurora
• Riesgo de acceso a grupos de seguridad de Amazon Aurora
• Copias de seguridad de Amazon Aurora
• Multi-AZ de Amazon Aurora
• Accesibilidad de instancias de base de datos de Aurora

200
Validación de la conformidad
Para obtener más información acerca de estas comprobaciones, consulte Prácticas recomendadas de
Trusted Advisor (verificaciones).
Transmisiones de actividades de la base de datos
En Aurora PostgreSQL, las secuencias de actividades de la base de datos pueden proteger su

bases de datos contra las amenazas internas, mediante el control del acceso de los DBA a las
secuencias de actividades de la base de datos. Así, los DBA que administran la base de datos no
tienen acceso a la recopilación, la transmisión, el almacenamiento y el procesamiento posterior de la
secuencia de actividades de la base de datos. Las secuencias de actividad de la base de datos puede
proporcionar medidas de seguridad que protejan su base de datos y cumplir los requisitos normativos
y de cumplimiento. Para obtener más información, consulte Uso de secuencias de actividades de la
base de datos con Aurora PostgreSQL (p. 446).
Para obtener más información sobre la monitorización de Aurora, consulte Monitorización de un clúster de
base de datos de Amazon Aurora (p. 363).
Validación de la conformidad en Amazon Aurora

Auditores externos evalúan la seguridad y la conformidad de Amazon Aurora como parte de varios
programas de conformidad de AWS. Estos incluyen SOC, PCI, FedRAMP, HIPAA y otros.
Para obtener una lista de los servicios de AWS en el ámbito de programas de conformidad específicos,
consulte Servicios de AWS en el ámbito del programa de conformidad. Para obtener información general,
consulte Programas de conformidad de AWS.
Puede descargar los informes de auditoría de terceros utilizando AWS Artifact. Para obtener más
información, consulte Descarga de informes en AWS Artifact.
Su responsabilidad de conformidad al utilizar Amazon Aurora se determina en función de la sensibilidad

de los datos, los objetivos de conformidad de su organización, así como de la legislación y los reglamentos
aplicables. AWS proporciona los siguientes recursos para ayudar con la conformidad:
• Guías de inicio rápido de seguridad y conformidad: estas guías de implementación tratan

consideraciones sobre arquitectura y ofrecen pasos para implementar los entornos de referencia
centrados en la seguridad y la conformidad en AWS.
• Documento técnico sobre arquitectura para seguridad y conformidad de HIPAA: este documento técnico
describe cómo las empresas pueden utilizar AWS para crear aplicaciones conformes con HIPAA.
• Recursos de conformidad de AWS: este conjunto de manuales y guías podría aplicarse a su sector y
ubicación.
• AWS Config: este servicio de AWS evalúa en qué medida las configuraciones de los recursos cumplen
las prácticas internas, las directrices del sector y las normativas.
• AWS Security Hub: este servicio de AWS ofrece una vista integral de su estado de seguridad en AWS
que le ayuda a comprobar la conformidad con las normas del sector de seguridad y las prácticas
recomendadas.
Resiliencia en Amazon Aurora

La infraestructura global de AWS está conformada por regiones y zonas de disponibilidad de AWS. Las
regiones de AWS proporcionan varias zonas de disponibilidad físicamente independientes y aisladas
que se encuentran conectadas mediante redes con un alto nivel de rendimiento y redundancia, además
de baja latencia. Con las zonas de disponibilidad, puede diseñar y utilizar aplicaciones y bases de datos
que realizan una conmutación por error automática entre zonas de disponibilidad sin interrupciones. Las

201
Copia de seguridad y restauración
zonas de disponibilidad tienen una mayor disponibilidad, tolerancia a errores y escalabilidad que las
infraestructuras tradicionales de centros de datos únicos o múltiples.
Para obtener más información sobre las zonas de disponibilidad y las regiones de AWS, consulte
Infraestructura global de AWS.
Además de la infraestructura global de AWS, Aurora ofrece características que le ayudan con sus
necesidades de resiliencia y copia de seguridad de los datos.
Copia de seguridad y restauración

Aurora crea copias de seguridad del volumen de clúster automáticamente y conserva los datos de
restauración durante el tiempo asignado al periodo de retención de copia de seguridad. Las copias de
seguridad de Aurora son continuas e incrementales para que se pueda restaurar con rapidez a cualquier
punto durante el periodo de retención de copia de seguridad. No se produce ningún impacto en el
desempeño ni ninguna interrupción del servicio de base de datos durante la escritura de los datos de copia
de seguridad. Puede especificar un periodo de retención de copia de seguridad de 1 a 35 días cuando cree
o modifique un clúster de base de datos.
Si desea conservar una copia de seguridad más allá del período de retención de copia de seguridad,
también puede tomar una instantánea de los datos en el volumen de su clúster. Aurora conserva los datos
de restauración incrementales durante todo el período de retención de la copia de seguridad. Por tanto,
solo tiene que crear una instantánea de los datos que desee conservar después del periodo de retención
de copia de seguridad. Puede crear un nuevo clúster de base de datos a partir de la instantánea.
Puede recuperar sus datos creando un nuevo clúster de base de datos Aurora a partir de los datos de
copias de seguridad conservados por Aurora; o de una instantánea de clúster de base de datos que haya
guardado. Puede crear rápidamente una nueva copia del clúster de base de datos a partir de los datos de
la copia de seguridad de cualquier momento dado durante el periodo de retención de copia de seguridad.
La naturaleza continua e incremental de las copias de seguridad de Aurora durante el periodo de retención
de copia de seguridad implica que no es necesario realizar instantáneas de los datos con demasiada
frecuencia para mejorar los tiempos de restauración.
Para obtener más información, consulte Backup y restauración de un clúster de base de datos de Amazon
Aurora (p. 314).
Replicación
disponibilidad que abarca un clúster de base de datos dentro de una región de AWS. El volumen del
clúster de base de datos consta de varias copias de los datos del clúster de base de datos. No obstante,
los datos del volumen del clúster se representan como un único volumen lógico para la instancia de base
de datos principal y para las réplicas de Aurora del clúster de base de datos. Si la instancia principal da
error, una réplica de Aurora se convierte en la instancia de base de datos principal.
Aurora también admite opciones de replicación que son específicas de Aurora MySQL y Aurora
PostgreSQL.
Para obtener más información, consulte Replicación con Amazon Aurora (p. 48).
Conmutación por error

Aurora almacena copias de los datos de un clúster de base de datos entre varias zonas de disponibilidad
de una sola región de AWS. Este almacenamiento se produce independientemente de si las instancias de

202
Seguridad de la infraestructura
base de datos en el clúster de base de datos abarca varias zonas de disponibilidad. Al crear réplicas de
Aurora entre zonas de disponibilidad, Aurora las aprovisiona automáticamente y las mantiene de forma
síncrona. La instancia de base de datos principal se replica de forma síncrona en distintas zonas de
disponibilidad en réplicas de Aurora para proporcionar redundancia de datos, eliminar las congelaciones de
E/S y minimizar los picos de latencia durante las copias de seguridad del sistema. Ejecutar un clúster de
base de datos con alta disponibilidad puede mejorar la disponibilidad durante el mantenimiento de sistema
planificado y ayuda a proteger las bases de datos contra los errores y las interrupciones de las zonas de
disponibilidad.
Para obtener más información, consulte Alta disponibilidad para Aurora (p. 28).
Seguridad de la infraestructura en Amazon Aurora

Al tratarse de un servicio administrado, Amazon RDS está protegido por los procedimientos de seguridad
de red globales de AWS que se describen en el documento técnico Amazon Web Services: Información
general sobre procesos de seguridad.
Puede utilizar llamadas a la API publicadas en AWS para obtener acceso a Amazon Aurora a través
de la red. Los clientes deben admitir Transport Layer Security (TLS) 1.0. Le recomendamos TLS 1.2
o una versión posterior. Los clientes también deben ser compatibles con conjuntos de cifrado con
confidencialidad directa total (PFS) tales como Ephemeral Diffie-Hellman (DHE) o Elliptic Curve Ephemeral
Diffie-Hellman (ECDHE). La mayoría de los sistemas modernos como Java 7 y posteriores son compatibles
con estos modos.
Además, las solicitudes deben estar firmadas mediante un ID de clave de acceso y una clave de acceso
secreta que esté asociada a una entidad principal de IAM. También puede utilizar AWS Security Token
Service (AWS STS) para generar credenciales de seguridad temporales para firmar solicitudes.
Puede llamar a estas operaciones de la API desde cualquier ubicación de red. Sin embargo, Amazon
Aurora admite también políticas de acceso basadas en recursos, que pueden incluir restricciones en
función de la dirección IP de origen. Además, puede utilizar las políticas de Amazon Aurora para controlar
el acceso desde puntos de enlace específicos de la Amazon VPC, o desde VPC específicas. Este proceso
aísla con eficacia el acceso de red a un recurso de Amazon Aurora determinado únicamente desde la VPC
específica de la red de AWS.
Además, Aurora ofrece características para ayudar a admitir la seguridad de la infraestructura.
Grupos de seguridad
Los grupos de seguridad controlan el acceso del tráfico entrante y saliente a una instancia de base de
datos. De forma predeterminada, el acceso de red está deshabilitado para una instancia de base de datos.
Puede especificar reglas en un grupo de seguridad que permita el acceso desde un rango de direcciones
IP, un puerto o un grupo de seguridad de Amazon EC2. Una vez configuradas las reglas de entrada, se
aplican las mismas reglas a todas las instancias de base de datos que están asociadas a ese grupo de
seguridad.
Para obtener más información, consulte Control de acceso con grupos de seguridad (p. 204).
Public accessibility (Accesibilidad pública)

Cuando lance una instancia de base de datos dentro de una Virtual Private Cloud (VPC) basada en el
servicio de Amazon VPC, podrá activar o desactivar la accesibilidad pública para esa instancia. Para
designar si la instancia de base de datos que se crea tiene un nombre de DNS que se resuelve en una

203
Prácticas recomendadas de seguridad
dirección IP pública, utilice el parámetro Public accessibility (Accesibilidad pública). Con este parámetro
podrá especificar si hay acceso público a la instancia de base de datos. Es posible modificar una instancia
de base de datos para activar o desactivar la accesibilidad pública modificando el parámetro Public
accessibility (Accesibilidad pública).
Para obtener más información, consulte Cómo ocultar una instancia de base de datos en una VPC desde
Internet. (p. 223).
Prácticas recomendadas de seguridad para

Amazon Aurora
Use cuentas de AWS Identity and Access Management (IAM) para controlar el acceso a acciones de API
de Amazon RDS, especialmente acciones que crean, modifican o eliminan recursos de Amazon Aurora.
Dichos recursos incluyen clústeres de base de datos, grupos de seguridad y grupos de parámetros. Utilice
también IAM para controlar acciones que realizan acciones administrativas comunes como copias de
seguridad y restauración de clústeres de base de datos.
• Asigne una cuenta de IAM individual a cada persona que administre los recursos de Amazon Aurora.
No use las credenciales raíz de AWS para administrar los recursos de Amazon Aurora; debe crear un
usuario de IAM para todos, incluido usted mismo.
• Asigne a cada usuario el conjunto mínimo de permisos requerido para realizar sus tareas.
• Use los grupos de IAM para administrar con eficacia los permisos para varios usuarios.
• Rote con regularidad sus credenciales de IAM.
• Configure AWS Secrets Manager para que rote automáticamente el secreto para Amazon Aurora. Para
obtener más información, consulte Rotación de sus secretos de AWS Secrets Manager en la Guía del
usuario de AWS Secrets Manager.
Para obtener más información acerca de IAM, consulte AWS Identity and Access Management. Para
obtener información acerca de las prácticas recomendadas de IAM, consulte Prácticas recomendadas de
IAM.
Utilice la Consola de administración de AWS, la AWS CLI o la API de RDS para cambiar la contraseña
para el usuario maestro. Si usa otra herramienta, como un cliente de SQL, para cambiar la contraseña del
usuario maestro, podría provocar involuntariamente la revocación de privilegios para el usuario.
Control de acceso con grupos de seguridad

Los grupos de seguridad controlan el acceso del tráfico entrante y saliente a una instancia de base de
datos. En Aurora se utilizan dos tipos de grupos de seguridad: de base de datos, de VPC y de Amazon
EC2. En pocas palabras, estos funcionan de la manera siguiente:
• Un grupo de seguridad de VPC controla el acceso a instancias de base de datos e instancias EC2 dentro
de una VPC.
• Un grupo de seguridad de EC2 controla el acceso a una instancia EC2.
De forma predeterminada, el acceso a la red está desactivado para una instancia de base de datos. Puede
especificar reglas en un grupo de seguridad que permita el acceso desde un rango de direcciones IP,
un puerto o un grupo de seguridad de EC2. Cuando se configuran las reglas de entrada, se aplican las

204
Grupos de seguridad de la VPC
mismas reglas a todas las instancias de base de datos que están asociadas a ese grupo de seguridad.
Puede especificar hasta 20 reglas en un grupo de seguridad.
Grupos de seguridad de la VPC

Cada regla de grupo de seguridad de VPC permite a un origen específico obtener acceso a una instancia
de base de datos de una VPC asociada a ese grupo de seguridad de VPC. El origen puede ser un rango
de direcciones (por ejemplo, 203.0.113.0/24), u otro grupo de seguridad de VPC. Cuando se especifica un
grupo de seguridad de VPC como origen, se permite el tráfico entrante procedente de todas las instancias,
normalmente servidores de aplicaciones, que utilizan el grupo de seguridad de VPC. Los grupos de
seguridad de VPC pueden tener reglas que gobiernan el tráfico entrante y saliente, aunque las reglas de
tráfico saliente normalmente no se aplican a las instancias de bases de datos. Las reglas de tráfico saliente
solo se aplican si la instancia de base de datos actúa como cliente. Debe utilizar la API de Amazon EC2 o
la opción Security Group (Grupo de seguridad) de la consola de VPC para crear grupos de seguridad de
VPC.
Cuando cree reglas para un grupo de seguridad de VPC que permitan el acceso a las instancias de una
VPC, debe especificar un puerto para cada rango de direcciones a las que la regla permite el acceso. Por
ejemplo, si desea habilitar el acceso SSH a las instancias de la VPC, puede crear una regla que permita el
acceso al puerto TCP 22 para el rango de direcciones especificado.
Puede configurar varios grupos de seguridad de VPC que permitan el acceso a puertos distintos para las
distintas instancias de la VPC. Por ejemplo, puede crear un grupo de seguridad de VPC que permita el
acceso al puerto TCP 80 para los servidores web de la VPC. A continuación, puede crear otro grupo de
seguridad de VPC que permita el acceso al puerto TCP 3306 para las instancias de base de datos Aurora
MySQL de la VPC.
Note
En un clúster de base de datos de Aurora, el grupo de seguridad de VPC asociado al clúster de

base de datos también se asocia a todas las instancias de base de datos en el clúster de base
de datos. Si cambia el grupo de seguridad de VPC para el clúster de base de datos o para la
instancia de base de datos, el cambio se aplica automáticamente a todas las instancias de base
de datos en el clúster de base de datos.
Para obtener más información sobre los grupos de seguridad de VPC, consulte Grupos de seguridad en la
Guía del usuario de Amazon Virtual Private Cloud.
Escenario de grupos de seguridad

Un uso común de una instancia de base de datos en una VPC es compartir datos con un servidor de
aplicaciones que se ejecuta en una instancia Amazon EC2 de la misma VPC, al que obtiene acceso desde
una aplicación cliente situada fuera de la VPC. Para este escenario, se utilizan las páginas de RDS y VPC
de la Consola de administración de AWS o las acciones de la API de RDS y EC2 para crear las instancias
y los grupos de seguridad necesarios:
1. Cree un grupo de seguridad de VPC (por ejemplo, sg-appsrv1) y defina reglas de entrada que
utilicen las direcciones IP de la aplicación cliente como origen. Este grupo de seguridad permite que la
aplicación cliente se conecte a las instancias EC2 de una VPC que utilice este grupo de seguridad.
2. Cree una instancia EC2 para la aplicación y añada la instancia EC2 al grupo de seguridad de VPC (sg-
appsrv1) que creó en el paso anterior. La instancia EC2 de la VPC comparte el grupo de seguridad de
VPC con la instancia de base de datos.
3. Cree un segundo grupo de seguridad de VPC (por ejemplo, sg-dbsrv1) y cree una regla nueva
especificando el grupo de seguridad de VPC que creó en el paso 1 (sg-appsrv1) como origen.
4. Cree una instancia de base de datos y añada la instancia de base de datos al grupo de seguridad de
VPC (sg-dbsrv1) que creó en el paso anterior. Cuando cree la instancia de base de datos, utilice el

205
Creación de un grupo de seguridad de VPC
mismo número de puerto que especificó para la regla de grupo de seguridad de VPC (sg-dbsrv1) que
creó en el paso 3.
En el siguiente diagrama se muestra este escenario.
Para obtener más información acerca del uso de una VPC, consulte VPC Amazon Virtual Private Cloud y
Creación de un grupo de seguridad de VPC

Puede crear un grupo de seguridad de VPC para una instancia de base de datos mediante la consola de
VPC. Para obtener información sobre la creación de un grupo de seguridad, consulte Proporcionar acceso
al clúster de base de datos en la VPC mediante la creación de un grupo de seguridad (p. 53) y Grupos de
seguridad en la Guía del usuario de Amazon Virtual Private Cloud.
Asociación de un grupo de seguridad con una

instancia de base de datos
Puede asociar un grupo de seguridad con una instancia de base de datos mediante la opción Modify
(Modificar) de la consola de RDS, la API de Amazon RDS ModifyDBInstance o el comando modify-
db-instance de AWS CLI.
Para obtener información sobre la modificación de una instancia de base de datos en un clúster de base de
datos, consulte Modificar una instancia de base de datos en un clúster de base de datos (p. 237). Para
consideraciones relativas al grupo de seguridad al restaurar una instancia de base de datos a partir de una
instantánea de base de datos, consulte Consideraciones relativas al grupo de seguridad (p. 320).
Asociación de un grupo de seguridad con un clúster

de base de datos
Puede asociar un grupo de seguridad con un clúster de base de datos mediante la opción Modify cluster
(Modificar clúster) de la consola de RDS, la API de Amazon RDS ModifyDBCluster o el comando
modify-db-cluster de AWS CLI.

206
Privilegios de la cuenta de usuario maestro
Para obtener más información acerca de la modificación de un clúster de base de datos, consulte
Modificación de un clúster de base de datos Amazon Aurora (p. 235).
Privilegios de la cuenta de usuario maestro

Cuando se crea un clúster nuevo de base de datos, el usuario maestro predeterminado que se utiliza
obtiene ciertos privilegios para ese clúster de base de datos. En la siguiente tabla se muestran los
privilegios y los roles de base de datos que obtiene el usuario maestro para cada uno de los motores de
bases de datos.
Important
Le recomendamos encarecidamente que no utilice el usuario maestro directamente en sus
aplicaciones. En lugar de ello, es mejor ceñirse a la práctica recomendada de utilizar un usuario
de base de datos creado con los privilegios mínimos necesarios para su aplicación.
Note
Si elimina los permisos para el usuario maestro de forma accidental, puede restaurarlos
modificando el de base de datos y estableciendo una nueva contraseña para el usuario maestro.
Para obtener más información acerca de la modificación de un clúster de de base de datos,
consulte Modificación de un clúster de base de datos Amazon Aurora (p. 235).
Motor de Privilegio del sistema Rol de base de datos

base de
datos
MySQL CREATE, DROP, GRANT OPTION, REFERENCES, —

de EVENT, ALTER, DELETE, INDEX, INSERT, SELECT,
Amazon UPDATE, CREATE TEMPORARY TABLES, LOCK
Aurora TABLES, TRIGGER, CREATE VIEW, SHOW
VIEW, LOAD FROM S3, SELECT INTO S3, ALTER
ROUTINE, CREATE ROUTINE, EXECUTE, CREATE
USER, PROCESS, SHOW DATABASES , RELOAD,
REPLICATION CLIENT, REPLICATION SLAVE
PostgreSQLLOGIN, NOSUPERUSER, INHERIT, CREATEDB, RDS_SUPERUSER

de CREATEROLE, NOREPLICATION, VALID UNTIL
Amazon 'infinity'
Aurora
Uso de roles vinculados a servicios en Amazon

Aurora
Amazon Aurora usa roles vinculados a servicios de AWS Identity and Access Management (IAM). Un rol
vinculado a un servicio es un tipo único de rol de IAM que está vinculado directamente a Amazon Aurora.
Los roles vinculados a servicios están predefinidos por Amazon Aurora e incluyen todos los permisos que
el servicio requiere para llamar a otros servicios de AWS en su nombre.
Con un rol vinculado a servicios, resulta más sencillo usar Amazon Aurora, porque no es preciso agregar
los permisos necesarios manualmente. Amazon Aurora define los permisos de los roles vinculados con su
propio servicio y, a menos que esté definido de otra manera, solo Amazon Aurora puede asumir sus roles.
Los permisos definidos incluyen las políticas de confianza y de permisos, y que la política de permisos no
se pueda asociar a ninguna otra entidad de IAM.

207
Permisos de roles vinculados a
servicios para Amazon Aurora
Las funciones se pueden eliminar únicamente después de eliminar primero sus recursos relacionados.
De esta forma, se protegen los recursos de Amazon Aurora, ya que se evita que se puedan eliminar
accidentalmente permisos de acceso a los recursos.
Para obtener información acerca de otros servicios que admiten roles vinculados a servicios, consulte
Servicios de AWS que funcionan con IAM y busque los servicios que tienen Sí en la columna Rol vinculado
a servicio. Seleccione una opción Sí con un enlace para ver la documentación acerca del rol vinculado al
servicio en cuestión.
Permisos de roles vinculados a servicios para Amazon

Aurora
Amazon Aurora usa el rol vinculado a servicios denominado AWSServiceRoleForRDS – to allow Amazon
RDS to call AWS services on behalf of your DB clusters.
La función vinculada al servicio AWSServiceRoleForRDS confía en los siguientes servicios para asumir la
función:
• rds.amazonaws.com
La política de permisos del rol permite que Amazon Aurora realice las siguientes acciones en los recursos
especificados:
• Acciones en ec2:
• AssignPrivateIpAddresses
• AuthorizeSecurityGroupIngress
• CreateNetworkInterface
• CreateSecurityGroup
• DeleteNetworkInterface
• DeleteSecurityGroup
• DescribeAvailabilityZones
• DescribeInternetGateways
• DescribeSecurityGroups
• DescribeSubnets
• DescribeVpcAttribute
• DescribeVpcs
• ModifyNetworkInterfaceAttribute
• RevokeSecurityGroupIngress
• UnassignPrivateIpAddresses
• Acciones en sns:
• ListTopic
• Publish
• Acciones en cloudwatch:
• PutMetricData
• GetMetricData
• CreateLogStream
• PullLogEvents
• DescribeLogStreams
• CreateLogGroup Versión de API 2014-10-31
208
Creación de una función vinculada
a servicios para Amazon Aurora
Note
Debe configurar permisos para permitir a una entidad de IAM (como un usuario, grupo o función)
crear, editar o eliminar la descripción de una función vinculada a un servicio. Si aparece el
siguiente mensaje de error:
Unable to create the resource. Verify that you have permission to create service linked role.
Otherwise wait and try again later.
Asegúrese de que tiene habilitados los permisos siguientes:
{
"Action": "iam:CreateServiceLinkedRole",
"Effect": "Allow",
"Resource": "arn:aws:iam::*:role/aws-service-role/rds.amazonaws.com/
AWSServiceRoleForRDS",
"Condition": {
"StringLike": {
"iam:AWSServiceName":"rds.amazonaws.com"
}
}
}
Para obtener más información, consulte Permisos de roles vinculados a servicios en la Guía del
usuario de IAM.
Creación de una función vinculada a servicios para

Amazon Aurora
No necesita crear manualmente un rol vinculado a un servicio. Al realizar una operación de create a DB
cluster, Amazon Aurora se encarga de crear automáticamente la función vinculada al servicio.
Important
Si utilizaba el servicio Amazon Aurora antes de December 1, 2017, cuando comenzó a admitir los
roles vinculados a servicios, creó Amazon Aurora el rol AWSServiceRoleForRDS en su cuenta.
Para obtener más información, consulte Un nuevo rol ha aparecido en la cuenta de IAM.
Si elimina este rol vinculado a servicio y necesita crearlo de nuevo, puede utilizar el mismo proceso para
volver a crear el rol en su cuenta. Al realizar una operación de create a DB cluster, Amazon Aurora se
encarga de volver crear automáticamente la función vinculada al servicio.
Edición de un rol vinculado a un servicio para Amazon

Aurora
Amazon Aurora no le permite editar el rol vinculado a servicios AWSServiceRoleForRDS. Después de
crear un rol vinculado a un servicio, no puede cambiarle el nombre, ya que varias entidades pueden hacer
referencia al mismo. Sin embargo, puede editar la descripción de la función utilizando IAM. Para obtener
más información, consulte Editar un rol vinculado a un servicio en la Guía del usuario de IAM.
Eliminación de un rol vinculado a un servicio para

Amazon Aurora
Si ya no necesita utilizar una característica o servicio que requiere un rol vinculado a un servicio, le
recomendamos que elimine dicho rol. De esta forma no tiene una entidad no utilizada que no se monitorice

209
Eliminación de un rol vinculado a
un servicio para Amazon Aurora
ni mantenga de forma activa. Sin embargo, debe eliminar todos los clústeres para poder eliminar el rol
vinculado al servicio.
Limpiar un rol vinculado a un servicio

Antes de poder utilizar IAM para eliminar una función vinculada a un servicio, primero debe confirmar que
dicha función no tiene sesiones activas y eliminar los recursos que utiliza.
Para comprobar si la función vinculada al servicio tiene una sesión activa en la consola de IAM
1. Inicie sesión en la Consola de administración de AWS y abra la consola de IAM en https://

console.aws.amazon.com/iam/.
2. En el panel de navegación de la consola de IAM, elija Roles (Funciones). A continuación, seleccione el
nombre (no la casilla de verificación) de la función de AWSServiceRoleForRDS.
3. En la página Summary (Resumen) del rol seleccionado, elija la pestaña Access Advisor (Acceso a
Advisor).
4. En la pestaña Access Advisor, revise la actividad reciente del rol vinculado al servicio.
Note
Si no está seguro de si Amazon Aurora utiliza el rol AWSServiceRoleForRDS, puede intentar

eliminar el rol para comprobarlo. Si el servicio está utilizando el rol, este no podrá eliminarse y
podrá ver las regiones de AWS en las que se está utilizando. Si el rol se está utilizando, debe
esperar que la sesión finalice para poder eliminarlo. No se puede revocar la sesión de un rol
vinculado a un servicio.
Si desea eliminar la función de AWSServiceRoleForRDS, primero debe eliminar todos sus clústeres de
base de datos.
Eliminación de todos los clústeres

Use alguno de estos procedimientos para eliminar un clúster. Repita el procedimiento para cada uno de los
clústeres.
Para eliminar un clúster (consola)

2. En la lista Databases (Bases de datos), elija el clúster que desea eliminar.
3. En Cluster Actions (Acciones de clúster), seleccione Delete (Eliminar).
4. Elija Eliminar.
Para eliminar un clúster (CLI)
Consulte delete-db-cluster en la AWS CLI Command Reference.
Para eliminar un clúster (API)
Consulte DeleteDBCluster en la Amazon RDS API Reference.
Puede usar la consola de IAM, la CLI de IAM o la API de IAM para eliminar la función vinculada al servicio
AWSServiceRoleForRDS. Para obtener más información, consulte Eliminar un rol vinculado a un servicio

210
Uso de Amazon Aurora con Amazon VPC
VPC Amazon Virtual Private Cloud y Amazon

Aurora
Amazon Virtual Private Cloud (Amazon VPC) permite lanzar recursos de AWS como, por ejemplo,
clústeres de base de datos Aurora, en una Virtual Private Cloud (VPC).
Cuando se utiliza una Amazon VPC, se tiene control sobre el entorno de red virtual: es posible seleccionar
un intervalo de direcciones IP propio, crear subredes y configurar el enrutamiento y las listas de control de
acceso. Es posible ejecutar la instancia de base de datos en Amazon VPC sin ningún costo adicional.
Las cuentas que solo admiten la plataforma EC2-VPC tienen una VPC predeterminada. Todas las
instancias de bases de datos nuevas se crean en la VPC predeterminada, a menos que se especifique lo
contrario. Si es un cliente nuevo de Amazon Aurora, si nunca ha creado una instancia de base de datos
antes, o si está creando una instancia de base de datos en una región de AWS que no ha utilizado antes,
lo más probable es que esté en la plataforma EC2-VPC y que tenga una VPC predeterminada.
Temas
• Cómo crear una VPC para el uso con Amazon Aurora (p. 211)
• Escenarios para el acceso a una instancia de base de datos situada en una VPC (p. 218)
• Uso de una instancia de base de datos en una VPC (p. 222)
• Tutorial: Creación de una Amazon VPC para utilizarla con una instancia de base de datos (p. 227)
En esta documentación solo se describe la funcionalidad de VPC relevante para los clústeres de base
de datos de Amazon Aurora. Para obtener más información sobre Amazon VPC, consulte Guía de
introducción a Amazon VPC y Guía del usuario de Amazon VPC. Para obtener información sobre una
gateway de traducción de direcciones de red (NAT), consulte NAT Gateways (Gateways NAT) en la Guía
de usuario de Amazon Virtual Private Cloud.
Cómo crear una VPC para el uso con Amazon Aurora

En las secciones siguientes se analiza el procedimiento para crear una VPC para utilizarla con Amazon
Aurora.
Note
Para obtener una guía detallada y práctica sobre la conexión a un clúster de base de datos de
Amazon Aurora, puede consultar el manual del administrador de base de datos de Aurora MySQL:
Administración de conexión.

211
Creación de una VPC para Aurora
Creación de una VPC y de subredes

Solo puede crear clúster de base de datos Aurora en una Virtual Private Cloud (VPC) que abarca dos
zonas de disponibilidad y cada zona debe contener al menos una subred. Puede crear un clúster de
base de datos de Aurora en la VPC predeterminada para su cuenta de AWS o crear una VPC definida
por el usuario. Para obtener información, consulte VPC Amazon Virtual Private Cloud y Amazon
Aurora (p. 211).
Amazon Aurora creará, opcionalmente, una VPC y un grupo de subredes para que pueda usarlos con el
clúster de base de datos. Esto puede resultar útil si nunca ha creado una VPC o si desea crear una nueva
VPC independiente de las otras VPC. Si quiere que Amazon Aurora cree una VPC y un grupo de subredes,
omita este procedimiento y consulte Crear un clúster de base de datos (p. 55).
Note
Todos los recursos de EC2 y VPC que se usan con un clúster de base de datos de Aurora deben
estar en una de las siguientes regiones: US East (N. Virginia), EE.UU. Este (Ohio), EE.UU. Oeste
(Oregón), Asia Pacífico (Mumbai), Asia Pacífico (Seúl), Asia Pacífico (Sídney), Asia Pacífico
(Tokio), Canadá (Central), UE (Irlanda), UE (Londres).
Para crear una VPC para el uso con un clúster de base de datos de Aurora
console.aws.amazon.com/vpc/.
que desea crear la VPC. En este ejemplo se utiliza la región EE.UU. Este (Ohio).
3. En la esquina superior izquierda, elija VPC Dashboard. Elija Start VPC Wizard (Iniciar asistente de VPC)
para comenzar a crear una VPC.
4. En el asistente Create VPC (Crear VPC), elija VPC with a Single Public Subnet (VPC con una única
subred pública). Elija Select.
5. Defina los siguientes valores en el panel Create VPC:

• IP CIDR block: 10.0.0.0/16
• VPC name: gs-cluster-vpc
• Public subnet: 10.0.0.0/24
• Availability Zone: us-east-1a
• Subnet name: gs-subnet1
• Enable DNS hostnames: Yes
• Hardware tenancy: Default

212
6. Seleccione Create VPC.

7. Cuando se haya creado la VPC, elija Close (Cerrar) en la página de notificación.
Para crear subredes adicionales
1. Para añadir la segunda subred a la VPC, en VPC Dashboard (Panel VPC), elija Subnets (Subredes) y,
por último, Create Subnet (Crear subred). Un clúster de base de datos de Amazon Aurora requiere al
menos dos subredes de VPC.
2. Defina los siguientes valores en el panel Create Subnet:
• Name tag: gs-subnet2
• VPC: seleccione la VPC que creó en el paso anterior, por ejemplo: vpc-a464d1c1 (10.0.0.0/16)
| gs-cluster-vpc.
• Availability Zone: us-east-1c
• CIDR block: 10.0.1.0/24

213
3. Elija Yes, Create (Sí, crear).

4. Para garantizar que la segunda subred que ha creado usa la misma tabla de ruteo que la primera
subred, en el panel de la VPC haga clic en Subnets y, a continuación, seleccione la primera subred que
se creó para la VPC, gs-subnet1. Elija la pestaña Route Table (Tabla de enrutamiento) y tome nota de
Current Route Table (Tabla de enrutamiento actual), por ejemplo: rtb-c16ce5bc.
5. En la lista de subredes, anule la selección de la primera subred y seleccione la segunda subred, gs-
subnet2. Seleccione la pestaña Route Table (Tabla de enrutamiento) y, a continuación, haga clic en
Edit (Editar). En la lista Change to, seleccione la tabla de ruteo del paso anterior, por ejemplo: rtb-
c16ce5bc. Elija Save (Guardar) para guardar la selección.
Creación de un grupo de seguridad y adición de reglas entrantes

Una vez que haya creado la VPC y las subredes, el siguiente paso es crear un grupo de seguridad y añadir
reglas de entrada.
Para crear un grupo de seguridad
El último paso de la creación de una VPC para el uso con un clúster de base de datos de Amazon Aurora
es crear un grupo de seguridad de VPC, que identificará las direcciones de red y los protocolos que tienen
permiso para obtener acceso a las instancias de base de datos de la VPC.

214
1. En VPC Dashboard (Panel VPC), elija Security Groups (Grupos de seguridad) y, a continuación,
seleccione Create Security Group (Crear grupo de seguridad).
2. Defina los siguientes valores en el panel Create Security Group:
• Name tag: gs-securitygroup1
• Group name: gs-securitygroup1
• Description: Getting Started Security Group
• VPC: seleccione la VPC que creó antes, por ejemplo: vpc-b5754bcd | gs-cluster-vpc.
3. Para crear el grupo de seguridad, elija Yes, Create (Sí, crear).
Para añadir reglas de entrada al grupo de seguridad
Para conectarse al clúster de base de datos Aurora, tendrá que añadir al grupo de seguridad de la VPC
una regla de entrada que permita conectarse al tráfico entrante.
1. Determine la dirección IP que usará para conectarse al clúster de Aurora. Puede usar el servicio
disponible en https://checkip.amazonaws.com para determinar su dirección IP pública. Si se conecta a
través de un ISP o protegido por su firewall sin una dirección IP estática, deberá encontrar el rango de
direcciones IP utilizadas por los equipos cliente.
Warning
Si utiliza 0.0.0.0/0, permitirá que todas las direcciones IP obtengan acceso a su clúster de
base de datos. Esto es aceptable para un periodo de tiempo corto en un entorno de prueba,
pero no es seguro en entornos de producción. En producción, solo debe autorizar el acceso a
su clúster de base de datos a una dirección IP específica o un rango de direcciones.
2. En el panel de la VPC, elija Security Groups (Grupos de seguridad) y, a continuación, seleccione el
grupo de seguridad gs-securitygroup1 que creó en el procedimiento anterior.
3. Seleccione la pestaña Inbound Rules (Reglas de entrada) y, a continuación, elija el botón Edit (Editar).
4. Defina los siguientes valores para la nueva regla de entrada:
• Type: All Traffic
• Origen: la dirección IP o el rango de direcciones del paso anterior, por ejemplo 203.0.113.25/32.
5. Seleccione Save (Guardar) para guardar las configuraciones.

215
Creación de un grupo de subredes de base de datos

Lo último que necesita antes de crear un clúster de base de datos de Aurora es un grupo de subredes
de base de datos. El grupo de subredes de base de datos identifica las subredes de la VPC creada en
los pasos anteriores que usará el clúster de base de datos. El grupo de subredes de base de datos debe
incluir como mínimo una subred en al menos dos de las zonas de disponibilidad de la región de AWS en la
que desea implementar su clúster de base de datos.
Para crear un grupo de subredes de base de datos para el uso con un clúster de base de datos de Aurora
1. Abra la consola de Amazon Aurora en https://console.aws.amazon.com/rds.

2. Seleccione Subnet Groups (Grupos de subredes) y, a continuación, elija Create DB Subnet Group
(Crear grupo de subredes de base de datos).
3. Defina los siguientes valores para el nuevo grupo de subredes de base de datos:
• Name: gs-subnetgroup1
• Description: Getting Started Subnet Group
• VPC ID: seleccione la VPC que creó en el procedimiento anterior, por ejemplo, gs-cluster-vpc
(vpc-b5754bcd).
4. Elija Add all the subnets related to this VPC (Añadir todas las subredes relacionadas con esta VPC) para
añadir las subredes para la VPC que creó en los pasos anteriores. También puede añadir cada subred
por separado. Para ello, seleccione Availability zone, especifique el valor de Subnet y haga clic en Add
subnet.

216
5. Elija Create (Crear) para crear el grupo de subredes.

217
Escenarios para el acceso a una instancia
de base de datos situada en una VPC
Escenarios para el acceso a una instancia de base de

datos situada en una VPC
Amazon Aurora admite los siguientes escenarios para obtener acceso a una instancia de base de datos:
• Una instancia EC2 de la misma VPC (p. 218)

• Una instancia EC2 de otra VPC (p. 219)
• Una instancia EC2 que no está en una VPC (p. 220)
• Una aplicación cliente a través de Internet (p. 221)
Acceso a una instancia de base de datos situada en una VPC

desde una instancia EC2 de la misma VPC
Un uso común de una instancia de base de datos en una VPC es compartir datos con un servidor de
aplicaciones que se ejecuta en una instancia EC2 de la misma VPC. Este es el escenario de usuario que
se crea cuando se utiliza AWS Elastic Beanstalk para crear una instancia EC2 y una instancia de base de
datos en la misma VPC.
La forma más sencilla de administrar el acceso entre instancias EC2 e instancias de bases de datos de la
misma VPC es hacer lo siguiente:
• Cree el grupo de seguridad de VPC al que pertenecerán las instancias de bases de datos. Este grupo
de seguridad se puede utilizar para restringir el acceso a las instancias de bases de datos. Por ejemplo,
puede crear una regla personalizada para este grupo de seguridad que permita el acceso mediante TCP
utilizando el puerto que asignó a la instancia de base de datos cuando la creó, y una dirección IP que se
utilizará para obtener acceso a la instancia de base de datos para fines de desarrollo u otros propósitos.
• Cree el grupo de seguridad de VPC al que pertenecerán las instancias EC2 (clientes y servidores web).
Si es necesario, este grupo de seguridad puede permitir el acceso a la instancia EC2 desde Internet a
través de la tabla de enrutamiento de la VPC. Por ejemplo, puede establecer reglas en este grupo de
seguridad para permitir el acceso mediante TCP a la instancia EC2 a través del puerto 22.

218
• Cree reglas personalizadas en el grupo de seguridad para las instancias de bases de datos que
permitan las conexiones desde el grupo de seguridad que creó para las instancias EC2. Esto permitiría a
cualquier miembro del grupo de seguridad obtener acceso a las instancias de bases de datos.
Para ver un tutorial que muestra cómo crear una VPC con subredes públicas y privadas para este
escenario, consulte Tutorial: Creación de una Amazon VPC para utilizarla con una instancia de base de
datos (p. 227).
Para crear una regla en un grupo de seguridad de VPC que permita establecer conexiones desde
otro grupo de seguridad, haga lo siguiente:
2. En el panel de navegación, elija Security Groups.
3. Seleccione o cree el grupo de seguridad al que desea que puedan tener acceso los miembros de
otro grupo de seguridad. En el escenario anterior, este es el grupo de seguridad que utiliza para las
instancias de base de datos. Elija la pestaña Inbound Rules (Reglas de entrada) y, a continuación,
elija Edit rule (Editar regla).
4. En la página Edit inbound rules (Editar reglas de entrada), seleccione Add Rule (Añadir regla).
5. En Type (Tipo), seleccione una de las opciones All ICMP (Todos los ICMP). En el campo Source,
comience a escribir el ID del grupo de seguridad; se mostrará una lista de grupos de seguridad.
Seleccione el grupo de seguridad cuyos miembros desea que tengan acceso a los recursos protegidos
por este grupo de seguridad. En el escenario anterior, este es el grupo de seguridad que utiliza para
su instancia EC2.
6. Repita los pasos para el protocolo TCP creando una regla con All TCP en el campo Type y con el
grupo de seguridad en el campo Source. Si va a utilizar el protocolo UDP, cree una regla con All UDP
en el campo Type y con el grupo de seguridad en el campo Source.
7. Cree una regla TCP personalizada que permita el acceso a través del puerto que ha usado al crear
la instancia de base de datos, como, por ejemplo, el puerto 3306 para MySQL. En el campo Source
(Origen), introduzca el grupo de seguridad o la dirección IP que utilizará.
8. Cuando haya terminado, elija Save (Guardar).

desde una instancia EC2 de otra VPC
Cuando una instancia de base de datos está en una VPC que no coincide con la de la instancia EC2 que
se está utilizando para obtener acceso a ella, puede usar la interconexión con VPC para obtener acceso a

219
Una interconexión de VPC es una conexión de redes entre dos VPC que permite direccionar el tráfico entre
ellas mediante direcciones IP privadas. Las instancias de ambas VPC se pueden comunicar entre sí como
si estuvieran en la misma red. Puede crear una interconexión de VPC entre sus propias VPC, con una VPC
de otra cuenta de AWS o con una VPC de otra región de AWS. Para obtener más información sobre las
interconexiones de VPC, consulte Interconexión con VPC en la Guía de usuario de Amazon Virtual Private
Cloud.

desde una instancia EC2 que no está en una VPC
Es posible la comunicación entre una instancia de base de datos de Amazon Aurora que se encuentra
en una VPC y una instancia EC2 que no está en una Amazon VPC utilizando ClassicLink. Cuando se
utiliza ClassicLink, una aplicación de la instancia EC2 puede conectarse a la instancia de base de datos
utilizando el punto de enlace de la instancia de base de datos. ClassicLink está disponible sin ningún costo
adicional.
ClassicLink permite conectar una instancia EC2 a una base de datos lógicamente aislada en la que se
define el rango de direcciones IP y se controlan las listas de control de acceso (ACL) para administrar el
tráfico de red. No es necesario utilizar direcciones IP públicas ni túneles para comunicarse con la instancia
de base de datos de la VPC. Esta disposición proporciona un mayor desempeño y una menor latencia de
conectividad para las comunicaciones entre instancias.

220
Para activar ClassicLink entre una instancia de base de datos de una VPC y una instancia EC2
que no esté en una VPC
2. En el panel de navegación, elija Your VPCs.
3. Elija la VPC utilizada por la instancia de base de datos.
4. En Actions, elija Enable ClassicLink. En el cuadro de diálogo de confirmación, elija Yes, Enable (Sí,
habilitar).
5. En la consola EC2, seleccione la instancia EC2 que desea conectar a la instancia de base de datos de
la VPC.
6. En Actions, elija ClassicLink y, a continuación, elija Link to VPC.
7. En la página Link to VPC, elija el grupo de seguridad que desea utilizar y, a continuación, seleccione
Link to VPC.
Note
Las características de ClassicLink solo están visibles en las consolas de las cuentas y regiones
que admiten EC2-Classic. Para obtener más información, consulte ClassicLink en la Guía del
usuario de Amazon EC2 para instancias de Linux.

desde una aplicación cliente a través de Internet
Para acceder a una instancia de base de datos situada en una VPC desde una aplicación cliente a través
de Internet, configure una VPC con una única subred pública y una gateway de Internet para permitir la
comunicación a través de Internet.
Recomendamos la siguiente configuración:
• Una VPC de tamaño /16 (por ejemplo, CIDR: 10.0.0.0/16). Este tamaño proporciona 65 536 direcciones
IP privadas.
• Una subred de tamaño /24 (por ejemplo, CIDR: 10.0.0.0/24). Este tamaño proporciona 256 direcciones
IP privadas.
• Una instancia de base de datos de Amazon Aurora asociada a la VPC y a la subred. Amazon RDS
asigna una dirección IP de la subred a la instancia de base de datos.

221
Uso de una instancia de base de datos en una VPC
• Una gateway de Internet que conecte la VPC a Internet y a otros productos de AWS.
• Un grupo de seguridad asociado a la instancia de base de datos. Las reglas de entrada del grupo de
seguridad permiten a la aplicación cliente obtener acceso a la instancia de base de datos.
Para obtener información acerca de la creación de una instancia de base de datos en una VPC, consulte
Creación de una instancia de base de datos en una VPC (p. 224).

se encuentra en una Virtual Private Cloud (VPC). Puede configurar una VPC, que es una red virtual que
está aislada de forma lógica de otras redes virtuales de la nube de AWS. Amazon VPC permite lanzar
recursos de AWS como, por ejemplo, una instancia de base de datos de Amazon Aurora o una instancia
de Amazon EC2, en una VPC. La VPC puede ser una VPC predeterminada que viene con la cuenta o una
que se haya creado en ella. Todas las VPC están asociadas a la cuenta de AWS.
La VPC predeterminada tiene tres subredes que se pueden utilizar para aislar recursos dentro de la VPC.
La VPC predeterminada también tiene una gateway de Internet que se puede utilizar para proporcionar
acceso a los recursos situados dentro de la VPC desde fuera de la VPC.
Para obtener una lista de los escenarios relacionados con las instancias de bases de datos de
Amazon Aurora , consulte Escenarios para el acceso a una instancia de base de datos situada en una
VPC (p. 218).
Para ver un tutorial que muestra cómo crear una VPC que se puede utilizar con un escenario común de
Amazon Aurora, consulte Tutorial: Creación de una Amazon VPC para utilizarla con una instancia de base
de datos (p. 227).
Para obtener información sobre cómo utilizar instancias de bases de datos situadas dentro de una VPC,
consulte los siguientes temas:
Temas
• Uso de una instancia de base de datos en una VPC (p. 222)
• Uso de los grupos de subredes de base de datos (p. 223)
• Cómo ocultar una instancia de base de datos en una VPC desde Internet. (p. 223)
• Creación de una instancia de base de datos en una VPC (p. 224)

A continuación se ofrecen algunos consejos para utilizar una instancia de base de datos en una VPC:
• La VPC debe tener dos subredes como mínimo. Estas subredes deben estar en dos zonas de
disponibilidad distintas de la región de AWS en la que desea implementar la instancia de base de datos.
Una subred es un segmento del rango de direcciones IP de una VPC que puede especificar y que le
permite agrupar instancias según sus necesidades operativas y de seguridad.
• Si desea que una instancia de base de datos de la VPC sea accesible públicamente, debe activar los
atributos DNS hostnames y DNS resolution de la VPC.
• La VPC debe tener un grupo de subredes de base de datos creado específicamente (para obtener
más información, consulte la siguiente sección). Puede crear un grupo de subredes de base de datos
especificando las subredes que ha creado. Amazon Aurora utiliza ese grupo de subredes de base de
datos y su zona de disponibilidad preferida para seleccionar una subred y una dirección IP dentro de esa
subred con el fin de asignársela a la instancia de base de datos.
• La VPC debe tener un grupo de seguridad de VPC que permita el acceso a la instancia de base de
datos.

222
• Los bloques de CIDR de cada una de las subredes deben ser lo suficientemente grandes como para
acomodar direcciones IP de repuesto para que Amazon Aurora las use durante las actividades de
mantenimiento, incluyendo la conmutación por error y el escalado de recursos de computación.
• El atributo instance tenancy de una VPC puede definirse como default o dedicated. Todas las
VPC predeterminadas tienen el atributo de tenencia de instancia definido como default, y una VPC
predeterminada puede admitir cualquier clase de instancia de base de datos.
Si opta por tener la instancia de base de datos en una VPC dedicada cuyo atributo de tenencia de
instancia está establecido en dedicated, la clase de instancia de base de datos de la instancia debe ser
uno de los tipos aprobados de instancia dedicada de Amazon EC2. Por ejemplo, la instancia dedicada
m3.medium de EC2 corresponde a la clase de instancia de base de datos db.m3.medium. Para obtener
información acerca de la tenencia de instancias en una VPC, vaya a Uso de las instancias dedicadas de
EC2 en la Guía del usuario de Amazon Virtual Private Cloud.
Para obtener más información acerca de los tipos de instancia que puede haber en una instancia
dedicada, consulte Instancias dedicadas de Amazon EC2 en la página de precios de EC2.
Uso de los grupos de subredes de base de datos

Las subredes son segmentos del rango de direcciones IP de una VPC que se definen para agrupar
recursos de acuerdo con las necesidades operativas y de seguridad. Un grupo de subredes de base de
datos es una colección de subredes (normalmente privadas) que se crean en una VPC y que después se
asignan a las instancias de bases de datos. Un grupo de subredes de base de datos le permite especificar
una VPC específica al crear instancias de bases de datos utilizando la CLI o API; si utiliza la consola, solo
puede seleccionar la VPC y las subredes que desea utilizar.
Cada grupo de subredes de base de datos debe tener subredes como mínimo en dos zonas de
disponibilidad de una región de AWS determinada. Al crear una instancia de base de datos en una VPC,
debe seleccionar un grupo de subredes de base de datos. Amazon Aurora utiliza ese grupo de subredes
de base de datos y su zona de disponibilidad preferida para seleccionar una subred y una dirección IP
dentro de esa subred con el fin de asociarla a la instancia de base de datos. Si falla la instancia de base
de datos principal de un despliegue Multi-AZ, Amazon Aurora puede promocionar la instancia en espera
correspondiente y, posteriormente, crear una nueva instancia en espera utilizando una dirección IP de la
subred de una de las otras zonas de disponibilidad.
Cuando Amazon Aurora crea una instancia de base de datos en una VPC, asigna una interfaz de red a
la instancia de base de datos utilizando una dirección IP seleccionada del grupo de subredes de base de
datos. Sin embargo, recomendamos que utilice el nombre de DNS para conectarse a la instancia de base
de datos, ya que la dirección IP subyacente cambia durante la conmutación por error.
Note
Para cada instancia de base de datos que ejecute en una VPC, debe reservar al menos una
dirección en cada subred del grupo de subredes de base de datos para que la utilice Amazon
Aurora para las acciones de recuperación.
Cómo ocultar una instancia de base de datos en una VPC desde

Internet.
Un escenario común de Amazon Aurora consiste en tener una VPC en la que hay una instancia EC2 con
una aplicación web abierta al público y una instancia de base de datos con una base de datos que no
está accesible públicamente. Por ejemplo, puede crear una VPC que tenga una subred pública y una
subred privada. Las instancias Amazon EC2 que funcionan como servidores web se pueden implementar
en la subred pública y las instancias de bases de datos se implementan en la subred privada. En una
implementación de este tipo, solo los servidores web tienen acceso a las instancias de bases de datos.

223
Para ver una ilustración de este escenario, consulte Acceso a una instancia de base de datos situada en
una VPC desde una instancia EC2 de la misma VPC (p. 218).
Cuando se lanza una instancia de base de datos dentro de una VPC, el parámetro Public accessibility
(Accesibilidad pública) permite especificar si la instancia de base de datos que se crea tiene un DNS
que se resuelve en una dirección IP pública. Este parámetro permite especificar si hay acceso público a
la instancia de base de datos. El acceso a la instancia de base de datos se controla en última instancia
mediante el grupo de seguridad que utiliza, y que el acceso público no está permitido si el grupo de
seguridad asignado a la instancia de base de datos no lo permite.
Es posible modificar una instancia de base de datos para activar o desactivar la accesibilidad pública
modificando el parámetro Public accessibility (Accesibilidad pública). Este parámetro se modifica como
cualquier otro parámetro de instancia de base de datos. Para obtener más información, consulte la sección
de modificación correspondiente a su motor de base de datos.
La ilustración siguiente muestra la opción Public accessibility (Accesibilidad pública) de la sección Network
& Security (Red y seguridad).
Creación de una instancia de base de datos en una VPC

Los siguientes procedimientos le ayudan a crear una instancia de base de datos en una VPC. Si su
cuenta tiene una VPC predeterminada, puede comenzar por el paso 3, ya que la VPC y el grupo de
subredes de base de datos ya se han creado automáticamente. Si su cuenta de AWS no tiene una VPC
predeterminada, o si desea crear una VPC adicional, puede crear una VPC nueva.
Note
Si desea que una instancia de base de datos de la VPC sea accesible públicamente, debe
actualizar la información de DNS para la VPC activando los atributos DNS hostnames y DNS
resolution de la VPC. Para obtener información acerca de cómo actualizar la información de DNS
para una instancia de VPC, consulte Actualización de la compatibilidad de DNS para su VPC.
Siga estos pasos para crear una instancia de base de datos en una VPC:
• Paso 1: Crear una VPC (p. 225)

• Paso 2: Añadir subredes a la VPC (p. 225)
• Paso 3: Crear un grupo de subredes de base de datos (p. 225)

224
• Paso 4: Crear un grupo de seguridad de VPC (p. 226)

• Paso 5: Crear la instancia de base de datos en la VPC (p. 226)
Paso 1: Crear una VPC

Si su cuenta de AWS no tiene una VPC predeterminada o si desea crear una VPC adicional, siga las
instrucciones para crear una VPC nueva. Consulte Creación de una VPC con subredes públicas y
privadas (p. 228) o Paso 1: Crear una VPC en la documentación de Amazon VPC.
Paso 2: Añadir subredes a la VPC

Una vez que haya creado una VPC, deberá crear subredes como mínimo en dos zonas de disponibilidad.
Utilizará estas subredes cuando cree un grupo de subredes de base de datos. Si tiene una VPC
predeterminada, se crea automáticamente una subred en cada zona de disponibilidad de la región de
AWS.
Para obtener instrucciones sobre cómo crear subredes, consulte Creación de una VPC con subredes
públicas y privadas (p. 228).
Paso 3: Crear un grupo de subredes de base de datos

Un grupo de subredes de base de datos es una colección de subredes (normalmente privadas) que
se crean para una VPC y que después se asignan a las instancias de bases de datos. Un grupo de
subredes de base de datos le permite especificar una VPC específica al crear instancias de bases de
datos utilizando la CLI o API. Si utiliza la consola, solo puede seleccionar la VPC y las subredes que desea
utilizar. Cada grupo de subredes de base de datos debe tener como mínimo una subred en dos zonas de
disponibilidad de la región de AWS.
Note
Para que una instancia de base de datos sea accesible públicamente, las subredes del grupo de
subredes de base de datos deben tener una gateway de Internet. Para obtener más información
acerca de las gateways de Internet para las subredes, consulte Gateways de Internet en la
documentación de Amazon VPC.
Cuando cree una instancia de base de datos en una VPC, debe seleccionar un grupo de subredes de
base de datos. Amazon Aurora utiliza ese grupo de subredes de base de datos y su zona de disponibilidad
preferida para seleccionar una subred. Amazon Aurora crea y asocia una interfaz de red elástica a la
instancia de base de datos que tiene esa dirección IP. Para las implementaciones Multi-AZ, si se define
una subred para dos o más zonas de disponibilidad de una región de AWS, Amazon Aurora podrá crear
una instancia en espera en otra zona de disponibilidad si fuera necesario. Debe hacerlo incluso para los
despliegues Single-AZ, por si desea convertirlos en implementaciones Multi-AZ en algún momento.
En este paso, creará un grupo de subredes de base de datos y añadirá las subredes que creó para la VPC.
Para crear un grupo de subredes de base de datos

2. En el panel de navegación, elija Subnet groups.
3. Elija Create DB Subnet Group.
4. En Name, escriba el nombre del grupo de subredes de base de datos.
5. En Description, escriba la descripción del grupo de opciones de base de datos.
6. En VPC, elija la VPC que ha creado.

225
7. En la sección Add subnets (Añadir subredes), elija Add all the subnets related to this VPC (Añadir
todas las subredes relacionadas con esta VPC).
El nuevo grupo de subredes de base de datos aparece en la lista de grupos de subredes de base
de datos de la consola de RDS. Puede elegir el grupo de subredes de base de datos para ver los
detalles, incluidas todas las subredes asociadas al grupo, en el panel de detalles de la parte inferior de
la ventana.
Paso 4: Crear un grupo de seguridad de VPC

Antes de crear la instancia de base de datos, debe crear un grupo de seguridad de VPC para asociarlo a la
instancia de base de datos. Para obtener instrucciones acerca de cómo crear un grupo de seguridad para
la instancia de base de datos, consulte Creación de un grupo de seguridad de VPC para una instancia
privada de base de datos (p. 230) o Grupos de seguridad de su VPC en la documentación de Amazon
VPC.
Paso 5: Crear la instancia de base de datos en la VPC

En este paso, se crea una instancia de base de datos y se utiliza el nombre de la VPC, el grupo de
subredes de base de datos y el grupo de seguridad de VPC creados en los pasos anteriores.

226
Tutorial: Creación de una Amazon VPC para
utilizarla con una instancia de base de datos
Note
Si desea que una instancia de base de datos de la VPC sea accesible públicamente, debe
activar los atributos DNS hostnames y DNS resolution de la VPC. Para obtener información sobre
cómo actualizar la información de DNS para una instancia de VPC, consulte Actualización de la
compatibilidad de DNS para su VPC.
Para obtener información detallada sobre cómo crear una instancia de base de datos para su motor de
base de datos, consulte el tema correspondiente a su motor de base de datos en la tabla siguiente. Para
cada motor, cuando la sección Network & Security (Red y seguridad) se lo pida, introduzca el nombre de
la VPC, el grupo de subredes de base de datos y el grupo de seguridad de VPC que creó en los pasos
anteriores.
Motor de base de datos Documentación relacionada
Amazon Aurora Creación de un clúster de base de datos de Amazon Aurora (p. 85)
Note
La actualización de VPC no se admite actualmente para los clústeres de Aurora.
Tutorial: Creación de una Amazon VPC para utilizarla

con una instancia de base de datos
Un escenario común incluye una instancia de base de datos en una Amazon VPC, que comparte datos con
un servidor web que se ejecuta en la misma VPC. En este tutorial se crea la VPC para este escenario.
En el siguiente diagrama se muestra este escenario. Para obtener información acerca de otros escenarios,
consulte Escenarios para el acceso a una instancia de base de datos situada en una VPC (p. 218).
Debido a que la instancia de base de datos solo necesita estar disponible para su servidor web y no para
la red pública de Internet, debe crear una VPC con subredes tanto públicas como privadas. El servidor web
está alojado en la subred pública, para que pueda obtener acceso a la red pública de Internet. La instancia

227
de base de datos está alojada en una subred privada. El servidor web puede conectarse a la instancia de
base de datos porque está alojado de la misma VPC, pero la instancia de base de datos no está disponible
para la red pública de Internet, lo que proporciona mayor seguridad.
Creación de una VPC con subredes públicas y privadas

Utilice el siguiente procedimiento para crear una VPC con subredes públicas y privadas.
Para crear una VPC y las subredes
1. Abra la consola de Amazon VPC en https://console.aws.amazon.com/vpc/.

2. En la esquina superior derecha de la Consola de administración de AWS, elija la región en la que
desea crear la VPC. En este ejemplo se utiliza la región EE.UU. Oeste (Oregón).
3. En la esquina superior izquierda, elija VPC Dashboard. Para comenzar a crear una VPC, elija Launch
VPC Wizard (Lanzar asistente de VPC).
4. En la página Step 1: Select a VPC Configuration, elija VPC with Public and Private Subnets y, a
continuación, elija Select.
5. En la página Step 2: VPC with Public and Private Subnets, establezca estos valores:
• IPv4 CIDR block: 10.0.0.0/16

• IPv6 CIDR block: No IPv6 CIDR Block
• VPC name: tutorial-vpc
• Public subnet's IPv4 CIDR: 10.0.0.0/24
• Availability Zone: us-west-2a
• Public subnet name: Tutorial public
• Private subnet's IPv4 CIDR: 10.0.1.0/24
• Availability Zone: us-west-2a
• Private subnet name: Tutorial Private 1
• Instance type: t2.small
Important
Si no ve el cuadro Instance type (Tipo de instancia) en la consola, elija Use a NAT instance
instead (Usar una instancia NAT). Este enlace está a la derecha.
Note
Si no aparece el tipo de instancia t2.small, puede elegir un tipo de instancia diferente.

• Key pair name: No key pair
• Service endpoints: omita este campo.
• Enable DNS hostnames: Yes
• Hardware tenancy: Default
6. Cuando haya terminado, elija Create VPC.
Creación de las subredes adicionales

Debe tener dos subredes privadas o dos subredes públicas disponibles para crear un grupo de subredes
de base de datos para que lo utilice una instancia de base de datos en una VPC. Debido a que la instancia
de base de datos de este tutorial es privada, debe añadir una segunda subred privada a la VPC.
Para crear una subred adicional

228
2. Para añadir la segunda subred privada a la VPC, elija VPC Dashboard (Panel VPC), seguido de
Subnets (Subredes) y, por último, Create Subnet (Crear subred).
3. En la página Create Subnet (Crear subred), defina estos valores:
• Name tag: Tutorial private 2

• VPC: elija la VPC que creó anteriormente, por ejemplo: vpc-identifier (10.0.0.0/16) |
tutorial-vpc.
• Availability Zone: us-west-2b
Note
Elija una zona de disponibilidad que sea distinta de la que eligió para la primera subred
privada.
• IPv4 CIDR block: 10.0.2.0/24
4. Cuando haya terminado, elija Create (Crear). A continuación, seleccione Close (Cerrar) en la página
de confirmación.
5. Para asegurarse de que la segunda subred privada que ha creado utiliza la misma tabla de ruteo que
la primera, elija VPC Dashboard, seguido de Subnets y, por último, elija la primera subred privada que
se creó para la VPC, Tutorial private 1.
6. Debajo de la lista de subredes, elija la pestaña Route Table (Tabla de enrutamiento) y anote el valor
de Route Table (Tabla de enrutamiento), por ejemplo: rtb-98b613fd.
7. En la lista de subredes, anule la selección de la primera subred privada.
8. En la lista de subredes, elija la segunda subred privada Tutorial private 2 y elija la pestaña
Route Table.
9. Si la tabla de ruteo actual no es la misma que la tabla de ruteo de la primera subred privada,
seleccione Edit route table association (Editar asociación de tabla de ruteo). En Route Table ID (ID de
tabla de ruteo), elija la tabla de enrutamiento que anotó anteriormente, por ejemplo: rtb-98b613fd.
A continuación, para guardar lo que ha seleccionado, elija Save (Guardar).
Creación de un grupo de seguridad de VPC para un servidor web

público
A continuación, debe crear un grupo de seguridad para el acceso público. Para conectarse a instancias
públicas en la VPC, añada reglas de entrada al grupo de seguridad de VPC que permitan el tráfico para las
conexiones desde Internet.

2. Elija VPC Dashboard (Panel VPC), seguido de Security Groups (Grupos de seguridad) y, por último,
Create Security Group (Crear grupo de seguridad).
3. En la página Create Security Group (Crear grupo de seguridad), establezca estos valores:
• Security group name (Nombre de grupo de seguridad): tutorial-securitygroup

• Description: Tutorial Security Group
• VPC: elija la VPC que creó antes; por ejemplo: vpc-identifier (10.0.0.0/16) |
tutorial-vpc.
4. Para crear el grupo de seguridad, elija Create (Crear). A continuación, seleccione Close (Cerrar) en la
página de confirmación.
Anote el ID del grupo de seguridad, ya que lo necesitará más tarde en este tutorial.
229
1. Determine la dirección IP que usará para conectarse a las instancias de la VPC. Puede usar el servicio
disponible en https://checkip.amazonaws.com para determinar su dirección IP pública. Un ejemplo de
dirección IP es 203.0.113.25/32.
Si se conecta a través de un proveedor de Internet (ISP) o protegido por un firewall sin una dirección
IP estática, deberá identificar el rango de direcciones IP utilizadas por los equipos cliente.
Warning
Si utiliza 0.0.0.0/0, permitirá que todas las direcciones IP tengan acceso a las instancias
públicas. Este método es aceptable para un periodo de tiempo corto en un entorno de
prueba, pero no es seguro en entornos de producción. En entornos de producción, solo
debe permitir el acceso a las instancias desde una dirección IP o un rango de direcciones
específico.
3. Elija VPC Dashboard, seguido de Security Groups y, por último, el grupo de seguridad tutorial-
securitygroup que creó en el procedimiento anterior.
4. Bajo la lista de grupos de seguridad, seleccione la pestaña Inbound Rules (Reglas de entrada) y,
luego, seleccione Edit (Editar).
6. Establezca los siguientes valores para la regla de entrada nueva con objeto de permitir el acceso
Secure Shell (SSH) a la instancia de EC2. Si lo hace, puede conectarse a la instancia de EC2 para
instalar el servidor web y otras utilidades, y para cargar contenido para el servidor web.
• Type: SSH
• Source: la dirección IP o el rango de direcciones del Paso 1, por ejemplo 203.0.113.25/32.
7. Seleccione Add rule.
8. Establezca los siguientes valores para la regla de entrada nueva con objeto de permitir el acceso
HTTP al servidor web.
• Type: HTTP
• Source: 0.0.0.0/0.
9. Para guardar la configuración, elija Save rules (Guardar reglas). A continuación, seleccione Close
(Cerrar) en la página de confirmación.
Creación de un grupo de seguridad de VPC para una instancia

privada de base de datos
Para que una instancia de base de datos sea privada, cree un segundo grupo de seguridad para el acceso
privado. Para conectarse a instancias privadas en la VPC, añada reglas de entrada al grupo de seguridad
de VPC que permitan el tráfico desde su servidor web únicamente.

2. Elija VPC Dashboard (Panel VPC), seguido de Security Groups (Grupos de seguridad) y, por último,
Create Security Group (Crear grupo de seguridad).
3. En la página Create Security Group (Crear grupo de seguridad), establezca estos valores:
• Security group name (Nombre de grupo de seguridad): tutorial-db-securitygroup

• Description: Tutorial DB Instance Security Group

230
• VPC: elija la VPC que creó antes; por ejemplo: vpc-identifier (10.0.0.0/16) |
tutorial-vpc.
4. Para crear el grupo de seguridad, elija Create (Crear). A continuación, seleccione Close (Cerrar) en la
página de confirmación.

2. Elija VPC Dashboard, seguido de Security Groups y, por último, el grupo de seguridad tutorial-
db-securitygroup que creó en el procedimiento anterior.
3. Bajo la lista de grupos de seguridad, seleccione la pestaña Inbound Rules (Reglas de entrada) y,
luego, seleccione Edit (Editar).
5. Establezca los siguientes valores para la regla de entrada nueva con objeto de permitir el tráfico de
MySQL en el puerto 3306 desde la instancia de EC2. Si lo hace, podrá conectarse desde su servidor
web a la instancia de base de datos para almacenar y recuperar datos en la base de datos desde la
aplicación web.
• Type: MySQL/Aurora
• Source: el identificador del grupo de seguridad tutorial-securitygroup que creó
anteriormente en este tutorial; por ejemplo: sg-9edd5cfb.
6. Para guardar la configuración, elija Save rules (Guardar reglas). A continuación, seleccione Close
(Cerrar) en la página de confirmación.
Creación de un grupo de subredes de base de datos

Un grupo de subredes de base de datos es una colección de subredes que se crean en una VPC y que
después se asignan a las instancias de bases de datos. Un grupo de subredes de base de datos le permite
especificar una VPC específica al crear instancias de bases de datos.
Para crear un grupo de subredes de base de datos

2. En el panel de navegación, elija Subnet groups.
3. Elija Create DB Subnet Group.
4. En la página Create DB subnet group (Crear grupo de subredes de base de datos), establezca estos
valores en Subnet group details (Detalles del grupo de subredes):
• Name: tutorial-db-subnet-group
• Description: Tutorial DB Subnet Group
• VPC: tutorial-vpc (vpc-identifier)
5. En la sección Add subnets (Añadir subredes), elija Add all the subnets related to this VPC (Añadir
todas las subredes relacionadas con esta VPC).
El nuevo grupo de subredes de base de datos aparece en la lista de grupos de subredes de base de
datos de la consola de RDS. Puede hacer clic en el grupo de subredes de base de datos para ver los
detalles, incluidas todas las subredes asociadas al grupo, en el panel de detalles de la parte inferior de
la ventana.

231
Detención e inicio de un clúster
Administración de un clúster de base

de datos de Amazon Aurora
En esta sección se muestra cómo administrar y mantener el clúster de base de datos Aurora. Aurora
implica clústeres de servidores de bases de datos que están conectados con una topología de replicación.
Por lo tanto, la administración de Aurora suele requerir la implementación de cambios en varios servidores
y asegurarse de que todas las réplicas de Aurora mantengan el ritmo del servidor maestro. Dado que
Aurora escala transparentemente el almacenamiento subyacente a medida que crecen sus datos, la
administración de Aurora requiere relativamente poco esfuerzo administrativo del almacenamiento en
disco. Del mismo modo, dado que Aurora realiza automáticamente copias de seguridad continuas, un
clúster de Aurora no requiere una planificación extensa ni tiempo de inactividad a la hora de realizarlas.
Temas
• Detención e inicio de un clúster de base de datos Amazon Aurora (p. 232)
• Modificación de un clúster de base de datos Amazon Aurora (p. 235)
• Adición de réplicas de Aurora a un clúster de base de datos (p. 254)
• Administración del desempeño y el escalado para clústeres de base de datos Aurora (p. 257)
• Trabajo con los grupos de parámetros de base de datos y grupos de parámetros de clúster de base de
datos (p. 259)
• Clonación de bases de datos en un clúster de bases de datos de Aurora (p. 282)
• Integración de Aurora con otros servicios de AWS (p. 297)
• Backup y restauración de un clúster de base de datos de Amazon Aurora (p. 314)
• Mantenimiento de un clúster de base de datos de Amazon Aurora (p. 340)
• Reinicio de una instancia de base de datos en un clúster de base de datos (p. 347)
• Eliminación de una instancia de base de datos en un clúster de base de datos de Aurora (p. 348)
• Etiquetado de recursos de Amazon RDS (p. 349)
• Uso de nombres de recursos de Amazon (ARN) en Amazon RDS (p. 354)
• Actualizaciones de Amazon Aurora (p. 361)
Detención e inicio de un clúster de base de datos

Amazon Aurora
Detener e iniciar los clústeres de Amazon Aurora le ayuda a administrar los costos de entornos de
desarrollo y pruebas. Puede detener temporalmente todas las instancias de base de datos su clúster, en
lugar de configurar y eliminar todas las instancias de base de datos cada vez que use el clúster.
Temas
• Información general de detención e inicio de un clúster de base de datos Aurora (p. 233)
• Limitaciones para la detención e inicio de clústeres de base de datos de Aurora (p. 233)

232
Información general de detención e inicio de un clúster
• Detención de un clúster de base de datos Aurora (p. 233)

• Posibles operaciones mientras un clúster de base de datos Aurora está detenido (p. 234)
• Inicio de un clúster de base de datos Aurora (p. 235)
Información general de detención e inicio de un clúster

de base de datos Aurora
Durante los periodos en los que no necesite un clúster de Aurora, puede detener todas las instancias
de ese clúster a la vez. Puede volver a iniciar el clúster en cualquier momento que necesite usarlo. El
inicio y la detención simplifican los procesos de configuración y eliminación de clústeres usados para
desarrollo, pruebas o actividades similares que no requieren disponibilidad continua. Puede realizar
todos los procedimientos de la Consola de administración de AWS implicados con una sola acción,
independientemente de cuántas instancias haya en el clúster.
Mientras su instancia de base de datos esté detenida, solo se le cobrará el almacenamiento del clúster, las
instantáneas manuales y el almacenamiento de la copia de seguridad automática dentro de su intervalo
de retención especificado. No se le cobrarán las horas de instancia de base de datos. Aurora inicia
automáticamente su clúster de base de datos después de siete días para que no se quede rezagado con
respecto a actualizaciones de mantenimiento necesarias.
Para minimizar los cargos de un clúster de Aurora de carga ligera, puede detener el clúster en lugar de
eliminar todas sus réplicas de Aurora. En el caso de clústeres con más de una o dos instancias, eliminar
y volver a crear las instancias de base de datos con frecuencia solo es práctico si se usa la AWS CLI o la
API de Amazon RDS. Una secuencia de operaciones de ese tipo también puede ser difícil de realizar en
el orden correcto, por ejemplo, eliminar todas las réplicas de Aurora antes de eliminar la instancia principal
para evitar activar el mecanismo de conmutación por error.
No use la opción de iniciar y detener si necesita mantener su clúster de base de datos en ejecución pero
tiene más capacidad de la que necesita. Si su clúster es demasiado costoso o no está muy ocupado,
elimine una o varias de las instancias de base de datos o cambie todas las instancias de base de datos a
clase de instancia pequeña. No puede detener una instancia de base de datos Aurora individual.
Limitaciones para la detención e inicio de clústeres de

base de datos de Aurora
Algunos clústeres de Aurora no se pueden detener e iniciar:
• No puede detener e iniciar un clúster que forma parte de una base de datos global de Aurora (p. 29).
• No puede detener e iniciar un clúster que utiliza la característica de consulta en paralelo de
Aurora (p. 566).
Detención de un clúster de base de datos Aurora

Para usar un clúster de base de datos Aurora o realizar tareas de administración, siempre se empieza con
un clúster de base de datos Aurora en ejecución, a continuación, se detiene el clúster y, después, se inicia
de nuevo. Mientras su clúster esté detenido, se le cobrará el almacenamiento del clúster, las instantáneas
manuales y el almacenamiento de la copia de seguridad automática dentro de su intervalo de retención
especificado, pero no se le cobrarán las horas de instancia de base de datos.
La operación de detención detiene primero las instancias de réplica de Aurora y, a continuación, la

instancia principal, para evitar activar el mecanismo de conmutación por error.

233
Mientras un clúster de base de datos está detenido
No se puede detener un clúster de base de datos que actúa como destino de replicación para datos de
otro clúster de base de datos, o que actúa como el principal de replicación y transmite los datos a otro
clúster.
Consola
Para detener un clúster de Aurora
2. En el panel de navegación, elija Databases (Bases de datos) y, a continuación, elija un clúster. Puede
realizar la operación de detención desde esta página o navegar a la página de detalles del clúster de
base de datos que desea detener.
3. En Actions (Acciones), elija Stop (Detener).
AWS CLI
Para detener una instancia de base de datos con la AWS CLI, llame al comando stop-db-cluster con los
siguientes parámetros:
• --db-cluster-identifier: el nombre del clúster de Aurora.
Example
stop-db-cluster --db-cluster-identifier mydbcluster
API de RDS
Para detener una instancia de base de datos con la API de Amazon RDS, llame a la acción StopDBCluster
con el siguiente parámetro:
• DBClusterIdentifier: el nombre del clúster de Aurora.
Posibles operaciones mientras un clúster de base de

datos Aurora está detenido
Mientras un clúster de Aurora esté detenido, se podrá restaurar a cualquier momento previo que esté
especificado en su intervalo de retención de copias de seguridad. Para obtener información acerca de
cómo hacer una restauración en un momento dado, consulte Restauración de datos (p. 316).
No se puede modificar la configuración de un clúster de base de datos Aurora ni de ninguna de sus

instancias de base de datos mientras el clúster esté detenido. Tampoco puede añadir ni quitar instancias
de base de datos del clúster, ni eliminar el clúster si todavía tiene alguna instancia de base de datos
asociada. Debe iniciar el clúster antes de realizar cualquier tarea administrativa de ese tipo.
Aurora aplica cualquier mantenimiento programado a su clúster detenido después de que se vuelva a
iniciar. Recuerde que después de siete días Aurora inicia automáticamente cualquier clúster detenido para
que no se quede demasiado rezagado en su estado de mantenimiento.
Además, Aurora no realiza copias de seguridad automatizadas porque los datos subyacentes no pueden
cambiar mientras el clúster está detenido. Aurora no amplía el periodo de retención de copia de seguridad
mientras el clúster está detenido.

234
Inicio de un clúster
Inicio de un clúster de base de datos Aurora

Para iniciar un clúster de base de datos Aurora, siempre debe comenzar con un clúster de Aurora que
ya está en estado detenido. Cuando inicia el clúster, todas sus instancias de base de datos se vuelven
disponibles otra vez. El clúster mantiene sus ajustes de configuración como puntos de enlace, grupos de
parámetros y grupos de seguridad de VPC.
Consola
Para iniciar un clúster de Aurora
2. En el panel de navegación, elija Databases (Bases de datos) y, a continuación, elija un clúster. Puede
realizar la operación de inicio desde esta página o navegar a la página de detalles del clúster de base
de datos que desea iniciar.
3. En Actions (Acciones), elija Start (Iniciar).
AWS CLI
Para iniciar un clúster de base de datos con la AWS CLI, llame al comando start-db-instance con los
• --db-cluster-identifier: el nombre del clúster de Aurora. Este nombre es un identificador de

clúster específico que se elige cuando se crea el clúster o el identificador de la instancia de base de
datos que eligió con -cluster añadido al final.
Example
start-db-cluster --db-cluster-identifier mydbcluster
API de RDS
Para iniciar un clúster de base de datos de Aurora con la API de Amazon RDS, llame a la acción
StartDBCluster con el siguiente parámetro:
• DBCluster: el nombre del clúster de Aurora. Este nombre es un identificador de clúster específico que
se elige cuando se crea el clúster o el identificador de la instancia de base de datos que eligió con -
cluster añadido al final.
Modificación de un clúster de base de datos

Amazon Aurora
Puede cambiar la configuración de un clúster de base de datos para completar tareas como el cambio
del periodo de retención de copia de seguridad o el puerto de la base de datos. También puede modificar
instancias de base de datos en un clúster de base de datos para completar tareas como el cambio de la
clase de dicha instancia de base de datos o la activación de información sobre rendimiento para ella. En
este tema se detalla el proceso de modificación de un clúster de base de datos Aurora y sus instancias de
base de datos y se describe la configuración para cada uno de ellos.
Recomendamos que pruebe cualquier cambio en un clúster o una instancia de prueba de una base de
datos antes de modificar un clúster o una instancia de base de datos de producción para que pueda

235
Modificación del clúster de base
de datos con la consola, CLI y API
comprender completamente el impacto de cada cambio. Esto es especialmente importante al actualizar la

versión de la base de datos.
Modificación del clúster de base de datos con la

consola, CLI y API
Puede modificar un clúster de base de datos utilizando la Consola de administración de AWS, la AWS CLI
o la API de RDS.
Note
Para Aurora, al modificar un clúster de base de datos, solo los cambios en los ajustes DB cluster
identifier (Identificador de clúster de base de datos), IAM DB authentication (Autenticación de
base de datos IAM) y New master password (Nueva contraseña maestra) se ven afectados por el
ajuste Apply Immediately (Aplicar inmediatamente). Todas las demás modificaciones se aplican
de inmediato, con independencia del valor del ajuste aplicar inmediatamente.
Consola
Para modificar un clúster de base de datos
2. En el panel de navegación, elija Databases (Bases de datos) y, a continuación, seleccione el clúster
de base de datos que desee modificar.
3. Elija Modify. Aparece la página Modify DB cluster (Modificar clúster de base de datos).
4. Cambie los parámetros que desee. Para obtener más información acerca de cada ajuste, consulte
Configuración para Amazon Aurora (p. 239).
Note
En la Consola de administración de AWS, algunos cambios en el nivel de instancia solo

se aplican a la instancia actual de la base de datos, mientras que otros se aplican a la
totalidad del clúster de base de datos. Para obtener información sobre si una configuración
se aplica a la instancia de base de datos o al clúster de la base de datos, consulte el ámbito
de la configuración en Configuración para Amazon Aurora (p. 239). Para cambiar una
configuración que modifique todo el clúster de base de datos en el nivel de la instancia en la
Consola de administración de AWS, siga las instrucciones de Modificar una instancia de base
de datos en un clúster de base de datos (p. 237).
5. Cuando haya realizado todos los cambios que desee, elija Continue y compruebe el resumen de las
modificaciones.
6. Para aplicar los cambios inmediatamente, seleccione Apply immediately.
7. En la página de confirmación, revise los cambios. Si son correctos, elija Modify cluster (Modificar
clúster) para guardarlos.
O bien, elija Back para editar los cambios o Cancel para cancelarlos.
AWS CLI
Para modificar un clúster de base de datos mediante la AWS CLI, llame al comando modify-db-cluster.
Especifique el identificador de clúster de bases de datos y los valores de la configuración que desea
modificar. Para obtener más información acerca de cada ajuste, consulte Configuración para Amazon
Aurora (p. 239).

236
Modificar una instancia de base de
datos en un clúster de base de datos
Note
Algunos ajustes se aplican únicamente a las instancias de base de datos. Para cambiar dichos
ajustes, siga las instrucciones de Modificar una instancia de base de datos en un clúster de base
de datos (p. 237).
Example
El siguiente comando modifica mydbcluster configurando el periodo de retención de copia de seguridad
en 1 semana (7 días).

--db-cluster-identifier mydbcluster \
--backup-retention-period 7
Para Windows:

--db-cluster-identifier mydbcluster ^
--backup-retention-period 7
API de RDS
Para modificar un clúster de base de datos mediante la API de Amazon RDS, llame a la acción
ModifyDBCluster. Especifique el identificador de clúster de bases de datos y los valores de la configuración
que desea modificar. Para obtener información acerca de cada parámetro, consulte Configuración para
Note
Algunos ajustes se aplican únicamente a las instancias de base de datos. Para cambiar dichos
ajustes, siga las instrucciones de Modificar una instancia de base de datos en un clúster de base
de datos (p. 237).
Modificar una instancia de base de datos en un clúster

de base de datos
Puede modificar una instancia de base de datos en un clúster de base de datos utilizando la Consola de
administración de AWS, la AWS CLI o la API de RDS.
Al modificar una instancia de base de datos, puede aplicar los cambios inmediatamente. Para aplicar
los cambios inmediatamente, seleccione la opción Apply Immediately (Aplicar inmediatamente) en la
Consola de administración de AWS, utilice el parámetro --apply-immediately al llamar a la AWS CLI o
establezca el parámetro ApplyImmediately en true cuando utilice la API de Amazon RDS.
Si decide no aplicar los cambios inmediatamente, estos se colocan en la cola de modificaciones

pendientes. Los cambios pendientes en la cola se aplican durante el siguiente periodo de mantenimiento.
Si opta por aplicar los cambios inmediatamente, se aplican los nuevos cambios y cualquier cambio de la
cola de modificaciones pendientes.
Important
Si alguna de las modificaciones pendientes requiere un tiempo de inactividad, este puede
producirse al aplicarlas inmediatamente para la instancia de base de datos. No hay tiempo de
inactividad para el resto de instancias de base de datos en el clúster de base de datos.

237
Modificar una instancia de base de
datos en un clúster de base de datos
Consola
Para modificar una instancia de base de datos en un clúster de base de datos
2. En el panel de navegación, elija Databases (Bases de datos) y, a continuación, seleccione la instancia
de base de datos que desea modificar.
3. Para Actions (Acciones), elija Modify (Modificar). Aparece la página Modify DB Instance.
4. Cambie los parámetros que desee. Para obtener más información acerca de cada ajuste, consulte
Note
Algunos ajustes se aplican a todo el clúster de la base de datos y deben cambiarse a nivel
del clúster. Para cambiar dichos ajustes, siga las instrucciones de Modificación del clúster de
base de datos con la consola, CLI y API (p. 236).
En la Consola de administración de AWS, algunos cambios en el nivel de instancia solo se
aplican a la instancia actual de la base de datos, mientras que otros se aplican a la totalidad
del clúster de base de datos. Para obtener información sobre si una configuración se aplica
a la instancia de base de datos o al clúster de la base de datos, consulte el ámbito de la
configuración en Configuración para Amazon Aurora (p. 239).
5. Cuando haya realizado todos los cambios que desee, elija Continue y compruebe el resumen de las
modificaciones.
6. Para aplicar los cambios inmediatamente, seleccione Apply immediately.
7. En la página de confirmación, revise los cambios. Si son correctos, elija Modify DB Instance para
guardarlos.
AWS CLI
Para modificar una instancia de base de datos en un clúster de base de datos mediante la AWS CLI, llame
al comando modify-db-instance. Especifique el identificador de instancias de bases de datos y los valores
de la configuración que desea modificar. Para obtener información acerca de cada parámetro, consulte
Note
Algunos ajustes se aplican al clúster de base de datos completo. Para cambiar dichos ajustes,
siga las instrucciones de Modificación del clúster de base de datos con la consola, CLI y
API (p. 236).
Example
El siguiente código modifica mydbinstance al establecer la clase de instancia de base de dato en

db.r4.xlarge. Los cambios se aplican durante el siguiente periodo de mantenimiento si se utiliza
el parámetro --no-apply-immediately. Utilice --apply-immediately para aplicar los cambios
inmediatamente.
aws rds modify-db-instance \

--db-instance-identifier mydbinstance \
--db-instance-class db.r4.xlarge \
--no-apply-immediately

238
Opciones disponibles
Para Windows:
aws rds modify-db-instance ^

--db-instance-identifier mydbinstance ^
--db-instance-class db.r4.xlarge ^
API de RDS
Para modificar una instancia de MySQL mediante la API de Amazon RDS, llame a la acción
ModifyDBInstance. Especifique el identificador de instancias de bases de datos y los valores de la
configuración que desea modificar. Para obtener información acerca de cada parámetro, consulte
Note
Algunos ajustes se aplican al clúster de base de datos completo. Para cambiar dichos ajustes,
siga las instrucciones de Modificación del clúster de base de datos con la consola, CLI y
API (p. 236).
Configuración para Amazon Aurora

La siguiente tabla contiene detalles sobre la configuración que se puede modificar, los métodos para
modificar la configuración y el ámbito de la configuración. El ámbito determina si la configuración se aplica
al clúster de base de datos completo o si puede establecerse solamente para instancias de base de datos
específicas.
Configuración y Método Ámbito Notas acerca del tiempo

descripción de inactividad
Auto minor version Uso de la Consola de El clúster de base de –

upgrade (Actualización administración de AWS, datos completo
automática de versiones Modificar una instancia
secundarias) de base de datos en
un clúster de base de
Si desea permitir datos (p. 237).
que la instancia de
base de datos reciba Con la AWS CLI,
automáticamente ejecute modify-db-
las actualizaciones instance y establezca
preferidas de la versión la opción --auto-
secundaria del motor de minor-version-
base de datos cuando upgrade|--no-auto-
estén disponibles. Las minor-version-
actualizaciones se upgrade.
instalan únicamente
durante la ventana Mediante la API
de mantenimiento de RDS, realice
programada. una llamada a
ModifyDBInstance y
El ajuste Auto minor establezca el parámetro
version upgrade AutoMinorVersionUpgrade.
(Actualización
automática a versiones
secundarias) solo se
aplica a los clústeres de

239

base de datos Aurora
PostgreSQL.
Para obtener más

información acerca
de las actualizaciones
de motor de Aurora
PostgreSQL, consulte
Actualizaciones del
motor de base de datos
para Amazon Aurora
Para obtener más

información acerca
de las actualizaciones
de motor de Aurora
MySQL, consulte
Actualizaciones del
motor de base de datos
para Amazon Aurora
MySQL (p. 695).
Backup retention period Uso de la Consola El clúster de base de –

(Periodo de retención de de administración de datos completo
copia de seguridad) AWS, Modificación del
clúster de base de datos
El número de días con la consola, CLI y
que se conservan las API (p. 236).
copias de seguridad
automáticas. El valor Con la AWS CLI,
mínimo es 1. ejecute modify-db-
cluster y establezca
Para obtener la opción --backup-
más información, retention-period.
consulte Copias de
seguridad (p. 315). Mediante la API
de RDS, realice
una llamada a
ModifyDBCluster y
establezca el parámetro
BackupRetentionPeriod.

240

Certificate Authority Uso de la Consola de Solo la instancia –

(Entidad de administración de AWS, de base de datos
certificación) Modificar una instancia especificada
de base de datos en
El certificado que desea un clúster de base de
utilizar. datos (p. 237).
Con la AWS CLI,

ejecute modify-
db-instance y
establezca la opción
--ca-certificate-
identifier.
Mediante la API
de RDS, realice
una llamada a
ModifyDBInstance y
CACertificateIdentifier.
Copy Tags To Uso de la Consola El clúster de base de –

Snapshots (Copiar de administración de datos completo
etiquetas en AWS, Modificación del
instantáneas) clúster de base de datos
con la consola, CLI y
Selecciónelo para API (p. 236).
especificar qué
etiquetas definidas para Con la AWS CLI,
este clúster de base de ejecute modify-db-
datos se copian en las cluster y establezca
instantáneas de base la opción --copy-
de datos creadas desde tags-to-snapshot o
este clúster de base --no-copy-tags-to-
de datos. Para obtener snapshot.
más información,
consulte Etiquetado de Mediante la API
recursos de Amazon de RDS, realice
RDS (p. 349). una llamada a
ModifyDBCluster y
CopyTagsToSnapshot.

241

Data API (API de datos) Uso de la Consola El clúster de base de –

de administración de datos completo
Puede acceder a AWS, Modificación del
Aurora Serverless clúster de base de datos
con aplicaciones web con la consola, CLI y
basadas en servicios, API (p. 236).
incluidas AWS Lambda
y AWS AppSync. Este Con la AWS CLI,
ajuste solo se aplica ejecute modify-db-
a un clúster de base cluster y establezca
de datos de Aurora la opción --enable-
Serverless. http-endpoint.
Para obtener más Mediante la API

información, consulte de RDS, realice
Uso de la API de una llamada a
datos para Aurora ModifyDBCluster y
Serverless (p. 125). establezca el parámetro
EnableHttpEndpoint.
Database port (Puerto Uso de la Consola El clúster de base de Se produce una

de base de datos) de administración de datos completo interrupción durante
AWS, Modificación del este cambio. Todas
El puerto que desea clúster de base de datos las instancias de
utilizar para obtener con la consola, CLI y base de datos en el
acceso al clúster de API (p. 236). clúster de base de
base de datos. datos se reinician
Con la AWS CLI, inmediatamente.
ejecute modify-db-
la opción --port.
Mediante la API
de RDS, realice
una llamada a
ModifyDBCluster y
Port.

242

DB cluster identifier Uso de la Consola El clúster de base de –

Identificador de clúster AWS, Modificación del
de base de datos. Este clúster de base de datos
valor se almacena con la consola, CLI y
como una cadena en API (p. 236).
minúsculas.
Con la AWS CLI,
Cuando cambia el ejecute modify-
identificador del clúster db-cluster y
de base de datos, el establezca la opción
punto de enlace del --new-db-cluster-
clúster de base de datos identifier.
cambia y los puntos de
enlace de las instancias Mediante la API
de base de datos en el de RDS, realice
clúster de base de datos una llamada a
cambian. ModifyDBCluster y
NewDBClusterIdentifier.
DB cluster parameter Uso de la Consola El clúster de base de No se produce una

group (Grupo de de administración de datos completo interrupción durante
parámetros de clúster AWS, Modificación del este cambio. Cuando
de base de datos) clúster de base de datos cambia el grupo
con la consola, CLI y de parámetros, los
El grupo de parámetros API (p. 236). cambios en algunos
de clúster de base de parámetros se aplican
datos que desea asociar Con la AWS CLI, a las instancias de
al clúster de base de ejecute modify-db- bases de datos en el
datos. cluster y establezca clúster de base de datos
la opción --db- inmediatamente, sin
Para obtener más cluster-parameter- reinicio. Los cambios
información, consulte group-name. en otros parámetros
Trabajo con los grupos se aplican únicamente
de parámetros de base Mediante la API después de reiniciar las
de datos y grupos de RDS, realice instancias de bases de
de parámetros de una llamada a datos en el clúster de
clúster de base de ModifyDBCluster y base de datos.
datos (p. 259). establezca el parámetro
DBClusterParameterGroupName.

243

DB engine version Uso de la Consola El clúster de base de Se produce una

(Versión del motor de de administración de datos completo interrupción durante
base de datos) AWS, Modificación del este cambio.
La versión del motor con la consola, CLI y
de base de datos API (p. 236).
que desea utilizar.
Antes de actualizar Con la AWS CLI,
el clúster de base de ejecute modify-db-
datos de producción, cluster y establezca
recomendamos que la opción --engine-
pruebe el proceso de version.
actualización en un
clúster de base de datos Mediante la API
prueba para comprobar de RDS, realice
la duración y validar las una llamada a
aplicaciones. ModifyDBCluster y
Actualmente, solo EngineVersion.
puede utilizar esta
configuración para la
actualización local de la
versión secundaria del
motor de un clúster de
base de datos Aurora
PostgreSQL.
DB instance class Uso de la Consola de Solo la instancia Se produce una

(Clase de instancia de administración de AWS, de base de datos interrupción durante
base de datos) Modificar una instancia especificada este cambio.
de base de datos en
Clase de instancia de un clúster de base de
base de datos que datos (p. 237).
desea utilizar.
Con la AWS CLI,
Para obtener más ejecute modify-db-
información, consulte instance y establezca
Selección de la clase la opción --db-
de instancia de base de instance-class.
datos (p. 61).
Mediante la API
de RDS, realice
una llamada a
ModifyDBInstance y
DBInstanceClass.

244

DB instance identifier Uso de la Consola de Solo la instancia Se produce una

(Identificador de administración de AWS, de base de datos interrupción durante
instancias de bases de Modificar una instancia especificada este cambio. La
datos) de base de datos en instancia de base de
un clúster de base de datos se reinicia.
El identificador de datos (p. 237).
instancias de bases
de datos. Este valor se Con la AWS CLI,
almacena como una ejecute modify-
cadena en minúsculas. db-instance y
establezca la opción --
new-db-instance-
identifier.
Mediante la API
de RDS, realice
una llamada a
ModifyDBInstance y
NewDBInstanceIdentifier.
DB Parameter Group Uso de la Consola de Solo la instancia No se produce una

(Grupo de parámetros administración de AWS, de base de datos interrupción durante
de base de datos) Modificar una instancia especificada este cambio. Cuando
de base de datos en cambia el grupo de
El grupo de parámetros un clúster de base de parámetros, los cambios
de la base de datos datos (p. 237). en algunos parámetros
que desea asociar a la se aplican a las
instancia de base de Con la AWS CLI, instancias de bases de
datos. ejecute modify-db- datos inmediatamente,
instance y establezca sin reinicio. Los cambios
Para obtener más la opción --db- en otros parámetros
información, consulte parameter-group- se aplican únicamente
Trabajo con los grupos name. después de reiniciar la
de parámetros de base instancia de base de
de datos y grupos Mediante la API datos.
de parámetros de de RDS, realice
clúster de base de una llamada a
datos (p. 259). ModifyDBInstance y
DBParameterGroupName.

245

Deletion protection Uso de la Consola El clúster de base de –

(Protección contra de administración de datos completo
eliminación) AWS, Modificación del
Seleccione Enable con la consola, CLI y
deletion protection API (p. 236).
(Habilitar la protección
contra la eliminación) Con la AWS CLI,
para evitar que se ejecute modify-db-
elimine el clúster cluster y establezca
de base de datos. la opción --deletion-
Para obtener más protection|--
información, consulte no-deletion-
Eliminación de una protection.
instancia de base de
datos en un clúster Mediante la API
de base de datos de de RDS, realice
Aurora (p. 348). una llamada a
ModifyDBCluster y
DeletionProtection.
Enhanced monitoring Uso de la Consola de Solo la instancia –

(Monitorización administración de AWS, de base de datos
mejorada) Modificar una instancia especificada
de base de datos en
Enable enhanced un clúster de base de
monitoring para habilitar datos (p. 237).
la recopilación de
métricas en tiempo Con la AWS CLI,
real para el sistema ejecute modify-
operativo en el que se db-instance y
ejecuta la instancia de establezca las opciones
base de datos. --monitoring-role-
arn y --monitoring-
Para obtener más interval.
información, consulte
Monitorización Mediante la API
mejorada (p. 395). de RDS, realice
una llamada a
ModifyDBInstance
y establezca
los parámetros
MonitoringRoleArn y
MonitoringInterval.

246

IAM DB authentication Uso de la Consola El clúster de base de –

(Autenticación de base de administración de datos completo
de datos de IAM) AWS, Modificación del
Seleccione Enable con la consola, CLI y
IAM DB authentication API (p. 236).
(Habilitar autenticación
de base de datos Con la AWS CLI,
IAM) para habilitar ejecute modify-db-
la autenticación de cluster y establezca
base de datos IAM la opción --enable-
para este clúster de iam-database-
base de datos. Esta authentication|--
configuración solo está no-enable-
disponible para Aurora iam-database-
MySQL authentication.
Para obtener más Mediante la API

información, consulte de RDS, realice
Autenticación de una llamada a
bases de datos de ModifyDBCluster y
IAM (p. 180). establezca el parámetro
EnableIAMDatabaseAuthentication.
Log exports Uso de la Consola El clúster de base de –

(Exportaciones de de administración de datos completo
registros) AWS, Modificación del
Seleccione los tipos con la consola, CLI y
de registro que desee API (p. 236).
publicar en Amazon
CloudWatch Logs Con la AWS CLI,
ejecute modify-
Para obtener más db-cluster y
información, consulte establezca la opción
Archivos de registro --cloudwatch-
de base de datos de logs-export-
MySQL (p. 485). configuration.
Mediante la API
de RDS, realice
una llamada a
ModifyDBCluster y
CloudwatchLogsExportConfiguration.

247

Maintenance Para cambiar el periodo El clúster de base de Si hay una o varias

window (Periodo de de mantenimiento del datos completo o una acciones pendientes
mantenimiento) clúster de la base de instancia de base de que provocan una
datos con la Consola datos individual interrupción y el periodo
El intervalo de de administración de de mantenimiento se
tiempo durante el AWS, Modificación del cambia para incluir
que se produce clúster de base de datos la hora actual, las
el mantenimiento con la consola, CLI y acciones pendientes se
del sistema. El API (p. 236). aplican inmediatamente,
mantenimiento del y se produce una
sistema incluye Para cambiar el periodo interrupción.
actualizaciones, si de mantenimiento de
procede. El periodo la instancia de base de
de mantenimiento se datos con la Consola de
expresa mediante una administración de AWS,
hora de inicio en tiempo Modificar una instancia
universal coordinado de base de datos en
(UTC) y una duración en un clúster de base de
horas. datos (p. 237).
Si establece un intervalo Para cambiar el periodo

que incluya la hora de mantenimiento del
actual, debe haber clúster de base de datos
al menos 30 minutos con la AWS CLI, ejecute
entre la hora actual y el modify-db-cluster
final del intervalo, para y establezca la opción
asegurarse de que se --preferred-
apliquen los cambios maintenance-
pendientes. window.
Puede establecer Para cambiar el periodo

el periodo de de mantenimiento
mantenimiento de de una instancia de
manera independiente base de datos con
para el clúster de base la AWS CLI, ejecute
de datos y para cada modify-db-instance
instancia de base de y establezca la opción
datos en el clúster --preferred-
de base de datos. maintenance-
Cuando el ámbito de window.
una modificación es
el clúster de base de Para cambiar el periodo
datos completo, la de mantenimiento del
modificación se realiza clúster de base de datos
durante el periodo de con la API de RDS,
mantenimiento del realice una llamada a
clúster de base de ModifyDBCluster y
datos. Cuando el ámbito establezca el parámetro
de una modificación PreferredMaintenanceWindow.
es una instancia
de base de datos, Para cambiar el periodo
modificación se realiza de mantenimiento
durante el periodo de de una instancia
mantenimiento de esa de base de datos
con la API de RDS,

248

instancia de base de realice una llamada a
datos. ModifyDBInstance y
Para obtener más PreferredMaintenanceWindow.
La ventana de
mantenimiento de
Amazon RDS (p. 344).
New master password Uso de la Consola El clúster de base de –

La contraseña para AWS, Modificación del
el usuario maestro. clúster de base de datos
La contraseña debe con la consola, CLI y
contener entre API (p. 236).
8 y 41 caracteres
alfanuméricos. Con la AWS CLI,
ejecute modify-db-
la opción --master-
user-password.
Mediante la API
de RDS, realice
una llamada a
ModifyDBCluster y
MasterUserPassword.
Performance Insights Uso de la Consola de Solo la instancia –

administración de AWS, de base de datos
Si se habilita Modificar una instancia especificada
Performance Insights, de base de datos en
una herramienta que un clúster de base de
monitoriza la carga datos (p. 237).
de las instancias de
base de datos para Con la AWS CLI,
que pueda y solucionar ejecute modify-db-
los problemas de instance y establezca
rendimiento de la base la opción --enable-
de datos. performance-
insights|--
Para obtener más no-enable-
información, consulte performance-
Uso de Performance insights.
Insights de Amazon
RDS (p. 402). Mediante la API
de RDS, realice
una llamada a
ModifyDBInstance y
EnablePerformanceInsights.

249


AWS KMS key identifier administración de AWS, de base de datos
(Identificador de la Modificar una instancia especificada
clave de AWS KMS de base de datos en
de información sobre un clúster de base de
rendimiento) datos (p. 237).
El identificador de la Con la AWS CLI,

clave de AWS KMS ejecute modify-
para el cifrado de datos db-instance y
de Performance Insights establezca la opción
El ID de la clave de --performance-
KMS es el Nombre de insights-kms-key-
recurso de Amazon id.
(ARN), el identificador
de la clave de KMS o el Mediante la API
alias de la clave de KMS de RDS, realice
de la clave de cifrado de una llamada a
KMS. ModifyDBInstance y
Para obtener PerformanceInsightsKMSKeyId.
más información,
consulte Activación
de Performance
Insights (p. 404).

retention period administración de AWS, de base de datos
(Periodo de retención Modificar una instancia especificada
de información sobre de base de datos en
rendimiento) un clúster de base de
datos (p. 237).
El tiempo, en días,
durante los que se Con la AWS CLI,
conservan los datos ejecute modify-
de información sobre db-instance y
rendimiento. Los valores establezca la opción
válidos son 7 o 731 (2 --performance-
años). insights-
retention-period.
Para obtener
más información, Mediante la API
consulte Activación de RDS, realice
de Performance una llamada a
Insights (p. 404). ModifyDBInstance y
PerformanceInsightsRetentionPeriod.

250

Promotion tier (Capa de Uso de la Consola de Solo la instancia –

promoción) administración de AWS, de base de datos
Modificar una instancia especificada
Un valor que especifica de base de datos en
el orden en que se un clúster de base de
promueven las réplicas datos (p. 237).
de Aurora a instancia
principal tras un error Con la AWS CLI,
de la instancia principal ejecute modify-
existente. db-instance y
establezca la opción --
Para obtener más promotion-tier.
Tolerancia a errores Mediante la API
para un clúster de de RDS, realice
base de datos de una llamada a
Aurora (p. 314). ModifyDBInstance y
PromotionTier.
Public accessibility Uso de la Consola de Solo la instancia –

(Acceso público) administración de AWS, de base de datos
Modificar una instancia especificada
Si desea dar una de base de datos en
dirección IP pública a un clúster de base de
la instancia de base de datos (p. 237).
datos, lo que significa
que es accesible desde Con la AWS CLI,
fuera de la VPC. Para ejecute modify-db-
que sea accesible instance y establezca
públicamente, la la opción --publicly-
instancia de base de accessible|--
datos también debe no-publicly-
estar en una subred accessible.
pública de la VPC. Si
no es posible acceder Mediante la API
públicamente a la de RDS, realice
instancia de base de una llamada a
datos, solo es posible ModifyDBInstance y
acceder desde dentro establezca el parámetro
de la VPC. PubliclyAccessible.
Para obtener más

Cómo ocultar una
instancia de base de
datos en una VPC
desde Internet. (p. 223).

251

Scaling configuration Uso de la Consola El clúster de base de –

(Escalado de de administración de datos completo
configuración) AWS, Modificación del
Las propiedades de con la consola, CLI y
escalado del clúster API (p. 236).
de base de datos. Solo
es posible modificar Con la AWS CLI,
las propiedades de ejecute modify-db-
escalado para clústeres cluster y establezca
de base de datos en el la opción --scaling-
modo del motor de base configuration.
de datos serverless.
Esta configuración solo Mediante la API
está disponible para de RDS, realice
Aurora MySQL. una llamada a
ModifyDBCluster y
Para obtener establezca el parámetro
información acerca ScalingConfiguration.
de Aurora Serverless,
consulte Uso de
Amazon Aurora
Security group (Grupo Uso de la Consola El clúster de base de –

de seguridad) de administración de datos completo
AWS, Modificación del
El grupo de seguridad clúster de base de datos
que desea asociar con la consola, CLI y
al clúster de base de API (p. 236).
datos.
Con la AWS CLI,
Para obtener más ejecute modify-db-
información, consulte cluster y establezca
Control de acceso la opción --vpc-
con grupos de security-group-
seguridad (p. 204). ids.
Mediante la API
de RDS, realice
una llamada a
ModifyDBCluster y
VpcSecurityGroupIds.

252
Configuración no aplicable

Target Backtrack Uso de la Consola El clúster de base de –

window (Periodo de de administración de datos completo
Backtrack de destino) AWS, Modificación del
La cantidad de tiempo con la consola, CLI y
que desea poder API (p. 236).
realizar búsqueda de
datos anteriores en Con la AWS CLI,
su clúster de base de ejecute modify-
datos, en segundos. db-cluster y
Esta configuración está establezca la opción --
disponible solo para backtrack-window.
Aurora MySQL y solo
si el clúster de base Mediante la API
de datos se creó con de RDS, realice
Backtrack habilitado. una llamada a
ModifyDBCluster y
BacktrackWindow.
Opciones que no se aplican a Amazon Aurora

Las opciones siguientes del comando modify-db-instance de la AWS CLI y de la acción
ModifyDBInstance de la API de RDS no se aplican a Amazon Aurora.
Note
La Consola de administración de AWS no le permite modificar esta configuración para Aurora.
Configuración de la AWS CLI Configuración de la API de RDS
--allocated-storage AllocatedStorage
--allow-major-version-upgrade|--no- AllowMajorVersionUpgrade
allow-major-version-upgrade
--copy-tags-to-snapshot|--no-copy- CopyTagsToSnapshot
tags-to-snapshot
--domain Domain
--db-security-groups DBSecurityGroups
--db-subnet-group-name DBSubnetGroupName
--domain-iam-role-name DomainIAMRoleName
--multi-az|--no-multi-az MultiAZ
--iops Iops
--license-model LicenseModel
--option-group-name OptionGroupName

253
Adición de réplicas de Aurora
Configuración de la AWS CLI Configuración de la API de RDS
--preferred-backup-window PreferredBackupWindow
--processor-features ProcessorFeatures
--storage-type StorageType
--tde-credential-arn TdeCredentialArn
--tde-credential-password TdeCredentialPassword
--use-default-processor-features|--no- UseDefaultProcessorFeatures
use-default-processor-features
Note
Si bien puede configurarse el periodo de realización de copia de seguridad preferido para Aurora,
se hace caso omiso a la configuración. Las copias de seguridad de Aurora son continuas e
incrementales.
Adición de réplicas de Aurora a un clúster de base

de datos
En un clúster de base de datos de Aurora, hay una instancia de base de datos principal y hasta 15 réplicas
de Aurora. La instancia principal de base de datos admite operaciones de lectura y escritura y realiza todas
las modificaciones de los datos en el volumen del clúster. Las réplicas de Aurora se conectan con el mismo
volumen de almacenamiento que la instancia de base de datos principal y solo admiten operaciones de
lectura. Las réplicas de Aurora pueden descargar las cargas de trabajo de lectura desde la instancia de
base de datos principal.
Es recomendable que distribuya la instancia principal y las réplicas de Aurora del clúster de base de datos
entre varias zonas de disponibilidad para mejorar la disponibilidad del clúster de base de datos. Para
obtener más información, consulte Disponibilidad (p. 65).
Puede añadir réplicas de Aurora a un clúster de base de datos utilizando la Consola de administración de
Para eliminar una réplica de Aurora de un clúster de base de datos, elimine la instancia de base de datos
la réplica de Aurora siguiendo las instrucciones de Eliminación de una instancia de base de datos en un
Para obtener más información acerca de las réplicas de Aurora, consulte Réplicas de Aurora (p. 48).
Note
Amazon Aurora también admite la replicación con una base de datos de externa o una instancia
de base de datos de RDS Cuando se usa Amazon Aurora, la instancia de base de datos de RDS
debe estar en la misma región. Para obtener más información, consulte Replicación con Amazon
Aurora (p. 48).
Consola
Para añadir una réplica de Aurora a un clúster de base de datos

254
2. En el panel de navegación, elija Databases (Bases de datos) y, a continuación, seleccione el clúster

de base de datos en el que desee añadir a la nueva instancia de base de datos.
3. En Actions (Acciones), elija Add reader (Añadir lector).
Aparecerá la página Add reader (Añadir lector).

4. En la página Add reader (Añadir lector), especifique las opciones para su réplica de Aurora. La
siguiente tabla muestra la configuración de una réplica de Aurora.

concreta. La lista incluye únicamente las zonas de
disponibilidad asignadas por el grupo de subredes de base
de datos que especificó previamente. Para obtener más
información acerca de las zonas de disponibilidad, consulte
Elección de Regiones y zonas de disponibilidad (p. 64).
Publicly accessible (Accesible Seleccione Yes para asignar a la réplica de Aurora una
públicamente) dirección IP pública; de lo contrario, seleccione No. Para
obtener más información acerca del modo de ocultar
réplicas de Aurora del acceso público, consulte Cómo
Internet. (p. 223).
Cifrado Seleccione Enable encryption para habilitar el cifrado

en reposo para esta réplica de Aurora. Para obtener más
información, consulte Cifrado de recursos de Amazon
Aurora (p. 158).
DB instance class (Clase de instancia Seleccione una clase de instancia de base de datos que
de base de datos) defina los requisitos de procesamiento y memoria de la
réplica de Aurora. Para obtener más información acerca
de las opciones de clases de instancia de base de datos,
consulte Selección de la clase de instancia de base de
datos (p. 61).
Aurora replica source (Origen de la Seleccione el identificador de la instancia principal para la

réplica de Aurora) que se debe crear una réplica de Aurora.
DB Instance Identifier (Identificador de Escriba un nombre para la instancia que sea único para su
instancias de bases de datos)s cuenta en la región de AWS que ha seleccionado. Puede
optar por agregar al nombre información como la región de
AWS y el motor de base de datos que ha seleccionado, por
ejemplo, aurora-read-instance1.

Aurora (p. 314).
Database port (Puerto de base de El puerto de una réplica de Aurora coincide con el puerto
datos) del clúster de base de datos.

255

Enhanced monitoring (Monitorización Elija Enable enhanced monitoring (Habilitar monitorización


mejorada (p. 395).

Auto minor version upgrade Seleccione Enable auto minor version upgrade (Habilitar
(Actualización automática a versiones actualización automática a versiones secundarias) si desea
secundarias) habilitar su clúster de base de datos de Aurora para recibir
actualizaciones de las versiones secundarias del motor de
base de datos automáticamente cuando estén disponibles.
El ajuste Auto minor version upgrade (Actualización

automática a versiones secundarias) solo se aplica a los
clústeres de base de datos Aurora PostgreSQL.

actualizaciones de motor de Aurora PostgreSQL, consulte
Aurora PostgreSQL (p. 856).

5. Elija Add reader (Añadir lector) para crear la réplica de Aurora.
AWS CLI
Para crear una réplica de Aurora en un clúster de base de datos, ejecute el comando create-db-instance
de la AWS CLI. Incluya el nombre del clúster de base de datos como opción de --db-cluster-

256
Gestión del desempeño y el escalado
identifier. Si lo desea, puede especificar una zona de disponibilidad para la réplica de Aurora usando
el parámetro --availability-zone, como se muestra en los siguientes ejemplos.
Por ejemplo, el comando siguiente crea una nueva réplica de Aurora compatible con MySQL 5.7 llamada
sample-instance-us-west-2a.
aws rds create-db-instance --db-instance-identifier sample-instance-us-west-2a \

db.r4.large \
--availability-zone us-west-2a
Para Windows:
aws rds create-db-instance --db-instance-identifier sample-instance-us-west-2a ^

db.r4.large ^
El comando siguiente crea una nueva réplica de Aurora compatible con MySQL 5.6 llamada sample-
instance-us-west-2a.
aws rds create-db-instance --db-instance-identifier sample-instance-us-west-2a \

--db-cluster-identifier sample-cluster --engine aurora --db-instance-class db.r4.large
\
Para Windows:
aws rds create-db-instance --db-instance-identifier sample-instance-us-west-2a ^

--db-cluster-identifier sample-cluster --engine aurora --db-instance-class db.r4.large
^
API de RDS
Para crear una réplica de Aurora en un clúster de base de datos, realice una llamada a la
acción CreateDBInstance. Incluya el nombre del clúster de base de datos como parámetro
DBClusterIdentifier. Opcionalmente, puede especificar una zona de disponibilidad para la réplica de
Aurora con el parámetro AvailabilityZone.
Administración del desempeño y el escalado para

clústeres de base de datos Aurora
Puede utilizar las siguientes opciones para administrar el desempeño y el escalado de clústeres e
instancias de bases de datos Aurora:
Temas
• Escalado del almacenamiento (p. 258)

257
Escalado del almacenamiento
• Escalado de instancia (p. 258)

• Escalado de lectura (p. 258)
• Administración de conexiones (p. 259)
• Administración de planes de ejecución de consultas (p. 259)
Escalado del almacenamiento

El almacenamiento de Aurora se escala automáticamente con los datos del volumen de clúster. A medida
que crecen los datos, el almacenamiento del volumen de clúster aumenta en incrementos de 10 gibibyte
(GiB) hasta un máximo de 64 TiB.
El tamaño del volumen de clúster se comprueba cada hora para determinar los costos de almacenamiento.
Para obtener información sobre los precios, consulte la página de precios de Aurora.
Cuando se eliminan datos de Aurora, como por ejemplo al suprimir una tabla o partición, el espacio
asignado general sigue siendo el mismo. El espacio libre se reutiliza automáticamente cuando el volumen
de datos aumenta en el futuro.
Note
Dado que los costos de almacenamiento se basan en el "nivel máximo de crecimiento" (la
cantidad máxima que se asignó para el clúster de Aurora en cualquier momento), puede
administrar costos evitando prácticas de ETL que crean grandes volúmenes de información
temporal o que cargan grandes volúmenes de datos nuevos antes de eliminar datos más antiguos
que ya no se necesitan.
Si la eliminación de datos de un clúster de Aurora produce una cantidad sustancial de espacio asignado
pero que no se utiliza, el restablecimiento del nivel máximo de crecimiento exige realizar el volcado de
datos lógicos y restablecerlo a un clúster nuevo, con una herramienta como mysqldump. La creación y
restauración de una instantánea no reduce el almacenamiento asignado debido a que la distribución física
del almacenamiento subyacente no se verá modificada en la instantánea restaurada.
Escalado de instancia
Puede escalar el clúster de base de datos Aurora como considere necesario modificando la clase
de instancia de base de datos para cada instancia de base de datos del clúster de base de datos.
Aurora admite varias clases de instancia de base de datos optimizadas para Aurora en función de la
compatibilidad del motor de base de datos.
Motor de base de datos Escalado de instancia
Amazon Aurora MySQL Consulte Escalado de las instancias de base de datos Aurora
MySQL (p. 544)
Amazon Aurora PostgreSQL Consulte Escalado de las instancias de base de datos Aurora
PostgreSQL (p. 795)
Escalado de lectura
Puede realizar el escalado de lectura de su clúster de base de datos Aurora creando un máximo de 15
réplicas de Aurora en el clúster de base de datos. Cada réplica de Aurora devuelve los mismos datos
desde el volumen de clúster con un retardo de réplica mínimo, normalmente mucho menos de 100

258
Administración de conexiones
milisegundos una vez que la instancia principal ha escrito una actualización. A medida que el tráfico de
lectura aumenta, puede crear réplicas de Aurora adicionales y conectarlas directamente para distribuir la
carga de lectura del clúster de base de datos. Las réplicas de Aurora no tienen que ser de la misma clase
de instancia de base de datos que la instancia principal.
Para obtener más información acerca de la adición de réplicas de Aurora a un clúster de base de datos,
consulte Adición de réplicas de Aurora a un clúster de base de datos (p. 254).
Administración de conexiones
El número máximo de conexiones permitidas a una instancia de base de datos Aurora viene determinado
por el parámetro max_connections del grupo de parámetros de nivel de instancia para la instancia de
base de datos. El valor predeterminado de dicho parámetro varía en función de la clase de instancia de
base de datos utilizada para la instancia de base de datos y la compatibilidad del motor de base de datos.
Motor de base de datos Valor predeterminado de max_connections
Amazon Aurora MySQL Consulte Número máximo de conexiones a una instancia de base de
datos Aurora MySQL (p. 545)
Amazon Aurora PostgreSQL Consulte Número máximo de conexiones a una instancia de base de
datos Aurora PostgreSQL (p. 795)
Administración de planes de ejecución de consultas

La administración de un plan de consultas para Aurora PostgreSQL le otorga el control sobre qué planes
ejecutará el optimizador. Para obtener más información, consulte Administración de planes de ejecución de
consultas para Aurora PostgreSQL (p. 802).
Trabajo con los grupos de parámetros de base de

datos y grupos de parámetros de clúster de base de
datos
Administre su configuración del motor de la base de datos mediante la asociación de sus instancias
de base de datos y clústeres de Aurora con grupos de parámetros. Amazon RDS define los grupos de
parámetros con una configuración predeterminada que se aplica a instancias de base de datos recién
creadas y clústeres de Aurora. Puede definir sus propios grupos de parámetros con una configuración
personalizada. A continuación, puede modificar las instancias de bases de datos y clústeres de Aurora
para utilizar sus propios grupos de parámetros.
Un grupo de parámetros de base de datos sirve de contenedor para los valores de configuración del motor
que se aplican a una o varias instancias de bases de datos. Los grupos de parámetros de base de datos
de se aplican a instancias de base de datos en Amazon RDS y Aurora. Estos ajustes de configuración
se aplican a propiedades que pueden variar entre las instancias de base de datos dentro de un clúster de
Aurora, como los tamaños de los búferes de memoria.
Un grupo de parámetros del clúster de base de datos funciona como un contenedor para los valores
de configuración del motor que se aplican a cada instancia de base de datos en un clúster de base de
datos de Aurora. Por ejemplo, el modelo de almacenamiento compartido de Aurora requiere que cada
instancia de base de datos en un clúster de Aurora utilice la misma configuración para parámetros, como

259
Trabajo con los grupos de parámetros
innodb_file_per_table. Por lo tanto, los parámetros que afectan al diseño de almacenamiento físico
forman parte del grupo de parámetros del clúster. Los grupos de parámetros de clúster de base de datos
también incluyen valores predeterminados para todos los parámetros de nivel de instancia.
Si crea una instancia de base de datos sin especificar un grupo de parámetros de bases de datos, la
instancia de base de datos utilizará un grupo de parámetros de base de datos predeterminado. Del mismo
modo, si crea un clúster de base de datos de Aurora sin especificar un grupo de parámetros del clúster
de base de datos, el clúster de base de datos utiliza un grupo de parámetros del clúster de base de datos
predeterminado. Cada grupo de parámetros de predeterminado contiene los valores predeterminados
del motor de base de datos y los valores predeterminados del sistema Amazon RDS correspondientes
al motor, la clase de computación y el almacenamiento asignado de la instancia. La configuración de los
parámetros de un grupo de parámetros predeterminado no se puede modificar. En su lugar, cree su propio
grupo de parámetros en el que elija sus propios ajustes de parámetros. No todos los parámetros del motor
de base de datos pueden cambiarse en el grupo de parámetros que cree.
Si desea utilizar su propio grupo de parámetros, cree un nuevo grupo de parámetros y modifique los
parámetros que desee. A continuación, modifique su instancia de base de datos o el clúster de base de
datos para utilizar el nuevo grupo de parámetros. Si actualiza los parámetros en un grupo de parámetros
de base de datos, los cambios se aplican a todas las instancias de base de datos que se asocian a ese
grupo de parámetros. De la misma forma, si actualiza los parámetros en un grupo de parámetros del
clúster de base de datos, los cambios se aplican a todos los clústeres de Aurora que se asocian a ese
grupo de parámetros del clúster de base de datos.
Es posible copiar un grupo de parámetros de base de datos existente con el comando copy-db-parameter-
group de la AWS CLI. Es posible copiar un grupo de parámetros de clúster de base de datos existente
con el comando copy-db-cluster-parameter-group de la AWS CLI. Copiar un grupo de parámetros puede
resultar práctico cuando desee incluir la mayoría de valores y parámetros personalizados de un grupo de
parámetros de en un nuevo grupo de parámetros de .
Estos son algunos puntos importantes para utilizar los parámetros de un grupo de parámetros de :
• Cuando se modifica un parámetro dinámico y se guarda el grupo de parámetros , el cambio se aplica

inmediatamente independientemente del estado de Apply Immediately (Aplicar inmediatamente). Cuando
se cambia un parámetro estático y se guarda el grupo de parámetros de base de datos, el cambio
de parámetros se aplicará después de reiniciar manualmente la instancia de base de datos. Puede
reiniciar una instancia de base de datos utilizando la consola de RDS o invocando explícitamente la
acción RebootDbInstance de la API (sin conmutación por error, si la instancia de base de datos
está en una implementación Multi-AZ). El requisito de reiniciar la instancia de base de datos asociada
después de cambiar los parámetros estáticos ayuda a mitigar el riesgo de que una configuración errónea
de parámetros afecte a una llamada a la API como, por ejemplo, llamar a ModifyDBInstance para
cambiar la clase de instancia de base de datos o escalar el almacenamiento.
Por ejemplo, si la instancia de base de datos no está utilizando los cambios más recientes del grupo
de parámetros de base de datos asociado, la Consola de administración de AWS muestra el grupo de
parámetros de base de datos con el estado pending-reboot. El estado de los grupos de parámetros
pending-reboot no genera un reinicio automático durante la siguiente ventana de mantenimiento.
Para aplicar los cambios de parámetros más recientes en esa instancia de base de datos, reinicie
manualmente la instancia de base de datos.
• Cuando se cambia el grupo de parámetros de base de datos asociado a una instancia de base de datos,
se debe reiniciar manualmente la instancia para que esta utilice el nuevo grupo de parámetros de base
de datos.
• Puede especificar el valor de un parámetro de como una expresión entera construida a partir de
fórmulas, variables, funciones y operadores. Las funciones pueden incluir una expresión logarítmica
matemática. Para obtener más información, consulte Valores de los parámetros de base de
datos (p. 279).
• Establezca los parámetros relacionados con la intercalación o el conjunto de caracteres de la base de
datos en el grupo de parámetros antes de crear la instancia de base de datos y antes de crear una base

260
Parámetros del clúster de base de
datos y la instancia de base de datos
de datos en la instancia de base de datos. De este modo, la base de datos predeterminada y las bases
de datos nuevas de la instancia de base de datos utilizarán los valores de la intercalación y del conjunto
de caracteres que especifique. Si cambia los parámetros de la intercalación o del conjunto de caracteres
para la instancia de base de datos, los cambios de parámetros no se aplicarán a las bases de datos
existentes.
Puede cambiar los valores de la intercalación o del conjunto de caracteres para una base de datos
existente mediante el comando ALTER DATABASE; por ejemplo:
ALTER DATABASE database_name CHARACTER SET character_set_name COLLATE collation;
• Si se configuran de forma incorrecta los parámetros de un grupo de parámetros , pueden producirse

efectos adversos no deseados, como la degradación del rendimiento y la inestabilidad del sistema.
Realice siempre cualquier modificación de los parámetros de base de datos con cuidado y haga una
copia de seguridad de los datos antes de modificar un grupo de parámetros . Pruebe los cambios de
configuración de los grupos de parámetros en una instancia de base de datos de prueba antes de aplicar
dichos cambios a una instancia de base de datos de producción.
• Para una base de datos global de Aurora, puede especificar distintos ajustes de configuración para los
clústeres de Aurora individuales. Asegúrese de que la configuración sea lo suficientemente similar como
para producir un comportamiento coherente si promueve un clúster secundario para convertirlo en el
principal. Por ejemplo, utilice la misma configuración de zonas horarias y conjuntos de caracteres en
todos los clústeres de una base de datos global de Aurora.
Temas
• Parámetros del clúster de base de datos y la instancia de base de datos Amazon Aurora (p. 261)
• Creación de un grupo de parámetros de base de datos (p. 262)
• Creación de un grupo de parámetros de clúster de base de datos (p. 264)
• Modificación de parámetros de un grupo de parámetros de base de datos (p. 265)
• Modificación de parámetros de un grupo de parámetros de clúster de base de datos (p. 269)
• Copia de un grupo de parámetros de base de datos (p. 271)
• Copia de un grupo de parámetros de clúster de base de datos (p. 273)
• Obtención de la lista de grupos de parámetros de base de datos (p. 274)
• Lista de grupos de parámetros de clúster de base de datos (p. 276)
• Visualización de los valores de los parámetros de un grupo de parámetros de base de datos (p. 277)
• Visualización de los valores de los parámetros de un grupo de parámetros de clúster de base de
datos (p. 278)
• Comparación de grupos de parámetros (p. 279)
• Valores de los parámetros de base de datos (p. 279)
Parámetros del clúster de base de datos y la instancia

de base de datos Amazon Aurora
Aurora utiliza un sistema de dos niveles de ajustes de configuración como aparece a continuación:
• Los parámetros de un grupo de parámetros de clúster de base de datos se aplican a todas las instancias
de bases de datos de un clúster de base de datos. Sus datos se almacenan en el subsistema de
almacenamiento compartido de Aurora. Debido a esto, todos los parámetros relacionados con el
diseño físico de los datos de tabla deben ser los mismos para todas las instancias de base de datos
en un clúster de Aurora. De igual forma, puesto que las instancias de base de datos de Aurora están

261
Creación de un grupo de parámetros de base de datos
conectadas mediante replicación, todos los parámetros para la configuración de replicación deben ser
idénticos en un clúster de Aurora.
• Los parámetros de un grupo de parámetros de base de datos se aplican a una sola instancia de base
de datos de un clúster de base de datos de Aurora. Estos parámetros están relacionados con aspectos
como el uso de la memoria que puede variar según las instancias de base de datos en el mismo clúster
de Aurora. Por ejemplo, un clúster suele contener instancias de base de datos con diferentes clases de
instancia de AWS.
Cada clúster de Aurora se asocia a un grupo de parámetros del clúster de base de datos. Cada instancia
de base de datos dentro del clúster hereda la configuración de ese grupo de parámetros del clúster
de base de datos, y se asocia a un grupo de parámetros de base de datos. Aurora asigna grupos de
parámetros predeterminados cuando crea un clúster o una nueva instancia de base de datos según la
versión y el motor de base de datos especificadas. Puede cambiar los grupos de parámetros después a los
que ha creado, donde puede editar los valores de parámetros.
Los grupos de parámetros del clúster de base de datos también incluyen valores predeterminados para
todos los parámetros de nivel de instancia de un grupo de parámetros de base de datos. Estos valores
predeterminados se han creado principalmente para configurar clústeres de Aurora Serverless, que solo
se asocian a los grupos de parámetros de clúster de base de datos, no a grupos de parámetros de base
de datos. Puede modificar la configuración de parámetros de nivel de instancia en el grupo de parámetros
del clúster de base de datos. A continuación, Aurora aplica esos ajustes a cada nueva instancia de base
de datos que se añade a un clúster de Serverless. Para obtener más información sobre los ajustes de
configuración para clústeres de Aurora Serverless y los ajustes que puede modificar, consulte Aurora
Serverless y grupos de parámetros (p. 106).
Para clústeres sin servidor, los valores de configuración que modifique en el grupo de parámetros de
clúster de base de datos anulan los valores predeterminados en el grupo de parámetros de base de datos.
Si edita los valores correspondientes en el grupo de parámetros de base de datos, dichos valores anulan la
configuración del grupo de parámetros de clúster de base de datos.
Los ajustes de parámetros de base de datos que modifique tienen preferencia sobre los valores de grupo
de parámetros de clúster de base de datos, incluso si devuelve los parámetros de configuración a sus
valores predeterminados. Puede ver qué parámetros se sobrescriben mediante el comando de la CLI
describe-db-parameters AWS CLI o la API de RDS DescribeDBParameters. El campo Source
contiene el valor user si modificó ese parámetro. Para restablecer uno o más parámetros de manera que
el valor del grupo de parámetros de clúster de base de datos tenga preferencia, utilice el comando de la
AWS CLI reset-db-parameter-group o la operación de la API de RDS ResetDBParameterGroup.
Los parámetros de instancia de base de datos y de clúster de base de datos disponible en Aurora varían
en función de la compatibilidad del motor de base de datos.
Motor de base de datos Parámetros
Aurora MySQL Consulte Parámetros de Aurora MySQL (p. 678).
Para clústeres de Aurora Serverless, consulte la información

adicional en Aurora Serverless y grupos de parámetros (p. 106).
Aurora PostgreSQL Consulte Parámetros de Amazon Aurora PostgreSQL (p. 846).

Puede crear un nuevo grupo de parámetros de base de datos mediante la Consola de administración de

262
Consola
Para crear un grupo de parámetros de base de datos
2. En el panel de navegación, seleccione Parameter groups (Grupos de parámetros).
3. Elija Create parameter group.
Aparece la ventana Create parameter group (Crear grupo de parámetros).

4. En la lista Parameter group family (Familia de grupos de parámetros), seleccione una familia de
grupos de parámetros de base de datos.
5. En la lista Type (Tipo), seleccione DB Parameter Group (Grupo de parámetros de base de datos).
6. En el cuadro Group name (Nombre de grupo), escriba el nombre del nuevo grupo de parámetros de
base de datos.
7. En el cuadro Description (Descripción), escriba una descripción para el nuevo grupo de parámetros de
base de datos.
AWS CLI
Para crear un grupo de parámetros de base de datos, utilice el comando create-db-parameter-group
de la AWS CLI. En el siguiente ejemplo se crea un grupo de parámetros de base de datos denominado
mydbparametergroup para MySQL versión 5.6 con la descripción “My new parameter group”.
Incluya los siguientes parámetros obligatorios:
• --db-parameter-group-name
• --db-parameter-group-family
• --description
Para mostrar todas las familias de grupos de parámetros disponibles, use el siguiente comando:
aws rds describe-db-engine-versions --query "DBEngineVersions[].DBParameterGroupFamily"
Note
La salida contiene duplicados.
Example
aws rds create-db-parameter-group \

--db-parameter-group-name mydbparametergroup \
--description "My new parameter group"
Para Windows:
aws rds create-db-parameter-group ^

263
Creación de un grupo de parámetros
de clúster de base de datos
--db-parameter-group-name mydbparametergroup ^
--db-parameter-group-family aurora5.6 ^
--description "My new parameter group"
El resultado de este comando debería ser similar al siguiente:
DBPARAMETERGROUP mydbparametergroup aurora5.6 My new parameter group
API de RDS
Para crear un grupo de parámetros de base de datos, utilice la acción CreateDBParameterGroup de la
API de RDS.
• DBParameterGroupName
• DBParameterGroupFamily
• Description
Creación de un grupo de parámetros de clúster de

base de datos
Puede crear un nuevo grupo de parámetros de clúster de base de datos mediante la Consola de
administración de AWS, la AWS CLI o la API de RDS.
Consola
Para crear un grupo de parámetros de clúster de base de datos
3. Elija Create parameter group.
Aparece la ventana Create parameter group (Crear grupo de parámetros).

4. En la lista Parameter group family (Familia de grupos de parámetros), seleccione una familia de
grupos de parámetros de base de datos.
5. En la lista Type (Tipo), seleccione DB Cluster Parameter Group (Grupo de parámetros de clúster de
base de datos).
6. En el cuadro Group name (Nombre de grupo), escriba el nombre del nuevo grupo de parámetros de
7. En el cuadro Description (Descripción), escriba una descripción para el nuevo grupo de parámetros de
CLI
Para crear un grupo de parámetros de clúster de base de datos, use el comando create-db-cluster-
parameter-group de la AWS CLI. En el siguiente ejemplo se crea un grupo de parámetros de clúster
base de datos denominado mydbclusterparametergroup para MySQL versión 5.6 con la descripción “My
new cluster parameter group”.

264
Modificación de parámetros de un
grupo de parámetros de base de datos
• --db-cluster-parameter-group-name
• --db-parameter-group-family
• --description
Para mostrar todas las familias de grupos de parámetros disponibles, use el siguiente comando:
aws rds describe-db-engine-versions --query "DBEngineVersions[].DBParameterGroupFamily"
Note
La salida contiene duplicados.
Example
aws rds create-db-cluster-parameter-group \

--db-cluster-parameter-group-name mydbclusterparametergroup \
--description "My new cluster parameter group"
Para Windows:
aws rds create-db-cluster-parameter-group ^

--db-cluster-parameter-group-name mydbclusterparametergroup ^
--db-parameter-group-family aurora5.6 ^
--description "My new cluster parameter group"
El resultado de este comando debería ser similar al siguiente:
DBCLUSTERPARAMETERGROUP mydbclusterparametergroup mysql5.6 My cluster new parameter

group
API de RDS
Para crear un grupo de parámetros de clúster de base de datos, use la acción
CreateDBClusterParameterGroup de la API de RDS.
• DBClusterParameterGroupName
• DBParameterGroupFamily
• Description
Modificación de parámetros de un grupo de

parámetros de base de datos
Es posible modificar los valores de los parámetros de un grupo de parámetros de base de datos creado
por el cliente; no es posible modificar los valores de los parámetros de un grupo de parámetros de base

265
de datos predeterminado. Los cambios realizados en los parámetros de un grupo de parámetros de base
de datos creado por el cliente se aplican a todas las instancias de bases de datos asociadas al grupo de
parámetros de base de datos.
Si se modifica el valor de un parámetro, el momento en que se aplica el cambio depende del tipo de
parámetro. Los cambios realizados en los parámetros dinámicos se aplican inmediatamente. Para que
surtan efecto los cambios realizados en los parámetros estáticos, es necesario reiniciar la instancia de
base de datos asociada al grupo de parámetros de base de datos. Para determinar de qué tipo es un
parámetro, obtenga la lista de parámetros de un grupo de parámetros mediante uno de los procedimientos
de la sección Obtención de la lista de grupos de parámetros de base de datos (p. 274).
La consola de RDS muestra el estado del grupo de parámetros de base de datos asociado a una instancia
de base de datos en la pestaña Configuration (Configuración). Por ejemplo, si la instancia de base de
datos no está utilizando los cambios más recientes del grupo de parámetros de base de datos que tiene
asociado, la consola de RDS muestra el grupo de parámetros de base de datos con el estado pending-
reboot. Para aplicar los cambios de parámetros más recientes en esa instancia de base de datos, reinicie
manualmente la instancia de base de datos.

266

267
Consola
Para modificar un grupo de parámetros de base de datos
3. En la lista, seleccione el grupo de parámetros que desea modificar.
4. En Parameter group actions (Acciones de grupos de parámetros), seleccione Edit (Editar).
5. Cambie los valores de los parámetros que desee modificar. Puede desplazarse por los parámetros
utilizando las teclas de flecha de la parte superior derecha del cuadro de diálogo.
No puede cambiar los valores de un grupo de parámetros predeterminado.

6. Elija Save changes.
CLI
Para modificar un grupo de parámetros de base de datos, utilice el comando modify-db-parameter-
group de la AWS CLI con los siguientes parámetros obligatorios:
• --parameters
En el siguiente ejemplo se modifican los valores de max_connections y max_allowed_packet en el

grupo de parámetros de base de datos denominado mydbparametergroup.
Note
Amazon RDS no permite pasar varios valores de parámetros delimitados por comas para un solo
parámetro.
Example
aws rds modify-db-parameter-group \

--db-parameter-group-name mydbparametergroup \
--parameters "ParameterName=max_connections,ParameterValue=250,ApplyMethod=immediate" \
"ParameterName=max_allowed_packet,ParameterValue=1024,ApplyMethod=immediate"
Para Windows:
aws rds modify-db-parameter-group ^

--db-parameter-group-name mydbparametergroup ^
--parameters "ParameterName=max_connections,ParameterValue=250,ApplyMethod=immediate" ^
"ParameterName=max_allowed_packet,ParameterValue=1024,ApplyMethod=immediate"
El comando produce un resultado similar al siguiente:
DBPARAMETERGROUP mydbparametergroup

268
Modificación de parámetros de un grupo
de parámetros de clúster de base de datos
API de RDS
Para modificar un grupo de parámetros de base de datos, utilice el comando ModifyDBParameterGroup
de la API de RDS con los siguientes parámetros necesarios:
• Parameters
Modificación de parámetros de un grupo de

parámetros de clúster de base de datos
Es posible modificar los valores de los parámetros de un grupo de parámetros de clúster de base de datos
creado por el cliente; no es posible modificar los valores de los parámetros de un grupo de parámetros
de clúster de base de datos predeterminado. Los cambios realizados en los parámetros de un grupo de
parámetros de clúster de base de datos creado por el cliente se aplican a todas las instancias de clústeres
de bases de datos asociados al grupo de parámetros de clúster de base de datos.
Si se modifica el valor de un parámetro, el momento en que se aplica el cambio depende del tipo de
parámetro. Los cambios realizados en los parámetros dinámicos se aplican inmediatamente. Para que
surtan efecto los cambios realizados en los parámetros estáticos, es necesario reiniciar las instancias
de base de datos asociadas al clúster de base de datos que utiliza el grupo de parámetros de clúster
de base de datos. Para determinar de qué tipo es un parámetro, obtenga la lista de parámetros de un
grupo de parámetros mediante uno de los procedimientos de la sección Obtención de la lista de grupos de
parámetros de base de datos (p. 274).
La consola de RDS muestra el estado del grupo de parámetros de clúster de base de datos asociado a una
instancia de base de datos. Por ejemplo, si la instancia de base de datos no está utilizando los cambios
más recientes del grupo de parámetros de clúster de base de datos que tiene asociado, la consola de RDS
muestra el grupo de parámetros de clúster de base de datos con el estado pending-reboot. Debe reiniciar
manualmente la instancia de base de datos para que surtan efecto en ella los últimos cambios realizados
en los parámetros.

269
Modificación de parámetros de un grupo
de parámetros de clúster de base de datos
Consola
Para modificar un grupo de parámetros de clúster de base de datos
3. En la lista, seleccione el grupo de parámetros que desea modificar.
5. Cambie los valores de los parámetros que desea modificar. Puede desplazarse por los parámetros
utilizando las teclas de flecha de la parte superior derecha del cuadro de diálogo.
No puede cambiar los valores de un grupo de parámetros predeterminado.


270
Copia de un grupo de parámetros de base de datos
CLI
Para modificar un grupo de parámetros de clúster de base de datos, utilice el comando modify-db-
cluster-parameter-group de la AWS CLI con los siguientes parámetros obligatorios:
• --parameters
En el siguiente ejemplo se modifican los valores de server_audit_logging y

server_audit_logs_upload en el grupo de parámetros de clúster de base de datos denominado
mydbclusterparametergroup.
Note
Amazon RDS no permite pasar varios valores de parámetros delimitados por comas para un solo
parámetro.
Example
aws rds modify-db-cluster-parameter-group \

--db-cluster-parameter-group-name mydbclusterparametergroup \
--parameters
"ParameterName=server_audit_logging,ParameterValue=1,ApplyMethod=immediate" \
"ParameterName=server_audit_logs_upload,ParameterValue=1,ApplyMethod=immediate"
Para Windows:
aws rds modify-db-cluster-parameter-group ^

--db-cluster-parameter-group-name mydbclusterparametergroup ^
--parameters
"ParameterName=server_audit_logging,ParameterValue=1,ApplyMethod=immediate" ^
"ParameterName=server_audit_logs_upload,ParameterValue=1,ApplyMethod=immediate"
El comando produce un resultado similar al siguiente:
DBCLUSTERPARAMETERGROUP mydbclusterparametergroup
API de RDS
Para modificar un grupo de parámetros de clúster de base de datos, utilice el comando
ModifyDBClusterParameterGroup de la API de RDS con los siguientes parámetros obligatorios:
• Parameters

Puede copiar los grupos de parámetros de base de datos personalizados que cree. Copiar un grupo de
parámetros es una solución conveniente cuando ya se ha creado un grupo de parámetros de base de

271
datos y se desea incluir la mayoría de los parámetros y valores personalizados de ese grupo en un nuevo
grupo de parámetros de base de datos. Puede copiar un grupo de parámetros de base de datos mediante
el comando copy-db-parameter-group de la AWS CLI o la acción CopyDBParameterGroup de la API de
RDS.
Después de copiar un grupo de parámetros de base de datos, espere al menos 5 minutos antes de
crear la primera instancia de base de datos que utilice ese grupo de parámetros de base de datos como
grupo de parámetros predeterminado. Esto permite a Amazon RDS finalizar por completo la acción
de copia antes de que se utilice el grupo de parámetros. Esto es especialmente importante para los
parámetros que son críticos al crear la base de datos predeterminada de una instancia de base de datos.
Un ejemplo es el conjunto de caracteres para la base de datos predeterminada definida por el parámetro
character_set_database. Utilice la opción Parameter Groups (Grupos de parámetros) de la consola
de Amazon RDS o el comando describe-db-parameters para comprobar que se ha creado el grupo de
Note
No es posible copiar un grupo de parámetros predeterminado. Sin embargo, puede crear un grupo
de parámetros que se base en uno predeterminado.
Consola
Para copiar un grupo de parámetros de base de datos
3. En la lista, seleccione el grupo de parámetros personalizado que desea copiar.
4. En Parameter group actions (Acciones de grupos de parámetros), seleccione Copy (Copiar).
5. En New DB parameter group identifier (Nuevo identificador de grupo de parámetros de base de datos),
escriba el nombre del nuevo grupo de parámetros.
6. En Description (Descripción), escriba una descripción para el nuevo grupo de parámetros.
7. Elija Copy.
CLI
Para copiar un grupo de parámetros de base de datos, utilice el comando copy-db-parameter-group
de la AWS CLI con los siguientes parámetros obligatorios:
• --source-db-parameter-group-identifier
• --target-db-parameter-group-identifier
• --target-db-parameter-group-description
En el siguiente ejemplo se crea un nuevo grupo de parámetros de base de datos denominado mygroup2
que es una copia del grupo de parámetros de base de datos mygroup1.
Example
aws rds copy-db-parameter-group \

--source-db-parameter-group-identifier mygroup1 \
--target-db-parameter-group-identifier mygroup2 \

272
Copia de un grupo de parámetros
--target-db-parameter-group-description "DB parameter group 2"
Para Windows:
aws rds copy-db-parameter-group ^

--source-db-parameter-group-identifier mygroup1 ^
--target-db-parameter-group-identifier mygroup2 ^
--target-db-parameter-group-description "DB parameter group 2"
API de RDS
Para copiar un grupo de parámetros de base de datos, utilice la acción CopyDBParameterGroup de la
API de RDS con los siguientes parámetros obligatorios:
• SourceDBParameterGroupIdentifier
• TargetDBParameterGroupIdentifier
• TargetDBParameterGroupDescription
Copia de un grupo de parámetros de clúster de base

de datos
Puede copiar los grupos de parámetros de clúster de base de datos personalizados que cree. Copiar
un grupo de parámetros es una solución conveniente cuando ya se ha creado un grupo de parámetros
de clúster de base de datos y se desea incluir la mayoría de los parámetros y valores personalizados
de ese grupo en un nuevo grupo de parámetros de clúster de base de datos. Puede copiar un grupo de
parámetros de clúster de base de datos mediante el comando copy-db-cluster-parameter-group de la AWS
CLI o la acción CopyDBClusterParameterGroup de la API de RDS.
Después de copiar un grupo de parámetros de clúster de base de datos, espere al menos 5 minutos antes
de crear el primer clúster de base de datos que utilice ese grupo de parámetros de clúster de base de
datos como grupo de parámetros predeterminado. Esto permite a Amazon RDS finalizar por completo la
acción de copia antes de que el grupo de parámetros se use de forma predeterminada para un clúster de
base de datos nueva. Puede utilizar la opción Parameter Groups (Grupos de parámetros) de la consola de
Amazon RDS o el comando describe-db-cluster-parameters para comprobar que se ha creado el grupo de
parámetros de clúster de base de datos.
Note
No es posible copiar un grupo de parámetros predeterminado. Sin embargo, puede crear un grupo
de parámetros que se base en uno predeterminado.
Consola
Para copiar un grupo de parámetros de clúster de base de datos
3. En la lista, seleccione el grupo de parámetros personalizado que desea copiar.
4. En Parameter group actions (Acciones de grupos de parámetros), seleccione Copy (Copiar).
5. En New DB parameter group identifier (Nuevo identificador de grupo de parámetros de base de datos),
escriba el nombre del nuevo grupo de parámetros.

273
Obtención de la lista de grupos
de parámetros de base de datos
6. En Description (Descripción), escriba una descripción para el nuevo grupo de parámetros.

7. Elija Copy.
CLI
Para copiar un grupo de parámetros de clúster de base de datos, utilice el comando copy-db-cluster-
parameter-group de la AWS CLI con los siguientes parámetros obligatorios:
• --source-db-cluster-parameter-group-identifier
• --target-db-cluster-parameter-group-identifier
• --target-db-cluster-parameter-group-description
En el siguiente ejemplo se crea un nuevo grupo de parámetros de clúster de base de datos denominado
mygroup2 que es una copia del grupo de parámetros de clúster de base de datos mygroup1.
Example
aws rds copy-db-cluster-parameter-group \

--source-db-cluster-parameter-group-identifier mygroup1 \
--target-db-cluster-parameter-group-identifier mygroup2 \
--target-db-cluster-parameter-group-description "DB parameter group 2"
Para Windows:
aws rds copy-db-cluster-parameter-group ^

--source-db-cluster-parameter-group-identifier mygroup1 ^
--target-db-cluster-parameter-group-identifier mygroup2 ^
--target-db-cluster-parameter-group-description "DB parameter group 2"
API de RDS
Para copiar un grupo de parámetros de clúster de base de datos, utilice la acción
CopyDBClusterParameterGroup de la API de RDS con los siguientes parámetros obligatorios:
• SourceDBClusterParameterGroupIdentifier
• TargetDBClusterParameterGroupIdentifier
• TargetDBClusterParameterGroupDescription
Obtención de la lista de grupos de parámetros de base

de datos
Es posible obtener un listado de los grupos de parámetros de base de datos que se han creado para una
cuenta de AWS.
Note
Los grupos de parámetros predeterminados se crean automáticamente a partir de una plantilla de

parámetros predeterminados cuando se crea una instancia de base de datos para un motor y una
versión de base de datos específicos. Estos grupos de parámetros predeterminados contienen los

274
Obtención de la lista de grupos
de parámetros de base de datos
valores preferidos para los parámetros y no se pueden modificar. Los valores de los parámetros
se pueden modificar cuando se crea un grupo de parámetros personalizado.
Consola
Para obtener una lista de todos los grupos de parámetros de base de datos de una cuenta de
AWS
Los grupos de parámetros de base de datos aparecen en una lista.
CLI
Para obtener la lista de todos los grupos de parámetros de base de datos para una cuenta de AWS, utilice
el comando describe-db-parameter-groups de la AWS CLI.
Example
En el siguiente ejemplo se obtiene la lista de todos los grupos de parámetros de base de datos disponibles
en una cuenta de AWS.
aws rds describe-db-parameter-groups
El comando devuelve una respuesta similar a la siguiente:
DBPARAMETERGROUP default.mysql5.5 mysql5.5 Default parameter group for MySQL5.5

DBPARAMETERGROUP default.mysql5.6 mysql5.6 Default parameter group for MySQL5.6
DBPARAMETERGROUP mydbparametergroup mysql5.6 My new parameter group
En el siguiente ejemplo se describe el grupo de parámetros mydbparamgroup1.
aws rds describe-db-parameter-groups \

--db-parameter-group-name mydbparamgroup1
Para Windows:
aws rds describe-db-parameter-groups ^

--db-parameter-group-name mydbparamgroup1
DBPARAMETERGROUP mydbparametergroup1 mysql5.5 My new parameter group
API de RDS
Para obtener la lista de todos los grupos de parámetros de base de datos de una cuenta de AWS, utilice la
acción DescribeDBParameterGroups de la API de RDS.

275
Lista de grupos de parámetros de clúster de base de datos
Lista de grupos de parámetros de clúster de base de

datos
Es posible obtener un listado de los grupos de parámetros de clúster de base de datos que se han creado
para una cuenta de AWS.
Note
Los grupos de parámetros predeterminados se crean automáticamente a partir de una plantilla

de parámetros predeterminados cuando se crea un clúster de base de datos para un motor y una
versión de base de datos específicos. Estos grupos de parámetros predeterminados contienen los
valores preferidos para los parámetros y no se pueden modificar. Los valores de los parámetros
se pueden modificar cuando se crea un grupo de parámetros personalizado.
Consola
Para obtener una lista de todos los grupos de parámetros de clúster de base de datos de una
cuenta de AWS
Los grupos de parámetros de clúster de base de datos aparecen en la lista con Grupo de parámetros
de clúster de base de datos para Tipo.
CLI
Para obtener la lista de todos los grupos de parámetros de clúster de base de datos para una cuenta de
AWS, utilice el comando describe-db-cluster-parameter-groups de la AWS CLI.
Example
En el siguiente ejemplo se obtiene la lista de todos los grupos de parámetros de clúster de base de datos
disponibles en una cuenta de AWS.
aws rds describe-db-cluster-parameter-groups
DBCLUSTERPARAMETERGROUPS arn:aws:rds:us-west-2:1234567890:cluster-
pg:default.aurora5.6 default.aurora5.6 aurora5.6 Default cluster parameter
group for aurora5.6
pg:mydbclusterparametergroup mydbclusterparametergroup aurora5.6 My new cluster
parameter group
En el siguiente ejemplo se describe el grupo de parámetros mydbclusterparametergroup.
aws rds describe-db-cluster-parameter-groups \

--db-cluster-parameter-group-name mydbclusterparametergroup

276
Visualización de los valores de los parámetros
de un grupo de parámetros de base de datos
Para Windows:
aws rds describe-db-cluster-parameter-groups ^

--db-cluster-parameter-group-name mydbclusterparametergroup
pg:mydbclusterparametergroup mydbclusterparametergroup aurora5.6 My new cluster
parameter group
API de RDS
Para obtener la lista de todos los grupos de parámetros de clúster de base de datos de una cuenta de
AWS, utilice la acción DescribeDBClusterParameterGroups de la API de RDS.
Visualización de los valores de los parámetros de un

Es posible obtener una lista de todos los parámetros de un grupo de parámetros de base de datos y sus
valores.
Consola
Para ver los valores de los parámetros de un grupo de parámetros de base de datos
Los grupos de parámetros de base de datos aparecen en una lista.

3. Seleccione el nombre del grupo de parámetros para ver su lista de parámetros.
CLI
Para ver los valores de los parámetros de un grupo de parámetros de base de datos, utilice el comando
describe-db-parameters de la AWS CLI con el siguiente parámetro obligatorio.
Example
En el siguiente ejemplo se obtiene la lista de los parámetros y los valores de los parámetros de un grupo
de parámetros de base de datos denominado mydbparametergroup.
aws rds describe-db-parameters --db-parameter-group-name mydbparametergroup
DBPARAMETER Parameter Name Parameter Value Source Data Type Apply

Type Is Modifiable
DBPARAMETER allow-suspicious-udfs engine-default boolean static
false

277
Visualización de los valores de los parámetros de
un grupo de parámetros de clúster de base de datos
DBPARAMETER auto_increment_increment engine-default integer dynamic

true
DBPARAMETER auto_increment_offset engine-default integer dynamic
true
DBPARAMETER binlog_cache_size 32768 system integer dynamic
true
DBPARAMETER socket /tmp/mysql.sock system string static
false
API de RDS
Para ver los valores de los parámetros de un grupo de parámetros de base de datos, utilice el comando
DescribeDBParameters de la API de RDS con el siguiente parámetro obligatorio.
Visualización de los valores de los parámetros de un

grupo de parámetros de clúster de base de datos
Es posible obtener una lista de todos los parámetros de un grupo de parámetros de clúster de base de
datos y sus valores.
Consola
Para ver los valores de los parámetros de un grupo de parámetros de clúster de base de datos
Los grupos de parámetros de clúster de base de datos aparecen en la lista con Grupo de parámetros
de clúster de base de datos para Tipo.
3. Seleccione el nombre del grupo de parámetros de clúster de base de datos para ver su lista de
parámetros.
CLI
Para ver los valores de los parámetros de un grupo de parámetros de clúster de base de datos, utilice el
comando describe-db-cluster-parameters de la AWS CLI con el siguiente parámetro obligatorio.
Example
En el siguiente ejemplo se obtiene la lista de los parámetros y los valores de los parámetros de un grupo
de parámetros de clúster de base de datos denominado mydbparametergroup.
aws rds describe-db-cluster-parameters --db-cluster-parameter-group-

name mydbclusterparametergroup

278
Comparación de grupos de parámetros
PARAMETERS pending-reboot dynamic string IAM role ARN used to load data from
AWS S3 True aurora_load_from_s3_role engine-default
PARAMETERS pending-reboot dynamic string IAM role ARN used to select data
into AWS S3 True aurora_select_into_s3_role engine-default
PARAMETERS pending-reboot dynamic string Default IAM role ARN used to access
AWS Lambda Service True aws_default_lambda_role engine-default
PARAMETERS pending-reboot dynamic string Arn for the role used to upload
data to CloudWatch Logs True aws_default_logs_role engine-default
API de RDS
Para ver los valores de los parámetros de un grupo de parámetros de clúster de base de datos, utilice el
comando DescribeDBClusterParameters de la API de RDS con el siguiente parámetro obligatorio.
Comparación de grupos de parámetros

Puede usar la Consola de administración de AWS para ver las diferencias entre dos grupos de parámetros
del mismo motor y versión de la base de datos.
Para comparar dos grupos de parámetros
3. En la lista, seleccione los dos grupos de parámetros que desea comparar.
4. En Parameter group actions (Acciones de grupos de parámetros), seleccione Compare (Comparar).
Valores de los parámetros de base de datos

Puede especificar el valor de un parámetro de base de datos como una de las siguientes opciones:
• Una constante entera

• Una fórmula de parámetro de base de datos
• Una función de parámetro de base de datos
• Una constante de cadena de caracteres
• Una expresión logarítmica (la función log representa el logaritmo de base 2); por ejemplo,
value={log(DBInstanceClassMemory/8187281418)*1000}
Fórmulas de parámetros de base de datos

Una fórmula de parámetros de base de datos es una expresión que da como resultado un valor entero
o un valor booleano y está encerrada entre llaves: {}. Puede especificar fórmulas para el valor de un
parámetro de base de datos o como argumento de una función de parámetro de base de datos.
Sintaxis
{FormulaVariable}
{FormulaVariable*Integer}
{FormulaVariable*Integer/Integer}

279
{FormulaVariable/Integer}
Variables de las fórmulas de parámetros de base de datos

Cada variable de la fórmula devuelve un entero o un valor booleano. Los nombres de las variables
distinguen entre mayúsculas y minúsculas.
AllocatedStorage
Devuelve el tamaño del volumen de datos, en bytes.

DBInstanceClassMemory
Devuelve el número de bytes de memoria asignados a la clase de instancia de base de datos

asociada a la instancia de base de datos actual, menos la memoria utilizada por los procesos de
Amazon RDS que administran la instancia.
EndPointPort
Devuelve el número del puerto utilizado para conectarse a la instancia de base de datos.
Operadores de las fórmulas de parámetros de base de datos

Las fórmulas de parámetros de base de datos admiten dos operadores: división y multiplicación.
Operador de división: /
Divide el dividendo entre el divisor, y devuelve un cociente entero. Los decimales del cociente se
truncan, no se redondean.
Sintaxis
dividend / divisor
Los argumentos del dividendo y el divisor deben ser expresiones enteras.

Operador de multiplicación: *
Multiplica las expresiones, devolviendo el producto de las expresiones. Los decimales de las
expresiones se truncan, no se redondean.
Sintaxis
expression * expression
Las dos expresiones deben dar como resultado valores enteros.
Funciones de parámetros de base de datos

Los argumentos de los parámetros se pueden especificar como valores enteros o como fórmulas.
Cada función debe tener un argumento como mínimo. Si hay varios argumentos, se pueden especificar
como una lista separada por comas. La lista no puede tener ningún miembro vacío; por ejemplo,
argumento1,,argumento3. Los nombres de las funciones no distinguen entre mayúsculas y minúsculas.
Note
Las funciones de parámetros de base de datos no se admiten actualmente en la AWS CLI.

280
IF()
Devuelve un argumento.
Sintaxis
IF(argument1, argument2, argument3)
Devuelve el segundo argumento si el primer argumento da como resultado true. En caso contrario,
devuelve el tercer argumento.
GREATEST()
Devuelve el valor más grande de una lista de números enteros o fórmulas de parámetros.
Sintaxis
GREATEST(argument1, argument2,...argumentn)
Devuelve un número entero.

LEAST()
Devuelve el valor más pequeño de una lista de números enteros o fórmulas de parámetros.
Sintaxis
LEAST(argument1, argument2,...argumentn)

SUM()
Suma los valores de los números enteros o fórmulas de parámetros especificados.
Sintaxis
SUM(argument1, argument2,...argumentn)
Ejemplos de valores de los parámetros de base de datos

En estos ejemplos se muestra el uso de fórmulas y funciones en los valores de los parámetros de base de
datos.
Warning
Si se configuran de forma incorrecta los parámetros de un grupo de parámetros de base de datos,

pueden producirse efectos adversos no deseados, como la degradación del desempeño y la
inestabilidad del sistema. Tenga cuidado siempre que modifique los parámetros de base de datos
y haga una copia de seguridad de los datos antes de modificar el grupo de parámetros de base
de datos. Pruebe los cambios de los grupos de parámetros en instancias de bases de datos de
prueba, creadas mediante restauraciones a un momento dado, antes de aplicar dichos cambios a
las instancias de bases de datos de producción.
Puede especificar la función LEAST() en el valor de un parámetro table_definition_cache de Aurora

MySQL para establecer e número de definiciones de tabla que se pueden almacenar en la memoria caché
de definiciones para que sea el menor de estos valores: DBInstanceClassMemory/393040 o 20 000.

281
Clonación de bases de datos en un
clúster de bases de datos de Aurora
LEAST({DBInstanceClassMemory/393040}, 20000)
Clonación de bases de datos en un clúster de

bases de datos de Aurora
Mediante la clonación de bases de datos, puede crear de una forma rápida y rentable clones de todas las
bases de datos dentro de un clúster de base de datos Aurora. Las bases de datos clonadas requieren un
espacio adicional mínimo cuando se crean inicialmente.
La clonación de bases de datos usa un protocolo de copia en escritura en el que los datos se copian
únicamente cuando cambian en las bases de datos de origen o en las bases de datos clonadas. Puede
crear varios clones partiendo del mismo clúster de base de datos. También puede crear clones adicionales
desde otros clones. Para obtener más información acerca del funcionamiento del protocolo de copia en
escritura en el contexto del almacenamiento de Aurora, consulte Protocolo de copia en escritura para la
clonación de bases de datos (p. 283).
Puede usar la clonación de bases de datos en diversos casos de uso, especialmente cuando no desee que
su entorno de producción se vea afectado. A continuación se muestran algunos ejemplos:
• Experimentar con el impacto de los cambios, como por ejemplo los cambios de esquema o los cambios
de grupos de parámetros, y valorar dicho impacto.
• Realizar operaciones intensivas, como exportar datos o ejecutar consultas analíticas.
• Crear una copia de un clúster de base de datos de producción en un entorno que no sea de producción
para el desarrollo o las pruebas.
Temas
• Limitaciones (p. 282)
• Protocolo de copia en escritura para la clonación de bases de datos (p. 283)
• Eliminación de bases de datos de origen (p. 284)
• Clonación de un clúster de Aurora mediante la Consola de administración de AWS (p. 285)
• Clonación de un clúster de Aurora mediante la AWS CLI (p. 285)
• Clonación entre cuentas (p. 286)
Limitaciones
La clonación de bases de datos tiene algunas limitaciones, que se describen a continuación:
• No puede crear bases de datos clonadas entre regiones de AWS diferentes. Las bases de datos
clonadas se deben crear en la misma región que las bases de datos de origen.
• Actualmente, existe un límite de 15 clones basados en una copia, incluidos los clones basados en otros
clones. Después de eso, solo se podrán crear copias. No obstante, cada copia puede tener también
hasta 15 clones.
• La clonación de bases de datos entre varias cuentas solo es compatible actualmente con Aurora
MySQL.
• En la actualidad, no es posible clonar desde un clúster sin la característica de consulta paralela a un
clúster con consulta paralela habilitada. Para llevar datos a un clúster que utiliza la consulta paralela,
cree una instantánea del clúster original y restáurela al clúster donde está habilitada la opción de
consulta paralela.

282
Protocolo de copia en escritura
para la clonación de bases de datos
• Puede proporcionar una Virtual Private Cloud (VPC) diferente para su clon. Sin embargo, las subredes
de esas VPC deben estar asignadas al mismo conjunto de zonas de disponibilidad.
Protocolo de copia en escritura para la clonación de

bases de datos
Las siguientes situaciones ilustran el funcionamiento del protocolo de copia en escritura.
• Antes de la clonación de la base de datos (p. 283)

• Después de la clonación de la base de datos (p. 283)
• Cuando se produce un cambio en la base de datos de origen (p. 284)
• Cuando se produce un cambio en la base de datos clonada (p. 284)
Antes de la clonación de la base de datos

En una base de datos de origen, los datos se almacenan en páginas. En el diagrama siguiente, la base de
datos de origen tiene cuatro páginas.
Después de la clonación de la base de datos

Como se muestra en el diagrama siguiente, no se producen cambios en la base de datos de origen
después de la clonación. Tanto la base de datos de origen como la base de datos clonada apuntan a las
mismas cuatro páginas. Ninguna de las páginas se ha copiado físicamente, por lo que no se necesita
almacenamiento adicional.

283
Eliminación de bases de datos de origen
Cuando se produce un cambio en la base de datos de origen

En el siguiente ejemplo, la base de datos de origen realiza un cambio en los datos de la Page 1. En
lugar de escribir en la Page 1 original, se usa almacenamiento adicional para crear una nueva página
denominada Page 1'. Ahora, la base de datos de origen apunta a la nueva Page 1' y también a la Page
2, la Page 3 y la Page 4. La base de datos clonada sigue apuntando a la Page 1 a través de la Page 4.
Cuando se produce un cambio en la base de datos clonada

En el siguiente diagrama, la base de datos clonada también ha sufrido un cambio, esta vez en la Page 4.
En lugar de escribir en la Page 4 original, se usa almacenamiento adicional para crear una nueva página
denominada Page 4'. La base de datos de origen sigue apuntando a la Page 1' y también a la Page 2
a través de la Page 4, pero ahora la base de datos clonada apunta a la Page 1 a través de la Page 3 y
también de la Page 4'.
Como se muestra en la segunda situación, después de la clonación de la base de datos no se requiere

almacenamiento adicional en el momento de la creación del clon. Sin embargo, a medida que se
producen cambios en la base de datos de origen y en la base de datos clonada, solo se crean las páginas
modificadas, como se muestra en las situaciones tercera y cuarta. A medida que se producen más
cambios a lo largo del tiempo tanto en la base de datos de origen como en la base de datos clonada, irá
necesitando más almacenamiento para capturar y almacenar los cambios.
Eliminación de bases de datos de origen

Cuando se elimina una base de datos de origen que tiene una o varias bases de datos clonadas asociadas
con ella, las bases de datos clonadas no se ven afectadas. Las bases de datos clonadas siguen apuntando
a las páginas que antes pertenecían a la base de datos de origen.

284
Clonación mediante la Consola de administración de AWS
Clonación de un clúster de Aurora mediante la

El siguiente procedimiento describe cómo clonar un clúster de base de datos Aurora usando la Consola de
Estas instrucciones se aplican a los clústeres de base de datos que pertenecen a la misma cuenta de AWS
que está creando la clonación. Si el clúster de base de datos pertenece a una cuenta de AWS diferente,
consulte Clonación entre cuentas (p. 286).
Para crear un clon de un clúster de base de datos que pertenezca a su cuenta de AWS mediante
la Consola de administración de AWS, realice el siguiente procedimiento:
2. En el panel de navegación, seleccione Databases (Bases de datos). Elija el clúster de base de datos
para el que desee crear un clon.
3. En Actions (Acciones), elija Create alias (Crear alias).
4. En la página Create Clone (Crear clon), escriba un nombre para la instancia principal del clúster de
base de datos clonado como DB instance identifier (Identificador de instancias de bases de datos).
Si lo desea, configure los demás ajustes del clúster de base de datos clonado. Para obtener
información acerca de los distintos ajustes de clúster de base de datos, consulte Consola (p. 87).
5. Elija Create Clone (Crear clon) para lanzar el clúster de base de datos clonado.
Clonación de un clúster de Aurora mediante la AWS

CLI
El siguiente procedimiento describe cómo clonar un clúster de base de datos Aurora usando la AWS CLI.
Para crear un clon de un clúster de base de datos con la AWS CLI
• Llame al comando restore-db-cluster-to-point-in-time de la CLI de AWS y suministre los siguientes

valores:
• --source-db-cluster-identifier: nombre del clúster de base de datos origen del que desea
crear un clon.
• --db-cluster-identifier: nombre del clúster de base de datos clonado.
• --restore-type copy-on-write: valores que indican que se debe crear un clúster de base de
datos clonado.
• --use-latest-restorable-time: indica que se utiliza la hora de la última copia de seguridad
restaurable.
El siguiente ejemplo crea un clon del clúster de base de datos denominado sample-source-
cluster. El nombre del clúster de base de datos clonado es sample-cluster-clone.
aws rds restore-db-cluster-to-point-in-time \

--source-db-cluster-identifier sample-source-cluster \
--db-cluster-identifier sample-cluster-clone \

285
Clonación entre cuentas
--restore-type copy-on-write \
--use-latest-restorable-time
Para Windows:
aws rds restore-db-cluster-to-point-in-time ^

--source-db-cluster-identifier sample-source-cluster ^
--db-cluster-identifier sample-cluster-clone ^
--restore-type copy-on-write ^
Note
El comando restore-db-cluster-to-point-in-time de la CLI de AWS solo restaura el clúster de

la base de datos, no las instancias de base de datos dicho clúster. Debe invocar el comando
create-db-instance para crear instancias de base de datos para el clúster de base de datos
restaurado, especificando el identificador de dicho clúster restaurado en --db-instance-
identifier. Solo puede crear instancias de base de datos después de que se haya completado
el comando restore-db-cluster-to-point-in-time y de que el clúster de base de datos
esté disponible.

Con Amazon Aurora, puede compartir un clúster de base de datos de Aurora con otra cuenta de AWS u
organización de AWS. Al compartir de esta forma, puede clonar el clúster de base de datos y acceder al
clon desde la otra cuenta u organización.
Por ejemplo, si usa cuentas separadas para producción y pruebas, puede crear un clon de datos de
producción en su cuenta de pruebas. Puede utilizar este clon para experimentar con diferentes parámetros
y ejecutar amplias consultas de procesamiento analítico en línea (OLAP), todo sin que afecte al entorno
de producción. Puede dar a su empresa acceso a su base de datos, por ejemplo, para que un proveedor
externo capacite un modelo de aprendizaje automático. La clonación entre cuentas es mucho más rápida
en dichas situaciones que crear y restaurar una instantánea de base de datos.
Para autorizar el uso compartido, debe utilizar AWS Resource Access Manager (AWS RAM). Para obtener
más información sobre el control de acceso a través de AWS RAM, consulte la Guía del usuario de AWS
RAM.
La creación de un clon entre cuentas requiere acciones de la cuenta de AWS propietaria del clúster original
y la cuenta de AWS que crea el clon. En primer lugar, el propietario modifica el clúster para permitir que
una o más cuentas lo clonen. Si alguna de las cuentas están en una organización de AWS diferente, AWS
genera una invitación de uso compartido y la otra cuenta debe aceptar la invitación antes de proceder. A
continuación, cada cuenta autorizada puede clonar el clúster. En todo este proceso, el clúster se identifica
mediante su nombre de recurso de Amazon (ARN) único.
Se le aplican cargos por espacio de almacenamiento adicional si realiza cambios en los datos. Si se borra
el clúster de origen, los costes de almacenamiento se distribuyen por igual entre el resto de clústeres
clonados.
Temas
• Limitaciones de la clonación entre cuentas (p. 287)
• Permitir a otras cuentas de AWS clonar su clúster (p. 287)
• Clonar un clúster propiedad de otra cuenta de AWS (p. 290)

286
Limitaciones de la clonación entre cuentas

La clonación entre cuentas de Aurora tiene las siguientes limitaciones:
• No puede clonar un clúster de Aurora Serverless en cuentas de AWS.

• No puede clonar una base de datos global de Aurora en cuentas de AWS.
• Ver y aceptar invitaciones de uso compartido requiere el uso de la AWS CLI, la API de Amazon RDS o
la consola de AWS RAM. Actualmente, no puede realizar este procedimiento utilizando la consola de
Amazon RDS.
• Cuando se crea un clúster entre cuentas, no se puede crear clones adicionales de ese clúster ni
compartir el clúster clonado con otras cuentas de AWS.
• El número máximo de los clones entre cuentas que puede tener para cualquier clúster de Aurora es 15.
• Su clúster debe tener el estado ACTIVE en el momento en que lo comparte con otras cuentas de AWS.
• Mientras un clúster de Aurora se comparte con otras cuentas de AWS, no puede cambiar el nombre del
clúster.
• No puede crear un clon entre cuentas de un clúster que esté cifrado con la clave de RDS
predeterminada.
• Cuando un clúster cifrado se comparte con usted, debe cifrar el clúster clonado. La clave que utilice
puede ser diferente de la clave de cifrado del clúster original. El propietario del clúster también debe
concederle permiso para acceder a la clave de AWS Key Management Service (AWS KMS) del clúster
original.
Permitir a otras cuentas de AWS clonar su clúster

Para permitir a otras cuentas de AWS clonar un clúster de su propiedad, utilice AWS RAM para establecer
el permiso de uso compartido. Al hacerlo, también se envía una invitación a cada una de las otras cuentas
que está en una organización de AWS diferente.
Para que los procedimientos compartan recursos de su propiedad en la consola de AWS RAM, consulte
Sharing Resources Owned by You en la Guía del usuario de AWS RAM.
Temas
• Conceder permisos a otras cuentas de AWS para clonar su clúster (p. 287)
• Comprobar si un clúster de su propiedad se comparte con otras cuentas de AWS (p. 289)
Conceder permisos a otras cuentas de AWS para clonar su clúster

Si el clúster que está compartiendo está cifrado, también comparte la clave maestra de cliente (CMK)
del clúster. Puede permitir que los usuarios o roles de AWS Identity and Access Management (IAM) de
una cuenta de AWS utilice una CMK en una cuenta diferente. Para hacer esto, primero tiene que añadir
la cuenta externa (usuario raíz) a la política de claves de CMK a través de AWS KMS. No se añaden los
usuarios o roles de IAM individuales a la política de claves, solo la cuenta externa que los posee. Solo
puede compartir una CMK que cree, no la clave de servicio de RDS predeterminada. Para obtener más
información sobre control de acceso para CMK, consulte Autenticación y control de acceso de KMS de
AWS.
Consola
Para conceder permisos para clonar su clúster con la Consola de administración de AWS

287

3. Elija el clúster de base de datos que quiera compartir para ver su página Details (Detalles) y elija la
pestaña Connectivity & security (Conectividad y seguridad).
4. En la sección Share DB cluster with other AWS accounts (Compartir clúster de base de datos con
otras cuentas de AWS), introduzca el ID numérico de la cuenta para la cuenta de AWS que quiera
permitir clonar este clúster. Para los ID de cuenta en la misma organización, puede comenzar a
escribir en el cuadro y luego elegir en el menú.
Important
En algunos casos, es posible que desee una cuenta que no esté en la misma organización
de AWS que su cuenta para clonar un clúster. En estos casos, por razones de seguridad la
Consola de administración de AWS no notifica el propietario de ese ID de cuenta o si existe la
cuenta.
Tenga cuidado de introducir números de cuenta que no estén en la misma organización de
AWS que su cuenta de AWS. Verifique inmediatamente que ha compartido con la cuenta
pretendida.
5. En la página de confirmación, verifique que el ID de cuenta que ha especificado sea correcto.
Introduzca share en el cuadro de confirmación para confirmar.
En la página Details (Detalles), aparece una entrada que muestra el ID de cuenta de AWS
especificado en Accounts that this DB cluster is shared with (Cuentas con las que se comparte
este clúster de base de datos). La columna Status (Estado) inicialmente muestra el estado Pending
(Pendiente).
6. Póngase en contacto con el propietario de la otra cuenta de AWS o inicie sesión en dicha cuenta si es
propietario de ambas. Pida al propietario de la otra cuenta que acepte la invitación de uso compartido
y clone el clúster de base de datos, como se describe a continuación.
AWS CLI
Para conceder permisos para clonar su clúster con la AWS CLI
1. Recopile la información de los parámetros requeridos. Necesita el ARN de su clúster y el ID numérico

de la otra cuenta de AWS.
2. Ejecute el comando de la CLI create-resource-share.
aws ram create-resource-share --name descriptive_name \

--region region \
--resource-arns cluster_arn \
--principals other_account_ids
Para Windows:
aws ram create-resource-share --name descriptive_name ^

--region region ^
--resource-arns cluster_arn ^
--principals other_account_ids
Para incluir varios ID de cuenta para el parámetro --principals, separe los ID entre sí con
espacios. Para especificar si los ID de cuenta permitidos pueden estar fuera de la organización
de AWS, incluya el parámetro --allow-external-principals o --no-allow-external-
principals para create-resource-share.

288
API de RAM
Para conceder permisos para clonar su clúster con la API de RAM
1. Recopile la información de los parámetros requeridos. Necesita el ARN de su clúster y el ID numérico

de la otra cuenta de AWS.
2. Llame a la operación de la API de RAM CreateResourceShare y especifique los siguientes valores:
• Especifique los ID de cuenta de una o más cuentas de AWS en el parámetro principals.

• Especifique los ARN de uno o más clústeres de base de datos de Aurora en el parámetro
resourceArns.
• Especifique si los ID de cuenta permitidos pueden estar fuera de la organización de AWS o no
incluyendo un valor booleano para el parámetro allowExternalPrincipals.
Recreación de un clúster que utiliza la clave predeterminada de RDS
Para volver a crear un clúster cifrado que utiliza la clave de RDS predeterminada
Si el clúster cifrado que desea compartir utiliza la clave predeterminada de RDS, debe volver a crearlo
utilizando una clave maestra (CMK) y compartir el nuevo clúster en su lugar. Se hace creando una
instantánea manual de su clúster de base de datos y restaurándola en un nuevo clúster. Utilice los
siguientes pasos:
3. Elija una instantánea.
4. En Actions (Acciones), elija Copy Snapshot (Copiar instantánea) y, a continuación, elija Enable
encryption (Habilitar cifrado).
5. En Master key (Clave maestra), elija la nueva clave de cifrado que desee utilizar.
6. Restaure la instantánea copiada. Para ello, siga el procedimiento indicado en Restauración de una
instantánea de clúster de base de datos (p. 319). La nueva instancia de base de datos utiliza su
clave de cifrado nueva.
7. (Opcional) Elimine el clúster de base de datos antiguo si ya no lo necesita más. Para ello, siga el
procedimiento indicado en Eliminación de una instantánea de clúster de base de datos (p. 339).
Antes de hacerlo, confirme que su nuevo clúster tiene todos los datos necesarios y que su aplicación
puede acceder a ellos correctamente.
Comprobar si un clúster de su propiedad se comparte con otras cuentas de AWS

Puede comprobar si otros usuarios tienen permiso para compartir un clúster. Hacerlo puede ayudarle a
comprender si el clúster se acerca al límite del número máximo de clones entre cuentas.
Para que los procedimientos compartan recursos utilizando la consola de AWS RAM, consulte Sharing
Resources Owned by You en la Guía del usuario de AWS RAM.
AWS CLI
Para descubrir si un clúster de su propiedad se comparte con otras cuentas de AWS utilizando la
AWS CLI
• Llame al comando list-principals de la CLI de RAM utilizando su ID de cuenta como el

propietario del recurso y el ARN de su clúster como el ARN del recurso. Puede ver todas las unidades
compartidas con el siguiente comando. Los resultados indican qué cuentas de AWS tienen permiso
para clonar el clúster.

289
aws ram list-principals \

--resource-arns your_cluster_arn \
--principals your_aws_id
API de RAM
Para descubrir si un clúster de su propiedad se comparte con otras cuentas de AWS utilizando la
API de RAM
• Llame a la operación ListPrincipals de la API de RAM. Utilice su ID de cuenta como el propietario del
recurso y el ARN de su clúster como el ARN del recurso.
Clonar un clúster propiedad de otra cuenta de AWS

Para clonar un clúster propiedad de otra cuenta de AWS, utilice AWS RAM para obtener permiso para
crear un clon. Una vez que tenga el permiso requerido, utilice el procedimiento estándar para clonar un
clúster de Aurora.
También puede comprobar si un clúster de su propiedad es un clon de un clúster propiedad de una cuenta
de AWS diferente.
Para que funcionen los procedimientos con recursos que son propiedad de otros en la consola de AWS
RAM, consulte Accessing Resources Shared With You en la Guía del usuario de AWS RAM.
Temas
• Visualización de invitaciones para clonar clústeres propiedad de otras cuentas de AWS (p. 290)
• Aceptación de invitaciones para compartir clústeres propiedad de otras cuentas de AWS (p. 291)
• Clonar un clúster de Aurora propiedad de otra cuenta de AWS (p. 292)
• Comprobar si un clúster de base de datos es un clon entre cuentas (p. 295)
Visualización de invitaciones para clonar clústeres propiedad de otras cuentas de

AWS
Para trabajar con invitaciones para clonar clústeres propiedad de cuentas de AWS en otras organizaciones
de AWS, utilice la AWS CLI, la consola de AWS RAM o la API de AWS RAM. Actualmente, no puede
realizar este procedimiento utilizando la consola de Amazon RDS.
Para que funcionen los procedimientos con invitaciones en la consola de AWS RAM, consulte Accessing
Resources Shared With You en la Guía del usuario de AWS RAM.
AWS CLI
Para ver invitaciones para clonar clústeres propiedad de otras cuentas de AWS utilizando la AWS
CLI
1. Ejecute el comando get-resource-share-invitations de la CLI de RAM.
aws ram get-resource-share-invitations --region region_name
Los resultados del comando anterior muestran todas las invitaciones para clonar clústeres, incluidas
las que ya haya aceptado o rechazado.

290
2. (Opcional) Filtre la lista de forma que vea solo las invitaciones que requieren una acción por
su parte. Para hacerlo, añada el parámetro --query 'resourceShareInvitations[?
status==`PENDING`]'.
API de RAM
Para ver invitaciones para clonar clústeres propiedad de otras cuentas de AWS utilizando la API
de RAM
1. Llame a la operación GetResourceShareInvitations de la API de RAM. Esta operación devuelve

estas invitaciones, incluidas las que ya haya aceptado o rechazado.
2. (Opcional) Busque solo invitaciones que requieran de una acción por su parte comprobando que el
campo de devolución resourceShareAssociations tenga un valor de status de PENDING.
Aceptación de invitaciones para compartir clústeres propiedad de otras cuentas

de AWS
Puede aceptar invitaciones para compartir clústeres propiedad de otras cuentas de AWS que estén en
diferentes organizaciones de AWS. Para trabajar con estas invitaciones, utilice la AWS CLI, las API de
RAM y RDS o la consola de RAM. Actualmente, no puede realizar este procedimiento utilizando la consola
de RDS.
Para que funcionen los procedimientos con invitaciones en la consola de AWS RAM, consulte Accessing
Resources Shared With You en la Guía del usuario de AWS RAM.
Consola
Para aceptar una invitación para compartir un clúster desde otra cuenta de AWS utilizando la AWS
CLI
1. Busque el ARN de la invitación ejecutando el comando get-resource-share-invitations de la

CLI de RAM, como se ha mostrado anteriormente.
2. Acepte la invitación llamando al comando accept-resource-share-invitation de la CLI de
RAM, como se muestra a continuación.
aws ram accept-resource-share-invitation \

--resource-share-invitation-arn invitation_arn \
--region region
Para Windows:
aws ram accept-resource-share-invitation ^

--resource-share-invitation-arn invitation_arn ^
--region region
API de RAM y RDS
Para aceptar invitaciones para compartir el clúster de alguien utilizando las API de RAM y RDS
1. Busque el ARN de la invitación llamando a la operación GetResourceShareInvitations de la CLI

de RAM, como se ha mostrado anteriormente.

291
2. Pase ese ARN como el parámetro resourceShareInvitationArn a la operación

AcceptResourceShareInvitation de la API de RDS.
Clonar un clúster de Aurora propiedad de otra cuenta de AWS

Después de aceptar la invitación de otra cuenta de AWS propiedad del clúster de base de datos, como se
ha mostrado anteriormente, puede clonar el clúster.
Consola
Para clonar un clúster de Aurora propiedad de otra cuenta de AWS utilizando la Consola de
administración de AWS
En la parte superior de la lista de bases de datos, debe ver uno o más elementos con un valor de
Role (Role) de Shared from account #account_id. Por razones de seguridad, solo puede ver
información limitada sobre los clústeres originales. Las propiedades que puede ver son las de motor
de base de datos y versión que deben ser las mismas en su clúster clonado.
3. Elija el clúster que pretende clonar.
4. En Actions (Acciones), elija Create alias (Crear alias).
5. Siga el procedimiento de Clonación de un clúster de Aurora mediante la Consola de administración de
AWS (p. 285) para finalizar la configuración del clúster clonado.
6. Según sea necesario, habilite el cifrado del clúster clonado. Si el clúster que esté clonando está
cifrado, debe habilitar el cifrado del clúster clonado. La cuenta de AWS que compartió el clúster con
usted debe también compartir la clave de KMS utilizada para cifrar el clúster. Puede utilizar la misma
clave para cifrar el clon o su propia clave maestra de cliente (CMK). No puede crear un clon entre
cuentas de un clúster que esté cifrado con la clave RDS predeterminada.
La cuenta que posee la clave de cifrado debe otorgar permiso a la cuenta de destino para utilizar
la clave utilizando una política de claves. Este proceso es similar al utilizado para compartir las
instantáneas cifradas, utilizando una política de claves que otorga permiso a la cuenta de destino para
utilizar la clave.
AWS CLI
Para clonar un clúster de Aurora propiedad de otra cuenta de AWS utilizando la AWS CLI
1. Acepte la invitación de otra cuenta de AWS propiedad del clúster de base de datos, como se ha
mostrado anteriormente.
2. Clone el clúster especificando el ARN completo del clúster de origen en el parámetro source-db-
cluster-identifier del comando restore-db-cluster-to-point-in-time de la CLI de
RDS, como se muestra a continuación.
Si el ARN pasado como el source-db-cluster-identifier no se ha compartido, se devuelve el

mismo error que si no existiera el clúster especificado.

--source-db-cluster-identifier=arn:aws:rds:arn_details \
--db-cluster-identifier=new_cluster_id \

292
--restore-type=copy-on-write \
Para Windows:

--source-db-cluster-identifier=arn:aws:rds:arn_details ^
--db-cluster-identifier=new_cluster_id ^
--restore-type=copy-on-write ^
3. Si el clúster que está clonando está cifrado, cifre su clúster clonado incluyendo un parámetro kms-
key-id. Este valor de kms-key-id puede ser el utilizado para cifrar el clúster de base de datos
original o su propia clave maestra de cliente (CMK). Su cuenta debe tener permiso para utilizar dicha
clave de cifrado.

--source-db-cluster-identifier=arn:aws:rds:arn_details \
--db-cluster-identifier=new_cluster_id \
--restore-type=copy-on-write \
--use-latest-restorable-time \
--kms-key-id=arn:aws:kms:arn_details
Para Windows:

--source-db-cluster-identifier=arn:aws:rds:arn_details ^
--db-cluster-identifier=new_cluster_id ^
--restore-type=copy-on-write ^
--use-latest-restorable-time ^
--kms-key-id=arn:aws:kms:arn_details
utilizar la clave. A continuación se incluye una política de claves.
{
"Id": "key-policy-1",
"Version": "2012-10-17",
"Statement": [
{
"Sid": "Allow use of the key",
"Effect": "Allow",
"Principal": {"AWS": [
"arn:aws:iam::account_id:user/KeyUser",
"arn:aws:iam::account_id:root"
]},
"Action": [
"kms:CreateGrant",
"kms:Encrypt",
"kms:Decrypt",
"kms:ReEncrypt",
"kms:GenerateDataKey*",
293
"kms:DescribeKey"
],
"Resource": "*"
},
{
"Sid": "Allow attachment of persistent resources",
"Effect": "Allow",
]},
"Action": [
"kms:CreateGrant",
"kms:ListGrants",
"kms:RevokeGrant"
],
"Resource": "*",
"Condition": {"Bool": {"kms:GrantIsForAWSResource": true}}
}
]
}
API de RDS
Para clonar un clúster de Aurora propiedad de otra cuenta de AWS utilizando la API de RDS
1. Acepte la invitación de otra cuenta de AWS propiedad del clúster de base de datos, como se ha
mostrado anteriormente.
2. Clone el clúster especificando el ARN completo del clúster de origen en el parámetro
SourceDBClusterIdentifier de la operación RestoreDBClusterToPointInTime de la API de
RDS.
Si el ARN pasado como el SourceDBClusterIdentifier no se ha compartido, se devuelve el

mismo error que se el clúster especificado no exista.
3. Si el clúster que está clonando está cifrado, incluya un parámetro KmsKeyId para cifrar el clúster
clonado. Este valor de kms-key-id puede ser el utilizado para cifrar el clúster de base de datos
original o su propia clave maestra de cliente (CMK). Su cuenta debe tener permiso para utilizar dicha
clave de cifrado.
Al clonar un volumen, la cuenta de destino debe tener permiso para utilizar la clave de cifrado
utilizada para cifrar el clúster de origen. Aurora cifra el nuevo clúster clonado con la clave de cifrado
especificada en KmsKeyId.
utilizar la clave. A continuación se incluye una política de claves.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
]},

294
"Action": [
"kms:CreateGrant",
"kms:Encrypt",
"kms:Decrypt",
"kms:ReEncrypt",
"kms:DescribeKey"
],
"Resource": "*"
},
{
"Effect": "Allow",
]},
"Action": [
"kms:CreateGrant",
"kms:ListGrants",
"kms:RevokeGrant"
],
"Resource": "*",
}
]
}
Comprobar si un clúster de base de datos es un clon entre cuentas

El objeto DBClusters identifica si cada clúster es un clon entre cuentas. Puede ver los clústeres
que tienen permiso para clonar utilizando el la opción include-shared cuando ejecute el comando
describe-db-clusters de la CLI de RDS. Sin embargo, no puede ver la mayoría de los detalles de
configuración de dichos clústeres.
AWS CLI
Para comprobar si un clúster de base de datos es un clon entre cuentas utilizando la AWS CLI
• Llame al comando describe-db-clusters de CLI de RDS.
El siguiente ejemplo muestra cómo los clústeres de base de datos de clonación entre cuentas reales
o potenciales aparece en la salida de describe-db-clusters. Para clústeres existentes propiedad
de su cuenta de AWS, el campo CrossAccountClone indica si el clúster es un clon de un clúster de
base de datos propiedad de otra cuenta de AWS.
En algunos casos, una entrada podría tener un número de cuenta de AWS diferente al suyo en
el campo DBClusterArn. En este caso, dicha entrada representa un clúster propiedad de una
cuenta de AWS diferente y que se puede clonar. Dichas entradas tienen pocos cambios aparte de
DBClusterArn. Al crear el clúster clonado, especifique los mismos valores de StorageEncrypted,
Engine y EngineVersion que el clúster original.
$ aws rds describe-db-clusters --include-shared --region us-east-1

{
"DBClusters": [
{
"EarliestRestorableTime": "2019-05-01T21:17:54.106Z",
"Engine": "aurora",
"EngineVersion": "5.6.10a",
"CrossAccountClone": false,

295
...
},
{
"Engine": "aurora",
"CrossAccountClone": true,
...
},
{
"StorageEncrypted": false,
"DBClusterArn": "arn:aws:rds:us-east-1:12345678:cluster:cluster-abcdefgh",
"Engine": "aurora",
}
]
}
API de RDS
Para comprobar si un clúster de base de datos es un clon entre cuentas utilizando la API de RDS
• Llame a la operación DescribeDBClusters de la API de RDS.
Para clústeres existentes propiedad de su cuenta de AWS, el campo CrossAccountClone indica si

el clúster es un clon de un clúster de base de datos propiedad de otra cuenta de AWS. Las entradas
con un número de cuenta de AWS diferente en el campo DBClusterArn representan clústeres
que puede clonar y que son propiedad de otras cuentas de AWS. Estas entradas tienen pocos
cambios aparte de DBClusterArn. Al crear el clúster clonado, especifique los mismos valores de
StorageEncrypted, Engine y EngineVersion que el clúster original.
El siguiente ejemplo muestra un valor de devolución que demuestra los clústeres clonados tanto
reales como potenciales.
{
"DBClusters": [
{
"Engine": "aurora",
"CrossAccountClone": false,
...
},
{
"Engine": "aurora",
"CrossAccountClone": true,
...
},
{
"DBClusterArn": "arn:aws:rds:us-east-1:12345678:cluster:cluster-abcdefgh",
"Engine": "aurora",
"EngineVersion": "5.6.10a"
}
]
}

296
Integración con los servicios de AWS
Integración de Aurora con otros servicios de AWS

Amazon Aurora se integra con otros servicios de AWS con el fin de permitirle ampliar su clúster de base de
datos Aurora para usar funcionalidades adicionales en la nube de AWS.
Integración con Amazon Aurora MySQL

Amazon Aurora MySQL se integra con otros servicios de AWS con el fin de permitirle ampliar su clúster de
base de datos Aurora MySQL para usar funcionalidades adicionales en la nube de AWS. El clúster de base
de datos de Aurora MySQL puede usar los servicios de AWS para hacer lo siguiente:
• Invoque de forma síncrona o asíncrona una función de AWS Lambda mediante las funciones nativas
lambda_sync o lambda_async. O bien invoque de forma asíncrona una función de AWS Lambda con
el procedimiento mysql.lambda_async.
• Cargar datos desde archivos de texto o XML almacenados en un bucket de Amazon Simple Storage
Service (Amazon S3) en el clúster de base de datos usando el comando LOAD DATA FROM S3 o LOAD
XML FROM S3.
• Guardar datos en archivos de texto almacenados en un bucket de Amazon S3 desde su clúster de base
de datos usando el comando SELECT INTO OUTFILE S3.
• Añada o quite de forma automática réplicas de Aurora con Auto Scaling de aplicaciones. Para obtener
más información, consulte Uso de Auto Scaling de Amazon Aurora con réplicas de Aurora (p. 297).
Para obtener más información acerca de la integración de Aurora MySQL con otros servicios de AWS,
consulte Integración de Amazon Aurora MySQL con otros servicios de AWS (p. 629).
Integración con Amazon Aurora PostgreSQL

Amazon Aurora PostgreSQL se integra con otros servicios de AWS con el fin de permitirle ampliar su
clúster de base de datos Aurora PostgreSQL para usar funcionalidades adicionales en la nube de AWS. El
clúster de base de datos de Aurora PostgreSQL puede usar los servicios de AWS para hacer lo siguiente:
• Recopilar, ver y evaluar rápidamente el desempeño en las cargas de trabajo de la base de datos
relacional con Performance Insights.
• Añada o quite de forma automática réplicas de Aurora con Aurora Auto Scaling. Para obtener más
información, consulte Uso de Auto Scaling de Amazon Aurora con réplicas de Aurora (p. 297).
Para obtener más información acerca de la integración de Aurora PostgreSQL con otros servicios de AWS,
consulte Integración de Amazon Aurora PostgreSQL con otros servicios de AWS (p. 802).
Uso de Auto Scaling de Amazon Aurora con réplicas

de Aurora
Para cumplir sus requisitos de conectividad y carga de trabajo, Auto Scaling de Aurora ajusta
dinámicamente el número de réplicas de Aurora aprovisionadas para un clúster de base de datos Aurora.
El Auto Scaling de Aurora está disponible para Aurora MySQL y Aurora PostgreSQL. Auto Scaling
de Aurora permite a su clúster de base de datos Aurora hacer frente a los aumentos repentinos de
conectividad o carga de trabajo. Cuando la conectividad o carga de trabajo disminuye, Auto Scaling de
Aurora quita réplicas de Aurora innecesarias para evitar que tenga que pagar por instancias de base de
datos aprovisionadas que no se utilicen.
Puede definir y aplicar una política de escalado a un clúster de base de datos Aurora. La política de
escalado define el número mínimo y máximo de réplicas de Aurora que Auto Scaling de Aurora puede

297
Uso de Auto Scaling con réplicas de Aurora
administrar. En función de la política, Auto Scaling de Aurora aumenta o reduce el número de réplicas
de Aurora en respuesta a las cargas de trabajo reales, determinadas mediante las métricas de Amazon
CloudWatch y los valores de destino.
Puede usar la Consola de administración de AWS para aplicar una política de escalado en función de una
métrica predefinida. También puede utilizar la API de Auto Scaling de AWS CLI o Aurora para aplicar una
política de escalado basada en una métrica predefinida o personalizada.
Temas
• Antes de empezar (p. 298)
• Políticas de Auto Scaling de Aurora (p. 298)
• Adición de una política de escalado (p. 300)
• Edición de una política de escalado (p. 309)
• Eliminación de una política de escalado (p. 312)
• Temas relacionados (p. 313)
Antes de empezar
Antes de que pueda usar Auto Scaling de Aurora con un clúster de base de datos Aurora, primero debe
crear un clúster de base de datos Aurora con una instancia principal y al menos una réplica de Aurora.
Aunque Auto Scaling de Aurora administra réplicas de Aurora, el clúster de base de datos Aurora debe
comenzar con al menos una réplica de Aurora. Para obtener más información acerca de la creación
de un clúster de base de datos Aurora, consulte Creación de un clúster de base de datos de Amazon
Aurora (p. 85).
Auto Scaling de Aurora solo escala un clúster de base de datos si todas las réplicas de Aurora en un
clúster de base de datos están en un estado disponible. Si alguna de las réplicas de Aurora está en otro
estado distinto de disponible, Auto Scaling de Aurora espera hasta que todo el clúster de base de datos
esté disponible para el escalado.
Cuando Auto Scaling de Aurora añade una nueva réplica de Aurora, la nueva réplica de Aurora es la
misma clase de instancia de base de datos que la usada por la instancia principal. Para obtener más
información acerca de las clases de instancias de bases de datos, consulte Selección de la clase de
instancia de base de datos (p. 61). Además, la capa de promoción para las nuevas réplicas de Aurora
se establecen en la última prioridad, que es 15 de forma predeterminada. Eso significa que durante
una conmutación por error, una réplica con una mejor prioridad, como una creada manualmente, se
promocionaría primero. Para obtener más información, consulte Tolerancia a errores para un clúster de
base de datos de Aurora (p. 314).
Auto Scaling de Aurora solo quita las réplicas de Aurora que ha creado.
Para poder beneficiarse de Auto Scaling de Aurora, sus aplicaciones deben admitir conexiones a nuevas
réplicas de Aurora. Y para hacerlo, recomendamos que utilice el punto de enlace de lector de Aurora.
Para Aurora MySQL puede usar un controlador como la utilidad MariaDB Connector/J. Para obtener más
información, consulte Conexión a un clúster de base de datos Amazon Aurora (p. 148).
Políticas de Auto Scaling de Aurora

Auto Scaling de Aurora usa una política de escalado para ajustar el número de réplicas de Aurora en un
clúster de base de datos Aurora. Auto Scaling de Aurora tiene los siguientes componentes:
• Una función vinculada a un servicio

• Una métrica de destino
• Capacidad mínima y máxima
• Un periodo de recuperación

298
Función vinculada a un servicio

Auto Scaling de Aurora usa el rol vinculado a un servicio
AWSServiceRoleForApplicationAutoScaling_RDSCluster. Para obtener más información,
consulte el tema relacionado con los roles vinculados a servicios de Auto Scaling de aplicaciones en la
referencia de la API de Auto Scaling de aplicaciones.
Métrica de destino
En este tipo de política, una métrica predefinida o personalizada y un valor de destino de la métrica
se especifica en una configuración de la política de escalado de seguimiento de destino. Auto Scaling
de Aurora crea y administra las alarmas de CloudWatch que desencadenan la política de escalado y
calcula el ajuste de escalado en función de la métrica y el valor objetivo. La política de escalado amplía o
reduce las réplicas de Aurora en función de las necesidades para mantener la métrica en el valor objetivo
especificado o en un valor próximo. Además de mantener la métrica próxima al valor de destino, la política
de escalado de seguimiento de destino también se ajusta a las fluctuaciones de la métrica producidas por
una carga de trabajo en constante cambio. Esta política también minimiza las fluctuaciones rápidas del
número de réplicas de Aurora disponibles de su clúster de base de datos.
Por ejemplo, adopte una política de escalado que use la métrica de utilización de la CPU media
predefinida. Esta política puede mantener la utilización de la CPU en el porcentaje de utilización
especificado o en un valor próximo, como el 40 por ciento.
Note
Para cada clúster de base de datos Aurora, puede crear solo una política de Auto Scaling para
cada métrica de destino.
Capacidad mínima y máxima

Puede especificar el número máximo de réplicas de Aurora que Auto Scaling de aplicaciones va a
administrar. Este valor debe establecerse en 0–15 y debe ser igual o superior al valor especificado para el
número mínimo de réplicas de Aurora.
También puede especificar el número mínimo de réplicas de Aurora que Auto Scaling de aplicaciones va
a administrar. Este valor debe establecerse en 0–15 y debe ser igual o inferior al valor especificado para el
número máximo de réplicas de Aurora.
Note
La capacidad mínima y máxima se establece para un clúster de base de datos Aurora. Los
valores especificados se aplican a todas las políticas asociadas al clúster de base de datos
Aurora.
Periodo de recuperación
Puede ajustar la capacidad de respuesta de una política de escalado de seguimiento de destino añadiendo
periodos de recuperación que afecten a la ampliación o reducción de su clúster de base de datos Aurora.
Un periodo de recuperación bloquea solicitudes de escalado descendente o ascendente posteriores hasta
que vence el periodo. Estos bloques ralentizan las eliminaciones de réplicas de Aurora en su clúster de
base de datos Aurora para solicitudes de escalado descendente y la creación de réplicas de Aurora para
solicitudes de escalado ascendente.
Puede especificar los siguientes periodos de recuperación:
• Una actividad de escalado descendente reduce el número de réplicas de Aurora en su clúster de base
de datos Aurora. Un periodo de recuperación de escalado descendente especifica la cantidad de tiempo,
en segundos, tras completarse una actividad de escalado descendente antes de que pueda comenzar
otra actividad de escalado descendente.

299
• Una actividad de escalado ascendente incrementa el número de réplicas de Aurora en su clúster de

base de datos Aurora. Un periodo de recuperación de escalado ascendente especifica la cantidad de
tiempo, en segundos, tras completarse una actividad de escalado ascendente antes de que pueda
comenzar otra actividad de escalado ascendente.
Si no se especifica un periodo de recuperación de escalado descendente o ascendente, el valor

predeterminado de cada uno es de 300 segundos.
Habilitar o deshabilitar actividades de escalado descendente

Puede habilitar o deshabilitar actividades de escalado descendente para una política. La habilitación de
actividades de escalado descendente permite a la política de escalado eliminar réplicas de Aurora. Al
habilitarse actividades de escalado descendente, el periodo de recuperación de escalado descendente
de la política de escalado se aplica a las actividades de escalado descendente. La deshabilitación de
actividades de escalado descendente impide a la política de escalado eliminar réplicas de Aurora.
Note
Las actividades de escalado ascendente siempre se habilitan de modo que la política de escalado
pueda crear réplicas de Aurora según sea necesario.
Adición de una política de escalado

Puede añadir una política de escalado utilizando la Consola de administración de AWS, la AWS CLI o la
API de Auto Scaling de aplicaciones.
Temas
• Adición de una política de escalado mediante la Consola de administración de AWS (p. 300)
• Adición de una política de escalado utilizando la AWS CLI o la API de Auto Scaling de
aplicaciones (p. 303)
Adición de una política de escalado mediante la Consola de administración de

AWS
Puede añadir una política de escalado a un clúster de base de datos Aurora mediante la Consola de
Para añadir una política de Auto Scaling a un clúster de base de datos Aurora
3. Seleccione el clúster de base de datos Aurora para el que desea añadir una política.
4. En Actions (Acciones), elija Add Auto Scaling policy (Agregar política de Auto Scaling).
Aparecerá el cuadro de diálogo Add Auto Scaling policy (Añadir política de Auto Scaling).
5. En Policy name (Nombre de la política), escriba un nombre para la política.
6. Para la métrica de destino, elija una de las siguientes opciones:
• Average CPU utilization of Aurora Replicas (Utilización media de CPU de réplicas de Aurora) para
crear una política basada en el uso medio de la CPU.
• Average connections of Aurora Replicas (Promedio de conexiones de réplicas de Aurora) para crear
una política basada en el número medio de conexiones a réplicas de Aurora.
7. Para el valor de destino, escriba una de las siguientes opciones:

300
• Si eligió Average CPU utilization of Aurora Replicas (Utilización media de CPU de réplicas de
Aurora) en el paso anterior, escriba el porcentaje de utilización de CPU que desea mantener en las
réplicas de Aurora.
• Si eligió Average connections of Aurora Replicas (Promedio de conexiones de réplicas de Aurora)
en el paso anterior, escriba el número de conexiones que desea mantener.
Las réplicas de Aurora se añaden o quitan para mantener la métrica en un valor próximo al
especificado.
8. (Opcional) Abra Additional Configuration (Configuración adicional) para crear un periodo de
recuperación de escalado descendente o ascendente.
9. Para Minimum capacity (Capacidad mínima), escriba el número mínimo de réplicas de Aurora que
debe mantener la política de Auto Scaling de Aurora.
10. Para Maximum capacity (Capacidad máxima), escriba el número máximo de réplicas de Aurora que
debe mantener la política de Auto Scaling de Aurora.
11. Elija Add policy (Agregar política).
El siguiente cuadro de diálogo crea una política de Auto Scaling basada en un uso medio de la CPU del 40
por ciento. En la política se especifica un mínimo de 5 réplicas de Aurora y un máximo de 15 réplicas de
Aurora.

301
El siguiente cuadro de diálogo crea una política de Auto Scaling basada en un número medio de
conexiones de 100. En la política se especifica un mínimo de dos réplicas de Aurora y un máximo de ocho

302
Adición de una política de escalado utilizando la AWS CLI o la API de Auto

Scaling de aplicaciones
Puede aplicar una política de escalado en función de una métrica predefinida o una personalizada. Para
ello, puede usar la AWS CLI o la API de Auto Scaling de aplicaciones. El primer paso consiste en registrar
su clúster de base de datos Aurora con Auto Scaling de aplicaciones.
Registro de un clúster de base de datos Aurora
Antes de que pueda usar Auto Scaling de Aurora con un clúster de base de datos Aurora, puede registrar
su clúster de base de datos Aurora con Auto Scaling de aplicaciones. Esto se hace para definir la

303
dimensión y los límites de escalado que se van a aplicar a ese clúster. Auto Scaling de aplicaciones
escala de forma dinámica el clúster de base de datos Aurora a lo largo de la dimensión escalable
rds:cluster:ReadReplicaCount, que representa el número de réplicas de Aurora.
Para registrar su clúster de base de datos Aurora, puede usar la AWS CLI o la API de Auto Scaling de
aplicaciones.
CLI
Para registrar un clúster de base de datos de Aurora, utilice el comando register-scalable-target

de la AWS CLI con los siguientes parámetros:
• --service-namespace: ajuste este valor en rds.

• --resource-id: identificador de recurso para el clúster de base de datos Aurora. Para este parámetro,
el tipo de recurso es cluster y el identificador único es el nombre del clúster de base de datos Aurora,
por ejemplo cluster:myscalablecluster.
• --scalable-dimension: ajuste este valor en rds:cluster:ReadReplicaCount.
• --min-capacity: el número mínimo de réplicas de Aurora que Auto Scaling de aplicaciones va a
administrar. Este valor debe establecerse en 0–15 y debe ser igual o inferior al valor especificado para
max-capacity.
• --max-capacity: el número máximo de réplicas de Aurora que Auto Scaling de aplicaciones va a
administrar. Este valor debe establecerse en 0–15 y debe ser igual o superior al valor especificado para
min-capacity.
Example
En el siguiente ejemplo, registra un clúster de base de datos Aurora denominado myscalablecluster.

El registro indica que el clúster de base de datos debe escalarse dinámicamente para tener de una a ocho
aws application-autoscaling register-scalable-target \

--service-namespace rds \
--resource-id cluster:myscalablecluster \
--scalable-dimension rds:cluster:ReadReplicaCount \
--min-capacity 1 \
--max-capacity 8 \
Para Windows:
aws application-autoscaling register-scalable-target ^

--service-namespace rds ^
--resource-id cluster:myscalablecluster ^
--scalable-dimension rds:cluster:ReadReplicaCount ^
--min-capacity 1 ^
--max-capacity 8 ^
API
Para registrar un clúster de base de datos de Aurora con Auto Scaling de aplicaciones, use la acción
RegisterScalableTarget de la API de Auto Scaling de aplicaciones con los siguientes parámetros:
• ServiceNamespace: ajuste este valor en rds.

304
• ResourceID: identificador de recurso para el clúster de base de datos Aurora. Para este parámetro, el
tipo de recurso es cluster y el identificador único es el nombre del clúster de base de datos Aurora,
• ScalableDimension: ajuste este valor en rds:cluster:ReadReplicaCount.
• MinCapacity: el número mínimo de réplicas de Aurora que Auto Scaling de aplicaciones va a
administrar. Este valor debe establecerse en 0–15 y debe ser igual o inferior al valor especificado para
MaxCapacity.
• MaxCapacity: el número máximo de réplicas de Aurora que Auto Scaling de aplicaciones va a
administrar. Este valor debe establecerse en 0–15 y debe ser igual o superior al valor especificado para
MinCapacity.
Example
En el siguiente ejemplo, registra un clúster de base de datos Aurora denominado myscalablecluster

con la API de Auto Scaling de aplicaciones. Este registro indica que el clúster de base de datos debe
escalarse dinámicamente para tener de una a ocho réplicas de Aurora.
POST / HTTP/1.1
Host: autoscaling.us-east-2.amazonaws.com
Accept-Encoding: identity
Content-Length: 219
X-Amz-Target: AnyScaleFrontendService.RegisterScalableTarget
X-Amz-Date: 20160506T182145Z
User-Agent: aws-cli/1.10.23 Python/2.7.11 Darwin/15.4.0 botocore/1.4.8
Content-Type: application/x-amz-json-1.1
Authorization: AUTHPARAMS
{
"ServiceNamespace": "rds",
"ResourceId": "cluster:myscalablecluster",
"ScalableDimension": "rds:cluster:ReadReplicaCount",
"MinCapacity": 1,
"MaxCapacity": 8
}
Definición de una política de escalado para un clúster de base de datos Aurora
Una configuración de la política de escalado de seguimiento de destino está representada por un bloque
JSON en el que se definen las métricas y los valores de destino. Puede guardar una configuración de
la política de escalado como bloque JSON en un archivo de texto. Puede usar ese archivo de texto al
invocar la AWS CLI o la API de Auto Scaling de aplicaciones. Para obtener más información acerca de la
sintaxis de configuración de la política, consulte TargetTrackingScalingPolicyConfiguration en
la referencia de la API de Auto Scaling de aplicaciones.
Las siguientes opciones están disponibles para definir una configuración de la política de escalado de
seguimiento de destino.
Temas
• Uso de una métrica predefinida (p. 306)
• Uso de una métrica personalizada (p. 306)
• Uso de periodos de recuperación (p. 307)
• Deshabilitación de actividad de escalado descendente (p. 307)

305
Uso de una métrica predefinida
Mediante las métricas predefinidas, puede definir rápidamente una política de escalado de seguimiento
de destino para un clúster de base de datos Aurora que funciona bien tanto con el seguimiento de destino
como con el escalado dinámico en Auto Scaling de Aurora.
Actualmente, Aurora admite las siguientes métricas predefinidas en Auto Scaling de Aurora:
• RDSReaderAverageCPUUtilization: el valor medio de la métrica de CPUUtilization en CloudWatch

en todas las réplicas de Aurora del clúster de base de datos Aurora.
• RDSReaderAverageDatabaseConnections: el valor medio de la métrica de DatabaseConnections en
CloudWatch en todas las réplicas de Aurora del clúster de base de datos Aurora.
Para obtener más información sobre las métricas de CPUUtilization y DatabaseConnections,

consulte Métricas de Amazon Aurora (p. 384).
Para usar una métrica predefinida en su política de escalado, puede crear una configuración
de seguimiento de destino para su política de escalado. Esta configuración debe incluir
PredefinedMetricSpecification para la métrica predefinida y TargetValue para el valor de
destino de esa métrica.
Example
En el siguiente ejemplo se describe una configuración de la política típica para el escalado de seguimiento
de destino de un clúster de base de datos Aurora. En esta configuración, la métrica predefinida
RDSReaderAverageCPUUtilization se usa para ajustar el clúster de base de datos Aurora en función
del uso medio de la CPU del 40 por ciento en todas las réplicas de Aurora.
{
"TargetValue": 40.0,
"PredefinedMetricSpecification":
{
"PredefinedMetricType": "RDSReaderAverageCPUUtilization"
}
}
Uso de una métrica personalizada
Mediante las métricas personalizadas, puede definir una política de escalado de seguimiento de destino
que cumpla sus requisitos personalizados. Puede definir una métrica personalizada en función de
cualquier métrica de Aurora que cambie en proporción al escalado.
No todas las métricas de Aurora funcionan para el seguimiento de destino. La métrica debe ser una
métrica de utilización válida y describir el nivel de actividad de una instancia. El valor de la métrica debe
aumentar o reducirse en proporción al número de réplicas de Aurora del clúster de base de datos Aurora.
Este aumento o reducción proporcionales son necesarios para usar los datos de las métricas a fin de
ampliar o reducir proporcionalmente el número de réplicas de Aurora.
Example
En el siguiente ejemplo se describe una configuración de seguimiento de destino para una política de
escalado. En esta configuración, una métrica personalizada ajusta un clúster de base de datos Aurora
en función de un uso medio de la CPU del 50 % en todas las réplicas de Aurora de un clúster de base de
datos Aurora denominado my-db-cluster.
{
"TargetValue": 50,
"CustomizedMetricSpecification":

306
{
"MetricName": "CPUUtilization",
"Namespace": "AWS/RDS",
"Dimensions": [
{"Name": "DBClusterIdentifier","Value": "my-db-cluster"},
{"Name": "Role","Value": "READER"}
],
"Statistic": "Average",
"Unit": "Percent"
}
}
Uso de periodos de recuperación

Puede especificar un valor, en segundos, a fin de que ScaleOutCooldown añada un periodo
de recuperación para el escalado ascendente de su clúster de base de datos Aurora. De forma
similar, puede añadir un valor, en segundos, a fin de que ScaleInCooldown añada un periodo
de recuperación para el escalado descendente de su clúster de base de datos Aurora. Para
obtener más información acerca de ScaleInCooldown y ScaleOutCooldown, consulte
TargetTrackingScalingPolicyConfiguration en la referencia de la API de Auto Scaling de
aplicaciones.
Example
escalado. En esta configuración, la métrica predefinida RDSReaderAverageCPUUtilization se usa
para ajustar un clúster de base de datos Aurora en función del uso medio de la CPU del 40 % en todas
las réplicas de Aurora de ese clúster de base de datos Aurora. La configuración proporciona un periodo
de recuperación de escalado descendente de 10 minutos y un periodo de recuperación de escalado
ascendente de 5 minutos.
{
{
},
"ScaleInCooldown": 600,
"ScaleOutCooldown": 300
}
Deshabilitación de actividad de escalado descendente

Puede evitar que la configuración de la política de escalado de seguimiento de destino escale de forma
descendente su clúster de base de datos Aurora deshabilitando la actividad de escalado descendente. La
deshabilitación de la actividad de escalado descendente evita que la política de escalado elimine réplicas
de Aurora, a la vez que permite a la política de escalado crearlas según sea necesario.
Puede especificar un valor booleano para que DisableScaleIn habilite o deshabilite la actividad de
escalado descendente para su clúster de base de datos Aurora. Para obtener más información acerca de
DisableScaleIn, consulte TargetTrackingScalingPolicyConfiguration en la referencia de la
Example
escalado. En esta configuración, la métrica predefinida RDSReaderAverageCPUUtilization ajusta
un clúster de base de datos Aurora en función del uso medio de la CPU del 40 % en todas las réplicas
de Aurora de ese clúster de base de datos Aurora. La configuración deshabilita la actividad de escalado
descendente para la política de escalado.

307
{
{
},
"DisableScaleIn": true
}
Aplicación de una política de escalado a un clúster de base de datos Aurora
Tras registrar su clúster de base de datos Aurora con Auto Scaling de aplicaciones y definir una política
de escalado, puede aplicar esta al clúster de base de datos Aurora registrado. Para aplicar una política
de escalado a un clúster de base de datos Aurora, puede usar la AWS CLI o la API de Auto Scaling de
aplicaciones.
CLI
Para aplicar una política de escalado a un clúster de base de datos de Aurora, use el comando put-
scaling-policy de la AWS CLI con los siguientes parámetros:
• --policy-name: el nombre de la política de escalado.

• --policy-type: ajuste este valor en TargetTrackingScaling.
• --target-tracking-scaling-policy-configuration: configuración de la política de escalado
de seguimiento de destino que se usará para el clúster de base de datos Aurora.
Example
En el siguiente ejemplo, aplica una política de escalado de seguimiento de destino denominada

myscalablepolicy a un clúster de base de datos Aurora llamado myscalablecluster con Auto
Scaling de aplicaciones. Para ello, puede usar una configuración de la política guardada en un archivo
denominado config.json.
aws application-autoscaling put-scaling-policy \

--policy-name myscalablepolicy \
--policy-type TargetTrackingScaling \
--target-tracking-scaling-policy-configuration file://config.json
Para Windows:
aws application-autoscaling put-scaling-policy ^

--policy-name myscalablepolicy ^
--policy-type TargetTrackingScaling ^

308
--target-tracking-scaling-policy-configuration file://config.json
API
Para aplicar una política de escalado a un clúster de base de datos de Aurora con la API de Auto Scaling
de aplicaciones, utilice la acción PutScalingPolicy de la API de Auto Scaling de aplicaciones con los
• PolicyName: el nombre de la política de escalado.

• PolicyType: ajuste este valor en TargetTrackingScaling.
• TargetTrackingScalingPolicyConfiguration: configuración de la política de escalado de
seguimiento de destino que se usará para el clúster de base de datos Aurora.
Example
En el siguiente ejemplo, aplica una política de escalado de seguimiento de destino denominada

myscalablepolicy a un clúster de base de datos Aurora llamado myscalablecluster con Auto
Scaling de aplicaciones. Puede usar una configuración de la política en función de la métrica predefinida
RDSReaderAverageCPUUtilization.
POST / HTTP/1.1
Content-Length: 219
X-Amz-Target: AnyScaleFrontendService.PutScalingPolicy
X-Amz-Date: 20160506T182145Z
{
"PolicyName": "myscalablepolicy",
"ScalableDimension": "rds:cluster:ReadReplicaCount",
"PolicyType": "TargetTrackingScaling",
"TargetTrackingScalingPolicyConfiguration": {
{
}
}
}
Edición de una política de escalado

Puede editar una política de escalado utilizando la Consola de administración de AWS, la AWS CLI o la

309
Edición de una política de escalado mediante la Consola de administración de

AWS
Puede editar una política de escalado mediante la Consola de administración de AWS.
Para editar una política de Auto Scaling para un clúster de base de datos Aurora
3. Elija el clúster de base de datos Aurora cuya política de Auto Scaling desea editar para mostrar los
detalles del clúster de base de datos.
4. En la sección Auto Scaling Policies (Políticas de Auto Scaling), elija la política de Auto Scaling y, a
continuación, Edit (Editar).
5. Realice cambios en la política.
6. Seleccione Save.
A continuación, se muestra un cuadro de diálogo Edit Auto Scaling policy (Editar política de Auto Scaling)
de ejemplo.

310
Edición de una política de escalado utilizando la AWS CLI o la API de Auto

Puede usar la AWS CLI o la API de Auto Scaling de aplicaciones para editar una política de escalado de la
misma forma que aplica una política de escalado:

311
• Al usar la AWS CLI, especifique el nombre de la política que desea editar en el parámetro --policy-
name. Especifique nuevos valores para los parámetros que desea cambiar.
• Al usar la API de Auto Scaling de aplicaciones, especifique el nombre de la política que desea editar en
el parámetro PolicyName. Especifique nuevos valores para los parámetros que desea cambiar.
Para obtener más información, consulte Aplicación de una política de escalado a un clúster de base de
datos Aurora (p. 308).
Eliminación de una política de escalado

Puede eliminar una política de escalado utilizando la Consola de administración de AWS, la AWS CLI o la
Eliminación de una política de escalado mediante la Consola de administración de

AWS
Puede eliminar una política de escalado mediante la Consola de administración de AWS.
Para eliminar una política de Auto Scaling para un clúster de base de datos Aurora
3. Elija el clúster de base de datos Aurora con la política de escalado que desea eliminar.
4. En la sección Auto Scaling Policies (Políticas de escalado automático), elija la política de Auto Scaling
y, a continuación, Delete (Eliminar).
Eliminación de una política de escalado utilizando la AWS CLI o la API de Auto

Puede usar la AWS CLI o la API de Auto Scaling de aplicaciones para eliminar una política de escalado de
un clúster de base de datos Aurora.
CLI
Para eliminar una política de escalado de su clúster de base de datos Aurora, use el comando delete-
scaling-policy de la AWS CLI con los siguientes parámetros:
• --policy-name: el nombre de la política de escalado.

Example
En el siguiente ejemplo, elimina una política de escalado de seguimiento de destino denominada

myscalablepolicy de un clúster de base de datos Aurora llamado myscalablecluster.

312
aws application-autoscaling delete-scaling-policy \

--policy-name myscalablepolicy \
Para Windows:
aws application-autoscaling delete-scaling-policy ^

--policy-name myscalablepolicy ^
API
Para eliminar una política de escalado de su clúster de base de datos Aurora, use la acción
DeleteScalingPolicy de la API de Auto Scaling de aplicaciones con los siguientes parámetros:
• PolicyName: el nombre de la política de escalado.

Example
En el siguiente ejemplo, elimina una política de escalado de seguimiento de destino denominada

myscalablepolicy de un clúster de base de datos Aurora llamado myscalablecluster con la API de
Auto Scaling de aplicaciones.
POST / HTTP/1.1
Content-Length: 219
X-Amz-Target: AnyScaleFrontendService.DeleteScalingPolicy
X-Amz-Date: 20160506T182145Z
{
"PolicyName": "myscalablepolicy",
"ScalableDimension": "rds:cluster:ReadReplicaCount"
}
Temas relacionados

313
Temas relacionados
• Administración de un clúster de base de datos de Amazon Aurora (p. 232)
Temas relacionados
Backup y restauración de un clúster de base de

datos de Amazon Aurora
En esta sección se muestra cómo crear copias de seguridad y restauraciones de clústeres de base de
datos de Amazon Aurora.
Temas
• Información general de copias de seguridad y restauración de un clúster de base de datos
Aurora (p. 314)
• Descripción del uso de almacenamiento de copias de seguridad en Aurora (p. 316)
• Creación de una instantánea de clúster de base de datos (p. 317)
• Restauración de una instantánea de clúster de base de datos (p. 319)
• Copia de una instantánea (p. 321)
• Compartir una instantánea de clúster de base de datos (p. 332)
• Restauración de un clúster de base de datos a un momento especificado (p. 338)
• Eliminación de una instantánea (p. 339)
Información general de copias de seguridad y

restauración de un clúster de base de datos Aurora
En las secciones siguientes encontrará información sobre las copias de seguridad de Aurora y cómo
restaurar el clúster de base de datos Aurora usando la Consola de administración de AWS.
Tolerancia a errores para un clúster de base de datos de Aurora

Un clúster de base de datos de Aurora ofrece tolerancia a errores por diseño. El volumen de clúster abarca
varias zonas de disponibilidad en una sola región de AWS, de modo que cada zona de disponibilidad
contiene una copia de los datos del volumen de clúster. Esta funcionalidad significa que el clúster de
base de datos puede tolerar un error de una zona de disponibilidad sin perder datos y con tan solo una
interrupción breve del servicio.
Si se produce un error en la instancia principal de un clúster de base de datos, Aurora conmuta

automáticamente a una nueva instancia principal de una de las dos formas siguientes:
• Promoviendo una réplica de Aurora ya existente a nueva instancia principal

• Creando una nueva instancia principal
Si el clúster de base de datos tiene una o varias réplicas de Aurora, se promueve una réplica de Aurora a
instancia principal durante un evento de error. Un evento de error provoca una interrupción breve durante
la cual las operaciones de lectura y escritura generan errores con una excepción. Sin embargo, el servicio
se suele restaurar en menos de 120 segundos y, en muchos casos, en menos de 60 segundos. Para

314
Información general de copias de seguridad y restauración
aumentar la disponibilidad de su clúster de base de datos, es recomendable que cree al menos una o
varias réplicas de Aurora en dos o más zonas de disponibilidad diferentes.
Puede personalizar el orden en que se promueven las réplicas de Aurora a instancia principal tras un
error mediante la asignación de una prioridad a cada réplica. Las prioridades van desde 0 para la primera
propiedad hasta 15 para la última. Si la instancia principal experimenta un error, Amazon RDS promueve la
réplica de Aurora con la mejor prioridad a la nueva instancia principal. Puede modificar la prioridad de una
réplica de Aurora en cualquier momento. Al modificar la prioridad, no se activa una conmutación por error.
Puede haber más de una réplica de Aurora con la misma prioridad, lo que genera niveles de promoción. Si
dos o más réplicas de Aurora comparten la misma prioridad, Amazon RDS promueve la réplica que tiene
un tamaño mayor. Si dos o más réplicas de Aurora tienen la misma prioridad y el mismo tamaño, Amazon
RDS promueve una réplica arbitraria del mismo nivel de promoción.
Si el clúster de base de datos no contiene ninguna réplica de Aurora, la instancia principal se vuelve
a crear durante un evento de error. Un evento de error provoca una interrupción durante la cual las
operaciones de lectura y escritura generan errores con una excepción. El servicio se restaura cuando se
crea la nueva instancia principal, un proceso que normalmente dura menos de 10 minutos. Promover una
réplica de Aurora a instancia principal es mucho más rápido que crear una nueva instancia principal.
Note
Amazon Aurora también admite la replicación con una base de datos de MySQL externa o una
instancia de base de datos de RDS MySQL. Para obtener más información, consulte Replicación
entre Aurora y MySQL o entre Aurora y otro clúster de base de datos Aurora (p. 610).
Copias de seguridad
Aurora crea copias de seguridad del volumen de clúster automáticamente y conserva los datos de
restauración durante el tiempo asignado al periodo de retención de copia de seguridad. Las copias de
seguridad de Aurora son continuas e incrementales para que se pueda restaurar con rapidez a cualquier
punto durante el periodo de retención de copia de seguridad. No se produce ningún impacto en el
desempeño ni ninguna interrupción del servicio de base de datos durante la escritura de los datos de copia
de seguridad. Puede especificar un periodo de retención de copia de seguridad de 1 a 35 días cuando cree
o modifique un clúster de base de datos.
Si desea conservar una copia de seguridad más allá del periodo de retención de copia de seguridad,
también puede crear un snapshot de los datos del volumen de clúster. Como Aurora conserva datos de
restauración incrementales durante todo el periodo de retención de copia de seguridad, solo tiene que
crear un snapshot para los datos que desee conservar más allá del periodo de retención de copia de
seguridad. Puede crear un nuevo clúster de base de datos a partir del snapshot.
Note
• Para todos los clústeres de base de datos de Amazon Aurora, el periodo de retención de copia
de seguridad predeterminado es de un día con independencia del procedimiento empleado para
crear el clúster.
• No es posible deshabilitar los backups automatizados en Aurora. El clúster de base de datos
administra el período de retención de copia de seguridad para Aurora.
Los costos de almacenamiento de copias de seguridad dependen de la cantidad de datos de copia de

seguridad e instantáneas de Aurora y de cuánto tiempo los conserve. Para obtener más información
sobre el almacenamiento asociado con las copias de seguridad y las instantáneas de Aurora, consulte
Descripción del uso de almacenamiento de copias de seguridad en Aurora (p. 316). Para obtener
información sobre los precios del almacenamiento de copias de seguridad de Aurora, consulte Precios de
Amazon RDS para Aurora. Después de que un clúster de Aurora asociado con una instantánea se borre,
el almacenamiento de esa instantánea incurre en los costos de almacenamiento de copias de seguridad
estándares de Aurora.

315
Almacenamiento de copia de seguridad
Restauración de datos
Puede recuperar sus datos creando un nuevo clúster de base de datos Aurora a partir de los datos de
copias de seguridad conservados por Aurora; o de una instantánea de clúster de base de datos que haya
guardado. Puede restaurar rápidamente una nueva copia del clúster de base de datos creada a partir de
los datos de backup de cualquier momento dado durante el periodo de retención de copia de seguridad. La
naturaleza continua e incremental de los backups de Aurora durante el periodo de retención de copia de
seguridad implica que no es necesario realizar instantáneas de los datos con demasiada frecuencia para
mejorar los tiempos de restauración.
Para determinar el primer o el último momento para el que se puede restaurar una instancia de base de
datos, busque los valores Latest Restorable Time o Earliest Restorable Time en la consola
de RDS. Para obtener más información acerca de cómo ver estos valores, consulte Visualización de un
clúster de base de datos de Amazon Aurora (p. 375). El último momento que se puede restaurar para un
clúster de base de datos es el punto más reciente en el que se puede restaurar dicho clúster, normalmente
en los cinco minutos previos a la hora actual. El momento más antiguo que se puede restaurar especifica
el primer momento del periodo de retención de copia de seguridad para el que se puede restaurar el
volumen del clúster.
Puede determinar cuándo se ha completado la restauración de un clúster de base de datos comprobando

los valores Latest Restorable Time y Earliest Restorable Time. Los valores Latest
Restorable Time y Earliest Restorable Time devolverán NULL hasta que la operación de
restauración se haya completado. No puede solicitar una operación de backup o restauración si Latest
Restorable Time o Earliest Restorable Time devuelven el valor NULL.
Para obtener más información acerca la restauración de un clúster de base de datos a un momento
especificado, consulte Restauración de un clúster de base de datos a un momento especificado (p. 338).
Clonación de base de datos para Aurora

También puede utilizar la clonación de bases de datos para clonar las bases de datos de su clúster de
base de datos e Aurora en un nuevo clúster de base de datos, en lugar de restaurar una instantánea de
clúster de base de datos. Las bases de datos clonadas usan un espacio adicional mínimo cuando se crean
inicialmente. Los datos se copian solo como cambios de datos, o bien en la bases de datos de origen o en
las bases de datos clonadas. Puede crear varios clones desde el mismo clúster de base de datos o crear
clones adicionales incluso desde otros clones. Para obtener más información, consulte Clonación de bases
de datos en un clúster de bases de datos de Aurora (p. 282).
Backtrack
Aurora MySQL ahora admite "rebobinar" un clúster de base de datos a un momento específico, sin
restaurar datos desde una copia de seguridad. Para obtener más información, consulte Búsqueda de datos
anteriores de un clúster de base de datos de Aurora (p. 546).
Descripción del uso de almacenamiento de copias de

seguridad en Aurora
Aurora almacena copias de seguridad continuas (durante el periodo de retención de copias de seguridad)
e instantáneas en el almacenamiento de copias de seguridad de Aurora. Para controlar el uso de
almacenamiento de copias de seguridad, puede reducir el intervalo de retención de copia de seguridad,
eliminar las instantáneas manuales anteriores cuando ya no las necesite o ambas cosas. Para obtener
información general sobre las copias de seguridad de Aurora, consulte Copias de seguridad (p. 315).
Para obtener información sobre los precios del almacenamiento de copias de seguridad de Aurora,
consulte la página web de Precios de Amazon Aurora.
Para controlar los costos, puede monitorizar la cantidad de almacenamiento consumido por las copias
de seguridad continuas y las instantáneas manuales que persistan más allá del periodo de retención. A

316
Creación de una instantánea de clúster de base de datos
continuación, puede reducir el intervalo de retención de copia de seguridad y eliminar las instantáneas
manuales cuando ya no las necesite.
Puede utilizar las métricas de Amazon CloudWatch TotalBackupStorageBilled,

SnapshotStorageUsed y BackupRetentionPeriodStorageUsed para revisar y monitorizar la
cantidad de almacenamiento utilizado por sus copias de seguridad de Aurora, tal y como se indica a
continuación:
• BackupRetentionPeriodStorageUsed representa la cantidad de almacenamiento de copias de

seguridad, en gibibytes, utilizado para almacenar copias de seguridad continuas en el momento actual.
Este valor depende del tamaño del volumen del clúster y de la cantidad de cambios que realice durante
el periodo de retención. Sin embargo, a efectos de facturación, no supera el tamaño del volumen del
clúster acumulado durante el periodo de retención. Por ejemplo, si el tamaño del clúster es de 100 GiB
y el periodo de retención es de dos días, el valor máximo de BackRetentionPeriodStorageUsed es
200 (100 GiB + 100 GiB).
• SnapshotStorageUsed representa la cantidad de almacenamiento de copias de seguridad utilizado,
en gibibytes, para almacenar instantáneas manuales más allá del periodo de retención de copia
de seguridad. Las instantáneas manuales realizadas en el periodo de retención no cuentan para el
almacenamiento de copias de seguridad. Todas las instantáneas automáticas tampoco cuentan para el
almacenamiento de copias de seguridad. El tamaño de cada instantánea es el tamaño del volumen del
clúster en el momento en que se realiza la instantánea. El valor de SnapshotStorageUsed depende
del número de instantáneas que mantiene y del tamaño de cada instantánea. Suponga, por ejemplo, que
tiene una instantánea fuera del periodo de retención y que el volumen de clúster tenía un tamaño de 100
GiB cuando se realizó la instantánea. La cantidad de SnapshotStorageUsed es 100.
• TotalBackupStorageBilled representa la suma, en gibibytes, de
BackupRetentionPeriodStorageUsed y SnapshotStorageUsed, menos una cantidad de
almacenamiento gratuito de copias de seguridad equivalente al tamaño del volumen de un clúster de un
día. Por ejemplo, si el tamaño de la base de datos es de 100 GiB, tiene 1 día de retención y tiene una
instantánea fuera del periodo de retención, TotalBackupStorageBilled es 100 (100 GiB +100 GiB -
100 GiB).
• Estas métricas se calculan de forma independiente para cada clúster de base de datos de Aurora.
Puede monitorizar los clústeres de Aurora y crear informes que utilicen las métricas de CloudWatch con la
consola de CloudWatch. Para obtener más información acerca de cómo utilizar métricas de CloudWatch,
consulte Información general sobre la monitorización de Amazon RDS (p. 363) y la tabla de métricas en
Métricas de Amazon RDS (p. 368).
La configuración de búsqueda de datos anteriores para un clúster de base de datos de Aurora no afecta
el volumen de datos de copias de seguridad para ese clúster. Amazon factura el almacenamiento para
datos de búsquedas anteriores por separado. También encontrará la información de precios de búsquedas
anteriores en la página Precios de Amazon Aurora.
Si comparte una instantánea con otro usuario, seguirá siendo el propietario de ella. Los costos de
almacenamiento se aplican al propietario de la instantánea. Si elimina una instantánea compartida de su
propiedad, nadie podrá acceder a ella. Para mantener el acceso a una instantánea compartida propiedad
de otra persona, puede copiar la contraseña. Este procedimiento lo convierte en el propietario de la nueva
contraseña. Los costos de almacenamiento para la instantánea copiada se aplican a su cuenta.
Creación de una instantánea de clúster de base de

datos
Amazon RDS crea una instantánea del volumen de almacenamiento del clúster de base de datos, creando
una copia de seguridad de todo el clúster, y no solo de las bases de datos individuales. Cuando se
crea una instantánea de un clúster de base de datos, se debe identificar la instancia del clúster de base
de datos cuya copia de seguridad se va a realizar y, a continuación, se debe asignar un nombre a la

317
Creación de una instantánea de clúster de base de datos
instantánea del clúster de base de datos para poder restaurarla posteriormente. La cantidad de tiempo
que tarda en crearse una instantánea de clúster de base de datos varía con el tamaño de sus bases de
datos. Dado que la instantánea incluye todo el volumen de almacenamiento, el tamaño de los archivos (por
ejemplo, archivos temporales) también afecta a la cantidad de tiempo que tarda en crearse la instantánea.
Note
Amazon le factura en función de la cantidad de datos de copias de seguridad e instantáneas de

Aurora que conserve y el periodo de tiempo que los conserve. Para obtener más información
sobre el almacenamiento asociado con las copias de seguridad y las instantáneas de Aurora,
consulte Descripción del uso de almacenamiento de copias de seguridad en Aurora (p. 316).
Para obtener más información acerca de los precios de almacenamiento de Aurora, consulte
Precios de Amazon RDS para Aurora.
Puede crear una instantánea de clúster de base de datos usando la Consola de administración de AWS, la
AWS CLI o la API de RDS.
Consola
Para crear una instantánea de clúster de base de datos
3. En la lista de instancias de base de datos, seleccione la instancia principal para el clúster de base de
datos.
4. Elija Instance actions (Acciones de instancias) y, a continuación, Take snapshot (Tomar instantánea).
Aparece la ventana Take DB Snapshot.

5. Escriba el nombre de la instantánea del clúster de base de datos en el cuadro de texto Snapshot
Name (Nombre de instantánea).
6. Elija Take Snapshot (Tomar instantánea).
AWS CLI
Cuando se crea una instantánea de un clúster de base de datos con la AWS CLI, se debe identificar el
clúster de base de datos cuya copia de seguridad se va a realizar y, a continuación, se debe asignar un

318
Restauración de una instantánea
nombre a la instantánea del clúster de base de datos para poder restaurarla posteriormente. Puede hacerlo
utilizando el comando create-db-cluster-snapshot de la AWS CLI con los siguientes parámetros:
• --db-cluster-identifier
• --db-cluster-snapshot-identifier
En este ejemplo, va a crear una instantánea de clúster de base de datos denominada

mydbclustersnapshot para un clúster de base de datos denominado mydbcluster.
Example
aws rds create-db-cluster-snapshot \

--db-cluster-snapshot-identifier mydbclustersnapshot
Para Windows:
aws rds create-db-cluster-snapshot ^

API de RDS
Cuando se crea una instantánea de un clúster de base de datos con la API de Amazon RDS, se debe
identificar el clúster de base de datos cuya copia de seguridad se va a realizar y, a continuación, se debe
asignar un nombre a la instantánea del clúster de base de datos para poder restaurarla posteriormente.
Puede hacerlo utilizando el comando CreateDBClusterSnapshot de la API de Amazon RDS con los
• DBClusterIdentifier
• DBClusterSnapshotIdentifier
Restauración de una instantánea de clúster de base

de datos
Amazon RDS crea una instantánea del volumen de almacenamiento del clúster de base de datos, para lo
que hace una copia de seguridad de toda la instancia de base de datos y no solo de las bases de datos
individuales. Puede crear un clúster de base de datos restaurando a partir de esta instantánea de clúster
de base de datos. Al restaurar el clúster de base de datos, debe indicar el nombre de la instantánea de
clúster de base de datos desde la que se restaura y, a continuación, indicar un nombre para el nuevo
clúster de base de datos que se crea con la restauración. No puede restaurar desde una instantánea de un
clúster de base de datos en un clúster; al restaurar se crea un nuevo clúster de base de datos.
Note
No puede restaurar un clúster de base de datos desde una instantánea de de clúster de base de
datos que esté compartida y cifrada. En lugar de ello, puede hacer una copia de la instantánea de
clúster de base de datos y restaurar el clúster desde la copia.

319
Restauración de una instantánea
Consideraciones relativas al grupo de parámetros

Recomendamos conservar el grupo de parámetros de todas las instantáneas de clúster de base de
datos que cree, para así poder asociar el grupo correcto a el clúster de base de datos restaurada. Puede
especificar el grupo de parámetros al restaurar el clúster de base de datos.
Consideraciones relativas al grupo de seguridad

Al restaurar un clúster de base de datos, el grupo de seguridad predeterminado se asocia a la instancia
restaurada. En cuanto termine la restauración y el nuevo clúster esté disponible, debe asociarle los grupos
de seguridad personalizados que utilizara la instancia desde la que se ha restaurado. Debe aplicar estos
cambios con el comando Modify (Modificar) de la consola de RDS, con la API ModifyDBInstance de
Amazon RDS o con el comando modify-db-instance de la AWS CLI.
Consideraciones de Amazon Aurora

Con Aurora, se restaura una instantánea de clúster de base de datos en un clúster de base de datos.
Con Aurora MySQL, puede restaurar una instantánea de un clúster de base de datos en un clúster de base
de datos de Aurora Serverless. Para obtener más información, consulte Restauración de un clúster de
base de datos de Aurora Serverless (p. 115).
Con Aurora MySQL, puede restaurar una instantánea de clúster de base de datos desde un clúster sin
una consulta paralela a un clúster con consulta paralela. Debido a que la consulta paralela generalmente
se usa con tablas muy grandes, el mecanismo de instantáneas es la forma más rápida de ingerir grandes
volúmenes de datos en un clúster habilitado para consultas paralelas de Aurora MySQL. Para obtener más
información, consulte Trabajar con Consultas en paralelo de Amazon Aurora MySQL (p. 566).
Restauración a partir de una instantánea

Puede restaurar un clúster de base de datos desde una instantánea de clúster de base de datos utilizando
la Consola de administración de AWS, la AWS CLI o la API de RDS.
Para restaurar un clúster de base de datos desde una instantánea de clúster de base de datos
3. Elija la instantánea de clúster de base de datos desde la que desea restaurar.
4. En Actions (Acciones), seleccione Restore Snapshot (Restaurar instantánea).
5. En la página Restore DB Instance (Restaurar instancia de base de datos), en el campo DB Instance
Identifier (Identificador de instancias de bases de datos), escriba el nombre de el clúster de base de
datos restaurada.
6. Elija Restore DB Instance (Restaurar instancia de base de datos).
7. Si desea restaurar la funcionalidad de el clúster de base de datos para que concuerde con la de la
instantánea con la que se creó el clúster, debe modificar el clúster para que use el grupo de seguridad.
Los pasos siguientes presuponen que su clúster de base de datos está en una VPC. Si el clúster de
base de datos no está en una VPC, use la consola de administración de EC2 para encontrar el grupo
de seguridad que necesita para el clúster.
a. Inicie sesión en la Consola de administración de AWS y abra la consola de Amazon VPC en

https://console.aws.amazon.com/vpc/.
b. En el panel de navegación, elija Security Groups.

320
Copia de una instantánea
c. Seleccione el grupo de seguridad que desea usar para los clústeres de base de datos. Si es
necesario, añada reglas para vincular el grupo de seguridad a un grupo de seguridad de una
instancia EC2. Para obtener más información, consulte Acceso a una instancia de base de datos
situada en una VPC desde una instancia EC2 de la misma VPC (p. 218).
CLI
Para restaurar un clúster de base de datos desde una instantánea de clúster de base de datos, use el
comando restore-db-cluster-from-snapshot de la AWS CLI.
En este ejemplo, se restaura desde una instantánea de clúster de base de datos creada previamente
con el nombre mydbclustersnapshot. La restauración se hace en un nuevo clúster de base de datos
denominado mynewdbcluster.
Example

--db-cluster-identifier mynewdbcluster \
--snapshot-identifier mydbclustersnapshot
Para Windows:

--db-instance-identifier mynewdbcluster ^
--db-snapshot-identifier mydbclustersnapshot
Una vez restaurado el clúster de base de datos, debe añadirlo al grupo de seguridad que utilizaba el
clúster de base de datos empleado para crear la instantánea de base de datos si desea tener la misma
funcionalidad del clúster de base de datos anterior.
API
Para restaurar un clúster de base de datos desde una instantánea de clúster de base de datos, use la
función RestoreDBClusterFromSnapshot de la API de Amazon RDS con los parámetros siguientes:
• SnapshotIdentifier

Con Amazon RDS, puede copiar instantáneas de clúster de base de datos automatizadas o manuales.
Después de copiar una instantánea, la copia es una instantánea manual.
Puede copiar una instantánea en la misma región de AWS, entre regiones de AWS y entre cuentas de
AWS.
La copia de una instantánea automatizada en otra cuenta de AWS consta de dos pasos: primero se crea
una instantánea manual a partir de la automatizada y, a continuación, se copia la manual en la otra cuenta.
No puede copiar una instantánea de clúster de base de datos entre regiones y cuentas en un solo paso.
Lleve a cabo un paso para cada una de estas acciones de copia. Como alternativa a la copia, también
puede compartir instantáneas manuales con otras cuentas de AWS. Para obtener más información,
consulte Compartir una instantánea de clúster de base de datos (p. 332).

321
Note
Amazon le factura en función de la cantidad de datos de copias de seguridad e instantáneas de
Aurora que conserve y el periodo de tiempo que los conserve. Para obtener más información
sobre el almacenamiento asociado con las copias de seguridad y las instantáneas de Aurora,
consulte Descripción del uso de almacenamiento de copias de seguridad en Aurora (p. 316).
Para obtener más información acerca de los precios de almacenamiento de Aurora, consulte
Precios de Amazon RDS para Aurora.
Limitaciones
A continuación se indican algunas limitaciones al copiar instantáneas:
• No puede copiar una instantánea en o desde las siguientes regiones de AWS: China (Pekín) o China
(Ningxia).
• Puede copiar una instantánea entre AWS GovCloud (EE.UU. Este) y AWS GovCloud (US-West), pero no
puede copiar una instantánea entre estas regiones de AWS GovCloud (US) y otras regiones de AWS.
• Si elimina una instantánea de origen antes de que la instantánea de destino esté disponible, la copia
de la instantánea puede generar un error. Compruebe que la instantánea de destino tiene el estado
AVAILABLE antes de eliminar una instantánea de origen.
• Puede tener hasta cinco solicitudes de copia de instantánea en curso en una única región de destino por
cuenta.
• Dependiendo de las regiones implicadas y de la cantidad de datos que se vayan a copiar, una copia de
instantánea entre regiones puede tardar horas en completarse. Si hay un gran número de solicitudes de
copia de instantánea entre regiones desde una región de AWS de origen, Amazon RDS puede poner
nuevas solicitudes de copia entre regiones desde esa región de AWS de origen en una cola hasta que
alguna de las copias en curso se complete. No se muestra ninguna información de progreso sobre las
solicitudes de copia mientras están en la cola. La información de progreso se muestra cuando comienza
la copia.
Retención de instantáneas
Amazon RDS elimina las instantáneas automatizadas al final de su periodo de retención, cuando el usuario
desactiva las instantáneas automatizadas para un clúster de base de datos o cuando elimina un clúster de
base de datos. Si desea conservar una instantánea automatizada durante un periodo de tiempo más largo,
cópielo para crear una instantánea manual, que se conservará hasta que lo elimine. Puede haber costos
de almacenamiento de Amazon RDS asociados con las instancias manuales si sobrepasan el espacio de
almacenamiento predeterminado.
Para obtener más información acerca de los costos de almacenamiento de copias de seguridad, consulte
Precios de Amazon RDS.
Copia de instantáneas compartidas

Puede copiar instantáneas compartidas con usted por otras cuentas de AWS. Si va a copiar una
instantánea cifrada que se ha compartido desde otra cuenta de AWS, debe tener acceso a la clave de
cifrado de KMS que se usó para cifrar la instantánea.
Solo puede copiar una instantánea de clúster de base de datos compartidos, cifrada o no, en la
misma región de AWS. Para obtener más información, consulte Cómo compartir una instantánea
cifrada (p. 333).
Tratamiento del cifrado

Puede copiar una instantánea que haya sido cifrada con una clave de cifrado de AWS KMS. Si copia una
instantánea cifrada, la copia de la instantánea se debe cifrar también. Si copia una instantánea cifrada

322
dentro de la misma región de AWS, puede cifrar la copia con la misma clave de cifrado de KMS que la
instantánea original o puede especificar una clave de cifrado de KMS. Si copia una instantánea cifrada
entre regiones, no puede usar para la copia la misma clave de cifrado de KMS que usó para la instantánea
de origen, ya que las claves de KMS son específicas de cada región. En lugar de eso debe especificar una
clave de KMS válida en la región de AWS de destino.
Note
Para instantáneas del clúster de base de datos Amazon Aurora, no es posible cifrar una
instantánea del clúster de base de datos sin cifrar al copiar la instantánea.
Copiar instantáneas en las regiones de AWS

Al copiar una instantánea en una región de AWS que es distinta de la región de AWS de la instantánea
de origen, la primera copia es una copia de la instantánea completa, incluso si copia una instantánea
incremental. Una copia de la instantánea completa contiene todos los datos y metadatos necesarios para
restaurar la instancia de base de datos. Tras la primera copia de la instantánea, puede copiar instantáneas
incrementales de la misma instancia de base de datos en la misma región de destino en la misma cuenta
de AWS.
Una instantánea incremental contiene solo los datos que han cambiado tras la instantánea más reciente
de la misma instancia de base de datos. La copia de instantáneas incrementales es más rápida y genera
un costo de almacenamiento más bajo que la copia de instantáneas completa. La copia de instantáneas
incrementales en las regiones de AWS se admite tanto para las instantáneas sin cifrar como para las
cifradas.
Important
La copia de instantáneas incrementales en varias cuentas de AWS no es compatible. Si configura

copias de instantáneas de una cuenta de AWS a otra cuenta de AWS, todas las copias son
instantáneas completas, incluso dentro de la misma región.
Dependiendo de las regiones de AWS implicadas y de la cantidad de datos que se vayan a copiar, una
copia de instantáneas entre regiones puede tardar horas en completarse. En algunos casos, puede haber
un gran número de solicitudes de copia de instantáneas entre regiones desde una región de AWS de
origen especificada. En estos casos, Amazon RDS puede poner nuevas solicitudes de copia entre regiones
desde esa región de AWS de origen en una cola hasta que alguna de las copias en curso se complete. No
se muestra ninguna información de progreso sobre las solicitudes de copia mientras están en la cola. La
información de progreso se muestra cuando comienza la copia.
Note
Al copiar una instantánea de origen que es una copia de la instantánea, la copia no es

incremental porque la copia de la instantánea no incluye los metadatos que necesitan las copias
incrementales.
Aurora no admite la copia de instantáneas incrementales. Las copias de instantáneas de clúster
de base de datos Aurora siempre son copias completas.
Consideraciones relativas al grupo de parámetros

Cuando se copia una instantánea entre regiones, la copia no incluye el grupo de parámetros empleado por
el clúster de base de datos original. Cuando se restaura una instantánea para crear un nuevo clúster de
base de datos, ese clúster de base de datos usa el grupo de parámetros predeterminado para la región de
AWS en la que se ha creado. Para aplicar en el nuevo clúster de base de datos los mismos parámetros
que en el original, debe hacer lo siguiente:
1. En la región de AWS de destino, cree un grupo de parámetros del clúster de base de datos con la
misma configuración que el clúster de base de datos original. Si ya existe uno en la nueva región de
AWS, puede usarlo.

323
2. Después de restaurar la instantánea en la región de AWS de destino, modifique el nuevo clúster de

base de datos y añada el grupo de parámetros nuevo o ya existente del paso anterior.
Copia de una instantánea de clúster de base de datos

Use los procedimientos de este tema para copiar una instantánea de clúster de base de datos. Si el motor
de base de datos de origen es Aurora, su instantánea es una instantánea de clúster de base de datos.
Para cada cuenta de AWS, puede copiar hasta cinco instantáneas de clúster de base de datos a la vez de
una región de AWS a otra. Puede copiar instantáneas de clúster de base de datos cifradas y sin cifrar. Si
copia una instantánea de clúster de base de datos en otra región de AWS, crea una instantánea de clúster
de base de datos manual que se conserva en esa región de AWS. Al copiar una instantánea de clúster
de base de datos fuera de la región de AWS de origen, se producen cargos por transferencia de datos de
Amazon RDS.
Para obtener más información acerca de los precios de las transferencias de datos, consulte Precios de
Amazon RDS.
Una vez que la copia de la instantánea de clúster de base de datos se ha creado en la nueva región de
AWS, se comporta como los demás instantáneas de clúster de base de datos de esa región de AWS.

Este procedimiento sirve para copiar instantáneas de clúster de base de datos cifradas o sin cifrar, en la
misma región de AWS o entre regiones.
Para cancelar una operación de copia una vez que está en curso, elimine la instantánea del clúster de
base de datos de destino mientras está en el estado copying.
Para copiar una instantánea de clúster de base de datos
3. Active la casilla de verificación de la instantánea del clúster de base de datos que desee copiar.
4. En Actions (Acciones), elija Copy Snapshot (Copiar instantánea). Aparece la página Make Copy of DB
Snapshot.

324
5. (Opcional) Para copiar la instantánea de clúster de base de datos en una región de AWS diferente,
elija esa región en Destination Region (Región de destino).
6. Escriba el nombre de la copia de la instantánea del clúster de base de datos en New DB Snapshot
Identifier (Nuevo identificador de instantánea de base de datos).
7. Para copiar las etiquetas y los valores de la instantánea en la copia de la instantánea, elija Copy Tags.
8. En Enable Encryption, elija una de las siguientes opciones:
• Elija Disable encryption (Deshablitar cifrado) si la instantánea de clúster de base de datos no está
cifrada y no desea cifrar la copia.
• Elija Enable encryption (Habilitar cifrado) si la instantánea de clúster de base de datos no está
cifrada pero desea cifrar la copia. En este caso, en Master Key (Clave maestra), especifique el

325
identificador de la clave de KMS que desea usar para cifrar la copia de la instantánea del clúster de
base de datos.
• Elija Enable encryption (Habilitar cifrado) si la instantánea de clúster de base de datos está cifrada.
En ese caso, debe cifrar la copia, de modo que Yes ya está seleccionado. En Master Key (Clave
maestra), especifique el identificador de la clave de KMS que se debe usar para cifrar la copia de la
instantánea del clúster de base de datos.
9. Elija Copy Snapshot.
Copia de una instantánea de clúster de base de datos sin cifrar con la AWS CLI o
la API de Amazon RDS
Use los procedimientos que se describen en las siguientes secciones para copiar una instantánea de
clúster de base de datos sin cifrar con la AWS CLI o la API de Amazon RDS.
Para cancelar una operación de copia una vez que está en curso, elimine la instantánea del clúster
de base de datos de destino identificado por --target-db-cluster-snapshot-identifier o
TargetDBClusterSnapshotIdentifier mientras está en el estado copying.
CLI
Para copiar una instantánea de clúster de base de datos, utilice el comando copy-db-cluster-
snapshot de la AWS CLI. Si desea copiar la instantánea en otra región de AWS, ejecute el comando en
la región de AWS en la que se va a copiar la instantánea.
Las siguientes opciones se usan para copiar una instantánea de clúster de base de datos sin cifrar:
• --source-db-cluster-snapshot-identifier: identificador de la instantánea del clúster de base

de datos que se va a copiar. Si desea copiar la instantánea en otra región de AWS, este identificador
debe estar en el formato de ARN para la región de AWS de origen.
• --target-db-cluster-snapshot-identifier: identificador de la nueva copia de la instantánea
de clúster de base de datos.
El código siguiente crea una copia de la instantánea del clúster de base de datos arn:aws:rds:us-
east-1:123456789012:cluster-snapshot:aurora-cluster1-snapshot-20130805 llamado
myclustersnapshotcopy en la región de AWS en la que se ejecuta el comando. Cuando se crea la
copia, todas las etiquetas de la instantánea original se copian en la copia de la instantánea.
Example
aws rds copy-db-cluster-snapshot \

--source-db-cluster-snapshot-identifier arn:aws:rds:us-east-1:123456789012:cluster-
snapshot:aurora-cluster1-snapshot-20130805 \
--target-db-cluster-snapshot-identifier myclustersnapshotcopy \
--copy-tags
Para Windows:
aws rds copy-db-cluster-snapshot ^

--source-db-cluster-snapshot-identifier arn:aws:rds:us-east-1:123456789012:cluster-
snapshot:aurora-cluster1-snapshot-20130805 ^
--target-db-cluster-snapshot-identifier myclustersnapshotcopy ^
--copy-tags

326
API
Para copiar una instantánea de clúster de base de datos, utilice la acción CopyDBClusterSnapshot de
la API de Amazon RDS. Si desea copiar la instantánea en otra región de AWS, lleve a cabo la acción en la
región de AWS en la que se va a copiar la instantánea.
Los siguientes parámetros se usan para copiar una instantánea de clúster de base de datos sin cifrar:
• SourceDBClusterSnapshotIdentifier: identificador de la instantánea del clúster de base de datos

que se va a copiar. Si desea copiar la instantánea en otra región de AWS, este identificador debe estar
en el formato de ARN para la región de AWS de origen.
• TargetDBClusterSnapshotIdentifier: identificador de la nueva copia de la instantánea de clúster
de base de datos.
El siguiente código crea una copia de una instantánea arn:aws:rds:us-

east-1:123456789012:cluster-snapshot:aurora-cluster1-snapshot-20130805 llamada
myclustersnapshotcopy en la región us-west-1. Cuando se crea la copia, todas las etiquetas de la
instantánea original se copian en la copia de la instantánea.
Example
?Action=CopyDBClusterSnapshot
&CopyTags=true
&SignatureVersion=4
&SourceDBSnapshotIdentifier=arn%3Aaws%3Ards%3Aus-east-1%3A123456789012%3Acluster-
snapshot%3Aaurora-cluster1-snapshot-20130805
&TargetDBSnapshotIdentifier=myclustersnapshotcopy
&Version=2013-09-09
&X-Amz-Date=20140429T175351Z
&X-Amz-Signature=9164337efa99caf850e874a1cb7ef62f3cea29d0b448b9e0e7c53b288ddffed2
Copia de una instantánea de clúster de base de datos cifrada con la AWS CLI o la
API de Amazon RDS
Use los procedimientos que se describen en las siguientes secciones para copiar una instantánea de
clúster de base de datos cifrada con la AWS CLI o la API de Amazon RDS.
Para cancelar una operación de copia una vez que está en curso, elimine la instantánea del clúster
de base de datos de destino identificado por --target-db-cluster-snapshot-identifier o
TargetDBClusterSnapshotIdentifier mientras está en el estado copying.
CLI
Para copiar una instantánea de clúster de base de datos, utilice el comando copy-db-cluster-
snapshot de la AWS CLI. Si desea copiar la instantánea en otra región de AWS, ejecute el comando en
la región de AWS en la que se va a copiar la instantánea.
Las siguientes opciones se usan para copiar una instantánea de clúster de base de datos cifrada:
• --source-region: si desea copiar la instantánea en otra región de AWS, especifique la región de

AWS desde la que se va a copiar la instantánea de clúster de base de datos cifrada.
Si desea copiar la instantánea en otra región de AWS y no especifica source-region, debe especificar
en su lugar la opción pre-signed-url. El valor de pre-signed-url debe ser una URL que contenga
una solicitud firmada de Signature Version 4 para la acción CopyDBClusterSnapshot que se debe

327
llamar en la región de AWS de origen desde la que se va a copiar la instantánea de clúster de base
de datos. Para obtener más información acerca de pre-signed-url, consulte copy-db-cluster-
snapshot.
• --source-db-cluster-snapshot-identifier: identificador de la instantánea del clúster de
base de datos cifrada que se va a copiar. Si desea copiar la instantánea en otra región de AWS, este
identificador debe estar en el formato de ARN para la región de AWS de origen. En ese caso, la región
de AWS especificada en source-db-cluster-snapshot-identifier debe coincidir con la región
de AWS especificada para --source-region.
• --target-db-cluster-snapshot-identifier: identificador de la nueva copia de la instantánea
de clúster de base de datos cifrada.
• --kms-key-id: identificador de la clave de KMS que se debe usar para cifrar la copia de la instantánea
del clúster de base de datos.
Puede usar esta opción si la instantánea del clúster de base de datos está cifrada, la instantánea se va a
copiar en la misma región de AWS y desea especificar una nueva clave de cifrado de KMS que se usará
para cifrar la copia. De lo contrario, la copia de la instantánea del clúster de base de datos se cifra con la
misma clave de KMS que la instantánea del clúster de base de datos de origen.
Debe usar esta opción si la instantánea del clúster de base de datos está cifrada y va a copiar la
instantánea en otra región de AWS. En ese caso, debe especificar una clave de KMS para la región de
AWS de destino.
El siguiente ejemplo de código copia la instantánea del clúster de base de datos cifrada de la región us-
west-2 en la región us-east-1. Se llama al comando en la región us-east-1.
Example
aws rds copy-db-cluster-snapshot \

--source-db-cluster-snapshot-identifier arn:aws:rds:us-west-2:123456789012:cluster-
snapshot:aurora-cluster1-snapshot-20161115 \
--target-db-cluster-snapshot-identifier myclustersnapshotcopy \
--source-region us-west-2 \
--kms-key-id my-us-east-1-key
Para Windows:
aws rds copy-db-cluster-snapshot ^

--source-db-cluster-snapshot-identifier arn:aws:rds:us-west-2:123456789012:cluster-
snapshot:aurora-cluster1-snapshot-20161115 ^
--target-db-cluster-snapshot-identifier myclustersnapshotcopy ^
--source-region us-west-2 ^
--kms-key-id my-us-east-1-key
API
Para copiar una instantánea de clúster de base de datos, utilice la acción CopyDBClusterSnapshot de
la API de Amazon RDS. Si desea copiar la instantánea en otra región de AWS, lleve a cabo la acción en la
región de AWS en la que se va a copiar la instantánea.
Los siguientes parámetros se usan para copiar una instantánea de clúster de base de datos cifrada:
• SourceDBClusterSnapshotIdentifier: identificador de la instantánea del clúster de base de datos

cifrada que se va a copiar. Si desea copiar la instantánea en otra región de AWS, este identificador debe
estar en el formato de ARN para la región de AWS de origen.

328
• TargetDBClusterSnapshotIdentifier: identificador de la nueva copia de la instantánea de clúster

de base de datos cifrada.
• KmsKeyId: identificador de la clave de KMS que se debe usar para cifrar la copia de la instantánea del
Puede usar este parámetro si la instantánea del clúster de base de datos está cifrada, la instantánea se
va a copiar en la misma región de AWS y desea especificar una nueva clave de cifrado de KMS que se
usará para cifrar la copia. De lo contrario, la copia de la instantánea del clúster de base de datos se cifra
con la misma clave de KMS que la instantánea del clúster de base de datos de origen.
Debe usar este parámetro si la instantánea del clúster de base de datos está cifrada y va a copiar la
instantánea en otra región de AWS. En ese caso, debe especificar una clave de KMS para la región de
AWS de destino.
• PreSignedUrl: si desea copiar la instantánea en otra región de AWS, debe especificar el parámetro
PreSignedUrl. El valor de PreSignedUrl debe ser una URL que contenga una solicitud firmada de
Signature Version 4 para la acción CopyDBClusterSnapshot que se debe llamar en la región de AWS
de origen desde la que se va a copiar la instantánea de clúster de base de datos. Para obtener más
información acerca del uso de una URL prefirmada, consulte CopyDBClusterSnapshot.
Para generar una URL prefirmada de forma automática y no manual, use el comando copy-db-
cluster-snapshot de la AWS CLI con la opción --source-region.
El siguiente ejemplo de código copia la instantánea del clúster de base de datos cifrada de la región us-
west-2 en la región us-east-1. Se llama a la acción en la región us-east-1.
Example
&KmsKeyId=my-us-east-1-key
&PreSignedUrl=https%253A%252F%252Frds.us-west-2.amazonaws.com%252F
%253FAction%253DCopyDBClusterSnapshot
%2526DestinationRegion%253Dus-east-1
%2526KmsKeyId%253Dmy-us-east-1-key
%2526SourceDBClusterSnapshotIdentifier%253Darn%25253Aaws%25253Ards%25253Aus-
west-2%25253A123456789012%25253Acluster-snapshot%25253Aaurora-cluster1-snapshot-20161115
%2526SignatureMethod%253DHmacSHA256
%2526SignatureVersion%253D4
%2526Version%253D2014-10-31
%2526X-Amz-Algorithm%253DAWS4-HMAC-SHA256
%2526X-Amz-Credential%253DAKIADQKE4SARGYLE%252F20161117%252Fus-west-2%252Frds
%252Faws4_request
%2526X-Amz-Date%253D20161117T215409Z
%2526X-Amz-Expires%253D3600
%2526X-Amz-SignedHeaders%253Dcontent-type%253Bhost%253Buser-agent%253Bx-amz-
content-sha256%253Bx-amz-date
%2526X-Amz-Signature
%253D255a0f17b4e717d3b67fad163c3ec26573b882c03a65523522cf890a67fca613
&SignatureVersion=4
&SourceDBClusterSnapshotIdentifier=arn%3Aaws%3Ards%3Aus-
west-2%3A123456789012%3Acluster-snapshot%3Aaurora-cluster1-snapshot-20161115
&TargetDBClusterSnapshotIdentifier=myclustersnapshotcopy
&Version=2014-10-31
&X-Amz-Date=20161117T221704Z
&X-Amz-Signature=da4f2da66739d2e722c85fcfd225dc27bba7e2b8dbea8d8612434378e52adccf

329
Copia de una instantánea de clúster de base de datos entre cuentas

Puede habilitar otras cuentas de AWS para copiar los instantáneas de clúster de base de datos que
especifique usando las acciones ModifyDBClusterSnapshotAttribute y CopyDBClusterSnapshot
de la API de Amazon RDS. Solo puede copiar instantáneas de clúster de base de datos entre cuentas
en la misma región de AWS. El proceso de copia entre cuentas funciona del modo que se describe a
continuación, donde la cuenta A hace que la instantánea esté disponible para la copia y la cuenta B lo
copia.
1. Con la cuenta A, llame a ModifyDBClusterSnapshotAttribute y especifique restore para el

parámetro AttributeName y el ID de la cuenta B para el parámetro ValuesToAdd.
2. (Si la instantánea está cifrada) Con la cuenta A, actualice la política de claves para la clave de KMS.
Para ello, añada primero el ARN de la cuenta B como Principal y a continuación permita la acción
kms:CreateGrant.
3. (Si la instantánea está cifrada) Con la cuenta B, elija o cree un usuario de IAM y asocie a ese usuario
una política de IAM que le permita copiar una instantánea de clúster de base de datos cifrada usando la
clave de KMS.
4. Con la cuenta B, llame a CopyDBClusterSnapshot y use el parámetro
SourceDBClusterSnapshotIdentifier para especificar el ARN de la instantánea del clúster de
base de datos que se va a copiar, que debe incluir el ID de la cuenta A.
Para ver una lista de todas las cuentas de AWS con permiso para restaurar una instantánea de clúster de
base de datos, use la acción DescribeDBSnapshotAttributes o DescribeDBClusterSnapshotAttributes de la
API.
Para eliminar el permiso de uso compartido de una cuenta de AWS, utilice la acción
ModifyDBSnapshotAttribute o ModifyDBClusterSnapshotAttribute con AttributeName
definido como restore y el ID de la cuenta que desea eliminar en el parámetro ValuesToRemove.
Copia de una instantánea de clúster de base de datos sin cifrar en otra cuenta
Use el siguiente procedimiento para copiar una instantánea de clúster de base de datos sin cifrar en otra
cuenta de la misma región de AWS.
1. En la cuenta de origen de la instantánea del clúster de base de datos, llame a

ModifyDBClusterSnapshotAttribute especificando restore para el parámetro
AttributeName y el ID de la cuenta de destino para el parámetro ValuesToAdd.
La ejecución del siguiente ejemplo con la cuenta 987654321 permite que dos identificadores de
cuenta de AWS, 123451234512 y 123456789012, restauren la instantánea de clúster de base de
datos llamada manual-snapshot1.
?Action=ModifyDBClusterSnapshotAttribute
&AttributeName=restore
&DBClusterSnapshotIdentifier=manual-snapshot1
&SignatureMethod=HmacSHA256&SignatureVersion=4
&ValuesToAdd.member.1=123451234512
&Version=2014-10-31
&X-Amz-Date=20150922T220515Z
&X-Amz-Signature=ef38f1ce3dab4e1dbf113d8d2a265c67d17ece1999ffd36be85714ed36dddbb3

330
2. En la cuenta de destino, llame a CopyDBClusterSnapshot y use el parámetro

base de datos que se va a copiar, que debe incluir el ID de la cuenta de origen.
La ejecución del siguiente ejemplo con la cuenta 123451234512 copia la instantánea del clúster
de base de datos aurora-cluster1-snapshot-20130805 de la cuenta 987654321 y crea una
instantánea de clúster de base de datos llamado dbclustersnapshot1.
&CopyTags=true
&SignatureVersion=4
&SourceDBClusterSnapshotIdentifier=arn:aws:rds:us-west-2:987654321:cluster-
snapshot:aurora-cluster1-snapshot-20130805
&TargetDBClusterSnapshotIdentifier=dbclustersnapshot1
&Version=2013-09-09
&X-Amz-Date=20140429T175351Z
Copia de una instantánea de clúster de base de datos cifrada en otra cuenta
Use el siguiente procedimiento para copiar una instantánea de clúster de base de datos cifrada en otra
cuenta de la misma región de AWS.
1. En la cuenta de origen de la instantánea del clúster de base de datos, llame a

ModifyDBClusterSnapshotAttribute especificando restore para el parámetro
AttributeName y el ID de la cuenta de destino para el parámetro ValuesToAdd.
La ejecución del siguiente ejemplo con la cuenta 987654321 permite que dos identificadores de
cuenta de AWS, 123451234512 y 123456789012, restauren la instantánea de clúster de base de
datos llamada manual-snapshot1.
?Action=ModifyDBClusterSnapshotAttribute
&AttributeName=restore
&DBClusterSnapshotIdentifier=manual-snapshot1
&SignatureMethod=HmacSHA256&SignatureVersion=4
&Version=2014-10-31
&X-Amz-Date=20150922T220515Z
&X-Amz-Signature=ef38f1ce3dab4e1dbf113d8d2a265c67d17ece1999ffd36be85714ed36dddbb3
2. En la cuenta de origen de la instantánea del clúster de base de datos, actualice la política de claves
para la clave de KMS. Para ello, añada primero el ARN de la cuenta de destino como Principal y,
a continuación permita la acción kms:CreateGrant. Para obtener más información, consulte Cómo
permitir el acceso a una clave de cifrado de AWS KMS (p. 333).
3. En la cuenta de destino, elija o cree un usuario de IAM y asocie a ese usuario una política de IAM
que le permita copiar una instantánea de clúster de base de datos cifrada usando la clave de KMS.
Para obtener más información, consulte Creación de una política de IAM para permitir la copia de la
instantánea cifrada (p. 334).

331
Cómo compartir una instantánea
4. En la cuenta de destino, llame a CopyDBClusterSnapshot y use el parámetro

base de datos que se va a copiar, que debe incluir el ID de la cuenta de origen.
La ejecución del siguiente ejemplo con la cuenta 123451234512 copia la instantánea del clúster
de base de datos aurora-cluster1-snapshot-20130805 de la cuenta 987654321 y crea una
instantánea de clúster de base de datos llamado dbclustersnapshot1.
&CopyTags=true
&SignatureVersion=4
&SourceDBClusterSnapshotIdentifier=arn:aws:rds:us-west-2:987654321:cluster-
snapshot:aurora-cluster1-snapshot-20130805
&TargetDBClusterSnapshotIdentifier=dbclustersnapshot1
&Version=2013-09-09
&X-Amz-Date=20140429T175351Z
Compartir una instantánea de clúster de base de datos

Con Amazon RDS, es posible compartir una instantánea manual de clúster de base de datos de las formas
siguientes:
• Si se comparte una instantánea manual de clúster de base de datos, ya sea cifrada o sin cifrar, las
cuentas autorizadas de AWS podrán copiar la instantánea.
• Si se comparte una instantánea manual de un clúster de base de datos, ya sea cifrada o sin cifrar, las
cuentas autorizadas de AWS podrán restaurar directamente un clúster de base de datos a partir de la
instantánea en lugar de hacer una copia de ella y restaurarla.
Note
Para compartir una instantánea de clúster de base de datos automatizada, cree una instantánea
de clúster de base de datos manual copiando la instantánea automatizada y, a continuación,
comparta esa copia.
Para obtener más información acerca de la copia de instantáneas, consulte Copia de una
instantánea (p. 321). Para obtener más información acerca de cómo restaurar una instancia de base de
datos partir de una instantánea de clúster de base de datos, consulte Restauración de una instantánea de
Para obtener más información acerca de cómo restaurar un clúster de base de datos a partir de una
instantánea de clúster de base de datos, consulte Información general de copias de seguridad y
restauración de un clúster de base de datos Aurora (p. 314).
Puede compartir una instantánea manual con un máximo de 20 cuentas de AWS. También puede
compartir una instantánea manual sin cifrar como pública, lo que hace que esté disponible para todas las
cuentas de AWS. Al compartir una instantánea como pública, tenga cuidado de que no incluya información
confidencial.
Cuando se comparten instantáneas manuales con otras cuentas de AWS, se aplican las restricciones
siguientes:

332
• Cuando se restaura un clúster de base de datos a partir de una instantánea compartida utilizando la
AWS Command Line Interface (AWS CLI) o la API de Amazon RDS, se debe especificar el nombre de
recurso de Amazon (ARN) de la instantánea compartida como identificador de instantánea.
Cómo compartir una instantánea cifrada

Puede compartir instantáneas de clúster de base de datos que se han cifrado "en reposo" utilizando el
algoritmo de cifrado AES-256, como se describe en Cifrado de recursos de Amazon Aurora (p. 158). Para
ello, debe seguir estos pasos:
1. Comparta la clave de cifrado de AWS Key Management Service (AWS KMS) que se utilizó para cifrar la
instantánea con las cuentas que desea que tengan acceso a la instantánea.
Puede compartir las claves de cifrado de AWS KMS con otra cuenta de AWS añadiendo la otra cuenta a
la política de claves de KMS. Para obtener información detallada sobre cómo actualizar una política de
claves, consulte Políticas de claves en la Guía para desarrolladores de AWS KMS. Para ver un ejemplo
de cómo crear una política de claves, consulte Cómo permitir el acceso a una clave de cifrado de AWS
KMS (p. 333) más adelante en este tema.
2. Utilice la Consola de administración de AWS, la AWS CLI, o la API de Amazon RDS para compartir la
instantánea cifrada con las otras cuentas.
Estas restricciones se aplican al uso compartido de instantáneas cifradas:
• No se pueden compartir instantáneas cifradas como públicas.

• No se puede compartir una instantánea que se ha cifrado utilizando la clave de cifrado predeterminada
de AWS KMS de la cuenta de AWS que compartió la instantánea.
Cómo permitir el acceso a una clave de cifrado de AWS KMS

Para que una cuenta de AWS copie una instantánea de clúster de base de datos cifrada compartida desde
otra cuenta, la cuenta con la que se comparte la instantánea debe tener acceso a la clave de KMS con la
que se cifró la instantánea. Para permitir que otra cuenta de AWS tenga acceso a una clave de AWS KMS,
actualice la política de claves correspondiente a la clave de KMS con el ARN de la cuenta de AWS con
la que está compartiendo como Principal en la política de claves de KMS y, a continuación, permita la
acción kms:CreateGrant.
Después de dar a una cuenta de AWS acceso a su clave de cifrado de KMS, para copiar la instantánea
cifrada, dicha cuenta de AWS debe crear un usuario de AWS Identity and Access Management (IAM) si
todavía no lo tiene. Además, esa cuenta de AWS también debe asociar a ese usuario de IAM una política
de IAM que le permita copiar una instantánea de clúster de base de datos cifrada utilizando la clave de
KMS. La cuenta debe ser un usuario de IAM y no puede ser una identidad raíz de cuenta de AWS, debido
a las restricciones de seguridad de KMS.
En el siguiente ejemplo de política de claves, el usuario 111122223333 es el propietario de la clave de

cifrado de KMS, y el usuario 444455556666 es la cuenta con la que se comparte la clave. Esta política
de claves actualizada da a la cuenta de AWS acceso a la clave de KMS incluyendo el ARN de la identidad
raíz de la cuenta de AWS del usuario 444455556666 como Principal para la política, y permitiendo la
acción kms:CreateGrant.
{
"Version": "2012-10-17",
"Statement": [
{

333
"Effect": "Allow",
"arn:aws:iam::111122223333:user/KeyUser",
"arn:aws:iam::444455556666:root"
]},
"Action": [
"kms:CreateGrant",
"kms:Encrypt",
"kms:Decrypt",
"kms:ReEncrypt*",
"kms:DescribeKey"
],
"Resource": "*"
},
{
"Effect": "Allow",
"arn:aws:iam::111122223333:user/KeyUser",
"arn:aws:iam::444455556666:root"
]},
"Action": [
"kms:CreateGrant",
"kms:ListGrants",
"kms:RevokeGrant"
],
"Resource": "*",
}
]
}
Creación de una política de IAM para permitir la copia de la instantánea cifrada
Una vez que la cuenta externa de AWS tenga acceso a la clave de KMS, el propietario de esa cuenta
de AWS puede crear una política que permita a un usuario de IAM creado para esa cuenta copiar una
instantánea que haya sido cifrada con esa clave de KMS.
En el siguiente ejemplo se muestra una política que se puede asociar a un usuario de IAM para la
cuenta de AWS 444455556666 que permite al usuario de IAM copiar una instantánea compartida por la
cuenta de AWS 111122223333 que se ha cifrado con la clave de KMS c989c1dd-a3f2-4a5d-8d96-
e793d082ab26 en la región us-west-2.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowUseOfTheKey",
"Effect": "Allow",
"Action": [
"kms:Encrypt",
"kms:Decrypt",
"kms:ReEncrypt*",
"kms:DescribeKey",
"kms:CreateGrant",
"kms:RetireGrant"
],
"Resource": ["arn:aws:kms:us-west-2:111122223333:key/c989c1dd-a3f2-4a5d-8d96-
e793d082ab26"]
},

334
{
"Sid": "AllowAttachmentOfPersistentResources",
"Effect": "Allow",
"Action": [
"kms:CreateGrant",
"kms:ListGrants",
"kms:RevokeGrant"
],
"Resource": ["arn:aws:kms:us-west-2:111122223333:key/c989c1dd-a3f2-4a5d-8d96-
e793d082ab26"],
"Condition": {
"Bool": {
"kms:GrantIsForAWSResource": true
}
}
}
]
}
Para obtener información detallada sobre cómo actualizar una política de claves, consulte Políticas de
claves en la Guía para desarrolladores de AWS KMS.

Puede compartir una instantánea de clúster de base de datos usando la Consola de administración de
Con la consola de Amazon RDS, puede compartir una instantánea manual de clúster de base de datos
con un máximo de 20 cuentas de AWS. También puede utilizar la consola para dejar de compartir una
instantánea manual con una o varias cuentas.
Para compartir una instantánea manual de clúster de base de datos mediante la consola de
Amazon RDS
3. Seleccione la instantánea manual que desea compartir.
4. En Actions (Acciones), elija Share Snapshot (Compartir instantánea).
5. Elija una de las siguientes opciones para DB Snapshot Visibility (Visibilidad de instantánea de base de
datos).
• Si el original está sin cifrar, elija Public (Públics) para permitir que todas las cuentas de AWS
restauren un un clúster de base de datos a partir de la instantánea de clúster de base de datos
manual o elija Private (Privada) para permitir que únicamente las cuentas de AWS que especifique
restauren un clúster de base de datos a partir de una instantánea de clúster de base de datos
manual.
Warning
Si establece DB Snapshot Visibility (Visibilidad de instantánea de base de datos) en Public

(Pública), todas las cuentas de AWS pueden restaurar un clúster de base de datos a partir
de una instantánea de clúster de base de datos manual y tener acceso a sus datos. No
comparta como Public (Pública) ninguna instantánea de clúster de base de datos manual
que contenga información confidencial.

335
• Si el original está cifrado, DB Snapshot Visibility (Visibilidad de instantánea de base de datos) se

establece en Private (Privada), ya que las instantáneas cifradas no se pueden compartir como
públicas.
6. En AWS Account ID (ID de cuenta de AWS), escriba el identificador de cuenta de AWS
correspondiente a una cuenta a la que desea permitir la restauración de un clúster de base de datos
a partir de la instantánea manual y, a continuación, elija Add (Agregar). Repita esta acción para incluir
identificadores de cuenta de AWS adicionales, con un máximo de 20 cuentas de AWS.
Si comete un error al añadir un identificador de cuenta de AWS a la lista de cuentas permitidas, puede
eliminarlo de la lista seleccionando Delete a la derecha del identificador incorrecto.
7. Después de añadir los identificadores de todas las cuentas de AWS a las que desea permitir la
restauración de la instantánea manual, elija Save para guardar los cambios.
Para dejar de compartir una instantánea manual de clúster de base de datos con una cuenta de
AWS
3. Seleccione la instantánea manual que desea dejar de compartir.
4. Elija Actions (Acciones) y, a continuación, elija Share Snapshot (Compartir instantánea).
5. Para eliminar el permiso de una cuenta de AWS, elija Delete para el identificador de cuenta de AWS
correspondiente a esa cuenta en la lista de cuentas autorizadas.

336
6. Elija Save para guardar los cambios.
AWS CLI
Para compartir una instantánea de clúster de base de datos, use el comando aws rds modify-db-
cluster-snapshot-attribute . Use el parámetro --values-to-add para añadir la lista de los ID de
las cuentas de AWS que tienen autorización para restaurar la instantánea manual.
En el siguiente ejemplo, se permite a dos identificadores de cuenta de AWS, 123451234512 y

123456789012, que restauren la instantánea de clúster de base de datos denominada manual-
cluster-snapshot1, y se elimina el valor all del atributo para marcar la instantánea como privada.
aws rds modify-db-cluster-snapshot-attribute \

--db-cluster-snapshot-identifier manual-cluster-snapshot1 \
--attribute-name restore \
--values-to-add '["111122223333","444455556666"]'
Para quitar un identificador de cuentas de AWS de la lista, use el parámetro -- values-to-remove.

En el siguiente ejemplo se impide que el ID 444455556666 de la cuenta de AWS se restaure desde la
instantánea.
aws rds modify-db-cluster-snapshot-attribute \

--db-cluster-snapshot-identifier manual-cluster-snapshot1 \
--attribute-name restore \
--values-to-remove '["444455556666 "]'

337
Recuperación a un momento dado
API
También puede compartir una instantánea manual de clúster de base de datos con otras cuentas de AWS
mediante la API de Amazon RDS. Para ello, llame a la acción ModifyDBClusterSnapshotAttribute.
Especifique restore en AttributeName y utilice el parámetro ValuesToAdd para añadir la lista de los
ID de las cuentas de AWS que tienen autorización para restaurar la instantánea manual.
Para hacer que una instantánea manual sea pública y puedan restaurarla todas las cuentas de AWS,
utilice el valor all. Sin embargo, tenga cuidado de no añadir el valor all para las instantáneas manuales
que contienen información confidencial que no desea que esté disponible para todas las cuentas de AWS.
Además, tampoco especifique all para las instantáneas cifradas, ya que dichas instantáneas no pueden
hacerse públicas.
Para eliminar el permiso de uso compartido de una cuenta de AWS, utilice la acción
ModifyDBClusterSnapshotAttribute con AttributeName establecido en restore y el parámetro
ValuesToRemove. Para marcar una instantánea manual como privada, elimine el valor all de la lista de
valores del atributo restore.
Para ver una lista de todas las cuentas de AWS que tienen permiso para restaurar una instantánea, utilice
la acción DescribeDBClusterSnapshotAttributes de la API.
Restauración de un clúster de base de datos a un

momento especificado
Puede restaurar un clúster de base de datos a cualquier momento concreto y crear así un nuevo clúster de
base de datos. Cuando restaure un clúster de base de datos a un momento dado, el grupo de seguridad
de base de datos predeterminado se aplica a el nuevo clúster de base de datos. Si necesita que se
apliquen grupos de seguridad de base de datos personalizados a su clúster de base de datos, debe
aplicarlos expresamente con la Consola de administración de AWS, el comando modify-db-cluster de
la AWS CLI o la acción ModifyDBCluster de la API de Amazon RDS una vez que la instancia de base
de datos esté disponible.
Note
Para obtener más información sobre la realización de copia de seguridad y restauración de

un clúster de base de datos de Aurora, consulte Información general de copias de seguridad
y restauración de un clúster de base de datos Aurora (p. 314). Para Aurora MySQL, puede
restaurar un clúster de base de datos aprovisionado en un clúster de base de datos de Aurora
Serverless. Para obtener más información, consulte Restauración de un clúster de base de datos
de Aurora Serverless (p. 115).
Puede restaurar un clúster de base de datos a un punto en el tiempo con la Consola de administración de

Para restaurar un clúster de base de datos a un momento específico
3. Seleccione la instancia principal del clúster de base de datos que desea restaurar.
4. Para Actions (Acciones), seleccione Restore to point in time (Restaurar a un momento dado).
Aparece la ventana Launch DB Instance (Lanzar instancia de base de datos).

5. Elija Latest restorable time (Última hora de restauración) para restaurar a la última hora posible o elija
Custom (Personalizar) para elegir una hora.

338
Eliminación de una instantánea
Si elige Custom (Personalizar), introduzca la fecha y hora en la que quiere restaurar el clúster.
6. En DB instance identifier (Identificador de instancia de base de datos), introduzca el nombre de la
instancia de base de datos restaurada y complete las otras opciones.
7. Elija Launch DB Instance.
CLI
Para restaurar un clúster de base de datos a un momento dado, use el comando restore-db-cluster-
to-point-in-time de la CLI de AWS para crear un nuevo clúster de base de datos.
Example

--source-db-cluster-identifier mysourcedbcluster \
--db-cluster-identifier mytargetdbcluster \
--restore-to-time 2017-10-14T23:45:00.000Z
Para Windows:

--source-db-cluster-identifier mysourcedbcluster ^
--db-cluster-identifier mytargetdbcluster ^
--restore-to-time 2017-10-14T23:45:00.000Z
API
Para restaurar un clúster de base de datos a un momento especificado, llame a la función
RestoreDBClusterToPointInTime de la API de Amazon RDS con los siguientes parámetros:
• SourceDBClusterIdentifier
• RestoreToTime
Eliminación de una instantánea

Puede eliminar las instantáneas de clúster de base de datos administradas por Amazon RDS cuando ya no
las necesite.
Eliminación de una instantánea de clúster de base de datos

Puede eliminar una instantánea de clúster de base de datos con la consola, la AWS CLI, o la API de RDS.
Para eliminar una instantánea compartida o pública, debe iniciar sesión en la cuenta de AWS propietaria
de la instantánea.
Consola
Para eliminar una instantánea de clúster de base de datos, realice el siguiente procedimiento:

339
Mantenimiento de un clúster de base de datos de Aurora

3. Elija la instantánea de clúster de base de datos que desee eliminar.
4. En Actions (Acciones), elija Delete Snapshot (Eliminar instantánea).
5. En la página de confirmación, elija Delete (Eliminar).
AWS CLI
Puede eliminar una instantánea de clúster de base de datos con el comando de la AWS CLI delete-db-
snapshot.
Las siguientes opciones se usan para eliminar una instantánea de clúster de base de datos.
• --db-cluster-snapshot-identifier: el identificador de la instantánea de clúster de base de

datos.
Example
El código siguiente elimina la instantánea de clúster de base de datos mydbclustersnapshot.
aws rds delete-db-cluster-snapshot \

Para Windows:
aws rds delete-db-cluster-snapshot ^

API de RDS
Puede eliminar una instantánea de clúster de base de datos mediante la operación de la API de Amazon
RDS DeleteDBClusterSnapshot.
Los siguientes parámetros se usan para eliminar una instantánea de clúster de base de datos.
• DBClusterSnapshotIdentifier: el identificador de la instantánea de clúster de base de datos.
Mantenimiento de un clúster de base de datos de

Amazon Aurora
Amazon RDS realiza tareas de mantenimiento periódicas en los recursos de Amazon RDS. En la mayoría
de los casos, estas tareas de mantenimiento incluyen actualizaciones del hardware subyacente, del
sistema operativo (SO) subyacente o de la versión del motor de base de datos de clúster de base de datos.
Las actualizaciones del sistema operativo suelen deberse a motivos de seguridad y deben efectuarse lo
antes posible.
Algunos elementos de mantenimiento necesitan que Amazon RDS desconecte su clúster de base de
datos durante un breve plazo de tiempo. Entre los elementos de mantenimiento que requieren que un

340
Mantenimiento de un clúster de base de datos de Aurora
recurso esté desconectado están el sistema operativo necesario o la aplicación de parches a la base
de datos. Los parches obligatorios que tienen que ver con la seguridad y la fiabilidad de la instancia son
los únicos que se programan automáticamente. La aplicación de estos parches tiene lugar con poca
frecuencia (normalmente, una vez cada varios meses) y suele requerir tan solo una fracción de la ventana
de mantenimiento.
Para ver si hay disponible una actualización de mantenimiento para un clúster de base de datos, use la
consola de RDS, la AWS CLI o la API de Amazon RDS. Si hay disponible una actualización, se indicará
en la columna Maintenance (Mantenimiento) para el clúster de base de datos en la consola Amazon RDS,
como se muestra a continuación.
Si no hay ninguna actualización de mantenimiento disponible para un clúster de base de datos, el valor de
columna es none (ninguno).
Si una actualización de mantenimiento está disponible para un clúster, son posibles los siguientes valores
de columna:
• required (obligatorio): la acción de mantenimiento se aplicará al recurso y no se podrá aplazar.

• available (disponible): la acción de mantenimiento está disponible, pero no se aplicará al recurso
automáticamente. Puede aplicarla manualmente.
• next window (siguiente periodo): la acción de mantenimiento se aplicará al recurso durante el siguiente
periodo de mantenimiento.
• In progress (en curso): la acción de mantenimiento está en proceso de aplicarse al recurso.
Si hay una actualización disponible, puede realizar una de las acciones:
• Si el valor de mantenimiento es next window (siguiente periodo), aplace los elementos de mantenimiento
eligiendo defer upgrade (aplazar actualización) en Actions (Acciones).
• Aplicar inmediatamente los elementos de mantenimiento.
• Programar los elementos de mantenimiento para que se inicien en la siguiente ventana de
mantenimiento.
• No realice ninguna acción.
Note
Determinadas actualizaciones del sistema operativo se marcan como required (obligatorio).

Si aplaza una actualización obligatoria, Amazon RDS le indicará cuándo se ejecutará la

341
Aplicación de actualizaciones
actualización. Otras actualizaciones se marcan como available (disponible) y puede diferir de

forma indefinida.
Para realizar una acción, elija el clúster para mostrar sus detalles y, a continuación, elija Maintenance &
backups (Mantenimiento y copias de seguridad). Aparecerán los elementos de mantenimiento pendientes.
El periodo de mantenimiento determina el momento en que comienzan las operaciones pendientes, pero
no limita su tiempo de ejecución total. No existen garantías de que las operaciones de mantenimiento
finalicen antes de que termine el periodo de mantenimiento, de modo que pueden continuar más allá de la
hora de finalización establecida. Para obtener más información, consulte La ventana de mantenimiento de
Para obtener información acerca de actualizaciones de motores de Amazon Aurora e instrucciones para
actualizarlos y aplicarles parches, consulte Actualizaciones del motor de base de datos para Amazon
Aurora MySQL (p. 695) y Actualizaciones del motor de base de datos para Amazon Aurora PostgreSQL
(p. 856).
Aplicación de actualizaciones a un clúster de base de

datos o clúster de base de datos
Con Amazon RDS puede elegir el momento en que desea aplicar las operaciones de mantenimiento.
Puede indicar cuándo debe aplicar Amazon RDS las actualizaciones usando la consola de RDS, la AWS
Command Line Interface (AWS CLI) o la API de RDS.
Consola
Para administrar la actualización de un clúster de base de datos
3. Seleccione el clúster de base de datos que tenga una actualización necesaria.
4. En Actions (Acciones), elija una de las siguientes opciones:
• Upgrade now (Actualizar ahora)

• Upgrade at next window (Actualizar en el siguiente periodo)

342
Aplicación de actualizaciones
Note
Si elige Upgrade at next window (Actualizar en el siguiente periodo) y después desea

aplazar la actualización, puede seleccionar Defer upgrade (Aplazar actualización).
AWS CLI
Para aplicar una actualización pendiente a un clúster de base de datos, use el comando apply-pending-
maintenance-action de la AWS CLI.
Example
aws rds apply-pending-maintenance-action \

--resource-identifier arn:aws:rds:us-west-2:001234567890:db:mysql-db \
--apply-action system-update \
--opt-in-type immediate
Para Windows:
aws rds apply-pending-maintenance-action ^

--resource-identifier arn:aws:rds:us-west-2:001234567890:db:mysql-db ^
--apply-action system-update ^
--opt-in-type immediate
Para obtener una lista de los recursos con al menos una actualización pendiente, use el comando
describe-pending-maintenance-actions de la AWS CLI.
Example
aws rds describe-pending-maintenance-actions \

--resource-identifier arn:aws:rds:us-west-2:001234567890:db:mysql-db
Para Windows:
aws rds describe-pending-maintenance-actions ^

--resource-identifier arn:aws:rds:us-west-2:001234567890:db:mysql-db
También puede obtener una lista de recursos de un clúster de base de datos especificando el parámetro
--filters del comando describe-pending-maintenance-actions de la AWS CLI. El formato del
comando --filters es Name=filter-name,Value=resource-id,....
Los valores aceptados para el parámetro Name de un filtro son los siguientes:
• db-instance-id: acepta una lista de identificadores o nombres de recurso de Amazon (ARN) de

instancias de base de datos. La lista obtenida solo incluirá las operaciones de mantenimiento pendientes
para las instancias de base de datos referidas por esos identificadores o ARN.
• db-cluster-id: acepta una lista de identificadores o ARN de clústeres de base de datos para Amazon
Aurora. La lista obtenida solo incluirá las operaciones de mantenimiento pendientes para los clústeres de
base de datos referidos por esos identificadores o ARN.

343
La ventana de mantenimiento
Por ejemplo, en el ejemplo siguiente se obtienen las operaciones de mantenimiento pendientes para los
clústeres de base de datos sample-cluster1 y sample-cluster2.
Example
aws rds describe-pending-maintenance-actions \

--filters Name=db-cluster-id,Values=sample-cluster1,sample-cluster2
Para Windows:
aws rds describe-pending-maintenance-actions ^

--filters Name=db-cluster-id,Values=sample-cluster1,sample-cluster2
API de RDS
Para aplicar una actualización pendiente a un clúster de base de datos, llame a la acción
ApplyPendingMaintenanceAction de la API de Amazon RDS.
Para obtener una lista de los recursos con al menos una actualización pendiente, llame a la acción
DescribePendingMaintenanceActions de la API Amazon RDS.
La ventana de mantenimiento de Amazon RDS

Cada clúster de base de datos tienen una ventana de mantenimiento semanal durante la que se aplican
los cambios del sistema. Puede entender la ventana de mantenimiento como una oportunidad de controlar
cuándo se producen modificaciones y se aplican parches de software, en caso de que se solicite o sea
necesario. Si hay un evento de mantenimiento programado para una semana determinada, se iniciará
durante la ventana de mantenimiento que identifique. La mayoría de los eventos de mantenimiento
también se completan durante la ventana de mantenimiento de 30 minutos, aunque otros eventos de
mantenimiento pueden tardar más de 30 minutos en completarse.
La ventana de mantenimiento de 30 minutos se selecciona al azar dentro de un bloque de 8 horas por

región. Si no especifica una ventana de mantenimiento preferida al crear un clúster de base de datos,
Amazon RDS asigna una ventana de mantenimiento de 30 minutos un día de la semana seleccionado al
azar.
RDS consumirá algunos de los recursos de su clúster de base de datos mientras se aplica el
mantenimiento. Es posible que observe un efecto mínimo en el desempeño. Para una instancia de
base de datos, en raras ocasiones puede ser necesaria una conmutación por error de varias zonas de
disponibilidad para que se complete una actualización de mantenimiento.
A continuación, puede encontrar los bloques de horas de cada región desde los que se asignan las
ventanas predeterminadas de mantenimiento.
Región Bloque de tiempo
Región EE.UU. Oeste 06:00–14:00 UTC

(Oregón)
EE.UU. Oeste (Norte de 06:00–14:00 UTC

California)
Región EE.UU Este (Ohio) 03:00–11:00 UTC

344
Ajuste de la ventana de mantenimiento
para un clúster de base de datos
Región Bloque de tiempo
Región EE.UU. Este (Norte 03:00–11:00 UTC

de Virginia)
Región Asia Pacífico 17:30–01:30 UTC

(Mumbai)
Región Asia Pacífico (Seúl) 13:00–21:00 UTC
Región Asia Pacífico 14:00–22:00 UTC

(Singapur)
Región Asia Pacífico (Sídney) 12:00–20:00 UTC
Región Asia Pacífico (Tokio) 13:00–21:00 UTC
Región Canadá (Central) 03:00–11:00 UTC
Región UE (Fráncfort) 23:00–07:00 UTC
Región UE (Irlanda) 22:00–06:00 UTC
Región UE (Londres) 22:00–06:00 UTC
Región América del Sur (São 00:00–08:00 UTC

Paulo)
AWS GovCloud (EE.UU. 06:00–14:00 UTC

Oeste)
Ajuste de la ventana de mantenimiento preferida para

un clúster de base de datos
La ventana de mantenimiento del clúster de base de datos de Aurora debe corresponder al momento de
mínimo uso y, por tanto, podría ser preciso modificarla cada cierto tiempo. El clúster de base de datos solo
deja de estar disponible durante este tiempo si las actualizaciones que se están aplicando requieren una
interrupción. La interrupción dura la cantidad de tiempo mínima requerida para realizar las actualizaciones
necesarias.
Consola
Para ajustar la ventana de mantenimiento preferida del clúster de base de datos
3. Elija el clúster de base de datos cuyo periodo de mantenimiento desea cambiar.
4. Para Actions (Acciones), elija Modify cluster (Modificar clúster).
5. En la sección Maintenance (Mantenimiento), actualice el periodo de mantenimiento.
6. Elija Continue.
En la página de confirmación, revise los cambios.

7. Para aplicar los cambios al periodo de mantenimiento de forma inmediata, seleccione Apply
immediately (Aplicar inmediatamente).

345
Ajuste de la ventana de mantenimiento
para un clúster de base de datos
8. Seleccione Modify cluster (Modificar clúster) para guardar los cambios.
AWS CLI
Para ajustar la ventana de mantenimiento preferida del clúster de base de datos, use el comando modify-
db-cluster de la AWS CLI con los siguientes parámetros:
• --preferred-maintenance-window
Example
En el siguiente ejemplo de código, el periodo de mantenimiento se define para los martes de 4:00 a 4:30
AM UTC.

--db-cluster-identifier my-cluster \
--preferred-maintenance-window Tue:04:00-Tue:04:30
Para Windows:

--db-cluster-identifier my-cluster ^
--preferred-maintenance-window Tue:04:00-Tue:04:30
API de RDS
Para ajustar el periodo de mantenimiento preferida del clúster de base de datos, use la acción
ModifyDBCluster de la API de Amazon RDS con los siguientes parámetros:
• DBClusterIdentifier = my-cluster
• PreferredMaintenanceWindow = Tue:04:00-Tue:04:30
Example
En el siguiente ejemplo de código, el periodo de mantenimiento se define para los martes de 4:00 a 4:30
AM UTC.
?Action=ModifyDBCluster
&DBClusterIdentifier=my-cluster
&PreferredMaintenanceWindow=Tue:04:00-Tue:04:30
&SignatureVersion=4
&Version=2014-10-31
&X-Amz-Date=20161017T161457Z
&X-Amz-Signature=d6d1c65c2e94f5800ab411a3f7336625820b103713b6c063430900514e21d784

346
Reinicio de una instancia de base de datos
Reinicio de una instancia de base de datos en un

Es posible que necesite reiniciar su instancia de base de datos, normalmente por razones de
mantenimiento. Por ejemplo, si realiza determinadas modificaciones o si cambia el grupo de parámetros
de base de datos asociado a la instancia de base de datos o su clúster de base de datos, debe reiniciar la
instancia para que los cambios surtan efecto.
Note
Por ejemplo, si la instancia de base de datos no está utilizando los cambios más recientes del
grupo de parámetros de base de datos asociado, la Consola de administración de AWS muestra
el grupo de parámetros de base de datos con el estado pending-reboot. El estado de los grupos
de parámetros pending-reboot no genera un reinicio automático durante la siguiente ventana de
mantenimiento. Para aplicar los cambios de parámetros más recientes en esa instancia de base
de datos, reinicie manualmente la instancia de base de datos. Para obtener más información
acerca de los grupos de parámetros, consulte Trabajo con los grupos de parámetros de base de
datos y grupos de parámetros de clúster de base de datos (p. 259).
Cuando se reinicia una instancia de base de datos, se reinicia el servicio del motor de base de datos. Al
reiniciar una instancia de base de datos, se produce una interrupción momentánea, durante la cual su
estado se establece en rebooting.
No puede reiniciar su instancia de base de datos si no está en el estado disponible. Su base de datos
puede no estar disponible por varias razones, como una copia de seguridad en curso, una modificación
solicitada anteriormente o una acción durante un periodo de mantenimiento.
Important
Al reiniciar la instancia principal de un clúster de base de datos de Amazon Aurora, RDS también
reinicia automáticamente todas las réplicas de Aurora de ese clúster de base de datos. Al reiniciar
la instancia principal de un clúster de base de datos Aurora, no se produce ninguna conmutación
por error. Al reiniciar una réplica de Aurora, no se produce ninguna conmutación por error. Para
conmutar por error un clúster de base de datos de Aurora, llame al comando failover-db-
cluster de la AWS CLI o a la acción FailoverDBCluster de la API.

Para reiniciar una instancia de base de datos
de base de datos que desee reiniciar.
3. Para Actions (Acciones), elija Reboot (Reiniciar).
Aparece la página Reboot DB Instance.

4. Elija Reboot para reiniciar su instancia de base de datos.
O bien, elija Cancel.
CLI
Para reiniciar una instancia de base de datos mediante la AWS CLI, llame al comando reboot-db-
instance.

347
Eliminación de una instancia de base de datos
Example Reinicio sencillo
aws rds reboot-db-instance \

--db-instance-identifier mydbinstance
Para Windows:
aws rds reboot-db-instance ^

API
Para reiniciar una instancia de base de datos mediante la API de Amazon RDS, llame a la acción
RebootDBInstance.
Eliminación de una instancia de base de datos en

un clúster de base de datos de Aurora
Puede eliminar una instancia de base de datos en un clúster de base de datos, incluida la eliminación de la
instancia de base de datos principal en un clúster de base de datos o una réplica de Amazon Aurora. Para
eliminar una instancia de base de datos, debe especificar el nombre de la instancia.
Puede habilitar la protección contra eliminación para que los usuarios no puedan eliminar un clúster
de base de datos. La protección contra eliminación se habilita de forma predeterminada cuando crea
un clúster de base de datos de producción con la Consola de administración de AWS. Sin embargo, la
protección contra eliminación está deshabilitada de forma predeterminada si crea un clúster con la AWS
CLI o la API.
Aurora aplica la protección de eliminación para un clúster si realiza la operación desde la consola, la CLI o
la API. Si intenta eliminar un clúster de base de datos que tenga habilitada la protección contra eliminación,
no podrá hacerlo. Para asegurarse de que puede eliminar el clúster, modifique el clúster y deshabilite la
protección contra eliminación.
Si intenta eliminar la última instancia de base de datos del clúster, el comportamiento depende del
método que utilice. No puede eliminar la última instancia de base de datos a través de la Consola de
administración de AWS, puesto que, de hacerlo, también se elimina el clúster. Puede eliminar la última
instancia de base de datos a través de la AWS CLI o la API si el clúster tiene la protección contra
contraseña habilitada. En ese caso, el propio clúster de base de datos sigue existiendo y se conservan
los datos. Puede acceder a los datos si asocia nuevas instancias de base de datos al clúster. Para
obtener más información sobre la activación y desactivación de la protección contra contraseña, consulte
Modificación del clúster de base de datos con la consola, CLI y API (p. 236).
Para Aurora MySQL, no puede eliminar una instancia de la base de datos en un clúster de base de datos si
se cumplen las dos condiciones siguientes:
• El clúster de base de datos es una réplica de lectura de otro clúster de base de datos de Aurora.
• La instancia de base de datos es la única instancia en el clúster de base de datos.
Para eliminar una instancia de base de datos en este caso, primero promueva el clúster de bases de
datos para que deje de ser una réplica de lectura. Una vez finalizada la promoción, puede eliminar
la instancia final de la base de datos en el clúster de bases de datos. Para obtener más información,

348
Uso de la consola, la CLI y la API
consulte Replicación de clústeres de base de datos Amazon Aurora MySQL entre distintas regiones de
AWS (p. 599).
Eliminación de una instancia de base de datos

mediante la consola, la CLI y la API
Puede eliminar una instancia de base de datos mediante la consola de Consola de administración de AWS,
la AWS CLI o la API de RDS.
Consola
Para eliminar una instancia de base de datos
de base de datos que desee eliminar.
3. En Actions (Acciones), elija Delete (Eliminar).
4. Para conservar las copias de seguridad automatizadas, seleccione Retain automated backups
(Conservar copias de seguridad automatizadas).
5. En el cuadro, escriba delete me.
6. Elija Eliminar.
AWS CLI
Para eliminar una instancia de base de datos con la AWS CLI, llame al comando delete-db-instance y
especifique la opción --db-instance-identifier.
Example
aws rds delete-db-instance \

Para Windows:
aws rds delete-db-instance ^

API de RDS
Para eliminar una instancia de base de datos con la API de Amazon RDS, llame a la acción
DeleteDBInstance y especifique el parámetro DBInstanceIdentifier.
Etiquetado de recursos de Amazon RDS

Puede utilizar etiquetas de Amazon RDS para agregar metadatos a los recursos de Amazon RDS.
Además, estas etiquetas se pueden utilizar junto con políticas de IAM para administrar el acceso a los

349
Información general
recursos de Amazon RDS y para controlar qué acciones se pueden aplicar a los recursos de Amazon RDS.
Por último, estas etiquetas se pueden utilizar para hacer un seguimiento de costos, agrupando los gastos
correspondientes a recursos con etiqueta similar.
Todos los recursos de Amazon RDS pueden etiquetarse
• Instancias de base de datos

• Clústeres de base de datos
• Réplicas de lectura
• Instantáneas de base de datos
• Instantáneas de clúster de base de datos
• Instancias de base de datos reservadas
• Suscripciones de eventos
• Grupos de opciones de base de datos
• Grupos de parámetros de base de datos
• Grupos de parámetros de clúster de base de datos
• Grupos de seguridad de base de datos
• Grupos de subred de base de datos
Para obtener más información sobre la administración del acceso a recursos etiquetados con políticas de
IAM, consulte Administración de identidad y acceso en Amazon Aurora (p. 163).
Información general de las etiquetas de recursos de

Amazon RDS
Las etiquetas de Amazon RDS son pares nombre-valor que el usuario define y asocia a un recurso de
Amazon RDS. El nombre es la clave. Si lo desea puede proporcionar un valor para la clave o no. También
puede usar etiquetas para asignar información arbitraria a un recurso de Amazon RDS. Puede usar claves
de etiqueta, por ejemplo, para definir una categoría, y el valor de la etiqueta puede ser un elemento dentro
de esa categoría. Por ejemplo, puede definir una clave de etiqueta "proyecto" y un valor de etiqueta "Salix"
para indicar que el recurso de Amazon RDS va asignado al proyecto Salix. También puede usar etiquetas
para designar recursos de Amazon RDS para pruebas o para producción a través de una clave como
entorno=prueba o entorno=producción. Se recomienda utilizar un conjunto coherente de claves de etiqueta
que facilite el seguimiento de los metadatos asociados a los recursos de Amazon RDS.
Use etiquetas para organizar sus facturas de AWS de manera que reflejen su propia estructura de costos.
Para ello, regístrese para obtener una factura de su cuenta de AWS que incluya valores de clave de
etiquetas. A continuación, para ver los costos de los recursos combinados, organice la información de
facturación de acuerdo con los recursos con los mismos valores de clave de etiquetas. Por ejemplo, puede
etiquetar varios recursos con un nombre de aplicación específico y luego organizar su información de
facturación para ver el costo total de la aplicación en distintos servicios. Para obtener más información,
consulte Cost Allocation and Tagging en About AWS Billing and Cost Management.
Cada recurso de Amazon RDS tiene un conjunto de etiquetas con todas las etiquetas asignadas a ese
recurso de Amazon RDS. Un conjunto de etiquetas puede contener hasta 50 etiquetas, y también puede
estar vacío. Si agrega una etiqueta a un recurso de Amazon RDS con la misma clave que una etiqueta
existente en el recurso, el nuevo valor sobrescribirá al antiguo.
AWS no aplica ningún significado semántico a las etiquetas, que se interpretan estrictamente como
cadenas de caracteres. Amazon RDS puede definir etiquetas en una instancia de base de datos u otros
recursos de Amazon RDS, con arreglo a la configuración utilizada al crear el recurso. Por ejemplo,

350
Amazon RDS podría agregar una etiqueta en la que se indica que una instancia de base de datos es para
producción o para la realización de pruebas.
• La clave de la etiqueta es el nombre obligatorio de la etiqueta. El valor de la cadena puede tener una
longitud de entre 1 y 128 caracteres Unicode y no puede llevar los prefijos "aws:" ni "rds:". La cadena
puede contener únicamente el conjunto de letras, dígitos y espacio en blanco, '_', '.', ':', '/', '=', '+', '-',
'@' (Java regex: "^([\\p{L}\\p{Z}\\p{N}_.:/=+\\-]*)$").
• El valor de etiqueta es un valor de cadena optativo en la etiqueta. El valor de cadena puede tener
una longitud de entre 1 y 256 caracteres Unicode y no puede llevar el prefijo "aws:". La cadena puede
contener únicamente el conjunto de letras, dígitos y espacio en blanco, '_', '.', ':', '/', '=', '+', '-', '@' (Java
regex: "^([\\p{L}\\p{Z}\\p{N}_.:/=+\\-]*)$").
Los valores no deben ser únicos dentro de un conjunto de etiquetas y también pueden ser nulos. Por
ejemplo, puede tener un par clave-valor en un conjunto de etiquetas en proyecto/Trinity y centro-de-
costos/Trinity.
Note
Puede añadir una etiqueta a una instantánea, pero la factura no reflejará esta agrupación.
Puede utilizar la Consola de administración de AWS, la interfaz de línea de comandos o la API de Amazon
RDS para agregar, listar y eliminar etiquetas de recursos de Amazon RDS. Si utiliza la interfaz de línea
de comandos o la API de Amazon RDS, deberá proporcionar el nombre de recurso de Amazon (ARN)
correspondiente al recurso de Amazon RDS con el que desee trabajar. Para obtener más información
sobre cómo crear un ARN, consulte Creación de un nombre ARN para Amazon RDS (p. 354).
Las etiquetas se almacenan en caché con fines de autorización. Por este motivo, cuando se actualizan o
se agregan valores a las etiquetas de recursos de Amazon RDS, pueden tardar varios minutos en estar
disponibles.
Note
Los clústeres de base de datos de Aurora no admiten etiquetas de asignación de costos para
almacenamiento, copias de seguridad, E/S, E/S de escritura replicada de la base de datos global
o registros de cambios de búsqueda de datos anteriores.
Consola
El proceso para etiquetar un recurso de Amazon RDS es similar para todos los recursos. El siguiente
procedimiento muestra cómo etiquetar una instancia de base de datos de Amazon RDS.
Para agregar una etiqueta a una instancia de base de datos
Note
Para filtrar la lista de instancias de base de datos en el panel Databases (Bases de datos),
escriba una cadena de texto para Filter databases (Filtrar bases de datos). Solo aparecen
instancias de base de datos que contienen la cadena.
3. Seleccione el nombre de la instancia de base de datos que desea etiquetar para mostrar sus detalles.
4. En la sección de detalles, desplácese hasta la sección Tags (Etiquetas).
5. Elija Add. Aparece la ventana Add tags (Añadir etiquetas).

351
6. Escriba un valor para Tag key (Clave de etiqueta) y Value (Valor).

7. Para añadir otra etiqueta, puede elegir Add another Tag (Añadir otra etiqueta) y escribir un valor para
Tag key (Clave de etiqueta) y Value (Valor).
Repita este paso tantas veces como sea necesario.

8. Elija Add.
Para eliminar una etiqueta de una instancia de base de datos
Note
Para filtrar la lista de instancias de base de datos en el panel Databases (Bases de datos),
escriba una cadena de texto en el cuadro Filter databases (Filtrar bases de datos). Solo
aparecen instancias de base de datos que contienen la cadena.
3. Seleccione el nombre de la instancia de base de datos para mostrar sus detalles.
4. En la sección de detalles, desplácese hasta la sección Tags (Etiquetas).
5. Elija la etiqueta desea eliminar.
6. Elija Delete (Eliminar) y después elija (Eliminar) en la ventana Delete tags (Eliminar etiquetas).

352
AWS CLI
Puede utilizar la AWS CLI para agregar, listar o eliminar etiquetas de una instancia de base de datos.
• Para añadir una o más etiquetas a un recurso de Amazon RDS, utilice el comando add-tags-to-
resource de la AWS CLI.
• Para ver una lista de las etiquetas de un recurso de Amazon RDS, utilice el comando list-tags-for-
resource de la AWS CLI.
• Para eliminar una o más etiquetas de un recurso de Amazon RDS, utilice el comando remove-tags-
from-resource de la AWS CLI.
Para obtener más información acerca de cómo crear el ARN requerido, consulte Creación de un nombre
ARN para Amazon RDS (p. 354).
API de RDS
Puede utilizar la API de Amazon RDS para agregar, listar o eliminar etiquetas de una instancia de base de
datos.
• Para añadir una etiqueta a un recurso de Amazon RDS, utilice la operación AddTagsToResource.
• Para ver una lista de las etiquetas asignadas a un recurso de Amazon RDS, utilice
ListTagsForResource.
• Para eliminar etiquetas de un recurso de Amazon RDS, utilice la operación
RemoveTagsFromResource.
Para obtener más información acerca de cómo crear el ARN requerido, consulte Creación de un nombre
ARN para Amazon RDS (p. 354).
Cuando se trabaja con XML mediante la API de Amazon RDS, las etiquetas utilizan el esquema siguiente:
<Tagging>
<TagSet>
<Tag>
<Key>Project</Key>
<Value>Trinity</Value>
</Tag>
<Tag>
<Key>User</Key>
<Value>Jones</Value>
</Tag>
</TagSet>
</Tagging>
La tabla siguiente proporciona una lista de las etiquetas XML permitidas y sus características. Los
valores de clave y de valor distinguen entre mayúsculas y minúsculas. Por ejemplo, proyecto=Trinity y
PROYECTO=Trinity son dos etiquetas diferentes.
Elemento de etiquetado Descripción
TagSet Los conjuntos de etiquetas contienen todas las etiquetas asignadas a un

recurso de Amazon RDS. Solo puede haber un conjunto de etiquetas por
recurso. Solo puede trabajar con conjuntos de etiquetas a través de la API de
Amazon RDS.
Tag Las etiquetas son pares clave-valor que define el usuario. En un conjunto de
etiquetas puede haber entre 1 y 50 etiquetas.

353
Uso de ARN
Elemento de etiquetado Descripción
Key La clave es el nombre obligatorio de la etiqueta. El valor de la cadena puede

tener una longitud de entre 1 y 128 caracteres Unicode y no puede llevar los
prefijos "rds:" ni "aws:". La cadena solo puede contener el conjunto de letras,
dígitos y espacio en blanco Unicode, '_', '.', '/', '=', '+', '-' (Java regex: "^([\\p{L}\
\p{Z}\\p{N}_.:/=+\\-]*)$").
Las claves deben ser únicas dentro de un conjunto de etiquetas. Por ejemplo,
en un conjunto de etiquetas no puede haber claves iguales pero con valores
diferentes, como proyecto/Trinity y proyecto/Xanadu.
Value El valor es la parte opcional de la etiqueta. El valor de la cadena puede tener

una longitud de entre 1 y 256 caracteres Unicode y no puede llevar los prefijos
"rds:" ni "aws:". La cadena solo puede contener el conjunto de letras, dígitos
y espacio en blanco Unicode, '_', '.', '/', '=', '+', '-' (Java regex: "^([\\p{L}\\p{Z}\
\p{N}_.:/=+\\-]*)$").
Los valores no deben ser únicos dentro de un conjunto de etiquetas y también

pueden ser nulos. Por ejemplo, puede tener un par clave-valor en un conjunto
de etiquetas en proyecto/Trinity y centro-de-costos/Trinity.
Uso de nombres de recursos de Amazon (ARN) en

Amazon RDS
Cada recurso que se crea en Amazon Web Services se identifica de forma inequívoca mediante un nombre
de recurso de Amazon (ARN). Para determinadas operaciones de Amazon RDS, debe identificar de forma
inequívoca un recurso de Amazon RDS mediante su ARN. Por ejemplo, al crear una réplica de lectura de
una instancia de base de datos de RDS, debe proporcionar el ARN de la instancia de base de datos de
origen.
Creación de un nombre ARN para Amazon RDS

Cada recurso que se crea en Amazon Web Services se identifica de forma inequívoca mediante un
nombre de recurso de Amazon (ARN). Puede crear un ARN para un recurso de Amazon RDS utilizando la
siguiente sintaxis.
arn:aws:rds:<region>:<account number>:<resourcetype>:<name>

Name

Este
(Ohio)

Este
(Norte de
Virginia)

Oeste

354
Creación de un nombre ARN

Name
(Norte de
California)

Oeste
(Oregón)

Pacífico
(Hong
Kong)

Pacífico
(Mumbai)

(Osaka-
local)

(Seúl)

(Singapur)

(Sídney)

(Tokio)

(Central) central-1
China cn-north-1 rds.cn-north-1.amazonaws.com.cn HTTPS

(Beijing)



(Irlanda)

(Londres)

355
Creación de un nombre ARN

Name

(Estocolmo)

Oriente south-1
(Baréin)
América sa-east-1 rds.sa-east-1.amazonaws.com HTTPS

del Sur
(São
Paulo)

GovCloud east-1
(US-East)

GovCloud west-1
(EE.UU.)
En la siguiente tabla se muestra el formato que debe utilizar al crear un ARN para un tipo de recurso
concreto de Amazon RDS.
Tipo de recurso Formato de ARN
Instancia de base de datos arn:aws:rds:<region>:<account>:db:<name>
Por ejemplo:
arn:aws:rds:us-east-2:123456789012:db:my-mysql-instance-1
Clúster de base de datos arn:aws:rds:<region>:<account>:cluster:<name>
Por ejemplo:
arn:aws:rds:us-east-2:123456789012:cluster:my-aurora-
cluster-1
Suscripción a eventos arn:aws:rds:<region>:<account>:es:<name>
Por ejemplo:
arn:aws:rds:us-east-2:123456789012:es:my-subscription
Grupo de opciones de base de arn:aws:rds:<region>:<account>:og:<name>

datos
Por ejemplo:
arn:aws:rds:us-east-2:123456789012:og:my-og
Grupo de parámetros de base arn:aws:rds:<region>:<account>:pg:<name>

de datos

356
Obtención de un ARN existente
Tipo de recurso Formato de ARN

Por ejemplo:
arn:aws:rds:us-east-2:123456789012:pg:my-param-enable-logs
Grupo de parámetros de clúster arn:aws:rds:<region>:<account>:cluster-pg:<name>

de base de datos
Por ejemplo:
arn:aws:rds:us-east-2:123456789012:cluster-pg:my-cluster-
param-timezone
Instancia de base de datos arn:aws:rds:<region>:<account>:ri:<name>

reservada
Por ejemplo:
arn:aws:rds:us-east-2:123456789012:ri:my-reserved-
postgresql
Grupo de seguridad de base de arn:aws:rds:<region>:<account>:secgrp:<name>

datos
Por ejemplo:
arn:aws:rds:us-east-2:123456789012:secgrp:my-public
Instantánea de base de datos arn:aws:rds:<region>:<account>:snapshot:<name>
Por ejemplo:
arn:aws:rds:us-east-2:123456789012:snapshot:my-mysql-
snap-20130507
Instantánea de clúster de base arn:aws:rds:<region>:<account>:cluster-snapshot:<name>

de datos
Por ejemplo:
arn:aws:rds:us-east-2:123456789012:cluster-snapshot:my-
aurora-snap-20160809
Grupo de subred de base de arn:aws:rds:<region>:<account>:subgrp:<name>

datos
Por ejemplo:
arn:aws:rds:us-east-2:123456789012:subgrp:my-subnet-10

Puede obtener el ARN de un recurso de RDS mediante la Consola de administración de AWS, la AWS
Command Line Interface (AWS CLI) o la API de RDS.

357

Para obtener un ARN desde la Consola de administración de AWS, vaya al recurso cuyo ARN desea
obtener y consulte los detalles de ese recurso. Por ejemplo, puede obtener el ARN de una instancia de
base de datos desde la pestaña Configuration (Configuración) de los detalles de la instancia de base de
datos, como se muestra a continuación.

358

359
AWS CLI
Para obtener el ARN de un recurso concreto de RDS desde la AWS CLI, se utiliza el comando describe
con dicho recurso. En la siguiente tabla se muestran los distintos comandos de AWS CLI, junto con la
propiedad ARN que se utiliza con el comando para obtener un ARN.
Comando de AWS CLI Propiedad ARN
describe-event-subscriptions EventSubscriptionArn
describe-certificates CertificateArn
describe-db-parameter-groups DBParameterGroupArn
describe-db-cluster-parameter-groups DBClusterParameterGroupArn
describe-db-instances DBInstanceArn
describe-db-security-groups DBSecurityGroupArn
describe-db-snapshots DBSnapshotArn
describe-events SourceArn
describe-reserved-db-instances ReservedDBInstanceArn
describe-db-subnet-groups DBSubnetGroupArn
describe-option-groups OptionGroupArn
describe-db-clusters DBClusterArn
describe-db-cluster-snapshots DBClusterSnapshotArn
Por ejemplo, el siguiente comando de la AWS CLI obtiene el ARN de una instancia de base de datos.
Example
aws rds describe-db-instances \

--db-instance-identifier DBInstanceIdentifier \
--region us-west-2
Para Windows:
aws rds describe-db-instances ^

--db-instance-identifier DBInstanceIdentifier ^
--region us-west-2
API
Para obtener el ARN de un recurso concreto de RDS, puede llamar a las siguientes acciones de la API de
RDS y utilizar las propiedades ARN que se muestran a continuación.
Acción de API de RDS Propiedad ARN
DescribeEventSubscriptions EventSubscriptionArn

360
Actualizaciones de Aurora
Acción de API de RDS Propiedad ARN
DescribeCertificates CertificateArn
DescribeDBParameterGroups DBParameterGroupArn
DescribeDBClusterParameterGroups DBClusterParameterGroupArn
DescribeDBInstances DBInstanceArn
DescribeDBSecurityGroups DBSecurityGroupArn
DescribeDBSnapshots DBSnapshotArn
DescribeEvents SourceArn
DescribeReservedDBInstances ReservedDBInstanceArn
DescribeDBSubnetGroups DBSubnetGroupArn
DescribeOptionGroups OptionGroupArn
DescribeDBClusters DBClusterArn
DescribeDBClusterSnapshots DBClusterSnapshotArn
Actualizaciones de Amazon Aurora

Amazon Aurora publica de forma periódica actualizaciones. Las actualizaciones se aplican a clústeres
de base de datos de Amazon Aurora durante los períodos de mantenimiento del sistema. El momento
en el que se aplican las actualizaciones depende de la región y de la configuración del periodo de
mantenimiento para el clúster de la base de datos, así como del tipo de actualización. Las actualizaciones
exigen el reinicio de la base de datos, por lo que se producen entre 20 y 30 segundos de inactividad.
Tras esta inactividad, podrá volver a utilizar los clústeres de la base de datos. Puede ver o cambiar la
configuración del periodo de mantenimiento desde la Consola de administración de AWS.
A continuación, puede encontrar información acerca de actualizaciones generales a Amazon Aurora.

Algunas de las actualizaciones aplicadas a Amazon Aurora son específicas de un motor de base de datos
admitido por Aurora. Para obtener más información acerca de las actualizaciones del motor de base de
datos de Aurora, consulte la siguiente tabla.
Motor de base de datos Actualizaciones
Amazon Aurora MySQL Consulte Actualizaciones del motor de base de datos para Amazon
Aurora MySQL (p. 695)
Amazon Aurora PostgreSQL Consulte Actualizaciones del motor de base de datos para Amazon
Aurora PostgreSQL (p. 856)
Versiones de Amazon Aurora

Amazon Aurora incluye algunas características que son generales para Aurora y están disponibles para
todos los clústeres de base de datos Aurora. Aurora incluye otras características específicas de un
motor de base de datos en particular compatible con Aurora. Estas características están disponibles solo
para aquellos clústeres de base de datos Aurora que usan ese motor de base de datos, como Aurora
PostgreSQL.

361
Temas relacionados
Una instancia de base de datos Aurora proporciona dos números de versión, el número de versión de
Aurora y el número de versión del motor de base de datos Aurora. Los números de versión de Aurora
utilizan el siguiente formato.
<major version>.<minor version>.<patch version>
Para obtener el número de versión de Aurora a partir de una instancia de base de datos Aurora mediante
un motor de base de datos determinado, use una de las siguientes consultas.
Motor de base de datos Consultas
Amazon Aurora MySQL

SELECT AURORA_VERSION();
SHOW @@aurora_version;

SELECT AURORA_VERSION();
Temas relacionados

362
Información general sobre la monitorización
Monitorización de un clúster de base

de datos de Amazon Aurora
En esta sección se muestra cómo monitorizar Amazon Aurora. Aurora implica clústeres de servidores de
bases de datos que están conectados con una topología de replicación. Así, la monitorización de Aurora
exige comprobar el estado del servidor maestro (que se encarga de las operaciones de escritura) y las
réplicas de Aurora individuales (que distribuye la carga de trabajo de consultas entre múltiples servidores).
Temas
• Información general sobre la monitorización de Amazon RDS (p. 363)
• Visualización de un clúster de base de datos de Amazon Aurora (p. 375)
• Estado del clúster de base de datos (p. 380)
• Estado de la instancia de base de datos (p. 381)
• Monitorización de las métricas de un clúster de base de datos Amazon Aurora (p. 384)
• Monitorización mejorada (p. 395)
• Uso de Performance Insights de Amazon RDS (p. 402)
• Uso de recomendaciones de Amazon Aurora (p. 440)
• Uso de secuencias de actividades de la base de datos con Aurora PostgreSQL (p. 446)
• Uso de las notificaciones de eventos de Amazon RDS (p. 465)
• Consulta de eventos de Amazon RDS (p. 481)
• Archivos de registro de base de datos de Amazon RDS (p. 482)
• Registro de llamadas al API de Amazon RDS con AWS CloudTrail (p. 492)
Información general sobre la monitorización de

Amazon RDS
La monitorización es una parte importante del mantenimiento de la fiabilidad, la disponibilidad y el
rendimiento de Amazon RDS; y sus soluciones de AWS. Debe recopilar datos de monitorización de todas
las partes de su solución de AWS para que le resulte más sencillo depurar un error que se produce en
distintas partes del código, en caso de que ocurra. Antes de comenzar a monitorizar Amazon RDS, es
recomendable que cree un plan de monitorización que incluya respuestas a las siguientes preguntas:
• ¿Cuáles son los objetivos de la monitorización?

• ¿Qué recursos va a monitorizar?
• ¿Con qué frecuencia va a monitorizar estos recursos?
• ¿Qué herramientas de monitorización va a utilizar?
• ¿Quién se encargará de realizar las tareas de monitorización?
• ¿Quién debería recibir una notificación cuando surjan problemas?
El siguiente paso consiste en establecer un punto de referencia del desempeño normal de Amazon RDS
en su entorno. Para ello, se mide el desempeño en distintos momentos y bajo distintas condiciones de
carga. Cuando monitoree Amazon RDS, debe tener en cuenta el almacenamiento de los datos históricos
de monitoreo. Estos datos almacenados le darán un punto de referencia para compararlos con los datos
de desempeño actual, identificar los patrones de desempeño normales y las anomalías del desempeño e
idear métodos para solucionar problemas.

363
Herramientas de monitorización
Por ejemplo, con Amazon RDS, puede monitorizar el rendimiento de la red, el valor de E/S para las
operaciones de lectura, escritura o metadatos, las conexiones de clientes y los saldos de créditos de
ráfagas de sus instancias de base de datos. Cuando el rendimiento esté fuera de la referencia establecida,
es posible que necesite cambiar la clase de instancia de la instancia de base de datos o el número de
instancias de base de datos y réplicas de lectura que estén disponibles para los clientes con el fin de
optimizar la disponibilidad de la base de datos para su carga de trabajo.
En general, los valores aceptables para las métricas de desempeño dependen del aspecto de la referencia
y de lo que hace la aplicación. Investigue las variaciones coherentes o de las tendencias con respecto a la
referencia. La siguiente sección ofrece algunas sugerencias sobre tipos concretos de métricas:
• Consumo elevado de CPU o RAM: unos valores elevados de consumo de CPU o RAM pueden ser
adecuados si se ajustan a los objetivos de su aplicación (de rendimiento o simultaneidad, por ejemplo) y
son los esperados.
• Consumo de espacio en disco: investigue el consumo de espacio en el disco si el espacio utilizado está
por sistema alrededor o por encima del 85% del espacio total disponible en el disco. Compruebe si es
posible eliminar datos de la instancia o archivar los datos en un sistema diferente para liberar espacio.
• Tráfico de red: para el tráfico de red, hable con el administrador de su sistema para saber cuál es el
rendimiento esperado para la red de su dominio y para su conexión a Internet. Investigue el tráfico de
red si el rendimiento es por sistema inferior al esperado.
• Conexiones a bases de datos: valore la posibilidad de restringir las conexiones a las bases de datos si
ve que hay un alto número de conexiones de usuarios junto con una reducción en el rendimiento y el
tiempo de respuesta de la instancia. El mejor número de conexiones de usuarios para su instancia de
base de datos variará en función de la clase de instancia y de la complejidad de las operaciones que
se estén llevando a cabo. Puede determinar el número de conexiones a bases de datos asociando la
instancia de base de datos con un grupo de parámetros en el que el parámetro User Connections se
haya establecido en un valor distinto de 0 (ilimitado). Puede utilizar un grupo de parámetros existente o
crear uno nuevo. Para obtener más información, consulte Trabajo con los grupos de parámetros de base
de datos y grupos de parámetros de clúster de base de datos (p. 259).
• Métricas de IOPS: los valores esperados para las métricas de IOPS dependen de la especificación del
disco y la configuración del servidor, así que debe usar su referencia para conocer los valores típicos.
Investigue si los valores son por sistema diferentes de los de la referencia. Para un desempeño óptimo
de IOPS, asegúrese de que el conjunto de trabajo típico se ajuste a la memoria para minimizar las
operaciones de lectura y escritura.
AWS proporciona varias herramientas que puede utilizar para monitorizar Amazon RDS. Puede configurar
algunas de estas herramientas para que monitoricen por usted, pero otras herramientas requieren
intervención manual. Le recomendamos que automatice las tareas de monitorización en la medida de lo
posible.
Herramientas de monitorización automatizadas

Puede utilizar las siguientes herramientas de monitorización automatizado para vigilar Amazon RDS e
informar cuando haya algún problema:
• Eventos de Amazon RDS: suscríbase a los eventos de Amazon RDS si desea recibir una notificación
cuando se produzcan cambios en una instancia de base de datos, un clúster de base de datos, una
instantánea de clúster de base de datos, un grupo de parámetros de base de datos o un grupo de
seguridad de base de datos. Para obtener más información, consulte Uso de las notificaciones de
eventos de Amazon RDS (p. 465).
• Archivos de registro de base de datos: vea, descargue o supervise los archivos de registro de la base
de datos con la consola de Amazon RDS o las acciones de la API de Amazon RDS. También puede
consultar algunos archivos de registro de bases de datos que están cargados en las tablas de bases

364
de datos. Para obtener más información, consulte Archivos de registro de base de datos de Amazon
RDS (p. 482).
• Monitorización mejorada de Amazon RDS: examine métricas en tiempo real para el sistema operativo.
Para obtener más información, consulte Monitorización mejorada (p. 395).
Además, Amazon RDS se integra con Amazon CloudWatch para proporcionar funcionalidades de
monitorización adicionales:
• Métrica de Amazon CloudWatch: Amazon RDS envía métricas automáticamente a CloudWatch cada
minuto para cada instancia y clúster de base de datos activos. No se le cobrará ningún cargo adicional
por las métricas de Amazon RDS en CloudWatch. Para obtener más información, consulte the section
called “Visualización de métricas de una instancia de base de datos” (p. 373).
• Alarmas de Amazon CloudWatch: puede vigilar una única métrica de Amazon RDS durante un periodo
de tiempo determinado y realizar una o varias acciones según el valor de la métrica en relación con
un umbral que especifique. Para obtener más información, consulte Monitorización con Amazon
CloudWatch (p. 366)
• Amazon CloudWatch Logs: la mayoría de motores de base de datos permiten monitorizar, almacenar
y obtener acceso a los archivos de registro de base de datos en CloudWatch Logs. Para obtener más
información, consulte Amazon CloudWatch Logs User Guide
Herramientas de monitorización manual

Otra parte importante de la monitorización de Amazon RDS implica la monitorización manual de los
elementos que no cubren las alarmas de CloudWatch. Los paneles de Amazon RDS, CloudWatch, AWS
Trusted Advisor y otros paneles de consola de AWS proporcionan una vista rápida del entorno de AWS. Es
recomendable que también compruebe los archivos de registro de su DB instance.
• En la consola de Amazon RDS, puede monitorizar los siguientes elementos para sus recursos:
• Número de conexiones a una instancia de base de datos
• La cantidad de operaciones de lectura y escritura de una instancia de base de datos
• La cantidad de almacenamiento que está utilizando actualmente una instancia de base de datos
• La cantidad de memoria y de CPU que se está utilizando para una instancia de base de datos
• La cantidad de tráfico de red de entrada y salida de una instancia de base de datos
• En el panel de AWS Trusted Advisor, puede revisar las siguientes comprobaciones de optimización del
costo, seguridad, tolerancia a errores y mejora del desempeño:
• Amazon RDS Idle DB Instances
• Amazon RDS Security Group Access Risk
• Copias de seguridad de Amazon RDS
• Amazon RDS Multi-AZ
• Accesibilidad de instancias de base de datos de Aurora
Para obtener más información acerca de estas comprobaciones, consulte Prácticas recomendadas de
Trusted Advisor (verificaciones).
• La página de inicio de CloudWatch muestra:
• Alarmas y estado actual
• Gráficos de alarmas y recursos
• Estado de los servicios
Además, puede utilizar CloudWatch para hacer lo siguiente:

• Crear paneles personalizados para monitorizar los servicios que le interesan.
• Realizar un gráfico con los datos de las métricas para resolver problemas y descubrir tendencias
365
Monitorización con CloudWatch
• Buscar y examinar todas sus métricas de recursos de AWS.

• Crear y editar las alarmas de notificación de problemas
Monitorización con Amazon CloudWatch

Puede monitorizar instancias de bases de datos mediante Amazon CloudWatch, que recopila y procesa los
datos sin formato de Amazon RDS y los convierte en métricas legibles prácticamente en tiempo real. Estas
estadísticas se registran durante un periodo de dos semanas, de forma que pueda acceder a información
histórica y obtener una mejor perspectiva sobre el rendimiento de su aplicación web o servicio. De forma
predeterminada, los datos de las métricas de se envían automáticamente a Amazon RDS en períodos de
1 minuto. Para obtener más información acerca de CloudWatch, consulte ¿Qué son Amazon CloudWatch,
Amazon CloudWatch Events y Amazon CloudWatch Logs? en la Guía del usuario de Amazon CloudWatch.
Métricas y dimensiones de Amazon RDS

Cuando se usan recursos de Amazon RDS, Amazon RDS envía métricas y dimensiones a Amazon
CloudWatch cada minuto. Puede seguir los siguientes procedimientos para ver las métricas de Amazon
RDS.
Para consultar las métricas desde la consola de Amazon CloudWatch
Las métricas se agrupan en primer lugar por el espacio de nombres de servicio y, a continuación, por las
diversas combinaciones de dimensiones dentro de cada espacio de nombres.
1. Abra la consola de CloudWatch en https://console.aws.amazon.com/cloudwatch/.

2. Si es necesario, cambie la región de AWS. En la barra de navegación, seleccione la región de AWS
donde residen sus recursos de AWS. Para obtener más información, consulte Regiones y puntos de
enlace.
3. En el panel de navegación, seleccione Metrics. Elija el espacio de nombres de métrica de RDS.

366
4. Seleccione una dimensión de métrica, por ejemplo, By Database Class (Por clase de base de datos).
5. Para ordenar las métricas, utilice el encabezado de columna. Para representar gráficamente una
métrica, active la casilla de verificación situada junto a ella. Para filtrar por recurso, elija el ID de
recurso y, a continuación, elija Add to search (Añadir a la búsqueda). Para filtrar por métrica, elija el
nombre de la métrica y, a continuación, elija Add to search (Añadir a la búsqueda).

367
Para ver métricas mediante la AWS CLI
• En el símbolo del sistema, ejecute el siguiente comando:
aws cloudwatch list-metrics --namespace AWS/RDS
Métricas de Amazon RDS

El espacio de nombres de AWS/RDS incluye las siguientes métricas.
Métrica Descripción
BinLogDiskUsage La cantidad de espacio en disco ocupado por los logs binarios en el

nodo principal. Se aplica a las réplicas de lectura de MySQL.
Unidades: bytes
BurstBalance El porcentaje de créditos de E/S del bucket por ráfaga SSD de uso
general (gp2) disponibles.
Unidades: porcentaje
CPUUtilization El porcentaje de utilización de CPU.
Unidades: porcentaje
CPUCreditUsage [Instancias T2] La cantidad de créditos de CPU gastados por la

instancia para la utilización del CPU. Un crédito de CPU equivale a una
vCPU ejecutándose al 100% de utilización durante un minuto o una
combinación equivalente de unidades de vCPU, utilización y tiempo
(por ejemplo, una vCPU ejecutándose al 50% durante dos minutos o
dos vCPU ejecutándose al 25% durante dos minutos).
Las métricas de créditos de CPU solo están disponibles con una

frecuencia de cinco minutos. Si especifica un periodo superior a cinco
minutos, use la estadística Sum en lugar de Average.
Unidades: créditos (vCPU/minutos)
CPUCreditBalance [Instancias T2] La cantidad de créditos de CPU obtenidos que una

instancia ha acumulado desde que se lanzó o se inició. Para T2
Standard, el CPUCreditBalance incluye además el número de
créditos de lanzamiento que se han acumulado.
Los créditos se acumulan en el saldo de créditos una vez obtenidos

y se eliminan del saldo de créditos cuando se gastan. El saldo de
créditos tiene un límite máximo, determinado por el tamaño de la
instancia. Una vez que el límite se ha alcanzado, cualquier nuevo
crédito que se gane se descarta. Para T2 Standard, los créditos de
lanzamiento no cuentan para el límite.
Los créditos de CPUCreditBalance están disponibles para que la

instancia los gaste para aumentar la utilización de la CPU por encima
de la referencia.
Cuando una instancia está en ejecución, los créditos en el

CPUCreditBalance no caducan. Cuando se detiene la instancia,

368
el CPUCreditBalance no persiste y se pierden todos los créditos
acumulados.
Las métricas de créditos de CPU solo están disponibles cada cinco

minutos.
Unidades: créditos (vCPU/minutos)
DatabaseConnections El número de conexiones de base de datos en uso.
Unidades: recuento
DiskQueueDepth El número de operaciones de E/S pendientes (solicitudes de lectura/

escritura) a la espera de obtener acceso al disco.
Unidades: recuento
El número de trabajos del Agente SQL que han producido error durante
FailedSQLServerAgentJobsCount
el último minuto.
Unidad: recuento/minuto
FreeableMemory La cantidad de memoria de acceso aleatorio disponible.
Unidades: bytes
FreeStorageSpace La cantidad de espacio de almacenamiento disponible.
Unidades: bytes
MaximumUsedTransactionIDsEl ID de la transacción máxima que se ha utilizado. Se aplica a

PostgreSQL.
Unidades: recuento
NetworkReceiveThroughput El tráfico de red de entrada (recepción) en la instancia de base de

datos, incluidos el tráfico de base de datos del cliente y el tráfico de
Amazon RDS utilizado en monitorización y en replicación.
Unidades: bytes/segundo
NetworkTransmitThroughputEl tráfico de red de salida (transferencia) en la instancia de base de

datos, incluidos el tráfico de base de datos del cliente y el tráfico de
Amazon RDS utilizado en monitorización y en replicación.
OldestReplicationSlotLag El tamaño de retardo de la replica con mayor retardo en cuanto a los

datos de WAL recibidos. Se aplica a PostgreSQL.
Unidades: megabytes
ReadIOPS Número medio de operaciones de E/S de lectura en disco por segundo.
Unidades: recuento/segundo
ReadLatency Tiempo medio de cada operación de E/S en el disco.
Unidades: segundos

369
ReadThroughput El número medio de bytes leídos del disco por segundo.
ReplicaLag La cantidad de retraso de una instancia de base de datos de réplica

de lectura con respecto a la instancia de base de datos de origen. Se
aplica a las réplicas de lectura de MySQL, MariaDB y PostgreSQL.
Unidades: segundos
ReplicationSlotDiskUsage El espacio de disco utilizado por los archivos de ranura de la

replicación. Se aplica a PostgreSQL.
Unidades: megabytes
SwapUsage La cantidad de espacio de intercambio utilizado en la instancia de base

de datos. Esta métrica no está disponible para SQL Server.
Unidades: bytes
TransactionLogsDiskUsage El espacio de disco utilizado por los registros de transacciones. Se

aplica a PostgreSQL.
Unidades: megabytes
TransactionLogsGenerationEl tamaño de los registros de transacciones generados por segundo.

Se aplica a PostgreSQL.
WriteIOPS Número medio de operaciones de E/S de escritura en disco por

segundo.
Unidades: recuento/segundo
WriteLatency Tiempo medio de cada operación de E/S en el disco.
Unidades: segundos
WriteThroughput Número medio de bytes que se escriben en el disco por segundo.
Dimensiones en Amazon RDS

Los datos de las métricas de Amazon RDS se pueden filtrar por cualquiera de las dimensiones de la tabla
siguiente:
Dimensión Descripción
DBInstanceIdentifier Esta dimensión filtra los datos solicitados para una instancia de base
de datos específica.
DBClusterIdentifier Esta dimensión filtra los datos solicitados para un clúster de base de
datos de Amazon Aurora específico.

370
Dimensión Descripción
DBClusterIdentifier, Esta dimensión filtra los datos solicitados para un clúster de base
Role de datos de Aurora específico, agrupando las métricas por rol de
instancia (WRITER/READER). Por ejemplo, puede agregar métricas
para todas las instancias READER que pertenezcan a un clúster.
DatabaseClass Esta dimensión filtra los datos solicitados para todas las instancias
de una clase de base de datos. Por ejemplo, puede agregar métricas
para todas las instancias que pertenezcan a la clase de base de
datos db.m1.small.
EngineName Esta dimensión filtra los datos solicitados únicamente para el nombre
de motor identificado. Por ejemplo, puede agregar métricas para
todas las instancias que tengan el nombre de motor mysql.
SourceRegion Esta dimensión filtra únicamente los datos solicitados para la región
especificada. Por ejemplo, puede agregar métricas para todas las
instancias en la región us-east-1.
Creación de alarmas de CloudWatch para monitorizar Amazon RDS

Puede crear una alarma de CloudWatch que envíe un mensaje de Amazon SNS cuando la alarma cambie
de estado. Una alarma vigila una única métrica durante el periodo especificado y realiza una o varias
acciones en función del valor de la métrica relativo a un determinado umbral durante una serie de periodos
de tiempo. La acción es una notificación que se envía a un tema de Amazon SNS o a una política de Auto
Scaling.
Las alarmas invocan acciones únicamente para los cambios de estado prolongados. Las alarmas de
CloudWatch no invocarán acciones simplemente por tener un estado determinado. Es necesario que
el estado haya cambiado y se mantenga durante un número especificado de períodos. Los siguientes
procedimientos muestran cómo crear alarmas para Amazon RDS.
Para establecer alarmas utilizando la consola de CloudWatch
1. Inicie sesión en la Consola de administración de AWS y abra la consola de CloudWatch en https://

console.aws.amazon.com/cloudwatch/.
2. Elija Alarms (Alarmas) y, a continuación, seleccione Create Alarm (Crear alarma). Esto lanza el Create
Alarm Wizard (Asistente de creación de alarmas).
3. Elija RDS Metrics (Metricas de RDS) y desplácese a través de las métricas de Amazon RDS para
localizar la métrica donde desea colocar una alarma. Para mostrar solo las métricas de Amazon RDS
en este cuadro de diálogo, busque el identificador de su recurso. Seleccione la métrica para crear una
alarma y, a continuación, elija Next (Siguiente).
4. Escriba valores para Name (Nombre), Description (Descripción) y Whenever (Siempre que) para la
métrica.
5. Si desea que CloudWatch le envíe un correo electrónico cuando se alcance el estado de la alarma,
para Whenever this alarm: (Siempre que esta alarma:), elija State is ALARM (El estado es ALARM).
En Send notification to: (Enviar notificación a), seleccione un tema de SNS existente. Si elige Create
topic (Crear tema), puede definir el nombre y las direcciones de correo electrónico de una nueva lista
de suscripción de correo electrónico. Esta lista se guarda y aparece en el campo para futuras alarmas.
Note
Si utiliza Create topic para crear un nuevo tema de Amazon SNS, debe verificar las
direcciones de correo electrónico para que reciban notificaciones. Los correos electrónicos
solo se envían cuando la alarma entra en estado de alarma. Si este cambio en el estado de

371
Publicación en CloudWatch Logs
la alarma se produce antes de que se verifiquen las direcciones de correo electrónico, no

reciben una notificación.
6. En este momento, el área Alarm Preview le ofrece la oportunidad de previsualizar la alarma que está a
punto de crear. Elija Create Alarm.
Para configurar una alarma mediante la AWS CLI
• Llame a put-metric-alarm. Para obtener más información, consulte AWS CLI Command
Reference.
Para configurar una alarma mediante la API de CloudWatch
• Llame a PutMetricAlarm. Para obtener más información, consulte Amazon CloudWatch API
Reference
Publicación de registros del motor de base de datos

en Amazon CloudWatch Logs
Puede configurar el motor de base de datos de Amazon RDS para publicar datos de registro en un grupo
de registros en Amazon CloudWatch Logs. Con CloudWatch Logs, puede realizar análisis en tiempo
real de los datos de registro y utilizar CloudWatch para crear alarmas y ver métricas. Puede utilizar
CloudWatch Logs para almacenar conjuntos de registros en un almacenamiento de larga duración, que
puede administrar con el agente de CloudWatch Logs. Por ejemplo, puede determinar cuándo se deben
rotar los registros de registros desde un host al servicio de registros, para que pueda obtener acceso a los
registros sin formato cuando lo necesite.
Puede exportar registros de Aurora MySQL. Para obtener más información, consulte the section called
“Publicación de registros de Aurora MySQL en CloudWatch Logs” (p. 662).
Note
Debe tener un rol vinculado a servicio antes de activar la publicación de los datos de registro.
Para obtener más información acerca de los roles vinculados a servicios, consulte Uso de roles
vinculados a servicios en Amazon Aurora (p. 207).
Configuración de la integración con CloudWatch Logs

Para publicar archivos de registro de base de datos en CloudWatch Logs, elija los registros que desea
publicar. Realice esta selección en la sección Advanced Settings al crear una instancia de base de datos
nueva. También puede modificar una instancia de base de datos existente para comenzar la publicación.

372
Una vez activada la publicación, Amazon RDS transfiere continuamente todos los registros de la instancia
de base de datos a un grupo de registros. Por ejemplo, hay un grupo de registros /aws/rds/instance/
log type para cada tipo de registro que se publica. Este grupo de registros se encuentra en la misma
región de AWS que la instancia de base de datos que genera el registro.
Después de publicar los registros, puede utilizar CloudWatch Logs para buscar y filtrar los registros. Para
obtener más información sobre la búsqueda y el filtrado registros, consulte Búsqueda y filtrado de datos de
registros.
Visualización de métricas de una instancia de base de datos

Amazon RDS proporciona métricas para que pueda monitorizar el estado de sus instancias de base de
datos. Puede monitorizar tanto las métricas de las instancias de base de datos como las métricas del
sistema operativo (SO).
En esta sección se proporcionan detalles relativos al procedimiento para ver las métricas de una instancia
de base de datos usando la consola de RDS y CloudWatch. Para obtener información acerca de la
monitorización de métricas para el sistema operativo de su instancia de base de datos en tiempo real por
medio de CloudWatch Logs, consulte Monitorización mejorada (p. 395).
Visualización de métricas con la consola
Para ver métricas de base de datos y de sistema operativo para una instancia de base de datos
3. Seleccione el nombre de la instancia de base de datos sobre la que necesite información para mostrar
sus detalles.
4. Elija la pestaña Monitoring (Monitorización).
5. En Monitoring (Monitorización), elija la opción que desea usar para ver las métricas entre las
siguientes:
• CloudWatch: muestra un resumen de las métricas de instancia de base de datos disponibles en

Amazon CloudWatch. Cada métrica incluye un gráfico que muestra la métrica monitorizada a lo
largo de un periodo de tiempo concreto.

373
• Enhanced monitoring (Monitorización mejorada): muestra un resumen de las métricas de SO

disponibles para una instancia de base de datos con la monitorización mejorada habilitada. Cada
métrica incluye un gráfico que muestra la métrica monitorizada a lo largo de un periodo de tiempo
concreto.
• OS Process list (Lista de procesos de sistema operativo): muestra los detalles de cada proceso que
se ejecuta en la instancia seleccionada.
Tip
Puede seleccionar el intervalo de tiempo de las métricas representadas por los gráficos con la
lista de intervalos de tiempo.
Puede elegir cualquier gráfico para mostrar una vista más detallada. También puede aplicar
filtros específicos de métrica a los datos.
Visualizar métricas de instancia de base de datos con la CLI o la API

Amazon RDS se integra con las métricas de CloudWatch para proporcionar varias métricas de instancia de
base de datos. Puede ver las métricas de CloudWatch mediante la consola de RDS, la AWS CLI o la API.
Para ver una lista completa de las métricas de Amazon RDS, vaya a Dimensiones y métricas de Amazon
RDS en la Guía del usuario de Amazon CloudWatch.
Visualización de las métricas de base de datos con la CLI de CloudWatch

Note
El siguiente ejemplo de la CLI requiere el uso de las herramientas de línea de comandos de
CloudWatch. Para obtener más información sobre CloudWatch y para descargar las herramientas
para desarrolladores, consulte la página del producto de Amazon CloudWatch. Los valores de
StartTime y EndTime proporcionados en este ejemplo se proporcionan con fines ilustrativos.

374
Visualización de un clúster de base de datos
Debe sustituir estos valores por los tiempos de inicio y finalización adecuados para su instancia de
base de datos.
Para ver las estadísticas de uso y desempeño de una instancia de base de datos
• Use el comando mon-get-stats de CloudWatch con los siguientes parámetros.
PROMPT>mon-get-stats FreeStorageSpace --dimensions="DBInstanceIdentifier=mydbinstance"

--statistics= Average
--namespace="AWS/RDS" --start-time 2009-10-16T00:00:00 --end-time 2009-10-16T00:02:00
Visualización de métricas de base de datos con la API de CloudWatch

Los valores de StartTime y EndTime proporcionados en este ejemplo se proporcionan con fines
ilustrativos. Debe sustituir estos valores por los tiempos de inicio y finalización adecuados para su instancia
de base de datos.
Para ver las estadísticas de uso y desempeño de una instancia de base de datos
• Llame a CloudWatch de la API de GetMetricStatistics con los siguientes parámetros:
• Statistics.member.1 = Average
• Namespace = AWS/RDS
• StartTime = 2009-10-16T00:00:00
• EndTime = 2009-10-16T00:02:00
• Period = 60
• MeasureName = FreeStorageSpace
Visualización de un clúster de base de datos de

Amazon Aurora
Dispone de varias opciones para ver información acerca de los clústeres de base de datos de Amazon
Aurora y de las instancias de bases de datos que contienen.
• Puede ver clústeres e instancias de base de datos en la consola de Amazon RDS eligiendo Databases
(Bases de datos) en el panel de navegación.
• Puede obtener información de los clústeres e instancias de base de datos con la AWS Command Line
Interface (AWS CLI).
• Puede obtener información de los clústeres e instancias de base de datos con la API de Amazon RDS.

En Amazon RDS, puede ver la información sobre un clúster de base de datos si elige Databases (Bases
de datos) desde el panel de navegación de la consola. También puede ver los detalles sobre las instancias
de base de datos que son miembros de un clúster de base de datos de Amazon Aurora en la página
Databases (Bases de datos).
La lista Databases (Bases de datos) muestra todos los clústeres de base de datos para su cuenta de AWS.
Al elegir un clúster de base de datos se muestra información sobre él y también una lista con las instancias
de base de datos que son miembros de ese clúster. Puede elegir el identificador de una instancia de base
de datos en la lista para ir directamente a su página de detalles en la consola de RDS.

375
Para ver la página de detalles de un clúster de base de datos, elija Databases (Bases de datos) en el panel
de navegación y, a continuación, elija el nombre del clúster de base de datos.
Puede modificar el clúster de base de datos si elige Databases (Bases de datos) en el panel de
navegación de la consola para ir a la lista Databases (Bases de datos). Para modificar un clúster de base
de datos, elíjalo en la lista Databases (Bases de datos) y, a continuación, elija Modify (Modificar).
Para modificar una instancia de base de datos miembro de un clúster de base de datos, elija Databases
(Bases de datos) en el panel de navegación de la consola para dirigirse a la lista Databases (Bases de
datos).
Por ejemplo, la siguiente imagen muestra la página de detalles para el clúster llamado aurora-sample-
cluster. El clúster de base de datos tiene una instancia de base de datos que aparece en la lista DB
Cluster Members (Miembros del clúster de base de datos), denominada aurora-sample. Se trata de la
instancia principal del clúster de base de datos.
Al hacer clic en el enlace del identificador de instancias de bases de datos aurora-sample, la consola de
Amazon RDS le llevará a la página de detalles de la instancia de base de datos aurora-sample como se
muestra en la imagen siguiente.

376
CLI
CLI
Para ver información de un clúster de base de datos con la AWS CLI utilice el comando describe-db-
clusters. Por ejemplo, el comando de la AWS CLI siguiente muestra información del clúster de base de
datos todos los clústeres de base de datos la región us-east-1 para la cuenta de AWS configurada.
aws rds describe-db-clusters --region us-east-1
Si la AWS CLI está configurada para salida JSON, el comando devuelve lo siguiente.
{
"DBClusters": [
{
"Engine": "aurora",
"Endpoint": "sample-cluster1.cluster-123456789012.us-east-1.rds.amazonaws.com"
"AllocatedStorage": 1,
"DBClusterIdentifier": "sample-cluster1",
"MasterUsername": "mymasteruser",
"DBClusterMembers": [
{
"IsClusterWriter": false,
"DBClusterParameterGroupStatus": "in-sync",
"DBInstanceIdentifier": "sample-replica"
},
{
"IsClusterWriter": true,
"DBInstanceIdentifier": "sample-primary"
}
],
"Port": 3306,
"PreferredBackupWindow": "03:34-04:04",
"VpcSecurityGroups": [
{
"Status": "active",
"VpcSecurityGroupId": "sg-ddb65fec"
}
],

377
CLI
"DBSubnetGroup": "default",
"DatabaseName": "sample",
"DBClusterParameterGroup": "default.aurora5.6",
"BackupRetentionPeriod": 1,
"AvailabilityZones": [
"us-east-1b",
"us-east-1c",
"us-east-1d"
],
"LatestRestorableTime": "2016-03-31T20:06:08.903Z",
"PreferredMaintenanceWindow": "wed:08:15-wed:08:45"
},
{
"Engine": "aurora",
"Endpoint": "aurora-sample.cluster-123456789012.us-east-1.rds.amazonaws.com",
"AllocatedStorage": 1,
"DBClusterIdentifier": "aurora-sample-cluster",
"MasterUsername": "mymasteruser",
"DBClusterMembers": [
{
"IsClusterWriter": false,
"DBInstanceIdentifier": "aurora-replica-sample"
},
{
"IsClusterWriter": true,
"DBInstanceIdentifier": "aurora-sample"
}
],
"Port": 3306,
"PreferredBackupWindow": "10:20-10:50",
"VpcSecurityGroups": [
{
"Status": "active",
"VpcSecurityGroupId": "sg-55da224b"
}
],
"DBSubnetGroup": "default",
"DatabaseName": "sample",
"DBClusterParameterGroup": "default.aurora5.6",
"BackupRetentionPeriod": 1,
"AvailabilityZones": [
"us-east-1b",
"us-east-1c",
"us-east-1d"
],
"LatestRestorableTime": "2016-03-31T20:00:11.491Z",
"PreferredMaintenanceWindow": "sun:03:53-sun:04:23"
}
]
}

378
API
API
Para ver información de un clúster de base de datos con la API de Amazon RDS, utilice la acción
DescribeDBClusters. Por ejemplo, el siguiente comando de la API de Amazon RDS muestra información
de todos los clústeres de base de datos la región us-east-1.
?Action=DescribeDBClusters
&MaxRecords=100
&SignatureVersion=4
&Version=2014-10-31
&X-Amz-Date=20140722T200807Z
&X-Amz-Signature=2d4f2b9e8abc31122b5546f94c0499bba47de813cb875f9b9c78e8e19c9afe1b
La acción devuelve lo siguiente:
<DescribeDBClustersResponse xmlns="http://rds.amazonaws.com/doc/2014-10-31/">
<DescribeDBClustersResult>
<DBClusters>
<DBCluster>
<Engine>aurora5.6</Engine>
<Status>available</Status>
<BackupRetentionPeriod>0</BackupRetentionPeriod>
<DBSubnetGroup>my-subgroup</DBSubnetGroup>
<EngineVersion>5.6.10a</EngineVersion>
<Endpoint>sample-cluster2.cluster-cbfvmgb0y5fy.us-east-1.rds.amazonaws.com</
Endpoint>
<DBClusterIdentifier>sample-cluster2</DBClusterIdentifier>
<PreferredBackupWindow>04:45-05:15</PreferredBackupWindow>
<PreferredMaintenanceWindow>sat:05:56-sat:06:26</PreferredMaintenanceWindow>
<DBClusterMembers/>
<AllocatedStorage>15</AllocatedStorage>
<MasterUsername>awsuser</MasterUsername>
</DBCluster>
<DBCluster>
<Engine>aurora5.6</Engine>
<Status>available</Status>
<BackupRetentionPeriod>0</BackupRetentionPeriod>
<DBSubnetGroup>my-subgroup</DBSubnetGroup>
<EngineVersion>5.6.10a</EngineVersion>
<Endpoint>sample-cluster3.cluster-cefgqfx9y5fy.us-east-1.rds.amazonaws.com</
Endpoint>
<DBClusterIdentifier>sample-cluster3</DBClusterIdentifier>
<PreferredBackupWindow>07:06-07:36</PreferredBackupWindow>
<PreferredMaintenanceWindow>tue:10:18-tue:10:48</PreferredMaintenanceWindow>
<DBClusterMembers>
<DBClusterMember>
<IsClusterWriter>true</IsClusterWriter>
<DBInstanceIdentifier>sample-cluster3-master</DBInstanceIdentifier>
</DBClusterMember>
<DBClusterMember>
<IsClusterWriter>false</IsClusterWriter>
<DBInstanceIdentifier>sample-cluster3-read1</DBInstanceIdentifier>
</DBClusterMember>
</DBClusterMembers>
<AllocatedStorage>15</AllocatedStorage>
<MasterUsername>awsuser</MasterUsername>
</DBCluster>
</DBClusters>

379
Estado del clúster de base de datos
</DescribeDBClustersResult>
<ResponseMetadata>
<RequestId>d682b02c-1383-11b4-a6bb-172dfac7f170</RequestId>
</ResponseMetadata>
</DescribeDBClustersResponse>
Estado del clúster de base de datos

El estado de un clúster de base de datos indica la situación de este. Puede ver el estado de un clúster de
base de datos usando la consola de Amazon RDS, el comando describe-db-clusters de la AWS CLI o la
acción DescribeDBClusters de la API.
Note
Aurora también usa otro estado llamado estado de mantenimiento, que se muestra en la columna
Maintenance (Mantenimiento) de la consola de Amazon RDS. Este valor indica el estado de
los parches de mantenimiento que se deben aplicar a un clúster de base de datos. El estado
de mantenimiento es independiente del estado del clúster de base de datos. Para obtener más
información acerca del estado de mantenimiento, consulte Aplicación de actualizaciones a un
clúster de base de datos o clúster de base de datos (p. 342).
Encuentre los valores de estado posibles para clústeres de base de datos en la siguiente tabla.
Estado del clúster de base de Descripción

datos
available El clúster de base de datos funciona correctamente y está disponible.
backing-up Se está creando una copia de seguridad del clúster de base de

datos.
backtracking Se están realizando actualmente búsquedas de datos anteriores

en el clúster de base de datos. Este estado solo se aplica a Aurora
MySQL.
cloning-failed La clonación de un clúster de base de datos no se ha realizado

correctamente.
creating Se está creando el clúster de base de datos. No se puede obtener

acceso al clúster de base de datos mientras se está creando.
deleting Se está eliminando el clúster de base de datos.
failing-over Se está realizando una conmutación por error de la instancia

principal a una réplica de Aurora.
inaccessible-encryption- No se puede obtener acceso a la clave de AWS KMS utilizada para

credentials cifrar o descifrar el clúster de base de datos.
maintenance Amazon RDS está aplicando una actualización de mantenimiento al

clúster de base de datos. Este estado se usa para el mantenimiento
de nivel de clúster de base de datos que RDS programa con mucha
antelación.
migrating Se está restaurando una instantánea de clúster de base de datos en

un clúster de base de datos.

380
Estado de la instancia de base de datos
Estado del clúster de base de Descripción

datos
migration-failed Una migración no se ha realizado correctamente.
modifying El clúster de base de datos se está modificando porque un cliente ha

solicitado su modificación.
promoting Una réplica de lectura se está promoviendo a un clúster de base de

datos independiente.
renaming El nombre del clúster de base de datos se está cambiando porque un

cliente lo ha solicitado.
resetting-master-credentials Las credenciales maestras del clúster de base de datos se están

restableciendo porque un cliente lo ha solicitado.
starting El clúster de base de datos se está iniciando.
stopped El clúster de base de datos se detiene.
stopping Se está deteniendo el clúster de base de datos.
update-iam-db-auth Se está actualizando la autorización de IAM para el clúster de base

de datos.
upgrading Se está actualizando la versión del motor de clúster de base de

datos.

El estado de una instancia de base de datos indica la situación de la instancia de base de datos. Puede ver
el estado de una instancia de base de datos usando la consola de Amazon RDS, el comando describe-db-
instances de la AWS CLI o la acción DescribeDBInstances de la API.
Note
Amazon RDS también usa otro estado llamado estado de mantenimiento, que se muestra en
la columna Maintenance (Mantenimiento) de la consola de Amazon RDS. Este valor indica el
estado de los parches de mantenimiento que se deben aplicar a una instancia de base de datos.
El estado de mantenimiento es independiente del estado de la instancia de base de datos.
Para obtener más información acerca del estado de mantenimiento, consulte Aplicación de
actualizaciones a un clúster de base de datos o clúster de base de datos (p. 342).
Encuentre los valores de estado posibles para instancias de base de datos en la tabla siguiente, que
muestra también cómo se factura para cada estado. Le muestra si se le facturará la instancia de base de
datos y el almacenamiento, si se le facturará solo el almacenamiento o si no se le facturará. Para todos los
estados de instancia de base de datos, se le factura siempre el uso de copia de seguridad.
Estado de la instancia de FacturadoDescripción

base de datos
available FacturadoLa instancia de base de datos funciona correctamente y está

disponible.
backing-up FacturadoSe está creando una copia de seguridad de la instancia de base de

datos.

381

base de datos
backtracking FacturadoSe está realizando actualmente búsquedas de datos anteriores en

la instancia de base de datos. Este estado solo se aplica a Aurora
MySQL.
configuring-enhanced- FacturadoLa monitorización mejorada se está habilitando o deshabilitando

monitoring para esta instancia de base de datos.
configuring-iam- FacturadoLa autenticación de bases de datos en AWS Identity and Access

database-auth Management (IAM) se está habilitando o deshabilitando para esta
configuring-log-exports FacturadoLa publicación de archivos de registro en Amazon CloudWatch Logs

se está habilitando o deshabilitando para esta instancia de base de
datos.
converting-to-vpc FacturadoLa instancia de base de datos se está convirtiendo de una instancia

de base de datos que no está en una Amazon Virtual Private Cloud
(Amazon VPC) a una instancia de base de datos que está en una
Amazon VPC.
creating No La instancia de base de datos se está creando. No se puede

facturadoobtener acceso a la instancia de base de datos mientras se está
creando.
eliminando No Se está eliminando la instancia de base de datos.

facturado
error No La instancia de base de datos ha generado un error y Amazon RDS

facturadono puede recuperarla. Realice una restauración al último momento
restaurable de la instancia de base de datos para recuperar los
datos.
inaccessible-encryption- No No se puede obtener acceso a la clave de AWS KMS utilizada para

credentials facturadocifrar o descifrar la instancia de base de datos.
incompatible-network No Amazon RDS está intentando realizar una acción de recuperación

facturadoen una instancia de base de datos, pero no puede hacerlo porque la
VPC está en un estado que impide completar la acción. Este estado
puede darse si, por ejemplo, todas las direcciones IP disponibles
en una subred están en uso y Amazon RDS no puede obtener una
dirección IP para la instancia de base de datos.
incompatible-option- FacturadoAmazon RDS ha intentado aplicar un cambio en el grupo de

group opciones, pero no puede hacerlo y no puede revertir al estado
anterior del grupo de opciones. Para obtener información, consulte
la lista Recent Events (Eventos recientes) para la instancia de base
de datos. Este estado puede darse si, por ejemplo, el grupo de
opciones contiene una opción como TDE y la instancia de base de
datos no contiene información cifrada.

382

base de datos
incompatible-parameters FacturadoAmazon RDS no puede iniciar la instancia de base de datos porque

los parámetros especificados en el grupo de parámetros de base de
datos de la instancia de base de datos no son compatibles con la
instancia de base de datos. Revierta los cambios de los parámetros
o hágalos compatibles con la instancia de base de datos para
recuperar el acceso a la instancia de base de datos. Para obtener
más información acerca de los parámetros incompatibles, consulte
la lista Recent Events (Eventos recientes) de la instancia de base
de datos.
incompatible-restore No Amazon RDS no puede realizar una restauración a un momento

facturadodado. Las causas habituales para este estado incluyen el uso de
tablas temporales, el uso de tablas de MyISAM con MySQL o el uso
de tablas de Aria con MariaDB.
maintenance FacturadoAmazon RDS está aplicando una actualización de mantenimiento

a la instancia de base de datos. Este estado se usa para el
mantenimiento de nivel de instancia que RDS programa con mucha
antelación.
modifying FacturadoLa instancia de base de datos se está modificando porque un

cliente ha solicitado su modificación.
moving-to-vpc FacturadoLa instancia de base de datos se está moviendo a una nueva

Amazon Virtual Private Cloud (Amazon VPC).
rebooting FacturadoLa instancia de base de datos se está reiniciando porque un

cliente o un proceso de Amazon RDS que requiere el reinicio lo ha
solicitado.
renaming FacturadoEl nombre de la instancia de base de datos se está cambiando

porque un cliente lo ha solicitado.
resetting-master- FacturadoLas credenciales maestras de la instancia de base de datos se

credentials están restableciendo porque un cliente lo ha solicitado.
restore-error FacturadoLa instancia de base de datos ha registrado un error al intentar

restaurar a un momento dado o a partir de una instantánea.
starting FacturadoLa instancia de base de datos se está iniciando.

para
almacenamiento
stopped FacturadoLa instancia de base de datos se ha detenido.

para
almacenamiento
deteniendo FacturadoLa instancia de base de datos se está deteniendo.

para
almacenamiento

383
Monitorización de las métricas de
un clúster de base de datos Aurora

base de datos
storage-full FacturadoLa instancia de base de datos ha alcanzado su asignación de

capacidad de almacenamiento. Se trata de un estado crítico y le
recomendamos que corrija este problema de inmediato. Para ello,
aumente la escala del almacenamiento modificando la instancia
de base de datos. Para evitar esta situación, defina las alarmas de
Amazon CloudWatch para que se le advierta cuando el espacio de
almacenamiento está bajando.
storage-optimization FacturadoLa instancia de base de datos se está modificando para cambiar el

tamaño o el tipo de almacenamiento. La instancia de base de datos
está totalmente operativa. Sin embargo, mientras su estado sea
storage-optimization (Optimización de almacenamiento), no podrá
solicitar ningún cambio del almacenamiento de dicha instancia. El
proceso de optimización del almacenamiento suele durar poco, pero
a veces puede tardar 24 horas o más.
upgrading Facturadola versión del motor de base de datos se está actualizando.
Monitorización de las métricas de un clúster de

base de datos Amazon Aurora
Amazon Aurora proporciona diversas métricas de Amazon CloudWatch que se pueden monitorizar
para determinar el estado y el rendimiento de un clúster de base de datos Aurora. Puede utilizar varias
herramientas, como la consola de administración de Amazon RDS, la interfaz de línea de comandos (CLI)
de AWS y la API de CloudWatch para ver las métricas de Aurora. Para obtener más información, consulte
Monitorización de un clúster de base de datos de Amazon Aurora (p. 363).
Métricas de Amazon Aurora

Las siguientes métricas están disponibles en Amazon Aurora.
Métricas de Amazon Aurora

El espacio de nombres AWS/RDS incluye las siguientes métricas que se aplican a entidades de base de
datos que se ejecutan en Amazon Aurora.
Métrica Descripción Se aplica a
Número medio de transacciones que se ejecutan

ActiveTransactions Aurora MySQL
en una instancia de base de datos de Aurora por
segundo.
De forma predeterminada, Aurora no habilita

esta métrica. Para comenzar a medir este valor,
establezca innodb_monitor_enable='all' en
el grupo de parámetros de base de datos para una
instancia de base de datos específica.
Cantidad de tiempo de retraso de un clúster

AuroraBinlogReplicaLag Aurora MySQL
de base de datos de réplica que se ejecuta en

384
Métricas de Aurora MySQL

Compatibilidad de Aurora con MySQL con respecto
al clúster de base de datos de origen.
Esta métrica indica el valor del campo

Seconds_Behind_Master del comando SHOW
SLAVE STATUS de MySQL. Esta métrica resulta
útil para monitorizar el retardo de replicación entre
los clústeres de base de datos de Aurora que
se están replicando entre distintas regiones de
AWS. Para obtener más información, consulte
Replicación de Aurora MySQL.
Unidades: bytes
AuroraGlobalDBReplicatedWriteIO Aurora MySQL
Unidades: bytes
AuroraGlobalDBDataTransferBytes Aurora MySQL
Unidades: milisegundos
AuroraGlobalDBReplicationLag Aurora MySQL
Para una réplica de Aurora, retardo en

AuroraReplicaLag Aurora MySQL y Aurora
milisegundos que se da cuando la replicación PostgreSQL
actualiza desde la instancia principal.
Retardo máximo en milisegundos entre la instancia

AuroraReplicaLagMaximum Aurora MySQL y Aurora
principal y cada instancia de base de datos de PostgreSQL
Aurora del clúster de base de datos.
Retardo mínimo en milisegundos entre la instancia

AuroraReplicaLagMinimum Aurora MySQL y Aurora
principal y cada instancia de base de datos de PostgreSQL
Aurora del clúster de base de datos.
Número de registros de cambios en el seguimiento

BacktrackChangeRecordsCreationRate Aurora MySQL
de datos anteriores que se crean a lo largo de
cinco minutos en el clúster de base de datos.
Número real de registros de cambios en el

BacktrackChangeRecordsStored Aurora MySQL
seguimiento de datos anteriores que se han
utilizado en el clúster de base de datos.
Diferencia entre el intervalo de destino para el

BacktrackWindowActual Aurora MySQL
seguimiento de datos anteriores y el intervalo real.
Número de veces que el intervalo real para el

BacktrackWindowAlert Aurora MySQL
seguimiento de datos anteriores es inferior al de
destino en un determinado periodo.
La cantidad total de almacenamiento de copias

BackupRetentionPeriodStorageUsed Aurora MySQL y Aurora
de seguridad en GiB utilizada para permitir la PostgreSQL
restauración a un momento dado dentro del
periodo de retención de copias de seguridad
del clúster de base de datos de Aurora. Se
incluye en el total registrado por la métrica
TotalBackupStorageBilled. Se calcula de
forma independiente para cada clúster de Aurora.
Para obtener instrucciones, consulte Descripción
del uso de almacenamiento de copias de seguridad
en Aurora (p. 316).
Unidades: Gibibytes (GiB)

385
La cantidad de espacio en disco ocupado por los

BinLogDiskUsage Aurora MySQL
logs binarios en el nodo principal, en bytes.
Número medio de transacciones de la base de

BlockedTransactions Aurora MySQL
datos que se bloquean cada segundo.
Porcentaje de solicitudes que se responden desde

BufferCacheHitRatio Aurora MySQL y Aurora
la caché de búfer. PostgreSQL
CommitLatency Cantidad de latencia de las operaciones de Aurora MySQL y Aurora

confirmación en milisegundos. PostgreSQL
Número medio de operaciones de confirmación por

CommitThroughput Aurora MySQL y Aurora
segundo. PostgreSQL
Número de créditos de CPU que ha acumulado

CPUCreditBalance Aurora MySQL
una instancia. Esta métrica solo tiene validez
para las instancias de db.t2.small y
db.t2.medium . Se usa para determinar cuánto
tiempo puede una instancia de base de datos de
Aurora MySQL sobrepasar temporalmente su nivel
de desempeño de referencia a una velocidad dada.
Note
Las métricas de créditos de CPU se

indican a intervalos de cinco minutos.
CPUCreditUsageNúmero de créditos de CPU consumidos durante Aurora MySQL

el periodo especificado. Esta métrica solo tiene
validez para las instancias de db.t2.small y
db.t2.medium. Identifica la cantidad de tiempo
durante la que las CPU físicas se han usado
para procesar instrucciones de las CPU virtuales
asignadas a la instancia de base de datos Aurora
MySQL.
Note
Las métricas de créditos de CPU se

indican a intervalos de cinco minutos.
CPUUtilizationPorcentaje de CPU usado por una instancia de Aurora MySQL y Aurora

base de datos de Aurora. PostgreSQL
Número de conexiones a una instancia de base de

DatabaseConnections Aurora MySQL y Aurora
datos de Aurora. PostgreSQL
DDLLatency Cantidad de latencia en milisegundos para las Aurora MySQL

solicitudes del lenguaje de definición de datos
(DDL); por ejemplo, crear, alterar y eliminar
solicitudes.
DDLThroughput Número medio de solicitudes DDL por segundo. Aurora MySQL
Deadlocks Número medio de interbloqueos en la base de Aurora MySQL y Aurora

datos por segundo. PostgreSQL

386
DeleteLatency Cantidad de latencia de las consultas de Aurora MySQL

eliminación en milisegundos.
Número medio de consultas de eliminación por

DeleteThroughput Aurora MySQL
segundo.
DiskQueueDepthEl número de solicitudes de lectura/escritura Aurora PostgreSQL

pendientes a la espera de obtener acceso al disco.
DMLLatency Cantidad de latencia de las inserciones, Aurora MySQL

actualizaciones y eliminaciones en milisegundos.
DMLThroughput Número medio de inserciones, actualizaciones y Aurora MySQL

eliminaciones por segundo.
EngineUptime Cantidad de tiempo en segundos que la instancia Aurora MySQL y Aurora

lleva en ejecución. PostgreSQL
FreeableMemoryCantidad de memoria de acceso aleatorio Aurora MySQL y Aurora

disponible en bytes. PostgreSQL
Cantidad de almacenamiento disponible para las

FreeLocalStorage Aurora MySQL y Aurora
tablas y los registros temporales en bytes. PostgreSQL
A diferencia de otros motores de base de datos,

en las instancias de base de datos de Aurora esta
métrica indica la cantidad de almacenamiento
disponible en cada instancia de base de datos
para los logs y las tablas temporales. Este valor
depende de la clase de la instancia de base
de datos (para ver la información de precios,
consulte la página de producto de Amazon RDS).
Puede aumentar la cantidad de espacio de
almacenamiento libre para una instancia eligiendo
una clase de instancia de base de datos más
grande para ella.
InsertLatency Cantidad de latencia de las consultas de inserción Aurora MySQL

en milisegundos.
Número medio de consultas de inserción por

InsertThroughput Aurora MySQL
segundo.
LoginFailures Número medio de intentos de inicio de sesión con Aurora MySQL

error por segundo.
La antigüedad del ID de transacción sin vaciar más

MaximumUsedTransactionIDs Aurora PostgreSQL
antiguo, en transacciones. Si este valor alcanza
2 146 483 648 (2^31 - 1 000 000), la base de datos
se fuerza en modo de solo lectura, a fin de evitar
el reinicio de los ID de transacción. Para obtener
más información, consulte Preventing Transaction
ID Wraparound Failures en la documentación de
PostgreSQL.

387
Cantidad de rendimiento de red en bytes por

NetworkReceiveThroughput Aurora MySQL y Aurora
segundo recibida de los clientes por cada instancia PostgreSQL
del clúster de base de datos Aurora MySQL. Este
desempeño no incluye el tráfico de red entre las
instancias del clúster de base de datos de Aurora y
el volumen de clúster.
Cantidad de rendimiento de red en bytes por

NetworkThroughput Aurora MySQL y Aurora
segundo recibida de los clientes y transmitida a PostgreSQL
ellos por cada instancia del clúster de base de
datos Aurora MySQL. Este rendimiento no incluye
el tráfico de red entre las instancias del clúster de
base de datos y el volumen de clúster.
Cantidad de desempeño de red en bytes por

NetworkTransmitThroughput Aurora MySQL y Aurora
segundo enviada a los clientes por cada instancia PostgreSQL
del clúster de base de datos de Aurora. Este
rendimiento no incluye el tráfico de red entre
las instancias del clúster de base de datos y el
volumen de clúster.
Queries Número medio de consultas ejecutadas por Aurora MySQL

segundo.
Retardo en segundos que se produce cuando

RDSToAuroraPostgreSQLReplicaLag Aurora PostgreSQL
la replicación aplica una actualización desde la
instancia principal de RDS PostgreSQL a otros
nodos del clúster.
ReadIOPS El número medio de operaciones de E/S en el Aurora PostgreSQL

disco por segundo.
Compatibilidad de Aurora con PostgreSQL indica

las IOPS de lectura y escritura por separado en
intervalos de 1 minuto.
ReadLatency Tiempo medio de cada operación de E/S en el Aurora PostgreSQL

disco.
ReadThroughputEl número medio de bytes leídos del disco por Aurora PostgreSQL
segundo.
Porcentaje de solicitudes servidas por la caché

ResultSetCacheHitRatio Aurora MySQL
Resultset.
SelectLatency Cantidad de latencia de las consultas de selección Aurora MySQL

en milisegundos.
Número medio de consultas de selección por

SelectThroughput Aurora MySQL
segundo.

388

SnapshotStorageUsed Aurora MySQL y Aurora
de seguridad en GiB consumida por todas las PostgreSQL
instantáneas de Aurora un clúster de base de
datos de Aurora determinado fuera de su periodo
de retención de copia de seguridad. Se incluye en
el total registrado por la métrica . Se calcula de
forma independiente para cada clúster de Aurora.
Para obtener instrucciones, consulte Descripción
del uso de almacenamiento de copias de seguridad
en Aurora (p. 316).
SwapUsage La cantidad de espacio de intercambio utilizado en Aurora PostgreSQL

la instancia de base de datos Aurora PostgreSQL.

TotalBackupStorageBilled Aurora MySQL y Aurora
de seguridad en GiB facturada para un clúster de PostgreSQL
base de datos de Aurora determinado. Incluye el
almacenamiento de copias de seguridad medido
por las métricas SnapshotStorageUsed y
BackupRetentionPeriodStorageUsed. Se
calcula de forma independiente para cada clúster
de Aurora. Para obtener instrucciones, consulte
Descripción del uso de almacenamiento de copias
de seguridad en Aurora (p. 316).
La cantidad de espacio en disco ocupado por los

TransactionLogsDiskUsage Aurora PostgreSQL
registros de transacciones en la instancia de base
de datos PostgreSQL de Aurora.
UpdateLatency Cantidad de latencia de las consultas de Aurora MySQL

actualización en milisegundos.
Número medio de consultas de actualización por

UpdateThroughput Aurora MySQL
segundo.
Cantidad de almacenamiento utilizada por la

VolumeBytesUsed Aurora MySQL y Aurora
instancia de base de datos de Aurora en bytes. PostgreSQL
Este valor afecta al costo del clúster de base

de datos de Aurora (para ver la información de
precios, consulte la página de producto de Amazon
RDS).

389
Consulta de métricas en la consola de Amazon RDS
VolumeReadIOPsNúmero de operaciones de E/S de lectura Aurora MySQL y Aurora

facturadas desde un volumen de clúster, indicado a PostgreSQL
intervalos de 5 minutos.
Las operaciones de lectura facturadas se calculan

en el nivel del volumen de clúster, se agrupan
desde todas las instancias del clúster de base
de datos de Aurora y se notifican a continuación
a intervalos de 5 minutos. El valor se calcula
tomando el valor de la métrica Read operations
(Operaciones de lectura) a lo largo de un periodo
de 5 minutos. Puede determinar la cantidad de
operaciones de lectura facturadas por segundo
tomando el valor de la métrica Billed read
operations (Operaciones de lectura facturadas)
y dividiendo por 300 segundos. Por ejemplo, si
Billed read operations (Operaciones de lectura
facturadas) devuelve 13 686, las operaciones
de lectura facturadas por segundo serán 45
(13 686/300 = 45,62).
Las operaciones de lectura facturadas se

acumulan para las consultas que solicitan páginas
de la base de datos que no están en la caché del
búfer y que, por lo tanto, se deben cargar desde
el almacenamiento. Es posible que aparezcan
picos en las operaciones de lectura facturadas, ya
que los resultados de la consulta se leen desde el
almacenamiento y se cargan en la caché del búfer.
Número de operaciones de E/S de escritura en

VolumeWriteIOPs Aurora MySQL y Aurora
el disco en el volumen de clúster indicadas a PostgreSQL
intervalos de 5 minutos. Consulte la descripción
anterior de VolumeReadIOPS para obtener
información detallada acerca de cómo se calculan
las operaciones de escritura facturables.
WriteIOPS El número medio de operaciones de E/S en el Aurora PostgreSQL

disco por segundo.
Aurora PostgreSQL indica las IOPS de lectura y

escritura por separado, en intervalos de 1 minuto.
WriteLatency Tiempo medio de cada operación de E/S en el Aurora PostgreSQL

disco.
Número medio de bytes que se escriben en el

WriteThroughput Aurora PostgreSQL
disco por segundo.
Visualización de métricas de Aurora en la consola de

Amazon RDS
Para monitorizar el estado y el rendimiento de un clúster de base de datos Aurora, puede ver algunas de
las métricas (no todas) proporcionadas por Amazon Aurora en la consola de Amazon RDS. Para obtener

390
Consulta de métricas en la consola de Amazon RDS
una lista detallada de las métricas de Aurora disponibles para la consola de Amazon RDS, consulte
Métricas de Aurora disponibles en la consola de Amazon RDS (p. 392).
Para ver métricas de Aurora en la consola de Amazon RDS
3. Elija el nombre de la instancia de base de datos que desea monitorear para ver sus detalles.
4. En la sección CloudWatch, elija una de las siguientes opciones de Monitoring (Monitorización) para la
forma de ver las métricas:
• CloudWatch: muestra un resumen de las métricas de CloudWatch. Cada métrica incluye un gráfico
que muestra la métrica monitorizada a lo largo de un periodo de tiempo concreto. Para obtener más
información, consulte Monitorización con Amazon CloudWatch (p. 366).
• Enhanced monitoring (Monitorización mejorada): muestra un resumen de las métricas de SO
disponibles para una instancia de base de datos Aurora con la monitorización mejorada habilitada.
Cada métrica incluye un gráfico que muestra la métrica monitorizada a lo largo de un periodo de
tiempo concreto. Para obtener más información, consulte Monitorización mejorada (p. 395).
• OS process list (Lista de procesos de SO): muestra los procesos que se ejecutan en la instancia o el
clúster de base de datos y sus métricas relacionadas, incluido el porcentaje de la CPU, el uso de la
memoria, etc.
5. La imagen siguiente muestra la vista de métricas la opción Enhanced monitoring (Monitorización

mejorada) seleccionada.

391
Métricas de Aurora disponibles
en la consola de Amazon RDS
Métricas de Aurora disponibles en la consola de

Amazon RDS
No todas las métricas proporcionadas por Amazon Aurora están disponibles en la consola de Amazon
RDS. Sin embargo, puede verlas usando otras herramientas, como la interfaz de línea de comandos (CLI)
de AWS y la API de CloudWatch. Además, algunas de las métricas que están disponibles en la consola
de Amazon RDS solo se muestran para clases de instancias concretas o con nombres distintos y con
unidades de medida diferentes.
Las siguientes métricas de Aurora no están disponibles en la consola de Amazon RDS:
• AuroraBinlogReplicaLag
• DeleteLatency
• DeleteThroughput

392
• EngineUptime
• InsertLatency
• InsertThroughput
• NetworkThroughput
• Queries
• UpdateLatency
• UpdateThroughput
Además, algunas métricas de Aurora solo se muestran para clases de instancias concretas, para
instancias de base de datos o con nombres distintos y con unidades de medida diferentes:
• Las métricas CPUCreditBalance y CPUCreditUsage se muestran únicamente para las instancias

db.t2.small y db.t2.medium.
• Las siguientes métricas se muestran con nombres diferentes, como se indica en la lista:
Métrica Nombre de visualización
Replica lag maximum

AuroraReplicaLagMaximum
Replica lag minimum

AuroraReplicaLagMinimum
DDLThroughput DDL
Network throughput
NetworkReceiveThroughput
VolumeBytesUsed Bytes de volumen [facturados] usados
VolumeReadIOPs IOPS de lectura de volumen [facturadas]
VolumeWriteIOPs IOPS de escritura de volumen [facturadas]
• Las siguientes métricas se aplican a un clúster de base de datos Aurora completo, pero se muestran
solo al ver instancias de base de datos para un clúster de base de datos Aurora en la consola de
Amazon RDS:
• VolumeBytesUsed
• VolumeReadIOPs
• VolumeWriteIOPs
• Las siguientes métricas se muestran en megabytes y no en bytes en la consola de Amazon RDS:
• FreeableMemory
• FreeLocalStorage
• NetworkReceiveThroughput
• NetworkTransmitThroughput
Vista de métricas más recientes

Puede ver un subconjunto de métricas de Aurora clasificadas en la vista de métricas más recientes de la
consola de Amazon RDS. En la siguiente tabla se muestran las categorías y las métricas asociadas que se
muestran en la consola de Amazon RDS para una instancia de Aurora.
Categoría Métricas
SQL ActiveTransactions

393
Categoría Métricas
BlockedTransactions
BufferCacheHitRatio
CommitLatency
CommitThroughput
DatabaseConnections
DDLLatency
DDLThroughput
Deadlocks
DMLLatency
DMLThroughput
LoginFailures
ResultSetCacheHitRatio
SelectLatency
SelectThroughput
System (Sistema) AuroraReplicaLag
AuroraReplicaLagMaximum
AuroraReplicaLagMinimum
CPUCreditBalance
CPUCreditUsage
CPUUtilization
FreeableMemory
FreeLocalStorage
NetworkReceiveThroughput
Deployment AuroraReplicaLag
(Implementación)
BufferCacheHitRatio
ResultSetCacheHitRatio
SelectThroughput
Note
La métrica Failed SQL Statements (Instrucciones SQL con error), que se muestra en la categoría
SQL de la vista de métricas más recientes en la consola de Amazon RDS, no es válida para
Amazon Aurora.

394
Temas relacionados
Temas relacionados
Monitorización mejorada
Amazon RDS proporciona métricas en tiempo real para el sistema operativo (SO) en el que se ejecuta
la instancia de base de datos. Puede ver las métricas de su instancia de base de datos en la consola
o usar la salida JSON de la monitorización mejorada de Amazon CloudWatch Logs en el sistema de
monitorización que prefiera.
Las métricas de Enhanced Monitoring se almacenan de forma predeterminada en CloudWatch Logs

durante 30 días. Para modificar la cantidad de tiempo que se almacenan las métricas en CloudWatch Logs,
cambie la retención del grupo de registros RDSOSMetrics en la consola de CloudWatch. Para obtener
más información, consulte Cambiar la retención de datos de registro en CloudWatch Logs en la Amazon
CloudWatch Logs User Guide.
El costo del uso de la monitorización mejorada depende de varios factores:
• Se le cobra solo por la monitorización mejorada que supere la capa gratuita proporcionada por Amazon
CloudWatch Logs.
Para obtener más información sobre los precios, consulte Precios de Amazon CloudWatch.
• Un intervalo de monitorización más corto deriva en informes más frecuentes de métricas del SO y
aumenta el costo de la monitorización.
• Los costos de uso de la monitorización mejorada se aplican en cada instancia de base de datos para la
que está habilitada dicha monitorización. Monitorizar un gran números de instancias de base de datos es
más costoso que monitorizar tan solo unas cuantas.
• Las instancias de base de datos que admiten una carga de trabajo con computación más intensiva
tienen más actividad de proceso de SO de la que informar y costos más elevados de monitorización
mejorada.
Diferencias entre métricas de monitorización mejorada

y CloudWatch
CloudWatch recopila métricas sobre el uso de la CPU del hipervisor para una instancia de base de datos
y la monitorización mejorada recopila su métrica desde un agente en la instancia. Como consecuencia,
podría encontrar diferencias entre las mediciones, porque la capa del hipervisor realiza una pequeña
cantidad de trabajo. Las diferencias pueden ser mayores si sus instancias de base de datos utilizan clases
de instancia más pequeñas, porque probablemente hay más máquinas virtuales (VM) administradas por
la capa del hipervisor en una sola instancia física. Las métricas de monitorización mejoradas son útiles
cuando desea ver cómo diferentes procesos o subprocesos en una instancia de base de datos usan la
CPU.
Configuración y habilitación de la monitorización

mejorada
Para configurar y habilitarla monitorización mejorada, realice los pasos que aparecen a continuación.

395
Configuración y habilitación de la monitorización mejorada
Antes de empezar
La monitorización mejorada necesita permiso para actuar en su nombre y enviar información de métrica del
SO a CloudWatch Logs. Puede otorgar los permisos necesarios a la monitorización mejorada mediante un
rol de AWS Identity and Access Management (IAM).
La primera vez que habilita la monitorización mejorada en la consola, puede seleccionar la opción
Default para la propiedad Monitoring Role, a fin de que RDS cree el rol de IAM necesario. RDS le crea a
continuación automáticamente un rol llamado rds-monitoring-role y lo utiliza para la instancia de
base de datos o la réplica de lectura especificadas.
También puede crear el rol necesario antes de habilitar la monitorización mejorada y especificar, a
continuación, el nombre del nuevo rol cuando habilita dicha monitorización. Debe crear este rol necesario
si habilita la monitorización mejorada mediante la AWS CLI o la API de RDS.
Para crear el rol de IAM apropiado que permita a Amazon RDS comunicarse con el servicio de Amazon
CloudWatch Logs en su nombre, siga estos pasos.
Se debe conceder al usuario que habilite la monitorización mejorada el permiso PassRole. Para obtener
más información, consulte el Ejemplo 2 en Concesión de permisos a un usuario para transferir un rol a un
servicio de AWS en la Guía del usuario de IAM.
Para crear un rol de IAM para la monitorización mejorada de Amazon RDS
1. Abra la consola de IAM en https://console.aws.amazon.com.

2. Seleccione Roles en el panel de navegación.
3. Elija Create role.
4. Elija la pestaña AWS service (Servicio de AWS) y, a continuación, elija RDS de la lista de servicios.
5. Elija RDS - Enhanced Monitoring (Monitorización mejorada de RDS) y, a continuación, elija Next:
Permissions (Siguiente: permisos).
6. En la página Attached permissions policy, elija AmazonRDSEnhancedMonitoringRole y, a
continuación, Next: Review (Siguiente: Etiquetas).
7. En la página Add tags (Añadir etiquetas), elija Next: Review (Siguiente: Revisión).
8. Para Role name (Nombre de rol), escriba un nombre para su función, por ejemplo emaccess y, a
continuación, elija Create role (Crear rol).
Habilitación y deshabilitación de la monitorización mejorada

Puede habilitar la monitorización mejorada cuando crea un clúster de base de datos o réplica de lectura, o
cuando modifica un clúster de base de datos. Si modifica una instancia de base de datos para habilitar la
monitorización mejorada, no es necesario reiniciar dicha instancia para que el cambio tenga efecto.
Puede habilitar la monitorización mejorada en la consola de RDS cuando realiza una de las siguientes
acciones:
• Create a DB Cluster – (Crear una instancia un clúster de base de datos): puede habilitar la
monitorización mejorada en la página Configure Advanced Settings (Configurar ajustes avanzados) .
• Create a Read Replica (Crear réplica de lectura)–: puede habilitar la monitorización mejorada en la
página Configure Advanced Settings (Configurar ajustes avanzados).
• Modificar una instancia de base de datos–: puede habilitar la monitorización mejorada en la página
Modify DB Instance (Modificar instancia de base de datos).
Para habilitar la monitorización mejorada mediante la consola de RDS, desplácese hasta la sección
Monitoring y haga lo siguiente:

396
Visualización de la monitorización mejorada
1. Elija Enable enhanced monitoring (Habilitar monitorización mejorada) para su instancia de base de
datos o réplica de lectura.
2. Establezca la propiedad Monitoring Role (Rol de monitorización) en el rol de IAM que ha creado
para permitir que Amazon RDS se comunique con Amazon CloudWatch Logs, o bien elija Default
(Predeterminado) para que RDS cree un rol denominado rds-monitoring-role.
3. Establezca la propiedad Granularity en el intervalo (en segundos) entre puntos cuando se recopilan
métricas para la instancia de base de datos o réplica de lectura. La propiedad Granularity puede
establecerse en uno de los siguientes valores: 1, 5, 10, 15, 30 o 60.
Para deshabilitar la monitorización mejorada, elija Disable Enhanced Monitoring (Deshabilitar

monitorización mejorada).
Para habilitar la monitorización mejorada no es necesario reiniciar la instancia de base de datos.

Note
La velocidad más rápida a la que la consola de RDS se actualiza es cada 5 segundos. Si

establece la granularidad en 1 segundo en la consola de RDS, seguirá viendo métricas
actualizadas solo cada 5 segundos. Puede recuperar actualizaciones de métricas de 1 segundo
mediante CloudWatch Logs.

Puede ver las métricas del SO informadas por la monitorización mejorada en la consola de RDS si elige
Enhanced monitoring (Monitorización mejorada) para Monitoring (Monitorización).
A continuación, se muestra la página de monitorización mejorada.

397
Si desea ver detalles para los procesos que se ejecutan en su instancia de base de datos, elija OS process
list (Lista de procesos del SO) para Monitoring (Monitorización).
A continuación, se muestra la vista Process List (Lista de procesos).
La métrica de monitorización mejorada que se muestra en la vista Process list (Lista de procesos) se
organiza de la siguiente manera:
• RDS child processes (Procesos secundarios de RDS): muestra un resumen de los procesos de RDS
que admiten la instancia de base de datos, por ejemplo aurora para clústeres de base de datos de
Amazon Aurora. Los subprocesos aparecen anidados debajo del proceso principal. Los subprocesos
solo muestran el uso de la CPU, ya que otras métricas son iguales para todos los subprocesos. La
consola muestra un máximo de 100 procesos y subprocesos. Los resultados son una combinación de
los principales procesos y subprocesos que consumen memoria y CPU. Si hay más de 50 procesos y
más de 50 subprocesos, la consola muestra los 50 consumidores principales de cada categoría. Esta
pantalla le ayuda a identificar qué procesos están teniendo mayor impacto en el desempeño.
• RDS processes (Procesos de RDS)–: muestra un resumen de los recursos utilizados por el agente de
administración de RDS, procesos de monitorización de diagnóstico y otros procesos de AWS que son
necesarios para admitir instancias de base de datos de RDS.

398
Visualización de la monitorización
mejorada con CloudWatch Logs
• OS processes (Procesos de SO)–: muestra un resumen del kernel y de los procesos del sistema, que
por lo general tienen un impacto mínimo en el rendimiento.
Los elementos enumerados para cada proceso son los siguientes:
• VIRT–: muestra el tamaño virtual del proceso.

• RES–: muestra la memoria física real que utiliza el proceso.
• CPU%–: muestra el porcentaje de ancho de banda de CPU que consume el proceso.
• MEM%–: muestra el porcentaje de memoria total que consume el proceso.
Los datos de monitorización que se muestran en la consola de RDS se obtienen de Amazon CloudWatch
Logs. También puede obtener la métrica para una instancia de base de datos en forma de flujo de registro
de CloudWatch Logs. Para obtener más información, consulte Visualización de la monitorización mejorada
con CloudWatch Logs (p. 399).
La métrica de monitorización mejorada no se devuelve durante las siguientes situaciones:
• Una conmutación por error de la instancia de base de datos.

• Cambio de la clase de una instancia de base de datos (escalado del cómputo).
La métrica de monitorización mejorada se devuelve al reiniciar una instancia de base de datos porque solo
se reinicia el motor de la base de datos. Se sigue informando de la métrica correspondiente al sistema
operativo.
Visualización de la monitorización mejorada con

CloudWatch Logs
Después de haber habilitado la monitorización mejorada para la instancia de base de datos, puede ver
la métrica para dicha instancia con CloudWatch Logs, en la que cada flujo de registro representa una
instancia de base de datos individual monitorizada. El identificador del flujo de registro es un identificador
de recursos (DbiResourceId) para la instancia de base de datos.
Para ver los datos de registro de la monitorización mejorada
1. Abra la consola de CloudWatch en https://console.aws.amazon.com/cloudwatch/.

2. Si fuera necesario, elija la región en la que se encuentra su instancia de base de datos. Para obtener
más información, consulte Regiones y puntos de enlace en la Referencia general de Amazon Web
Services.
3. En el panel de navegación, elija Logs.
4. Elija RDSOSMetrics en la lista de grupos de registro.
5. Elija el flujo de registro que desea ver en la lista de flujos de registro.
Métricas de SO disponibles
Las tablas siguientes incluyen las métricas de SO disponibles al usar Amazon CloudWatch Logs.
Métricas de Aurora
Grupo Métricas Descripción
General engine El motor de base de datos para la instancia de base de datos.

399
instanceID El identificador de instancias de base de datos.
Un identificador inmutable único de la región para la instancia

instanceResourceID
de base de datos, que también se utiliza como identificador
de flujo de registro.
numVCPUs El número de CPU virtuales para la instancia de base de

datos.
timestamp La hora a la que se tomó la métrica.
uptime La cantidad de tiempo que ha estado activa la instancia de

base de datos.
version La versión del formato JSON del flujo de la métrica del SO.
cpuUtilization guest El porcentaje de CPU utilizado por programas invitados.
idle El porcentaje inactivo de CPU.
irq El porcentaje de CPU utilizado por interrupciones de software.
nice El porcentaje de CPU utilizado por programas que se

ejecutan con la prioridad más baja.
steal El porcentaje de CPU utilizado por otras máquinas virtuales.
system El porcentaje de CPU utilizado por el kernel.
total El porcentaje total de CPU utilizado. Este valor incluye el valor

nice.
user El porcentaje de CPU utilizado por programas de usuario.
wait El porcentaje de CPU sin utilizar mientras se espera el acceso

de E/S.
fileSys maxFiles El número máximo de archivos que se pueden crear para el

sistema de archivos.
mountPoint La ruta al sistema de archivos.
name El nombre del sistema de archivos.
total La cantidad total de espacio en disco disponible para el

sistema de archivos, en kilobytes.
used La cantidad de espacio en disco utilizado por los archivos en

el sistema de archivos, en kilobytes.
usedFilePercent El porcentaje de archivos disponibles en uso.
usedFiles El número de archivos en el sistema de archivos.
usedPercent El porcentaje de espacio en disco del sistema de archivos que

está en uso.
loadAverageMinute
fifteen El número de procesos que solicitan tiempo de la CPU en los
últimos 15 minutos.

400
five El número de procesos que solicitan tiempo de la CPU en los

últimos 5 minutos.
one El número de procesos que solicitan tiempo de la CPU en el

último minuto.
memory active La cantidad de memoria asignada, en kilobytes.
buffers La cantidad de memoria utilizada para almacenar en búfer

solicitudes de E/S antes de escribir en el dispositivo de
almacenamiento, en kilobytes.
cached La cantidad de memoria utilizada para almacenar en la caché

E/S basadas en el sistema de archivos.
dirty La cantidad de páginas de memoria en la RAM que se

han modificado, pero no escrito, en su bloque de datos
relacionado en el almacenamiento, en kilobytes.
free La cantidad de memoria no asignada, en kilobytes.
hugePagesFree El número de páginas de gran tamaño libres. Las páginas de

gran tamaño son una característica del kernel de Linux.
hugePagesRsvd El número de páginas de gran tamaño confirmadas.
hugePagesSize El tamaño de cada unidad de páginas de gran tamaño, en

kilobytes.
hugePagesSurp El número de páginas de gran tamaño sobrantes disponibles

con respecto al total.
hugePagesTotal El número total de páginas de gran tamaño para el sistema.
inactive La cantidad de páginas de memoria utilizadas con menor

frecuencia, en kilobytes.
mapped La cantidad total de contenido del sistema de archivos

mapeado a la memoria dentro de un espacio de direcciones
de proceso, en kilobytes.
pageTables La cantidad de memoria utilizada por tablas de página, en

kilobytes.
slab La cantidad de estructuras de datos de kernel reutilizables, en

kilobytes.
total La cantidad total de memoria, en kilobytes.
writeback La cantidad de páginas desfasadas en la RAM que se siguen

escribiendo en el almacenamiento de respaldo, en kilobytes.
network interface El identificador para la interfaz de red que se utiliza para la

rx El número de bytes recibidos por segundo.
tx El número de bytes cargados por segundo.

401
Performance Insights
processList cpuUsedPc El porcentaje de CPU utilizado por el proceso.
id El identificador del proceso.
memoryUsedPc La cantidad de memoria utilizada por el proceso, en kilobytes.
name El nombre del proceso.
parentID El identificador correspondiente al proceso principal.
rss La cantidad de RAM asignada al proceso, en kilobytes.
tgid El identificador del grupo de subprocesos, que es un

número que representa el ID del proceso al que pertenece
un subproceso. Este identificador se utiliza para agrupar
subprocesos del mismo proceso.
VIRT La cantidad de memoria virtual asignada al proceso, en

kilobytes.
swap swap La cantidad de memoria de intercambio disponible, en

kilobytes.
swap in La cantidad de memoria, en kilobytes, intercambiada desde

disco.
swap out La cantidad de memoria, en kilobytes, intercambiada del

disco.
free La cantidad de memoria de intercambio no asignada, en

kilobytes.
committed La cantidad de memoria de intercambio, en kilobytes, utilizada

como memoria caché.
tasks blocked El número de tareas que están bloqueadas.
running El número de tareas que están en ejecución.
sleeping El número de tareas que están inactivas.
stopped El número de tareas que se han detenido.
total El número total de tareas.
zombie El número de tareas secundarias inactivas con una tarea

principal activa.
Uso de Performance Insights de Amazon RDS

Performance Insights de Amazon RDS monitoriza la carga de las instancias de base de datos de Amazon
RDS para poder analizar y solucionar los problemas de desempeño de la base de datos. Actualmente,
Performance Insights de Amazon RDS solo está disponible con los siguientes motores de base de datos.
• Compatibilidad de Amazon Aurora con MySQL versión 2.04.2 y versiones posteriores a 2.x (compatible
con MySQL 5.7)

402
• Compatibilidad de Amazon Aurora con MySQL versión 1.17.3 y versiones posteriores a 1.x (compatible
con MySQL 5.6)
• Compatibilidad de Amazon Aurora con PostgreSQL
• Amazon RDS para MariaDB versión 10.2.21 y versiones posteriores a 10.2
• Amazon RDS para MySQL versión 5.7.22 y versiones posteriores a 5.7, así como versión 5.6.41 y
versiones posteriores a 5.6
• Amazon RDS para Microsoft SQL Server (todas las versiones, excepto SQL Server 2008)
• Amazon RDS para la versión 10 y 11 de PostgreSQL
• Amazon RDS para Oracle (todas las versiones)
Note
La característica de Información sobre rendimiento de Amazon RDS no es compatible con

MariaDB versión 10.0, 10.1 o 10.3, ni con MySQL versión 5.5 u 8.0.
Para Amazon RDS para MariaDB y MySQL, Performance Insights no es compatible en
las siguientes clases de instancia de base de datos: db.t2.micro, db.t2.small, db.t3.micro y
db.t3.small.
En Aurora MySQL, Performance Insights no es compatible con las clases de instancia de bases
de datos db.t2 o db.t3.
La característica de Información sobre rendimiento no es compatible con clústeres de base de
datos de Aurora MySQL habilitados para consulta paralela.
La Información sobre rendimiento amplía las características de monitorización existentes de Amazon RDS
para ilustrar el rendimiento de la base de datos y le ayuda a analizar cualquier problema que le afecte.
Con el panel de Performance Insights, puede visualizar la carga de la base de datos y filtrarla por esperas,
instrucciones SQL, hosts o usuarios.
Performance Insights está activado de forma predeterminada en el asistente de la consola Create para
todos los motores de base de datos que funcionen con Amazon RDS. Si tiene más de una base de datos
en una instancia de base de datos, se acumulan los datos de desempeño de todas las bases de datos
para la instancia de base de datos.
La métrica central de Performance Insights es DB Load, que representa el número medio de sesiones
activas del motor de base de datos. La métrica DB Load se recopila cada segundo. Una sesión activa
es una conexión que ha enviado trabajo al motor de la base de datos y está esperando una respuesta.
Por ejemplo, si envía una consulta SQL al motor de base de datos, la sesión de base de datos está activa
mientras el motor de base de datos procesa esa consulta.
Al combinar datos de DB Load (Carga de base de datos) con wait event (evento de espera) es posible
obtener una visión completa del estado de la sesión activa. Los eventos de espera varían en función del
motor de base de datos:
• Para ver una lista de los eventos de espera utilizados con más frecuencia para Aurora MySQL, consulte
Eventos de Aurora MySQL (p. 690).
• Para obtener más información sobre todos los MySQL, consulte Wait Event Summary Tables (Tablas de
resumen de eventos de espera) en la documentación de MySQL.
• Para ver una lista de los eventos de espera utilizados con más frecuencia para Aurora PostgreSQL,
consulte Eventos de Amazon Aurora PostgreSQL (p. 855).
• Para obtener más información sobre todos los eventos de espera de PostgreSQL, consulte PostgreSQL
Wait Events en la documentación de PostgreSQL.
La información de la sesión se recopila, acumula y muestra en el gráfico Average Active Sessions

(Sesiones activas promedio) en el panel. El gráfico Average Active Sessions muestra el valor Max CPU en

403
Activación de Performance Insights
forma de línea para poder ver si las sesiones activas sobrepasan este valor o no. El valor de Max CPU se
determina por el número de núcleos de vCPU (CPU virtual) de la instancia de base de datos.
Si la carga que se indica en el gráfico Average Active Sessions (Sesiones activas promedio) está por
encima de la línea Max CPU y el estado de espera principal es CPU, eso significa que la CPU del sistema
está sobrecargada. En estos casos, quizá sea conveniente limitar las conexiones con la instancia, ajustar
las consultas SQL con una carga de CPU alta o pensar en la posibilidad de usar una clase de instancia
de mayor tamaño. Si hay instancias altas y uniformes en cualquier estado de espera, eso indica que es
posible que haya problemas de contención de recursos o cuellos de botella que hay que resolver. Esto
puede ser así aunque la carga no cruce la línea de Max CPU.
Puede encontrar una introducción a Performance Insights en el vídeo siguiente.
Uso de Performance Insights para analizar el rendimiento de Amazon Aurora PostgreSQL
Temas
• Activación de Performance Insights (p. 404)
• Control de acceso de Performance Insights (p. 408)
• Uso del panel de Performance Insights (p. 409)
• Características adicionales de la interfaz de usuario (p. 419)
• API de Performance Insights (p. 420)
• Métricas de Performance Insights publicadas en Amazon CloudWatch (p. 432)
• Contadores de Performance Insights (p. 433)
• Registro de operaciones de Performance Insights mediante AWS CloudTrail (p. 440)

Para usar Performance Insights, debe habilitarlo en su instancia de base de datos.
Si utiliza Performance Insights junto con Aurora Global Database, debe habilitar Performance Insights
de forma individual para las instancias de base de datos en cada región de AWS. Para obtener más
información, consulte Performance Insights para base de datos global de Aurora (p. 46).
Consola
Puede utilizar la consola para habilitar Performance Insights cuando se crea una nueva instancia de base
de datos. También puede modificar una instancia de base de datos para habilitar Performance Insights.
Temas
• Activación de Performance Insights con la consola cuando se crea una instancia de base de
datos (p. 404)
• Activación de Performance Insights con la consola cuando se modifica una instancia de base de
datos (p. 405)
Activación de Performance Insights con la consola cuando se crea una instancia de base de datos
Cuando crea una nueva instancia de base de datos, Performance Insights se habilita con la opción Enable
Performance Insights (Activar Performance Insights) de la sección Performance Insights.
Para crear una instancia de base de datos, siga las instrucciones del motor de base de datos específico
que se indican en Creación de un clúster de base de datos de Amazon Aurora (p. 85).
La imagen siguiente muestra la sección Performance Insights.

404
Puede seleccionar las siguientes opciones cuando elige Enable Performance Insights (Activar Performance
Insights):
• Retention (Retención): el número de días durante los que se conservan los datos de Performance
Insights. Elija entre 7 días (el valor predeterminado) o 2 años.
• Master key (Clave maestra): especifique la clave de AWS Key Management Service (AWS KMS).
Performance Insights cifra todos los datos potencialmente confidenciales con su propia clave de AWS
KMS. Las datos se cifran en reposo y en tránsito. Para obtener más información, consulte Cifrado de
recursos de Amazon Aurora (p. 158).
Activación de Performance Insights con la consola cuando se modifica una instancia de base de
datos
Puede modificar una instancia de base de datos para habilitar Performance Insights mediante la consola.
Para habilitar Performance Insights para una instancia de base de datos mediante la consola
2. Seleccione Databases (Bases de datos).
3. Seleccione la instancia de base de datos que desea modificar y elija Modify (Modificar).
4. En la sección Performance Insights, elija Enable Performance Insights (Activar Performance Insights).
Puede seleccionar las siguientes opciones cuando elige Enable Performance Insights (Activar
Performance Insights):
• Retention (Retención): el número de días durante los que se conservan los datos de Performance
Insights. Elija entre 7 días (el valor predeterminado) o 2 años.
• Master key (Clave maestra): especifique la clave de AWS Key Management Service (AWS KMS).
Performance Insights cifra todos los datos potencialmente confidenciales con su propia clave de
AWS KMS. Las datos se cifran en reposo y en tránsito. Para obtener más información, consulte

405
5. Elija Continue.
6. Para Scheduling of Modifications (Programación de modificaciones), elija una de las siguientes:
• Apply during the next scheduled maintenance window (Aplicar durante el próximo periodo de
mantenimiento programada): espere para aplicar la modificación de Performance Insights hasta el
próximo periodo de mantenimiento.
• Apply immediately (Aplicar inmediatamente): aplique la modificación de Performance Insights lo
antes posible.
7. Elija Modify instance (Modificar instancia).
AWS CLI
Cuando se crea una nueva instancia de base de datos con el comando create-db-instance de la AWS CLI,
Performance Insights se habilita al especificar --enable-performance-insights.
También puede especificar el valor --enable-performance-insights utilizando los siguientes

comandos de la AWS CLI:
• create-db-instance-read-replica
• modify-db-instance
• restore-db-instance-from-s3
El siguiente procedimiento describe cómo habilitar Performance Insights para una instancia de base de
datos utilizando la AWS CLI.
Para habilitar Performance Insights para una instancia de base de datos mediante la AWS CLI
• Llame al comando modify-db-instance de la AWS CLI y especifique los siguientes valores:
• --db-instance-identifier: nombre de la instancia de base de datos.

• --enable-performance-insights
El siguiente ejemplo habilita Performance Insights para sample-db-instance.

--db-instance-identifier sample-db-instance \
--enable-performance-insights
Para Windows:

--db-instance-identifier sample-db-instance ^
--enable-performance-insights
Cuando habilita Performance Insights, puede especificar, si lo desea, la cantidad de tiempo en días que se
conservan los datos de Performance Insights con la opción --performance-insights-retention-
period. Los valores válidos son 7 (predeterminado) o 731 (2 años).

406
El ejemplo siguiente habilita Performance Insights para sample-db-instance y especifica que los datos
de Performance Insights se conserven durante dos años.

--db-instance-identifier sample-db-instance \
--enable-performance-insights \
--performance-insights-retention-period 731
Para Windows:

--db-instance-identifier sample-db-instance ^
--enable-performance-insights ^
--performance-insights-retention-period 731
API
Cuando se crea una nueva instancia de base de datos mediante la acción CreateDBInstance de la API de
Amazon RDS, se habilita Performance Insight al establecer EnablePerformanceInsights en True.
También puede especificar el valor EnablePerformanceInsights utilizando las siguientes acciones de

la API:
• ModifyDBInstance
• CreateDBInstanceReadReplica
• RestoreDBInstanceFromS3
Cuando habilita Performance Insights, puede especificar, si lo desea, la cantidad de

tiempo en días que se conservan los datos de Performance Insights con el parámetro
PerformanceInsightsRetentionPeriod. Los valores válidos son 7 (predeterminado) o 731 (2 años).
Habilitar Performance Schema para Performance Insights en

Aurora MySQL
Para Aurora MySQL, Performance Insights proporciona información más detallada cuando la característica
Performance Schema de está habilitada. Performance Schema se habilita automáticamente al crear
una instancia de base de datos de Aurora MySQL con Performance Insights habilitado. Al crear una
instancia de base de datos con Performance Insights habilitado, el siguiente subconjunto de parámetros de
Performance Schema se establece automáticamente en los valores especificados:
• performance_schema=1
• performance-schema-consumer-events-waits-current=ON
• performance-schema-instrument='wait/%=ON'
• performance-schema-consumer-global-instrumentation=ON
• performance-schema-consumer-thread-instrumentation=ON
Performance Schema se habilita automáticamente solo si el grupo de parámetros no contiene un valor

establecido explícitamente para el parámetro performance_schema. Puede examinar el parámetro
performance_schema. Si el valor del origen es user, establezca un valor. Si desea que los parámetros

407
Control de acceso de Performance Insights
de Performance Schema se establezcan automáticamente, cancele la definición del valor del parámetro
performance_schema. Para ver el origen del valor de un parámetro, visualice el parámetro en la Consola
de administración de AWS o ejecute el comando describe-db-parameters de la AWS CLI.
Cuando se cambia el valor del parámetro performance_schema, es preciso reiniciar la instancia de la

base de datos. Al crear una nueva instancia de base de datos de con Performance Insights habilitado, el
parámetro performance_schema se establece en 1 (habilitado) de forma predeterminada.
Si Performance Schema no está habilitado, Performance Insights muestra la carga de base de datos
desglosada por estados en la lista del proceso de MySQL. Si Performance Schema está habilitado,
Performance Insights muestra la carga de base de datos desglosada por eventos de espera detallados.
Para obtener más información, consulte Uso del panel de Performance Insights (p. 409).
Control de acceso de Performance Insights

Para acceder a Performance Insights, debe tener los permisos adecuados de AWS Identity and Access
Management (IAM). Existen dos opciones disponibles para conceder el acceso:
1. Asocie la política administrada AmazonRDSFullAccess a un rol o usuario de IAM.

2. Cree una política de IAM personalizada y asóciela a un rol o usuario de IAM.
Política administrada AmazonRDSFullAccess

AmazonRDSFullAccess es una política administrada de AWS que concede acceso a todas las acciones
de API de Amazon RDS. Esta política también concede acceso a servicios relacionados que utiliza la
consola de Amazon RDS como, por ejemplo, las notificaciones de eventos que utilizan Amazon SNS.
Asimismo, AmazonRDSFullAccess contiene todos los permisos necesarios para utilizar Performance
Insights. Si esta política se asocia a un rol o usuario de IAM, el destinatario puede utilizar Performance
Insights además de otras demás características de la consola.
Uso de una política de IAM personalizada

Para los usuarios que no tienen acceso completo con la política AmazonRDSFullAccess, puede conceder
acceso a Performance Insights creando o modificando una política de IAM administrada por el usuario. Al
asociar la política a un rol o usuario de IAM, el destinatario puede utilizar Performance Insights.
Para crear una política personalizada
1. Abra la consola de IAM, en https://console.aws.amazon.com/iam/.

2. En el panel de navegación, seleccione Policies.
3. Elija Create Policy.
4. En la página Create Policy (Crear política), elija la pestaña JSON.
5. Copie y pegue lo siguiente.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "pi:*",
"Resource": "arn:aws:pi:*:*:metrics/rds/*"
}
]
}

408
Uso del panel de Performance Insights
6. Elija Review policy

Note
Actualmente, cuando se introduce esta política, la pestaña Visual editor muestra una
advertencia de que el recurso pi no está reconocido. Puede omitir esta advertencia.
7. Proporcione un nombre para la política y, opcionalmente, una descripción, a continuación, elija Create
policy (Crear política).
Ahora ya puede asociar la política a un usuario o un rol de IAM. En el procedimiento siguiente, se

presupone que ya tiene un usuario de IAM para este fin.
Para asociar la política a un usuario de IAM
1. Abra la consola de IAM, en https://console.aws.amazon.com/iam/.

2. En el panel de navegación, seleccione Users.
3. Elija en la lista un usuario existente.
Important
Para usar Performance Insights, el usuario debe tener acceso a Amazon RDS así como a
la política personalizada. Por ejemplo, la política predefinida AmazonRDSReadOnlyAccess
ofrece acceso de solo lectura a Amazon RDS. Para obtener más información, consulte
Administración de acceso mediante políticas (p. 165).
4. En la página Summary, elija Add permissions.
5. Elija Attach existing policies directly. En Search, escriba los primeros caracteres del nombre de la
política, como se muestra más abajo.
6. Elija la política y, a continuación, elija Next: Review.

7. Elija Add permissions.

El panel de Performance Insights contiene información de desempeño de la base de datos para ayudarle
a analizar y solucionar los problemas de desempeño. En la página del panel principal, encontrará
información sobre la carga de la base de datos. También puede ampliar los detalles de un estado de
espera en particular, consulta SQL, host o usuario.

409
Temas
• Apertura del panel de Performance Insights (p. 410)
• Componentes del panel de Performance Insights (p. 412)
• Análisis de la carga de la base de datos mediante el panel de Performance Insights (p. 416)
• Ver más texto SQL en el panel de Performance Insights (p. 417)
Apertura del panel de Performance Insights

Para ver el panel de Performance Insights, lleve a cabo el siguiente procedimiento.
Para ver el panel de Performance Insights en la consola de administración de AWS

2. En el panel de navegación, seleccione Performance Insights.
3. Elija una instancia de base de datos. Se abre el panel de Performance Insights para esa instancia de
base de datos.
En instancias de base de datos con Performance Insights habilitado, también puede acceder al panel
eligiendo el elemento Sessions (Sesiones) en la lista de instancias de base de datos. En Current
activity (Actividad actual), el elemento Sessions (Sesiones) muestra la carga de la base de datos en
el como promedio de sesiones activas en los últimos cinco minutos. La barra muestra gráficamente
la carga. Cuando la barra está vacía, la instancia de base de datos está inactiva. Conforme aumenta
la carga, la barra se va completando en azul. Cuando la carga supera el número de CPU virtuales
(vCPU) en la clase de instancia de base de datos, la barra cambia a rojo, lo cual indica un posible
cuello de botella.
En la siguiente imagen se muestra el panel para una instancia de base de datos.

410
De manera predeterminada, el panel de Performance Insights muestra datos de los últimos 60 minutos.
Puede cambiarlo para que muestre datos de los últimos 5 minutos, 60 minutos, 5 horas 24 horas o 1
semana. También puede mostrar todos los datos disponibles.
El panel de información de rendimiento se actualiza automáticamente con nuevos datos. La frecuencia de

actualización depende de la cantidad de datos mostrados:
• 5 minutos actualiza cada 5 segundos.

• 1 hora y 5 horas actualizan cada minuto.
• 24 horas actualiza cada 5 minutos.
• 1 semana actualiza cada hora.

411
Componentes del panel de Performance Insights

El panel está dividido en tres partes:
1. Gráfico Counter Metrics (Métricas de contador): muestra los datos para métricas de contador de
rendimiento específicas.
2. Gráfico Average Active Sessions (Sesiones activas medias): compara la carga de la base de datos con
la capacidad de la instancia de base de datos representada con la línea Max CPU.
3. Tabla Top load items (Elementos principales de carga): muestra los elementos principales que
contribuyen a la carga de la base de datos.
Gráfico Counter Metrics

El gráfico Counter Metrics (Métricas de contador): muestra los datos para los contadores de rendimiento.
Las métricas mostradas de forma predeterminada son blks_read.avg y xact_commit.avg. Puede
seleccionar qué contadores de desempeño mostrar seleccionando el icono de engranaje de la esquina
superior derecha del gráfico.
Para obtener más información, consulte Contadores de Performance Insights (p. 433).

412
Gráfico Average Active Sessions

El gráfico Average Active Sessions muestra la comparación de la carga de la base de datos con
la capacidad de la instancia de base de datos representada con la línea Max CPU. De manera
predeterminada, la carga se muestra como sesiones activas agrupadas por estados de espera. También
puede optar por ver la carga como sesiones activas agrupadas por consultas SQL, hosts o usuarios.
Para ver los detalles de cualquier elemento del período seleccionado en la leyenda, pase el cursor por ese
elemento en el gráfico Average Active Sessions.
Tabla Top Load Items

La tabla Top Load Items muestra los elementos principales que contribuyen a la carga de la base de datos.
De manera predeterminada, se muestran las consultas SQL principales que contribuyen a la carga de la
base de datos. Las consultas se muestran como resúmenes de varias consultas reales cuya estructura es
similar pero que, posiblemente, tengan parámetros diferentes. Puede optar por ver los principales estados
de espera, hosts o usuarios.
El porcentaje de carga de la base de datos que está asociada con cada elemento de carga principal se
ilustra en la columna DB Load by Waits (Carga de base de datos por esperas). Esta columna refleja la
carga de ese elemento por la agrupación que se haya seleccionado en el gráfico Average Active Sessions
(Sesiones activas medias). Vamos a suponer que el gráfico Average Active Sessions está agrupado por
hosts y desea buscar consultas SQL en la tabla de elementos de carga principales. En este caso, la barra
DB Load by Waits (Carga de base de datos por espera) refleja la carga que representa esa consulta en el

413
host relacionado. Aquí está representado con colores que se corresponden con la representación de ese
host en el gráfico Average Active Sessions.
Supongamos ahora que el gráfico Average Active Sessions está agrupado por estados de espera y desea
buscar consultas SQL en la tabla de elementos de carga principales. En este caso, la barra DB Load by
Waits (Carga de base de datos por esperas) estaría dimensionada, segmentada y dividida por colores para
mostrar en qué proporción contribuye esa consulta a un estado de espera. También indica qué estados de
espera están afectando a esa consulta.
En la tabla Top Load Items (Principales elementos de carga), puede ver los siguientes tipos de
identificadores (ID) asociados con instrucciones SQL:
• SQL ID: un ID que utiliza la base de datos para identificar de forma exclusiva una instrucción SQL.
• Support SQL ID (Compatibilidad con ID SQL): un valor hash del ID de SQL. Este valor sirve solo para
hacer referencia a un ID de SQL al trabajar con AWS Support. AWS Support no tiene acceso a sus ID de
SQL y texto SQL reales.
• Digest ID (ID de resumen): un ID que utiliza la base de datos para identificar de forma exclusiva un
resumen SQL. Un resumen SQL puede contener una o varias instrucciones SQL con los literales
eliminados y los espacios estandarizados. Los literales se sustituyen por signos de interrogación (?).
Para instancias de bases de datos de Aurora MySQL y Aurora PostgreSQL, puede usar un ID de
resumen para encontrar un resumen de SQL específico.
• Support Digest ID (Compatibilidad con ID de resumen): un valor hash del ID de resumen. Este valor
sirve solo para hacer referencia a un ID de resumen al trabajar con AWS Support. AWS Support no tiene
acceso a sus ID de resumen y texto SQL reales.
En la tabla Top Load Items (Principales elementos de carga), puede abrir una instrucción principal para ver
sus ID. En la siguiente imagen se muestra una instrucción principal de apertura.

414
Puede controlar las ID que muestra la tabla Top Load Items (Principales elementos de carga)
seleccionando el icono Preferences (Preferencias).
Al seleccionar el icono Preferences (Preferencias), se abrirá la ventana Preferences (Preferencias).

415
Habilite las ID que quiera tener visibles en la tabla Top Load Items (Principales elementos de carga) y
seleccione Save (Guardar).
Análisis de la carga de la base de datos mediante el panel de

Si el gráfico Average Active Sessions (Sesiones activas promedio) indica que hay un cuello de botella,
puede averiguar de dónde procede la carga. Para ello, fíjese en la tabla de elementos de carga principales
situada debajo del gráfico Average Active Sessions. Elija un elemento en particular, como una consulta
SQL o un usuario, para ampliar la información de ese elemento y ver los detalles.
La carga de base de datos agrupada por esperas y principales consultas de SQL es la vista
predeterminada del panel de Performance Insights. Esta combinación normalmente ofrece la máxima
información sobre problemas de desempeño. La carga de la base de datos agrupada por esperas indica si
hay algún cuello de botella de simultaneidad o recursos en la base de datos. En este caso, la pestaña SQL
de la tabla de elementos de carga principales indica qué consultas están contribuyendo a esa carga.
Este es el flujo de trabajo típico para diagnosticar los problemas de desempeño:
1. Revise el gráfico Average Active Sessions para ver si hay algún incidente de carga de la base de datos
que sobrepase la línea Max CPU.
2. De ser así, fíjese en el gráfico Average Active Sessions e identifique qué estado o estados de espera
son los principales responsables.
3. Para identificar las consultas de resumen que están provocando la carga, consulte qué consultas de la
pestaña SQL de la tabla de elementos de carga principales están contribuyendo más a esos estados de
espera. Para identificarlas, utilice la columna DB Load by Wait (Carga de base de datos por espera).
4. Elija una de estas consultas de resumen en la pestaña SQL para ampliarla y ver las consultas
secundarias que contiene.
Por ejemplo, en el siguiente panel, las esperas IO:XactSync son un problema frecuente. La espera de la
CPU es menor, pero aun así contribuye a la carga.
Las primeras cuatro consultas de la pestaña SQL de la tabla de elementos de carga principales están
enormemente correlacionadas con el primer estado. Por tanto, la información de esas consultas es la que
hay que ampliar para examinar sus consultas secundarias. Para ello, hay que determinar cómo contribuyen
al problema de desempeño.
Las últimas tres consultas son las que más contribuyen al problema de la CPU. Estas son las consultas
que hay que investigar si la carga de la CPU da problemas.

416
Ver más texto SQL en el panel de Performance Insights

De forma predeterminada, cada fila en la tabla Top Load Items (Elementos principales de carga) muestra
500 bytes de texto SQL para cada instrucción SQL. Cuando una instrucción SQL supera los 500 bytes,
puede ver más de la instrucción SQL abriéndola en el panel de Performance Insights. El panel de
Performance Insights puede mostrar hasta 4096 bytes para una instrucción SQL. Puede copiar la
instrucción SQL mostrada. Para ver más de 4096 bytes, elija Download full SQL (Descargar SQL completo)
para ver el texto SQL hasta el límite del motor de base de datos.
El límite del texto de SQL depende del motor de la base de datos. Se aplican los siguientes límites:
• Aurora MySQL 5.7: 4096 bytes

• Aurora MySQL 5.6: 1024 bytes
• Aurora PostgreSQL: establecido por el parámetro de instancia de base de datos
track_activity_query_size
Para instancias de base de datos de Aurora PostgreSQL, puede controlar el límite de tamaño del texto
SQL ajustando el parámetro de instancia de base de datos track_activity_query_size hasta en 102
400 bytes. Puede utilizar la Consola de administración de AWS para descargar texto SQL hasta el límite
establecido por este parámetro. Para obtener más información, consulte Ajuste del limite de texto SQL
para las instancias de base de datos de Aurora PostgreSQL (p. 418).
Important
Actualmente, solo puede ver y descargar más texto SQL con la Consola de administración de
AWS. La CLI y la API de AWS Performance Insights pueden devolver un máximo de 500 bytes de
texto.
Note
Para instancias de base de datos de Aurora MySQL, la visualización de más texto SQL no se
admite en la región UE Estocolmo.
Para ver más texto SQL en el panel de Performance Insights

2. En el panel de navegación, seleccione Performance Insights.
3. Elija una instancia de base de datos. Se abre el panel de Performance Insights para esa instancia de
base de datos.
Las instrucciones SQL con texto superior a 500 bytes son similares a las que se indican en la siguiente
imagen.

417
4. Abra una instrucción SQL para ver más texto SQL.
El panel de Performance Insights puede mostrar hasta 4096 bytes por cada instrucción SQL.
5. (Opcional) Elija Copy snippet (Copiar fragmento) para copiar la instrucción SQL mostrada, o bien elija
Download full SQL (Descargar SQL completo) para descargar la instrucción SQL y ver el texto SQL
hasta el límite del motor de base de datos.
Note
Para copiar o descargar la instrucción SQL, deshabilite los bloqueadores de pantallas

emergentes.
Ajuste del limite de texto SQL para las instancias de base de datos de Aurora
PostgreSQL
Para las instancias de base de datos de Aurora PostgreSQL, puede controlar el límite de texto SQL que se
puede mostrar en el panel de Performance Insights.

418
Características adicionales de la interfaz de usuario
Para ello, modifique el parámetro de instancia de base de datos track_activity_query_size.

En la versión 9.6 de Aurora PostgreSQL, el ajuste predeterminado del parámetro
track_activity_query_size es 1024 bytes. En la versión 10 o posterior de Aurora PostgreSQL, el
ajuste predeterminado del parámetro track_activity_query_size es 4096 bytes.
Puede aumentar el número de bytes para aumentar el tamaño del texto SQL visible en el panel de
Performance Insights. El límite del parámetro es 10240 bytes. Para obtener más información sobre el
parámetro de instancia de base de datos track_activity_query_size, consulte Run-time Statistics
(Estadísticas de tiempo de ejecución) en la documentación de PostgreSQL.
Para modificar el parámetro, cambie el ajuste en el grupo de parámetros asociado a la instancia de base
de datos de Aurora PostgreSQL.
Si la instancia de base de datos de Aurora PostgreSQL utiliza el grupo de parámetros predeterminado,

realice los siguientes pasos:
1. Cree un nuevo grupo de parámetros de instancia de base de datos para el motor de base de datos y la
versión del motor de base de datos adecuados.
2. Establezca el parámetro en el nuevo grupo de parámetros.
3. Asocie el nuevo grupo de parámetros a la instancia de base de datos.
Para obtener más información sobre configurar un parámetro de instancia de base de datos, consulte
Modificación de parámetros de un grupo de parámetros de base de datos (p. 265).
Características adicionales de la interfaz de usuario

Hay otras características de la interfaz de usuario de Performance Insights que ayudan a analizar los datos
de desempeño.
Ampliación mediante clic y arrastre del ratón
En la interfaz de Performance Insights, se puede seleccionar una pequeña parte del gráfico de carga y
ampliarlo para ver los detalles.
Para ampliar una parte del gráfico de carga, elija la hora de inicio y arrastre el ratón hasta el final del
período que desee. Al hacer esto, el área seleccionada queda resaltada. Al soltar el ratón, el gráfico de
carga se amplía en la zona seleccionada y la tabla Top N se recalcula.
Pausa y reducción
En la esquina superior derecha del gráfico de carga, encontrará las herramientas Pause y Zoom out.

419
API de Performance Insights
Al elegir Pause, el gráfico de carga deja de actualizarse automáticamente. Al elegir Pause de nuevo, el
gráfico de carga vuelve a actualizarse automáticamente.
Al elegir Zoom out, el gráfico de carga se reduce para mostrar un intervalo de tiempo más largo.

La API Performance Insights de Amazon RDS proporciona visibilidad del rendimiento de la instancia de
RDS, cuando Performance Insights está habilitado para los tipos de motor admitidos. Amazon CloudWatch
Logs constituye la fuente autorizada de métricas de monitoreo incluidas para los servicios de AWS.
Performance Insights ofrece una vista específica del dominio de la carga de la base de datos, medida
como promedio de sesiones activas y proporcionada a los consumidores del API como conjunto de datos
de serie temporal bidimensional. La dimensión temporal de los datos proporciona datos de carga de base
de datos para cada punto temporal del intervalo de tiempo consultado. Cada punto temporal descompone
la carga global en relación con las dimensiones solicitadas, tales como SQL, Wait-event, Host o User,
medidas en ese punto temporal.
Performance Insights de Amazon RDS monitoriza la instancia de base de datos de Amazon RDS para
poder analizar y solucionar los problemas de desempeño de la base de datos. Una forma de ver los
datos de Performance Insights es a través de la Consola de administración de AWS. Performance
Insights además ofrece una API pública, para poder consultar en sus propios datos. La API se puede
utilizar para descargar datos en una base de datos, añadir datos de Performance Insights a paneles de
monitorización existentes o crear herramientas de monitorización. Para utilizar la API de Performance
Insights, habilite Performance Insights en una de sus instancias de base de datos de Amazon RDS. Para
obtener información sobre la habilitación de Performance Insights, consulte Activación de Performance
Insights (p. 404).
Para obtener información sobre la API de Performance Insights, consulte la Referencia de la API de
Performance Insights de Amazon RDS.
AWS CLI de Performance Insights

Puede ver los datos de Performance Insights a través de la AWS CLI. Puede obtener ayuda sobre los
comandos de la AWS CLI de Performance Insights escribiendo lo siguiente en la línea de comandos.
aws pi help
Si no tiene instalada la AWS CLI, consulte Instalación de la AWS CLI en la Guía del usuario de la AWS CLI
para obtener información sobre cómo instalarla.
Recuperación de métricas de series temporales

La operación GetResourceMetrics recupera una o más métricas de series temporales a partir de los
datos de Performance Insights. GetResourceMetrics requiere una métrica y un periodo de tiempo y
devuelve una respuesta con una lista de puntos de datos.
Por ejemplo, la Consola de administración de AWS utiliza GetResourceMetrics en dos lugares en el

panel de Performance Insights. GetResourceMetrics se utiliza para rellenar el gráfico Counter Metrics
(Métricas de contador) y el gráfico Database Load (Carga de base de datos), tal y como se muestra en la
siguiente imagen.

420
Todas las métricas que devuelve GetResourceMetrics son métricas de series temporales estándar
con una excepción. La excepción es db.load, que es la métrica principal en Performance Insights. Esta
métrica se muestra en el gráfico Database Load (Carga de base de datos). La métrica db.load es distinta
de las demás métricas de series temporales porque puede desglosarla en subcomponentes llamados
dimensiones. En la imagen anterior, db.load está desglosado y agrupado por los estados de espera que
forman el db.load.
Para obtener información acerca del uso del comando get-resource-metrics de la AWS CLI, consulte
get-resource-metrics.
Para la opción --metric-queries, especifique una o más consultas para las que desea obtener
resultados. Cada consulta consta de un parámetro Metric obligatorio y de parámetros opcionales
GroupBy y Filter. A continuación, se muestra un ejemplo de una especificación de opción --metric-
queries.
{
"Metric": "string",
"GroupBy": {
"Group": "string",
"Dimensions": ["string", ...],
"Limit": integer
},
"Filter": {"string": "string"
...}
}
Ejemplos de AWS CLI para Performance Insights

A continuación, se muestran varios ejemplos que utilizan la AWS CLI para Performance Insights.
Temas
• Recuperación de métricas de contador (p. 422)

421
• Recuperación del promedio de carga de base de datos para los eventos de espera
principales (p. 424)
• Recuperación del promedio de carga de base de datos para las instrucciones SQL
principales (p. 426)
• Recuperación del promedio de carga de base de datos filtrado por SQL (p. 429)
Recuperación de métricas de contador

La siguiente imagen muestra dos gráficos de métricas de contador en la Consola de administración de
AWS.
El siguiente ejemplo muestra cómo recopilar los mismos datos que utiliza la Consola de administración de
AWS para generar los dos gráficos de métricas de contador.
aws pi get-resource-metrics \
--service-type RDS \
--identifier db-ID \
--start-time 2018-10-30T00:00:00Z \
--end-time 2018-10-30T01:00:00Z \
--period-in-seconds 60 \
--metric-queries '[{"Metric": "sys.cpu.user.avg" },
{"Metric": "sys.cpu.system.avg"}]'
Para Windows:
aws pi get-resource-metrics ^
--service-type RDS ^
--identifier db-ID ^
--start-time 2018-10-30T00:00:00Z ^
--end-time 2018-10-30T01:00:00Z ^
--period-in-seconds 60 ^
--metric-queries '[{"Metric": "sys.cpu.user.avg" },
{"Metric": "sys.cpu.system.avg"}]'
También puede hacer que un comando sea más fácil de leer especificando un archivo para la opción --
metrics-query. El siguiente ejemplo utiliza un archivo llamado query.json para la opción. El archivo
tiene el siguiente contenido.

422
[
{
"Metric": "sys.cpu.user.avg"
},
{
"Metric": "sys.cpu.system.avg"
}
]
Ejecute el siguiente comando para utilizar el archivo.
--start-time 2018-10-30T00:00:00Z \
--end-time 2018-10-30T01:00:00Z \
--metric-queries file://query.json
Para Windows:
--start-time 2018-10-30T00:00:00Z ^
--end-time 2018-10-30T01:00:00Z ^
El ejemplo anterior especifica los siguientes valores para las opciones:
• --service-type: RDS para Amazon RDS

• --identifier: el ID de recurso para la instancia de base de datos
• --start-time y --end-time: los valores ISO 8601 DateTime para el periodo de consulta, con varios
formatos admitidos
Consulta durante un intervalo de una hora:
• --period-in-seconds : 60 para una consulta por minuto

• --metric-queries: una matriz de dos consultas, cada una para una métrica.
El nombre de la métrica utiliza puntos para clasificar la métrica en categorías útiles y el elemento final es
una función. En el ejemplo, la función es avg para cada consulta. Al igual que con Amazon CloudWatch,
las funciones admitidas son min, max, total y avg.
La respuesta tiene un aspecto similar a la siguiente.

423
{
"Identifier": "db-XXX",
"AlignedStartTime": 1540857600.0,
"AlignedEndTime": 1540861200.0,
"MetricList": [
{ //A list of key/datapoints
"Key": {
"Metric": "sys.cpu.user.avg" //Metric1
},
"DataPoints": [
//Each list of datapoints has the same timestamps and same number of items
{
"Timestamp": 1540857660.0, //Minute1
"Value": 4.0
},
{
"Value": 4.0
},
{
"Timestamp": 1540857780.0, //Minute 3
"Value": 10.0
}
//... 60 datapoints for the sys.cpu.user.avg metric
]
},
{
"Key": {
"Metric": "sys.cpu.system.avg" //Metric2
},
"DataPoints": [
{
"Value": 12.0
},
{
"Value": 13.5
},
//... 60 datapoints for the sys.cpu.system.avg metric
]
}
] //end of MetricList
} //end of response
La respuesta tiene un Identifier, un AlignedStartTime y un AlignedEndTime. Como el valor --

period-in-seconds era 60, los tiempos de inicio y final se han alineado con el minuto. Si el --period-
in-seconds fuera 3600, los tiempos de inicio y final se habrían alineado con la hora.
La MetricList en la respuesta tiene una serie de entradas, cada una con una entrada Key y una entrada
DataPoints. Cada DataPoint tiene un Timestamp y un Value. Cada lista Datapoints tiene 60
puntos de datos porque las consultas son datos por minuto sobre una hora, con Timestamp1/Minute1,
Timestamp2/Minute2y así sucesivamente, hasta Timestamp60/Minute60.
Como la consulta es para dos métricas de contador distintas, hay dos elementos en la respuesta
MetricList.
Recuperación del promedio de carga de base de datos para los eventos de

espera principales
El siguiente ejemplo es la misma consulta que utiliza la Consola de administración de AWS para generar
un gráfico de línea de área apilada. Este ejemplo recupera el db.load.avg durante la última hora con la

424
carga dividida según los siete eventos de espera principales. El comando es el mismo que el comando en
Recuperación de métricas de contador (p. 422). Sin embargo, el archivo query.json tiene los elementos
indicados a continuación.
[
{
"Metric": "db.load.avg",
"GroupBy": { "Group": "db.wait_event", "Limit": 7 }
}
]
Ejecute el comando siguiente.
--start-time 2018-10-30T00:00:00Z \
--end-time 2018-10-30T01:00:00Z \
Para Windows:
--start-time 2018-10-30T00:00:00Z ^
--end-time 2018-10-30T01:00:00Z ^
El ejemplo especifica la métrica de db.load.avg y un GroupBy de los siete eventos de espera

principales. Para obtener detalles acerca de los valores válidos para este ejemplo, consulte
DimensionGroup en la Referencia de la API de Performance Insights.
{
"MetricList": [
{ //A list of key/datapoints
"Key": {
//A Metric with no dimensions. This is the total db.load.avg
"Metric": "db.load.avg"
},
"DataPoints": [
//Each list of datapoints has the same timestamps and same number of items
{

425
"Value": 0.5166666666666667
},
{
"Value": 0.38333333333333336
},
{
"Timestamp": 1540857780.0, //Minute 3
"Value": 0.26666666666666666
}
//... 60 datapoints for the total db.load.avg key
]
},
{
"Key": {
//Another key. This is db.load.avg broken down by CPU
"Dimensions": {
"db.wait_event.name": "CPU",
"db.wait_event.type": "CPU"
}
},
"DataPoints": [
{
"Value": 0.35
},
{
"Value": 0.15
},
//... 60 datapoints for the CPU key
]
},
//... In total we have 8 key/datapoints entries, 1) total, 2-8) Top Wait Events
] //end of MetricList
} //end of response
En esta respuesta, hay ocho entradas en la MetricList. Hay una entrada para el db.load.avg total
y siete entradas para el db.load.avg divididas según uno de los siete eventos de espera principales. A
diferencia del primer ejemplo, como había una dimensión de agrupación, debe haber una clave para cada
agrupación de la métrica. No puede haber solo una clave para cada métrica, como en el caso de uso de
métrica de contador básica.
Recuperación del promedio de carga de base de datos para las instrucciones

SQL principales
El siguiente ejemplo agrupa db.wait_events por las 10 instrucciones SQL principales. Hay dos grupos
distintos para instrucciones SQL:
• db.sql: la instrucción SQL completa, como select * from customers where customer_id =
123
• db.sql_tokenized: la instrucción SQL tokenizada, como select * from customers where
customer_id = ?
Al analizar el desempeño de la base de datos, puede resultar útil tener en cuenta instrucciones SQL
que solo se diferencien en sus parámetros como un elemento de lógica. Así pues, puede utilizar
db.sql_tokenized al consultar. Sin embargo, sobre todo cuando le interese explicar planes, a veces
es más útil examinar instrucciones SQL completas con parámetros y consultar agrupando por db.sql.
Existe una relación principal-secundaria entre instrucciones SQL tokenizadas y completas, con varias

426
instrucciones SQL completas (secundarias) agrupadas bajo la misma instrucción SQL tokenizada
(principal).
El comando en este ejemplo es similar al comando en Recuperación del promedio de carga de base
de datos para los eventos de espera principales (p. 424). Sin embargo, el archivo query.json tiene los
elementos indicados a continuación.
[
{
"GroupBy": { "Group": "db.sql_tokenized", "Limit": 10 }
}
]
El siguiente ejemplo utiliza db.sql_tokenized.
--start-time 2018-10-29T00:00:00Z \
--end-time 2018-10-30T00:00:00Z \
Para Windows:
--start-time 2018-10-29T00:00:00Z ^
--end-time 2018-10-30T00:00:00Z ^
Este ejemplo consulta durante 24 horas, con un periodo de una hora en segundos.
El ejemplo especifica la métrica de db.load.avg y un GroupBy de los siete eventos de espera

principales. Para obtener detalles acerca de los valores válidos para este ejemplo, consulte
DimensionGroup en la Referencia de la API de Performance Insights.
{
"MetricList": [ //11 entries in the MetricList

{
"Key": { //First key is total

427
}
"DataPoints": [ //Each DataPoints list has 24 per-hour Timestamps and a value
{
"Value": 1.6964980544747081,
"Timestamp": 1540774800.0
},
//... 24 datapoints
]
},
{
"Key": { //Next key is the top tokenized SQL
"Dimensions": {
"db.sql_tokenized.statement": "INSERT INTO authors (id,name,email)
VALUES\n( nextval(?) ,?,?)",
"db.sql_tokenized.db_id": "pi-2372568224",
"db.sql_tokenized.id": "AKIAIOSFODNN7EXAMPLE"
},
},
"DataPoints": [ //... 24 datapoints
]
},
// In total 11 entries, 10 Keys of top tokenized SQL, 1 total key
] //End of MetricList
} //End of response
Esta respuesta tiene 11 entradas en la MetricList (1 total, 10 SQL tokenizadas principales) y cada
entrada tiene 24 DataPoints por hora.
Para consultas SQL tokenizadas, hay tres entradas en cada lista de dimensiones:
• db.sql_tokenized.statement: la instrucción SQL tokenizada.

• db.sql_tokenized.db_id : el ID de base de datos nativo utilizado para hacer referencia a SQL, o un
ID sintético que genera Performance Insights para usted si no se encuentra disponible el ID de base de
datos nativo. Este ejemplo devuelve el ID sintético de pi-2372568224.
• db.sql_tokenized.statement: el ID de la consulta dentro de Performance Insights.
En la Consola de administración de AWS, este ID se denomina ID de soporte. Se llama así porque el

ID son datos que AWS Support puede examinar para ayudarle a resolver problemas con la base de
datos. AWS se toma muy en serio la seguridad y la privacidad de sus datos y casi todos los datos se
almacenan cifrados con su clave de AWS KMS. Por lo tanto, nadie dentro de AWS puede ver estos
datos. En el ejemplo anterior, tanto tokenized_statement como tokenized.db_id se almacenan
cifrados. Si tiene un problema con su base de datos, AWS Support puede ayudarle haciendo referencia
al ID de soporte.
Al realizar consultas, puede ser conveniente especificar un Group en GroupBy. Sin embargo, para un
control de más precisión sobre los datos que se devuelven, especifique la lista de dimensiones. Por
ejemplo, si todo lo que se necesita es db.sql_tokenized.statement, entonces se puede añadir un
atributo Dimensions al archivo query.json.
[
{
"GroupBy": {
"Group": "db.sql_tokenized",
"Dimensions":["db.sql_tokenized.statement"],
"Limit": 10
}
}

428
Recuperación del promedio de carga de base de datos filtrado por SQL
La imagen anterior muestra que se ha seleccionado una consulta concreta y el gráfico de línea de área
apilada de principales sesiones activas promedio se limita a esa consulta. Aunque se siguen consultando
los siete eventos de espera generales principales, se filtra el valor de la respuesta. El filtro hace que solo
tenga en cuenta las sesiones que coinciden con el filtro concreto.
La consulta de API correspondiente en este ejemplo es similar al comando en Recuperación del promedio
de carga de base de datos para las instrucciones SQL principales (p. 426). Sin embargo, el archivo
query.json tiene los elementos indicados a continuación.
[
{
"GroupBy": { "Group": "db.wait_event", "Limit": 5 },
"Filter": { "db.sql_tokenized.id": "AKIAIOSFODNN7EXAMPLE" }
}
]
--start-time 2018-10-30T00:00:00Z \
--end-time 2018-10-30T01:00:00Z \
Para Windows:

429
--start-time 2018-10-30T00:00:00Z ^
--end-time 2018-10-30T01:00:00Z ^
{
"MetricList": [
{
"Key": {
},
"DataPoints": [
{
"Timestamp": 1556218800.0,
"Value": 1.4878117913832196
},
{
"Timestamp": 1556222400.0,
"Value": 1.192823803967328
}
]
},
{
"Key": {
"Dimensions": {
"db.wait_event.type": "io",
"db.wait_event.name": "wait/io/aurora_redo_log_flush"
}
},
"DataPoints": [
{
"Timestamp": 1556218800.0,
"Value": 1.1360544217687074
},
{
"Timestamp": 1556222400.0,
"Value": 1.058051341890315
}
]
},
{
"Key": {
"Dimensions": {
"db.wait_event.type": "io",
"db.wait_event.name": "wait/io/table/sql/handler"
}
},
"DataPoints": [
{
"Timestamp": 1556218800.0,
"Value": 0.16241496598639457
},

430
{
"Timestamp": 1556222400.0,
"Value": 0.05163360560093349
}
]
},
{
"Key": {
"Dimensions": {
"db.wait_event.type": "synch",
"db.wait_event.name": "wait/synch/mutex/innodb/
aurora_lock_thread_slot_futex"
}
},
"DataPoints": [
{
"Timestamp": 1556218800.0,
"Value": 0.11479591836734694
},
{
"Timestamp": 1556222400.0,
"Value": 0.013127187864644107
}
]
},
{
"Key": {
"Dimensions": {
"db.wait_event.type": "CPU",
"db.wait_event.name": "CPU"
}
},
"DataPoints": [
{
"Timestamp": 1556218800.0,
"Value": 0.05215419501133787
},
{
"Timestamp": 1556222400.0,
"Value": 0.05805134189031505
}
]
},
{
"Key": {
"Dimensions": {
"db.wait_event.type": "synch",
"db.wait_event.name": "wait/synch/mutex/innodb/lock_wait_mutex"
}
},
"DataPoints": [
{
"Timestamp": 1556218800.0,
"Value": 0.017573696145124718
},
{
"Timestamp": 1556222400.0,
"Value": 0.002333722287047841
}
]
}
],
"AlignedEndTime": 1556222400.0

431
Métricas publicadas en CloudWatch
} //end of response
En esta respuesta, todos los valores se filtran según la contribución del SQL tokenizado
AKIAIOSFODNN7EXAMPLE especificado en el archivo query.json. Las claves también podrían seguir un
orden distinto de una consulta sin un filtro, porque el SQL filtrado afectaba a los cinco eventos de espera
principales.
Métricas de Performance Insights publicadas en

Amazon CloudWatch
Performance Insights publica automáticamente las métricas en Amazon CloudWatch. Se pueden consultar
los mismos datos en Performance Insights, pero al contar con las métricas en CloudWatch es sencillo
añadir alarmas de CloudWatch. También resulta fácil añadir las métricas a paneles de CloudWatch
existentes.
DBLoad El número de sesiones activas del motor de

base de datos. Normalmente, necesita los datos
del número promedio de sesiones activas. En
Performance Insights, estos datos se consultan
como db.load.avg.
DBLoadCPU El número de sesiones activas cuyo tipo de evento

de espera es CPU. En Performance Insights, estos
datos se consultan como db.load.avg, filtrados
por el tipo de evento de espera CPU.
DBLoadNonCPU Promedio de sesiones activas cuyo tipo de evento

de espera no es CPU.
Puede examinar estas métricas mediante la consola de CloudWatch, la AWS CLI o el API de CloudWatch.
Por ejemplo, puede obtener las estadísticas para la métrica DBLoad ejecutando el comando get-metric-
statistics.
aws cloudwatch get-metric-statistics --region us-west-2 --namespace AWS/RDS --metric-name

DBLoad --period 60 --statistics Average --start-time 1532035185 --end-time 1532036185 --
dimensions Name=DBInstanceIdentifier,Value=db-loadtest-0
Este ejemplo genera un resultado similar al siguiente.
{
"Datapoints": [
{
"Timestamp": "2018-07-19T21:30:00Z",
"Unit": "None",
"Average": 2.1
},
{
"Timestamp": "2018-07-19T21:34:00Z",
"Unit": "None",
"Average": 1.7

432
Contadores de Performance Insights
},
{
"Timestamp": "2018-07-19T21:35:00Z",
"Unit": "None",
"Average": 2.8
},
{
"Timestamp": "2018-07-19T21:31:00Z",
"Unit": "None",
"Average": 1.5
},
{
"Timestamp": "2018-07-19T21:32:00Z",
"Unit": "None",
"Average": 1.8
},
{
"Timestamp": "2018-07-19T21:29:00Z",
"Unit": "None",
"Average": 3.0
},
{
"Timestamp": "2018-07-19T21:33:00Z",
"Unit": "None",
"Average": 2.4
}
],
"Label": "DBLoad"
}
Para obtener más información acerca de CloudWatch, consulte ¿Qué es Amazon CloudWatch? en la Guía
del usuario de Amazon CloudWatch.

Con las métricas de contador, puede personalizar el panel de Performance Insights para que incluya hasta
10 gráficos adicionales. Estos gráficos muestran una selección de docenas de métricas de desempeño de
sistemas operativos y bases de datos. Esta información se puede correlacionar con la carga de las bases
de datos para ayudar a identificar y analizar problemas de desempeño.
Temas
• Contadores de sistemas operativos de Performance Insights (p. 433)
• Contadores de Performance Insights para Aurora MySQL (p. 435)
• Contadores de Performance Insights para Aurora PostgreSQL (p. 438)
Contadores de sistemas operativos de Performance Insights

Los siguientes contadores de sistemas operativos están disponibles para Performance Insights
para Aurora PostgreSQL. Puede encontrar definiciones para estas métricas en Visualización de la
monitorización mejorada con CloudWatch Logs (p. 399).
Contador Tipo
active (activa) memory
buffers memory
cached memory

433
Contador Tipo
dirty memory
free memory
inactive memory
hugePagesFree memory
hugePagesRsvd memory
hugePagesSize memory
hugePagesSurp memory
hugePagesTotal memory
mapped memory
pageTables memory
slab memory
total memory
writeback memory
guest cpuUtilization
idle cpuUtilization
irq cpuUtilization
nice cpuUtilization
steal cpuUtilization
system cpuUtilization
total cpuUtilization
user cpuUtilization
wait cpuUtilization
avgQueueLen diskIO
avgReqSz diskIO
await diskIO
readIOsPS diskIO
readKb diskIO
readKbPS diskIO
rrqmPS diskIO
tps diskIO
util diskIO

434
Contador Tipo
writeIOsPS diskIO
writeKb diskIO
writeKbPS diskIO
wrqmPS diskIO
blocked tasks
running tasks
sleeping tasks
stopped tasks
total tasks
zombie tasks
one loadAverageMinute
fifteen loadAverageMinute
cinco loadAverageMinute
cached swap
free swap
in swap
out swap
total swap
maxFiles fileSys
usedFiles fileSys
usedFilePercent fileSys
usedPercent fileSys
used fileSys
total fileSys
rx network
tx network
numVCPUs general
Contadores de Performance Insights para Aurora MySQL

Los siguientes contadores de base de datos están disponibles con Performance Insights para Aurora
MySQL.
Temas

435
• Contadores nativos para Aurora MySQL (p. 436)

• Contadores no nativos para Aurora MySQL (p. 437)
Contadores nativos para Aurora MySQL

Puede encontrar las definiciones de estas métricas nativas en Server Status Variables (Variables de
estado de servidor) en la documentación de MySQL.
Contador Tipo Unidad
Com_analyze SQL Consultas por segundo
Com_optimize SQL Consultas por segundo
Com_select SQL Consultas por segundo
Innodb_rows_deleted SQL Filas por segundo
Innodb_rows_inserted SQL Filas por segundo
Innodb_rows_read SQL Filas por segundo
Innodb_rows_updated SQL Filas por segundo
Select_full_join SQL Consultas por segundo
Select_full_range_join SQL Consultas por segundo
Select_range SQL Consultas por segundo
Select_range_check SQL Consultas por segundo
Select_scan SQL Consultas por segundo
Slow_queries SQL Consultas por segundo
Sort_merge_passes SQL Consultas por segundo
Sort_range SQL Consultas por segundo
Sort_rows SQL Consultas por segundo
Sort_scan SQL Consultas por segundo
Preguntas SQL Consultas por segundo
Table_locks_immediate Bloqueos Solicitudes por segundo
Table_locks_waited Bloqueos Solicitudes por segundo
Innodb_row_lock_time Bloqueos Milisegundos (promedio)
Aborted_clients Usuarios Conexiones
Aborted_connects Usuarios Conexiones
Threads_created Usuarios Conexiones
Threads_running Usuarios Conexiones
Created_tmp_disk_tables Temp Tablas por segundo

436
Created_tmp_tables Temp Tablas por segundo
Innodb_buffer_pool_pages_data Caché Páginas
Innodb_buffer_pool_pages_total Caché Páginas
Innodb_buffer_pool_read_requests Caché Páginas por segundo
Innodb_buffer_pool_reads Caché Páginas por segundo
Opened_tables Caché Tablas
Opened_table_definitions Caché Tablas
Qcache_hits Caché Consultas
Contadores no nativos para Aurora MySQL

Las métricas de contadores no nativos se definen mediante Amazon RDS. Una métrica no nativa puede
ser una métrica que obtiene con una consulta concreta. Una métrica no nativa también puede ser una
métrica derivada, en la que se utilicen dos o más contadores nativos en cálculos para proporciones,
aciertos o latencias.
Contador Tipo Descripción Definición
innodb_buffer_pool_hits
Caché El número de lecturas que innodb_buffer_pool_read_requests
InnoDB podría cumplir del grupo -
de búferes. innodb_buffer_pool_reads
innodb_buffer_pool_hit_rate
Caché El porcentaje de lecturas que 100 *
InnoDB podría cumplir del grupo innodb_buffer_pool_read_requests /
de búferes. (innodb_buffer_pool_read_requests
+
innodb_buffer_pool_reads)
innodb_buffer_pool_usage
Caché El porcentaje del grupo de Innodb_buffer_pool_pages_data /
búferes de InnoDB que contiene Innodb_buffer_pool_pages_total
datos (páginas). * 100.0
Note
Al usar tablas
comprimidas, este
valor puede variar.
Para obtener más
información, consulte la
información acerca de
Innodb_buffer_pool_pages_data
y
Innodb_buffer_pool_pages_total
en Server Status
Variables (Variables de
estado de servidor) en
la documentación de
MySQL.

437
query_cache_hit_rate
Caché La proporción de aciertos de Qcache_hits /
caché de conjunto de resultados (QCache_hits +
MySQL (caché de consultas). Com_select) * 100
innodb_rows_changed
SQL Las operaciones de filas de db.SQL.Innodb_rows_inserted
InnoDB totales. +
db.SQL.Innodb_rows_deleted
+
db.SQL.Innodb_rows_updated
active_transactions
Transacciones Las transacciones activas totales. SELECT COUNT(1) AS
active_transactions FROM
INFORMATION_SCHEMA.INNODB_TRX
innodb_deadlocksBloqueos El número total de interbloqueos. SELECT COUNT AS

innodb_deadlocks FROM
INFORMATION_SCHEMA.INNODB_METRICS
WHERE
NAME='lock_deadlocks'
innodb_lock_timeouts
Bloqueos El número total de interbloqueos SELECT COUNT AS
que agotaron el tiempo de innodb_lock_timeouts
espera. FROM
WHERE
NAME='lock_timeouts'
innodb_row_lock_waits
Bloqueos El número total de bloqueos que SELECT COUNT AS
resultaron en una espera. innodb_row_lock_waits
FROM
WHERE
NAME='lock_row_lock_waits'
Contadores de Performance Insights para Aurora PostgreSQL

Los siguientes contadores de base de datos están disponibles con Performance Insights para Aurora
PostgreSQL.
Temas
• Contadores nativos para Aurora PostgreSQL (p. 438)
• Contadores no nativos para Aurora PostgreSQL (p. 440)
Contadores nativos para Aurora PostgreSQL

Puede encontrar definiciones para estas métricas en Viewing Statistics (Ver estadísticas) en la
documentación de PostgreSQL.
tup_deleted SQL Tuplas por segundo
tup_fetched SQL Tuplas por segundo

438
tup_inserted SQL Tuplas por segundo
tup_returned SQL Tuplas por segundo
tup_updated SQL Tuplas por segundo
buffers_checkpoint Punto de comprobación Bloques por segundo
checkpoints_req Punto de comprobación Puntos de comprobación por

minuto
checkpoint_sync_time Punto de comprobación Milisegundos por punto de

comprobación
checkpoints_timed Punto de comprobación Puntos de comprobación por

minuto
checkpoint_write_time Punto de comprobación Milisegundos por punto de

comprobación
maxwritten_clean Punto de comprobación Paradas de eliminación de

Bgwriter por minuto
active_transactions Transacciones Transacciones
blocked_transactions Transacciones Transacciones
max_used_xact_ids Transacciones Transacciones
xact_commit Transacciones Confirmaciones por segundo
xaxt_rollback Transacciones Restauraciones por segundo
blk_read_time E/S Milisegundos
blks_read E/S Bloques por segundo
buffers_backend E/S Bloques por segundo
buffers_backend_fsync E/S Bloques por segundo
buffers_clean E/S Bloques por segundo
blks_hit Caché Bloques por segundo
buffers_alloc Caché Bloques por segundo
temp_files Temp Archivos por minuto
numbackends Usuario Conexiones
deadlocks Simultaneidad Interbloqueos por minuto
archived_count WAL Archivos por minuto
archive_failed_count WAL Archivos por minuto

439
Registro de operaciones de Performance
Insights mediante AWS CloudTrail
Contadores no nativos para Aurora PostgreSQL

Las métricas de contadores no nativos se definen mediante Amazon RDS. Una métrica no nativa puede
ser una métrica que obtiene con una consulta concreta. Una métrica no nativa también puede ser una
métrica derivada, en la que se utilicen dos o más contadores nativos en cálculos para proporciones,
aciertos o latencias.
checkpoint_sync_latency
Punto de La cantidad de tiempo invertido checkpoint_sync_time /
comprobación en la parte del procesamiento del (checkpoints_timed +
punto de comprobación en la que checkpoints_req)
los archivos se han sincronizado
en el disco.
checkpoint_write_latency
Punto de La cantidad de tiempo invertido checkpoint_write_time /
comprobación en la parte del procesamiento del (checkpoints_timed +
punto de comprobación en la que checkpoints_req)
los archivos se han escrito en el
disco.
read_latency E/S El tiempo invertido leyendo blk_read_time /

bloques de archivos de datos por blks_read
backends en esta instancia.
Registro de operaciones de Performance Insights

mediante AWS CloudTrail
Performance Insights se integra con AWS CloudTrail. CloudTrail captura las solicitudes de API de bajo
nivel realizadas por o en nombre de Performance Insights en su cuenta de AWS. CloudTrail a continuación
entrega los archivos de registro a un bucket de Amazon S3 que se especifique. CloudTrail captura las
llamadas realizadas desde Performance Insights en la consola de RDS o desde la API de bajo nivel de
Performance Insights.
A partir de la información recopilada por CloudTrail, puede determinar qué solicitud se realizó a
Performance Insights. También puede identificar la dirección IP de origen desde la que se realizó, quién
realizó la solicitud, cuándo se realizó, etcétera. El registro de CloudTrail se habilita automáticamente en
la cuenta de AWS. Para obtener más información acerca de CloudTrail, consulte la AWS CloudTrail User
Guide.
Las llamadas al API de bajo nivel efectuadas a Performance Insights se registran en archivos log. Los
registros de Performance Insights se agrupan junto con otros registros de servicios de AWS en un archivo
de registro. CloudTrail determina cuándo se crea un archivo nuevo para usarlo como registro en función
del periodo de tiempo y el tamaño del archivo. Se admiten las siguientes operaciones de la API:
• DescribeDimensionKeys
• GetResourceMetrics
Uso de recomendaciones de Amazon Aurora

Amazon Aurora ofrece recomendaciones automatizadas para recursos de base de datos, como instancias
de base de datos, clústeres de base de datos, y grupos de parámetros de clúster de base de datos. Estas
recomendaciones proporcionan instrucciones de las prácticas recomendadas mediante el análisis de la

440
configuración de clúster de base de datos, la configuración de instancia de base de datos, el uso y los
datos de rendimiento.
Puede encontrar ejemplos de estas recomendaciones en la siguiente tabla.
Tipo Descripción Recomendación Información adicional
Parámetros Su grupo de Los ajustes que se diferencia Trabajo con los

de memoria parámetros de base demasiado de los valores grupos de parámetros
personalizados de datos establece predeterminados pueden de base de datos y
no los parámetros de provocar errores y un rendimiento grupos de parámetros
predeterminadosmemoria que se deficiente. Recomendamos de clúster de base de
diferencian demasiado establecer parámetros de memoria datos (p. 259)
de los valores personalizados en valores
predeterminados. predeterminados en el grupo de
parámetros de base de datos utilizado
por la instancia de base de datos.
Cambio de Su grupo de El cambio de almacenamiento en Prácticas

almacenamientoparámetros de búfer permite a una instancia de base recomendadas para
en búfer base de datos de datos aplazar algunas escrituras la configuración de
habilitado tiene el cambio de necesarias para mantener los índices parámetros para
para una almacenamiento en secundarios. Esta configuración puede Amazon RDS para
instancia de búfer habilitado. mejorar ligeramente el rendimiento, MySQL, part 1:
base de datos pero puede crear un gran retraso en Parameters related to
de MySQL el recuperación de bloqueos. Durante performance (MySQL,
la recuperación de bloqueos, se debe parte 1: parámetros
actualizar el índice secundario. Por relacionados con el
lo tanto, las ventajas del cambio rendimiento) en el
de almacenamiento en búfer se blog de base de datos
compensan con los posibles eventos de AWS
de recuperación de bloqueos muy
largos. Recomendamos deshabilitar el
cambio de almacenamiento en búfer.
Caché de Su grupo de La caché de consultas puede provocar Prácticas

consultas parámetros de base que la instancia de base de datos recomendadas para
habilitada de datos dispone aparezca detenida cuando los cambios la configuración de
para una de un parámetro de requieran que se purgue la caché. parámetros para
instancia de caché de consultas La mayoría de las cargas de trabajo Amazon RDS para
base de datos habilitado. no se benefician de una caché de MySQL, part 1:
de MySQL consultas. La caché de consultas se Parameters related to
quitó de la versión 8.0 de MySQL. performance (MySQL,
Le recomendamos que deshabilite el parte 1: parámetros
parámetro de caché de consultas. relacionados con el
rendimiento) en el
blog de base de datos
de AWS
Registro en la Su grupo de El establecimiento de la salida Archivos de registro

tabla parámetros de base de registro en TABLE utiliza más de base de datos de
de datos establece la almacenamiento que la configuración MySQL (p. 485)
salida de registro en de este parámetro en FILE. Para
TABLE. evitar que se alcance el límite de
almacenamiento, recomendamos
establecer el parámetro de salida de
registro a FILE.

441
Clúster de Su clúster de base de Para ofrecer un rendimiento y fiabilidad Alta disponibilidad

base de datos solo contiene mejorados, recomendamos añadir para Aurora (p. 28)
datos con una una instancia de base otra instancia de base de datos con la
instancia de de datos. misma clase de instancia de base de
base de datos datos en una zona de disponibilidad
diferente.
Clúster de Su clúster de base Para ofrecer una disponibilidad Alta disponibilidad

base de de datos dispone de mejorada, recomendamos añadir otra para Aurora (p. 28)
datos en todas las instancias instancia de base de datos con la
una zona de de base de datos en misma clase de instancia de base de
disponibilidad la misma zona de datos en una zona de disponibilidad
disponibilidad. diferente.
Clúster de Su clúster de base de Le recomendamos que su clúster Mantenimiento de

base de datos datos está ejecutando de base de datos esté actualizado un clúster de base
obsoleto una versión de motor con la versión secundaria más de datos de Amazon
antigua. reciente, ya que incluirá las últimas Aurora (p. 340)
correcciones de seguridad y
funcionalidad. A diferencia de
las actualizaciones de versiones
principales, las actualizaciones de
versiones secundarias solo incluyen
cambios compatibles con versiones
secundarias anteriores (de la misma
versión principal) del motor de base
de datos. Le recomendamos que
actualice a una versión de motor
reciente.
Clúster de Su clúster de base El uso de diferentes grupos de Trabajo con los

base de datos de datos dispone de parámetros puede provocar grupos de parámetros
con diferentes grupos de parámetros incompatibilidades entre las instancias de base de datos y
grupos de de base de datos de base de datos. Para evitar grupos de parámetros
parámetros diferentes asignados problemas y conseguir realizar un de clúster de base de
a sus instancias de mantenimiento más sencillo, le datos (p. 259)
base de datos. recomendamos utilizar el mismo
grupo de parámetros para todas las
instancias de base de datos en el

442
Respuesta a las recomendaciones
Clúster de Su clúster de base El uso de diferentes clases de Réplicas de

base de datos de datos dispone de instancia de base de datos para Aurora (p. 48)
con diferentes instancias de base instancias de base de datos puede
clases de de datos que utilizan provocar problemas. Por ejemplo, el
instancia de distintas clases de rendimiento puede verse afectado
base de datos instancia de base de si se promueve una instancia de
datos. base de datos menos potente para
reemplazar a una clase de instancia
de base de datos más potente. Para
evitar problemas y conseguir realizar
un mantenimiento más sencillo, le
recomendamos utilizar la misma clase
de instancia de base de datos para
las instancias de base de datos en el
Amazon Aurora genera recomendaciones para un recurso cuando se crea o modifica el recurso. Amazon
Aurora analiza también periódicamente sus recursos y genera recomendaciones.
Respuesta a las recomendaciones de Amazon Aurora

Puede encontrar recomendaciones en la Consola de administración de AWS. Puede realizar la acción
recomendada de forma inmediata, programarla para el siguiente periodo de mantenimiento o descartarla.
Para responder a las recomendaciones de Amazon Aurora, realice el siguiente procedimiento:
2. En el panel de navegación, elija Recommendations (Recomendaciones).

443
Aparece la página Recommendations (Recomendaciones)
3. En la página Recommendations (Recomendaciones), elija alguna de las siguientes operaciones:
• Active (Activas): muestra las recomendaciones actuales que puede aplicar, descartar o programar.
• Dismissed (Descartadas): muestra las recomendaciones que se han descartado. Al elegir Dismissed
(Descartadas), puede aplicar estas recomendaciones descartadas.
• Scheduled (Programadas): muestra las recomendaciones que están programadas, pero no se
han aplicado aún. Estas recomendaciones se aplicarán en el siguiente periodo de mantenimiento
programado.

444
• Applied (Aplicadas): muestra las recomendaciones que se aplican actualmente.
En cualquier lista de recomendaciones, puede abrir una sección para ver las recomendaciones de esa
sección.
Para configurar las preferencias a la hora de mostrar las recomendaciones en cada sección, elija el
icono Preferences (Preferencias).
En la ventana Preferences (Preferencias) que aparece, puede establecer opciones de visualización.

Estas opciones incluyen las columnas visibles y el número de recomendaciones que se van a mostrar
en la página.
4. Administre sus recomendaciones activas:
a. Elija Active (Activas) y abra una o varias secciones para ver las recomendaciones en ellas.
b. Elija una o varias recomendaciones y seleccione Apply now (Aplicar ahora) (para aplicarlas
inmediatamente), Schedule (Programar) (para aplicarlas en el siguiente periodo de
mantenimiento) o Dismiss (Descartar).

445
Uso de secuencias de actividades de la base de datos
Si aparece el botón Apply now (Aplicar ahora) para una recomendación, pero no está disponible
(aparece atenuado), la instancia de base de datos tampoco lo estará. Solo podrá aplicar
recomendaciones inmediatamente si el estado de la instancia de base de datos es available
(disponible). Por ejemplo, no podrá aplicar recomendaciones inmediatamente a la instancia de
base de datos si su estado es modifying (modificando). En este caso, espere a que la instancia de
base de datos esté disponible y, a continuación, aplique la recomendación.
Si no aparece el botón Active (Activas) para una recomendación, no podrá aplicar la

recomendación con la página Recommendations (Recomendaciones). Puede modificar la
instancia de base de datos para aplicar la recomendación manualmente.
Para obtener más información sobre la modificación de un clúster de base de datos, consulte
Modificación de un clúster de base de datos Amazon Aurora (p. 235).
Note
Al elegir Apply now (Aplicar ahora), puede producirse una breve interrupción de instancia
de base de datos.
Uso de secuencias de actividades de la base de

datos con Aurora PostgreSQL
Monitorizar la actividad de su base de datos puede serle útil para adoptar medidas de seguridad que
protejan su base de datos y cumplir los requisitos normativos y de cumplimiento. Con Compatibilidad de
Amazon Aurora con PostgreSQL puede monitorizar la actividad de la base de datos mediante secuencias
de actividades de la base de datos. Las secuencias de actividades de la base de datos proporcionan una
secuencia de datos prácticamente en tiempo real de la actividad de su base de datos relacional. Si integra
secuencias de actividades de la base de datos con herramientas de monitorización de terceros, podrá
monitorizar la actividad de la base de datos y realizar su auditoría.
Las bases de datos administradas, además de proporcionar protección contra amenazas externas a la
seguridad, tienen que protegerse también contra los riesgos internos provenientes de los administradores
de bases de datos (DBA). Las secuencias de actividades de la base de datos protegen su bases de datos
contra las amenazas internas, mediante el control del acceso de los DBA a las secuencias de actividades
de la base de datos. Así, los DBA que administran la base de datos no tienen acceso a la recopilación, la
transmisión, el almacenamiento y el procesamiento posterior de la secuencia de actividades de la base de
datos.
Se inserta una secuencia de actividades de la base de datos de Aurora PostgreSQL en una secuencia de
datos de Amazon Kinesis que se crea en nombre de la base de datos. En Kinesis, Amazon CloudWatch
o las aplicaciones pueden utilizar la secuencia de actividades de la base de datos para administrar el
cumplimiento. Las aplicaciones de cumplimiento pueden ser SecureSphere Database Audit and Protection
de Imperva, Data Center Security Suite de McAfee o Infosphere Guardium de IBM. Estas aplicaciones
pueden usar la información de la secuencia de actividades de la base de datos para generar alertas y
proporcionar una auditoría de todas las actividades de sus bases de datos de Amazon Aurora.
Las secuencias de actividades de la base de datos tienen los límites y los requisitos siguientes:
• Actualmente, estas secuencias solo son compatibles con Compatibilidad de Aurora con PostgreSQL
versión 2.3, que es compatible con PostgreSQL, versión 10.7.
• No se admiten en las siguientes regiones de AWS:
• Región China (Pekín), cn-north-1
• Región China (Ningxia), cn-northwest-1
• AWS GovCloud (EE.UU. Este), us-gov-east-1

446
Inicio de una secuencia de actividades de la base de datos
• AWS GovCloud (EE.UU. Oeste), us-gov-west-1

• Es obligatorio el uso de AWS Key Management Service (AWS KMS).
Temas
• Inicio de una secuencia de actividades de la base de datos (p. 447)
• Obtención del estado de una secuencia de actividades de base de datos (p. 449)
• Detención de una secuencia de actividades de la base de datos (p. 449)
• Monitorización de secuencias de actividades de la base de datos (p. 450)
• Administración del acceso a secuencias de actividades de base de datos (p. 463)
Inicio de una secuencia de actividades de la base de

datos
Una secuencia de actividades de la base de datos se inicia en el nivel de clúster de la base de datos para
monitorizar la actividad de todas las instancias de la base de datos del clúster. Toda instancia de la base
de datos que se añada al clúster también se monitorizará automáticamente.
Cuando comience una secuencia de actividades de la base de datos, todos los eventos de actividad de
la base de datos, como un cambio o un acceso, generarán un evento en la secuencia de actividades.
Los eventos de acceso se generan a partir de comandos SQL como CONNECT y SELECT. Los eventos de
cambio se generan a partir de comandos SQL como CREATE y INSERT. Para que todos los eventos de
la secuencia de actividades sean duraderos, cífrelos y almacénelos. Puede optar por que la sesión de la
base de datos gestione los eventos de actividad de la base de datos de forma síncrona o asíncrona:
• Modo síncrono: en el modo síncrono, cuando una sesión de la base de datos genera un evento de
secuencia de actividades, la sesión se bloquea hasta que se hace que el evento sea duradero. Si, por
algún motivo, no se puede conseguir que el evento sea duradero, la sesión de la base de datos volverá
a las actividades normales. Sin embargo, se enviará un evento RDS para indicar que podrían haberse
perdido registros de la secuencia de actividades durante algún tiempo. Cuando el estado del sistema
vuelva a ser bueno, se enviará otro evento RDS.
El modo síncrono favorece la precisión de la secuencia de actividades de la base de datos sobre el

rendimiento de la base de datos.
• Modo asíncrono: en el modo asíncrono, cuando una sesión de la base de datos genere un evento de
secuencia de actividades, la sesión volverá de inmediato a las actividades normales. En segundo plano,
el evento de secuencia de actividades se convertirá en un registro duradero. Si se produce un error
en la tarea en segundo plano, se enviará un evento RDS. Dicho evento marca el principio y el fin de
todo período de tiempo en el que podrían haberse perdido registros de eventos de la secuencia de
actividades.
El modo síncrono favorece el rendimiento de la base de datos sobre la precisión de la secuencia de

actividades de la base de datos.
Consola
Para iniciar una secuencia de actividades de la base de datos

3. Elija el clúster de base de datos que desee usar.

447
Inicio de una secuencia de actividades de la base de datos
4. En Actions (Acciones), elija Start activity stream (Iniciar secuencia de actividades). Se visualizará la
ventana Database Activity Stream (Secuencia de actividades de base de datos).
5. Especifique la siguiente configuración en la ventana Database Activity Stream (Secuencia de
actividades de base de datos).
• En Master key (Clave maestra), elija una clave en la lista de claves de AWS KMS.
La clave maestra se usará para cifrar la clave que, a su vez, cifrará la actividad de la base de
datos registrada. Tiene que elegir una clave maestra que no sea la clave predeterminada. Para
obtener más información acerca de las claves de cifrado y AWS KMS, consulte ¿Qué es AWS Key
Management Service? en la AWS Key Management Service Developer Guide.
• En Database activity stream mode (Modo de secuencia de actividades de base de datos), elija
Asynchronous (Asíncrono) o Synchronous (Síncrono).
• Seleccione Apply immediately (Aplicar inmediatamente).
Si elige Schedule for the next maintenance window (Programar para el siguiente período de
mantenimiento), la base de datos no se reiniciará de inmediato. En su lugar, se mantendrá en el
estado PENDING REBOOT. En este caso, la secuencia de actividades de la base de datos no
comenzará hasta el siguiente período de mantenimiento o hasta un reinicio manual.
Cuando haya acabado de introducir la configuración, elija Continue (Continuar).
El estado de la instancia de la base de datos del clúster muestra que se está configurando una
secuencia de actividades de la base de datos.
AWS CLI
Para iniciar secuencias de actividades de la base de datos de un clúster de base de datos, configure el
clúster de base de datos ejecutando el comando start-activity-stream de AWS CLI. Identifique la región de
AWS del clúster de base de datos con el parámetro --region. El parámetro --apply-immediately es
opcional.
aws rds --region us-west-2 \

start-activity-stream \
--mode sync \
--kms-key-id MY_KMS_KEY_ARN \
--resource-arn MY_CLUSTER_ARN \
--apply-immediately \
--profile MY_PROFILE_CREDENTIALS
Para Windows:
aws rds --region us-west-2 ^

start-activity-stream ^
--mode sync ^
--kms-key-id MY_KMS_KEY_ARN ^
--resource-arn MY_CLUSTER_ARN ^
--apply-immediately ^

448
Uso de secuencias de actividades de la base de datos
Obtención del estado de una secuencia de actividades

de base de datos
Puede obtener el estado de una secuencia de actividades de la base de datos mediante la consola o AWS
CLI.
Consola
Para obtener el estado de una secuencia de actividades de la base de datos de un clúster de base
de datos

2. En el panel de navegación, elija Databases (Bases de datos) y, a continuación, elija un clúster de base
de datos.
3. Elija la pestaña Configuration (Configuración) y consulte el estado en Database activity stream
(Secuencia de actividades de base de datos).
AWS CLI
Puede obtener la configuración de una secuencia de actividades de la base de datos de un clúster
de base de datos como la respuesta a una solicitud de la CLI describe-db-clusters. En el ejemplo
siguiente, consulte los valores de ActivityStreamKinesisStreamName, ActivityStreamStatus,
ActivityStreamKmsKeyId y ActivityStreamMode.
La solicitud es la siguiente:
aws rds --region us-west-2 describe-db-clusters --db-cluster-identifier my-cluster --

profile MY_PROFILE_CREDENTIALS
La respuesta incluye los elementos siguientes para una secuencia de actividades de la base de datos:
{
"DBClusters": [
{
"DBClusterIdentifier": "my-cluster",
. . .
"ActivityStreamKinesisStreamName": "aws-rds-das-cluster-A6TSYXITZCZXJHIRVFUBZ5LTWY",
"ActivityStreamStatus": "starting",
"ActivityStreamKmsKeyId": "12345678-abcd-efgh-ijkl-bd041f170262",
"ActivityStreamMode": "sync",
"DbClusterResourceId": "cluster-ABCD123456"
. . .
}
]
}
Detención de una secuencia de actividades de la base

de datos
Puede detener una secuencia de actividades de la base de datos mediante la consola o AWS CLI.

449
Monitorización de secuencias de
actividades de la base de datos
Consola
Para desactivar una secuencia de actividades de la base de datos

3. Elija el clúster de base de datos cuya secuencia de actividades de la base de datos desee detener.
4. En Actions (Acciones), elija Stop activity stream (Detener secuencia de actividades). Se visualizará la
ventana Database Activity Stream (Secuencia de actividades de base de datos).
a. Seleccione Apply immediately (Aplicar inmediatamente).
Si elige Schedule for the next maintenance window (Programar para el siguiente período de
mantenimiento), la base de datos no se reiniciará de inmediato. En su lugar, se mantendrá en el
estado PENDING REBOOT. En este caso, la secuencia de actividades de la base de datos no se
deshabilitará hasta el siguiente período de mantenimiento o hasta un reinicio manual.
b. Elija Continue (Continuar).
AWS CLI
Para detener secuencias de actividades de base de datos de un clúster de base de datos, configure el
clúster de base de datos ejecutando el comando de AWS CLI stop-activity-stream. Identifique la región de
AWS del clúster de base de datos con el parámetro --region. El parámetro --apply-immediately es
opcional.
aws rds --region us-west-2 \

stop-activity-stream \
--resource-arn MY_CLUSTER_ARN \
--apply-immediately \
Para Windows:
aws rds --region us-west-2 ^

stop-activity-stream ^
--resource-arn MY_CLUSTER_ARN ^
--apply-immediately ^
Monitorización de secuencias de actividades de la

base de datos
Una secuencia de actividades de la base de datos monitoriza y notifica todas las actividades que se
producen en la base de datos. La secuencia de datos se recopila y transmite a un servidor seguro
mediante Amazon Kinesis. en Kinesis, la secuencia de datos se puede monitorizar o más tarde la pueden
utilizar otros servicios y aplicaciones para profundizar en el análisis.
Las categorías de actividad siguientes se monitorizan y se ponen en el registro de auditoría de la cadena

de actividades de la base de datos:
• Comandos SQL: todos los comandos de SQL se auditan, así como las instrucciones preparadas, las
funciones de PostgreSQL y las funciones en lenguaje de procedimientos para SQL (PL/SQL).

450
• Otra información de la base de datos: la actividad monitorizada incluye la instrucción SQL completa,
los parámetros, las variables de vínculo, el recuento de las filas afectadas de los comandos DML, los
objetos a los que se accede y el nombre único de la base de datos.
• Información de conexión: la actividad monitorizada incluye la información de sesión y de red, el ID de
proceso del servidor y los códigos de salida.
Si una secuencia de actividades de la base de datos sufre un error mientras monitoriza una instancia de
base de datos, se le notificará mediante eventos RDS. Si se produce un error, puede optar entre cerrar la
instancia de la base de datos o dejarla continuar.
Temas
• Acceso a una secuencia de actividades de la base de datos desde Kinesis (p. 451)
• Auditoría de contenido de registros y ejemplos (p. 451)
• Procesamiento de una secuencia de actividades de base de datos mediante el AWS SDK (p. 457)
Acceso a una secuencia de actividades de la base de datos

desde Kinesis
Cuando habilite una secuencia de actividades de la base de datos para un clúster de base de datos, se
creará una secuencia de Kinesis para usted. En Kinesis podrá monitorizar la actividad de la base de datos
en tiempo real. Para profundizar en el análisis de la actividad de la base de datos, puede conectar su
secuencia de Kinesis a aplicaciones de consumidor como Amazon CloudWatch. También puede conectar
la secuencia a aplicaciones de administración del cumplimiento de Imperva, McAfee o IBM.
Para obtener acceso a una secuencia de actividades de la base de datos desde Kinesis
1. Abra la consola de Kinesis en https://console.aws.amazon.com/kinesis.

2. Elija la secuencia de actividades de la base de datos en la lista de secuencias de Kinesis.
El nombre de una secuencia de actividades de la base de datos consta de un prefijo aws-rds-das-

seguido del ID de recurso del clúster de base de datos. A continuación se muestra un ejemplo.
aws-rds-das-cluster-NHVOV4PCLWHGF52NP
Para utilizar la consola de Amazon RDS para encontrar el ID de recurso del clúster de base de
datos, elija su clúster de base de datos en la lista de bases de datos y luego seleccione la pestaña
Configuration (Configuración).
Para utilizar la AWS CLI para encontrar el nombre completo de la secuencia de Kinesis de una
secuencia de actividades de la base de datos, use una solicitud de CLI describe-db-clusters y anote el
valor de DBActivityStreamKinesisStreamName en la respuesta.
3. Elija Monitoring (Monitorización) para empezar a observar la actividad de la base de datos.
Para obtener más información acerca del uso de Amazon Kinesis, consulte ¿Qué es Amazon Kinesis Data
Streams?.
Auditoría de contenido de registros y ejemplos

Los eventos de actividad de la base de datos que se monitorizan se representan en la secuencia
de actividades de Kinesis como cadenas JSON. La estructura está formada por un objeto JSON
que contiene un DatabaseActivityMonitoringRecord, el cual, a su vez, contiene una matriz
databaseActivityEventList de eventos de actividad.

451
Temas
• Ejemplos de registro de auditoría (p. 452)
• Registro de evento de actividad (p. 454)
• Matriz de JSON databaseActivityEventList (p. 454)
Ejemplos de registro de auditoría

A continuación mostramos registros de auditoría JSON descifrados de muestra de registros de eventos de
actividad.
Example Registro de evento de actividad de una instrucción SQL CONNECT
A continuación se muestra un registro de evento de actividad de un inicio de sesión que usa una
instrucción SQL CONNECT (command) de un cliente psql (clientApplication).
{
"type":"DatabaseActivityMonitoringRecord",
"clusterId":"cluster-4HNY5V4RRNPKKYB7ICFKE5JBQQ",
"instanceId":"db-FZJTMYKCXQBUUZ6VLU7NW3ITCM",
"databaseActivityEventList":[
{
"logTime": "2019-05-23 01:31:28.610198+00",
"statementId": 1,
"substatementId": 1,
"objectType": null,
"command": "CONNECT",
"objectName": null,
"databaseName": "postgres",
"dbUserName": "rdsadmin",
"remoteHost": "172.31.3.195",
"remotePort": "49804",
"sessionId": "5ce5f7f0.474b",
"rowCount": null,
"commandText": null,
"paramList": [],
"pid": 18251,
"clientApplication": "psql",
"exitCode": null,
"class": "MISC",
"serverVersion": "2.3.1",
"serverType": "PostgreSQL",
"serviceName": "Amazon Aurora PostgreSQL-Compatible edition",
"serverHost": "172.31.3.192",
"netProtocol": "TCP",
"dbProtocol": "Postgres 3.0",
"type": "record"
}
]
}
Example Registro de evento de actividad de una instrucción CREATE TABLE
A continuación, se muestra un ejemplo de un evento CREATE TABLE.
{

452
{
"logTime": "2019-05-24 00:36:54.494235+00",
"statementId": 2,
"objectType": null,
"command": "CREATE TABLE",
"objectName": null,
"remoteHost": "172.31.3.195",
"sessionId": "5ce73c6f.7e64",
"rowCount": null,
"commandText": "create table my_table (id serial primary key, name varchar(32));",
"paramList": [],
"pid": 32356,
"exitCode": null,
"class": "DDL",
"serverHost": "172.31.3.192",
"type": "record"
}
]
}
Example Registro de evento de actividad de una instrucción SELECT
A continuación, se muestra un ejemplo de un evento SELECT.
{
{
"logTime": "2019-05-24 00:39:49.940668+00",
"statementId": 6,
"objectType": "TABLE",
"command": "SELECT",
"objectName": "public.my_table",
"remoteHost": "172.31.3.195",
"sessionId": "5ce73c6f.7e64",
"rowCount": 10,
"commandText": "select * from my_table;",
"paramList": [],
"pid": 32356,
"exitCode": null,
"class": "READ",
"serverHost": "172.31.3.192",

453
"type": "record"
}
]
}
Registro de evento de actividad

Un registro de evento de actividad de registro de auditoría es un objeto JSON que contiene la información
siguiente.
Campo JSON Tipo de Descripción

datos
type cadena Tipo de registro JSON. El valor es

DatabaseActivityMonitoringRecord.
clusterId cadena ID de clúster de base de datos.
instanceId cadena ID de instancia de base de datos.
cadena
databaseActivityEventList Objeto JSON cifrado como matriz de bytes base64. Siga los pasos
que indicamos a continuación para descifrar este contenido:
1. Descifre el valor del campo JSON clave usando la clave

maestra de la secuencia de actividades de base de datos.
2. Descifre el objeto databaseActivityEventList usando la
clave descifrada del paso 1.
Matriz de JSON databaseActivityEventList

La carga de registro de auditoría es una matriz JSON databaseActivityEventList cifrada. En
la tabla siguiente se enumeran alfabéticamente los campos de cada evento de actividad de la matriz
DatabaseActivityEventList descifrada de un registro de auditoría.
Campo Tipo de datos Descripción
class cadena Clase de evento de actividad. Los valores válidos son los
siguientes:
• ALL
• CONNECT: evento de conexión o desconexión.
• DDL: instrucción DDL que no está incluida en la lista de
instrucciones de la clase ROLE.
• FUNCTION: llamada de función o bloque DO.
• MISC: comando variado como, por ejemplo, DISCARD, FETCH,
CHECKPOINT o VACUUM.
• NONE
• READ: instrucción SELECT o COPY donde el origen es una
relación o una consulta.
• ROLE: instrucción relacionada con roles y privilegios como
GRANT, REVOKE y CREATE/ALTER/DROP ROLE.
• WRITE: instrucción INSERT, UPDATE, DELETE, TRUNCATE o
COPY cuando el destino es una relación.

454
clientApplicationcadena Aplicación que el cliente ha usado para establecer conexión

según notificación del cliente. No es obligatorio que el cliente
notifique esta información, por lo que el valor puede ser nulo.
command cadena Nombre del comando SQL sin ningún detalle del comando.
commandText cadena Instrucción SQL real que el usuario ha pasado. Este campo se
usa para todo tipo de registros, salvo para registros de conexión o
desconexión, en cuyo caso el valor es nulo.
Información confidencial
Se ve el texto SQL completo, incluida toda la información

confidencial. Sin embargo, las contraseñas de usuario de la
base de datos se redactan si se pueden determinar a partir del
contexto, tal y como pasa con la siguiente instrucción SQL.
ALTER ROLE role-name WITH password
databaseName cadena Base de datos a la que se ha conectado el usuario.
dbProtocol cadena Protocolo de la base de datos.
dbUserName cadena Usuario de base de datos que el cliente ha usado para

autenticarse.
exitCode int Valor usado para un registro de salida de sesión. Si la salida es

limpia, contiene el código de salida. No siempre se puede obtener
un código de salida en algunos escenarios de error. Por ejemplo,
este es el caso cuando PostgreSQL genera un exit() o si un
operador ejecuta un comando kill -9.
logTime cadena Marca temporal según se ha registrado en la ruta del código de

auditoría.
netProtocol cadena Protocolo de comunicación de red
objectName cadena Nombre del objeto de base de datos si la instrucción SQL opera
en uno. Este campo solo se usa cuando la instrucción SQL
funciona en un objeto de base de datos. Si la instrucción SQL no
opera en un objeto, este valor es nulo.

455
objectType cadena Tipo de objeto de base de datos como mesa, índice, vista, etc.
Este campo solo se usa cuando la instrucción SQL funciona en
un objeto de base de datos. Si la instrucción SQL no opera en un
objeto, este valor es nulo. Entre los valores válidos se incluyen los
siguientes:
• COMPOSITE TYPE
• FOREIGN TABLE
• FUNCTION
• INDEX
• MATERIALIZED VIEW
• SEQUENCE
• TABLE
• TOAST TABLE
• VIEW
• UNKNOWN
paramList cadena Matriz de parámetros separados por comas que se transfiere a la

instrucción SQL. Si la instrucción SQL no tiene parámetros, este
valor es una matriz vacía.
pid int ID del proceso de backend que se asigna para atender la

conexión cliente.
remoteHost cadena Dirección IP cliente o nombre de host, según la configuración del

parámetro log_hostname de la base de datos.
remotePort cadena Número de puerto del cliente.
rowCount int Número de filas de tabla que la instrucción SQL recupera o a las
que afecta. Este campo se usa únicamente para instrucciones
SQL que son instrucciones de lenguaje de manipulación de datos
(DML). Si la instrucción SQL no es una instrucción DML, este
valor es nulo.
serverHost cadena Dirección IP del host de servidor de la base de datos.
serverType cadena Tipo de servidor de base de datos; por ejemplo, PostgreSQL,
serverVersion cadena Versión del servidor de base de datos.
serviceName cadena Nombre del servicio, por ejemplo Amazon Aurora

PostgreSQL-Compatible edition.
sessionId int Identificador de sesión pseudoúnico.
statementId int ID para la instrucción SQL del cliente. El contador está en el nivel
de sesión y aumenta con cada instrucción SQL que el cliente
introduce.
substatementId int ID de una subinstrucción de SQL. Este valor cuenta las

subinstrucciones contenidas por cada instrucción SQL que el
campo statementId identifica.
type cadena Tipo de evento. Los valores válidos son record o heartbeat.

456
Procesamiento de una secuencia de actividades de base de

datos mediante el AWS SDK
Puede procesar mediante programación una secuencia de actividades de base de datos mediante AWS
SDK. A continuación mostramos ejemplos de Java y Python con plena funcionalidad de cómo puede
procesar la secuencia de datos de Kinesis.
Java
import java.io.ByteArrayInputStream;
import java.io.ByteArrayOutputStream;
import java.io.IOException;
import java.net.InetAddress;
import java.nio.ByteBuffer;
import java.nio.charset.StandardCharsets;
import java.security.NoSuchAlgorithmException;
import java.security.NoSuchProviderException;
import java.security.Security;
import java.util.HashMap;
import java.util.Map;
import java.util.UUID;
import java.util.zip.GZIPInputStream;
import javax.crypto.Cipher;
import javax.crypto.NoSuchPaddingException;
import javax.crypto.spec.SecretKeySpec;
import com.amazonaws.auth.AWSStaticCredentialsProvider;
import com.amazonaws.auth.BasicAWSCredentials;
import com.amazonaws.encryptionsdk.AwsCrypto;
import com.amazonaws.encryptionsdk.CryptoInputStream;
import com.amazonaws.encryptionsdk.jce.JceMasterKey;
import com.amazonaws.services.kinesis.clientlibrary.exceptions.InvalidStateException;
import com.amazonaws.services.kinesis.clientlibrary.exceptions.ShutdownException;
import com.amazonaws.services.kinesis.clientlibrary.exceptions.ThrottlingException;
import com.amazonaws.services.kinesis.clientlibrary.interfaces.IRecordProcessor;
import
com.amazonaws.services.kinesis.clientlibrary.interfaces.IRecordProcessorCheckpointer;
import com.amazonaws.services.kinesis.clientlibrary.interfaces.IRecordProcessorFactory;
import com.amazonaws.services.kinesis.clientlibrary.lib.worker.InitialPositionInStream;
import
com.amazonaws.services.kinesis.clientlibrary.lib.worker.KinesisClientLibConfiguration;
import com.amazonaws.services.kinesis.clientlibrary.lib.worker.ShutdownReason;
import com.amazonaws.services.kinesis.clientlibrary.lib.worker.Worker;
import com.amazonaws.services.kinesis.clientlibrary.lib.worker.Worker.Builder;
import com.amazonaws.services.kinesis.model.Record;
import com.amazonaws.services.kms.AWSKMS;
import com.amazonaws.services.kms.AWSKMSClientBuilder;
import com.amazonaws.services.kms.model.DecryptRequest;
import com.amazonaws.services.kms.model.DecryptResult;
import com.amazonaws.util.Base64;
import com.amazonaws.util.IOUtils;
import com.google.gson.Gson;
import com.google.gson.GsonBuilder;
import com.google.gson.annotations.SerializedName;
import org.bouncycastle.jce.provider.BouncyCastleProvider;
public class DemoConsumer {
private static final String STREAM_NAME = "aws-rds-das-[cluster-external-resource-

id]";

457
private static final String APPLICATION_NAME = "AnyApplication"; //unique

application name for dynamo table generation that holds kinesis shard tracking
private static final String AWS_ACCESS_KEY = "[AWS_ACCESS_KEY_TO_ACCESS_KINESIS]";
private static final String AWS_SECRET_KEY = "[AWS_SECRET_KEY_TO_ACCESS_KINESIS]";
private static final String DBC_RESOURCE_ID = "[cluster-external-resource-id]";
private static final String REGION_NAME = "[region-name]"; //us-east-1, us-
east-2...
private static final BasicAWSCredentials CREDENTIALS = new
BasicAWSCredentials(AWS_ACCESS_KEY, AWS_SECRET_KEY);
private static final AWSStaticCredentialsProvider CREDENTIALS_PROVIDER = new
AWSStaticCredentialsProvider(CREDENTIALS);
private static final AwsCrypto CRYPTO = new AwsCrypto();

private static final AWSKMS KMS = AWSKMSClientBuilder.standard()
.withRegion(REGION_NAME)
.withCredentials(CREDENTIALS_PROVIDER).build();
class Activity {
String type;
String version;
String databaseActivityEvents;
String key;
}
class ActivityEvent {
@SerializedName("class") String _class;
String clientApplication;
String command;
String commandText;
String databaseName;
String dbProtocol;
String dbUserName;
String exitCode;
String logTime;
String netProtocol;
String objectName;
String objectType;
List<String> paramList;
String pid;
String remoteHost;
String remotePort;
String rowCount;
String serverHost;
String serverType;
String serverVersion;
String serviceName;
String sessionId;
String statementId;
String substatementId;
String type;
}
class ActivityRecords {
String type;
String clusterId;
String instanceId;
List<ActivityEvent> databaseActivityEventList;
}
static class RecordProcessorFactory implements IRecordProcessorFactory {

@Override
public IRecordProcessor createProcessor() {
return new RecordProcessor();
}
}

458
static class RecordProcessor implements IRecordProcessor {
private static final long BACKOFF_TIME_IN_MILLIS = 3000L;

private static final int PROCESSING_RETRIES_MAX = 10;
private static final long CHECKPOINT_INTERVAL_MILLIS = 60000L;
private static final Gson GSON = new GsonBuilder().serializeNulls().create();
private static final Cipher CIPHER;

static {
Security.insertProviderAt(new BouncyCastleProvider(), 1);
try {
CIPHER = Cipher.getInstance("AES/GCM/NoPadding", "BC");
} catch (NoSuchAlgorithmException | NoSuchPaddingException |
NoSuchProviderException e) {
throw new ExceptionInInitializerError(e);
}
}
private long nextCheckpointTimeInMillis;
@Override
public void initialize(String shardId) {
}
@Override
public void processRecords(final List<Record> records, final
IRecordProcessorCheckpointer checkpointer) {
for (final Record record : records) {
processSingleBlob(record.getData());
}
if (System.currentTimeMillis() > nextCheckpointTimeInMillis) {

checkpoint(checkpointer);
nextCheckpointTimeInMillis = System.currentTimeMillis() +
CHECKPOINT_INTERVAL_MILLIS;
}
}
@Override
public void shutdown(IRecordProcessorCheckpointer checkpointer, ShutdownReason
reason) {
if (reason == ShutdownReason.TERMINATE) {
checkpoint(checkpointer);
}
}
private void processSingleBlob(final ByteBuffer bytes) {

try {
// JSON $Activity
final Activity activity = GSON.fromJson(new String(bytes.array(),
StandardCharsets.UTF_8), Activity.class);
// Base64.Decode
final byte[] decoded = Base64.decode(activity.databaseActivityEvents);
final byte[] decodedDataKey = Base64.decode(activity.key);
Map<String, String> context = new HashMap<>();

context.put("aws:rds:dbc-id", DBC_RESOURCE_ID);
// Decrypt
final DecryptRequest decryptRequest = new DecryptRequest()
.withCiphertextBlob(ByteBuffer.wrap(decodedDataKey)).withEncryptionContext(context);
final DecryptResult decryptResult = KMS.decrypt(decryptRequest);
final byte[] decrypted = decrypt(decoded,
getByteArray(decryptResult.getPlaintext()));

459
// GZip Decompress
final byte[] decompressed = decompress(decrypted);
// JSON $ActivityRecords
final ActivityRecords activityRecords = GSON.fromJson(new
String(decompressed, StandardCharsets.UTF_8), ActivityRecords.class);
// Iterate throught $ActivityEvents

for (final ActivityEvent event :
activityRecords.databaseActivityEventList) {
System.out.println(GSON.toJson(event));
}
// Handle error.
e.printStackTrace();
}
}
private static byte[] decompress(final byte[] src) throws IOException {

ByteArrayInputStream byteArrayInputStream = new ByteArrayInputStream(src);
GZIPInputStream gzipInputStream = new
GZIPInputStream(byteArrayInputStream);
return IOUtils.toByteArray(gzipInputStream);
}
private void checkpoint(IRecordProcessorCheckpointer checkpointer) {

for (int i = 0; i < PROCESSING_RETRIES_MAX; i++) {
try {
checkpointer.checkpoint();
break;
} catch (ShutdownException se) {
// Ignore checkpoint if the processor instance has been shutdown
(fail over).
System.out.println("Caught shutdown exception, skipping
checkpoint." + se);
break;
} catch (ThrottlingException e) {
// Backoff and re-attempt checkpoint upon transient failures
if (i >= (PROCESSING_RETRIES_MAX - 1)) {
System.out.println("Checkpoint failed after " + (i + 1) +
"attempts." + e);
break;
} else {
System.out.println("Transient issue when checkpointing -
attempt " + (i + 1) + " of " + PROCESSING_RETRIES_MAX + e);
}
} catch (InvalidStateException e) {
// This indicates an issue with the DynamoDB table (check for
table, provisioned IOPS).
System.out.println("Cannot save checkpoint to the DynamoDB table
used by the Amazon Kinesis Client Library." + e);
break;
}
try {
Thread.sleep(BACKOFF_TIME_IN_MILLIS);
} catch (InterruptedException e) {
System.out.println("Interrupted sleep" + e);
}
}
}
}
private static byte[] decrypt(final byte[] decoded, final byte[] decodedDataKey)

throws IOException {
// Create a JCE master key provider using the random key and an AES-GCM
encryption algorithm

460
final JceMasterKey masterKey = JceMasterKey.getInstance(new

SecretKeySpec(decodedDataKey, "AES"),
"BC", "DataKey", "AES/GCM/NoPadding");
try (final CryptoInputStream<JceMasterKey> decryptingStream =
CRYPTO.createDecryptingStream(masterKey, new ByteArrayInputStream(decoded));
final ByteArrayOutputStream out = new ByteArrayOutputStream()) {
IOUtils.copy(decryptingStream, out);
return out.toByteArray();
}
}

final String workerId = InetAddress.getLocalHost().getCanonicalHostName() + ":"
+ UUID.randomUUID();
final KinesisClientLibConfiguration kinesisClientLibConfiguration =
new KinesisClientLibConfiguration(APPLICATION_NAME, STREAM_NAME,
CREDENTIALS_PROVIDER, workerId);
kinesisClientLibConfiguration.withInitialPositionInStream(InitialPositionInStream.LATEST);
kinesisClientLibConfiguration.withRegionName(REGION_NAME);
final Worker worker = new Builder()
.recordProcessorFactory(new RecordProcessorFactory())
.config(kinesisClientLibConfiguration)
.build();
System.out.printf("Running %s to process stream %s as worker %s...\n",

APPLICATION_NAME, STREAM_NAME, workerId);
try {
worker.run();
} catch (Throwable t) {
System.err.println("Caught throwable while processing data.");
t.printStackTrace();
System.exit(1);
}
System.exit(0);
}
private static byte[] getByteArray(final ByteBuffer b) {

byte[] byteArray = new byte[b.remaining()];
b.get(byteArray);
return byteArray;
}
}
Python
import zlib
import boto3
import base64
import json
import aws_encryption_sdk
from Crypto.Cipher import AES
from aws_encryption_sdk import DefaultCryptoMaterialsManager
from aws_encryption_sdk.internal.crypto import WrappingKey
from aws_encryption_sdk.key_providers.raw import RawMasterKeyProvider
from aws_encryption_sdk.identifiers import WrappingAlgorithm, EncryptionKeyType
aws_access_key_id="YOUR_ACCESS_KEY"
aws_secret_access_key="YOUR_SECRET_KEY"
key_id = "your_key_id"
stream_name = "YOUR_KINESIS_STREAM_NAME"
region_name = 'YOUR_REGION_NAME'

461
cluster_id = "YOUR_CLUSTER_ID"
class MyRawMasterKeyProvider(RawMasterKeyProvider):
provider_id = "BC"
def __new__(cls, *args, **kwargs):

obj = super(RawMasterKeyProvider, cls).__new__(cls)
return obj
def __init__(self, wrapping_key):

RawMasterKeyProvider.__init__(self)
self.wrapping_key = wrapping_key
def _get_raw_key(self, key_id):

return self.wrapping_key
def decrypt(decoded, plaintext):

wrapping_key =
WrappingKey(wrapping_algorithm=WrappingAlgorithm.AES_256_GCM_IV12_TAG16_NO_PADDING,
wrapping_key=plaintext,
wrapping_key_type=EncryptionKeyType.SYMMETRIC)
my_key_provider = MyRawMasterKeyProvider(wrapping_key)
my_key_provider.add_master_key("DataKey")
with aws_encryption_sdk.stream(
mode='d',
source=decoded,
materials_manager=DefaultCryptoMaterialsManager(master_key_provider=my_key_provider)
) as decryptor:
for chunk in decryptor:
d = zlib.decompressobj(16 + zlib.MAX_WBITS)
decompressed_database_stream = d.decompress(chunk)
print decompressed_database_stream
if __name__ == '__main__':
session = boto3.session.Session(
aws_access_key_id=aws_access_key_id,
aws_secret_access_key=aws_secret_access_key
)
kms = session.client('kms', region_name=region_name)
client = session.client('kinesis', region_name=region_name)
response = client.describe_stream(StreamName=stream_name)
shard_it = {}
for idx, shard in enumerate(response['StreamDescription']['Shards']):
shared_iterator = client.get_shard_iterator(
StreamName=stream_name,
ShardId=response['StreamDescription']['Shards'][idx]['ShardId'],
ShardIteratorType='LATEST',
)["ShardIterator"]
shard_it[idx] = shared_iterator
while True:
rows = []
for shared_iterator in shard_it:
response = client.get_records(ShardIterator=shard_it[shared_iterator],
Limit=10000)
for record in response['Records']:
record_data = record['Data']
record_data = json.loads(record_data)
key = record_data['key']
decoded = base64.b64decode(record_data['DatabaseActivityEvents'])

462
Administración del acceso a secuencias
de actividades de base de datos
decoded_data_key = base64.b64decode(record_data['key'])
decrypt_result = kms.decrypt(CiphertextBlob=decoded_data_key,
EncryptionContext={"aws:rds:dbc-id":
cluster_id})
plaintext = decrypt_result[u'Plaintext']
cipher = AES.new(plaintext, AES.MODE_GCM)
decrypt(decoded, decrypt_result[u'Plaintext'])
shard_it[shared_iterator] = response["NextShardIterator"]
Administración del acceso a secuencias de

actividades de base de datos
Cualquier usuario que tenga privilegios de rol de AWS Identity and Access Management (IAM) apropiados
para las secuencias de actividades de base de datos puede crear, comenzar, detener y modificar la
configuración de la secuencia de actividades de base de datos de un clúster de base de datos. Estas
acciones se incluyen en el registro de auditoría de la secuencia. Como práctica recomendada de
cumplimiento, le recomendamos que no proporcione estos privilegios a los DBA.
Establezca el acceso a las secuencias de actividades de base de datos mediante políticas IAM. Para
obtener más información acerca de la autenticación de Aurora, consulte Administración de identidad y
acceso en Amazon Aurora (p. 163). Para obtener más información sobre la creación de políticas de IAM,
consulte Creación y uso de una política de IAM para el acceso a bases de datos de IAM (p. 183).
Example Política para permitir configurar secuencias de actividades de la base de datos
Para dar a los usuarios un acceso preciso para modificar secuencias de actividades de la base de datos,
use la clave de contexto de operación específica del servicio rds:ConfigureDBActivityStreams
de una política de IAM. En el siguiente ejemplo de política de IAM, el usuario o rol puede configurar
secuencias de actividades de la base de datos.
{
"Version":"2012-10-17",
"Statement":[
{
"Sid":"ConfigureActivityStreams",
"Effect":"Allow",
"Action": [
"rds:StartActivityStream",
"rds:StopActivityStream"
],
"Resource":"*",
}
]
}
Example Política para permitir iniciar secuencias de actividades de la base de datos
En el siguiente ejemplo de política de IAM, el usuario o rol puede iniciar secuencias de actividades de la
base de datos.
{
"Version":"2012-10-17",
"Statement":[
{
"Sid":"AllowStartActivityStreams",

463
Administración del acceso a secuencias
de actividades de base de datos
"Effect":"Allow",
"Action":"rds:StartActivityStream",
"Resource":"*"
}
]
}
Example Política para permitir detener secuencias de actividades de la base de datos
En el siguiente ejemplo de política de IAM, el usuario o rol puede detener secuencias de actividades de la
base de datos.
{
"Version":"2012-10-17",
"Statement":[
{
"Sid":"AllowStopActivityStreams",
"Effect":"Allow",
"Action":"rds:StopActivityStream",
"Resource":"*"
}
]
}
Example Política para rechazar iniciar secuencias de actividades de la base de datos
En el siguiente ejemplo de política de IAM, se rechaza que el usuario o rol inicie secuencias de actividades
de la base de datos.
{
"Version":"2012-10-17",
"Statement":[
{
"Sid":"DenyStartActivityStreams",
"Effect":"Deny",
"Action":"rds:StartActivityStream",
"Resource":"*"
}
]
}
Example Política para rechazar la detención de secuencias de actividades de la base de datos
En el siguiente ejemplo de política de IAM, se rechaza que el usuario o rol detenga secuencias de
actividades de la base de datos.
{
"Version":"2012-10-17",
"Statement":[
{
"Sid":"DenyStopActivityStreams",
"Effect":"Deny",
"Action":"rds:StopActivityStream",
"Resource":"*"
}
]
}

464
Uso de las notificaciones de eventos de Amazon RDS
Uso de las notificaciones de eventos de Amazon

RDS
Temas
• Categorías y mensajes de eventos de Amazon RDS (p. 466)
• Suscripción a notificaciones de eventos de Amazon RDS (p. 473)
• Mostrar las suscripciones de notificación de eventos de Amazon RDS (p. 475)
• Modificación de una suscripción a notificaciones de eventos de Amazon RDS (p. 476)
• Añadir un identificador de origen a una suscripción de notificación de eventos de Amazon
RDS (p. 477)
• Quitar un identificador de origen de una suscripción de notificación de eventos de Amazon
RDS (p. 478)
• Obtención de la lista de categorías de notificaciones de eventos de Amazon RDS (p. 479)
• Eliminar una suscripción de notificación de eventos de Amazon RDS (p. 480)
Amazon RDS utiliza Amazon Simple Notification Service (Amazon SNS) para proporcionar una notificación
cuando se produce un evento de Amazon RDS. Estas notificaciones pueden realizarse con cualquier
método que admita Amazon SNS para una región de AWS como, por ejemplo, un mensaje de correo
electrónico, un mensaje de texto o una llamada a un punto de enlace HTTP.
Amazon RDS agrupa estos eventos en categorías a las que puede suscribirse para recibir una notificación
cada vez que se produzca un evento en esa categoría. Puede suscribirse a una categoría de eventos para
una instancia de base de datos, un clúster de base de datos, una instantánea de clúster de base de datos,
un grupo de parámetros de base de datos o un grupo de seguridad de base de datos. Por ejemplo, si se
suscribe a la categoría Backup de una instancia de base de datos determinada, recibe una notificación
cada vez que se produzca un evento relacionado con las copias de seguridad que afecte a la instancia
de base de datos. Si se suscribe a la categoría Configuration Change de un grupo de seguridad de base
de datos, recibe una notificación cada vez que se modifique un grupo de seguridad de base de datos.
También recibirá una notificación cuando cambie una suscripción de notificación de eventos.
Para Amazon Aurora, los eventos se producen en el clúster y no en la instancia, por lo que no recibirá
eventos si se suscribe a una instancia de base de datos de Aurora. Debe suscribirse al clúster de base de
datos.
Las notificaciones de eventos se envían a las direcciones que se proporcionan al crear la suscripción.
Es posible que le interese crear distintas suscripciones como, por ejemplo, una que reciba todas las
notificaciones de eventos y otra que incluya únicamente los eventos críticos para las instancias de
bases de datos de producción. Puede desactivar la notificación fácilmente sin eliminar una suscripción
seleccionando No en Enabled (Habilitado) en la consola de Amazon RDS o estableciendo el parámetro
Enabled en false con la AWS CLI o la API de Amazon RDS.
Note
Las notificaciones de eventos de Amazon RDS que utilizan mensajes de texto SMS están
disponibles actualmente para los Nombres de recursos de Amazon (ARN) de temas y para los
recursos de Amazon RDS en la Región EE. UU. Este (Norte de Virginia). Para obtener más
información acerca de cómo utilizar mensajes de texto con SNS, consulte Sending and Receiving
SMS Notifications Using Amazon SNS (Envío y recepción de notificaciones SMS mediante SNS)
en la Guía del desarrollador de Amazon Simple Notification Service.
Amazon RDS utiliza el ARN de un tema de Amazon SNS para identificar cada suscripción. La consola de
Amazon RDS crea el ARN automáticamente cuando se crea la suscripción. Si utiliza la CLI o la API, debe
crear el ARN con la consola de Amazon SNS o la API de Amazon SNS cuando cree una suscripción.

465
Categorías y mensajes de eventos de Amazon RDS
La facturación de las notificaciones de eventos de Amazon RDS se efectúa a través de Amazon Simple
Notification Service (Amazon SNS). Cuando se utiliza la notificación de eventos, se aplican las tarifas de
Amazon SNS. Para obtener más información sobre la facturación de Amazon SNS, consulte los precios de
Amazon Simple Notification Service.
El proceso para suscribirse a las notificaciones de eventos de Amazon RDS es el siguiente:
1. Cree una suscripción de notificación de eventos de Amazon RDS mediante la consola, la Amazon RDS
o la API de AWS CLI.
2. Amazon RDS envía un mensaje de correo electrónico o SMS de aprobación a las direcciones que envió
con la suscripción. Para confirmar la suscripción, elija el enlace de la notificación que reciba.
3. Cuando confirme la suscripción, el estado de la suscripción se actualizará en la sección My Event
Subscriptions (Mis suscripciones a eventos) de la consola de Amazon RDS.
4. Seguidamente, empezará a recibir notificaciones de eventos.
Note
Cuando Amazon SNS envía una notificación a un punto de enlace HTTP o HTTPS suscrito,
el cuerpo del mensaje POST enviado al punto de enlace contiene un documento JSON. Para
obtener más información, consulte Amazon SNS Message and JSON Formats (Formatos de
mensaje y JSON de SNS) en la Guía del desarrollador de Amazon Simple Notification Service.
En la siguiente sección, se enumeran todas las categorías y eventos de los que puede recibir
notificaciones. Además, se proporciona información acerca de cómo suscribirse y trabajar con las
suscripciones a eventos de Amazon RDS.

Amazon RDS genera un número significativo de eventos en categorías a las que puede suscribirse a
través de la Consola de Amazon RDS o la API de AWS CLI. Cada categoría se aplica a un tipo de origen,
que puede ser una instancia de base de datos, una instantánea de base de datos, un grupo de seguridad
de base de datos o un grupo de parámetros de base de datos.
En la siguiente tabla se muestran las categorías de eventos y una lista de los eventos que pueden
producirse cuando el tipo de origen es una instancia de base de datos.
Categoría ID de evento de Amazon Descripción

RDS
availability RDS-EVENT-0006 Instancia de base de datos reiniciada.
availability RDS-EVENT-0004 Instancia de base de datos cerrada.
availability RDS-EVENT-0022 Se ha producido un error al reiniciar MySQL o

MariaDB.
backtrack RDS-EVENT-0131 El periodo de búsqueda de datos anteriores real es

inferior al periodo de búsqueda de datos anteriores de
destino que especificó. Considere reducir el número
de horas del periodo de búsqueda de datos anteriores
de destino. Para obtener más información sobre la
búsqueda de datos anteriores, consulte Búsqueda de
datos anteriores de un clúster de base de datos de
Aurora (p. 546).

466

RDS
backtrack RDS-EVENT-0132 El periodo de búsqueda de datos anteriores real es

el mismo que el periodo de búsqueda de datos de
destino.
backup RDS-EVENT-0001 Se está realizando una copia de seguridad de la

backup RDS-EVENT-0002 Copia de seguridad de instancia de base de datos

finalizada.
configuration RDS-EVENT-0009 La instancia de base de datos se ha añadido a un

change grupo de seguridad.
configuration RDS-EVENT-0024 La instancia de base de datos se está convirtiendo en

change una instancia de base de datos Multi-AZ.
configuration RDS-EVENT-0030 La instancia de base de datos se está convirtiendo en

change una instancia de base de datos Single-AZ.
configuration RDS-EVENT-0012 Se está aplicando la modificación a la clase de

change instancia de base de datos.
configuration RDS-EVENT-0018 Se está modificando la configuración de

change almacenamiento actual de esta instancia de base de
datos.
configuration RDS-EVENT-0011 Se ha modificado un grupo de parámetros de esta

configuration RDS-EVENT-0092 Ha finalizado la actualización de un grupo de

change parámetros de esta instancia de base de datos.
configuration RDS-EVENT-0028 Se han desactivado las copias de seguridad

change automáticas en esta instancia de base de datos.
configuration RDS-EVENT-0032 Se han activado las copias de seguridad automáticas

change en esta instancia de base de datos.
configuration RDS-EVENT-0033 Hay [número] usuarios que coinciden con el nombre de

change usuario maestro. Los usuarios que no están vinculados
a un host específico se han restablecido.
configuration RDS-EVENT-0025 La instancia de base de datos se ha convertido en una

change instancia de base de datos Multi-AZ.
configuration RDS-EVENT-0029 La instancia de base de datos se ha convertido en una

change instancia de base de datos Single-AZ.
configuration RDS-EVENT-0014 Se ha modificado la clase de instancia de base de

change datos de esta instancia de base de datos.
configuration RDS-EVENT-0017 Se ha modificado la configuración de almacenamiento

change actual de esta instancia de base de datos.
configuration RDS-EVENT-0010 La instancia de base de datos se ha eliminado de un

change grupo de seguridad.

467

RDS
configuration RDS-EVENT-0016 Se ha restablecido la contraseña maestra de la

configuration RDS-EVENT-0067 Ha fallado un intento de restablecer la contraseña

change maestra de la instancia de base de datos.
configuration RDS-EVENT-0078 Se ha cambiado la configuración de monitorización

change mejorada.
creation RDS-EVENT-0005 Instancia de base de datos creada.
deletion RDS-EVENT-0003 Se ha eliminado la instancia de base de datos.
failover RDS-EVENT-0034 Amazon RDS no está intentando realizar la

conmutación por error solicitada porque recientemente
se ha producido una conmutación por error en la
failover RDS-EVENT-0013 Se ha iniciado una conmutación por error Multi-AZ que

ha dado como resultado la promoción de una instancia
en espera.
failover RDS-EVENT-0015 Ha finalizado una conmutación por error Multi-AZ que

ha dado como resultado la promoción de una instancia
en espera. El DNS puede tardar varios minutos en
realizar la transferencia a la nueva instancia de base
de datos principal.
failover RDS-EVENT-0065 La instancia se ha recuperado de una conmutación por

error parcial.
failover RDS-EVENT-0049 Ha finalizado una conmutación por error Multi-AZ.
failover RDS-EVENT-0050 Se ha iniciado una activación Multi-AZ después de una

recuperación correcta de la instancia.
failover RDS-EVENT-0051 Ha finalizado una activación Multi-AZ. La base de

datos ya debería estar accessible.
failure RDS-EVENT-0031 Se ha producido un error en la instancia de base de

datos debido a una configuración incompatible o a un
problema de almacenamiento subyacente. Comience
una restauración a un momento dado para la instancia
de base de datos.
failure RDS-EVENT-0036 La instancia de base de datos está en una

red incompatible. Algunos de los ID de subred
especificados no son válidos o no existen.
failure RDS-EVENT-0035 La instancia de base de datos tiene parámetros no

válidos. Por ejemplo, no se ha podido iniciar MySQL
porque un parámetro relacionado con la memoria tiene
un valor demasiado alto para esta clase de instancia,
por lo que el cliente debería modificar el parámetro de
memoria y reiniciar la instancia de base de datos.

468

RDS
failure RDS-EVENT-0058 Error al crear la cuenta del usuario PERFSTAT de

Statspack. Elimine la cuenta antes de añadir la opción
Statspack.
failure RDS-EVENT-0079 La monitorización mejorada no se puede activar

sin el rol de monitorización mejorada de IAM. Para
obtener información acerca de la creación del rol de
monitorización mejorada de IAM, consulte Para crear
un rol de IAM para la monitorización mejorada de
failure RDS-EVENT-0080 La monitorización mejorada se ha desactivado debido

a un error al realizar el cambio de configuración.
Es probable que el rol de monitorización mejorada
de IAM se haya configurado incorrectamente. Para
obtener información acerca de la creación del rol de
monitorización mejorada de IAM, consulte Para crear
un rol de IAM para la monitorización mejorada de
failure RDS-EVENT-0082 Aurora no ha podido copiar los datos de copia de

seguridad de un bucket de Amazon S3. Es probable
que los permisos que tiene Aurora para obtener
acceso al bucket de Amazon S3 se hayan configurado
incorrectamente. Para obtener más información,
consulte Migración de datos desde MySQL con un
bucket de Amazon S3 (p. 504) .
low storage RDS-EVENT-0089 La instancia de base de datos ha consumido más del

90 % del almacenamiento asignado. El espacio de
almacenamiento de una instancia de base de datos
se puede monitorizar con la métrica Free Storage
Space. Para obtener más información, consulte
Visualización de métricas de una instancia de base de
datos (p. 373).
low storage RDS-EVENT-0007 Se ha agotado el almacenamiento asignado a la

instancia de base de datos. Para solucionar este
problema, debe asignar almacenamiento adicional
a la instancia de base de datos. Para obtener más
información, consulte las Preguntas frecuentes de
RDS. El espacio de almacenamiento de una instancia
de base de datos se puede monitorizar con la métrica
Free Storage Space. Para obtener más información,
consulte Visualización de métricas de una instancia de
maintenance RDS-EVENT-0026 Se está realizando el mantenimiento sin conexión de

la instancia de base de datos. La instancia de base de
datos no está disponible en este momento.
maintenance RDS-EVENT-0027 Ha finalizado el mantenimiento sin conexión de la

instancia de base de datos. La instancia de base de
datos ya está disponible.

469

RDS
maintenance RDS-EVENT-0155 La instancia de base de datos tiene disponible una

actualización de versiones secundarias de motor de
base de datos.
notification RDS-EVENT-0044 Notificación emitida por el operador. Para obtener más

información, consulte el mensaje del evento.
notification RDS-EVENT-0047 Ha finalizado la aplicación de parches a la instancia de

base de datos.
notification RDS-EVENT-0048 Se ha retrasado la aplicación de parches a la instancia

de base de datos.
notification RDS-EVENT-0054 El motor de almacenamiento de MySQL que

está utilizando no es InnoDB, que es el motor de
almacenamiento de MySQL recomendado para
Amazon RDS. Para obtener información sobre los
motores de almacenamiento de MySQL, consulte
Motores de almacenamiento admitidos para MySQL en
Amazon RDS.
notification RDS-EVENT-0055 La instancia de base de datos tiene un número de

tablas que supera las prácticas recomendadas para
Amazon RDS. Reduzca el número de tablas de la
Para obtener más información acerca de las prácticas

recomendadas, consulte Prácticas recomendadas con
notification RDS-EVENT-0056 La instancia de base de datos tiene un número

de bases de datos que supera las prácticas
recomendadas para Amazon RDS. Reduzca el número
de bases de datos de la instancia de base de datos.
Para obtener más información acerca de las prácticas

recomendadas, consulte Prácticas recomendadas con
notification RDS-EVENT-0157 RDS no puede modificar la clase de instancia de

base de datos porque la clase de instancia de destino
no puede admitir el número de bases de datos que
hay en la instancia de base de datos de origen. El
mensaje de error aparece como: "The instance has N
databases, but after conversion it would only support
N" (La instancia dispone de N bases de datos, pero
después de la conversión solo admitirá N).
notification RDS-EVENT-0087 Se ha detenido la instancia de base de datos.
notification RDS-EVENT-0088 Se ha iniciado la instancia de base de datos.
notification RDS-EVENT-0154 La instancia de base de datos se está iniciando debido

a que se supera el tiempo máximo permitido para estar
detenida.

470

RDS
read replica RDS-EVENT-0045 Se ha producido un error en el proceso de replicación

de una réplica de lectura. Para obtener más
información, consulte el mensaje del evento.
Para obtener más información sobre la resolución

de errores de réplicas de lectura, consulte Solución
de problemas de una réplica de lectura de MySQL o
MariaDB.
read replica RDS-EVENT-0046 La réplica de lectura ha reanudado la replicación.

Este mensaje aparece cuando se crea por primera
vez una réplica de lectura o como mensaje de
monitorización que confirma que la replicación
funciona correctamente. Si este mensaje es posterior
a una notificación RDS-EVENT-0045, significa que la
replicación se ha reanudado después de que se detuvo
o tras producirse un error.
read replica RDS-EVENT-0057 La replicación de la réplica de lectura ha finalizado.
read replica RDS-EVENT-0062 La replicación de la réplica de lectura se ha detenido

manualmente.
read replica RDS-EVENT-0063 La replicación de la réplica de lectura se ha

restablecido.
recovery RDS-EVENT-0020 Se ha iniciado la recuperación de la instancia de base

de datos. El tiempo de recuperación dependerá de la
cantidad de datos que deban recuperarse.
recovery RDS-EVENT-0021 Ha finalizado la recuperación de la instancia de base

de datos.
recovery RDS-EVENT-0023 Se ha solicitado una copia de seguridad manual, pero

Amazon RDS está creando una instantánea de base
de datos. Envíe de nuevo la solicitud cuando Amazon
RDS haya terminado la instantánea de base de datos.
recovery RDS-EVENT-0052 Se ha iniciado la recuperación de la instancia Multi-AZ.

El tiempo de recuperación dependerá de la cantidad de
datos que deban recuperarse.
recovery RDS-EVENT-0053 Ha finalizado la recuperación de la instancia Multi-AZ.
restoration RDS-EVENT-0008 La instancia de base de datos se ha restaurado a partir

de una instantánea de base de datos.
restoration RDS-EVENT-0019 La instancia de base de datos se ha restaurado a partir

de una copia de seguridad de un momento dado.
En la siguiente tabla se muestra la categoría de eventos y una lista de los eventos que pueden producirse
cuando el tipo de origen es un grupo de parámetros de base de datos.

471
Categoría ID de evento de RDS Descripción
configuration RDS-EVENT-0037 El grupo de parámetros se ha modificado.

change
producirse cuando el tipo de origen es un grupo de seguridad de base de datos.
configuration RDS-EVENT-0038 El grupo de seguridad se ha modificado.

change
failure RDS-EVENT-0039 El grupo de seguridad de Amazon EC2 propiedad de

[usuario] no existe; se ha revocado la autorización para
el grupo de seguridad.
producirse cuando el tipo de origen es un clúster de base de datos de Aurora.
failover RDS-EVENT-0069 Ha fallado la conmutación por error de un clúster de

base de datos.
failover RDS-EVENT-0070 Se ha reiniciado la conmutación por error de un clúster

de base de datos.
failover RDS-EVENT-0071 Ha finalizado la conmutación por error de un clúster de

base de datos.
failover RDS-EVENT-0072 Se ha iniciado una conmutación por error para el

clúster de base de datos dentro de la misma zona de
disponibilidad.
failover RDS-EVENT-0073 Se ha iniciado una conmutación por error para el

clúster de base de datos entre zonas de disponibilidad
distintas.
failure RDS-EVENT-0083 Aurora no ha podido copiar los datos de copia de

seguridad de un bucket de Amazon S3. Es probable
que los permisos que tiene Aurora para obtener
acceso al bucket de Amazon S3 se hayan configurado
incorrectamente. Para obtener más información,
consulte Migración de datos desde MySQL con un
bucket de Amazon S3 (p. 504) .
maintenance RDS-EVENT-0156 El clúster de base de datos tiene disponible una

actualización de versiones secundarias de motor de
base de datos.
notification RDS-EVENT-0076 Error en la migración a un clúster de base de datos de

Aurora.

472
Suscripción a notificaciones de eventos de Amazon RDS
notification RDS-EVENT-0077 Ha fallado un intento de convertir una tabla de la base

de datos de origen a InnoDB durante la migración a un
clúster de base de datos de Aurora.
notification RDS-EVENT-0149 No se ha encontrado ningún punto de escalado.
notification RDS-EVENT-0150 El clúster de base de datos se ha detenido
notification RDS-EVENT-0151 El clúster de base de datos se ha iniciado
notification RDS-EVENT-0152 La detención del clúster de base de datos ha producido

un error.
notification RDS-EVENT-0153 El clúster de base de datos se está iniciando debido a

que se supera el tiempo máximo permitido para estar
detenida.
En la siguiente tabla se muestra la categoría de eventos y una lista de los eventos que pueden producirse
cuando el tipo de origen es una instantánea de clúster de base de datos de Aurora.
backup RDS-EVENT-0074 Se ha iniciado la creación de una instantánea manual

backup RDS-EVENT-0075 Se ha creado una instantánea manual de clúster de

base de datos.
Suscripción a notificaciones de eventos de Amazon

RDS
Puede crear una suscripción a notificaciones de eventos de Amazon RDS para recibir notificaciones cada
vez que se produzca un evento en una instancia de base de datos, una instantánea de base de datos,
un grupo de seguridad de base de datos o un grupo de parámetros de base de datos determinados. La
forma más sencilla de crear una suscripción es con la consola de RDS. Si decide crear las suscripciones
de notificaciones de eventos a través de la CLI o la API, debe crear un tema de Amazon Simple Notification
Service y suscribirse a dicho tema con la consola de Amazon SNS o la API de Amazon SNS. También
deberá conservar el Nombre de recurso de Amazon (ARN) del tema, ya que este se utiliza al enviar los
comandos de la CLI o las acciones de la API. Para obtener información acerca de cómo crear un tema
de SNS y suscribirse a él, consulte Introducción a Amazon SNS en la Guía del desarrollador de Amazon
Simple Notification Service.
Puede especificar el tipo de origen sobre el que desea recibir notificaciones y el origen de Amazon RDS
que inicia el evento. Se especifican mediante los parámetros SourceType y SourceIdentifier (el origen de
Amazon RDS que genera el evento). Si especifica tanto SourceType como SourceIdentifier, por ejemplo,
SourceType = db-instance y SourceIdentifier = myDBInstance1, recibirá todos los eventos
de instancia de base de datos de un origen especificado. Si especifica SourceType, pero no especifica
SourceIdentifier, recibirá notificaciones de los eventos de ese tipo de origen para todos sus orígenes de
Amazon RDS. Si no especifica ni SourceType ni SourceIdentifier, se le notificarán los eventos generados
en todos los orígenes de Amazon RDS que pertenezcan a su cuenta de cliente.
Note
Las notificaciones de eventos pueden tardar hasta cinco minutos en entregarse.

473
Suscripción a notificaciones de eventos de Amazon RDS

Para suscribirse a las notificaciones de eventos de RDS
2. En el panel de navegación seleccione Event Subscriptions (Suscripciones de eventos).
3. En la página Event Subscriptions (Suscripciones de eventos) seleccione Create Event Subscription
(Crear suscripción de eventos).
4. En el cuadro de diálogo Create Event Subscription (Crear suscripción de eventos), haga lo siguiente:
a. En Name (Nombre) escriba un nombre para la suscripción de notificación de evento.

b. Para Send notifications to (Enviar notificaciones a), elija un ARN de Amazon SNS existente
correspondiente a un tema de Amazon SNS o elija create topic (crear tema) para escribir el
nombre de un tema y una lista de destinatarios.
c. En Source type (Tipo de origen) elija un tipo de origen.
d. Elija Yes (Sí) para activar la suscripción. Si desea crear la suscripción, pero que todavía no
envíen notificaciones, seleccione No.
e. En función del tipo de origen que haya seleccionado, seleccione las categorías y orígenes del
evento de las que desea recibir notificaciones.
f. Seleccione Create.
La consola de Amazon RDS indica que se está creando la suscripción.
CLI
Para suscribirse a notificaciones de eventos de RDS, utilice el comando create-event-subscription
de la AWS CLI. Incluya los siguientes parámetros obligatorios:
• --subscription-name
• --sns-topic-arn
Example
aws rds create-event-subscription \

--subscription-name myeventsubscription \
--sns-topic-arn arn:aws:sns:us-east-1:802#########:myawsuser-RDS \
--enabled
Para Windows:
aws rds create-event-subscription ^

--subscription-name myeventsubscription ^
--sns-topic-arn arn:aws:sns:us-east-1:802#########:myawsuser-RDS ^
--enabled

474
Mostrar las suscripciones de
notificación de eventos de Amazon RDS
API
Para suscribirse a notificaciones de eventos de Amazon RDS, llame a la función
CreateEventSubscription de la API de Amazon RDS. Incluya los siguientes parámetros obligatorios:
• SubscriptionName
• SnsTopicArn
Mostrar las suscripciones de notificación de eventos

de Amazon RDS
Puede mostrar las suscripciones actuales de notificación de eventos de Amazon RDS.

Pasos mostrar las sus suscripciones actuales de notificación de eventos de Amazon RDS
2. En el panel de navegación seleccione Event Subscriptions (Suscripciones de eventos). El panel Event
subscriptions (Suscripciones de eventos) muestra todas sus suscripciones a notificaciones de eventos.
CLI
Para obtener una lista de sus suscripciones a notificaciones de eventos de Amazon RDS, utilice el
comando describe-event-subscriptions de la AWS CLI.
Example
En el siguiente ejemplo se obtienen todas las suscripciones a eventos.
aws rds describe-event-subscriptions
En el siguiente ejemplo se obtiene la descripción de myfirsteventsubscription.
aws rds describe-event-subscriptions --subscription-name myfirsteventsubscription
API
Para obtener una lista de sus suscripciones actuales a notificaciones de eventos de Amazon RDS, llame a
la acción DescribeEventSubscriptions de la API Amazon RDS.

475
Modificación de una suscripción a
notificaciones de eventos de Amazon RDS
Example
En el siguiente ejemplo de código se muestra una lista de hasta 100 suscripciones a eventos.
?Action=DescribeEventSubscriptions
&MaxRecords=100
&SignatureVersion=4
&Version=2014-09-01
&X-Amz-Date=20140428T161907Z
&X-Amz-Signature=4208679fe967783a1a149c826199080a066085d5a88227a80c6c0cadb3e8c0d4
En el siguiente ejemplo se obtiene la descripción de myfirsteventsubscription.
?Action=DescribeEventSubscriptions
&SignatureVersion=4
&SubscriptionName=myfirsteventsubscription
&Version=2014-09-01
&X-Amz-Date=20140428T161907Z
&X-Amz-Signature=4208679fe967783a1a149c826199080a066085d5a88227a80c6c0cadb3e8c0d4
Modificación de una suscripción a notificaciones de

eventos de Amazon RDS
Después de crear una suscripción, puede cambiar el nombre de la suscripción, el identificador del origen,
las categorías o el ARN del tema.
Para modificar una suscripción de notificación de eventos de Amazon RDS
2. En el panel de navegación seleccione Event Subscriptions (Suscripciones de eventos).
3. En el panel Event subscriptions (Suscripciones de eventos), elija la suscripción que desea modificar y
elija Edit (Editar).
4. Realice los cambios que desee en la suscripción en las secciones Target (Objetivo) o Source (Fuente).
5. Elija Edit. La consola de Amazon RDS indica que se está modificando la suscripción.

476
Añadir un identificador de origen a una suscripción
de notificación de eventos de Amazon RDS
CLI
Para modificar una suscripción a notificaciones de eventos de Amazon RDS, utilice el comando modify-
event-subscription de la AWS CLI. Incluya el siguiente parámetro obligatorio:
Example
El siguiente código activa myeventsubscription.
aws rds modify-event-subscription \

--subscription-name myeventsubscription \
--enabled
Para Windows:
aws rds modify-event-subscription ^

--subscription-name myeventsubscription ^
--enabled
API
Para modificar un evento de Amazon RDS, llame a la acción ModifyEventSubscription de la API de
Amazon RDS. Incluya el siguiente parámetro obligatorio:
Añadir un identificador de origen a una suscripción de

Puede añadir un identificador de origen (el origen de Amazon RDS que genera el evento) a una
suscripción existente.

Puede añadir o eliminar fácilmente identificadores de origen mediante la consola de Amazon RDS
activándolos o desactivándolos al modificar una suscripción. Para obtener más información, consulte
Modificación de una suscripción a notificaciones de eventos de Amazon RDS (p. 476).
CLI
Para añadir un identificador de origen a una suscripción a notificaciones de eventos de Amazon RDS,
utilice el comando add-source-identifier-to-subscription de la AWS CLI. Incluya los siguientes
parámetros obligatorios:
• --source-identifier
Example
En el siguiente ejemplo se añade el identificador de origen mysqldb a la suscripción
myrdseventsubscription

477
Quitar un identificador de origen de una suscripción
de notificación de eventos de Amazon RDS
aws rds add-source-identifier-to-subscription \

--subscription-name myrdseventsubscription \
--source-identifier mysqldb
Para Windows:
aws rds add-source-identifier-to-subscription ^

--subscription-name myrdseventsubscription ^
API
Para añadir un identificador de origen a una suscripción a notificaciones de eventos de Amazon RDS,
llame a la acción AddSourceIdentifierToSubscription de la API de Amazon RDS. Incluya los
siguientes parámetros obligatorios:
• SourceIdentifier
Quitar un identificador de origen de una suscripción de

Puede eliminar un identificador de origen (el origen de Amazon RDS que genera el evento) de una
suscripción si ya no desea recibir notificaciones de los eventos de ese origen.

Puede añadir o eliminar fácilmente identificadores de origen mediante la consola de Amazon RDS
activándolos o desactivándolos al modificar una suscripción. Para obtener más información, consulte
Modificación de una suscripción a notificaciones de eventos de Amazon RDS (p. 476).
CLI
Para eliminar un identificador de origen de una suscripción a notificaciones de eventos de Amazon RDS,
utilice el comando remove-source-identifier-from-subscription de la AWS CLI. Incluya los
siguientes parámetros obligatorios:
• --source-identifier
Example
En el siguiente ejemplo, se elimina el identificador de origen mysqldb de la suscripción

myrdseventsubscription.
aws rds remove-source-identifier-from-subscription \

--subscription-name myrdseventsubscription \

478
Obtención de la lista de categorías de
notificaciones de eventos de Amazon RDS
Para Windows:
aws rds remove-source-identifier-from-subscription ^

--subscription-name myrdseventsubscription ^
API
Para eliminar un identificador de origen de una suscripción a notificaciones de eventos de Amazon RDS,
utilice el comando RemoveSourceIdentifierFromSubscription de la API de Amazon RDS. Incluya
los siguientes parámetros obligatorios:
• SourceIdentifier
Obtención de la lista de categorías de notificaciones

de eventos de Amazon RDS
Todos los eventos de un tipo de recurso se agrupan en categorías. Para ver la lista de categorías
disponibles, utilice los siguientes procedimientos.

Cuando se crea o modifica una suscripción a notificaciones de eventos, las categorías de eventos se
muestran en la consola de Amazon RDS. Para obtener más información, consulte Modificación de una
suscripción a notificaciones de eventos de Amazon RDS (p. 476).
CLI
Para obtener la lista de categorías de notificaciones de eventos de Amazon RDS, utilice el comando
describe-event-categories de la AWS CLI. Este comando no tiene parámetros obligatorios.

479
Eliminar una suscripción de notificación
de eventos de Amazon RDS
Example
aws rds describe-event-categories
API
Para obtener la lista de categorías de notificaciones de eventos de Amazon RDS, utilice el comando
DescribeEventCategories de la API de Amazon RDS. Este comando no tiene parámetros obligatorios.
Eliminar una suscripción de notificación de eventos de

Amazon RDS
Puede eliminar una suscripción cuando ya no la necesite. Los suscriptores del tema dejarán de recibir
notificaciones de los eventos especificados en la suscripción.

Para eliminar una suscripción de notificación de eventos de Amazon RDS
2. En el panel de navegación seleccione DB Event Subscriptions (Suscripciones a eventos de base de
datos).
3. En el panel My DB Event Subscriptions (Mis suscripciones a eventos de base de datos), elija la
suscripción que desea eliminar.
4. Elija Eliminar.
5. La consola de Amazon RDS indica que se está eliminando la suscripción.
CLI
Para eliminar una suscripción a notificaciones de eventos de Amazon RDS, utilice el comando delete-
event-subscription de la AWS CLI. Incluya el siguiente parámetro obligatorio:
Example
En el siguiente ejemplo se elimina la suscripción myrdssubscription:
aws rds delete-event-subscription --subscription-name myrdssubscription

480
Consulta de eventos de Amazon RDS
API
Para eliminar una suscripción a notificaciones de eventos de Amazon RDS, utilice el comando
DeleteEventSubscription de la API de RDS. Incluya el siguiente parámetro obligatorio:
Consulta de eventos de Amazon RDS

Amazon RDS mantiene un registro de los eventos relacionados con las instancias de bases de datos, las
instantáneas de base de datos, los grupos de seguridad de base de datos y los grupos de parámetros de
base de datos. Esta información incluye la fecha y hora del evento, el nombre del origen y el tipo del origen
del evento y un mensaje relacionado con el evento.
Puede recuperar eventos de los recursos de RDS a través de la Consola de administración de AWS, la
cual muestra los eventos de las últimas 24 horas. También puede recuperar eventos de los recursos de
RDS utilizando el comando describe-events de la AWS CLI o la acción DescribeEvents de la API de RDS.
Si utiliza la AWS CLI o la API de RDS para ver eventos, puede recuperar eventos de los últimos 14 días
como máximo.

Para ver todos los eventos de las instancias de Amazon RDS de las últimas 24 horas
2. En el panel de navegación, seleccione Events. Los eventos disponibles aparecen en una lista.
3. Utilice la lista Filter para filtrar los eventos por tipo y utilice el cuadro de texto que aparece a la derecha
de la lista Filter para filtrar aún más los resultados. Por ejemplo, la siguiente captura de pantalla
muestra una lista de eventos filtrados por el tipo de evento de instancia de base de datos y que
contiene los caracteres 1318.
CLI
Para ver todos los eventos de las instancias de Amazon RDS de los últimas 7 días
Puede ver todos los eventos de las instancias de Amazon RDS de los últimos 7 días llamando al comando
describe-events de la AWS CLI y estableciendo el parámetro --duration en 10080.
aws rds describe-events --duration 10080

481
API
API
Para ver todos los eventos de las instancias de Amazon RDS de los últimas 14 días
Puede ver todos los eventos de las instancias de Amazon RDS de los últimos 14 días llamando a la acción
DescribeEvents de la API de RDS y estableciendo el parámetro Duration en 20160.
?Action=DescribeEvents
&Duration=20160
&MaxRecords=100
&SignatureVersion=4
&Version=2014-09-01
&X-Amz-Date=20140421T194733Z
&X-Amz-Signature=8e313cabcdbd9766c56a2886b5b298fd944e0b7cfa248953c82705fdd0374f27
Archivos de registro de base de datos de Amazon

RDS
Puede ver, descargar y monitorizar los registros de base de datos usando la consola de Amazon RDS, la
AWS Command Line Interface (AWS CLI) o la API de Amazon RDS. Visualizar, descargar o monitorizar
registros de transacción no está permitido.
Visualización y listado de archivos de registro de base

de datos
Puede ver los archivos de registro de base de datos de su motor de base de datos con la consola de
Amazon RDS. Puede ver los archivos de registro que están disponibles para su descarga o monitorización
usando la AWS CLI o la API de Amazon RDS.

Para ver un archivo de registro de base de datos

3. Seleccione el nombre de la instancia de base de datos que tiene el archivo de registro que desea
visualizar.
4. Seleccione la pestaña Logs & events (Registros y eventos).
5. Desplácese hacia abajo hasta la sección Logs.
6. En la sección Logs (Registros), elija el registro que quiera visualizar y, a continuación, elija View (Ver).
AWS CLI
Para ver los archivos de registro de base de datos disponibles para una instancia de base de datos, use el
comando describe-db-log-files de la AWS CLI.

482
Descarga de un archivo de registro de base de datos
El siguiente ejemplo devuelve una lista de los archivos de registro de una instancia de base de datos
denominada my-db-instance.
Example
aws rds describe-db-log-files --db-instance-identifier my-db-instance
API
Para ver los archivos de registro de base de datos de una instancia de base de datos, use la acción
DescribeDBLogFiles de la API de Amazon RDS.
Descarga de un archivo de registro de base de datos

Puede usar la consola, la Amazon RDS o la API de AWS CLI para descargar un archivo de registro de
base de datos.

Para descargar un archivo de registro de base de datos

visualizar.
5. Desplácese hacia abajo hasta la sección Logs.
6. En la sección Logs (Registros), elija el botón junto al registro que desee descargar y, a continuación,
elija Download (Descargar).
7. Abra el menú contextual (haga clic con el botón derecho) del enlace que se proporciona y elija Save
Link As (Guardar enlace como). Escriba la ubicación en la que desee guardar el archivo de registro y
elija Save (Guardar).
AWS CLI
Para descargar un archivo de registro de base de datos, use el comando download-db-log-file-
portion de la AWS CLI. De forma predeterminada, este comando solo descarga la última porción de
un archivo de registro. Sin embargo, puede descargar un archivo entero especificando el parámetro --
starting-token 0.

483
Monitorizar un archivo de registro de base de datos
En el siguiente ejemplo se muestra cómo descargar todo el contenido de un archivo de registro llamado
log/ERROR.4 y almacenarlo en un archivo local denominado errorlog.txt.
Example
aws rds download-db-log-file-portion \

--db-instance-identifier myexampledb \
--starting-token 0 --output text \
--log-file-name log/ERROR.4 > errorlog.txt
Para Windows:
aws rds download-db-log-file-portion ^

--db-instance-identifier myexampledb ^
--starting-token 0 --output text ^
--log-file-name log/ERROR.4 > errorlog.txt
API de RDS
Para descargar un archivo de registro de base de datos, use la acción DownloadDBLogFilePortion de
la API de Amazon RDS.
Monitorizar un archivo de registro de base de datos

Puede monitorizar el contenido de un archivo de registro usando la consola de Amazon RDS.

Para monitorizar un archivo de registro de base de datos

visualizar.
5. En la sección Logs (Registros), elija un archivo de registro y, a continuación, elija Watch (Ver).
Publicación de registros de base de datos en Amazon

CloudWatch Logs
Además de ver y descargar registros de instancias de base de datos, también puede publicarlos en
Amazon CloudWatch Logs. CloudWatch Logs permite realizar análisis de los datos del registro en tiempo
real, guardarlos en un almacenamiento de larga duración y gestionarlos con el agente de CloudWatch
Logs. AWS conserva los datos de registro publicados en CloudWatch Logs durante un periodo de tiempo
indefinido a menos que se especifique un periodo de retención. Para obtener más información, consulte
Cambiar la retención de datos de registro en CloudWatch Logs.
Si necesita documentación relativa a los motores, consulte lo siguiente:
• the section called “Publicación de registros de Aurora MySQL en CloudWatch Logs” (p. 662)

484
Lectura del contenido del archivo de registro mediante REST
Lectura del contenido del archivo de registro mediante

REST
Amazon RDS proporciona un punto de enlace REST que permite el acceso a los archivos de registro de
instancia de base de datos. Esto resulta útil si necesita escribir una aplicación para transmitir el contenido
del archivo de registro de Amazon RDS.
La sintaxis es la siguiente:
GET /v13/downloadCompleteLogFile/DBInstanceIdentifier/LogFileName HTTP/1.1

Content-type: application/json
host: rds.region.amazonaws.com
Se requieren los siguientes parámetros:
• DBInstanceIdentifier: el nombre asignado de la instancia de base de datos que contiene el archivo

de registro que se desea descargar.
• LogFileName: el nombre del archivo de registro que se va a descargar.
La respuesta incluye el contenido del archivo de registro solicitado como una secuencia.
En el siguiente ejemplo se descarga el archivo de registro denominado log/ERROR.6 para la instancia de

base de datos denominada sample-sql en la región us-west-2.
GET /v13/downloadCompleteLogFile/sample-sql/log/ERROR.6 HTTP/1.1

host: rds.us-west-2.amazonaws.com
X-Amz-Security-Token: AQoDYXdzEIH//////////
wEa0AIXLhngC5zp9CyB1R6abwKrXHVR5efnAVN3XvR7IwqKYalFSn6UyJuEFTft9nObglx4QJ+GXV9cpACkETq=
X-Amz-Date: 20140903T233749Z
X-Amz-Algorithm: AWS4-HMAC-SHA256
X-Amz-Credential: AKIADQKE4SARGYLE/20140903/us-west-2/rds/aws4_request
X-Amz-SignedHeaders: host
X-Amz-Content-SHA256: e3b0c44298fc1c229afbf4c8996fb92427ae41e4649b934de495991b7852b855
X-Amz-Expires: 86400
X-Amz-Signature: 353a4f14b3f250142d9afc34f9f9948154d46ce7d4ec091d0cdabbcf8b40c558
Si especifica una instancia de base de datos no existente, la respuesta consta del error siguiente:
• DBInstanceNotFound: DBInstanceIdentifier no hace referencia a una instancia de base de

datos existente. (Código de estado HTTP: 404)
Archivos de registro de base de datos de MySQL

Puede monitorizar el registro de errores, el registro de consultas lentas y el registro general. El registro
de errores de MySQL se genera de forma predeterminada. Los registros general y de consultas lentas se
pueden generar configurando parámetros del grupo de parámetros de base de datos. Amazon RDS aplica
una rotación a todos los archivos de registro de MySQL con los intervalos indicados a continuación para
cada tipo.
Puede monitorizar los registros de MySQL directamente desde la consola de Amazon RDS la API de
Amazon RDS, la AWS CLI o los SDK de AWS. También es posible el acceso a los registros de MySQL
dirigiéndolos a una tabla de la base de datos principal y consultando esa tabla. Puede usar la utilidad
mysqlbinlog para descargar un registro binario.

485
Para obtener más información acerca de la visualización, descarga y vigilancia de los registros de bases
de datos basados en archivos, consulte Archivos de registro de base de datos de Amazon RDS (p. 482).
Acceso a los registros de errores de MySQL

El registro de errores de MySQL se almacena en el archivo mysql-error.log. Puede ver mysql-
error.log usando la consola de Amazon RDS o recuperando el registro con la API de Amazon RDS, la
CLI de Amazon RDS o los SDK de AWS. mysql-error.log se vacía cada 5 minutos y su contenido se
agrega a mysql-error-running.log. El archivo mysql-error-running.log rota cada hora, y se
conservan los archivos generados cada hora durante las últimas 30 días. Tenga en cuenta que el periodo
de retención es diferente entre Amazon RDS y Aurora.
Cada archivo de registro tiene la hora a la que se generó (en UTC) agregada a su nombre. Los archivos de
registro también tienen una marca temporal que ayuda a determinar cuándo se escribieron las entradas del
registro.
MySQL solo escribe en el registro de errores durante el inicio, el cierre y cuando encuentra errores. Una
instancia de base de datos puede pasar horas o días sin que se escriban nuevas entradas en el registro de
errores. Si no hay entradas recientes, se debe a que el servidor no ha encontrado ningún error que genere
una entrada en el registro.
Acceso al registro de consultas lentas y al registro general de

MySQL
El registro de consultas lentas y el registro general de MySQL pueden almacenarse en un archivo o en
una tabla de base de datos configurando parámetros del grupo de parámetros de base de datos. Para
obtener información acerca de cómo crear y modificar un grupo de parámetros de base de datos, consulte
datos (p. 259). Debe definir estos parámetros para poder ver el registro de consultas lentas o el registro
general en la consola de Amazon RDS o a través de la API de Amazon RDS. la CLI de Amazon RDS o los
SDK de AWS.
Puede controlar lo que registra MySQL con los parámetros de esta lista:
• slow_query_log: para crear el registro de consultas lentas, use el valor 1. El valor predeterminado es
0.
• general_log: para crear el registro general, use el valor 1. El valor predeterminado es 0.
• long_query_time: para evitar que se registren consultas rápidas en el registro de consultas lentas,
especifique el valor del tiempo de ejecución mínimo de una consulta, en segundos, para que se registre.
El valor predeterminado es 10 segundos y el mínimo es 0. Si log_output = FILE, puede especificar un
valor de punto flotante que llega a una resolución de microsegundos. Si log_output = TABLE, debe
especificar un valor entero con resolución de segundos. Solo se registrarán las consultas cuyo tiempo de
ejecución exceda el valor de long_query_time. Por ejemplo, si configura long_query_time como
0,1, evitará que se registren las consultas que tarden menos de 100 milisegundos en ejecutarse.
• log_queries_not_using_indexes: para incluir en el registro de consultas lentas todas las
consultas que no usen un índice, use el valor 1. El valor predeterminado es 0. Las consultas que no
usen un índice se registrarán incluso cuando su tiempo de ejecución sea inferior al valor del parámetro
long_query_time.
• log_output option: puede especificar una de las opciones siguientes para el parámetro
log_output.
• TABLE (predeterminada): las consultas generales se escriben en la tabla mysql.general_log y las
consultas lentas en la tabla mysql.slow_log.
• FILE: tanto los registros de las consultas generales como los de las consultas lentas se escriben en el
sistema de archivos. Los archivos de registro se rotan cada hora.

486
• NONE: deshabilitar registro.
Cuando el registro está habilitado, Amazon RDS rota los registros de las tablas o elimina los archivos de
registro a intervalos regulares. Esta medida es una precaución para reducir el riesgo de que un archivo de
registro grande bloquee el uso de la base de datos o afecte al rendimiento. El registro con las opciones
FILE y TABLE emplea la rotación y eliminación del modo siguiente:
• Cuando está activado el registro FILE, los archivos de registro se examinan cada hora, y los que tienen
una antigüedad superior a 24 horas se eliminan. En algunos casos, el tamaño restante del archivo de
registro combinado después de la eliminación puede superar el umbral del 2 por ciento del espacio
asignado a una instancia de base de datos. En estos casos, los archivos de registro más grandes se
eliminan hasta que el tamaño del archivo de registro no sobrepase el umbral.
• Cuando el registro de tipo TABLE está habilitado, en algunos casos, las tablas de registro se rotan cada
24 horas. Esta rotación de produce cuando el espacio ocupado por los registros de tabla es superior
al 20% del espacio de almacenamiento asignado o si el tamaño de todos los registros combinados es
superior a 10 GB. Si la cantidad de espacio utilizada para una instancia de base de datos es superior al
90% del espacio de almacenamiento asignado a la instancia de base de datos, se reducen los umbrales
de la rotación de registros. En este caso las tablas de registro rotan cuando el espacio ocupado por
los registros es superior al 10% del almacenamiento asignado o si el tamaño de todos los registros
combinados es superior a 5 GB. Puede suscribirse al evento low_free_storage para recibir una
notificación cuando roten las tablas de registro para liberar espacio. Para obtener más información,
consulte Uso de las notificaciones de eventos de Amazon RDS (p. 465).
Cuando se rotan las tablas de registro, la tabla de registro actual se copia en una tabla de
registro de copia de seguridad y las entradas de la tabla de registro actual se eliminan. Si la
tabla de registro de copia de seguridad ya existe, se elimina antes de copiar la tabla del registro
actual en la copia de seguridad. Puede consultar la tabla de registro de copia de seguridad si
es necesaria. La tabla de registro de copia de seguridad para la tabla mysql.general_log se
llama mysql.general_log_backup. La tabla de registro de copia de seguridad para la tabla
mysql.slow_log se llama mysql.slow_log_backup.
Para rotar la tabla mysql.general_log puede ejecutar el procedimiento

mysql.rds_rotate_general_log. Para rotar la tabla mysql.slow_log puede ejecutar el
procedimiento mysql.rds_rotate_slow_log.
Los registros de tabla se rotan durante una actualización de la versión de la base de datos.
Para trabajar con los registros desde la consola de Amazon RDS, la API de Amazon RDS, CLI de Amazon
RDS o los SDK de AWS, configure el parámetro log_output en FILE. Al igual que el registro de errores
de MySQL, estos archivos de registro rotan cada hora. Se conservan los archivos de registro que se
generaron durante las 72 horas anteriores. Tenga en cuenta que el periodo de retención es diferente entre
Amazon RDS y Aurora.
Para obtener más información sobre la el registro de consultas lentas y el registro general, consulte los
siguientes temas de la documentación de MySQL:
• The Slow Query Log

• The General Query Log
Publicación de registros de Aurora MySQL en Amazon

CloudWatch Logs
Puede configurar un clúster de base de datos de Aurora MySQL para publicar datos de registro en un
grupo de registros en Amazon CloudWatch Logs. Con CloudWatch Logs, puede realizar análisis en

487
tiempo real de los datos de registro y utilizar CloudWatch para crear alarmas y ver métricas. Puede
utilizar CloudWatch Logs para almacenar los registros de registros en almacenamiento de larga duración.
Para obtener más información, consulte Publicación de registros de Amazon Aurora MySQL en Amazon
CloudWatch Logs (p. 662).
Tamaño del archivo de registro

El tamaño de los archivos de registro de consultas lentas, registro de errores y registro general de MySQL
está limitado al 2 por ciento del espacio de almacenamiento asignado a una instancia de base de datos.
Para mantener este umbral, los registros se rotan automáticamente cada hora y los que tienen una
antigüedad superior a 24 horas se eliminan. Si el tamaño combinado de los archivos de registro sobrepasa
el umbral después de eliminar los archivos de registro antiguos, los archivos de registro más grandes se
eliminan hasta que el tamaño del archivo de registro deje de sobrepasar el umbral.
En MySQL existe un límite al tamaño de los BLOB escritos en el registro REDO. Para respetar este límite,
asegúrese de que el parámetro innodb_log_file_size de la instancia de base de datos MySQL
sea 10 veces mayor que el tamaño máximo de BLOB que haya en las tablas, más la longitud de otros
campos de longitud variable (como VARCHAR, VARBINARY o TEXT) de las mismas tablas. Para obtener
información acerca del modo de configurar los valores de los parámetros, consulte Trabajo con los grupos
de parámetros de base de datos y grupos de parámetros de clúster de base de datos (p. 259). Para
obtener información acerca del límite de tamaño de BLOB en el registro REDO, consulte Changes in
MySQL 5.6.20.
Administración de registros de MySQL basados en tablas

Para dirigir los registros general y de consultas lentas a tablas de la instancia de base de datos, cree un
grupo de parámetros de base de datos y configure en el parámetro log_output del servidor el valor
TABLE. Las consultas generales se registrarán entonces en la tabla mysql.general_log y las consultas
lentas en la tabla mysql.slow_log. Puede consultar las tablas para obtener acceso a la información del
registro. Al habilitar este registro, se incrementa la cantidad de datos que se escribe en la base de datos, lo
que puede degradar el desempeño.
Tanto el registro general como los registros de consultas lentas están deshabilitados de manera
predeterminada. Para habilitar el registro en tablas, también debe asignar a los parámetros general_log
y slow_query_log del servidor el valor 1.
Las tablas de registro seguirán creciendo hasta que las actividades de registro respectivas se desactiven
cambiando el valor del parámetro a 0. A menudo, se acumula con el tiempo una gran cantidad de datos,
lo que puede consumir un porcentaje elevado del espacio de almacenamiento asignado. Amazon RDS
no permite truncar las tablas de registro, pero sí mover su contenido. Al rotar una tabla, su contenido se
guarda en una tabla de copia de seguridad y se crea una nueva tabla de registro vacía. Puede aplicar
manualmente la rotación de las tablas de registro con los procedimientos de línea de comandos siguientes,
en los que el símbolo del sistema se representa por PROMPT>:
PROMPT> CALL mysql.rds_rotate_slow_log;

PROMPT> CALL mysql.rds_rotate_general_log;
Para eliminar por completo los datos antiguos y recuperar el espacio del disco, llame al procedimiento
correspondiente dos veces consecutivas.
Formato de registro binario

MySQL en Amazon RDS admite los formatos de registro binario basado en filas, basado en instrucciones
y mixto para la versión 5.6 y posteriores de MySQL. El formato de registro binario predeterminado es el
mixto. Para las instancias de base de datos con MySQL 5.1 y 5.5, solo se admite el registro binario mixto.
Para obtener información detallada acerca de los formatos de registro binarios de MySQL, consulte Binary
Logging Formats (Formatos de registro binarios) en la documentación de MySQL.

488
Si tiene pensado utilizar la replicación, el formato de registro binario es importante porque determina el
registro de los cambios de datos que se registra en la fuente y se envía a los objetivos de replicación. Para
obtener más información acerca de las ventajas y desventajas de distintos tipos de formatos de registro
binarios para la replicación, consulte Advantages and Disadvantages of Statement-Based and Row-Based
Replication en la documentación de MySQL.
Important
La configuración del formato de registro binario como basado en filas puede generar archivos
de registro binario muy grandes. Los archivos de registro binario grandes reducen la cantidad de
almacenamiento disponible para una instancia de base de datos y pueden incrementar la cantidad
de tiempo necesaria para llevar a cabo la operación de restauración de una instancia de base de
datos.
La replicación basada en instrucciones puede causar incoherencias entre la instancia de base de
datos de origen y la réplica de lectura. Para obtener más información, consulte Determination of
Safe and Unsafe Statements in Binary Logging en la documentación de MySQL.
Para configurar el formato de registro binario de MySQL

3. Elija el grupo de parámetros utilizados por la instancia de base de datos que quiera modificar.
No puede modificar un grupo de parámetros predeterminado. Si la instancia de base de datos emplea

un grupo de parámetros predeterminado, cree un nuevo grupo de parámetros y asócielo con la
Para obtener más información acerca de los grupos de parámetros de base de datos, consulte
datos (p. 259).
5. Establezca el parámetro binlog_format en el formato de registro binario de su elección (ROW,
STATEMENT o MIXED).
6. Elija Save Changes (Guardar cambios) para guardar los cambios realizados en el grupo de
Important
Los cambios en el grupo de parámetros de base de datos default.mysql5.6,

default.mysql5.7 o default.mysql8.0 afectarán a todas las instancias de bases de datos
MySQL versión 5.6 que utilicen ese grupo de parámetros. Si desea especificar formatos de
registro binario distintos para diferentes instancias de base de datos MySQL 5.6, 5.7 u 8.0 en
una región AWS, debe crear su propio grupo de parámetros de base de datos. Este grupo de
parámetros identifica el formato de registro distinto y asigna ese grupo de parámetros de base de
datos a las instancias base de datos correspondientes.
Acceso a los registros binarios de MySQL

Puede usar la herramienta mysqlbinlog para descargar o transmitir los registros binarios desde las
instancias de Amazon RDS con MySQL 5.6 o posterior. El registro binario se descarga en el equipo
local, donde puede ejecutar acciones tales como reproducirlo con la utilidad mysql. Para obtener más
información acerca del uso de la herramienta mysqlbinlog, consulte Using mysqlbinlog to Back Up Binary
Log Files.
Para ejecutar la utilidad mysqlbinlog en una instancia de Amazon RDS, use las siguientes opciones:

489
• Especifique la opción --read-from-remote-server.

• --host: especifique el nombre de DNS del punto de conexión de la instancia.
• --port: especifique el puerto que utiliza la instancia.
• --user: especifique un usuario de MySQL al que se haya asignado el permiso de esclavo de
replicación.
• --password: especifique la contraseña del usuario o no indique ninguna para que la utilidad le pida una
contraseña.
• Especifique la opción --raw para descargar el archivo en formato binario.
• --result-file: especifique el archivo local en que se guardará la salida sin procesar.
• Especifique los nombres de uno o varios de los archivos de registro binarios. Para obtener una lista de
los registros disponibles, use el comando SHOW BINARY LOGS de SQL.
• Especifique la opción --stop-never para transmitir los archivos binarios en streaming.
Para obtener más información acerca de las opciones de mysqlbinlog, consulte mysqlbinlog - Utility for
Processing Binary Log Files.
Consulte los ejemplos siguientes.
mysqlbinlog \
--read-from-remote-server \
--host=MySQL56Instance1.cg034hpkmmjt.region.rds.amazonaws.com \
--port=3306 \
--user ReplUser \
--password \
--raw \
--result-file=/tmp/ \
binlog.00098
Para Windows:
mysqlbinlog ^
--read-from-remote-server ^
--host=MySQL56Instance1.cg034hpkmmjt.region.rds.amazonaws.com ^
--port=3306 ^
--user ReplUser ^
--password ^
--raw ^
--result-file=/tmp/ ^
binlog.00098
Normalmente, Amazon RDS limpia un registro binario lo antes posible, pero el registro binario debe seguir
estando disponible en la instancia para que mysqlbinlog pueda obtener acceso a él. Para especificar
el número de horas que RDS debe retener los archivos binarios, utilice el procedimiento almacenado
mysql.rds_set_configuration y especifique un periodo lo bastante largo como para descargar
los registros. Una vez que haya definido el periodo de retención, monitorice el uso del almacenamiento
para la instancia de base de datos con el fin de asegurarse de que los registros binarios conservados no
consuman demasiado almacenamiento.
Note
El procedimiento almacenado mysql.rds_set_configuration solo está disponible para la

versión 5.6 o posteriores de MySQL.
En el siguiente ejemplo se define el periodo de retención en 1 día.

490
Archivos de registro de base de datos de PostgreSQL
call mysql.rds_set_configuration('binlog retention hours', 24);
Para mostrar el valor actual, utilice el procedimiento almacenado mysql.rds_show_configuration.
call mysql.rds_show_configuration;
Archivos de registro de base de datos de PostgreSQL

RDS PostgreSQL genera registros de consultas y de errores. Se escribe información de auto-vacuum y las
acciones rds_admin en el registro de errores. PostgreSQL también registra las conexiones, desconexiones
y puntos de comprobación en el registro de errores. Para obtener más información, consulte Error
Reporting and Logging en la documentación de PostgreSQL.
Puede establecer el periodo de retención de los registros del sistema mediante el parámetro
rds.log_retention_period del grupo de parámetros de base de datos asociado con la instancia de
base de datos. La unidad para este parámetro son los minutos. Por ejemplo, un ajuste de 1440 conservaría
los registros un día. El valor predeterminado es 4320 (tres días). El valor máximo es 10080 (siete días).
Tenga en cuenta que la instancia debe tener suficiente almacenamiento asignado para contener los
archivos de registro retenidos.
Puede habilitar el registro de consultas de la instancia de base de datos de PostgreSQL estableciendo los
dos parámetros siguientes en el grupo de parámetros de base de datos asociado a la instancia de base
de datos: log_statement y log_min_duration_statement. El parámetro log_statement controla
qué instrucciones SQL se registran. Recomendamos configurar este parámetro en all para registrar todas
las instrucciones al depurar problemas en su instancia de base de datos. El valor predeterminado es none.
Como alternativa, puede configurar este valor en ddl para registrar todas las instrucciones en lenguaje de
definición de datos (DDL) (CREATE, ALTER, DROP, etc.) o en mod para registrar todas las instrucciones
en lenguaje DDL y en lenguaje de modificación de datos (INSERT, UPDATE, DELETE, etc.).
El parámetro log_min_duration_statement establece el límite de ejecución en milisegundos

para registrar las instrucciones. Todas las instrucciones SQL que se ejecuten durante mas tiempo del
establecido en este parámetro se registran. Este parámetro esta desactivado y establecido en menos 1 (-1)
de forma predeterminada. Si se activa este parámetro, puede resultar más sencillo encontrar consultas no
optimizadas.
Si es la primera vez que configura parámetros en un grupo de parámetros de base de datos y que asocia
ese grupo de parámetros a una instancia de base de datos, consulte Trabajo con los grupos de parámetros
de base de datos y grupos de parámetros de clúster de base de datos (p. 259)
Los siguientes pasos muestran cómo configurar el registro de consultas:
1. Establezca el parámetro log_statement en all. En el siguiente ejemplo se muestra la información que

se escribe en el archivo postgres.log:
2013-11-05 16:48:56 UTC::@:[2952]:LOG: received SIGHUP, reloading configuration files

2013-11-05 16:48:56 UTC::@:[2952]:LOG: parameter "log_statement" changed to "all"
Al ejecutar una consulta, se escribe información adicional en el archivo postgres.log. En el siguiente

ejemplo se muestra el tipo de información que se escribe en el archivo después de una consulta:
2013-11-05 16:41:07 UTC::@:[2955]:LOG: checkpoint starting: time

2013-11-05 16:41:07 UTC::@:[2955]:LOG: checkpoint complete: wrote 1 buffers (0.3%);
0 transaction log file(s) added, 0 removed, 1 recycled; write=0.000 s, sync=0.003 s,
total=0.012 s; sync files=1, longest=0.003 s, average=0.003 s
2013-11-05 16:45:14 UTC:[local]:master@postgres:[8839]:LOG: statement: SELECT d.datname
as "Name",

491
Registro de llamadas al API de
Amazon RDS con AWS CloudTrail
pg_catalog.pg_get_userbyid(d.datdba) as "Owner",
pg_catalog.pg_encoding_to_char(d.encoding) as "Encoding",
d.datcollate as "Collate",
d.datctype as "Ctype",
pg_catalog.array_to_string(d.datacl, E'\n') AS "Access privileges"
FROM pg_catalog.pg_database d
ORDER BY 1;
2013-11-05 16:45:
2. Establezca el parámetro log_min_duration_statement. En el siguiente ejemplo se muestra la

información que se escribe en el archivo postgres.log cuando se establece el parámetro en 1:
2013-11-05 16:48:56 UTC::@:[2952]:LOG: received SIGHUP, reloading configuration files

2013-11-05 16:48:56 UTC::@:[2952]:LOG: parameter "log_min_duration_statement" changed to
"1"
Cuando se ejecuta una consulta que supera el límite establecido en el parámetro de duración, se
escribe información adicional en el archivo postgres.log. En el siguiente ejemplo se muestra el tipo de
información que se escribe en el archivo después de una consulta:
2013-11-05 16:51:10 UTC:[local]:master@postgres:[9193]:LOG: statement: SELECT

c2.relname, i.indisprimary, i.indisunique, i.indisclustered, i.indisvalid,
pg_catalog.pg_get_indexdef(i.indexrelid, 0, true),
pg_catalog.pg_get_constraintdef(con.oid, true), contype, condeferrable, condeferred,
c2.reltablespace
FROM pg_catalog.pg_class c, pg_catalog.pg_class c2, pg_catalog.pg_index i
LEFT JOIN pg_catalog.pg_constraint con ON (conrelid = i.indrelid AND conindid =
i.indexrelid AND contype IN ('p','u','x'))
WHERE c.oid = '1255' AND c.oid = i.indrelid AND i.indexrelid = c2.oid
ORDER BY i.indisprimary DESC, i.indisunique DESC, c2.relname;
2013-11-05 16:51:10 UTC:[local]:master@postgres:[9193]:LOG: duration: 3.367 ms
2013-11-05 16:51:10 UTC:[local]:master@postgres:[9193]:LOG: statement: SELECT
c.oid::pg_catalog.regclass FROM pg_catalog.pg_class c, pg_catalog.pg_inherits i WHERE
c.oid=i.inhparent AND i.inhrelid = '1255' ORDER BY inhseqno;
2013-11-05 16:51:10 UTC:[local]:master@postgres:[9193]:LOG: statement:
SELECT c.oid::pg_catalog.regclass FROM pg_catalog.pg_class c,
pg_catalog.pg_inherits i WHERE c.oid=i.inhrelid AND i.inhparent = '1255' ORDER BY
c.oid::pg_catalog.regclass::pg_catalog.text;
2013-11-05 16:51:18 UTC:[local]:master@postgres:[9193]:LOG: statement: select proname
from pg_proc;
Registro de llamadas al API de Amazon RDS con

AWS CloudTrail
Amazon RDS está integrado con AWS CloudTrail, un servicio que proporciona un registro de las acciones
realizadas por un usuario, una función o un servicio de AWS en Amazon RDS. CloudTrail captura todas
las llamadas a la API de Amazon RDS como eventos, incluidas las llamadas procedentes de la consola de
Amazon RDS y de las llamadas del código a las API de Amazon RDS. Si crea un registro de seguimiento,
puede habilitar la entrega continua de eventos de CloudTrail a un bucket de Amazon S3, incluidos los
eventos de Amazon RDS. Si no configura un registro de seguimiento, puede ver los eventos más recientes
en la consola de CloudTrail en el Event history (Historial de eventos). Mediante la información que recopila
CloudTrail, se puede determinar la solicitud que se envió a Amazon RDS, la dirección IP desde la que se
realizó la solicitud, quién la realizó, cuándo la realizó y los detalles adicionales.
Para obtener más información sobre CloudTrail, consulte la AWS CloudTrail User Guide.

492
Información de Amazon RDS en CloudTrail
Información de Amazon RDS en CloudTrail

CloudTrail se habilita en una cuenta de AWS al crearla. Cuando se produce una actividad en Amazon
RDS, dicha actividad se registra en un evento de CloudTrail junto con los eventos de los demás servicios
de AWS en el Event history (Historial de eventos). Puede ver, buscar y descargar los últimos eventos de
la cuenta de AWS. Para obtener más información, consulte Visualización de eventos con el historial de
eventos de CloudTrail.
Para mantener un registro continuo de los eventos de la cuenta de AWS, incluidos los eventos de Amazon
RDS, cree un registro de seguimiento. Un registro de seguimiento permite a CloudTrail enviar archivos de
registro a un bucket de Amazon S3. De forma predeterminada, cuando se crea un registro de seguimiento
en la consola, el registro de seguimiento se aplica a todas las regiones. El registro de seguimiento registra
los eventos de todas las regiones de la partición de AWS y envía los archivos de registro al bucket de
Amazon S3 especificado. También puede configurar otros servicios de AWS para analizar y actuar en
función de los datos de eventos recopilados en los registros de CloudTrail. Para obtener más información,
consulte:
• Introducción a la creación de registros de seguimiento

• Servicios e integraciones compatibles con CloudTrail
• Configuración de notificaciones de Amazon SNS para CloudTrail
• Recibir archivos de registro de CloudTrail de varias regiones y Recepción de archivos de registro de
CloudTrail de varias cuentas
Todas las acciones de Amazon RDS las registra CloudTrail y están documentadas en la Amazon RDS
API Reference. Por ejemplo, las llamadas a las acciones CreateDBInstance, ModifyDBInstance y
CreateDBParameterGroup generan entradas en los archivos de registro de CloudTrail.
Cada entrada de registro o evento contiene información acerca de quién generó la solicitud. La información
de identidad del usuario le ayuda a determinar lo siguiente:
• Si la solicitud se realizó con las credenciales raíz o del usuario de IAM.

• Si la solicitud se realizó con credenciales de seguridad temporales de un rol o fue un usuario federado.
• Si la solicitud la realizó otro servicio de AWS.
Para obtener más información, consulte el elemento userIdentity de CloudTrail.
Descripción de las entradas de archivos de registro de

Amazon RDS
Un registro de seguimiento es una configuración que permite la entrega de eventos como archivos de
registro al bucket de Amazon S3 que se especifique. Los archivos de registro de CloudTrail contienen
una o varias entradas de registro. Un evento representa una única solicitud de cualquier origen e incluye
información sobre la acción solicitada, la fecha y la hora de la acción, los parámetros de la solicitud,
etcétera. Los archivos de registro de CloudTrail no son un rastro de la pila ordenada de las llamadas a la
API públicas, por lo que no aparecen en ningún orden específico.
En el ejemplo siguiente, se muestra una entrada de registro de CloudTrail que ilustra la acción
CreateDBInstance.
{
"eventVersion": "1.04",
"userIdentity": {

493
Descripción de las entradas de
archivos de registro de Amazon RDS
"type": "IAMUser",
"principalId": "AKIAIOSFODNN7EXAMPLE",
"arn": "arn:aws:iam::123456789012:user/johndoe",
"accountId": "123456789012",
"accessKeyId": "AKIAI44QH8DHBEXAMPLE",
"userName": "johndoe"
},
"eventTime": "2018-07-30T22:14:06Z",
"eventSource": "rds.amazonaws.com",
"eventName": "CreateDBInstance",
"awsRegion": "us-east-1",
"sourceIPAddress": "72.21.198.65",
"userAgent": "aws-cli/1.15.42 Python/3.6.1 Darwin/17.7.0 botocore/1.10.42",
"requestParameters": {
"enableCloudwatchLogsExports": [
"audit",
"error",
"general",
"slowquery"
],
"dBInstanceIdentifier": "test-instance",
"engine": "mysql",
"masterUsername": "myawsuser",
"allocatedStorage": 20,
"dBInstanceClass": "db.m1.small",
"masterUserPassword": "****"
},
"responseElements": {
"dBInstanceArn": "arn:aws:rds:us-east-1:123456789012:db:test-instance",
"storageEncrypted": false,
"preferredBackupWindow": "10:27-10:57",
"preferredMaintenanceWindow": "sat:05:47-sat:06:17",
"backupRetentionPeriod": 1,
"allocatedStorage": 20,
"storageType": "standard",
"engineVersion": "5.6.39",
"dbInstancePort": 0,
"optionGroupMemberships": [
{
"status": "in-sync",
"optionGroupName": "default:mysql-5-6"
}
],
"dBParameterGroups": [
{
"dBParameterGroupName": "default.mysql5.6",
"parameterApplyStatus": "in-sync"
}
],
"monitoringInterval": 0,
"dBInstanceClass": "db.m1.small",
"readReplicaDBInstanceIdentifiers": [],
"dBSubnetGroup": {
"dBSubnetGroupName": "default",
"dBSubnetGroupDescription": "default",
"subnets": [
{
"subnetAvailabilityZone": {"name": "us-east-1b"},
"subnetIdentifier": "subnet-cbfff283",
"subnetStatus": "Active"
},
{
"subnetAvailabilityZone": {"name": "us-east-1e"},
"subnetIdentifier": "subnet-d7c825e8",
},

494
Descripción de las entradas de
archivos de registro de Amazon RDS
{
"subnetAvailabilityZone": {"name": "us-east-1f"},
"subnetIdentifier": "subnet-6746046b",
},
{
"subnetAvailabilityZone": {"name": "us-east-1c"},
"subnetIdentifier": "subnet-bac383e0",
},
{
"subnetAvailabilityZone": {"name": "us-east-1d"},
"subnetIdentifier": "subnet-42599426",
},
{
"subnetAvailabilityZone": {"name": "us-east-1a"},
"subnetIdentifier": "subnet-da327bf6",
}
],
"vpcId": "vpc-136a4c6a",
"subnetGroupStatus": "Complete"
},
"masterUsername": "myawsuser",
"multiAZ": false,
"autoMinorVersionUpgrade": true,
"engine": "mysql",
"cACertificateIdentifier": "rds-ca-2015",
"dbiResourceId": "db-ETDZIIXHEWY5N7GXVC4SH7H5IA",
"dBSecurityGroups": [],
"pendingModifiedValues": {
"masterUserPassword": "****",
"pendingCloudwatchLogsExports": {
"logTypesToEnable": [
"audit",
"error",
"general",
"slowquery"
]
}
},
"dBInstanceStatus": "creating",
"publiclyAccessible": true,
"domainMemberships": [],
"copyTagsToSnapshot": false,
"dBInstanceIdentifier": "test-instance",
"licenseModel": "general-public-license",
"iAMDatabaseAuthenticationEnabled": false,
"performanceInsightsEnabled": false,
"vpcSecurityGroups": [
{
"status": "active",
"vpcSecurityGroupId": "sg-f839b688"
}
]
},
"requestID": "daf2e3f5-96a3-4df7-a026-863f96db793e",
"eventID": "797163d3-5726-441d-80a7-6eeb7464acd4",
"eventType": "AwsApiCall",
"recipientAccountId": "123456789012"
}

495
Información general de Aurora MySQL
Uso de Amazon Aurora MySQL

Amazon Aurora MySQL es un motor de base de datos relacional completamente administrado y compatible
con MySQL que combina la velocidad y la fiabilidad de las bases de datos comerciales de tecnología
avanzada con la sencillez y la rentabilidad de las bases de datos de código abierto. Aurora MySQL es
un reemplazo instantáneo para MySQL que simplifica y hace más rentable configurar, usar y escalar las
implementaciones de MySQL nuevas y ya existentes, lo que le permitirá centrarse en su negocio y sus
aplicaciones. Amazon RDS proporciona administración para Aurora mediante la gestión de tareas de
base de datos rutinarias como el aprovisionamiento, la aplicación de parches, las copias de seguridad, la
recuperación, la detección de errores y la reparación. Amazon RDS también proporciona herramientas de
migración que le permiten convertir sus aplicaciones de Amazon RDS para MySQL a Aurora MySQL con
un solo botón.
Temas
• Información general de Amazon Aurora MySQL (p. 496)
• Seguridad con Amazon Aurora MySQL (p. 499)
• Migración de datos a un clúster de base de datos de Amazon Aurora MySQL (p. 502)
• Administración de Amazon Aurora MySQL (p. 544)
• Trabajar con Consultas en paralelo de Amazon Aurora MySQL (p. 566)
• Uso de auditorías avanzadas con un clúster de base de datos de Amazon Aurora MySQL (p. 593)
• Replicación con Amazon Aurora MySQL (p. 596)
• Integración de Amazon Aurora MySQL con otros servicios de AWS (p. 629)
• Modo lab de Amazon Aurora MySQL (p. 665)
• Prácticas recomendadas con Amazon Aurora MySQL (p. 667)
• Referencia de Amazon Aurora MySQL (p. 677)
• Actualizaciones del motor de base de datos para Amazon Aurora MySQL (p. 695)
Información general de Amazon Aurora MySQL

En las siguientes secciones, encontrará información general de Amazon Aurora MySQL.
Temas
• Mejoras de desempeño de Amazon Aurora MySQL (p. 496)
• Amazon Aurora MySQL y los datos espaciales (p. 497)
• Comparación de Aurora MySQL 5.6 y Aurora MySQL 5.7 (p. 498)
• Comparación de Aurora MySQL 5.7 y MySQL 5.7 (p. 498)
Mejoras de desempeño de Amazon Aurora MySQL

Amazon Aurora incluye mejoras del desempeño para responder a las distintas necesidades de las bases
de datos comerciales de gama alta.

496
Aurora MySQL y los datos espaciales
Inserción rápida
La inserción rápida acelera las inserciones paralelas ordenadas por clave principal y se aplica
específicamente a las declaraciones LOAD DATA e INSERT INTO ... SELECT .... La inserción rápida
almacena en caché la posición de un cursor en un recorrido del índice mientras se ejecuta la declaración.
Esto evita tener que recorrer el índice de nuevo sin necesidad.
Puede monitorizar las siguientes métricas para determinar la eficacia de la inserción rápida para su clúster
de base de datos:
• aurora_fast_insert_cache_hits: un contador que se incrementa cuando el cursor en caché se

recupera y se verifica correctamente.
• aurora_fast_insert_cache_misses: un contador que se incrementa cuando el cursor en caché
deja de ser válido y Aurora realiza un recorrido normal del índice.
Puede recuperar el valor actual de las métricas de inserción rápida con el siguiente comando:
mysql> show global status like 'Aurora_fast_insert%';
Obtendrá un resultado similar al siguiente:
+---------------------------------+-----------+
| Variable_name | Value |
+---------------------------------+-----------+
| Aurora_fast_insert_cache_hits | 3598300 |
| Aurora_fast_insert_cache_misses | 436401336 |
+---------------------------------+-----------+
Amazon Aurora MySQL y los datos espaciales

Amazon Aurora MySQL admite los mismos tipos de datos espaciales y funciones de relaciones espaciales
que la versión de MySQL equivalente. Por ejemplo, Amazon Aurora MySQL 5.7 admite los mismos tipos de
datos espaciales y funciones de relaciones espaciales que MySQL 5.7.
Aurora MySQL también admite la indexación espacial en tablas de InnoDB, de un modo similar al ofrecido
por MySQL 5.7. La indexación espacial mejora el rendimiento de las consultas que usan datos espaciales
en los conjuntos de datos grandes. Aurora MySQL usa una estrategia de indexación distinta a la de
MySQL, ya que utiliza una curva de llenado espacial en un árbol B en lugar de en un árbol R.
Las siguientes declaraciones en el lenguaje de definición de datos (DDL) se admiten para crear índices en
columnas que usan tipos de datos espaciales.
CREATE TABLE
Puede usar las palabras clave SPATIAL INDEX en una declaración CREATE TABLE para añadir un índice
espacial a una columna en una tabla nueva. A continuación se muestra un ejemplo.
CREATE TABLE test (shape POLYGON NOT NULL, SPATIAL INDEX(shape));
ALTER TABLE
Puede usar las palabras clave SPATIAL INDEX en una declaración ALTER TABLE para añadir un índice
espacial a una columna en una tabla existente. A continuación se muestra un ejemplo.

497
Comparación de Aurora MySQL 5.6 y Aurora MySQL 5.7
ALTER TABLE test ADD SPATIAL INDEX(shape);
CREATE INDEX
Puede usar la palabra clave SPATIAL en una declaración CREATE INDEX para añadir un índice espacial a
una columna en una tabla existente. A continuación se muestra un ejemplo.
CREATE SPATIAL INDEX shape_index ON test (shape);
Comparación de Aurora MySQL 5.6 y Aurora MySQL

5.7
Las siguientes características de Amazon Aurora MySQL en Aurora MySQL 5.6, pero dichas
características no se admiten actualmente en Aurora MySQL 5.7.
• Captura previa de clave asíncrona (AKP). Para obtener más información, consulte Uso de la captura
previa de clave asíncrona en Amazon Aurora (p. 669).
• Combinaciones hash. Para obtener más información, consulte Trabajo con combinaciones hash en
• Funciones nativas para la invocación síncrona de las funciones AWS Lambda. Puede invocar de
forma asíncrona las funciones AWS Lambda desde Aurora MySQL 5.7. Para obtener más información,
consulte Invocación de una función de Lambda con una función nativa de Aurora MySQL (p. 656).
• Agrupación en lotes de análisis. Para obtener más información, consulte Actualizaciones del motor de
base de datos de Aurora MySQL (11/12/2017) (p. 733).
• Migración de datos desde MySQL con un bucket de Amazon S3. Para obtener más información, consulte
Migración de datos desde MySQL con un bucket de Amazon S3 (p. 504).
Actualmente, Aurora MySQL 5.7 no admite las características añadidas en Aurora MySQL versión
1.16 y posteriores. Para obtener información acerca de la versión 1.16 de Aurora MySQL, consulte
Actualizaciones del motor de base de datos de Aurora MySQL (11/12/2017) (p. 733).
El esquema de rendimiento no está disponible para la versión anterior de Aurora MySQL 5.7. Actualice a
Aurora 2.03 o posteriores para obtener compatibilidad con el esquema de rendimiento.
Comparación de Aurora MySQL 5.7 y MySQL 5.7

Las siguientes características se admiten en MySQL 5.7.12 pero no se admiten actualmente en Aurora
MySQL 5.7:
• Identificadores de transacciones globales (GTID)

• Complemento de replicación de grupo
• Tamaño de página incrementado
• Carga de grupo de búfer de InnoDB al inicio
• Complemento de analizador de texto completo de InnoDB
• Replicación de varios orígenes
• Cambio de tamaño de grupo de búfer online
• Complemento de validación de contraseñas
• Complementos de reescritura de consulta

498
Seguridad con Aurora MySQL
• Filtrado de replicación
• La instrucción SQL CREATE TABLESPACE
• Protocolo X
Para obtener más información sobre estas características, consulte la documentación de MySQL 5.7.
Seguridad con Amazon Aurora MySQL

La seguridad de Amazon Aurora MySQL se administra en tres niveles:
de datos e instancias de base de datos Aurora MySQL, se usa AWS Identity and Access Management
(IAM). Cuando se conecta a AWS con credenciales de IAM, la cuenta de IAM debe tener políticas de
IAM que otorguen los permisos necesarios para realizar operaciones de administración de Amazon
RDS. Para obtener más información, consulte Administración de identidad y acceso en Amazon
Aurora (p. 163).
sesión primero en la Consola de administración de AWS con su cuenta de IAM. Luego, vaya a la consola
de Amazon RDS en https://console.aws.amazon.com/rds.
• Los clústeres de base de datos Aurora MySQL se deben crear en una Amazon Virtual Private Cloud
(VPC). Para controlar qué dispositivos e instancias Amazon EC2 pueden abrir conexiones al punto de
enlace y al puerto de la instancia de base de datos los clústeres de base de datos Aurora MySQL en una
VPC, debe usar un grupo de seguridad de VPC. Las conexiones con el punto de enlace y el puerto se
pueden realizar por medio de la Capa de conexión segura (SSL). Además, las reglas del firewall de su
compañía pueden controlar si los dispositivos que se ejecutan en ella pueden abrir conexiones a una
instancia de base de datos. Para obtener más información acerca de las VPC, consulte VPC Amazon
Virtual Private Cloud y Amazon Aurora (p. 211).
La tenencia de VPC admitida depende de la clase de instancia usada por los clústeres de base de
datos de Aurora MySQL. En el caso de la tenencia de VPC default, la VPC se ejecuta en hardware
compartido. En el caso de la tenencia de VPC dedicated, la VPC se ejecuta en una instancia de
hardware dedicada. Aurora MySQL admite la siguiente tenencia de VPC dependiendo de la clase de
instancia:
• Las clases de instancia db.r3 admiten la tenencia de VPC default y dedicated.
• Las clases de instancia db.r4 admiten únicamente la tenencia de VPC default.
• Las clases de instancia db.r2 admiten únicamente la tenencia de VPC default.
Para obtener más información sobre las clases de instancias, consulte Selección de la clase de instancia
de base de datos (p. 61). Para obtener más información acerca de la tenencia de VPC default y
dedicated, consulte Instancias dedicadas en la Guía del usuario de Amazon Elastic Compute Cloud.
• Para autenticar el inicio de sesión y los permisos de un clúster de base de datos de Amazon Aurora
MySQL, puede usar cualquiera de los siguientes procedimientos o una combinación de ellos:
• Puede seguir el mismo procedimiento que con una instancia independiente de MySQL.
Los comandos como CREATE USER, RENAME USER, GRANT, REVOKE y SET PASSWORD funcionan de
la misma forma que en las bases de datos locales, al igual que la modificación directa de las tablas
de los esquemas de las bases de datos. Para obtener más información, consulte Administración de
cuentas de usuario de MySQL en la documentación de MySQL.
• También puede utilizar la autenticación de base de datos de IAM.
Con la autenticación de bases de datos de IAM, se autentica en el clúster de base de datos con un
usuario o un rol de IAM y un token de autenticación. Un token de autenticación es un valor único que
499
Privilegios de la cuenta de usuario
maestro con Aurora MySQL
se genera utilizando el proceso de firma Signature Version 4. Al utilizar la autenticación de base de

datos de IAM, puede usar las mismas credenciales para controlar el acceso a los recursos de AWS
y a sus bases de datos. Para obtener más información, consulte Autenticación de bases de datos de
IAM (p. 180).
Privilegios de la cuenta de usuario maestro con

Amazon Aurora MySQL
Cuando se crea una instancia de base de datos de Amazon Aurora MySQL, el usuario maestro tiene los
siguientes privilegios predeterminados:
• ALTER
• ALTER ROUTINE
• CREATE
• CREATE ROUTINE
• CREATE TEMPORARY TABLES
• CREATE USER
• CREATE VIEW
• DELETE
• DROP
• EVENT
• EXECUTE
• GRANT OPTION
• INDEX
• INSERT
• LOAD FROM S3
• LOCK TABLES
• PROCESS
• REFERENCES
• RELOAD
• REPLICATION CLIENT
• REPLICATION SLAVE
• SELECT
• SHOW DATABASES
• SHOW VIEW
• TRIGGER
• UPDATE
Para proporcionar servicios de administración para cada clúster de base de datos, se crea el usuario
rdsadmin cuando se crea el clúster de base de datos. Al intentar borrar, cambiar de nombre, modificar la
contraseña o cambiar los privilegios de la cuenta rdsadmin, se producirá un error.
Para la administración del clúster de base de datos Aurora MySQL, los comandos estándar kill
y kill_query se han restringido. En su lugar, use los comandos de Amazon RDS rds_kill y

500
Uso de SSL con clústeres de
base de datos de Aurora MySQL
rds_kill_query para terminar las consultas o las sesiones de usuario en las instancias de base de
datos Aurora MySQL.
Note
El cifrado de instantáneas de una instancia de base de datos no se admite en la región China

(Ningxia).

MySQL
Los clústeres de base de datos Amazon Aurora MySQL admiten conexiones de Capa de conexión segura
(SSL) desde aplicaciones con el mismo proceso y la misma clave pública que las instancias de base de
datos de Amazon RDS MySQL.
Amazon RDS crea un certificado de SSL e instala el certificado en la instancia de base de datos cuando
Amazon RDS aprovisiona la instancia. Estos certificados están firmados por una autoridad de certificación.
El certificado SSL incluye el punto de enlace de la instancia de base de datos como nombre común (CN)
que el certificado de SSL debe proteger frente a los ataques de suplantación. Como resultado, solo puede
usar el punto de enlace de clúster de base de datos para conectarse a un clúster de base de datos con
SSL si su cliente admite nombres alternativos de firmante (SAN). De lo contrario, tendrá que usar el punto
de enlace de la instancia principal.
Aurora MySQL 5.6 admite Transport Layer Security (TLS), versión 1.0. Aurora MySQL 5.7 admite TLS,
versión 1.0, 1.1 y 1.2.
Recomendamos MariaDB Connector/J como cliente que admite SAN con SSL. Para obtener más
información, consulte la página de descargas de MariaDB Connector/J.
La clave pública está almacenada en https://s3.amazonaws.com/rds-downloads/rds-combined-ca-

bundle.pem.
Para cifrar las conexiones utilizando el cliente mysql predeterminado, lance el cliente mysql utilizando --
ssl-ca parameter para hacer referencia a la clave pública. Por ejemplo:
Para MySQL 5.7 y versiones posteriores:
mysql -h myinstance.c9akciq32.rds-us-east-1.amazonaws.com
--ssl-ca=[full path]rds-combined-ca-bundle.pem --ssl-mode=VERIFY_IDENTITY
Para MySQL 5.6 y versiones anteriores:
mysql -h myinstance.c9akciq32.rds-us-east-1.amazonaws.com
--ssl-ca=[full path]rds-combined-ca-bundle.pem --ssl-verify-server-cert
Puede exigir conexiones SSL para determinadas cuentas de usuarios. Por ejemplo, puede utilizar una de
las siguientes declaraciones, dependiendo de su versión de MySQL, para exigir el uso de conexiones SSL
en la cuenta de usuario encrypted_user.
Para MySQL 5.7 y versiones posteriores:
ALTER USER 'encrypted_user'@'%' REQUIRE SSL;

501
Migración de datos a Aurora MySQL
Para MySQL 5.6 y versiones anteriores:
GRANT USAGE ON *.* TO 'encrypted_user'@'%' REQUIRE SSL;
Note
Para obtener más información acerca de las conexiones SSL con MySQL, consulte la

de Amazon Aurora MySQL
Tiene varias opciones para migrar datos desde una base de datos existente a un clúster de base de datos
MySQL en Amazon Aurora. Las opciones de migración dependen también de la base de datos desde la
que se realiza la migración y del tamaño de los datos que se van a migrar.
Existen dos tipos de trabajos distintos de migración: física y lógica. La migración física supone que las
copias físicas de archivos de base de datos se utilizan para migrar la base de datos. La migración lógica
supone que la migración se lleva a cabo aplicando cambios lógicos en la base de datos, tales como
inserciones, actualizaciones y eliminaciones.
La migración física tiene las siguientes ventajas:
• La migración física es más rápida que la migración lógica, especialmente para bases de datos grandes.
• El desempeño de la base de datos no sufre cuando se toma un backup para migración física.
• La migración física puede migrar todo en la base de datos origen, incluidos componentes de base de
datos complejos.
La migración física tiene las siguientes limitaciones:
• El parámetro innodb_page_size se debe establecer en su valor predeterminado (16KB).

• El innodb_data_file_path debe estar configurado con el nombre de archivo de datos
predeterminado "ibdata1". A continuación se muestran ejemplos de nombres de archivo no
permitidos: "innodb_data_file_path=ibdata1:50M; ibdata2:50M:autoextend" y
"innodb_data_file_path=ibdata01:50M:autoextend".
• El parámetro innodb_log_files_in_group se debe establecer en su valor predeterminado (2).
La migración lógica tiene las siguientes ventajas:
• Puede migrar subconjuntos de la base de datos, tales como tablas específicas o partes de una tabla.
• Los datos se pueden migrar con independencia de la estructura de almacenamiento físico.
La migración lógica tiene las siguientes limitaciones:
• La migración lógica es habitualmente más lenta que la migración física.

• Los componentes de base de datos complejos pueden ralentizar el proceso de migración lógica. En
algunos casos, los componentes de base de datos complejos pueden incluso bloquear la migración
lógica.

502
Migración de datos a Aurora MySQL
En la siguiente tabla se describen sus opciones y el tipo de migración para cada opción.
Migrar desde Tipo de migración Solución
Una instancia de base de Física Puede migrar desde una instancia de base
datos MySQL en Amazon de datos MySQL en RDS creando primero
RDS una réplica de lectura de Aurora MySQL
de una instancia de base de datos MySQL.
Cuando el retardo de la réplica entre la
instancia de base de datos MySQL y la
réplica de lectura de Aurora MySQL sea 0,
podrá indicar a las aplicaciones de cliente
que lean de la réplica de lectura de Aurora
y, a continuación, detener la replicación
para convertir la réplica de lectura de
Aurora MySQL en un clúster de base de
datos de Aurora MySQL independiente
para lectura y escritura. Para obtener más
información, consulte Migración de datos
desde una instancia de base de datos
MySQL a un clúster de base de datos de
Amazon Aurora MySQL con una réplica de
lectura de Aurora (p. 533).
Una instantánea de base de Física Puede migrar datos directamente a partir

datos MySQL de RDS de una instantánea de base de datos de
Amazon RDS MySQL a un clúster de
base de datos de Amazon Aurora MySQL.
Para obtener más información, consulte
Migración de datos desde una instancia
de base de datos MySQL a un clúster
de base de datos de Amazon Aurora
MySQL con una instantánea de base de
datos (p. 526).
Una base de datos MySQL Lógica Puede crear un volcado de los datos con
externa a Amazon RDS la utilidad mysqldump y, a continuación,
importar esos datos a un clúster de base
de datos de Amazon Aurora MySQL.
Migración de MySQL a Amazon Aurora con
mysqldump (p. 526).
Una base de datos MySQL Física Puede copiar los archivos de copia de
externa a Amazon RDS seguridad de la base de datos en un
bucket de Amazon Simple Storage Service
(Amazon S3) y, a continuación, restaurar
un clúster de base de datos de Amazon
Aurora MySQL a partir de esos archivos.
Esta opción puede ser bastante más rápida
que migrar los datos con mysqldump.
Migración de datos desde MySQL con un
bucket de Amazon S3 (p. 504).
Una base de datos MySQL Lógica Puede guardar los datos de la base de
externa a Amazon RDS datos como archivos de texto y copiar
esos archivos en un bucket de Amazon

503
Migración de una base de datos
MySQL externa a Aurora MySQL
Migrar desde Tipo de migración Solución

S3. A continuación, puede cargar esos
datos en un clúster de base de datos de
Aurora MySQL con el comando LOAD
DATA FROM S3 de MySQL. Para obtener
más información, consulte Carga de datos
en un clúster de base de datos Amazon
Aurora MySQL desde archivos de texto en
un bucket de Amazon S3 (p. 641).
Una bases de datos que no Lógica Puede utilizar AWS Database Migration
sea compatible con MySQL Service (AWS DMS) para migrar datos
desde una base de datos que no sea
compatible con MySQL. Para obtener
más información acerca de AWS DMS,
consulte ¿Qué es AWS Database Migration
Service?
Note
• Si está migrando una base de datos de MySQL externa a Amazon RDS, las opciones de
migración descritas en la tabla solo se admiten si su base de datos admite los espacios de tabla
InnoDB o MyISAM.
• Si la base de datos MySQL que va a migrar a Aurora MySQL usa memcached, quite
memcached antes de migrarla.
Migración de datos desde una base de datos MySQL

externa a un clúster de base de datos de Amazon
Aurora MySQL
Si la base de datos admite espacios de tablas InnoDB o MyISAM, dispone de estas opciones para migrar
los datos a un clúster de base de datos de Amazon Aurora MySQL:
• Puede crear un volcado de los datos con la utilidad mysqldump y, a continuación, importar esos datos
a un clúster de base de datos de Amazon Aurora MySQL. Para obtener más información, consulte
Migración de MySQL a Amazon Aurora con mysqldump (p. 526).
• Puede copiar los archivos de copia de seguridad completos e incrementales de la base de datos en
un bucket de Amazon S3 y, a continuación, restaurar un clúster de base de datos de Amazon Aurora
MySQL a partir de dichos archivos. Esta opción puede ser bastante más rápida que migrar los datos con
mysqldump. Para obtener más información, consulte Migración de datos desde MySQL con un bucket
de Amazon S3 (p. 504).
Migración de datos desde MySQL con un bucket de Amazon S3

Puede copiar los archivos de copia de seguridad completos e incrementales de la base de datos MySQL
5.5, 5.6 o 5.7 de origen en un bucket de Amazon S3 y, a continuación, restaurar un clúster de base de
datos de Amazon Aurora MySQL a partir de esos archivos.
Esta opción puede ser bastante más rápida que migrar datos mediante mysqldump, ya que mysqldump
repite todos los comandos para volver a crear el esquema y los datos a partir de la base de datos origen en

504
el nuevo clúster de base de datos de Aurora MySQL. Al copiar los archivos de datos de MySQL de origen,
Aurora MySQL puede utilizar inmediatamente esos archivos como datos para el clúster de base de datos
de Aurora MySQL.
Note
El bucket de Amazon S3 y el clúster de base de datos de Amazon Aurora MySQL deben estar en
la misma región de AWS.
Aurora MySQL no restaura todo lo que contiene la base de datos. Debe guardar el esquema y los valores
de la base de datos correspondientes a los siguientes elementos de la base de datos MySQL de origen y
añadirlos al clúster de base de datos de Aurora MySQL restaurado una vez creado:
• Cuentas de usuario
• Funciones
• Procedimientos almacenados
• Información de zona horaria. Esta información se carga desde el sistema operativo local del clúster de
base de datos de Amazon Aurora MySQL. Para obtener más información, consulte Zona horaria local
para los clústeres de base de datos Amazon Aurora (p. 68).
Pude cifrar los datos que se van a migrar o dejar los datos sin cifrar durante el proceso de migración.
Además, decida si desea reducir el tiempo de inactividad mediante el uso de la replicación de logs binarios
durante el proceso de migración. Si usa la replicación de logs binarios, la base de datos MySQL externa
permanece abierta a las transacciones mientras se migran los datos al clúster de base de datos de Aurora
MySQL. Una vez creado el clúster de base de datos de Aurora MySQL, se usa la replicación de registros
binarios para sincronizar el clúster de base de datos de Aurora MySQL con las transacciones que han
tenido lugar después de la copia de seguridad. Cuando el clúster de base de datos de Aurora MySQL DB
esté sincronizado con la base de datos MySQL, se termina la migración y se produce el cambio al clúster
de base de datos de Aurora MySQL para las nuevas transacciones.
Temas
• Antes de comenzar (p. 505)
• Ejecución de backups de archivos para restaurarlos como un clúster de base de datos de Amazon
Aurora MySQL (p. 507)
• Restauración de un clúster de base de datos de Amazon Aurora MySQL desde un bucket de Amazon
S3 (p. 509)
• Sincronización del clúster de base de datos de Amazon Aurora MySQL con la base de datos MySQL
mediante replicación (p. 520)
Antes de comenzar
Antes de copiar los datos en un bucket de Amazon S3 y restaurar un clúster de base de datos a partir de
esos archivos, debe hacer lo siguiente:
• Instale Percona XtraBackup en su servidor local.

• Permita que Aurora MySQL obtenga acceso a su bucket de Amazon S3 en su nombre.
Instalación de Percona XtraBackup
Amazon Aurora puede restaurar un clúster de base de datos a partir de archivos creados con Percona
XtraBackup. Puede instalar Percona XtraBackup desde el artículo acerca de cómo descargar Percona
XtraBackup.

505
Note
Para la migración de MySQL 5.7, debe usar Percona XtraBackup 2.4. Para versiones anteriores
de MySQL, utilice Percona XtraBackup 2.3 o 2.4.
Permisos necesarios
Para migrar los datos de MySQL a un clúster de base de datos de Amazon Aurora MySQL, se requieren
varios permisos:
• El usuario que solicita que Amazon RDS cree un nuevo clúster a partir de un bucket de Amazon S3 debe
tener permiso para enumerar los buckets de su cuenta de AWS. Puede otorgar este permiso al usuario
mediante una política de AWS Identity and Access Management (IAM).
• Amazon RDS requiere permiso para realizar acciones en su nombre y obtener acceso al bucket de
Amazon S3 en el que se almacenan los archivos utilizados para crear el clúster de base de datos de
Amazon Aurora MySQL. Puede otorgar los permisos necesarios a Amazon RDS mediante un rol de
servicio de IAM.
• El usuario que realiza la solicitud también debe tener permiso para enumerar los roles de IAM para la
cuenta de AWS.
• Si el usuario que ha realizado la solicitud va a crear el rol de servicio de IAM o va a solicitar que Amazon
RDS cree el rol de servicio de IAM (mediante la consola), entonces necesitará permiso para crear un rol
de IAM para la cuenta de AWS.
• Si tiene previsto cifrar los datos durante el proceso de migración, actualice la política de IAM del usuario
que va a realizar la migración para conceder a RDS acceso a las claves de KMS para cifrar los backups.
Para obtener instrucciones, consulte Creación de una política de IAM para acceder a los recursos de
AWS KMS (p. 635).
Por ejemplo, la siguiente política de IAM otorga a un usuario los permisos mínimos necesarios para usar
la consola para mostrar los roles de IAM, crear un rol de IAM, mostrar los buckets de Amazon S3 de la
cuenta y mostrar las claves de KMS.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"iam:ListRoles",
"iam:CreateRole",
"iam:CreatePolicy",
"iam:AttachRolePolicy",
"s3:ListBucket",
"s3:ListObjects"
"kms:ListKeys"
],
"Resource": "*"
}
]
}
Además, para que un usuario pueda asociar un rol de IAM a un bucket de Amazon S3, el usuario de IAM
debe disponer del permiso iam:PassRole para ese rol de IAM. Este permiso hace que un administrador
pueda restringir los roles de IAM que un usuario puede asociar a buckets de Amazon S3.
Por ejemplo, la siguiente política de IAM permite a un usuario asociar el rol denominado S3Access a un
bucket de Amazon S3.

506
"Version":"2012-10-17",
"Statement":[
{
"Sid":"AllowS3AccessRole",
"Effect":"Allow",
"Action":"iam:PassRole",
"Resource":"arn:aws:iam::123456789012:role/S3Access"
}
]
}
Para obtener más información sobre los permisos de usuario de IAM, consulte Administración de acceso
mediante políticas (p. 165).
Creación del rol de servicio de IAM

Puede hacer que la Consola de administración de AWS cree un rol para usted eligiendo la opción Create
a New Role (Crear una función) (se explica más adelante en este tema). Si selecciona esta opción y
especifica un nombre para el nuevo rol, Amazon RDS crea el rol de servicio de IAM necesario para que
Amazon RDS obtenga acceso al bucket de Amazon S3 con el nombre que usted indique.
Como alternativa, puede crear el rol manualmente completando el siguiente procedimiento.
Para crear un rol de IAM para que Amazon RDS pueda obtener acceso a Amazon S3
1. Realice los pasos que se indican en Creación de una política de IAM para acceder a los recursos de
Amazon S3 (p. 630).
2. Realice los pasos que se indican en Creación de un rol de IAM que permita a Amazon Aurora acceder
a los servicios de AWS (p. 635).
3. Realice los pasos que se indican en Asociación de un rol de IAM con un clúster de base de datos
Amazon Aurora MySQL (p. 636).
Ejecución de backups de archivos para restaurarlos como un clúster de base de

datos de Amazon Aurora MySQL
Puede crear un backup completo de los archivos de la base de datos MySQL usando Percona XtraBackup
y cargar los archivos de backup en un bucket de Amazon S3. Como alternativa, si ya usa Percona
XtraBackup para realizar los backups de los archivos de la base de datos MySQL, puede cargar los
archivos y los directorios de backup completos e incrementales en un bucket de Amazon S3.
Creación de una copia de seguridad completa con Percona XtraBackup

Para crear una copia de seguridad completa de los archivos de la base de datos MySQL que se puedan
restaurar desde Amazon S3 para crear un clúster de base de datos de Amazon Aurora MySQL, use la
utilidad Percona XtraBackup (xtrabackup) para realizar una copia de seguridad de la base de datos.
Por ejemplo, el siguiente comando crea un backup de una base de datos MySQL y almacena los archivos
en la carpeta /on-premises/s3-restore/backup.
xtrabackup --backup --user=<myuser> --password=<password> --target-dir=</on-premises/s3-

restore/backup>
Si desea comprimir su backup en un solo archivo (que se puede dividir si es necesario), puede utilizar la
opción --stream para guardar el backup en uno de los siguientes formatos:
• Gzip (.gz)
• tar (.tar)
• Percona xbstream (.xbstream)

507
El siguiente comando crea una copia de seguridad de la base de datos MySQL dividido en varios archivos
Gzip.
xtrabackup --backup --user=<myuser> --password=<password> --stream=tar \

--target-dir=</on-premises/s3-restore/backup> | gzip - | split -d --bytes=500MB \
- </on-premises/s3-restore/backup/backup>.tar.gz
tar.
xtrabackup --backup --user=<myuser> --password=<password> --stream=tar \

--target-dir=</on-premises/s3-restore/backup> | split -d --bytes=500MB \
- </on-premises/s3-restore/backup/backup>.tar
xbstream.
xtrabackup --backup --user=<myuser> --password=<password> --stream=xbstream \

--target-dir=</on-premises/s3-restore/backup> | split -d --bytes=500MB \
- </on-premises/s3-restore/backup/backup>.xbstream
Una vez realizado el backup de la base de datos MySQL con la utilidad Percona XtraBackup, ya podrá
copiar los directorios y los archivos del backup en un bucket de Amazon S3.
Para obtener más información acerca de cómo crear y cargar un archivo en un bucket de Amazon S3,
consulte Introducción a Amazon Simple Storage Service en la Guía de introducción a Amazon S3.
Uso de copias de seguridad incrementales con Percona XtraBackup
Amazon Aurora MySQL admite backups completos e incrementales creados con Percona XtraBackup. Si
ya usa Percona XtraBackup para realizar copias de seguridad completas e incrementales de sus archivos
de base de datos MySQL, no tiene que crear una copia de seguridad completa y cargar los archivos del
backup en Amazon S3. En lugar de eso, puede ahorrar una cantidad considerable de tiempo copiando los
directorios y archivos de backup de sus backups completos e incrementales en un bucket de Amazon S3.
Para obtener más información acerca de la creación de copias de seguridad incrementales con Percona
XtraBackup, consulte el artículo acerca de la copia de seguridad incremental.
Cuando copie los archivos de backup completos o incrementales en un bucket de Amazon S3, debe
copiar repetidamente el contenido del directorio base. Esos contenidos incluyen el backup completo y
también todos los directorios y archivos del backup incremental. Esta copia debe mantener la estructura
de directorios en el bucket de Amazon S3. Aurora realiza iteraciones por todos los archivos y directorios.
Aurora utiliza el archivo xtrabackup-checkpoints incluido con cada copia de seguridad incremental
para identificar el directorio base y ordenar las copias de seguridad incrementales por rango del número de
secuencia del registro (LSN).
Para obtener más información acerca de cómo crear y cargar un archivo en un bucket de Amazon S3,
consulte Introducción a Amazon Simple Storage Service en la Guía de introducción a Amazon S3.
Consideraciones sobre backups
Cuando carga un archivo en un bucket de Amazon S3, puede usar el cifrado del lado del servidor para
cifrar los datos. A continuación, puede restaurar un clúster de base de datos de Amazon Aurora MySQL a
partir de estos archivos cifrados. Amazon Aurora MySQL puede restaurar un clúster de base de datos de
con archivos cifrados usando los siguientes tipos de cifrado del lado del servidor:
• Cifrado en el servidor con claves de cifrado administradas por Amazon S3 (SSE-S3): cada objeto está
cifrado con una clave exclusiva que utiliza un cifrado multifactor seguro.

508
• Cifrado en el servidor con claves administradas por AWS KMS (SSE-KMS): similar a SSE-S3, pero tiene
la opción de crear y administrar usted mismo las claves de cifrado, así como otras diferencias.
Para obtener información sobre cómo usar el cifrado en el servidor al cargar archivos en un bucket
de Amazon S3, consulte Protección de datos con el cifrado del lado del servidor en la Guía para
desarrolladores de Amazon S3.
Amazon S3 limita el tamaño de un archivo cargado en un bucket de Amazon S3 a 5 terabytes (TB). Si los
datos del backup de su base de datos superan los 5 TB, use el comando split para dividir los archivos
de backup en varios archivos que ocupen menos de 5 TB.
Amazon RDS limita el número de archivos de origen cargados en un bucket de Amazon S3 a 1 millón de
archivos. En algunos casos, los datos de backup de su base de datos con todos los backups completos
e incrementales incluyen un número elevado de archivos. En estos casos, usa un archivo tarball (.tar.gz)
para almacenar los archivos de backups completos e incrementales en el bucket de Amazon S3.
Aurora consume sus archivos de copia de seguridad en función del nombre de archivo. Asegúrese de
asignar la extensión de archivo adecuada a los archivos de copia de seguridad según el formato de
archivo: por ejemplo, .xbstream para archivos almacenados con el formato xbstream de Percona.
Aurora consume sus archivos de backup en orden alfabético, así como según la numeración natural. Utilice
siempre la opción split al ejecutar el comando xtrabackup para asegurarse de que la escritura y la
asignación de nombre de sus archivos de backup se realice en el orden correcto.
Aurora no admite copias de seguridad parciales creados con Percona XtraBackup. No puede utilizar
las siguientes opciones para crear una copia de seguridad parcial al realizar copias de seguridad de
los archivos de origen de su base de datos: --tables, --tables-exclude, --tables-file, --
databases, --databases-exclude o --databases-file.
Para obtener más información acerca de cómo realizar una copia de seguridad de su base de datos con
Percona XtraBackup, consulte la documentación de Percona XtraBackup y el artículo sobre el archivo
binario xtrabackup en el sitio web de Percona.
Aurora admite copias de seguridad incrementales creadas con Percona XtraBackup. Para obtener más
información acerca de la creación de copias de seguridad incrementales con Percona XtraBackup,
consulte el artículo acerca de la copia de seguridad incremental.
Restauración de un clúster de base de datos de Amazon Aurora MySQL desde un

bucket de Amazon S3
Puede restaurar los archivos de copia de seguridad desde el bucket de Amazon S3 para crear un nuevo
clúster de base de datos de Amazon Aurora MySQL mediante la consola de Amazon RDS.
Para restaurar un clúster de base de datos de Amazon Aurora MySQL a partir de los archivos de
un bucket de Amazon S3
2. En la esquina superior derecha de la consola de Amazon RDS, elija la región de AWS en la que se va
a crear su clúster de base de datos. Elija la misma región de AWS que el bucket de Amazon S3 que
contiene su backup de base de datos.
3. En el panel de navegación, elija Databases (Bases de datos) y después Restore from S3 (Restaurar
desde S3).
4. En la página Select engine (Seleccionar motor), elija Amazon Aurora y, a continuación, la edición
compatible con MySQL y finalmente Next (Siguiente).
Aparecerá la página Specify source backup details (Especificar detalles de copia de seguridad de
origen).

509
5. En Specify source backup details (Especificar detalles de copia de seguridad de origen), especifique lo
siguiente.
Source engine (Motor de origen) Aurora MySQL solo admite actualmente la restauración a
partir de archivos de copia de seguridad para el motor de
base de datos mysql.
Source engine version (Versión de Elija la versión de MySQL de su base de datos de origen.
motor de origen)
S3 bucket Elija el bucket de Amazon S3 que contiene sus archivos de

backup.
S3 folder path prefix (optional) (Prefijo Especifique un prefijo de ruta de archivo para los archivos
de ruta de la carpeta de S3 [opcional]) almacenados en el bucket de Amazon S3. S3 Bucket Prefix
(Prefijo de bucket de S3) es opcional. Si no especifica un
prefijo, Aurora MySQL creará el clúster de base de datos
con todos los archivos y carpetas de la carpeta raíz del
bucket de Amazon S3. Si especifica un prefijo, Aurora

510

MySQL creará el clúster de base de datos con los archivos
y carpetas del bucket de Amazon S3 cuya ruta completa
del archivo empieza con el prefijo especificado.
Aurora no recorre otras subcarpetas del bucket de Amazon

S3 en busca de archivos de copia de seguridad. Solo se
usan los archivos de la carpeta identificados por S3 Bucket
Prefix (Prefijo de bucket de S3). Si almacena los archivos
de backup en una subcarpeta del bucket de Amazon S3,
especifique un prefijo que identifique la ruta completa hasta
la carpeta donde se almacenan los archivos.
Por ejemplo, suponga que almacena los archivos de

copia de seguridad en una subcarpeta de su bucket de
Amazon S3 llamada backups. Suponga también que
tiene varios conjuntos de archivos de backup, cada uno
en su propio directorio (gzip_backup1, gzip_backup2,
etc.). En este caso, debe especificar el prefijo backups/
gzip_backup1 para restaurar a partir de los archivos de
la carpeta gzip_backup1.
Create a new role (Crear un nuevo rol) Elija Yes (Sí) para crear un nuevo rol de IAM o No para
seleccionar un rol de IAM existente para otorgar acceso
a Aurora a Amazon S3 en su nombre. Para obtener más
información, consulte Permisos necesarios (p. 506).
IAM role name (Nombre de rol de IAM) Esta opción solo está disponible si Create a new role
(Crear un nuevo rol) se ha definido como Yes (Sí).
Especifique el nombre de la nueva función de IAM que

desea crear. El nuevo rol se utiliza para autorizar a
Amazon Aurora a obtener acceso a Amazon S3 en su
nombre. Para obtener más información, consulte Permisos
necesarios (p. 506).
Rol de IAM Esta opción solo está disponible si Create a new role
(Crear nuevo rol) se ha definido en No.
Seleccione el rol de IAM que creó para otorgar acceso a

Aurora a Amazon S3 en su nombre. Si no ha creado un
rol de IAM, puede definir Create a New Role (Crear un
nuevo rol) como Yes (Sí) para crear uno. Para obtener más
información, consulte Permisos necesarios (p. 506).

511
Permitir el acceso a una clave de KMS Esta opción solo está disponible si Create a new role
(Crear un nuevo rol) se ha definido como Yes (Sí).
Si no ha cifrado los archivos de copia de seguridad, elija

No.
Si ha cifrado los archivos de copia de seguridad con

AES-256 (SSE-S3) al cargarlos en Amazon S3, elija No. En
este caso, los datos se descifran automáticamente.
Si ha cifrado los archivos de copia de seguridad con el

cifrado en el servidor AWS-KMS (SSE-KMS) al cargarlos
en Amazon S3, elija Yes (Sí). A continuación, elija la
clave maestra correcta en Master key (Clave maestra). La
Consola de administración de AWS crea una política de
IAM que permite a Amazon RDS descifrar los datos.
Para obtener más información, consulte Protección de

datos con el cifrado del lado del servidor en la Guía para
desarrolladores de Amazon S3.
6. Seleccione Siguiente.
7. En la página Specify DB Details (Especificar detalles de la base de datos), especifique la información
de su clúster de base de datos.
Una página Specify DB details (Especificar detalles de la base de datos) típica tiene un aspecto similar
al siguiente.

512
La siguiente tabla muestra la configuración de una instancia de base de datos.

513
Capacity type (Tipo de capacidad) Elija Provisioned (Aprovisionado) para administrar

manualmente la capacidad de la instancia de base de
datos. Es posible que tenga que cambiar la clase de la
instancia de base de datos si cambia la carga de trabajo.
Elija Provisioned with Aurora paralela query enabled

(Aprovisionado con la consulta en paralelo de Aurora
habilitado) para administrar manualmente la capacidad
de la instancia de base de datos. Con esta opción,
Aurora mejora el rendimiento de las consultas analíticas
mediante el traslado del procesamiento a la capa de
almacenamiento de Aurora (actualmente disponible
para Aurora MySQL 5.6). Para obtener más información,
consulte Trabajar con Consultas en paralelo de Amazon
Elija Serverless (Sin servidor) para que Aurora administre

automáticamente la capacidad disponible para la instancia
Uso de Amazon Aurora Serverless (p. 100).
DB engine version (Versión del motor Solo se aplica al tipo de capacidad aprovisionada. Elija el
de base de datos) número de versión del motor de base de datos.
DB instance class Seleccione una clase de instancia de base de datos que

defina los requisitos de procesamiento y memoria para
cada instancia del clúster de base de datos. Para obtener
más información acerca de las clases de instancias de
bases de datos, consulte Selección de la clase de instancia
de base de datos (p. 61).
Multi-AZ Deployment (Implementación Determine si desea crear réplicas de Aurora en otras zonas
Multi-AZ) de disponibilidad para permitir la conmutación por error. Si
selecciona Create Replica in Different Zone (Crear réplica
en otra zona), Amazon RDS crea una réplica de Aurora en
su clúster de base de datos en una zona de disponibilidad
diferente de la instancia principal del clúster de base
de datos. Para obtener más información acerca del uso
de varias zonas de disponibilidad, consulte Elección de
Regiones y zonas de disponibilidad (p. 64).

514
DB Instance Identifier (Identificador de Escriba un nombre para la instancia principal de su

instancias de bases de datos) clúster de base de datos. Este identificador se utiliza en la
dirección del punto de enlace de la instancia principal de su


guiones.
consecutivos.
datos por cada cuenta de AWS y por región de AWS.
Master username Escriba un nombre con caracteres alfanuméricos para

utilizarlo como nombre de usuario maestro para iniciar
sesión en su clúster de base de datos.
Contraseña maestra Escriba una contraseña que contenga entre 8 y 41

caracteres ASCII imprimibles (excepto /, " y @) para su
contraseña de usuario maestro.
8. Seleccione Siguiente.
9. En la página Configure Advanced Settings (Configurar ajustes avanzados), puede personalizar la
configuración adicional para su clúster de base de datos de Aurora MySQL. La siguiente tabla muestra
la configuración avanzada de un clúster de base de datos.
Virtual Private Cloud (VPC) Seleccione la VPC que alojará el clúster de base de datos.
Seleccione Create a New VPC (Crear una nueva VPC)
para que Amazon RDS cree una VPC. Para obtener
más información, consulte la sección Requisitos previos
de clúster de base de datos (p. 86) que se ha expuesto
desea utilizar para el clúster de base de datos. Para
obtener más información, consulte la sección Requisitos
previos de clúster de base de datos (p. 86) que se ha
expuesto anteriormente en este tema.
Internet. (p. 223).


515

grupo de seguridad de VPC) para que Amazon RDS
cree un grupo de seguridad de VPC. O seleccione Select
existing VPC security groups (Seleccionar grupos de
seguridad de VPC existentes) y especifique uno o varios
grupos de seguridad de VPC para proteger el acceso
de red al clúster de base de datos. Para obtener más
información, consulte la sección Requisitos previos de
clúster de base de datos (p. 86) que se ha expuesto
DB Cluster Identifier (Identificador de Escriba un nombre para el clúster de base de datos que
clúster de base de datos) sea exclusivo para su cuenta en la región de AWS que
haya seleccionado. Este identificador se utiliza en la
dirección del punto de enlace del clúster para su clúster
de base de datos. Para obtener información acerca del
punto de enlace del clúster, consulte Administración de
conexiones de Amazon Aurora (p. 3).


guiones.
consecutivos.
datos por cuenta de AWS y región de AWS.
Nombre de base de datos Escriba un nombre de hasta 64 caracteres alfanuméricos

para la base de datos predeterminada. Si no proporciona
un nombre, Amazon RDS no crea una base de datos en el
clúster de base de datos que se está creando.
Para crear otras bases de datos, conéctese al clúster

de base de datos y use el comando SQL CREATE
DATABASE. Para obtener más información acerca de la
conexión al clúster de base de datos, consulte Conexión a
Database port (Puerto de base de Especifique el puerto que deben usar las aplicaciones y
datos) las utilidades para obtener acceso a la base de datos. Los
clústeres de base de datos Aurora MySQL usan de forma
predeterminada el puerto MySQL, 3306 y los clústeres
de base de datos Aurora PostgreSQL usan de forma
predeterminada el puerto PostgreSQL, 5432. Los firewalls
de algunas compañías bloquean las conexiones a estos
puertos predeterminados. Si el firewall de su compañía

516

DB cluster parameter group (Grupo Seleccione un grupo de parámetros de clúster de base

de parámetros de clúster de base de de datos. Aurora cuenta con un grupo de parámetros
datos) de clúster de base de datos predeterminado que puede
parámetros de clúster de base de datos. Para obtener
más información acerca de los grupos de parámetros de
clúster de base de datos, consulte Trabajo con los grupos
de parámetros de base de datos y grupos de parámetros
Option group (Grupo de opciones) Aurora tiene un grupo de opciones predeterminado.
Cifrado Seleccione Enable Encryption para habilitar el cifrado

en reposo para este clúster de base de datos. Para obtener
más información, consulte Cifrado de recursos de Amazon
Aurora (p. 158).
Clave maestra Solo está disponible si Encryption (Cifrado) se establece en

Enable Encryption (Habilitar cifrado). Seleccione la clave
maestra que se va a usar para el cifrado de este clúster

Aurora (p. 314).
Backup retention period (Período de Seleccione el tiempo (entre 1 y 35 días) durante el que
retención de copia de seguridad) Aurora conserva los backups de la base de datos. Los
backups se pueden utilizar para las restauraciones a
un momento dado (PITR) de la base de datos con una
precisión de segundos.

517
Backtrack Seleccione Enable Backtrack (Habilitar Backtrack) para

habilitar la búsqueda de datos anteriores o Disable
Backtrack (Deshabilitar Backtrack) para deshabilitarla.
Utilizando la búsqueda de datos anteriores puede
rebobinar un clúster de base de datos a un momento
específico, sin crear un nuevo clúster de base de datos.
Está deshabilitado de forma predeterminada. Si habilita
la búsqueda de datos anteriores, especifique también la
cantidad de tiempo que desea poder realizar la búsqueda
de datos anteriores en su clúster de base de datos (la
ventana de búsqueda de datos anteriores de destino).
Para obtener más información, consulte Búsqueda de
datos anteriores de un clúster de base de datos de
Aurora (p. 546).


mejorada (p. 395).

Log exports (Exportaciones de Elija los registros que desee comenzar a publicar en
registros) Amazon CloudWatch Logs. Para obtener más información
sobre la publicación en CloudWatch Logs, consulte
Publicación de registros de Amazon Aurora MySQL en
Amazon CloudWatch Logs (p. 662).
Auto minor version upgrade Esta configuración no se aplica a los clústeres de base de
(Actualización automática de datos Aurora MySQL.
versiones secundarias)


518
Enable deletion protection (Habilitar la Seleccione Enable deletion protection (Habilitar la

protección contra la eliminación) protección contra la eliminación) para evitar que se elimine
el clúster de base de datos. Si crea un clúster de base de
datos de producción con la consola, se habilita de forma
predeterminada la protección contra la eliminación.
10. Elija Create database (Crear base de datos) para lanzar la instancia de base de datos Aurora y, a
continuación, elija Close (Cerrar) para cerrar el asistente.
En la consola de Amazon RDS, la nueva instancia de base de datos aparece en la lista de instancias de
base de datos. La instancia de la base de datos tendrá el estado creating hasta que se cree la instancia y
esté lista para el uso. Cuando el estado cambie a available, podrá conectarse a la instancia principal de su
clúster de base de datos. Dependiendo de la clase de instancia de base de datos y del almacenamiento
asignado, es posible que la nueva instancia tarde varios minutos en estar disponible.
Para ver el clúster que acaba de crear, elija la vista Databases (Bases de datos) en la consola de Amazon
RDS y elija el clúster de base de datos. Para obtener más información, consulte Visualización de un clúster
de base de datos de Amazon Aurora (p. 375).

519
Anote el puerto y el punto de enlace del escritor del clúster de base de datos. Utilice el punto de enlace del
escritor y el puerto del clúster de base de datos en sus cadenas de conexión JDBC y ODBC para cualquier
aplicación que realice operaciones de lectura o escritura.
Sincronización del clúster de base de datos de Amazon Aurora MySQL con la

base de datos MySQL mediante replicación
Para que no se produzcan interrupciones durante la migración, puede replicar las transacciones que se
confirmaron en su base de datos MySQL en el clúster de base de datos de Aurora MySQL. La replicación
permite al clúster de base de datos ponerse al día con las transacciones de la base de datos MySQL que

520
se produjeron durante la migración. Cuando el clúster de base de datos esté totalmente sincronizado,
puede detener la replicación y terminar la migración a Aurora MySQL.
Temas
• Configuración de la base de datos MySQL externa y el clúster de base de datos de Aurora MySQL
para la replicación cifrada (p. 521)
• Sincronización del clúster de base de datos de Amazon Aurora MySQL con la base de datos MySQL
externa (p. 522)
Configuración de la base de datos MySQL externa y el clúster de base de datos de Aurora MySQL
para la replicación cifrada
Para replicar los datos de forma segura, puede usar la replicación cifrada.
Note
Si no necesita usar la replicación cifrada, puede omitir estos pasos y pasar a las instrucciones
de Sincronización del clúster de base de datos de Amazon Aurora MySQL con la base de datos
MySQL externa (p. 522).
A continuación, se indican los requisitos previos para utilizar la replicación cifrada:
• La Capa de conexión segura (SSL) debe estar habilitada en la base de datos maestra MySQL externa.
• Debe disponerse de una clave cliente y un certificado cliente para el clúster de base de datos de Aurora
MySQL.
Durante la replicación cifrada, el clúster de base de datos Aurora MySQL actúa como un cliente en el
servidor de base de datos MySQL. Los certificados y las claves del cliente de Aurora MySQL son archivos
con formato .pem.
Note
Actualmente, la replicación cifrada con una base de datos MySQL externa solo es compatible con
la versión 5.6 de Aurora MySQL.
Para configurar su base de datos MySQL externa y su clúster de base de datos de Aurora MySQL
para la replicación cifrada
1. Compruebe que esté preparado para la replicación cifrada:
• Si no tiene SSL habilitado en la base de datos maestra MySQL externa y no dispone de una clave
cliente y de un certificado cliente, habilite SSL en el servidor de base de datos MySQL y genere la
clave cliente y el certificado cliente necesarios.
• Si SSL está habilitado en la base de datos maestra externa, proporcione una clave cliente y un
certificado cliente para el clúster de base de datos Aurora MySQL. Si no los tiene, genere una nueva
clave y certificado para el clúster de base de datos Aurora MySQL. Para firmar el certificado cliente,
debe tener la clave de la entidad de certificación que usó para configurar SSL en la base de datos
maestra MySQL externa.
Para obtener más información, consulte Creating SSL Certificates and Keys Using openssl en la
Necesita un certificado de la entidad de certificación, la clave cliente y el certificado cliente.

2. Conéctese al clúster de base de datos Aurora MySQL como usuario maestro mediante SSL.
Para obtener información acerca de la conexión a un clúster de base de datos Aurora MySQL con
SSL, consulte Uso de SSL con clústeres de base de datos de Aurora MySQL (p. 501).

521
3. Ejecute el procedimiento almacenado mysql.rds_import_binlog_ssl_material para importar

la información de SSL en el clúster de base de datos Aurora MySQL.
Para el parámetro ssl_material_value, inserte la información de los archivos con formato .pem
para el clúster de base de datos Aurora MySQL en la carga JSON correcta.
En el siguiente ejemplo se importa la información de SSL en un clúster de base de datos Aurora

MySQL. En los archivos con formato .pem, el código del cuerpo suele ser más grande que el que se
muestra en el ejemplo.
call mysql.rds_import_binlog_ssl_material(
'{"ssl_ca":"-----BEGIN CERTIFICATE-----
AAAAB3NzaC1yc2EAAAADAQABAAABAQClKsfkNkuSevGj3eYhCe53pcjqP3maAhDFcvBS7O6V
hz2ItxCih+PnDSUaw+WNQn/mZphTk/a/gU8jEzoOWbkM4yxyb/wB96xbiFveSFJuOp/d6RJhJOI0iBXr
lsLnBItntckiJ7FbtxJMXLvvwJryDUilBMTjYtwB+QhYXUMOzce5Pjz5/i8SeJtjnV3iAoG/cQk+0FzZ
qaeJAAHco+CY/5WrUBkrHmFJr6HcXkvJdWPkYQS3xqC0+FmUZofz221CBt5IMucxXPkX4rWi+z7wB3Rb
BQoQzd8v7yeb7OzlPnWOyN0qFU0XA246RA8QFYiCNYwI3f05p6KLxEXAMPLE
-----END CERTIFICATE-----\n","ssl_cert":"-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----\n","ssl_key":"-----BEGIN RSA PRIVATE KEY-----
-----END RSA PRIVATE KEY-----\n"}');
Para obtener más información, consulte mysql_rds_import_binlog_ssl_material Uso de SSL con

clústeres de base de datos de Aurora MySQL (p. 501).
Note
Después de ejecutar el procedimiento, los secretos se almacenan en archivos.

Para borrar los archivos más tarde, puede ejecutar el procedimiento almacenado
mysql_rds_remove_binlog_ssl_material.
Sincronización del clúster de base de datos de Amazon Aurora MySQL con la base de datos
MySQL externa
Puede sincronizar su clúster de base de datos de Amazon Aurora MySQL con la base de datos MySQL
mediante replicación.
Para sincronizar su clúster de base de datos de Aurora MySQL con la base de datos MySQL
mediante replicación
1. Asegúrese de que el archivo /etc/my.cnf de la base de datos MySQL externa tenga las entradas
pertinentes.
Si no se requiere la replicación cifrada, asegúrese de que la base de datos MySQL externa se inicia
con los logs binarios (binlogs) habilitados y SSL deshabilitado. A continuación se indican las entradas
pertinentes en el archivo /etc/my.cnf para los datos sin cifrar.
log-bin=mysql-bin
server-id=2133421

522
innodb_flush_log_at_trx_commit=1
sync_binlog=1
Si se requiere la replicación cifrada, asegúrese de que la base de datos MySQL externa se inicia
con SSL y los binlogs habilitados. Las entradas del archivo /etc/my.cnf incluyen las ubicaciones del
archivo .pem para el servidor de base de datos MySQL.
log-bin=mysql-bin
server-id=2133421
sync_binlog=1
# Setup SSL.
ssl-ca=/home/sslcerts/ca.pem
ssl-cert=/home/sslcerts/server-cert.pem
ssl-key=/home/sslcerts/server-key.pem
Puede confirmar que SSL está habilitado con el siguiente comando.
mysql> show variables like 'have_ssl';
El resultado debería ser similar al siguiente.
+~-~-~-~-~-~-~-~-~-~-~-~-~-~--+~-~-~-~-~-~--+
+~-~-~-~-~-~-~-~-~-~-~-~-~-~--+~-~-~-~-~-~--+
| have_ssl | YES |
+~-~-~-~-~-~-~-~-~-~-~-~-~-~--+~-~-~-~-~-~--+
1 row in set (0.00 sec)
2. Determine la posición del log binario inicial para la replicación:
a. Inicie sesión en la Consola de administración de AWS y abra la consola de Amazon RDS en

https://console.aws.amazon.com/rds/.
b. En el panel de navegación, seleccione Events.
c. En la lista Events (Eventos), anote la posición del evento Recovered from Binary log filename
(Recuperado del nombre de archivo de log binario).
Especificará la posición para iniciar la replicación en un paso posterior.

523
3. Mientras está conectado a la base de datos MySQL externa, cree el usuario que se va a usar para la
replicación. Esta cuenta se usa únicamente para la replicación y debe estar limitada a su dominio para
mejorar la seguridad. A continuación se muestra un ejemplo.
mysql> CREATE USER '<user_name>'@'<domain_name>' IDENTIFIED BY '<password>';
El usuario requiere los privilegios REPLICATION CLIENT y REPLICATION SLAVE. Conceda estos
privilegios al usuario.
GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO '<user_name>'@'<domain_name>';
Si necesita usar la replicación cifrada, exija conexiones SSL al usuario de la replicación. Por ejemplo,
puede utilizar la siguiente declaración para exigir el uso de conexiones SSL en la cuenta de usuario
<user_name>.
GRANT USAGE ON *.* TO '<user_name>'@'<domain_name>' REQUIRE SSL;
Note
Si REQUIRE SSL no se incluye, la conexión de replicación podría cambiarse

inadvertidamente por una conexión sin cifrar.
4. En la consola de administración de Amazon RDS, añada la dirección IP del servidor que aloja la base
de datos MySQL externa al grupo de seguridad de VPC para el clúster de base de datos de Aurora
MySQL. Para obtener más información acerca de la modificación de un grupo de seguridad de VPC,
consulte Grupos de seguridad de su VPC en la Guía del usuario de Amazon Virtual Private Cloud.
Es posible que también necesite configurar su red local para permitir las conexiones desde la dirección
IP de su clúster de base de datos de Aurora MySQL con el fin de que se pueda comunicar con la
base de datos MySQL externa. Para encontrar la dirección IP del clúster de base de datos de Aurora
MySQL, use el comando host.
host RDS_MySQL_DB_<host_name>
El nombre de host es el nombre DNS del punto de enlace del clúster de base de datos de Aurora
MySQL.
5. Habilite la replicación de logs binarios ejecutando el procedimiento almacenado
mysql.rds_set_external_master. Este procedimiento almacenado tiene la siguiente sintaxis.
CALL mysql.rds_set_external_master (
host_name
, host_port
, replication_user_name
, replication_user_password
, mysql_binary_log_file_name
, mysql_binary_log_file_location
, ssl_encryption
);
Para obtener información acerca de los parámetros, consulte mysql_rds_set_external_master.

524
Para mysql_binary_log_file_name y mysql_binary_log_file_location, use la posición

del evento Recovered from Binary log filename (Recuperado del nombre de archivo de log binario) que
anotó antes.
Si los datos del clúster de base de datos de Aurora MySQL no están cifrados, el parámetro
ssl_encryption debe establecerse en 0. Si los datos están cifrados, el parámetro
ssl_encryption debe establecerse en 1.
El siguiente ejemplo ejecuta el procedimiento para un clúster de base de datos de Aurora MySQL que
tiene datos cifrados.
CALL mysql.rds_set_external_master(
'Externaldb.some.com',
3306,
'repl_user'@'mydomain.com',
'password',
'mysql-bin.000010',
120,
1);
Este procedimiento almacenado establece los parámetros que el clúster de base de datos de Aurora
MySQL usa para conectarse a una base de datos MySQL externa y leer su log binario. Si los datos
están cifrados, también descarga el certificado de la entidad de certificación de SSL, el certificado
cliente y la clave cliente en el disco local.
6. Inicie la replicación de logs binarios ejecutando el procedimiento almacenado
mysql.rds_start_replication.
CALL mysql.rds_start_replication;
7. Monitorice qué retardo tiene el clúster de base de datos de Aurora MySQL con respecto a la base
de datos de maestro de replicación de MySQL. Para ello, conéctese al clúster de base de datos de
Aurora MySQL y ejecute el siguiente comando.
SHOW SLAVE STATUS;
En la salida del comando, el campo Seconds Behind Master muestra cuánto retardo tiene el
clúster de base de datos de Aurora MySQL con respecto al maestro de MySQL. Cuando este valor
es 0 (cero), el clúster de base de datos de Aurora MySQL se ha sincronizado con el principal y puede
continuar con el siguiente paso para detener la replicación.
8. Conéctese a la base de datos del maestro de replicación MySQL y detenga la replicación. Para ello,
ejecute el siguiente comando.
CALL mysql.rds_stop_replication;

525
Migración desde una instancia de base
de datos MySQL a Aurora MySQL
Migración de MySQL a Amazon Aurora con mysqldump

Dado que Amazon Aurora MySQL es una base de datos compatible con MySQL, puede usar la utilidad
mysqldump para copiar datos de su base de datos MySQL o MariaDB en un clúster de base de datos de
Aurora MySQL.
Para consultar un debate sobre cómo hacerlo con bases de datos de MySQL de tamaño muy grande,
consulte Importación de datos a una instancia de base de datos de MySQL o MariaDB en Amazon RDS
con tiempo de inactividad reducido. En el caso de bases de datos de MySQL con menores cantidades de
datos, consulte Importación de datos de una base de datos de MySQL o MariaDB a una instancia de base
de datos MySQL o MariaDB en Amazon RDS.
Migración de datos desde una instancia de base

de datos MySQL a un clúster de base de datos de
Amazon Aurora MySQL con una instantánea de base
de datos
Puede migrar (copiar) los datos a un clúster de base de datos de Amazon Aurora MySQL desde una
instantánea de base de datos MySQL en Amazon RDS, tal y como se describe a continuación.
Temas
• Migración de un snapshot de RDS MySQL a Aurora (p. 526)
• Migración de datos desde una instancia de base de datos MySQL a un clúster de base de datos de
Amazon Aurora MySQL con una réplica de lectura de Aurora (p. 533)
Note
Dado que Amazon Aurora MySQL es compatible con MySQL, puede migrar datos desde la base
de datos MySQL configurando la replicación entre la base de datos MySQL y un clúster de base
de datos de Amazon Aurora MySQL. Si quiere utilizar la replicación para migrar datos desde la
base de datos MySQL, le recomendamos ejecutar la versión 5.5 o posterior de la base de datos
MySQL. Para obtener más información, consulte Replicación con Amazon Aurora (p. 48).
Migración de un snapshot de RDS MySQL a Aurora

Puede migrar una instantánea de base de datos una instancia de base de datos MySQL en Amazon
RDS para crear un clúster de base de datos de Aurora MySQL. El nuevo clúster de base de datos de
Aurora MySQL se rellena con los datos de la instancia de base de datos MySQL de Amazon RDS original.
La instantánea de base de datos debe haberse obtenido a partir de una instancia de base de datos de
Amazon RDS que ejecute MySQL versión 5.6 o 5.7.
Puede migrar una instantánea de base de datos manual o automatizada. Una vez creado el clúster de
base de datos, podrá crear réplicas de Aurora opcionales.
Cuando la instancia de base de datos MySQL y el clúster de base de datos de Aurora estén ejecutando la
misma versión de MySQL, puede restaurar la instantánea de MySQL directamente en el clúster de base
de datos de Aurora. Por ejemplo, puede restaurar una instantánea de la versión 5.6 de MySQL a la versión
5.6 de Aurora MySQL, pero no puede restaurar una instantánea de la versión 5.6 de MySQL directamente
a Aurora MySQL versión 5.7.
Si desea migrar una instantánea de la versión 5.6 de MySQL a la versión 5.7 de Aurora MySQL, puede
realizar la migración de una de las siguientes maneras:

526
• Migre una instantánea de la versión 5.6 de MySQL a la versión 5.6 de Aurora MySQL, tome una
instantánea del clúster de la base de datos la versión 5.6 de Aurora MySQL y, a continuación, restaure la
instantánea de la versión 5.6 de Aurora MySQL a la versión 5.7 de Aurora MySQL.
• Actualice la instantánea de la versión 5.6 de MySQL a la versión 5.7 de MySQL, tome una instantánea
de la instancia de la base de datos de la versión 5.7 de MySQL y, a continuación, restaure la instantánea
de la versión 5.7 de MySQL; a la versión 5.7 de Aurora MySQL.
Note
También puede migrar una instancia de base de datos MySQL a un clúster de base de datos de
Aurora MySQL creando una réplica de lectura de Aurora de su instancia de base de datos MySQL
de origen. Para obtener más información, consulte Migración de datos desde una instancia de
base de datos MySQL a un clúster de base de datos de Amazon Aurora MySQL con una réplica
de lectura de Aurora (p. 533).
Entre las incompatibilidades entre MySQL y Aurora MySQL se incluyen las siguientes:
• No puede migrar una instantánea de la versión 5.7 de MySQL a la versión 5.6 de Aurora MySQL.
• No puede migrar una instantánea de base de datos creada con MySQL 5.6.40 o 5.7.22 a Aurora MySQL.
Los pasos generales que debe realizar son los siguientes:
1. Determine la cantidad de espacio que desea aprovisionar para el clúster de base de datos de Aurora
MySQL. Para obtener más información, consulte ¿Cuánto espacio necesito? (p. 527)
2. Utilice la consola para crear la instantánea en la región de AWS en la que se encuentra la instancia de
MySQL en Amazon RDS. Para obtener más información acerca de la creación de una instantánea de
base de datos, consulte Creación de una instantánea de base de datos.
3. Si la instantánea de base de datos no se encuentra en la misma región de AWS que su clúster de
base de datos, utilice la consola de Amazon RDS para copiar la instantánea de base de datos en esa
región de AWS. Para obtener más información acerca de la copia de una instantánea de base de datos,
consulte Copia de una instantánea de base de datos.
4. Utilice la consola para migrar la instantánea de base de datos y crear un clúster de base de datos de
Aurora MySQL con las mismas bases de datos que la instancia de base de datos original de MySQL.
Warning
Amazon RDS limita cada cuenta de AWS a una copia de la instantánea en cada región de AWS
en un momento dado.
¿Cuánto espacio necesito?

Al migrar una instantánea de una instancia de base de datos MySQL a un clúster de base de datos de
Aurora MySQL, Aurora utiliza un volumen de Amazon Elastic Block Store (Amazon EBS) para formatear
los datos de la instantánea antes de migrarlos. En algunos casos, se necesita espacio adicional para
formatear los datos para la migración.
Las tablas que no son MyISAM y no están comprimidas pueden alcanzar un tamaño de 16 TB. Si tiene
tablas MyISAM, Aurora deberá utilizar espacio adicional en el volumen para convertir las tablas con el fin
de que sean compatibles con MySQL de Aurora. Si hay tablas comprimidas, Aurora tendrá que utilizar
espacio adicional en el volumen para ampliar esas tablas antes de almacenarlas en el volumen del clúster
de Aurora. Debido a este requisito de espacio adicional, debe asegurarse de que ninguna de las tablas
MyISAM y de las tablas comprimidas que se van a migrar desde su instancia de base de datos MySQL
tiene un tamaño superior a 8 TB.

527
Reducción de la cantidad de espacio necesario para migrar datos a Amazon

Aurora MySQL
Es posible que le interese modificar su esquema de base de datos antes de migrar a Amazon Aurora. Esta
modificación puede ser útil en los siguientes casos:
• Si desea acelerar el proceso de migración.

• Si no está seguro de cuánto espacio necesita aprovisionar.
• Si ha intentado migrar los datos y la migración ha generado un error por falta de espacio aprovisionado.
Puede realizar los siguientes cambios para mejorar el proceso de migración de una base de datos a
Amazon Aurora.
Important
Asegúrese de realizar estas actualizaciones en una instancia de base de datos nueva restaurada
a partir de un snapshot de una base de datos de producción y no a partir de una instancia de
producción. A continuación, puede migrar los datos de la instantánea de la nueva instancia de
base de datos al clúster de base de datos de Aurora para evitar las interrupciones de servicio en
la base de datos de producción.
Tipo de tabla Limitación o pauta
Tablas MyISAM Aurora MySQL solo admite tablas InnoDB. Si hay tablas MyISAM
en la base de datos, tendrá que convertirlas antes de migrarlas a
Aurora MySQL. El proceso de conversión requiere más espacio para
la conversión de MyISAM a InnoDB durante el procedimiento de
migración.
Para reducir el riesgo de quedarse sin espacio o para acelerar el

proceso de migración, convierta todas sus tablas MyISAM en tablas
InnoDB antes de migrarlas. El tamaño de la tabla InnoDB resultante
equivale al tamaño requerido por Aurora MySQL para esa tabla. Para
convertir una tabla MyISAM a InnoDB, ejecute el siguiente comando:
alter table <schema>.<table_name> engine=innodb,

algorithm=copy;
Tablas comprimidas Aurora MySQL no admite tablas comprimidas (es decir, tablas creadas
con ROW_FORMAT=COMPRESSED).
Para reducir el riesgo de quedarse sin espacio o para acelerar el

proceso de migración, amplíe las tablas comprimidas mediante
la configuración de ROW_FORMAT DEFAULT, COMPACT, DYNAMIC
o REDUNDANT. Para obtener más información, consulte https://
dev.mysql.com/doc/refman/5.6/en/innodb-row-format.html.
Puede utilizar el siguiente script de SQL en su instancia de base de datos MySQL para obtener una lista de
las tablas MyISAM o comprimidas de su base de datos.
-- This script examines a MySQL database for conditions that block

-- migrating the database into Amazon Aurora.
-- It needs to be run from an account that has read permission for the
-- INFORMATION_SCHEMA database.
-- Verify that this is a supported version of MySQL.

528
select msg as `==> Checking current version of MySQL.`

from
(
select
'This script should be run on MySQL version 5.6. ' +
'Earlier versions are not supported.' as msg,
cast(substring_index(version(), '.', 1) as unsigned) * 100 +
cast(substring_index(substring_index(version(), '.', 2), '.', -1)
as unsigned)
as major_minor
) as T
where major_minor <> 506;
-- List MyISAM and compressed tables. Include the table size.
select concat(TABLE_SCHEMA, '.', TABLE_NAME) as `==> MyISAM or Compressed Tables`,

round(((data_length + index_length) / 1024 / 1024), 2) "Approx size (MB)"
from INFORMATION_SCHEMA.TABLES
where
ENGINE <> 'InnoDB'
and
(
-- User tables
TABLE_SCHEMA not in ('mysql', 'performance_schema',
'information_schema')
or
-- Non-standard system tables
(
TABLE_SCHEMA = 'mysql' and TABLE_NAME not in
(
'columns_priv', 'db', 'event', 'func', 'general_log',
'help_category', 'help_keyword', 'help_relation',
'help_topic', 'host', 'ndb_binlog_index', 'plugin',
'proc', 'procs_priv', 'proxies_priv', 'servers', 'slow_log',
'tables_priv', 'time_zone', 'time_zone_leap_second',
'time_zone_name', 'time_zone_transition',
'time_zone_transition_type', 'user'
)
)
)
or
(
-- Compressed tables
ROW_FORMAT = 'Compressed'
);
El script genera una salida similar a la del siguiente ejemplo. El ejemplo muestra dos tablas que se
deben convertir de MyISAM a InnoDB. La salida también incluye el tamaño aproximado de cada tabla en
megabytes (MB).
+---------------------------------+------------------+
| ==> MyISAM or Compressed Tables | Approx size (MB) |
+---------------------------------+------------------+
| test.name_table | 2102.25 |
| test.my_table | 65.25 |
+---------------------------------+------------------+
2 rows in set (0.01 sec)

Puede migrar una instantánea de base de datos una instancia de base de datos MySQL en Amazon
RDS para crear un clúster de base de datos de Aurora MySQL. El nuevo clúster de base de datos de

529
Aurora MySQL se rellena con los datos de la instancia de base de datos MySQL de Amazon RDS original.
La instantánea de base de datos debe haberse obtenido a partir de una instancia de base de datos de
Amazon RDS que ejecute MySQL versión 5.6 o 5.7. Para obtener más información acerca de la creación
de una instantánea de base de datos, consulte Creación de una instantánea de base de datos.
Si la instantánea de base de datos no se encuentra en la región de AWS en la que desea ubicar sus datos,
utilice la consola de Amazon RDS para copiar la instantánea de base de datos en esa región de AWS.
Para obtener más información acerca de la copia de una instantánea de base de datos, consulte Copia de
una instantánea de base de datos.
Al migrar la instantánea de base de datos con la Consola de administración de AWS, esta realiza las
acciones necesarias para crear tanto el clúster de base de datos como la instancia principal.
También puede elegir que el nuevo clúster de base de datos de Aurora MySQL se cifre en reposo
mediante una clave de cifrado de AWS Key Management Service (AWS KMS).
Para migrar una instantánea de base de datos MySQL con la Consola de administración de AWS
2. Inicie la migración de datos desde la instancia de base de datos MySQL a desde la instantánea:
Para iniciar la migración desde la instancia de base de datos:
1. En el panel de navegación, elija Instances (Instancias) y seleccione la instancia de base de datos

MySQL.
2. En Actions (Acciones), elija Migrate latest snapshot (Migrar última instantánea).
Para iniciar la migración desde la instantánea:
1. Elija Snapshots (Instantáneas).

2. En la página Snapshots (Instantáneas), elija la instantánea que desea migrar a un clúster de base
de datos de Aurora MySQL.
3. Elija Snapshot Actions y, a continuación, seleccione Migrate Snapshot.
Aparece la página Migrate Database.

3. Defina los siguientes valores en la página Migrate Database (Migrar base de datos):
• Migrate to DB Engine (Migrar a motor de base de datos): seleccione aurora.

• DB Engine Version (Versión de motor de base de datos): seleccione la versión del motor de base de
datos para el clúster de base de datos de Aurora MySQL.
• Clase de instancia de base de datos: seleccione una clase de instancia de base de datos que tenga
el almacenamiento y la capacidad requeridos para la base de datos, por ejemplo db.r3.large.
Los volúmenes de clúster de Aurora aumentarán automáticamente a medida que se incremente
la cantidad de datos en la base de datos, hasta un tamaño máximo de 64 tebibytes (TiB). Por lo
tanto, solo tiene que seleccionar una clase de instancia de base de datos que se adapte a sus
necesidades actuales de almacenamiento. Para obtener más información, consulte Información
general del almacenamiento de Aurora (p. 25).
• DB Instance Identifier (Identificador de instancia de base de datos): escriba un nombre para el
clúster de base de datos que sea único para su cuenta en la región de AWS que ha seleccionado.
Este identificador se utiliza en las direcciones de punto de enlace para las instancias del clúster de
base de datos. Puede optar por agregar al nombre información como la región de AWS y el motor
de base de datos que ha seleccionado, por ejemplo, aurora-cluster1.
El identificador de instancias de bases de datos tiene las siguientes limitaciones:

530
• Debe contener de 1 a 63 caracteres alfanuméricos o guiones.

• No puede terminar con un guion ni contener dos guiones consecutivos.
• Debe ser único para todas las instancias de base de datos por cada cuenta de AWS y por región
de AWS.
• Virtual Private Cloud (VPC): si ya dispone de una VPC, puede utilizarla con su clúster de base de
datos de Aurora MySQL si selecciona el identificador de la VPC, por ejemplo, vpc-a464d1c1. Para
obtener información acerca del uso de una VPC, consulte Cómo crear una VPC para el uso con
De lo contrario, puede optar por hacer que Amazon RDS cree una VPC seleccionando Create a new
VPC (Crear una nueva VPC).
• Subnet group (Grupo de subredes): si dispone de un grupo de subredes existente, puede utilizarlo
con el clúster de base de datos de MySQL de Aurora si selecciona el identificador del grupo de
subredes, por ejemplo, gs-subnet-group1.
De lo contrario, puede optar por hacer que Amazon RDS cree un grupo de subredes seleccionando
Create a new subnet group (Crear un nuevo grupo de subredes).
• Public accessibility (Accesibilidad pública): seleccione No para especificar que a las instancias de
su clúster de base de datos solo pueden obtener acceso los recursos que se encuentren dentro de
su VPC. Seleccione Yes (Sí) para especificar que los recursos de la red pública pueden obtener
acceso a las instancias de su clúster de base de datos. El valor predeterminado es Yes (Sí).
Note
No es necesario que su clúster de base de datos de producción esté en una subred

pública, ya que solo los servidores de su aplicación necesitan acceso a su clúster de base
de datos. Si su clúster de base de datos no necesita estar en una subred pública, defina
Publicly Accessible (Accesible públicamente) como No.
• Availability Zone (Zona de disponibilidad): seleccione la zona de disponibilidad para alojar la
instancia principal del clúster de base de datos de Aurora MySQL. Para hacer que Amazon RDS
elija una zona de disponibilidad, seleccione No Preference (Sin preferencias).
• Database Port (Puerto de base de datos): indique el puerto predeterminado que se utilizará al
conectar a instancias del clúster de base de datos Aurora MySQL. El valor predeterminado es 3306.
Note
Es posible que se encuentre detrás de un firewall de una compañía que no permite el

acceso a los puertos predeterminados, como el puerto predeterminado de MySQL, el 3306.
En este caso, proporcione un valor de puerto permitido por el firewall corporativo. Recuerde
el valor del puerto cuando se conecte más adelante al clúster de base de datos de Aurora
MySQL.
• Encryption (Cifrado): elija Enable Encryption (Habilitar cifrado) para que el nuevo clúster de base de
datos de Aurora MySQL se cifre en reposo. Si elige Enable encryption (Habilitar cifrado), debe elegir
una clave de cifrado de AWS KMS como valor de Master key (Clave maestra).
Si la instantánea de base de datos no está cifrada, especifique una clave de cifrado para cifrar el
clúster de base de datos en reposo.
Si la instantánea de base de datos está cifrada, especifique una clave de cifrado para cifrar el
clúster de base de datos en reposo con la clave de cifrado especificada. Puede especificar la clave
de cifrado utilizada por la instantánea de base de datos o una clave distinta. No puede crear un
clúster de base de datos sin cifrar a partir de una instantánea de base de datos cifrada.
• Auto Minor Version Upgrade (Actualización automática a versiones secundarias): este ajuste no se
aplica a los clústeres de base de datos Aurora MySQL.
531
Para obtener más información acerca de las actualizaciones de motor de Aurora MySQL, consulte
Actualizaciones del motor de base de datos para Amazon Aurora MySQL (p. 695).
4. Elija Migrate (Migrar) para migrar la instantánea de base de datos.
5. Elija Instances y, a continuación, seleccione el icono de flecha para mostrar la información detallada
del clúster de base de datos y monitorizar el progreso de la migración. En la página de detalles,
encontrará el punto de enlace del clúster que se utiliza para conectar a la instancia principal del clúster
de base de datos. Para obtener más información acerca de la conexión a un clúster de base de datos
de Aurora MySQL, consulte Conexión a un clúster de base de datos Amazon Aurora (p. 148).
CLI
Puede migrar una instantánea de base de datos una instancia de base de datos MySQL en Amazon RDS
para crear un clúster de base de datos de Aurora. A continuación, el nuevo clúster de base de datos se
rellena con los datos de la instantánea de base de datos. La instantánea de base de datos debe proceder
de una instancia de base de datos de Amazon RDS que ejecute MySQL versión 5.6 o 5.7. Para obtener
más información, consulte Creación de una instantánea de base de datos.
Si la instantánea de base de datos no se encuentra en la región de AWS en la que desea ubicar sus datos,
copie la instantánea de base de datos en dicha región de AWS. Para obtener más información, consulte
Copia de una instantánea de base de datos.
Puede crear un clúster de base de datos de Aurora desde una instantánea de base de datos de una
instancia de base de datos MySQL en Amazon RDS con el comando restore-db-cluster-from-
snapshot y los siguientes parámetros:
El nombre del clúster de base de datos que se creará.

• Uso de --engine aurora-mysql para un clúster de base de datos compatible con MySQL 5.7 o --
engine aurora para un clúster de base de datos compatible con MySQL 5.6
• --kms-key-id
La clave de cifrado de AWS Key Management Service (AWS KMS) para cifrar, si lo desea, el clúster de
base de datos en función de si la instantánea de base de datos está cifrada o no.
• Si la instantánea de base de datos no está cifrada, especifique una clave de cifrado para cifrar el
clúster de base de datos en reposo. De lo contrario, el clúster no estará cifrado.
• Si la instantánea de base de datos está cifrada, especifique una clave de cifrado para cifrar el clúster
de base de datos en reposo con la clave de cifrado especificada. De lo contrario, el clúster de base de
datos se cifrará en reposo con la clave de cifrado de la instantánea de base de datos.
Note
No puede crear un clúster de base de datos sin cifrar a partir de una instantánea de base de
datos cifrada.
• --snapshot-identifier
El nombre de recurso de Amazon (ARN) de la instantánea de base de datos que se va a migrar. Para
obtener más información sobre los ARN de Amazon RDS, consulte Amazon Relational Database Service
(Amazon RDS).
Al migrar la instantánea de base de datos con el comando RestoreDBClusterFromSnapshot, este crea

tanto el clúster de base de datos como la instancia principal.
En este ejemplo, va a crear un clúster de base de datos compatible con MySQL 5.7 denominado
mydbcluster a partir de una instantánea de base de datos con un ARN definido en mydbsnapshotARN.

532

--snapshot-identifier mydbsnapshotARN \
--engine aurora-mysql
Para Windows:

--snapshot-identifier mydbsnapshotARN ^
--engine aurora-mysql
En este ejemplo, va a crear un clúster de base de datos compatible con MySQL 5.6 denominado
mydbcluster a partir de una instantánea de base de datos con un ARN definido en mydbsnapshotARN.

--snapshot-identifier mydbsnapshotARN \
--engine aurora
Para Windows:

--snapshot-identifier mydbsnapshotARN ^
--engine aurora
Migración de datos desde una instancia de base de datos MySQL

a un clúster de base de datos de Amazon Aurora MySQL con una
réplica de lectura de Aurora
Amazon RDS usa la funcionalidad de replicación de registros binarios de los motores de base de datos
MySQL para crear un tipo especial de clúster de base de datos denominado réplica de lectura de Aurora
para una instancia de base de datos origen de MySQL. Las actualizaciones realizadas en la instancia de
base de datos MySQL de origen se replican de forma asíncrona en la réplica de lectura de Aurora.
Es recomendable usar esta funcionalidad para migrar desde una instancia de base de datos MySQL a
un clúster de base de datos de Aurora MySQL creando una réplica de lectura de Aurora de la instancia
de base de datos MySQL de origen. Cuando el retardo de la réplica entre la instancia de base de datos
MySQL y la réplica de lectura de Aurora sea 0, podrá dirigir las aplicaciones cliente a la réplica de lectura
de Aurora y detener después la replicación para convertir la réplica de lectura de Aurora en un clúster de
base de datos de Aurora MySQL independiente. Esta migración puede tardar un tiempo considerable,
aproximadamente varias horas por tebibyte (TiB) de datos.
Para obtener una lista de las regiones en las que está disponible Aurora, consulte Amazon Aurora en la
AWS General Reference.
Cuando se crea una réplica de lectura de Aurora de una instancia de base de datos MySQL, Amazon
RDS crea una instantánea de base de datos la instancia de base de datos MySQL de origen (privada para
Amazon RDS y sin cargo). A continuación, Amazon RDS migra los datos desde la instantánea de base de
datos a la réplica de lectura de Aurora. Una vez que los datos de la instantánea de base de datos se hayan
migrado al nuevo clúster de base de datos de Aurora MySQL, Amazon RDS comenzará la replicación entre

533
la instancia de base de datos MySQL y el clúster de base de datos de Aurora MySQL. Si la instancia de
base de datos MySQL contiene tablas que usen motores de almacenamiento distintos de InnoDB o que
usen el formato de filas comprimidas, puede acelerar el proceso de creación de una réplica de lectura de
Aurora modificando esas tablas para que usen el motor de almacenamiento de InnoDB y el formato de filas
dinámicas antes de crear la réplica de lectura de Aurora. Para obtener más información acerca del proceso
de copia de una instantánea de base de datos MySQL en un clúster de base de datos de Aurora MySQL,
consulte Migración de datos desde una instancia de base de datos MySQL a un clúster de base de datos
de Amazon Aurora MySQL con una instantánea de base de datos (p. 526).
Solo puede tener una réplica de lectura de Aurora para una instancia de base de datos MySQL.
Note
Pueden surgir problemas de replicación a causa de las diferencias de características entre

MySQL en Amazon Aurora y la versión del motor de base de datos MySQL de la instancia de
base de datos MySQL en RDS que es el maestro de replicación. Si se produce un error, puede
encontrar ayuda en el foro de la comunidad de Amazon RDS o contactando con AWS Support.
Para obtener más información sobre las réplicas de lectura de MySQL, consulte Trabajo con réplicas de
lectura de instancias de base de datos MariaDB, MySQL y PostgreSQL.
Creación de una réplica de lectura de Aurora

Puede crear una réplica de lectura de Aurora para una instancia de base de datos MySQL por medio de la
consola o de la AWS CLI.
Para crear una réplica de lectura de Aurora a partir de una instancia de base de datos MySQL
3. Elija la instancia de base de datos MySQL que desee usar como origen para su réplica de lectura de
Aurora y elija Create Aurora Read Replica (Crear réplica de lectura de Aurora) en Instance Actions
(Acciones de instancias).
4. Elija las especificaciones del clúster de base de datos que desee usar para la réplica de lectura de
Aurora y que se describen en la tabla siguiente.
Opción Descripción
DB instance class Elija una clase de instancia de base de datos que defina
los requisitos de procesamiento y memoria para la
instancia principal del clúster de base de datos. Para
obtener más información acerca de las opciones de clases
de instancia de base de datos, consulte Selección de la
Multi-AZ deployment (Implementación Elija Create Replica in Different Zone (Crear réplica en
Multi-AZ) otra zona) para crear una réplica en espera del nuevo
clúster de base de datos en otra zona de disponibilidad de
la región de AWS de destino para permitir la conmutación
por error. Para obtener más información acerca del uso
DB Instance Identifier (Identificador de Escriba un nombre para la instancia principal de su clúster

instancias de bases de datos) de base de datos de réplica de lectura de Aurora. Este

534
identificador se utiliza en la dirección del punto de enlace
de la instancia principal del nuevo clúster de base de
datos.


guiones.
consecutivos.
datos de cada cuenta de AWS y para cada región de
AWS.
Como el clúster de base de datos réplica de lectura de

Aurora entre regiones se crea a partir de una instantánea
de la instancia de base de datos origen, el nombre de
usuario principal y la contraseña principal de la réplica
de lectura de Aurora coinciden con el nombre de usuario
principal y la contraseña principal de la instancia de base
de datos origen.
Virtual Private Cloud (VPC) Seleccione la VPC que alojará el clúster de base de
datos. Seleccione Create new VPC (Crear nueva VPC)
para que Amazon RDS cree una VPC. Para obtener más
información, consulte Requisitos previos de clúster de base
de datos (p. 86).
desea utilizar para el clúster de base de datos. Seleccione
Create new DB subnet group (Crear nuevo grupo de
subredes de base de datos) para que Amazon RDS cree
un grupo de subredes de base de datos. Para obtener más
de datos (p. 86).
Internet. (p. 223).


535
grupo de seguridad de VPC) para que Amazon RDS cree
un grupo de seguridad de VPC. Seleccione Select existing
VPC security groups (Seleccionar grupos de seguridad de
VPC existentes) para especificar uno o varios grupos de
seguridad de VPC para proteger el acceso de red al clúster
Requisitos previos de clúster de base de datos (p. 86).
Database port (Puerto de base de Especifique el puerto que deben usar las aplicaciones
datos) y las utilidades para obtener acceso a la base de datos.
Los clústeres de base de datos de Aurora MySQL usan
el puerto 3306 de MySQL de forma predeterminada. Los
firewalls de algunas compañías bloquean las conexiones a
este puerto. Si el firewall de su compañía bloquea el puerto
predeterminado, elija otro puerto para el nuevo clúster de
base de datos.
DB Parameter Group (Grupo de Seleccione un grupo de parámetros de base de datos

parámetros de base de datos) para el clúster de base de datos MySQL de Aurora. Aurora
cuenta con un grupo de parámetros de base de datos
predeterminado que puede utilizar. Si lo prefiere, puede
crear su propio grupo de parámetros de base de datos.
Para obtener más información acerca de los grupos de
parámetros de base de datos, consulte Trabajo con los
grupos de parámetros de base de datos y grupos de
parámetros de clúster de base de datos (p. 259).
DB cluster parameter group (Grupo Seleccione un grupo de parámetros de clúster de base de

de parámetros de clúster de base de datos para el clúster de base de datos de Aurora MySQL.
datos) Aurora cuenta con un grupo de parámetros de clúster de
base de datos predeterminado que puede utilizar. Si lo
prefiere, puede crear su propio grupo de parámetros de
clúster de base de datos. Para obtener más información
acerca de los grupos de parámetros de clúster de base de
datos, consulte Trabajo con los grupos de parámetros de
base de datos y grupos de parámetros de clúster de base
de datos (p. 259).

536
Cifrado Elija Disable encryption (Deshabilitar cifrado) si no desea

que se cifre su nuevo clúster de base de datos de Aurora.
Elija Enable encryption (Habilitar cifrado) para que el nuevo
clúster de base de datos de Aurora se cifre en reposo. Si
elige Enable encryption (Habilitar cifrado), debe elegir una
clave de cifrado de AWS KMS como valor de Master key
(Clave maestra).
Si la instancia de base de datos MySQL no está cifrada,

especifique una clave de cifrado para cifrar el clúster de
base de datos en reposo.
Si la instancia de base de datos MySQL está cifrada,

especifique una clave de cifrado para cifrar el clúster
de base de datos en reposo con la clave de cifrado
especificada. Puede especificar la clave de cifrado utilizada
por la instancia de base de datos MySQL o una clave
distinta. No puede crear un clúster de base de datos sin
cifrar a partir de una instancia de base de datos MySQL
cifrada.
Prioridad Elija una prioridad de conmutación por error para el

clúster de base de datos. Si no selecciona un valor, el
ajuste predeterminado es tier-1. Esta prioridad determina
el orden en que se promueven las réplicas de Aurora
Aurora (p. 314).
Backup retention period (Período de Seleccione el tiempo (entre 1 y 35 días) durante el que
retención de copia de seguridad) Aurora conserva los backups de la base de datos. Los
backups se pueden utilizar para las restauraciones a
un momento dado (PITR) de la base de datos con una
Enhanced Monitoring (Monitorización Elija Enable enhanced monitoring (Habilitar monitorización


mejorada (p. 395).

537

(Actualización automática de datos Aurora MySQL.
versiones secundarias)

5. Elija Create read replica (Crear réplica de lectura).
CLI
Para crear una réplica de lectura de Aurora a partir de una instancia de base de datos MySQL de origen,
utilice los comandos create-db-cluster y create-db-instance de la AWS CLI para crear un
clúster de base de datos de Aurora MySQL nuevo. Cuando llame al comando create-db-cluster,
incluya el parámetro --replication-source-identifier para identificar el Nombre de recurso de
Amazon (ARN) de la instancia de base de datos MySQL de origen. Para obtener más información sobre
los ARN de Amazon RDS, consulte Amazon Relational Database Service (Amazon RDS).
No especifique el nombre de usuario maestro, la contraseña maestra o el nombre de la base de datos, ya

que la réplica de lectura de Aurora usa el mismo nombre de usuario maestro, la misma contraseña maestra
y el mismo nombre de base de datos que la instancia de base de datos MySQL de origen.
aws rds create-db-cluster --db-cluster-identifier sample-replica-cluster --engine aurora \

--db-subnet-group-name mysubnetgroup --vpc-security-group-ids sg-c7e5b0d2 \
--replication-source-identifier arn:aws:rds:us-west-2:123456789012:db:master-mysql-
instance
Para Windows:
aws rds create-db-cluster --db-cluster-identifier sample-replica-cluster --engine aurora ^

--db-subnet-group-name mysubnetgroup --vpc-security-group-ids sg-c7e5b0d2 ^
--replication-source-identifier arn:aws:rds:us-west-2:123456789012:db:master-mysql-
instance
Si usa la consola para crear un clúster de base de datos de Aurora, Amazon RDS crea automáticamente la
instancia principal de la réplica de lectura de Aurora del clúster de base de datos. Si usa la AWS CLI para
crear una réplica de lectura de Aurora, debe crear expresamente la instancia principal del clúster de base
de datos. La instancia principal es la primera instancia que se crea en un clúster de base de datos.
Puede crear una instancia principal para el clúster de base de datos con el comando create-db-
instance de la AWS CLI y los siguientes parámetros.

538
El nombre del clúster de base de datos.

• --db-instance-class
El nombre de la clase de instancia de base de datos que se va a utilizar para la instancia principal.
• --db-instance-identifier
El nombre de la instancia principal.

• --engine aurora
En este ejemplo, va a crear una instancia principal llamada myreadreplicainstance para el clúster de
base de datos llamado myreadreplicacluster con la clase de instancia de base de datos especificada
en myinstanceclass.
Example

--db-cluster-identifier myreadreplicacluster \
--db-instance-class myinstanceclass
--db-instance-identifier myreadreplicainstance \
--engine aurora
Para Windows:

--engine aurora
API
Para crear una réplica de lectura de Aurora a partir de una instancia de base de datos MySQL de origen,
use los comandos CreateDBCluster y CreateDBInstance de la API de Amazon RDS para crear una
instancia principal y un nuevo clúster de base de datos de Aurora. No especifique el nombre de usuario
maestro, la contraseña maestra o el nombre de la base de datos, ya que la réplica de lectura de Aurora
usa el mismo nombre de usuario maestro, la misma contraseña maestra y el mismo nombre de base de
datos que la instancia de base de datos MySQL de origen.
Puede crear un nuevo clúster de base de datos de Aurora para una réplica de lectura de Aurora a partir
de una instancia de base de datos MySQL de origen con el comando CreateDBCluster de la API de
Amazon RDS y los siguientes parámetros:

• DBSubnetGroupName
El nombre del grupo de subredes de la base de datos que desea asociar con este clúster de base de
datos.
• Engine=aurora
• KmsKeyId

539
La clave de cifrado de AWS Key Management Service (AWS KMS) para cifrar, si lo desea, el clúster de
base de datos en función de si la instancia de base de datos MySQL está cifrada o no.
• Si la instancia de base de datos MySQL no está cifrada, especifique una clave de cifrado para cifrar el
clúster de base de datos en reposo. De lo contrario, el clúster de base de datos se cifrará en reposo
con la clave de cifrado predeterminada para la cuenta.
• Si la instancia de base de datos MySQL está cifrada, especifique una clave de cifrado para cifrar el
clúster de base de datos en reposo con la clave de cifrado especificada. De lo contrario, el clúster de
base de datos se cifrará en reposo con la clave de cifrado de la instancia de base de datos MySQL.
Note
No puede crear un clúster de base de datos sin cifrar a partir de una instancia de base de
datos MySQL cifrada.
• ReplicationSourceIdentifier
El nombre de recurso de Amazon (ARN) de la instancia de base de datos MySQL de origen. Para
(Amazon RDS).
• VpcSecurityGroupIds
La lista de grupos de seguridad de VPC de EC2 que se va a asociar con este clúster de base de datos.
En este ejemplo, se crea un clúster de base de datos llamado myreadreplicacluster a partir de una
instancia de base de datos MySQL de origen con un ARN definido en mysqlmasterARN, asociado con
un grupo de subredes de base de datos llamado mysubnetgroup y un grupo de seguridad de la VPC
llamado mysecuritygroup.
Example
?Action=CreateDBCluster
&DBClusterIdentifier=myreadreplicacluster
&DBSubnetGroupName=mysubnetgroup
&Engine=aurora
&ReplicationSourceIdentifier=mysqlmasterARN
&SignatureVersion=4
&Version=2014-10-31
&VpcSecurityGroupIds=mysecuritygroup
&X-Amz-Date=20150927T164851Z
&X-Amz-Signature=6a8f4bd6a98f649c75ea04a6b3929ecc75ac09739588391cd7250f5280e716db
Si usa la consola para crear un clúster de base de datos Aurora, Amazon RDS crea automáticamente la
instancia principal de la réplica de lectura de Aurora del clúster de base de datos. Si usa la AWS CLI para
crear una réplica de lectura de Aurora, debe crear expresamente la instancia principal del clúster de base
de datos. La instancia principal es la primera instancia que se crea en un clúster de base de datos.
Puede crear una instancia principal para el clúster de base de datos con el comando CreateDBInstance
de la API de Amazon RDS y los siguientes parámetros:

• DBInstanceClass

540
• DBInstanceIdentifier

• Engine=aurora
En este ejemplo, va a crear una instancia principal llamada myreadreplicainstance para el clúster de
base de datos llamado myreadreplicacluster con la clase de instancia de base de datos especificada
en myinstanceclass.
Example
?Action=CreateDBInstance
&DBInstanceClass=myinstanceclass
&DBInstanceIdentifier=myreadreplicainstance
&Engine=aurora
&SignatureVersion=4
&Version=2014-09-01
&X-Amz-Date=20140424T194844Z
&X-Amz-Signature=bee4aabc750bf7dad0cd9e22b952bd6089d91e2a16592c2293e532eeaab8bc77
Visualización de una réplica de lectura de Aurora

Puede ver las relaciones de replicación de MySQL con Aurora MySQL de los clústeres de base de datos
Aurora MySQL usando la Consola de administración de AWS o la AWS CLI.
Para ver la instancia de base de datos MySQL maestra para una réplica de lectura de Aurora
3. Elija el clúster de base de datos la réplica de lectura de Aurora para mostrar sus detalles. La
información de la instancia de base de datos MySQL maestra está en el campo Replication source
(Origen de replicación).

541
CLI
Para ver las relaciones de replicación de MySQL con Aurora MySQL de los clústeres de base de datos de
Aurora MySQL mediante la AWS CLI, utilice los comandos describe-db-clusters y describe-db-
instances.
Para determinar qué instancia de base de datos MySQL es la instancia maestra, utilice describe-db-
clusters y especifique el identificador de clúster de la réplica de lectura de Aurora para la opción --db-
cluster-identifier. Consulte el elemento ReplicationSourceIdentifier de la salida para ver el
ARN de la instancia de base de datos que es el maestro de replicación.
Para determinar qué clúster de base de datos es la réplica de lectura de Aurora, utilice describe-db-
instances y especifique el identificador de la instancia de base de datos MySQL para la opción --db-
instance-identifier. Consulte el elemento ReadReplicaDBClusterIdentifiers de la salida
para ver el identificador del clúster de base de datos la réplica de lectura de Aurora.

542
Example
aws rds describe-db-clusters \

--db-cluster-identifier myreadreplicacluster
aws rds describe-db-instances \

--db-instance-identifier mysqlmaster
Para Windows:
aws rds describe-db-clusters ^

aws rds describe-db-instances ^

--db-instance-identifier mysqlmaster
Promoción de una réplica de lectura de Aurora

Cuando la migración haya finalizado, puede promover la réplica de lectura de Aurora a un clúster de base
de datos independiente y dirigir sus aplicaciones de cliente al punto de enlace para la réplica de lectura de
Aurora. Para obtener más información acerca de los puntos de enlace de Aurora, consulte Administración
de conexiones de Amazon Aurora (p. 3). La promoción debe completarse relativamente rápido, y podrá
leer y escribir en la réplica de lectura de Aurora durante la promoción. Sin embargo, no podrá eliminar la
instancia de base de datos MySQL maestra ni desvincular la instancia de base de datos y la réplica de
lectura de Aurora durante ese tiempo.
Antes de promocionar la réplica de lectura de Aurora, detenga la escritura de transacciones en la instancia

de base de datos MySQL de origen y espere hasta que el retardo de la réplica de lectura de Aurora llegue
a 0. Puede ver el retardo de una réplica de lectura de Aurora llamando al comando SHOW SLAVE STATUS
en la réplica de lectura de Aurora y leyendo el valor de Seconds behind master (Segundos detrás del
maestro).
Puede comenzar escribiendo en la réplica de lectura de Aurora cuando las transacciones de escritura en
el maestro se hayan detenido y el retardo de la réplica sea 0. Si escribe en la réplica de lectura de Aurora
antes de esto y modifica tablas que también se están modificando en el maestro de MySQL, se arriesga a
interrumpir la replicación en Aurora. Si ocurre esto, tendrá que eliminar y volver a crear la réplica de lectura
de Aurora.
Después de promocionar, confirme que la promoción se ha completado eligiendo Instances (Instancias) en

el panel de navegación y confirmando que hay un evento Promoted Read Replica cluster to stand-alone
database cluster (Clúster de réplica de lectura promovido a clúster de base de datos independiente) para la
réplica de lectura de Aurora. Una vez que se haya completado la promoción, la instancia de base de datos
MySQL maestra y la réplica de lectura de Aurora se desvincularán y podrá eliminar sin riesgo la instancia
de base de datos si lo desea.
Para promover una réplica de lectura de Aurora a un clúster de base de datos Aurora

543
Administración de Aurora MySQL
3. Elija la instancia de base de datos la réplica de lectura de Aurora y elija Promote read replica
(Promocionar réplica de lectura) en Actions (Acciones).
4. Elija Promote Read Replica.
CLI
Para promocionar una réplica de lectura de Aurora a un clúster de base de datos independiente, utilice el
comando promote-read-replica-db-cluster de la AWS CLI.
Example
aws rds promote-read-replica-db-cluster \

Para Windows:
aws rds promote-read-replica-db-cluster ^

Administración de Amazon Aurora MySQL

En las siguientes secciones se analiza la administración de un clúster de base de datos de Amazon Aurora
MySQL.
Temas
• Administración del desempeño y el escalado para Amazon Aurora MySQL (p. 544)
• Búsqueda de datos anteriores de un clúster de base de datos de Aurora (p. 546)
• Pruebas de Amazon Aurora por medio de consultas de inserción de errores (p. 561)
• Modificación de las tablas de Amazon Aurora con operaciones DDL rápidas (p. 564)
• Visualización del estado del volumen para un clúster de base de datos de Aurora (p. 565)
Administración del desempeño y el escalado para

Amazon Aurora MySQL
Escalado de las instancias de base de datos Aurora MySQL
Puede escalar las instancias de base de datos Aurora MySQL de dos formas, mediante el escalado de
instancia y mediante el escalado de lectura. Para obtener más información acerca del escalado de lectura,
consulte Escalado de lectura (p. 258).
Puede escalar el clúster de base de datos Aurora MySQL como considere necesario modificando la clase
de instancia de base de datos para cada instancia de base de datos del clúster de base de datos. Aurora
MySQL admite varias clases de instancia de base de datos optimizadas para Aurora. En la siguiente tabla
se describen las especificaciones de las clases de instancia de base de datos compatibles con Aurora
MySQL.

544
Administración del desempeño y el
escalado para Amazon Aurora MySQL
Clase de instancia vCPU ECU Memoria (GiB)
db.t2.small 1 1 2
db.t2.medium 2 2 4
db.r3.large 2 6.5 15.25
db.r3.xlarge 4 13 30.5
db.r3.2xlarge 8 26 61
db.r3.4xlarge 16 52 122
db.r3.8xlarge 32 104 244
db.r4.large 2 7 15.25
db.r4.xlarge 4 13.5 30.5
db.r4.2xlarge 8 27 61
db.r4.4xlarge 16 53 122
db.r4.8xlarge 32 99 244
db.r4.16xlarge 64 195 488
Número máximo de conexiones a una instancia de base de datos

Aurora MySQL
El número máximo de conexiones permitidas a una instancia de base de datos Aurora MySQL viene
determinado por el parámetro max_connections del grupo de parámetros de nivel de instancia para la
En la siguiente tabla se indica el valor resultante predeterminado de max_connections para cada clase
de instancia de base de datos disponible para Aurora MySQL. Puede aumentar el número máximo de
conexiones de su instancia de base de datos Aurora MySQL escalando la instancia hasta una clase
de instancia de base de datos con más memoria o definiendo un valor más grande para el parámetro
max_connections, de un máximo de 16 000.
Clase de instancia Valor

predeterminado
de
max_connections
db.t2.small 45
db.t2.medium 90
db.r3.large 1 000
db.r3.xlarge 2000
db.r3.2xlarge 3 000
db.r3.4xlarge 4000

545
Búsqueda de datos anteriores
de un clúster de base de datos
Clase de instancia Valor

predeterminado
de
max_connections
db.r3.8xlarge 5000
db.r4.large 1 000
db.r4.xlarge 2000
db.r4.2xlarge 3 000
db.r4.4xlarge 4000
db.r4.8xlarge 5000
db.r4.16xlarge 6000
Si crea un nuevo grupo de parámetros para personalizar su propio límite de conexión predeterminado,
verá que el límite de conexión predeterminado se obtiene mediante una fórmula basada en el valor
DBInstanceClassMemory. Como se muestra en la tabla anterior, la fórmula produce límites de conexión
que aumentan en 1000 a medida que la memoria se duplica entre instancias R3 y R4 cada vez más
grandes, y en 45 para diferentes tamaños de memoria de instancias T2. Los límites de conectividad
mucho más bajos para las instancias T2 se deben a que las instancias T2 están pensadas solo para
escenarios de desarrollo y pruebas, no para cargas de trabajo de producción. Los límites de conexión
predeterminados se ajustan para los sistemas que utilizan los valores predeterminados para otros
consumidores de memoria importantes, como el grupo del búfer y la caché de consultas. Si cambia esas
otras configuraciones para el clúster, considere ajustar el límite de conexión para tener en cuenta el
aumento o la disminución de la memoria disponible en las instancias de base de datos.
Búsqueda de datos anteriores de un clúster de base

de datos de Aurora
Con Compatibilidad de Amazon Aurora con MySQL puede realizar búsquedas de datos anteriores en un
clúster de base de datos en un momento específico, sin restaurar datos desde un backup.
Información general de búsquedas de datos anteriores

La búsqueda de datos anteriores "rebobina" el clúster de base de datos al momento que especifique.
La búsqueda de datos anteriores no es un sustituto del backup del clúster de base de datos para que
pueda restaurarlo a un momento determinado. No obstante, la búsqueda de datos anteriores presenta las
siguientes ventajas respecto al backup y restauración tradicional:
• Puede deshacer errores con facilidad. Si lleva a cabo una acción destructiva por error, por ejemplo
DELETE sin una cláusula WHERE, puede realizar una búsqueda de datos anteriores del clúster de base
de datos a un momento anterior a la acción destructiva con una interrupción de servicio mínima.
• Puede realizar una búsqueda de datos anteriores en un clúster de base de datos rápidamente. La
restauración de un clúster de base de datos a un momento determinado lanza un nuevo clúster de base
de datos y lo restaura a partir de datos de backup o de una instantánea de clúster de base de datos, lo
que puede tardar horas. La búsqueda de datos anteriores de un clúster de base de datos no requiere un
nuevo clúster de base de datos y rebobina el clúster de base de datos en cuestión de minutos.
• Puede explorar cambios de datos anteriores. Puede realizar búsqueda de datos anteriores de un clúster
de base de datos repetidamente adelante y atrás en el tiempo para ayudar a determinar cuándo se
produjo un cambio de datos particular. Por ejemplo, puede realizar una búsqueda de datos anteriores

546
de un clúster de base de datos de hace tres horas y, a continuación, realizar la búsqueda de datos
anteriores hacia adelante en el tiempo una hora. En este caso, el tiempo de búsqueda de datos
anteriores es dos horas antes de la hora original.
Note
Para obtener más información acerca la restauración de un clúster de base de datos a un

momento determinado, consulte Información general de copias de seguridad y restauración de un
clúster de base de datos Aurora (p. 314).
Ventana de búsqueda de datos anteriores

Con la búsqueda de datos anteriores, hay una ventana de búsqueda de datos anteriores de destino y una
ventana de búsqueda de datos anteriores real:
• La ventana de búsqueda de datos anteriores de destino es la cantidad de tiempo que desea poder
realizar búsqueda de datos anteriores en su clúster de base de datos. Cuando habilita la búsqueda
de datos anteriores, especifica una ventana de búsqueda de datos anteriores de destino. Por ejemplo,
podría especificar una ventana de búsqueda de datos anteriores de 24 horas si desea poder realizar la
búsqueda de datos anteriores del clúster de base de datos un día.
• La ventana de búsqueda de datos anteriores real es la cantidad de tiempo real en la que puede realizar
búsqueda de datos anteriores en su clúster de base de datos, que puede ser inferior a la de la ventana
de búsqueda de datos anteriores de destino. La ventana de búsqueda de datos anteriores real se basa
en su carga de trabajo y en el almacenamiento disponible para información de almacenamiento sobre
cambios de base de datos, denominados registros de cambio.
A medida que actualiza su clúster de base de datos Aurora con la búsqueda de datos anteriores habilitada,
genera registros de cambio. Aurora mantiene los registros de cambios de la ventana de búsqueda de datos
anteriores de destino y paga una tarifa por hora para almacenarlos. Tanto la ventana de búsqueda de
datos anteriores de destino como la carga de trabajo de su clúster de base de datos determinan el número
de registros de cambio que puede almacenar. La carga de trabajo es el número de cambios que realiza
en su clúster de base de datos en un período de tiempo dado. Si la carga de trabajo es pesada, almacena
más registros de cambio en su ventana de búsqueda de datos anteriores de la que tendría si la carga de
trabajo fuera ligera.
Puede entender la ventana de búsqueda de datos anteriores de destino como el objetivo para la cantidad
de tiempo máxima que desea poder realizar la búsqueda de datos anteriores en su clúster de base de
datos. En la mayoría de los casos, puede realizar una búsqueda de datos anteriores del período de
tiempo máximo que haya especificado. No obstante, en algunos casos, el clúster de base de datos no
puede almacenar suficientes registros de cambio para realizar la búsqueda de datos anteriores durante el
período de tiempo máximo y la ventana de búsqueda de datos anteriores real es inferior a la de destino.
Normalmente, la ventana de búsqueda de datos anteriores real es más pequeña que el destino cuando se
tiene una carga de trabajo extremadamente pesada en el clúster de base de datos. Cuando la ventana de
búsqueda de datos anteriores real es inferior al destino, le enviamos una notificación.
Cuando la búsqueda de datos anteriores está habilitada para un clúster de base de datos y elimina una
tabla almacenada en el clúster de base de datos, Aurora mantiene dicha tabla en los registros de cambio
de búsqueda de datos anteriores. Lo hace para que pueda volver a un momento anterior a la eliminación
de la tabla. Si no tiene espacio suficiente en su ventana de búsqueda de datos anteriores para almacenar
la tabla, la tabla podría acabar por eliminarse de los registros de cambios de búsqueda de datos anteriores.
Tiempo de búsqueda de datos anteriores

Aurora siempre realiza la búsqueda de datos anteriores en un momento que sea coherente para el clúster
de base de datos. Al hacerlo así, se elimina la posibilidad de transacciones sin confirmar cuando se ha
completado la búsqueda de datos anteriores. Cuando se especifica una hora para una búsqueda de
datos anteriores, Aurora elige automáticamente la hora coherente más próxima posible. Este enfoque

547
significa que la búsqueda de datos anteriores completada podría no coincidir exactamente con la hora
que especifique, pero puede determinar la hora exacta de una búsqueda de datos anteriores utilizando
el comando describe-db-cluster-backtracks de la CLI de AWS. Para obtener más información, consulte
Recuperar búsqueda de datos anteriores existentes (p. 559).
Limitaciones de la búsqueda de datos anteriores

Las limitaciones siguientes son aplicables a la búsqueda de datos anteriores:
• La búsqueda de datos anteriores solo está disponible en clústeres de base de datos que se crearon
con la característica de búsqueda de datos anteriores habilitada. Puede habilitar la característica de
búsqueda de datos anteriores cuando cree un clúster de base de datos, restaure una instantánea de
un clúster de base de datos o clone un clúster de base de datos. Actualmente, la búsqueda de datos
anteriores no es posible en clústeres de base de datos que se crearon con la característica de búsqueda
de datos anteriores deshabilitada.
• El límite para una ventana de búsqueda de datos anteriores es de 72 horas.
• La búsqueda de datos anteriores afecta a todo el clúster de base de datos. Por ejemplo, puede realizar
la búsqueda de datos anteriores selectivamente en una única tabla o una única actualización de datos.
• La búsqueda de datos anteriores no se admite con replicación del log binario (binlog). La replicación
entre regiones debe estar deshabilitada antes de poder configurar o utilizar la búsqueda de datos
anteriores.
• No puede realizar una búsqueda de datos anteriores de un clon de base de datos a una hora anterior a
la que se creó dicho clon de base de datos. Sin embargo, puede utilizar la base de datos original para
realizar una búsqueda de datos anteriores a un momento anterior a la creación del clon. Para obtener
más información acerca de la clonación de la base de datos, consulte Clonación de bases de datos en
un clúster de bases de datos de Aurora (p. 282).
• La búsqueda de datos anteriores provoca una breve interrupción de la instancia de base de datos. Debe
detener o pausar las aplicaciones antes de iniciar una operación de búsqueda de datos anteriores para
asegurarse de que no haya ninguna solicitud nueva de lectura o escritura. Durante la operación de
búsqueda de datos anteriores, Aurora pone en pausa la base de datos, cierra las conexiones abiertas y
borra las lecturas y escrituras sin confirmar. A continuación, espera a que se complete la operación de
búsqueda de datos anteriores.
• La búsqueda de datos anteriores solo se admite en Aurora MySQL 5.6. No es compatible con Aurora
MySQL 5.7. Debido a esta limitación, no puede seguir actualmente determinadas rutas de actualización
de Aurora MySQL 5.6 a 5.7 si ha creado el clúster de Aurora MySQL 5.6 con la configuración de
búsqueda de datos anteriores habilitada:
• No puede restaurar una instantánea del clúster de base de datos de Aurora MySQL 5.6 en Aurora
MySQL 5.7.
• No puede realizar una recuperación a un momento dado en el clúster de base de datos de Aurora
MySQL 5.6 para restaurarla a Aurora MySQL 5.7.
Estas limitaciones se siguen aplicando incluso si desactiva la búsqueda de datos anteriores para el
clúster de Aurora MySQL 5.6.
• La búsqueda de datos anteriores no se admite en la región China (Ningxia).
Configuración de la búsqueda de datos anteriores

Para utilizar la característica de búsqueda de datos anteriores, debe habilitar la búsqueda de datos
anteriores y especificar una ventana de búsqueda de datos anteriores de destino. De lo contrario, se
deshabilita la búsqueda de datos anteriores.
Para la ventana de búsqueda de datos anteriores de destino, especifique la cantidad de tiempo que desea
poder rebobinar la base de datos utilizando la búsqueda de datos anteriores. Aurora intenta mantener
suficientes registros de cambio para admitir esa ventana de tiempo.

548
Consola
Puede utilizar la consola para configurar la búsqueda de datos anteriores cuando se crea un nuevo clúster
de base de datos. También puede modificar un clúster de base de datos para habilitar la búsqueda de
datos anteriores.
Temas
• Configuración de la búsqueda de datos anteriores con la consola al crear un clúster de base de
datos (p. 549)
• Configuración de la búsqueda de datos anteriores con la consola al modificar un clúster de base de
datos (p. 550)
Configuración de la búsqueda de datos anteriores con la consola al crear un clúster de base de

datos
Cuando se crea un nuevo clúster de base de datos Aurora MySQL, la búsqueda de datos anteriores está
configurada cuando elige Enable Backtrack (Habilitar búsqueda de datos anteriores) y especifica un valor
de Target Backtrack window (Ventana de búsqueda de datos anteriores de destino) que sea mayor que
cero en la sección Backtrack (Búsqueda de datos anteriores).
Para crear un clúster de base de datos, siga las instrucciones en Creación de un clúster de base de
datos de Amazon Aurora (p. 85). La imagen siguiente muestra la sección Backtrack (Búsqueda de datos
anteriores).
Cuando se crea un nuevo clúster de base de datos, Aurora no tiene ningún dato para la carga de trabajo
del clúster de base de datos. Por tanto, no puede estimar un costo específicamente para el nuevo clúster
de base de datos. En lugar de ello, la consola presenta un costo de usuario típico para la ventana de
búsqueda de datos anteriores de destino basado en una carga de trabajo típica. El costo típico tiene como
objetivo proporcionar una referencia general para el costo de la característica de búsqueda de datos
anteriores.
Important
El costo real podría no coincidir con el costo típico, ya que el costo real se basa en la carga de
trabajo de su clúster de base de datos.

549
Configuración de la búsqueda de datos anteriores con la consola al modificar un clúster de base

de datos
Puede modificar la búsqueda de datos anteriores de un clúster de base de datos utilizando la consola.
Para modificar la búsqueda de datos anteriores de un clúster de base de datos utilizando la

consola
3. Elija el clúster que desea modificar y elija Modify (Modificar).
4. Si la búsqueda de datos anteriores está deshabilitada en la sección Backtrack (Búsqueda de datos
anteriores), elija Enable Backtrack (Habilitar búsqueda de datos anteriores).
Note
Actualmente, puede habilitar la búsqueda de datos anteriores solo para un clúster de base
de datos que se creó con la característica de búsqueda de datos anteriores habilitada.
La sección Backtrack no aparece para un clúster de base de datos que se creó con la
característica de búsqueda de datos anteriores deshabilitada.
5. Para la Target Backtrack window (Ventana de búsqueda de datos anteriores de destino), modifique la
cantidad de tiempo que desea poder realizar la búsqueda de datos anteriores. El límite son 72 horas.
La consola muestra el costo estimado para la cantidad de tiempo que ha especificado en función de la
carga de trabajo pasada del clúster de base de datos:
• Si la búsqueda de datos anteriores se deshabilitó en el clúster de base de datos, la estimación

de costo se basa en la métrica VolumeWriteIOPS para el clúster de base de datos en Amazon
CloudWatch.
• Si la búsqueda de datos anteriores se habilitó anteriormente en el clúster de base de datos, la
estimación de costo se basa en la métrica BacktrackChangeRecordsCreationRate para el
clúster de base de datos en Amazon CloudWatch.
6. Elija Continue.

550
• Apply during the next scheduled maintenance window (Aplicar durante la próxima ventana
de mantenimiento programada): espere para aplicar la modificación de Target Backtrack
window (Ventana de búsqueda de datos anteriores de destinos) hasta la próxima ventana de
mantenimiento.
• Apply immediately (Aplicar inmediatamente): aplique la modificación de Target Backtrack window
(Ventana de búsqueda de datos anteriores de destino) lo antes posible.
AWS CLI
Cuando se crea un nuevo clúster de base de datos de Aurora MySQL utilizando el comando create-db-
cluster de la CLI de AWS, la búsqueda de datos anteriores se configura cuando se especifica un valor
de --backtrack-window mayor que cero. El valor --backtrack-window especifica la ventana de
búsqueda de datos anteriores de destino. Para obtener más información, consulte Creación de un clúster
de base de datos de Amazon Aurora (p. 85).
También puede especificar el valor --backtrack-window utilizando los siguientes comandos de la CLI
de AWS:
• modify-db-cluster
• restore-db-cluster-from-s3
• restore-db-cluster-from-snapshot
El siguiente procedimiento describe cómo modificar la ventana de búsqueda de datos anteriores de destino
para un clúster de base de datos utilizando la AWS CLI.
Para modificar la ventana de búsqueda de datos anteriores de destino para un clúster de base de
datos utilizando la AWS CLI
• Llame al comando modify-db-cluster de la CLI de AWS y suministre los siguientes valores:

• --backtrack-window: el número máximo de segundos que desea poder realizar una búsqueda
de datos anteriores en el clúster de base de datos.
En el siguiente ejemplo, se establece la ventana de búsqueda de datos anteriores de destino para

sample-cluster en un día (86 400 segundos).

--backtrack-window 86400
Para Windows:


551
Note
Actualmente, puede habilitar la búsqueda de datos anteriores solo para un clúster de base de
datos que se creó con la característica de búsqueda de datos anteriores habilitada.
API de RDS
Cuando se crea un nuevo clúster de base de datos de Aurora MySQL utilizando la acción CreateDBCluster
de la API de Amazon RDS, la búsqueda de datos anteriores se configura cuando se especifica un
valor de BacktrackWindow mayor que cero. El valor BacktrackWindow especifica la ventana de
búsqueda de datos anteriores de destino para el clúster de base de datos especificado en el valor
DBClusterIdentifier. Para obtener más información, consulte Creación de un clúster de base de
datos de Amazon Aurora (p. 85).
También puede especificar el valor BacktrackWindow utilizando las siguientes acciones de la API:
• ModifyDBCluster
• RestoreDBClusterFromS3
Note
Actualmente, puede habilitar la búsqueda de datos anteriores solo para un clúster de base de
datos que se creó con la característica de búsqueda de datos anteriores habilitada.
Realización de una búsqueda de datos anteriores

Puede realizar una búsqueda de datos anteriores de un clúster de base de datos a una marca temporal de
búsqueda de datos anteriores especificada. Si la marca temporal de búsqueda de datos anteriores no es
anterior al tiempo de búsqueda de datos anteriores más temprano posible y no se encuentra en el futuro,
se realiza la búsqueda de datos anteriores del clúster de base de datos a dicha marca temporal.
En caso contrario, se suele producir un error. Además, si intenta realizar una búsqueda de datos anteriores
en un clúster de base de datos para el que está habilitado el registro binario, suele producirse un error
normalmente, a menos que haya elegido forzar la búsqueda de datos anteriores. El forzado de una
búsqueda de datos anteriores puede interferir con otras operaciones que utilicen el registro binario.
Important
La búsqueda de datos anteriores no genera entradas de log binario para los cambios que realiza.
Si tiene habilitado el registro binario para el clúster de base de datos, la búsqueda de datos
anteriores podría no ser compatible con la implementación de log binario.
Note
Para los clones de base de datos, no puede realizar una búsqueda de datos anteriores del clúster
de base de datos antes de la fecha y hora en la que se creó el clon. Para obtener más información
acerca de la clonación de la base de datos, consulte Clonación de bases de datos en un clúster
de bases de datos de Aurora (p. 282).
Consola
El siguiente procedimiento describe cómo realizar una operación de búsqueda de datos anteriores para un
clúster de base de datos utilizando la consola.

552
Para realizar una operación de búsqueda de datos anteriores utilizando la consola
3. Elija la instancia principal del clúster de la base de datos en la que desea realizar la búsqueda de
datos anteriores.
4. En Actions (Acciones), elija (Clúster de base de datos de búsqueda de datos anteriores).
5. En la página Backtrack DB cluster (Realizar búsqueda de datos anteriores de clúster de base de
datos), especifique la marca temporal de búsqueda de datos anteriores en la que realizar la búsqueda
de datos anteriores en el clúster de base de datos.
6. Elija Backtrack DB cluster (Realizar búsqueda de datos anteriores en clúster de base de datos).
AWS CLI
El siguiente procedimiento describe cómo realizar una búsqueda de datos anteriores en un clúster de base
de datos usando la AWS CLI.
Para realizar una búsqueda de datos anteriores de un clúster de base de datos utilizando la AWS
CLI
• Llame al comando backtrack-db-cluster de la CLI de AWS y suministre los siguientes valores:

• --backtrack-to: la marca temporal de búsqueda de datos anteriores para realizar la búsqueda
de datos anteriores en el clúster de base de datos, especificada en formato ISO 8601.
El siguiente ejemplo realiza una búsqueda de datos anteriores en el clúster de base de datos
sample-cluster el 19 de marzo de 2018 a las 10:00 h.
aws rds backtrack-db-cluster \

553
--backtrack-to 2018-03-19T10:00:00+00:00
Para Windows:
aws rds backtrack-db-cluster ^

--backtrack-to 2018-03-19T10:00:00+00:00
API de RDS
Para realizar una búsqueda de datos anteriores en un clúster de base de datos utilizando la API de
Amazon RDS, utilice la acción BacktrackDBCluster. Esta acción realiza una búsqueda de datos anteriores
en el clúster de base de datos especificado en el valor DBClusterIdentifier a la hora especificada.
Monitoreo de la búsqueda de datos anteriores

Puede ver información de búsqueda de datos anteriores y monitorear métricas de búsqueda de datos
anteriores para un clúster de base de datos.
Consola
Para ver información de búsqueda de datos anteriores y monitorear métricas de búsqueda de

datos anteriores utilizando la consola
3. Elija el nombre del clúster de búsqueda de datos anteriores para abrir información sobre el mismo.
La información de búsqueda de datos anteriores se encuentra en la sección Backtrack (Búsqueda de

datos anteriores).
Cuando la búsqueda de datos anteriores está habilitada, está disponible la información siguiente:
• Target window (Ventana de destino): la cantidad de tiempo actual especificada para la ventana de
búsqueda de datos anteriores de destino. El objetivo es la cantidad de tiempo máxima que puede
realizar la búsqueda de datos anteriores si hay suficiente almacenamiento.

554
• Actual window (Ventana real): la cantidad de tiempo real que puede realizar la búsqueda de
datos anteriores, que puede ser inferior a la ventana de búsqueda de datos anteriores de
destino. La ventana de búsqueda de datos anteriores real se basa en su carga de trabajo y en
el almacenamiento disponible para mantener los registros de cambio de búsqueda de datos
anteriores.
• Earliest backtrack time (Tiempo de búsqueda de datos anteriores más temprano): el tiempo de
búsqueda de datos anteriores más temprano posible para el clúster de base de datos. No puede
realizar una búsqueda de datos anteriores de un clúster de base de datos de un momento anterior
al tiempo mostrado.
4. Realice lo siguiente para ver las métricas de búsqueda de datos anteriores del clúster de base de
datos:
a. En el panel de navegación, seleccione Instances (Instancias).

b. Elija el nombre de la instancia principal del clúster de base de datos para mostrar sus detalles.
c. En la sección CloudWatch, escriba Backtrack en el recuadro CloudWatch para mostrar solo las
métricas de búsqueda de datos anteriores.
Se muestran las siguientes métricas:

555
• Backtrack Change Records Creation Rate (Count) [Tasa de creación de registros de cambio
de búsqueda de datos anteriores (Recuento)]: esta métrica muestra el número de registros
de cambio de búsqueda de datos anteriores creados durante cinco minutos para su clúster
de base de datos. Puede utilizar esta métrica para estimar el costo de búsqueda de datos
anteriores de su ventana de búsqueda de datos anteriores de destino.
• [Billed] Backtrack Change Records Stored (Count) ([Facturado] Registros de cambio de
búsqueda de datos anteriores almacenados [Recuento]): esta métrica muestra el número real
de registros de cambio de búsqueda de datos anteriores utilizados por su clúster de base de
datos.
• Backtrack Window Actual (Minutes) [Ventana de búsqueda de datos anteriores real (Minutos)]:
esta métrica muestra si hay una diferencia entre la ventana de búsqueda de datos anteriores
de destino y la ventana de búsqueda de datos anteriores real. Por ejemplo, si su ventana de
búsqueda de datos anteriores de destino es de 2 horas (120 minutos) y esta métrica muestra
que la ventana de búsqueda de datos anteriores real es de 100 minutos, entonces la ventana
de búsqueda de datos anteriores real es inferior al destino.
• Backtrack Window Alert (Count) [Alerta de ventana de búsqueda de datos anteriores
(Recuento)]: esta métrica muestra con qué frecuencia la ventana de búsqueda de datos
anteriores real es inferior a la ventana de búsqueda de datos anteriores de destino para un
período de tiempo dado.
Note
Las métricas siguientes podrían llevar un retardo detrás de la hora actual:
• Backtrack Change Records Creation Rate (Count) [Tasa de creación de registros de

cambio de búsqueda de datos anteriores (Recuento)]
• [Billed] Backtrack Change Records Stored (Count) ([Facturado] Registros de cambio
de búsqueda de datos anteriores almacenados [Recuento])
AWS CLI
El siguiente procedimiento describe cómo ver la información de búsqueda de datos anteriores para un
clúster de base de datos utilizando la AWS CLI.
Para ver la información de búsqueda de datos anteriores de un clúster de base de datos utilizando
AWS CLI
• Llame al comando describe-db-clusters de la CLI de AWS y suministre los siguientes valores:
El ejemplo siguiente enumera información de búsqueda de datos anteriores para sample-cluster.
aws rds describe-db-clusters \

--db-cluster-identifier sample-cluster
Para Windows:
aws rds describe-db-clusters ^

556
API de RDS
Para ver la información de búsqueda de datos anteriores para un clúster de base de datos utilizando la API
de Amazon RDS, utilice la acción DescribeDBClusters. Esta acción devuelve la información de búsqueda
de datos anteriores para el clúster de base de datos especificada en el valor DBClusterIdentifier.
Suscripción a un evento de búsqueda de datos anteriores con la

consola
El siguiente procedimiento describe cómo suscribirse a un evento de búsqueda de datos anteriores
utilizando la consola. El evento le envía una notificación de correo electrónico o texto cuando su ventana
de búsqueda de datos anteriores real es inferior a su ventana de búsqueda de datos anteriores de destino.
Para ver información de búsqueda de datos anteriores mediante la consola
2. Elija Event subscriptions (Suscripciones de evento).
3. Seleccione Create event subscription (Crear suscripción de evento).
4. En el cuadro Name (Nombre), escriba un nombre para la suscripción de evento y asegúrese de que se
haya seleccionado Yes (Sí) en Enabled (Habilitado).
5. En la sección Target (Destino), elija New email topic (Nuevo tema de correo electrónico).
6. Para Topic name (Nombre de tema), escriba un nombre para el tema y para With these recipients
(Con estos destinatarios), introduzca las direcciones de correo electrónico o los números de teléfono
para recibir las notificaciones.
7. En la sección Source (Origen), elija Instances (Instancias) para Source type (Tipo de origen).
8. Para Instances to include (Instancias que incluir), elija Select specific instances (Seleccionar instancias
específicas) y elija su instancia de base de datos.
9. Para Event categories to include (Categorías de evento que incluir), elija Select specific event
categories (Seleccionar categorías de evento específicas) y elija backtrack (búsqueda de datos
anteriores).
La página debería tener un aspecto similar a la página siguiente.

557

558
Recuperar búsqueda de datos anteriores existentes

Puede recuperar información de búsquedas de datos anteriores existentes para un clúster de base de
datos. Esta información incluye el identificador único de la búsqueda de datos anteriores, la fecha y la
hora para realizar la búsqueda de datos anteriores de inicio y final, la fecha y la hora a la que se solicitó la
búsqueda de datos anteriores y el estado actual de la búsqueda de datos anteriores.
Note
Actualmente no se pueden recuperar las búsquedas de datos anteriores existentes utilizando la

consola.
AWS CLI
El siguiente procedimiento describe cómo recuperar las búsquedas de datos anteriores existentes para un
clúster de base de datos utilizando la AWS CLI.
Para recuperar búsquedas de datos anteriores existentes utilizando la AWS CLI
• Llame al comando describe-db-cluster-backtracks de la CLI de AWS y suministre los siguientes

valores:
El ejemplo siguiente recuperar búsquedas de datos anteriores existentes para sample-cluster.
aws rds describe-db-cluster-backtracks \

Para Windows:
aws rds describe-db-cluster-backtracks ^

API de RDS
Para recuperar información sobre las búsquedas de datos anteriores para un clúster de base de datos
utilizando la API de Amazon RDS, utilice la acción DescribeDBClusterBacktracks. Esta acción devuelve la
información acerca de las búsquedas de datos anteriores para el clúster de base de datos especificada en
el valor DBClusterIdentifier.
Deshabilitar la búsqueda de datos anteriores para un clúster de

base de datos
Puede deshabilitar la característica de búsqueda de datos anteriores para un clúster de base de datos.

559
Consola
Puede deshabilitar la búsqueda de datos anteriores de un clúster de base de datos utilizando la consola.
Para deshabilitar la característica de búsqueda de datos anteriores de un clúster de base de datos

utilizando la consola
3. Elija el clúster que desea modificar y elija Modify (Modificar).
4. En la sección Backtrack (Búsqueda de datos anteriores), seleccione Disable Backtrack (Deshabilitar
búsqueda de datos anteriores).
5. Elija Continue.
• Apply during the next scheduled maintenance window (Aplicar durante la próxima ventana de
mantenimiento programada): espere para aplicar la modificación hasta la próxima ventana de
mantenimiento.
• Apply immediately (Aplicar inmediatamente): aplique la modificación lo antes posible.
AWS CLI
Puede deshabilitar la característica de búsqueda de datos anteriores de un clúster de base de datos

utilizando la AWS CLI estableciendo la ventana de búsqueda de datos anteriores de destino en 0 (cero).
Para modificar la ventana de búsqueda de datos anteriores de destino para un clúster de base de
datos utilizando la AWS CLI
• Llame al comando modify-db-cluster de la CLI de AWS y suministre los siguientes valores:

• --backtrack-window: 0.
El ejemplo siguiente deshabilita la característica de búsqueda de datos anteriores para el sample-

cluster estableciendo --backtrack-window en 0.

Para Windows:


560
Pruebas de Amazon Aurora por medio
de consultas de inserción de errores
API de RDS
Para deshabilitar la característica de búsqueda de datos anteriores de un clúster de base

de datos utilizando la API de Amazon RDS, utilice la acción ModifyDBCluster. Establezca el
valor BacktrackWindow en 0 (cero) y especifique el clúster de base de datos en el valor
DBClusterIdentifier.
Pruebas de Amazon Aurora por medio de consultas de

inserción de errores
Puede probar la tolerancia a errores de su clúster de base de datos de Amazon Aurora usando consultas
de inserción de errores. Las consultas de inserción de errores se ejecutan como comandos SQL en una
instancia de Amazon Aurora y permiten programar una simulación de uno de los siguientes eventos:
• Un bloqueo de la instancia maestra o de una réplica de Aurora

• Un error de una réplica de Aurora
• Un error de disco
• Congestión del disco
Las consultas de inserción de errores que especifican un bloqueo fuerzan un bloqueo de la instancia de
Amazon Aurora. Las otras consultas de inserción de errores producen simulaciones de eventos de error,
pero no hacen que el evento ocurra. Cuando se envía una consulta de inserción de errores, se especifica
también la cantidad de tiempo que debe durar la simulación del evento de error.
Puede enviar una consulta de inserción de errores a una de las instancias de réplica de Aurora
conectándose al punto de enlace de la réplica de Aurora. Para obtener más información, consulte
Administración de conexiones de Amazon Aurora (p. 3).
Prueba de un bloqueo de instancia

Puede forzar el bloqueo de una instancia de Amazon Aurora usando la consulta de inserción de errores
ALTER SYSTEM CRASH.
En esta consulta de inserción de errores no se produce una conmutación por error. Si desea probar una
conmutación por error, puede elegir la acción de instancia Failover (Conmutación por error) para el clúster
de base de datos en la consola de RDS o usar el comando failover-db-cluster de la AWS CLI o la acción
FailoverDBCluster de la API de RDS.
Sintaxis
ALTER SYSTEM CRASH [ INSTANCE | DISPATCHER | NODE ];
Opciones
La consulta de inserción de errores toma uno de los siguientes tipos de bloqueos:
• INSTANCE: se simula un bloqueo de la base de datos compatible con MySQL para la instancia de
Amazon Aurora.
• DISPATCHER: se simula un bloqueo del distribuidor de la instancia maestra del clúster de base de datos
Aurora. El distribuidor escribe actualizaciones en el volumen de clúster de un clúster de base de datos
Amazon Aurora.
• NODE: se simula un bloqueo de la base de datos compatible con MySQL y del distribuidor para la
instancia de Amazon Aurora. En esta simulación de inserción de errores también se elimina la caché.

561
El tipo de bloqueo predeterminado es INSTANCE.
Prueba de un error de una réplica de Aurora

Puede simular el error de una réplica de Aurora usando la consulta de inserción de errores ALTER
SYSTEM SIMULATE READ REPLICA FAILURE.
Un error de réplica de Aurora bloqueará todas las solicitudes realizadas a una réplica de Aurora o a todas
las réplicas de Aurora del clúster de base de datos durante un intervalo de tiempo especificado. Cuando se
complete el intervalo de tiempo, las réplicas de Aurora afectadas se sincronizarán automáticamente con la
instancia maestra.
Sintaxis
ALTER SYSTEM SIMULATE percentage_of_failure PERCENT READ REPLICA FAILURE

[ TO ALL | TO "replica name" ]
FOR INTERVAL quantity { YEAR | QUARTER | MONTH | WEEK | DAY | HOUR | MINUTE | SECOND };
Opciones
Esta consulta de inserción de errores toma los siguientes parámetros:
• percentage_of_failure: el porcentaje de solicitudes que se deben bloquear durante el evento de

error. Puede ser un valor doble entre 0 y 100. Si se especifica 0, no se bloquea ninguna solicitud. Si se
especifica 100, se bloquean todas las solicitudes.
• Failure type (Tipo de error): el tipo de error que se va a simular. Especifique TO ALL para simular
errores para todas las réplicas de Aurora del clúster de base de datos. Especifique TO y el nombre de la
réplica de Aurora para simular un error de una única réplica de Aurora. El tipo de error predeterminado
es TO ALL.
• quantity: la cantidad de tiempo que debe durar la simulación del error de la réplica de Aurora. El
intervalo es una cantidad seguida por una unidad de tiempo. La simulación durará esa cantidad de la
unidad especificada. Por ejemplo, 20 MINUTE hará que la simulación se ejecute durante 20 minutos.
Note
Debe tener cuidado al especificar el intervalo de tiempo del evento de error de la réplica de
Aurora. Si especifica un intervalo de tiempo demasiado largo y la instancia maestra escribe una
gran cantidad de datos durante el evento de error, su clúster de base de datos de Aurora podría
entender que la réplica de Aurora se ha bloqueado y reemplazarla.
Prueba de un error de disco

Puede simular un error de disco para un clúster de base de datos Aurora usando la consulta de inserción
de errores ALTER SYSTEM SIMULATE DISK FAILURE.
Durante la simulación de un error de disco, el clúster de base de datos de Aurora marca de forma aleatoria
los segmentos de disco como defectuosos. Las solicitudes que lleguen a esos segmentos se bloquearán
mientras dure la simulación.
Sintaxis
ALTER SYSTEM SIMULATE percentage_of_failure PERCENT DISK FAILURE

[ IN DISK index | NODE index ]

562
Opciones
• percentage_of_failure: el porcentaje del disco que se debe marcar como defectuoso durante el
evento de error. Puede ser un valor doble entre 0 y 100. Si se especifica 0, ninguna parte del disco se
marca como defectuosa. Si se especifica 100, todo el disco se marca como defectuoso.
• DISK index: un bloque lógico de datos concreto para el que se debe simular el evento de error. Si se
sobrepasa el rango de bloques de datos lógicos disponibles, aparece un error que indica el valor máximo
del índice que se puede especificar. Para obtener más información, consulte Visualización del estado del
volumen para un clúster de base de datos de Aurora (p. 565).
• NODE index: un nodo de almacenamiento concreto para el que se debe simular el evento de error. Si
se sobrepasa el rango de nodos de almacenamiento disponibles, aparece un error que indica el valor
máximo del índice que se puede especificar. Para obtener más información, consulte Visualización del
estado del volumen para un clúster de base de datos de Aurora (p. 565).
• quantity: la cantidad de tiempo que debe durar la simulación del error de disco. El intervalo es
una cantidad seguida por una unidad de tiempo. La simulación durará esa cantidad de la unidad
especificada. Por ejemplo, 20 MINUTE hará que la simulación se ejecute durante 20 minutos.
Prueba de congestión del disco

Puede simular un error de disco para un clúster de base de datos Aurora usando la consulta de inserción
de errores ALTER SYSTEM SIMULATE DISK CONGESTION.
Durante la simulación de congestión del disco, el clúster de base de datos de Aurora marca de forma
aleatoria los segmentos de disco como congestionados. Las solicitudes que lleguen a esos segmentos se
retrasarán entre el mínimo especificado y el tiempo de demora máximo mientras dure la simulación.
Sintaxis
ALTER SYSTEM SIMULATE percentage_of_failure PERCENT DISK CONGESTION

BETWEEN minimum AND maximum MILLISECONDS
[ IN DISK index | NODE index ]
Opciones
• percentage_of_failure: el porcentaje del disco que se debe marcar como congestionado durante
el evento de error. Puede ser un valor doble entre 0 y 100. Si se especifica 0, ninguna parte del disco se
marca como congestionada. Si se especifica 100, todo el disco se marca como congestionado.
• DISK index o NODE index: un disco o nodo concreto para el que se debe simular el evento de error.
Si se sobrepasa el rango de índices para el disco o el nodo, aparece un error que indica el valor máximo
del índice que se puede especificar.
• minimum y maximum: la cantidad mínima y máxima de demora de la congestión en milisegundos. Los
segmentos de disco marcados como congestionados se retrasarán una cantidad de tiempo aleatoria del
rango comprendido entre la cantidad mínima y máxima de milisegundos mientras dure la simulación.
• quantity: la cantidad de tiempo durante la que se debe simular la congestión del disco. El intervalo
es una cantidad seguida por una unidad de tiempo. La simulación durará esa cantidad de la unidad de
tiempo especificada. Por ejemplo, 20 MINUTE hará que la simulación se ejecute durante 20 minutos.

563
Modificación de las tablas de Amazon
Aurora con operaciones DDL rápidas
Modificación de las tablas de Amazon Aurora con

operaciones DDL rápidas
En MySQL, muchas operaciones de lenguaje de definición de datos (DDL) tienen un impacto considerable
en el desempeño. El impacto en el desempeño se da incluso con las recientes mejoras de DDL online.
Por ejemplo, suponga que usa una operación ALTER TABLE para añadir una columna a una tabla. En
función del algoritmo especificado para la operación, esta puede incluir los siguientes pasos:
• Crear una copia completa de la tabla

• Crear una tabla temporal para procesar las operaciones simultáneas de lenguaje de manipulación de
datos (DML)
• Reconstruir todos los índices de la tabla
• Aplicar bloqueos de tabla mientras se aplican los cambios simultáneos de DML
• Ralentizar el rendimiento DML concurrente
En Amazon Aurora, puede usar DDL rápido para ejecutar una operación ALTER TABLE de forma casi
instantánea. La operación se completa sin que sea necesario copiar la tabla y sin que haya un impacto
perceptible en otras instrucciones DML. Como la operación no consume almacenamiento temporal para
una copia de la tabla, las instrucciones DDL resultan prácticas incluso para tablas grandes en clases de
instancia pequeñas.
Note
El lenguaje DDL rápido está disponible para las versiones 1.12 y posteriores de Aurora. Para
obtener más información acerca de las versiones de Aurora, consulte Actualizaciones del motor
de base de datos para Amazon Aurora MySQL (p. 695).
Limitaciones
Actualmente, el lenguaje DDL rápido tiene las siguientes limitaciones:
• El DDL rápido solo admite la adición de columnas que puedan contener valores nulos, sin valores
predeterminados, al final de una tabla existente.
• El DDL rápido no admite tablas con particiones.
• El DDL rápido no admite las tablas de InnoDB que usan el formato de fila REDUNDANT.
• Si el tamaño máximo posible de registro para la operación DDL es demasiado grande, no se utiliza el
lenguaje DDL rápido. Un tamaño de registro es demasiado grande si es superior a la mitad del tamaño
de la página. El tamaño máximo de un registro se computa sumando los tamaños máximos de todas las
columnas. Para columnas de tamaño variable, según estándares de InnoDB, los bytes externos no se
incluyen para computación.
Note
La revisión de tamaño máximo de registro se añadió en Aurora 1.15.
Sintaxis
ALTER TABLE tbl_name ADD COLUMN col_name column_definition
Opciones
Esta declaración puede usar las siguientes opciones:

564
Visualización del estado del volumen para
un clúster de base de datos de Aurora
• tbl_name: el nombre de la tabla que se va a modificar.

• col_name: el nombre de la columna que se va a añadir.
• col_definition: la definición de la columna que se va a añadir.
Note
Debe especificar una definición de columna que pueda tener valores nulos sin un valor
predeterminado. De lo contrario, no se usa el lenguaje DDL rápido.
Visualización del estado del volumen para un clúster

de base de datos de Aurora
En Amazon Aurora, un volumen de clúster de base de datos se compone de un conjunto de bloques
lógicos. Cada uno de esos bloques representa 10 gigabytes de almacenamiento asignado. Estos bloques
se denominan grupos de protección.
Los datos de cada grupo de protección se replican en seis dispositivos de almacenamiento físicos
denominados nodos de almacenamiento. Estos nodos de almacenamiento se distribuyen entre tres zonas
de disponibilidad (AZ) en la región en la que reside el clúster de base de datos. A su vez, cada nodo de
almacenamiento contiene uno o varios bloques lógicos de datos para el volumen del clúster de base de
datos. Para obtener más información acerca de los grupos de protección y los nodos de almacenamiento,
consulte Introducing the Aurora Storage Engine en AWS Database Blog.
Puede simular el error de un nodo de almacenamiento completo o de un único bloque lógico de datos
de un nodo de almacenamiento. Para ello, use la instrucción de inserción de errores ALTER SYSTEM
SIMULATE DISK FAILURE. Para la instrucción, especifique el valor del índice de un bloque lógico de
datos o nodo de almacenamiento concreto. Sin embargo, si especifica un valor de índice mayor que
el número de bloques lógicos de datos o los nodos de almacenamiento utilizados por el volumen de
clúster de base de datos, la instrucción devuelve un error. Para obtener más información acerca de las
consultas de inserción de errores, vea Pruebas de Amazon Aurora por medio de consultas de inserción de
errores (p. 561).
Puede evitar ese error usando la instrucción SHOW VOLUME STATUS. La instrucción devuelve dos
variables de estado de servidor, Disks y Nodes. Estas variables representan el número total de bloques
lógicos de datos y nodos de almacenamiento, respectivamente, para el volumen de clúster de base de
datos.
Note
La instrucción SHOW VOLUME STATUS está disponible para las versiones 1.12 y posteriores
de Aurora. Para obtener más información acerca de las versiones de Aurora, consulte
Actualizaciones del motor de base de datos para Amazon Aurora MySQL (p. 695).
Sintaxis
SHOW VOLUME STATUS
Ejemplo
El ejemplo siguiente muestra un resultado típico de SHOW VOLUME STATUS.
mysql> SHOW VOLUME STATUS;

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

565
Consulta paralela para Aurora MySQL
+---------------+-------+
| Disks | 96 |
| Nodes | 74 |
+---------------+-------+
Trabajar con Consultas en paralelo de Amazon

Aurora MySQL
A continuación encontrará una descripción de la optimización del rendimiento de las consultas en paralelo
de Compatibilidad de Amazon Aurora con MySQL. Esta característica usa una ruta de ejecución especial
para determinadas consultas de uso intensivo de datos, que aprovecha la arquitectura de almacenamiento
compartido de Aurora. Actualmente, las versiones de Aurora MySQL que son compatibles con MySQL 5.6
admiten las consultas en paralelo. Consultas en paralelo funciona mejor con los clústeres de base de datos
Aurora MySQL que tienen tablas con millones de filas y consultas analíticas que tardan minutos u horas en
completarse.
Temas
• Información general de Consultas en paralelo de Aurora MySQL (p. 566)
• Administración de un clúster de consultas en paralelo (p. 569)
• Consideraciones para actualizar Consultas en paralelo (p. 569)
• Creación de un clúster de base de datos que funciona con consultas en paralelo (p. 570)
• Habilitar y deshabilitar Consultas en paralelo (p. 574)
• Ajuste del rendimiento de las consultas en paralelo (p. 576)
• Creación de objetos de esquema para aprovechar las consultas en paralelo (p. 576)
• Verificación de qué instrucciones usan consultas en paralelo (p. 576)
• Monitorización de Consultas en paralelo (p. 579)
• Cómo funciona Consultas en paralelo con constructos de SQL (p. 581)
Información general de Consultas en paralelo de

Aurora MySQL
Consultas en paralelo de Aurora MySQL es una optimización que paraleliza algunas de los cálculos y E/
S del procesamiento de consultas con un uso intensivo de datos. El trabajo que se paraleliza incluye la
recuperación de filas del almacenamiento, la extracción de valores de columna y la determinación de qué
filas coinciden con las condiciones de la cláusula WHERE y de las cláusulas JOIN. Este trabajo con uso
intensivo de los datos se delega (en términos de optimización de base de datos, se baja de posición) a
varios nodos de la capa de almacenamiento distribuido de Aurora. Sin una consulta paralela, cada consulta
transfiere todos los datos analizados a un solo nodo del clúster de Aurora MySQL (el nodo principal) y
realiza ahí todos los procesamientos de consultas.
Cuando hay habilitada una característica de consulta en paralelo, el motor de Aurora MySQL determina
automáticamente cuándo las consultas pueden aprovecharla, sin requerir cambios de SQL como
sugerencias o atributos de tabla. En las secciones siguientes, puede encontrar una explicación cuándo
se aplica una consulta en paralelo a una consulta. También podrá encontrar cómo asegurarse de que las
consultas en paralelo se aplican cuando proporcionan el máximo beneficio.
Note
La optimización de las consultas en paralelo proporciona el máximo beneficio para las

consultas de ejecución prolongada que tardan minutos u horas en completarse. Aurora MySQL

566
Información general de Consultas en paralelo
normalmente no realiza optimización de consultas en paralelo para consultas económicas o si otra

técnica de optimización tiene más sentido, como el almacenamiento en caché de consultas, el
almacenamiento en caché de grupo de búfer o las búsquedas de índice. Consulte Verificación de
qué instrucciones usan consultas en paralelo (p. 576) si observa que las consultas en paralelo
no se usan cuando lo espera.
Temas
• Beneficios (p. 567)
• Arquitectura (p. 567)
• Limitaciones (p. 568)
Beneficios
Con las consultas en paralelo, puede ejecutar consultas analíticas de uso intensivo de datos en tablas de
Aurora MySQL, en muchos casos con una mejora del rendimiento de orden de magnitud sobre la división
tradicional de trabajo para el procesamiento de consultas.
Entre los beneficios de usar consultas en paralelo se incluyen los siguientes:
• Rendimiento de E/S mejorado, debido a la paralelización de solicitudes de lectura física en múltiples

nodos de almacenamiento.
• Tráfico de red reducido. Aurora no transmite páginas de datos enteras de nodos de almacenamiento al
nodo director y, después, filtra las filas y columnas innecesarias. En vez de eso, Aurora transmite tuplas
compactas que contienen solo los valores de columna necesarios para el conjunto de resultados.
• Uso reducido de CPU en el nodo director debido a la ejecución de la función de insertar, filtrado de filas y
proyección de columnas para la cláusula WHERE.
• Presión de memoria reducida en el grupo de búfer. Las páginas procesadas por la consulta en paralelo
no se añaden al grupo de búfer, lo que reduce las posibilidades de que los análisis con uso intensivo de
datos expulsen datos de uso frecuente del grupo de búfer.
• Reducción potencial de la duplicación de datos en la canalización de extracción, transformación y carga
(ETL), haciendo que sea práctico realizar consultas analíticas de ejecución prolongada en los datos
existentes.
Arquitectura
La característica de consulta en paralelo usa los principios de arquitectura principales de Aurora MySQL:
desacoplar el motor de base de datos del subsistema de almacenamiento y reducir el tráfico de red
optimizando los protocolos de comunicación. Aurora MySQL usa estas técnicas para acelerar las
operaciones de escritura intensivas como el procesamiento de registros REDO. Las consultas en paralelo
aplican los mismos principios a las operaciones de lectura.
Note
La arquitectura de las consultas en paralelo de Aurora MySQL es diferente de la de características

de nombre similar de otros sistemas de base de datos. La consulta en paralelo de Aurora MySQL
no implica multiprocesamiento simétrico (SMP), así que no depende de la capacidad de la CPU
del servidor de la base de datos. La ejecución paralela tiene lugar en la capa de almacenamiento,
independiente del servidor de Aurora MySQL que sirve como el coordinador de consultas.
De forma predeterminada, sin una consulta en paralelo, el procesamiento para una consulta de Aurora
implica transmitir los datos no procesados a un solo nodo del clúster de Aurora (el nodo director) y
realizar todos los demás procesamientos en un solo subproceso de ese único nodo. Con las consultas
paralelas, gran parte de este trabajo con uso intensivo de E/S y de CPU se delega a los nodos de la capa
de almacenamiento. Solo las filas compactas del conjunto de resultados se transmiten de vuelta al nodo
director, con las filas ya filtradas y los valores de la columna ya extraídos y transformados. El beneficio

567
Información general de Consultas en paralelo
del rendimiento viene de la reducción del tráfico de red, la reducción del uso de CPU en el nodo director
y la paralelización de la E/S en los nodos de almacenamiento. La cantidad de E/S, filtrado y proyección
paralelos es independiente del número de instancias de base de datos del clúster de Aurora que ejecute la
consulta.
Limitaciones
La característica de consultas en paralelo tiene las siguientes limitaciones:
• Actualmente, las versiones de Aurora MySQL que son compatibles con MySQL 5.6 admiten las
consultas en paralelo. Tenga en cuenta que el motor de base de datos PostgreSQL tiene una
característica no relacionada que también se denomina "consultas en paralelo".
• Actualmente solo puede usar las consultas en paralelo con las siguientes clases de instancia:
• Todas las clases de instancias de la serie db.r3.
• Todas las clases de instancias de la serie db.r4.
Note
No se pueden crear instancias T2 para consultas en paralelo.

• La opción de consultas en paralelo está disponible en las siguientes regiones:
• US East (N. Virginia)
• EE.UU. Este (Ohio)
• EE.UU. Oeste (Oregón)
• UE (Irlanda)
• Asia Pacífico (Tokio)
• El uso de consultas en paralelo requiere la creación de un nuevo clúster o la restauración de una
instantánea de clúster de Aurora MySQL existente, como se describe a continuación.
• Actualmente, la característica Performance Insights no está disponible para los clústeres habilitados para
las consultas en paralelo.
• Actualmente, la característica de búsqueda de datos anteriores no está disponible para los clústeres
habilitados para las consultas en paralelo.
• No puede detener e iniciar clústeres de base de datos habilitados para la consulta en paralela.
• Actualmente, no se admiten tablas con particiones para la consulta en paralelo. Puede utilizar tablas
particionadas en clústeres de consultas en paralelo. Las consultas con las que esas tablas utilizan la ruta
de ejecución de la consulta que no es en paralelo.
Note
Una consulta de unión, UNION, u otra consulta multiparte pueden usar parcialmente las
consultas en paralelo, incluso aunque algunos bloques de consulta hagan referencia a tablas
particionadas. Los bloques de consulta que hacen referencia solo a tablas no particionadas
pueden usar la optimización de consultas en paralelo.
• Para trabajar con consultas en paralelo, actualmente una tabla debe usar el formato sin procesar
COMPACT, que requiere el formato de archivo Antelope del motor de almacenamiento InnoDB.
• Los tipos de datos TEXT, BLOB y GEOMETRY no son compatibles con las consultas en paralelo. Una
consulta que haga referencia a cualquier columna de estos tipos no puede usar consultas en paralelo.
• Las columnas de longitud variable (tipos de datos VARCHAR y CHAR) son compatibles con las consultas
en paralelo hasta una longitud máxima declarada de 768 bytes. Una consulta que haga referencia a
cualquier columna de los tipos declarados con una longitud máxima más larga no puede usar consultas
en paralelo. En el caso de columnas que usen conjuntos de caracteres multibyte, el límite de bytes
tiene en cuenta el número máximo de bytes del conjunto de caracteres. Por ejemplo, para el conjunto
de caracteres utf8mb4 (que tiene una longitud máxima de caracteres de 4 bytes), una columna
VARCHAR(192) es compatible con una consulta en paralelo, pero una columna VARCHAR(193) no lo
es.

568
Administración
El tipo de datos JSON es de tipo BLOB que solo está disponible en Aurora y es compatible con MySQL
5.7. Las consultas en paralelo solo están disponibles en Aurora compatibles con MySQL 5.6. Por tanto,
este tipo actualmente no puede estar presente en una tabla de un clúster que incluya la característica de
consultas en paralelo.
• Actualmente, las consultas en paralelo no se usan para tablas que contengan un índice de búsqueda de
texto completo, independientemente de si la consulta se refiere a dichas columnas indexadas o si usa el
operador MATCH().
• Actualmente, las consultas en paralelo no se utilizan para ningún bloque de consultas que incluya una
cláusula LIMIT. Aun así, las consultas en paralelo podrían usarse para fases de consulta anteriores con
GROUP BY, ORDER BY o uniones.
• Actualmente, las subconsultas correlacionadas no pueden usar la optimización de consultas en paralelo.
• Consultas en paralelo funciona con instrucciones SELECT que no realizan escrituras o bloqueos, y solo
bajo el nivel de aislamiento REPEATABLE READ. Por ejemplo, las consultas en paralelo no funcionan con
SELECT FOR UPDATE ni con las cláusulas WHERE de las instrucciones UPDATE o DELETE.
• Consultas en paralelo solo está disponible para las tablas para las que no hay operaciones de lenguaje
de definición de datos (DDL) online rápidas pendientes.
• La característica de consultas en paralelo funciona con la mayoría de los operadores y funciones de
la cláusula WHERE, aunque no con todos. Para ver ejemplos en los que se ilustren las operaciones
compatibles, consulte Cómo funciona Consultas en paralelo con constructos de SQL (p. 581).
• Cada instancia de base de datos Aurora solo puede ejecutar un número determinado de sesiones de
consultas en paralelo a la vez. Si una consulta tiene varias partes que usan consultas en paralelo,
como subconsultas, uniones u operadores UNION, esas fases se ejecutan en secuencia. La instrucción
solo cuenta como una única sesión de consulta en paralelo cada vez. Puede monitorizar el número de
sesiones activas usando las variables de estado de consultas en paralelo (p. 579). Puede comprobar el
límite de sesiones simultáneas para una instancia de base de datos determinada consultando la variable
de estado Aurora_pq_max_concurrent_requests.
Administración de un clúster de consultas en paralelo

La administración de un clúster habilitado para realizar consultas en paralelo requiere algunos pasos de
configuración (para crear o restaurar un clúster de Aurora MySQL completo) y decidir la amplitud con la
que se habilitarán las consultas en paralelo en el clúster.
Es posible que se deban crear nuevas versiones de algunas tablas grandes en las que las consultas en
paralelo son útiles, por ejemplo, para hacer que la tabla no tenga particiones o para eliminar los índices
de búsqueda de texto completo. Para obtener más información, consulte Creación de objetos de esquema
para aprovechar las consultas en paralelo (p. 576).
Después de finalizar la configuración, la administración en curso implica la monitorización del rendimiento

y la eliminación de obstáculos para el uso de las consultas en paralelo. Para obtener esas instrucciones,
consulte Ajuste del rendimiento de las consultas en paralelo (p. 576).
Consideraciones para actualizar Consultas en paralelo

Actualmente, no se puede realizar una actualización local de un clúster de Aurora MySQL para habilitar la
característica de consultas en paralelo. El uso de consultas en paralelo requiere la creación de un nuevo
clúster o la restauración de una instantánea de clúster de Aurora MySQL 5.6 existente.

569
Creación de un clúster de consultas en paralelo
Creación de un clúster de base de datos que funciona

con consultas en paralelo
Para crear un clúster de Aurora MySQL con consultas en paralelo, añadirle nuevas instancias o realizar
otras operaciones administrativas, use la misma Consola de administración de AWS y técnicas de AWS
CLI que usaría con otros clústeres de Aurora MySQL. Puede crear un nuevo clúster para trabajar con
consultas en paralelo. También puede crear un clúster de base de datos con consultas en paralelo
realizando una restauración desde una instantánea de una base de datos compatible con MySQL 5.6.
Si no está familiarizado con el proceso de crear un nuevo clúster de Aurora MySQL, puede encontrar
información general y requisitos previos en Creación de un clúster de base de datos de Amazon
Aurora (p. 85).
Sin embargo, ciertas opciones son diferentes:
• Cuando elija una versión compatible con Aurora MySQL, asegúrese de elegir el motor más reciente que
sea compatible con MySQL 5.6. Actualmente, las versiones de Aurora MySQL que son compatibles con
MySQL 5.6 admiten las consultas en paralelo.
• Cuando cree o restaure el clúster de base de datos, asegúrese de seleccionar el modo de motor
parallelquery.
Tanto si crea un nuevo clúster como si lo restaura de una instantánea, se usan las mismas técnicas para
añadir nuevas instancias de base de datos que usaría con otros clústeres de Aurora MySQL.
Creación de un clúster de consultas en paralelo utilizando la

consola
Puede crear un nuevo clúster de consultas en paralelo con la consola como se describe a continuación.
Para crear un clúster de consultas en paralelo con la Consola de administración de AWS
1. Siga el procedimiento general de la Consola de administración de AWS de Creación de un clúster de

2. En la pantalla Select engine (Seleccionar motor), elija la edición compatible con MySQL 5.6 de Aurora.
3. En la pantalla Specify DB details (Especificar detalles de la base de datos), para Capacity type (Tipo
de capacidad), elija Provisioned with Aurora parallel query enabled (Aprovisionada con consultas en
paralelo de Aurora habilitadas) como se muestra en la siguiente captura de pantalla.

570
Para restaurar una instantánea a un clúster de consultas en paralelo con la Consola de

administración de AWS
1. Localice una instantánea de una instancia de base de datos compatible con MySQL 5.6.
2. Siga el procedimiento general de la Consola de administración de AWS de Restauración de una
instantánea de clúster de base de datos (p. 319).
3. Para DB Engine Mode (Modo del motor de base de datos), elija parallelquery, tal y como se muestra
en la siguiente captura de pantalla.

571
Para verificar que un nuevo clúster puede usar consultas en paralelo
1. Cree o restaure un clúster con las técnicas anteriores.

2. Compruebe que el ajuste aurora_pq_supported está configurado como verdadero.
mysql> select @@aurora_pq_supported;

+-----------------------+
| @@aurora_pq_supported |
+-----------------------+
| 1 |
+-----------------------+
Creación de un clúster de consultas en paralelo utilizando la CLI

Puede crear un nuevo clúster de consultas en paralelo con la CLI como se describe a continuación.
Para crear un clúster de consultas en paralelo con la AWS CLI
1. Compruebe qué combinaciones de la versión de Aurora MySQL, la clase de la instancia de AWS, la

región de AWS, la zona de disponibilidad, etc., están disponibles para los clústeres de consultas en
paralelo. Para ello, use el comando aws rds describe-orderable-db-instance-options,
que produce resultados en formato JSON. En el siguiente ejemplo de código se muestra cómo.
# See all choices for all AWS Regions.

aws rds describe-orderable-db-instance-options --engine aurora --engine-mode
parallelquery
# See choices only for a particular AWS Region.

parallelquery \
--region us-east-2

572
2. Siga el procedimiento general de la AWS CLI de Creación de un clúster de base de datos de Amazon
Aurora (p. 85).
3. Especifique el siguiente conjunto de opciones:
• Para la opción --engine, use aurora.

• Para la opción --engine-mode, use parallelquery. El parámetro --engine-mode se
aplica a la operación create-db-cluster. A continuación, el modo de motor del clúster se usa
automáticamente por las operaciones create-db-instance posteriores.
• Para la opción --engine-version, use 5.6.10a.
En el siguiente ejemplo de código se muestra cómo.
aws rds create-db-cluster --db-cluster-identifier $CLUSTER_ID

--engine aurora --engine-mode parallelquery --engine-version 5.6.10a \
--master-username $MASTER_USER_ID --master-user-password $MASTER_USER_PW \
--db-subnet-group-name $SUBNET_GROUP --vpc-security-group-ids $SECURITY_GROUP
aws rds create-db-instance --db-instance-identifier ${INSTANCE_ID}-1 \

--engine aurora \
--db-cluster-identifier $CLUSTER_ID --db-instance-class $INSTANCE_CLASS
4. Verificar que un clúster que ha creado o restaurado tiene la característica de consultas en paralelo
disponible. Compruebe que el ajuste aurora_pq_supported está configurado como verdadero.

+-----------------------+
+-----------------------+
| 1 |
+-----------------------+
Para restaurar una instantánea a un clúster de consultas en paralelo con la AWS CLI
1. Compruebe qué combinaciones de la versión de Aurora MySQL, la clase de la instancia de AWS, la

región de AWS, la zona de disponibilidad, etc., están disponibles para los clústeres de consultas en
paralelo. Para ello, use el comando aws rds describe-orderable-db-instance-options,
que produce resultados en formato JSON. En el siguiente ejemplo de código se muestra cómo.
# See all choices for all AWS Regions.

parallelquery
# See choices only for a particular AWS Region.

parallelquery \
--region us-east-2
2. Localizar una instantánea de una base de datos compatible con MySQL 5.6.
3. Siga el procedimiento general de la AWS CLI de Restauración de una instantánea de clúster de base
de datos (p. 319).
4. Para la opción --engine-mode, especifique parallelquery. En el siguiente ejemplo de código se
muestra cómo.

573
Habilitar y deshabilitar Consultas en paralelo
aws rds restore-db-instance-from-db-snapshot \

--db-instance-identifier mynewdbinstance \
--db-snapshot-identifier mydbsnapshot \
--engine-mode parallelquery
5. Verificar que un clúster que ha creado o restaurado tiene la característica de consultas en paralelo
disponible. Compruebe que el ajuste aurora_pq_supported está configurado como verdadero.

+-----------------------+
+-----------------------+
| 1 |
+-----------------------+

Puede habilitar y deshabilitar las consultas en paralelo de forma dinámica en los niveles global y
de sesión para una instancia de base de datos usando la opción aurora_pq. En los clústeres en los
que la característica de consultas en paralelo está disponible, el parámetro está habilitado de forma
predeterminada.
mysql> select @@aurora_pq;

+-------------+
| @@aurora_pq |
+-------------+
| 1 |
+-------------+
Para activar el parámetro aurora_pq en el nivel de sesión, por ejemplo mediante la línea de comandos
mysql o en una aplicación JDBC u ODBC, use los métodos estándares para cambiar un ajuste de
configuración de un cliente. Por ejemplo, el comando en el cliente MySQL estándar es set session
aurora_pq = {'ON'/'OFF'}. También puede añadir el parámetro de nivel de sesión a la configuración
de JDBC o en su código de aplicación para habilitar o deshabilitar las consultas en paralelo de forma
dinámica.
Actualmente, cuando cambia el ajuste global del parámetro aurora_pq, debe hacerlo para todo el clúster,
no para instancias de base de datos individuales. Para activar el parámetro de aurora_pq en el nivel de
clúster, use las técnicas para trabajar con los grupos de parámetros, como se describe en Trabajo con
los grupos de parámetros de base de datos y grupos de parámetros de clúster de base de datos (p. 259).
Sigue estos pasos:
1. Cree un grupo de parámetros de clúster personalizado.

2. Actualice aurora_pq al valor deseado.
3. Asocie el grupo de parámetros de clúster personalizado al clúster de Aurora en el que desea usar la
característica de consultas en paralelo.
4. Reinicie todas las instancias de base de datos del clúster.
Puede modificar el parámetro de consultas en paralelo usando la operación

ModifyDBClusterParameterGroup de la API o la Consola de administración de AWS.
Note
Cuando las consultas en paralelo están habilitada, Aurora MySQL determina si usarlas en
el tiempo de ejecución para cada consulta. En el caso de uniones, operaciones UNION,

574
subconsultas, etc., Aurora MySQL determina si usar consultas en paralelo en el tiempo de

ejecución para cada bloque de consulta. Para más detalles, consulte Verificación de qué
instrucciones usan consultas en paralelo (p. 576) y Cómo funciona Consultas en paralelo con
constructos de SQL (p. 581).
Habilitar y deshabilitar las consultas en paralelo para una

instancia de base de datos usando la consola
Puede habilitar o deshabilitar las consultas en paralelo en el nivel de la instancia de base de datos
trabajando con grupos de parámetros.
Para habilitar o deshabilitar las consultas en paralelo para un clúster de Aurora MySQL con la
1. Cree un grupo de parámetros personalizados según se indica en Trabajo con los grupos de
2. Actualice aurora_pq a 0 (deshabilitado) o 1 (habilitado), como se indica en la siguiente captura
de pantalla. En los clústeres en los que la característica de consultas en paralelo está disponible,
aurora_pq está habilitado de forma predeterminada.
3. Asocie el grupo de parámetros de clúster personalizado al clúster de base de datos Aurora en el que
desea usar la característica de consultas en paralelo.
Habilitar y deshabilitar las consultas en paralelo para una

instancia de base de datos usando la CLI
Puede modificar el parámetro de consultas en paralelo usando el comando modify-db-cluster-
parameter-group.
Para habilitar o deshabilitar las consultas en paralelo para una instancia de base de datos con la
CLI
• Modifique el parámetro de consultas en paralelo usando el comando modify-db-cluster-

parameter-group.
También puede habilitar o deshabilitar las consultas en paralelo en el nivel de sesión, por ejemplo,
mediante la línea de comandos mysql o en una aplicación JDBC u ODBC. Para ello, use los métodos
estándares para cambiar un ajuste de configuración de cliente. Por ejemplo, el comando en el cliente
MySQL estándar es set session aurora_pq = {'ON'/'OFF'}.
También puede añadir el parámetro de nivel de sesión a la configuración de JDBC o en su código de

aplicación para habilitar o deshabilitar las consultas en paralelo de forma dinámica.

575
Ajuste del desempeño
Ajuste del rendimiento de las consultas en paralelo

Para administrar el rendimiento de una carga de trabajo con consultas en paralelo, asegúrese de que dicha
consulta en paralelo se usa para consultas en las que esta optimización ayuda más.
Para ello, puede hacer lo siguiente:
• Monitorizar qué consultas usan consultas en paralelo.

• Verificar que se está usando para las consultas con mayor uso intensivo de datos y de mayor larga
ejecución.
• Ajustar las condiciones del clúster para habilitar las consultas en paralelo que aplicar a las consultas que
espera y ejecutar con el nivel correcto de simultaneidad para su carga de trabajo.
Creación de objetos de esquema para aprovechar las

consultas en paralelo
Dado que las consultas en paralelo requieren que las tablas usen el ajuste ROW_FORMAT=Compact,
consulte sus ajustes de configuración de Aurora para realizar cualquier cambio a la opción de
configuración INNODB_FILE_FORMAT. (Los ajustes ROW_FORMAT alternativos en la instrucción CREATE
TABLE requieren que la opción de configuración INNODB_FILE_FORMAT se haya establecido en
'Barracuda'). Emita la instrucción SHOW TABLE STATUS para confirmar el formato de fila para todas las
tablas en una base de datos.
Actualmente, las consultas en paralelo requieren tablas que no tengan particiones. Por tanto, compruebe
sus instrucciones CREATE TABLE y resultados SHOW CREATE TABLE y elimine cualquier cláusula
PARTITION BY. En el caso de tablas particionadas existentes, copie primero los datos en tablas no
particionadas con las mismas definiciones de columnas e índices. A continuación, cambie el nombre de
las tablas antiguas y nuevas para que las consultas existentes y flujos de trabajo de ETL usen la tabla no
particionada.
Antes de cambiar su esquema para habilitar que las consultas en paralelo trabajen con más tablas, realice
pruebas para confirmar si los resultados de las consultas en paralelo en una red aumentan el rendimiento
en esas tablas. También asegúrese de que los requisitos del esquema de una consulta en paralelo con
compatibles en los demás aspectos con sus objetivos.
Por ejemplo, antes de cambiar de ROW_FORMAT=Compressed a ROW_FORMAT=Compact, pruebe el

rendimiento de las cargas de trabajo frente a las tablas original y nueva. Además, tenga en cuenta otros
efectos potenciales como un mayor volumen de datos.
Verificación de qué instrucciones usan consultas en

paralelo
En el funcionamiento habitual, no es necesario realizar acciones especiales para sacar partido de las
consultas en paralelo. Cuando una consulta cumple los requisitos esenciales para consultas en paralelo,
el optimizador de consultas decide automáticamente si usar las consultas en paralelo para cada consulta
específica.
Si ejecuta experimentos en un entorno de desarrollador o de pruebas, puede que observe que las
consultas en paralelo no se utilizan porque las tablas son demasiado pequeñas en número de filas o
volumen de datos general. Los datos de la tabla también podrían encontrarse completamente en el grupo
de búfer, especialmente en el caso de tablas que haya creado recientemente para realizar experimentos.
Cuando monitoriza o ajusta el rendimiento de clústeres, debe decidir si las consultas en paralelo se están
usando en los contextos adecuados. Podría ajustar el esquema de la base de datos, la configuración,

576
Verificación del uso de Consultas en paralelo
las consultas SQL o incluso la topología de clústeres y la configuración de conexión de aplicación para
aprovechar esta característica.
Para comprobar si una consulta está usando las consultas en paralelo, revise el plan de ejecución de
consultas (también conocido como el plan de explicación) ejecutando la instrucción EXPLAIN. En el caso
de ejemplos sobre cómo afectan las instrucciones, cláusulas y expresiones de SQL a los resultados de
EXPLAIN para consultas en paralelo, consulte Cómo funciona Consultas en paralelo con constructos de
SQL (p. 581).
En el siguiente ejemplo se muestra la diferencia entre un plan de ejecución tradicional y un plan de

consultas en paralelo. Esta consulta es la consulta 3 del análisis comparativo de TPC-H. En muchas de las
consultas de ejemplo de esta sección se usan las tablas del conjunto de datos de TPC-H.
SELECT l_orderkey,
sum(l_extendedprice * (1 - l_discount)) AS revenue,
o_orderdate,
o_shippriority
FROM customer,
orders,
lineitem
WHERE c_mktsegment = 'AUTOMOBILE'
AND c_custkey = o_custkey
AND l_orderkey = o_orderkey
AND o_orderdate < date '1995-03-13'
AND l_shipdate > date '1995-03-13'
GROUP BY l_orderkey,
o_orderdate,
o_shippriority
ORDER BY revenue DESC,
o_orderdate LIMIT 10;
Con las consultas en paralelo deshabilitadas, la consulta podría tener un plan de ejecución como el
siguiente, que usa uniones hash, pero no consultas en paralelo.
+----+-------------+----------+...+-----------
+-----------------------------------------------------------------+
| id | select_type | table |...| rows | Extra
|
+----+-------------+----------+...+-----------
+-----------------------------------------------------------------+
| 1 | SIMPLE | customer |...| 5798330 | Using where; Using index; Using temporary;
Using filesort |
| 1 | SIMPLE | orders |...| 154545408 | Using where; Using join buffer (Hash Join
Outer table orders) |
| 1 | SIMPLE | lineitem |...| 606119300 | Using where; Using join buffer (Hash Join
Outer table lineitem) |
+----+-------------+----------+...+-----------
+-----------------------------------------------------------------+
Después de que las consultas en paralelo estén habilitadas, dos pasos de este plan de ejecución pueden
usar la optimización de consultas en paralelo, como se muestra en la columna Extra de la salida de
EXPLAIN. El procesamiento con uso intensivo de E/S y de CPU para estos pasos se baja a la capa de
almacenamiento.
+----+...
+------------------------------------------------------------------------------------------------------
+
| id |...| Extra
|

577
Verificación del uso de Consultas en paralelo
+----+...
+------------------------------------------------------------------------------------------------------
+
| 1 |...| Using where; Using index; Using temporary; Using filesort
|
| 1 |...| Using where; Using join buffer (Hash Join Outer table orders); Using parallel
query (4 columns, 1 filters, 1 exprs; 0 extra) |
| 1 |...| Using where; Using join buffer (Hash Join Outer table lineitem); Using parallel
query (4 columns, 1 filters, 1 exprs; 0 extra) |
+----+...
+------------------------------------------------------------------------------------------------------
+
Para obtener información sobre cómo interpretar las salidas de EXPLAIN para una consulta en paralelo
y las partes de las instrucciones de SQL a las que las consultas en paralelo pueden aplicarse, consulte
Cómo funciona Consultas en paralelo con constructos de SQL (p. 581).
En la siguiente salida de ejemplo se muestran los resultados de ejecutar la consulta anterior en una
instancia de db.r4.2xlarge con un grupo de búfer frío. La consulta se ejecuta notablemente más rápido al
usar las consultas en paralelo.
Note
Dado que los tiempos dependen de muchos factores del entorno y que esta consulta de ejemplo
se ejecutó con una versión anterior de las consultas en paralelo, sus resultados podrían ser
diferentes. Realice siempre sus propias pruebas de rendimiento para confirmar los resultados con
su propio entorno, carga de trabajo, etc.
-- Without parallel query

+------------+-------------+-------------+----------------+
| l_orderkey | revenue | o_orderdate | o_shippriority |
+------------+-------------+-------------+----------------+
| 92511430 | 514726.4896 | 1995-03-06 | 0 |
.
.
| 28840519 | 454748.2485 | 1995-03-08 | 0 |
+------------+-------------+-------------+----------------+
10 rows in set (24 min 49.99 sec)
-- With parallel query

+------------+-------------+-------------+----------------+
| l_orderkey | revenue | o_orderdate | o_shippriority |
+------------+-------------+-------------+----------------+
| 92511430 | 514726.4896 | 1995-03-06 | 0 |
.
.
| 28840519 | 454748.2485 | 1995-03-08 | 0 |
+------------+-------------+-------------+----------------+
10 rows in set (1 min 49.91 sec)
Muchas de las consultas de ejemplo de esta sección usan tablas de este conjunto de datos de TPC-H, en
particular la tabla PART, que tiene 20 millones de filas y la siguiente definición.
+---------------+---------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+---------------+---------------+------+-----+---------+-------+
| p_partkey | int(11) | NO | PRI | NULL | |
| p_name | varchar(55) | NO | | NULL | |
| p_mfgr | char(25) | NO | | NULL | |

578
Monitorización
| p_brand | char(10) | NO | | NULL | |

| p_type | varchar(25) | NO | | NULL | |
| p_size | int(11) | NO | | NULL | |
| p_container | char(10) | NO | | NULL | |
| p_retailprice | decimal(15,2) | NO | | NULL | |
| p_comment | varchar(23) | NO | | NULL | |
+---------------+---------------+------+-----+---------+-------+
Experimente con su carga de trabajo para averiguar si las instrucciones de SQL individuales pueden sacar
partido de las consultas en paralelo. Después, use las siguientes técnicas de monitorización para ayudar
a verificar la frecuencia con la que se usan las consultas en paralelo en las cargas de trabajo reales a lo
largo del tiempo. En el caso de cargas de trabajo reales, se aplican otros factores adicionales, como los
límites de simultaneidad.
Monitorización de Consultas en paralelo

Además de las métricas de Amazon CloudWatch descritas en Monitorización de las métricas de un clúster
de base de datos Amazon Aurora (p. 384), Aurora proporciona otras variables de estado globales. Puede
usar estas variables de estado globales para ayudar a monitorizar la ejecución de las consultas en paralelo
y obtener detalles de por qué el optimizador podría usar o no las consultas en paralelo en una situación
determinada. Para acceder a estas variables, puede usar el comando SHOW GLOBAL STATUS. También
puede encontrar estas variables enumeradas a continuación.
Una sesión de consultas en paralelo no es necesariamente un mapeo de uno a uno con una consulta
ejecutada. Por ejemplo, suponga que su plan de ejecución tiene dos pasos que usan una consulta en
paralelo. En tal caso, la consulta implica dos sesiones paralelas y los contadores de intentos de solicitud y
de solicitudes correctas se incrementan en dos.
Cuando experimente con las consultas en paralelo emitiendo instrucciones EXPLAIN, espere ver aumentos
en los contadores designados como no elegidos incluso aunque las consultas no se estén ejecutando
reamente. Cuando trabaje con consultas en paralelo en producción, puede comprobar si los contadores
de no elegido están aumentando más rápido de lo que espera. Entonces puede ajustar su configuración
de clúster, mezcla de consultas, instancias de base de datos en las que las consultas en paralelo estén
habilitadas, etc., de forma que la consulta en paralelo se ejecute para las consultas que espera.
Se realiza un seguimiento de estos contadores en el nivel de instancia de base de datos. Cuando se

conecte a un punto de enlace distinto, podría ver métricas diferentes porque cada instancia de base de
datos ejecuta su propio conjunto de consultas en paralelo. También podría ver métricas diferentes cuando
el punto de enlace del lector se conecte a una instancia de base de datos distinta para cada sesión.
Nombre Descripción
Aurora_pq_request_attempted El número de sesiones de consultas en paralelo

solicitadas. Este valor podría representar más
de una sesión por consulta, dependiendo de los
constructos de SQL como subconsultas y uniones.
Aurora_pq_request_executed El número de sesiones de consultas en paralelo

ejecutadas correctamente.
Aurora_pq_request_failed El número de sesiones de consultas en paralelo

que devolvieron un error al cliente. En algunos
casos, una solicitud de una consulta en paralelo
podría producir un error, por ejemplo, debido
a un problema en la capa de almacenamiento.
En tales casos, la parte de la consulta que haya
producido un error vuelve a intentarse usando
el mecanismo de consultas no paralelas. Si la

579
Monitorización
consulta reintentada también produce un error,

se devolverá un error al cliente y este contador se
incrementará.
Aurora_pq_pages_pushed_down El número de páginas de datos (cada una con un

tamaño fijo de 16 KiB) en las que las consultas en
paralelo evitaron una transmisión de red al nodo
director.
Aurora_pq_bytes_returned El número de bytes de estructuras de

datos de tuplas transmitido al nodo director
durante las consultas en paralelo. Debe
dividirse entre 16 384 para compararse con
Aurora_pq_pages_pushed_down.
Aurora_pq_request_not_chosen El número de veces que las consultas en

paralelo no se han elegido para satisfacer una
consulta. Este valor es la suma de varios otros
contadores más detallados. Este contador se
puede incrementar mediante una instrucción
EXPLAIN incluso aunque la consulta no se realice
realmente.
El número de veces que las consultas en paralelo

Aurora_pq_request_not_chosen_below_min_rows
no se han elegido debido al número de filas de
la tabla. Este contador se puede incrementar
mediante una instrucción EXPLAIN incluso aunque
la consulta no se realice realmente.
Aurora_pq_request_not_chosen_small_tableEl número de veces que las consultas en paralelo

no se han elegido debido al tamaño general de la
tabla, según lo determinado por el número de filas
y la longitud promedio de las filas. Este contador
se puede incrementar mediante una instrucción
realmente.

Aurora_pq_request_not_chosen_high_buffer_pool_pct
no se han elegido debido a que un porcentaje
elevado de datos de tabla (actualmente, superior
al 95 %) ya estaba en el grupo de búfer. En estos
casos, el optimizador determina que leer los datos
del grupo de búfer es más eficiente. Este contador
se puede incrementar mediante una instrucción
realmente.

Aurora_pq_request_not_chosen_few_pages_outside_buffer_pool
no se han elegido, incluso aunque menos del 95 %
de los datos de tabla ya estuviera en el grupo de
búfer, porque no había suficientes datos de tabla
fuera de búfer para que valiera la pena realizar
una consulta en paralelo. Este contador se puede
incrementar mediante una instrucción EXPLAIN
incluso aunque la consulta no se realice realmente.

580
Consultas en paralelo y constructos de SQL
Aurora_pq_max_concurrent_requests El número máximo de sesiones de consultas en

paralelo que se pueden ejecutar simultáneamente
en esta instancia de base de datos Aurora. Este
es un número fijo que depende de la clase de
instancia de AWS.
Aurora_pq_request_in_progress El número de sesiones de consultas en paralelo

en curso actualmente. Este número se aplica a
la instancia de base de datos Aurora concreta
a la que está conectado, no a todo el clúster de
base de datos Aurora. Para ver si una instancia
de base de datos está cerca de su límite de
simultaneidad, compare este valor con el de
Aurora_pq_max_concurrent_requests.
Aurora_pq_request_throttled El número de veces que las consultas en paralelo

no se han elegido debido a que el número máximo
de consultas en paralelo simultáneas que ya se
están ejecutando en una instancia de base de
datos Aurora concreta.
Aurora_pq_request_not_chosen_long_trx El número de solicitudes de consultas en paralelo

que usaron la ruta de ejecución de consultas
no en paralelo, debido a que la consulta se
estaba iniciando en una transacción de ejecución
prolongada. Este contador se puede incrementar
mediante una instrucción EXPLAIN incluso aunque
la consulta no se realice realmente.
El número de solicitudes de consultas en paralelo

Aurora_pq_request_not_chosen_unsupported_access
que usan la ruta de ejecución de consultas no en
paralelo porque la cláusula WHERE no cumple los
criterios de consultas en paralelo. Este resultado
puede producirse si la consulta no requiere un
análisis de uso intensivo de datos o si la consulta
es una instrucción DELETE o UPDATE.
Cómo funciona Consultas en paralelo con constructos

de SQL
En la siguiente sección, encontrará información más detallada sobre por qué instrucciones de SQL
determinadas usan o no las consultas en paralelo y cómo las características de Aurora MySQL interactúan
con las consultas en paralelo. Esta información le ayudará a diagnosticar los problemas de rendimiento
para un clúster que use consultas en paralelo o a comprender cómo se aplican las consultas en paralelo a
su carga de trabajo concreta.
La decisión de usar consultas en paralelo depende de muchos factores que tienen lugar en el momento en
que se ejecuta la instrucción. Por tanto, la consulta en paralelo podría usarse para determinadas consultas
siempre, nunca o solo en ciertas condiciones.
Temas
• Instrucción EXPLAIN (p. 582)
• Cláusula WHERE (p. 583)
• Llamadas de función en la cláusula WHERE (p. 585)

581
• Funciones de agregación, cláusulas GROUP BY y cláusulas HAVING (p. 586)

• Operadores de comparación (p. 586)
• combinaciones; (p. 587)
• Subconsultas (p. 588)
• UNION (p. 588)
• Vistas (p. 589)
• Instrucciones de lenguaje de manipulación de datos (DML) (p. 589)
• Transacciones y bloqueo (p. 590)
• Índices (p. 592)
• Mecanismos de almacenamiento en caché integrados (p. 592)
• Tablas temporales MyISAM (p. 593)
Instrucción EXPLAIN
Como se muestra en los ejemplos de esta sección, la instrucción EXPLAIN indica si cada fase de una
consulta es apta actualmente para las consultas en paralelo. También indica qué aspectos de una consulta
se pueden bajar a la capa de almacenamiento. Los elementos más importantes del plan de ejecución son
los siguientes:
• Un valor distinto de NULL para la columna key indica que la consulta se puede realizar con eficacia
usando búsquedas del índice y que es poco probable el uso de consultas en paralelo.
• Un valor pequeño para la columna rows (es decir, un valor que no sea de millones) indica que la
consulta no está accediendo a suficientes datos para que valga la pena realizar consultas en paralelo,
por lo que su uso es improbable.
• La columna Extra muestra si se espera usar consultas en paralelo. Este resultado tiene el aspecto del
siguiente ejemplo.
Using parallel query (A columns, B filters, C exprs; D extra)
El número de columns representa a cuántas columnas se hace referencia en el bloque de consultas.
El número de filters representa el número de predicados de WHERE que representan una simple
comparación de un valor de columna con una constante. La comparación puede ser de igualdad,
desigualdad o rango. Aurora puede paralelizar estos tipos de predicados con más eficacia.
El número de exprs representa el número de expresiones como las llamadas de función, operadores
u otras expresiones que también se pueden paralelizar, aunque no con la misma eficacia que una
condición de filtro.
El número extra representa cuántas expresiones no se pueden bajar y las realiza el nodo director.
Por ejemplo, fíjese en el siguiente resultado de EXPLAIN.
mysql> explain select p_name, p_mfgr from part

-> where p_brand is not null
-> and upper(p_type) is not null
-> and round(p_retailprice) is not null;
+----+-------------+-------+...+----------
+----------------------------------------------------------------------------+
|

582
+----+-------------+-------+...+----------
+----------------------------------------------------------------------------+
| 1 | SIMPLE | part |...| 20427936 | Using where; Using parallel query (5 columns, 1
filters, 2 exprs; 0 extra) |
+----+-------------+-------+...+----------
+----------------------------------------------------------------------------+
La información de la columna Extra muestra que se extraen cinco columnas de cada fila para evaluar
las condiciones de consulta y construir el conjunto de resultados. Un predicado WHERE implica un filtro,
es decir, una columna que se prueba directamente en la cláusula WHERE. Dos cláusulas WHERE requieren
la evaluación de expresiones más complicadas, en este caso implican llamadas de función. El campo 0
extra confirma que todas las operaciones de la cláusula WHERE se bajan a la capa de almacenamiento
como parte del procesamiento de consultas en paralelo.
En los casos en los que las consultas en paralelo no se eligen, normalmente se puede deducir el motivo
de las otras columnas de la salida EXPLAIN. Por ejemplo, el valor de rows podría ser demasiado pequeño
o la columna possible_keys podría indicar que la consulta puede usar búsqueda de índice en lugar
de un análisis de uso intensivo de datos. En el siguiente ejemplo se muestra una consulta en la que el
optimizador puede estimar, basándose en las características de la clave principal, que la consulta solo
analizará un número pequeño de filas. En este caso, las consultas en paralelo no se requieren.
mysql> explain select count(*) from part where p_partkey between 1 and 100;
+----+-------------+-------+-------+---------------+---------+---------+------+------
+--------------------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows |
Extra |
+----+-------------+-------+-------+---------------+---------+---------+------+------
+--------------------------+
| 1 | SIMPLE | part | range | PRIMARY | PRIMARY | 4 | NULL | 99 |
Using where; Using index |
+----+-------------+-------+-------+---------------+---------+---------+------+------
+--------------------------+
La salida que muestra si se usarán las consultas en paralelo tiene en cuenta todos los factores disponibles
en el momento en que se ejecuta la instrucción EXPLAIN. El optimizador podría realizar una elección
distinta cuando la consulta se ejecute realmente, si la situación ha cambiado mientras tanto. Por ejemplo,
EXPLAIN podría notificar que una instrucción usará consultas en paralelo. Pero cuando la consulta se
ejecute realmente más tarde, podría no usar consultas en paralelo en función de las condiciones de ese
momento. Tales condiciones pueden ser, entre otras, que se estén ejecutando otras varias consultas en
paralelo simultáneamente, filas que se estén eliminando de la tabla, la creación de un nuevo índice, el
paso de demasiado tiempo en una transacción de operador, etc.
Cláusula WHERE
Para que una consulta use la optimización de consultas en paralelo, debe incluir una cláusula WHERE.
La optimización de consultas en paralelo acelera muchos tipos de expresiones usadas en la cláusula

WHERE:
• Comparaciones simples de un valor de columna con una constante, conocidos como filtros. Estas
comparaciones se benefician más de bajarse a la capa de almacenamiento. El número de expresiones
de filtro de una consulta se notifica en la salida de EXPLAIN.
• Otros tipos de expresiones de la cláusula WHERE también se bajan a la capa de almacenamiento cuando
es posible. El número de expresiones de ese tipo en una consulta se notifica en la salida de EXPLAIN.
Dichas expresiones pueden ser llamadas de función, operadores LIKE, expresiones CASE, etc.
• Determinadas funciones y operadores actualmente no se bajan mediante consultas en paralelo. El
número de expresiones de ese tipo en una consulta se notifica como extra en la salida de EXPLAIN. El
resto de la consulta puede seguir usando consultas en paralelo.

583
• Aunque las expresiones de la lista de selección no se bajan, las consultas que contengan tales
funciones siguen pudiendo beneficiarse del tráfico de red reducido por los resultados intermedios de las
consultas en paralelo. Por ejemplo, las consultas que llaman a funciones de agregación en la lista de
selección pueden beneficiarse de las consultas en paralelo, incluso aunque las funciones de agregación
no se bajen.
Por ejemplo, la siguiente consulta realiza un análisis de tabla completa y procesa todos los valores de
la columna P_BRAND. Sin embargo, no usa consultas en paralelo porque la consulta no incluye ninguna
cláusula WHERE.
mysql> explain select count(*), p_brand from part group by p_brand;

+----+-------------+-------+------+---------------+------+---------+------+----------
+---------------------------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows |
Extra |
+----+-------------+-------+------+---------------+------+---------+------+----------
+---------------------------------+
| 1 | SIMPLE | part | ALL | NULL | NULL | NULL | NULL | 20427936 |
Using temporary; Using filesort |
+----+-------------+-------+------+---------------+------+---------+------+----------
+---------------------------------+
Por el contrario, la siguiente consulta incluye predicados de WHERE que filtran los resultados, de forma que
se pueden aplicar las consultas en paralelo:
mysql> explain select count(*), p_brand from part where p_name is not null
-> and p_mfgr in ('Manufacturer#1', 'Manufacturer#3') and p_retailprice > 1000
-> group by p_brand;
+----+...+----------
+------------------------------------------------------------------------------------------------------
+
| id |...| rows | Extra
|
+----+...+----------
+------------------------------------------------------------------------------------------------------
+
| 1 |...| 20427936 | Using where; Using temporary; Using filesort; Using parallel query (5
columns, 1 filters, 2 exprs; 0 extra) |
+----+...+----------
+------------------------------------------------------------------------------------------------------
+
Si el optimizador estima que el número de filas devueltas para un bloque de consulta es pequeño, las
consultas en paralelo no se usan para ese bloque de consultas. En el siguiente ejemplo se muestra un
caso en el que un operador de mayor que de la columna de clave principal se aplica a un millón de filas,
lo que causa que se usen las consultas en paralelo. La prueba contraria de menor que se estima que se
aplicará solo a unas pocas filas y no usa las consultas en paralelo.
mysql> explain select count(*) from part where p_partkey > 10;
+----+...+----------
+----------------------------------------------------------------------------+
|
+----+...+----------
+----------------------------------------------------------------------------+
| 1 |...| 20427936 | Using where; Using parallel query (1 columns, 1 filters, 0 exprs; 0
extra) |

584
+----+...+----------
+----------------------------------------------------------------------------+
mysql> explain select count(*) from part where p_partkey < 10;
+----+...+------+--------------------------+
| id |...| rows | Extra |
+----+...+------+--------------------------+
| 1 |...| 9 | Using where; Using index |
+----+...+------+--------------------------+
Llamadas de función en la cláusula WHERE

Aurora puede aplicar la optimización de consultas en paralelo a llamadas a la mayoría de las funciones
integradas en la cláusula WHERE. La paralelización de estas llamadas de función descarga algo de trabajo
de la CPU del nodo director. La evaluación de las funciones de predicado en paralelo durante la fase inicial
de consulta ayuda a Aurora a minimizar la cantidad de datos que se transmiten y procesan durante las
fases posteriores.
Actualmente, la paralelización no se aplica a llamadas de función de la lista de selección. Dichas funciones

las evalúa el nodo director, incluso aunque aparezca una función idéntica en la cláusula WHERE. Los
valores originales de las columnas relevantes se incluyen en las tuplas transmitidas desde los nodos de
almacenamiento de vuelta al nodo director. El nodo director realiza las transformaciones, como UPPER(),
CONCATENATE(), etc., para producir los valores finales del conjunto de resultados.
En el siguiente ejemplo, las consultas en paralelo paralelizan la llamada a LOWER() porque aparece en
la cláusula WHERE. Las consultas en paralelo no afectan a las llamadas a SUBSTR() y UPPER() porque
aparecen en la lista de selección.
mysql> explain select sql_no_cache distinct substr(upper(p_name),1,5) from part

-> where lower(p_name) like '%cornflower%' or lower(p_name) like '%goldenrod%';
+----+...
+---------------------------------------------------------------------------------------------
+
| id |...| Extra
|
+----+...
+---------------------------------------------------------------------------------------------
+
| 1 |...| Using where; Using temporary; Using parallel query (2 columns, 0 filters, 1
exprs; 0 extra) |
+----+...
+---------------------------------------------------------------------------------------------
+
La misma consideración se aplica a otras expresiones, como las expresiones CASE o los operadores LIKE.
Por ejemplo, en el siguiente ejemplo se muestra que las consultas en paralelo evalúan la expresión CASE y
los operadores LIKE de la cláusula WHERE.
mysql> explain select p_mfgr, p_retailprice from part

-> where p_retailprice > case p_mfgr
-> when 'Manufacturer#1' then 1000
-> when 'Manufacturer#2' then 1200
-> else 950
-> end
-> and p_name like '%vanilla%'
-> group by p_retailprice;
+----+...
+------------------------------------------------------------------------------------------------------
+

585
| id |...| Extra
|
+----+...
+------------------------------------------------------------------------------------------------------
+
| 1 |...| Using where; Using temporary; Using filesort; Using parallel query (4 columns, 0
+----+...
+------------------------------------------------------------------------------------------------------
+
Funciones de agregación, cláusulas GROUP BY y cláusulas

HAVING
Las consultas que implican funciones de agregación suelen ser buenas candidatas para las consultas
en paralelo porque implican el análisis de números grandes de filas en tablas grandes. Las llamadas de
función agregadas en la lista de selección o la cláusula HAVING no se bajan a la capa de almacenamiento.
Sin embargo, las consultas en paralelo siguen mejorando el rendimiento de tales consultas con las
funciones de agregación. Para ello, primero extraen los valores de columna de las páginas de datos sin
procesar en paralelo en la capa de almacenamiento. A continuación, transmiten dichos valores de vuelta al
nodo director en formato compacto de tupla en lugar de como páginas de datos completas. Como siempre,
la consulta requiere al menos un predicado WHERE para que las consultas en paralelo se activen.
En los siguientes ejemplos simples se ilustran los tipos de consultas de agregación que pueden
aprovechar las consultas en paralelo. Para ello, devuelven los resultados intermedios en formato compacto
al nodo director, filtran las filas que no coinciden de los resultados intermedios o ambos.
mysql> explain select sql_no_cache count(distinct p_brand) from part where p_mfgr =
'Manufacturer#5';
+----+...+----------------------------------------------------------------------------+
| id |...| Extra |
+----+...+----------------------------------------------------------------------------+
| 1 |...| Using where; Using parallel query (2 columns, 1 filters, 0 exprs; 0 extra) |
+----+...+----------------------------------------------------------------------------+
mysql> explain select sql_no_cache p_mfgr from part where p_retailprice > 1000 group by
p_mfgr having count(*) > 100;
+----+...
+------------------------------------------------------------------------------------------------------
+
| id |...| Extra
|
+----+...
+------------------------------------------------------------------------------------------------------
+
| 1 |...| Using where; Using temporary; Using filesort; Using parallel query (3 columns, 0
+----+...
+------------------------------------------------------------------------------------------------------
+
Operadores de comparación
El optimizador estima cuántas filas analizar para evaluar los operadores de comparación y determina si
usar las consultas en paralelo en función de dicha estimación.
El primer ejemplo a continuación muestra que puede realizarse una comparación de igualdad con
respecto a la columna de clave principal con eficacia sin usar consultas en paralelo. El segundo ejemplo

586
a continuación muestra que una comparación similar con respecto a una columna no indexada requiere el
análisis de millones de filas y, por tanto, puede sacar partido de las consultas en paralelo.
mysql> explain select * from part where p_partkey = 10;

+----+...+------+-------+
+----+...+------+-------+
| 1 |...| 1 | NULL |
+----+...+------+-------+
mysql> explain select * from part where p_type = 'LARGE BRUSHED BRASS';
+----+...+----------
+----------------------------------------------------------------------------+
|
+----+...+----------
+----------------------------------------------------------------------------+
extra) |
+----+...+----------
+----------------------------------------------------------------------------+
Se aplican las mismas consideraciones para pruebas de desigualdad y para comparaciones de rango,
como de menor que, mayor que, igual a, o BETWEEN. El optimizador estima el número de filas que analizar
y determina si vale la pena usar consultas en paralelo en función del volumen general de E/S.
combinaciones;
Las consultas de unión con tablas grandes suelen implicar operaciones con un uso intensivo de datos que
se benefician de la optimización de consultas en paralelo. Las comparaciones de valores de columnas
entre tablas múltiples (es decir, los predicados de unión en sí) actualmente no se paralelizan. Sin embargo,
las consultas en paralelo pueden bajar algunos de los procesamientos internos para otras fases de unión,
como la construcción del filtro de Bloom durante una unión de hash. Las consultas en paralelo se pueden
aplicar a consultas de unión incluso sin una cláusula WHERE. Por tanto, una consulta de unión es una
excepción a la regla de que se requiere una cláusula WHERE para usar las consultas en paralelo.
Cada fase del procesamiento de unión se evalúa para comprobar si es apto para las consultas en paralelo.
Si varias fases pueden usar consultas en paralelo, estas fases se ejecutan en secuencia. Por tanto,
cada consulta de unión cuenta como una sola sesión de consultas en paralelo en términos de límites de
simultaneidad.
Por ejemplo, cuando una consulta incluye predicados WHERE para filtrar las filas de una de las tablas
unidas, esa opción de filtrado puede usar las consultas en paralelo. Como otro ejemplo, suponga que una
consulta de unión usa el mecanismo de unión de hash, por ejemplo, para unir una tabla grande con una
tabla pequeña. En este caso, el análisis de tabla para producir la estructura de datos de filtro de Bloom
podría usar consultas en paralelo.
Note
Aunque actualmente la característica de unión de hash requiere habilitar el modo lab, las uniones
hash siempre están disponibles en los clústeres habilitados para consultas en paralelo.
mysql> explain select count(*) from orders join customer where o_custkey = c_custkey;
+----+...+----------+-------+---------------+-------------+...+-----------
+------------------------------------------------------------------------------------------------------
+
| id |...| table | type | possible_keys | key |...| rows | Extra

587
+----+...+----------+-------+---------------+-------------+...+-----------
+------------------------------------------------------------------------------------------------------
+
| 1 |...| customer | index | PRIMARY | c_nationkey |...| 15051972 | Using index
|
| 1 |...| orders | ALL | o_custkey | NULL |...| 154545408 | Using join
buffer (Hash Join Outer table orders); Using parallel query (1 columns, 0 filters, 1
exprs; 0 extra) |
+----+...+----------+-------+---------------+-------------+...+-----------
+------------------------------------------------------------------------------------------------------
+
En el caso de una consulta de unión que use el mecanismo de bucle anidado, el bloque de bucle anidado
más exterior podría usar consultas en paralelo. El uso de las consultas en paralelo depende de los factores
habituales, como la presencia de condiciones de filtro adicionales en la cláusula WHERE.
mysql> -- Nested loop join with extra filter conditions can use parallel query.
mysql> explain select count(*) from part, partsupp where p_partkey != ps_partkey and p_name
is not null and ps_availqty > 0;
+----+-------------+----------+...+----------
+----------------------------------------------------------------------------+
|
+----+-------------+----------+...+----------
+----------------------------------------------------------------------------+
| 1 | SIMPLE | part |...| 20427936 | Using where; Using parallel query (2
columns, 1 filters, 0 exprs; 0 extra) |
| 1 | SIMPLE | partsupp |...| 78164450 | Using where; Using join buffer (Block Nested
Loop) |
+----+-------------+----------+...+----------
+----------------------------------------------------------------------------+
Subconsultas
El bloque de consulta exterior y el bloque de subconsulta interior podrían usar o no usar consultas en
paralelo cada uno, en función de las características habituales de la tabla, la cláusula WHERE, etc., para
cada bloque. Por ejemplo, la siguiente consulta usa consultas en paralelo para el bloque de subconsulta,
pero no el bloque exterior.
mysql> explain select count(*) from part where

--> p_partkey < (select max(p_partkey) from part where p_name like '%vanilla%');
+----+-------------+...+----------
+----------------------------------------------------------------------------+
| id | select_type |...| rows | Extra
|
+----+-------------+...+----------
+----------------------------------------------------------------------------+
| 1 | PRIMARY |...| NULL | Impossible WHERE noticed after reading const tables
|
| 2 | SUBQUERY |...| 20427936 | Using where; Using parallel query (2 columns, 0
+----+-------------+...+----------
+----------------------------------------------------------------------------+
UNION
Cada bloque de consulta de una consulta de UNION puede usar o no usar consultas en paralelo, en
función de las características habituales de la tabla, la cláusula WHERE, etc., para cada parte de UNION

588
mysql> explain select p_partkey from part where p_name like '%choco_ate%'
-> union select p_partkey from part where p_name like '%vanil_a%';
+----+----------------+...+----------
+----------------------------------------------------------------------------+
| id | select_type |...| rows | Extra
|
+----+----------------+...+----------
+----------------------------------------------------------------------------+
| 1 | PRIMARY |...| 20427936 | Using where; Using parallel query (2 columns, 0
| 2 | UNION |...| 20427936 | Using where; Using parallel query (2 columns, 0
| NULL | UNION RESULT | <union1,2> |...| NULL | Using temporary
|
+----+--------------+...+----------
+----------------------------------------------------------------------------+
Note
Cada cláusula UNION de la consulta se ejecuta secuencialmente. Incluso aunque la consulta

incluya varias fases que todas usen consultas en paralelo, solo ejecuta una sola consulta en
paralelo cada vez. Por tanto, incluso una consulta multifase compleja solo cuenta como 1 para el
límite de consultas en paralelo simultáneas.
Vistas
El optimizador reescribe cualquier consulta que use una vista como una consulta mayor que use las tablas
subyacentes. Por tanto, las consultas en paralelo funcionan igual tanto si las referencias de tabla son
vistas como si son tablas reales. Las mismas consideraciones sobre si usar consultas en paralelo para una
consulta y qué partes se deben bajar también se aplican a la consulta reescrita final.
Por ejemplo, el siguiente plan de ejecución muestra una definición de vista que normalmente no usa
consultas en paralelo. Cuando se consulta la vista con cláusulas WHERE adicionales, Aurora MySQL usa
consultas en paralelo.
mysql> create view part_view as select * from part;
mysql> explain select count(*) from part_view where p_partkey is not null;
+----+...+----------
+----------------------------------------------------------------------------+
|
+----+...+----------
+----------------------------------------------------------------------------+
extra) |
+----+...+----------
+----------------------------------------------------------------------------+
Instrucciones de lenguaje de manipulación de datos (DML)

La instrucción INSERT puede usar consultas en paralelo para la fase SELECT de procesamiento, si la parte
SELECT cumple las demás condiciones para las consultas en paralelo.
mysql> explain insert into part_subset select * from part where p_mfgr = 'Manufacturer#1';
+----+...+----------
+----------------------------------------------------------------------------+

589

|
+----+...+----------
+----------------------------------------------------------------------------+
extra) |
+----+...+----------
+----------------------------------------------------------------------------+
Note
Normalmente, después de una instrucción INSERT, los datos de las filas recién insertadas se
encuentran en el grupo de búfer. Por tanto, una tabla podría no ser apta para las consultas
en paralelo inmediatamente después de insertar un gran número de filas. Más tarde, cuando
los datos se desalojen del grupo de búfer durante el funcionamiento normal, las consultas con
respecto a la tabla podrían comenzar a usar las consultas en paralelo de nuevo.
La instrucción CREATE TABLE AS SELECT no usa consultas en paralelo, incluso aunque la porción
SELECT de la instrucción fuera apta de otra forma para la consultas en paralelo. El aspecto de DDL de esta
instrucción hace que sea incompatible con el procesamiento de consultas en paralelo. Por el contrario, en
la instrucción INSERT ... SELECT, la porción SELECT puede usar consultas en paralelo.
Las consultas en paralelo nunca se usan para las instrucciones DELETE o UPDATE, independientemente
del tamaño de la tabla y los predicados de la cláusula WHERE.
mysql> explain delete from part where p_name is not null;

+----+-------------+...+----------+-------------+
| id | select_type |...| rows | Extra |
+----+-------------+...+----------+-------------+
| 1 | SIMPLE |...| 20427936 | Using where |
+----+-------------+...+----------+-------------+
Transacciones y bloqueo
Las consultas en paralelo solo se aplican a instrucciones ejecutadas en el nivel de aislamiento
REPEATABLE READ. El nivel de aislamiento es el único que se puede establecer en las instancias de base
de datos Aurora que son réplicas de lectura. Puede usar todos los niveles de aislamiento del servidor
maestro de Aurora.
Después de terminar una gran transacción, las estadísticas de tabla podrían quedar obsoletas. Dichas
estadísticas obsoletas podrían requerir una instrucción ANALYZE TABLE antes de que Aurora pueda
estimar con precisión el número filas. Una instrucción DML a gran escala también podría aportar una
porción sustancial de los datos de tabla en el grupo de búfer. Tener estos datos en el grupo de búfer puede
dar lugar a que las consultas en paralelo se elijan con menos frecuencia para esa tabla hasta que los datos
se desalojen del grupo.
Cuando su sesión esté dentro de una transacción de ejecución prolongada (por ejemplo, 10 minutos),
las consultas posteriores dentro de la sesión no usan consultas en paralelo. También puede agotarse
el tiempo de espera durante una única consulta de ejecución prolongada. Este tipo de finalización del
tiempo de espera podría ocurrir si la consulta se ejecuta durante más del intervalo máximo (actualmente,
10 minutos) antes de que empiece el procesamiento de las consultas en paralelo.
Puede reducir las posibilidades de iniciar transacciones de ejecución prolongada accidentalmente

estableciendo autocommit=1 en las sesiones de mysql en las que realiza consultas ad hoc (de una
vez). Incluso una instrucción SELECT con respecto a una tabla inicia una transacción creando una vista de
lectura. Una vista de lectura es un conjunto de datos uniforme para consultas posteriores que permanece
hasta que la transacción se confirme. Tenga en cuenta esta restricción también al usar aplicaciones

590
de JDBC u ODBC con Aurora porque tales aplicaciones podrían ejecutarse con el ajuste autocommit
desactivado.
En el siguiente ejemplo se muestra cómo, con el ajuste autocommit desactivado, ejecutar una consulta
contra una tabla crea una vista de lectura que inicia implícitamente una transacción. Las consultas que se
ejecutan poco después pueden seguir usando consultas en paralelo. Sin embargo, después de una pausa
de varios minutos, las consultas ya no son aptas para las consultas en paralelo. Terminar la transacción
con COMMIT o ROLLBACK restaura la elegibilidad de las consultas en paralelo.
mysql> set autocommit=0;
mysql> explain select sql_no_cache count(*) from part_txn where p_retailprice > 10.0;
+----+...+---------
+----------------------------------------------------------------------------+
|
+----+...+---------
+----------------------------------------------------------------------------+
extra) |
+----+...+---------
+----------------------------------------------------------------------------+
mysql> select sleep(720); explain select sql_no_cache count(*) from part_txn where
p_retailprice > 10.0;
+------------+
| sleep(720) |
+------------+
| 0 |
+------------+
1 row in set (12 min 0.00 sec)
+----+...+---------+-------------+
+----+...+---------+-------------+
| 1 |...| 2976129 | Using where |
+----+...+---------+-------------+
mysql> commit;
mysql> explain select sql_no_cache count(*) from part_txn where p_retailprice > 10.0;
+----+...+---------
+----------------------------------------------------------------------------+
|
+----+...+---------
+----------------------------------------------------------------------------+
extra) |
+----+...+---------
+----------------------------------------------------------------------------+
Para ver cuántas veces las consultas no fueron aptas para consultas en paralelo porque
estaban dentro de transacciones de ejecución prolongada, consulte la variable de estado
Aurora_pq_not_chosen_long_trx.
mysql> show global status like '%pq%trx%';

+-------------------------------+-------+
+-------------------------------+-------+
| Aurora_pq_not_chosen_long_trx | 4 |

591
+-------------------------------+-------+
Cualquier instrucción SELECT que adquiera bloqueos, como la sintaxis de SELECT FOR UPDATE o
SELECT LOCK IN SHARE MODE, no puede usar consultas en paralelo.
Las consultas en paralelo pueden funcionar para una tabla que esté bloqueada por una instrucción LOCK
TABLES.
mysql> explain select o_orderpriority, o_shippriority from orders where o_clerk =

'Clerk#000095055';
+----+...+-----------
+----------------------------------------------------------------------------+
|
+----+...+-----------
+----------------------------------------------------------------------------+
extra) |
+----+...+-----------
+----------------------------------------------------------------------------+
mysql> explain select o_orderpriority, o_shippriority from orders where o_clerk =

'Clerk#000095055' for update;
+----+...+-----------+-------------+
+----+...+-----------+-------------+
| 1 |...| 154545408 | Using where |
+----+...+-----------+-------------+
Índices
Las estadísticas reunidas por la instrucción ANALYZE TABLE ayudan al optimizador a decidir cuándo
usar las consultas en paralelo o las búsquedas de índice, según las características de los datos de
cada columna. Para mantener las estadísticas actualizadas, ejecute ANALYZE TABLE después de las
operaciones de DML que realicen cambios sustanciales en los datos de una tabla.
Si las búsquedas de índice pueden realizar una consulta de manera eficaz sin un análisis con uso intensivo
de datos, Aurora podría usar búsquedas de índice. Esto evita el gasto general del procesamiento de las
consultas en paralelo. También existen límites de simultaneidad sobre el número de consultas en paralelo
que se pueden ejecutar a la vez en cualquier clúster de base de datos Aurora. Asegúrese de usar las
prácticas recomendadas para indexar sus tablas, de forma que sus consultas más frecuentes y de mayor
simultaneidad usen búsquedas de índice.
Mecanismos de almacenamiento en caché integrados

Aurora incluye mecanismos de almacenamiento en caché integrados, es decir, el grupo de búfer y el caché
de las consultas. El optimizador de Aurora elige entre estos mecanismos de almacenamiento en caché y
las consultas en paralelo en función de cuál es más eficaz para una consulta concreta.
Cuando una consulta en paralelo filtra filas y transforma y extrae valores de columna, los datos se
transmiten de vuelta al nodo director como tuplas en lugar de como páginas de datos. Por tanto, ejecutar
una consulta en paralelo no añade ninguna página al grupo de búfer ni desaloja páginas que ya estén en el
grupo de búfer.
Aurora consulta el número de páginas de datos de tabla que están presentes en el grupo de búfer y qué
proporción de los datos de tabla representa ese número. Aurora usa esa información para determinar si es
más eficaz para usar consultas en paralelo (y omitir los datos del grupo de búfer). De manera alternativa,
Aurora podría usar la ruta de ejecución de consultas no paralelas, que usa los datos almacenados en
caché en el grupo de búfer. Las páginas que se almacenan en caché y cómo afectan las consultas con uso

592
Auditoría avanzada con Aurora MySQL
intensivo de datos al almacenamiento en caché y la expulsión dependen de la configuración relacionada

con el grupo de búfer. Por tanto, puede ser difícil predecir si una consulta concreta usará consultas en
paralelo porque la elección depende de los datos que cambian en el grupo de búfer.
Además, Aurora impone límites de simultaneidad en las consultas paralelas. Puesto que no todas las
consultas usan consultas en paralelo, las tablas a las que acceden múltiples consultas simultáneamente
suelen tener una porción importante de sus datos en el grupo de búfer. Por tanto, Aurora no suele elegir
estas tablas para consultas en paralelo.
Cuando ejecute una secuencia de consultas no paralelas en la misma tabla, la primera consulta podría ser
lenta debido a que los datos no estén en el grupo de búfer. Después, la segunda consulta y las posteriores
son mucho más rápidas puesto que el grupo de búfer ha "calentado". Las consultas en paralelo suelen
mostrar un rendimiento uniforme desde la primera consulta respecto a la tabla. Al realizar pruebas de
rendimiento, haga un análisis comparativo de las consultas no paralelas con un grupo de búfer frío y otro
caliente. En algunos casos, los resultados con un grupo de búfer caliente se pueden comparar bien con
los tiempos de consultas en paralelo. En estos casos, tenga en cuenta factores como la frecuencia de
consultas respecto a esa tabla y si vale la pena conservar los datos para esa tabla en el grupo de búfer.
El caché de la consulta evita volver a ejecutar una consulta cuando se ha enviado una consulta idéntica
y los datos de la tabla subyacente no han cambiado. Las consultas optimizadas por la característica de
consultas en paralelo pueden ir a la caché de consultas, lo que hace que sean instantáneas la siguiente
vez que se ejecuten.
Note
Al realizar comparaciones de rendimiento, la caché de consultas puede producir números de

tiempos artificialmente bajos. Por tanto, en situaciones de análisis comparativo, puede usar la
señal sql_no_cache. Esta señal evita que el resultado se sirva desde la caché de consultas,
incluso aunque se haya ejecutado la misma consulta previamente. La señal va inmediatamente
después de la instrucción SELECT en una consulta. Muchos ejemplos de consultas en paralelo
de este tema incluyen esta señal, para que los tiempos de consultas sean comparables entre las
versiones de la consulta que están habilitadas con las consultas en paralelo y las que no.
Asegúrese de quitar esta señal de su origen cuando pase a usar en producción las consultas en
paralelo.
Tablas temporales MyISAM

La optimización de consultas en paralelo solo se aplica a las tablas InnoDB. Dado que Aurora MySQL
usa MyISAM en segundo plano para las tablas temporales, las fases de consultas internas que impliquen
tablas temporales nunca usan consultas en paralelo. Estas fases de consultas se indican mediante Using
temporary en la salida EXPLAIN.
Uso de auditorías avanzadas con un clúster de

base de datos de Amazon Aurora MySQL
Puede usar la característica de auditoría avanzada de alto desempeño de Amazon Aurora MySQL para
auditar la actividad de la base de datos. Para ello, debe habilitar el conjunto de registros de auditoría
definiendo varios parámetros de clúster de base de datos. Cuando la auditoría avanzada está habilitada,
puede usarla para registrar cualquier combinación de eventos compatibles. Puede ver o descargar los
registros de auditoría para revisarlos.
Note
Puede publicar datos de registro general, lento, de auditoría y error de Aurora MySQL en un grupo
de registro en CloudWatch Logs. Para obtener más información, consulte Publicación de registros
de Amazon Aurora MySQL en Amazon CloudWatch Logs (p. 662).

593
Habilitar la auditoría avanzada
Habilitar la auditoría avanzada

Use los parámetros que se describen en esta sección para habilitar y configurar la auditoría avanzada para
su clúster de base de datos.
Use el parámetro server_audit_logging para habilitar o deshabilitar la auditoría avanzada y el

parámetro server_audit_events para especificar los eventos que se deben registrar.
Use los parámetros server_audit_excl_users y server_audit_incl_users para especificar

a quién se debe auditar. Si server_audit_excl_users y server_audit_incl_users
están vacíos (ajuste predeterminado), se auditan todos los usuarios. Si se añaden usuarios a
server_audit_incl_users y se deja server_audit_excl_users vacío, solo se auditan esos
usuarios. Si se añaden usuarios a server_audit_excl_users y se deja server_audit_incl_users
vacío, solo se excluyen de la auditoría esos usuarios y se auditan los restantes. Si se añaden los mismos
usuarios a server_audit_excl_users y a server_audit_incl_users, se audita a esos usuarios
porque server_audit_incl_users tiene una prioridad más alta.
Configure la auditoría avanzada definiendo estos parámetros en el grupo de parámetros utilizado por su
clúster de base de datos. Puede usar el procedimiento que se muestra en Modificación de parámetros
de un grupo de parámetros de base de datos (p. 265) para modificar los parámetros de clúster de base
de datos usando la Consola de administración de AWS. Puede utilizar el comando modify-db-cluster-
parameter-group de la AWS CLI o el comando ModifyDBClusterParameterGroup de la API de Amazon
RDS para modificar los parámetros de clúster de base de datos mediante programación.
Para modificar estos parámetros no se requiere un reinicio del clúster de base de datos.
server_audit_logging
Habilita o deshabilita la auditoría avanzada. Este parámetro tiene de manera predeterminada el ajuste
OFF; cámbielo a ON para habilitar la auditoría avanzada.
server_audit_events
Contiene una lista delimitada por comas de los eventos que se deben registrar. Los eventos se deben
especificar en mayúsculas y no debe haber espacios en blanco entre los elementos de la lista, por ejemplo:
CONNECT,QUERY_DDL. De manera predeterminada, este parámetro es una cadena vacía.
Puede registrar cualquier combinación de los siguientes eventos:
• CONNECT: registra las conexiones correctas y con error y también las desconexiones. Este evento
incluye información de usuario.
• QUERY: registra todas las consultas en texto sin formato, incluidas las que no se pueden completar
porque contienen errores de sintaxis o de permisos.
• QUERY_DCL: similar al evento QUERY, pero solo devuelve consultas en lenguaje de control de datos
(DCL) (GRANT, REVOKE, etc.).
• QUERY_DDL: similar al evento QUERY, pero solo devuelve consultas en lenguaje de definición de datos
(DDL) (CREATE, ALTER, etc.).
• QUERY_DML: similar al evento QUERY, pero solo devuelve consultas en lenguaje de manipulación de
datos (DML) (INSERT, UPDATE, etc. y también SELECT).
• TABLE: registra las tablas que se han visto afectadas por la ejecución de la consulta.
server_audit_excl_users
Contiene la lista delimitada por comas de los nombres de los usuarios cuya actividad no se registra. No
debe haber espacios en blanco entre los elementos de la lista, por ejemplo: rdsadmin,user_1,user_2.
De manera predeterminada, este parámetro es una cadena vacía. Los nombres de usuario especificados

594
Visualización de registros de auditoría
deben coincidir con los valores correspondientes de la columna User de la tabla mysql.user. Para
obtener más información acerca de los nombres de usuario, consulte la documentación de MySQL.
Los eventos de conexión y desconexión no se ven afectados por esta variable, siempre se
registran si se ha especificado. Un usuario se registra si ese usuario también se especifica en el
parámetro server_audit_incl_users, ya que ese ajuste tiene una prioridad más alta que
server_audit_excl_users.
server_audit_incl_users
Contiene la lista delimitada por comas de los nombres de los usuarios cuya actividad se registra. No debe
haber espacios en blanco entre los elementos de la lista, por ejemplo: user_3,user_4. De manera
predeterminada, este parámetro es una cadena vacía. Los nombres de usuario especificados deben
coincidir con los valores correspondientes de la columna User de la tabla mysql.user. Para obtener más
información acerca de los nombres de usuario, consulte la documentación de MySQL.
Los eventos de conexión y desconexión no se ven afectados por esta variable, siempre se registran si se
ha especificado. Un usuario se registra aunque ese usuario también se haya especificado en el parámetro
server_audit_excl_users, ya que server_audit_incl_users tiene una prioridad más alta.
Visualización de registros de auditoría

Puede ver y descargar los registros de auditoría mediante la consola. En la página Databases (Bases de
datos), elija la instancia de base de datos para mostrar sus detalles y, a continuación, desplácese hasta la
sección Logs (Registros).
Para descargar un archivo de registro, elija ese archivo en la sección Logs (Registros) y, a continuación,
elija Download (Descargar).
También puede obtener una lista de los archivos de registro usando el comando describe-db-log-files de la
AWS CLI. Puede descargar el contenido de un archivo de registro mediante el comando download-db-log-
file-portion de la AWS CLI. Para obtener más información, consulte Visualización y listado de archivos de
registro de base de datos (p. 482) y Descarga de un archivo de registro de base de datos (p. 483).
Detalles de los logs de auditoría

Los archivos de log están en formato UTF-8. Los registros se escriben en varios archivos, cuyo número
varía en función del tamaño de la instancia. Para ver los eventos más recientes, puede ser necesario
revisar todos los archivos de registro de auditoría.
Las entradas del registro no están en orden secuencial. Puede usar el valor de marca temporal para
ordenarlas.
Los archivos de log se rotan cuando llegan a 100 MB combinados. Este límite no se puede configurar.

595
Replicación con Aurora MySQL
Los archivos de registro de auditoría incluyen la siguiente información delimitada por comas en las filas en
el orden especificado:
Campo Descripción
timestamp Marca temporal de Unix para el evento registrado con una precisión de
microsegundos.
serverhost Nombre de la instancia para la que se ha registrado el evento.
nombre de Nombre de usuario conectado del usuario.

usuario
host Host desde el que se ha conectado el usuario.
connectionid Número de ID de conexión de la operación registrada.
queryid Número de ID de la consulta que se puede usar para buscar los eventos de la tabla
relacional y las consultas relacionadas. Para los eventos TABLE, se añaden varias
líneas.
operación Tipo de acción registrado. Los posibles valores son: CONNECT, QUERY, READ, WRITE,
CREATE, ALTER, RENAME y DROP.
base de datos Base de datos activa, definida por el comando USE.
objeto En los eventos QUERY, este valor indica la consulta ejecutada. En los eventos TABLE,
indica el nombre de la tabla.
retcode Código devuelto de la operación registrada.
Replicación con Amazon Aurora MySQL

Las características de replicación de Aurora MySQL son claves para la alta disponibilidad y rendimiento de
su clúster. Aurora facilita la creación o el cambio de tamaño de clústeres con hasta 15 réplicas de Aurora.
Todas las réplicas funcionan desde los mismos datos subyacentes. Si algunas bases de datos se quedan
sin conexión, otras permanecen disponibles para continuar procesando consultas o para hacerse cargo
como escritor si es necesario. Aurora extiende automáticamente las conexiones de solo lectura en varias
instancias de base de datos, lo que ayuda a un clúster de Aurora a admitir cargas de trabajo con uso
intensivo de consultas.
A continuación puede encontrar información sobre cómo funciona la replicación de Aurora MySQL y como
ajustar la configuración de replicación para una disponibilidad y un rendimiento óptimos.
Temas
• Uso de réplicas de Aurora (p. 597)
• Opciones de replicación para Amazon Aurora MySQL (p. 597)
• Consideraciones sobre el rendimiento de la replicación de Amazon Aurora MySQL (p. 598)
• Consideraciones sobre la alta disponibilidad de la replicación de Amazon Aurora MySQL (p. 598)
• Monitorización de replicación de Amazon Aurora MySQL (p. 599)
• Replicación de clústeres de base de datos Amazon Aurora MySQL entre distintas regiones de
AWS (p. 599)
• Replicación entre Aurora y MySQL o entre Aurora y otro clúster de base de datos Aurora (p. 610)
• Uso de replicación basada en GTID para Aurora MySQL (p. 625)

596
Réplicas de Aurora
Uso de réplicas de Aurora

disponibilidad que abarca un clúster de base de datosntro de una región de AWS. Aunque el volumen del
clúster de base de datos se compone de varias copias de los datos del clúster de base de datos, los datos
del volumen de clúster se representan como un único volumen lógico para la instancia principal y para las
réplicas de Aurora del clúster de base de datos. Para obtener más información acerca de las réplicas de
Aurora, consulte Réplicas de Aurora (p. 48).
las operaciones de lectura en el volumen del clúster. Las operaciones de escritura se administran en la
instancia principal. Como el volumen del clúster se comparte entre todas las instancias del clúster de base
de datos Aurora MySQL, no se requiere trabajo adicional para replicar una copia de los datos para cada
réplica de Aurora. En cambio, las réplicas de lectura de MySQL deben volver a reproducir, en un solo
subproceso, todas las operaciones de escritura de la instancia de base de datos maestra en su almacén
de datos local. Esta limitación puede afectar a la capacidad de las réplicas de lectura de MySQL de admitir
grandes volúmenes de tráfico de lectura.
Con Aurora MySQL, cuando se elimina una réplica de Aurora, su punto de enlace de instancia se quita
inmediatamente y la réplica de Aurora se quita del punto de enlace del lector. Si hay declaraciones que
se ejecutan en la réplica de Aurora que se van a eliminar, hay un periodo de gracia de tres minutos. Las
instrucciones existentes pueden finalizar correctamente durante el periodo de gracia. Cuando termina
dicho periodo, se apaga la réplica de Aurora y se elimina.
Important
Las réplicas de Aurora en Aurora MySQL siempre usan el nivel de aislamiento de transacción
predeterminado REPEATABLE READ para las operaciones en las tablas de InnoDB. Puede usar
el comando SET TRANSACTION ISOLATION LEVEL para cambiar el nivel de transacción solo
para la instancia principal de un clúster de base de datos Aurora MySQL. Esta restricción evita los
bloqueos de nivel de usuario en las réplicas de Aurora y permite escalar las réplicas de Aurora
para dar cabida a miles de conexiones de usuario activas manteniendo el retardo de las réplicas
en un valor mínimo.
Note
Las instrucciones DDL ejecutadas en la instancia primaria podrían interrumpir las conexiones
de la base de datos en las réplicas de Aurora asociadas. Si una conexión de réplica de Aurora
está utilizando activamente un objeto de base de datos, como por ejemplo una tabla, y ese objeto
se modifica en la instancia primaria con una declaración DDL, se interrumpe la conexión con la
réplica de Aurora.
Note
La región China (Ningxia) no es compatible con réplicas de lectura entre regiones.
Opciones de replicación para Amazon Aurora MySQL

Puede configurar la replicación entre cualquiera de las opciones siguientes:
• Dos clústeres de base de datos Aurora MySQL de diferentes regiones de AWS mediante la creación de
una réplica de lectura de Aurora de un clúster de base de datos Aurora MySQL en una región de AWS
distinta.
Para obtener más información, consulte Replicación de clústeres de base de datos Amazon Aurora
MySQL entre distintas regiones de AWS (p. 599).

597
Rendimiento
• Dos clústeres de base de datos Aurora MySQL en la misma región de AWS mediante la replicación de
logs binarios (binlog) de MySQL.
Para obtener más información, consulte Replicación entre Aurora y MySQL o entre Aurora y otro clúster
de base de datos Aurora (p. 610).
• Una instancia de base de datos MySQL maestra en Amazon RDS y un clúster de base de datos Aurora
MySQL mediante la creación de una réplica de lectura de Aurora de una instancia de base de datos
MySQL en Amazon RDS.
Normalmente, este método se usa para la migración de Aurora MySQL y no para una replicación
continua. Para obtener más información, consulte Migración de datos desde una instancia de base de
datos MySQL a un clúster de base de datos de Amazon Aurora MySQL con una instantánea de base de
datos (p. 526).
Note
Al reiniciarse la instancia principal de un clúster de base de datos Amazon Aurora también se
reinician automáticamente las réplicas de Aurora de ese clúster de base de datos para restablecer
un punto de entrada que garantice la coherencia de lectura/escritura en el clúster de base de
datos.
Consideraciones sobre el rendimiento de la replicación

de Amazon Aurora MySQL
A partir de Aurora MySQL 1.17.4, las siguientes características ayudan a ajustar el rendimiento de la
replicación de Aurora MySQL.
La característica de compresión de registros de réplica reduce automáticamente en ancho de banda de

la red para los mensajes de replicación. Dado que cada mensaje se transmite a todas las réplicas de
Aurora, los beneficios son mayores para los clústeres de mayor tamaño. Esta característica implica algo
de gasto general de CPU en el nodo escritor para realizar la compresión. Por tanto, esta característica
solo está disponible en las clases de instancia 8xlarge y 16xlarge, que tienen una capacidad de CPU
elevada. Está habilitada de forma predeterminada en estas clases de instancias. Puede controlar esta
característica desactivando el parámetro aurora_enable_replica_log_compression. Por ejemplo,
podría desactivar la compresión de registros de réplica para clases de instancia de mayor tamaño si el
nodo escritor se encuentra cerca de la capacidad de CPU máxima.
La característica de filtrado de binlog reduce automáticamente en ancho de banda de la red para los
mensajes de replicación. Puesto que las réplicas de Aurora no usan la información de binlog que se incluye
en los mensajes de replicación, esos datos se omiten de los mensajes enviados a esos nodos. Puede
controlar esta característica cambiando el parámetro aurora_enable_repl_bin_log_filtering.
Este parámetro está activado de forma predeterminada. Dado que la optimización está pensada para
ser transparente, podría desactivar este ajuste solo durante el diagnóstico o la resolución de problemas
relacionados con la replicación. Por ejemplo, para hacer coincidir el comportamiento de un clúster de
Aurora MySQL más antiguo en el que esta característica no estuviera disponible.
Consideraciones sobre la alta disponibilidad de la

replicación de Amazon Aurora MySQL
Tener más réplicas de Aurora en su clúster ayuda a garantizar una alta disponibilidad. Siempre hay
disponible una instancia de base de datos con una copia completa de sus datos que puede consultar,
incluso aunque algunas instancias de base de datos no estén disponibles.
La compensación de tener múltiples réplicas de Aurora es que las réplicas se vuelven no disponibles
durante periodos breves cuando las instancias de base de datos subyacentes se reinician. Estos reinicios

598
Monitorización
pueden tener lugar durante operaciones de mantenimiento o cuando una réplica empieza a quedar
demasiado rezagada por detrás de la maestra. Reiniciar una réplica interrumpe las conexiones existentes
con la instancia de base de datos correspondiente. Reiniciar un clúster de Aurora causa que todas las
réplicas dejen de estar disponibles a la vez.
A partir de Aurora MySQL 1.17.4, la siguiente característica ayuda a garantizar la alta disponibilidad incluso
durante estos intervalos en los que se reinician las réplicas.
La caracterísita de "reinicio sin tiempo de inactividad" preserva las conexiones existentes cuando se
reinicia una réplica de Aurora MySQL, por ejemplo, si la réplica cae demasiado lejos de la maestra.
Cualquier transacción abierta se revierte y su aplicación deberá reintentarla. Para habilitar esta
característica, active el parámetro aurora_enable_zdr en el grupo de parámetros del clúster. Este
parámetro está desactivado de forma predeterminada.
Monitorización de replicación de Amazon Aurora

MySQL
El escalado de lectura y la alta disponibilidad dependen de que el tiempo de retardo sea mínimo. Puede
monitorizar el retardo de una réplica de Aurora con respecto a la instancia principal del clúster de base
de datos Aurora MySQL mediante la monitorización de la métrica ReplicaLag de Amazon CloudWatch.
Como las réplicas de Aurora leen desde el mismo volumen de clúster que la instancia principal, la métrica
ReplicaLag tiene un significado diferente para un clúster de base de datos Aurora MySQL. La métrica
ReplicaLag de una réplica de Aurora indica el retardo para la caché de la página de la réplica de Aurora
comparado con el de la instancia principal.
Si necesita el valor más actualizado del retardo de la réplica de Aurora, puede consultar la tabla
mysql.ro_replica_status de su clúster de base de datos Aurora MySQL y comprobar el valor en
la columna Replica_lag_in_msec. El valor de esa columna se proporciona a Amazon CloudWatch
como el valor de la métrica ReplicaLag. Los valores de mysql.ro_replica_status también se
proporcionan en la tabla INFORMATION_SCHEMA.REPLICA_HOST_STATUS del clúster de base de datos
Aurora MySQL.
Para obtener más información acerca de la monitorización de instancias de RDS y de métricas de

CloudWatch, consulte Monitorización de un clúster de base de datos de Amazon Aurora (p. 363).
Replicación de clústeres de base de datos Amazon

Aurora MySQL entre distintas regiones de AWS
Puede crear un clúster de base de datos Amazon Aurora MySQL como réplica de lectura en una región
de AWS distinta a la del clúster de base de datos de origen. Utilizar este método puede mejorar las
capacidades de recuperación de desastres, permitirle escalar las operaciones de lectura en una región de
AWS que esté más cerca de sus usuarios y facilitar la migración de una región de AWS a otra.
Puede crear réplicas de lectura de clústeres de base de datos cifrados y sin cifrar. La réplica de lectura se
debe cifrar si el clúster de base de datos de origen está cifrado.
Por cada clúster de base de datos origen, puede tener hasta cinco clústeres de base de datos réplica de
lectura con varias regiones. Cuando se crea una réplica de lectura de clúster de base de datos Aurora
MySQL en otra región de AWS, se debe tener en cuenta lo siguiente:
• Tanto el clúster de base de datos origen como el clúster de base de datos réplica de lectura entre
regiones pueden tener un máximo de 15 réplicas de Aurora junto con la instancia principal del clúster de
base de datos. Usando esta funcionalidad, puede escalar las operaciones de lectura tanto para la región
de AWS de origen como para la región de AWS de destino de la replicación.
• En una situación con varias regiones, hay más tiempo de retardo entre el clúster de base de datos de
origen y la réplica de lectura porque los canales de red entre regiones son más largos.

599
• Los datos transferidos en las replicaciones entre regiones conllevan cargos por transferencia de datos
de Amazon RDS. Las siguientes acciones de replicación entre regiones generan cargos para los datos
transferidos fuera de la región de AWS de origen:
• Cuando se crea la réplica de lectura, Amazon RDS realiza un snapshot del clúster de origen y
transfiere el snapshot a la región de la réplica de lectura.
• Para cada modificación de datos realizada en las bases de datos de origen, Amazon RDS transfiere
los datos de la región de origen a la región de la réplica de lectura.
Para obtener más información acerca de los precios de las transferencias de datos de Amazon RDS,
consulte Precios de Amazon Aurora.
• Puede ejecutar varias acciones de creación o eliminación simultáneas para réplicas de lectura que
hagan referencia al mismo clúster de base de datos origen. Sin embargo, debe permanecer dentro del
límite de cinco réplicas de lectura por cada clúster de base de datos de origen.
• Para que la replicación sea eficaz, cada réplica de lectura debe tener la misma cantidad de recursos
de computación y de almacenamiento que el clúster de base de datos origen. Si modifica la escala del
clúster de base de datos origen, debe ajustar también la escala de las réplicas de lectura.
Temas
• Antes de comenzar (p. 600)
• Creación de un clúster de base de datos Amazon Aurora MySQL que sea una réplica de lectura entre
regiones (p. 600)
• Visualización de réplicas entre regiones de Amazon Aurora MySQL (p. 608)
• Promoción de una réplica de lectura para convertirla en un clúster de base de datos (p. 608)
• Solución de problemas de las réplicas entre regiones de Amazon Aurora MySQL (p. 610)
Antes de comenzar
Antes de crear un clúster de base de datos Aurora MySQL que sea una réplica de lectura entre regiones,
debe habilitar el registro binario en el clúster de base de datos Aurora MySQL de origen. La replicación
entre regiones de Aurora MySQL usa la replicación binaria de MySQL para volver a reproducir los cambios
en el clúster de base de datos de la réplica de lectura entre regiones.
Para habilitar el registro binario en un clúster de base de datos Aurora MySQL, actualice el parámetro
binlog_format para el clúster de base de datos origen. El parámetro binlog_format es un parámetro
de nivel de clúster que se encuentra en el grupo de parámetros de clúster predeterminado. Si su clúster
de base de datos usa el grupo de parámetros de clúster de base de datos predeterminado, cree un nuevo
grupo de parámetros de clúster de base de datos para modificar la configuración de binlog_format.
Es recomendable que defina binlog_format como MIXED. Sin embargo, también puede configurar
binlog_format como ROW o STATEMENT si necesita un formato binlog concreto. Reinicie el clúster de
base de datos de Aurora para que el cambio entre en vigor.
Para obtener más información, consulte Parámetros del clúster de base de datos y la instancia de base
de datos Amazon Aurora (p. 261) y Trabajo con los grupos de parámetros de base de datos y grupos de
Creación de un clúster de base de datos Amazon Aurora MySQL

que sea una réplica de lectura entre regiones
Puede crear un clúster de base de datos Aurora que sea una réplica de lectura entre regiones usando
la Consola de administración de AWS, la AWS Command Line Interface (AWS CLI) o la API de Amazon
RDS. Puede crear réplicas de lectura entre regiones desde clústeres de base de datos cifrados y sin cifrar.
Cuando se crea una réplica de lectura entre regiones para Aurora MySQL con la Consola de
administración de AWS, Amazon RDS crea un clúster de base de datos en la región de AWS de destino y,

600
a continuación, crea automáticamente una instancia de base de datos que es la instancia principal de ese
Cuando se crea una réplica de lectura entre regiones usando la AWS CLI o la API de RDS, primero se crea
el clúster de base de datos en la región de AWS de destino y se espera a que pase a estar activo. Una vez
que está activo, se crea una instancia de base de datos que es la instancia principal de ese clúster de base
de datos.
La replicación comienza cuando la instancia principal del clúster de base de datos de la réplica de lectura
pasa a estar disponible.
Use los siguientes procedimientos para crear una réplica de lectura entre regiones a partir de un clúster
de base de datos de Aurora MySQL. Estos procedimientos sirven para crear réplicas de lectura desde
clústeres de base de datos cifrados y sin cifrar.
Consola
Para crear un clúster de base de datos Aurora MySQL que sea una réplica de lectura entre
regiones con la Consola de administración de AWS
que aloja el clúster de base de datos de origen.
4. Active la casilla de verificación de la instancia de base de datos para el que desea crear una réplica de
lectura entre regiones. En Actions (Acciones), elija Create cross region read replica (Crear réplica de
lectura entre regiones).
5. En la página Create cross region read replica (Crear réplica de lectura entre regiones), elija la
configuración de opciones para su clúster de base de datos réplica de lectura entre regiones, como se
describe en la siguiente tabla.
Destination region (Región de destino) Elija la región de AWS que alojará el nuevo clúster de base
de datos de réplica de lectura entre regiones.
Destination DB subnet group (Destino Elija el grupo de subredes de base de datos que se debe
del grupo de subredes de base de usar para el clúster de base de datos de réplica de lectura
datos) entre regiones.
Publicly accessible (Accesible Elija Yes (Sí) para dar al clúster de base de datos réplica
públicamente) de lectura entre regiones una dirección IP pública; de lo
contrario, seleccione No.
Cifrado Seleccione Enable Encryption (Habilitar cifrado) para

habilitar el cifrado en reposo para este clúster de base de
datos. Para obtener más información, consulte Cifrado de
recursos de Amazon Aurora (p. 158).
Clave maestra Solo está disponible si Encryption (Cifrado) se establece

en Enable Encryption (Habilitar cifrado). Seleccione la
clave maestra que se va a usar para el cifrado de este
clúster de base de datos. Para obtener más información,
consulte Cifrado de recursos de Amazon Aurora (p. 158).

601
Implementación Multi-AZ Elija Yes (Sí) para crear una réplica en espera del nuevo
clúster de base de datos en otra zona de disponibilidad de
la región de AWS de destino para permitir la conmutación
por error. Para obtener más información acerca del uso
Read replica source (Origen de réplica Elija el clúster de base de datos de origen para el que
de lectura) desea crear una réplica de lectura entre regiones.
DB Instance Identifier (Identificador de Escriba un nombre para la instancia principal de su clúster

instancias de bases de datos) de base de datos de réplica de lectura entre regiones.
Este identificador se utiliza en la dirección del punto de
enlace de la instancia principal del nuevo clúster de base
de datos.


guiones.
consecutivos.
AWS.
Como el clúster de base de datos de réplica de lectura

entre regiones se crea a partir de un snapshot del clúster
de base de datos de origen, el nombre de usuario maestro
y la contraseña maestra de la réplica de lectura coinciden
con el nombre de usuario maestro y la contraseña maestra
del clúster de base de datos de origen.

602
DB cluster identifier (Identificador de Escriba un nombre para el clúster de base de datos de

clúster de base de datos) réplica de lectura entre regiones que sea único para su
cuenta en la región de AWS de destino de la réplica.
Este identificador se utiliza en la dirección del punto
de enlace del clúster para su clúster de base de datos.
Para obtener información acerca del punto de enlace del
clúster, consulte Administración de conexiones de Amazon
Aurora (p. 3).


guiones.
consecutivos.
AWS.
Prioridad Elija una prioridad de conmutación por error para la

primera instancia del nuevo clúster de base de datos. Esta
prioridad determina el orden en que se promueven las
réplicas de Aurora cuando el sistema se recupera de un
error en la instancia principal. Si no selecciona un valor,
el ajuste predeterminado es tier-1. Para obtener más
información, consulte Tolerancia a errores para un clúster
de base de datos de Aurora (p. 314).
Los clústeres de base de datos de Aurora usan de forma
predeterminada el puerto 3306 de MySQL. Los firewalls
de algunas compañías bloquean las conexiones a este
puerto. Si el firewall de su compañía bloquea el puerto
predeterminado, elija otro puerto para el nuevo clúster de
base de datos.

mejorada) mejorada) a fin de habilitar la recopilación de métricas
en tiempo real para el sistema operativo en el que se
ejecuta su clúster de base de datos. Para obtener más
información, consulte Monitorización mejorada (p. 395).

mejorada (p. 395).

603

(Actualización automática de versiones datos Aurora MySQL.
secundarias)
6. Elija Create (Crear) para crear una réplica de lectura entre regiones de Aurora.
AWS CLI
regiones con la CLI
1. Llame al comando create-db-cluster de la AWS CLI en la región de AWS en la que desee crear
el clúster de base de datos de la réplica de lectura. Incluya la opción --replication-source-
identifier y especifique el Nombre de recurso de Amazon (ARN) del clúster de base de datos de
origen para el que desea crear una réplica de lectura.
Para una replicación entre regiones en la que el clúster de base de datos identificado por --
replication-source-identifier esté cifrado, debe especificar también las opciones --kms-
key-id y --storage-encrypted. Además, debe especificar la opción --source-region o --
pre-signed-url. Al usar --source-region se genera automáticamente una URL prefirmada que
es una solicitud válida para la acción de la API CreateDBCluster que se puede ejecutar en la región
de AWS de origen que contiene el clúster de base de datos cifrado que se va a replicar. El uso de --
pre-signed-url requiere crear manualmente una URL prefirmada. El ID de la clave de KMS se usa
para cifrar la réplica de lectura y debe ser una clave de cifrado de KMS válida para la región de AWS
de destino. Para obtener más información acerca de estas opciones, consulte create-db-cluster.
Note
Puede configurar la replicación entre regiones desde un clúster de base de datos sin cifrar en
una réplica de lectura cifrada especificando --storage-encrypted y proporcionando un
valor para --kms-key-id. En este caso, no es necesario especificar --source-region o
--pre-signed-url.
No tiene que incluir los parámetros --master-username y --master-user-password, porque

esos valores se toman del clúster de base de datos de origen.
El siguiente ejemplo de código crea una réplica de lectura en la región us-east-1 a partir de un
snapshot de clúster de base de datos sin cifrar de la región us-west-2. Se llama al comando en la
región us-east-1.

--db-cluster-identifier sample-replica-cluster \
--engine aurora \
--replication-source-identifier arn:aws:rds:us-west-2:123456789012:cluster:sample-
master-cluster

604
Para Windows:

--db-cluster-identifier sample-replica-cluster ^
--engine aurora ^
master-cluster
snapshot de clúster de base de datos cifrado de la región us-west-2. Se llama al comando en la región
us-east-1.

--engine aurora \
master-cluster \
--kms-key-id my-us-east-1-key \
--source-region us-west-2 \
--storage-encrypted
Para Windows:

--engine aurora ^
master-cluster ^
--kms-key-id my-us-east-1-key ^
--source-region us-west-2 ^
--storage-encrypted
2. Compruebe que el clúster de base de datos está disponible para su uso con el comando describe-
db-clusters de la AWS CLI, como se muestra en el siguiente ejemplo.
aws rds describe-db-clusters --db-cluster-identifier sample-replica-cluster
Cuando los resultados de describe-db-clusters muestren el estado available, cree la

instancia principal del clúster de base de datos para que pueda comenzar la replicación. Para ello,
utilice el comando create-db-instance de la AWS CLI como se muestra en el siguiente ejemplo.

--db-instance-class db.r3.large \
--db-instance-identifier sample-replica-instance \
--engine aurora

605
Para Windows:

--db-instance-class db.r3.large ^
--db-instance-identifier sample-replica-instance ^
--engine aurora
Cuando la instancia de base de datos se ha creado y está disponible, comienza la replicación. Puede
determinar si la instancia de base de datos está disponible llamando al comando describe-db-
instances de la AWS CLI.
API de RDS
regiones con la API
1. Llame a la acción CreateDBCluster de la API de RDS en la región de AWS en la que

desea crear el clúster de base de datos de la réplica de lectura. Incluya el parámetro
ReplicationSourceIdentifier y especifique el Nombre de recurso de Amazon (ARN) del clúster
de base de datos de origen para el que desea crear una réplica de lectura.
Para una replicación entre regiones en la que el clúster de base de datos identificado por
ReplicationSourceIdentifier esté cifrado, debe especificar el parámetro KmsKeyId y
establecer el parámetro StorageEncrypted en true. También debe especificar el parámetro
PreSignedUrl. La URL prefirmada debe ser una solicitud válida para la acción de la API
CreateDBCluster que se pueda ejecutar en la región de AWS de origen que contiene el clúster de
base de datos cifrado que se va a replicar. El ID de la clave de KMS se usa para cifrar la réplica de
lectura y debe ser una clave de cifrado de KMS válida para la región de AWS de destino. Para generar
una URL prefirmada de forma automática y no manual, utilice el comando create-db-cluster de la
AWS CLI con la opción --source-region.
Note
Puede configurar la replicación entre regiones desde un clúster de base de datos sin
cifrar en una réplica de lectura cifrada especificando StorageEncrypted como true
y proporcionando un valor para KmsKeyId. En este caso, no es necesario especificar
PreSignedUrl.
No tiene que incluir los parámetros MasterUsername y MasterUserPassword, porque esos valores
se toman del clúster de base de datos de origen.
snapshot de clúster de base de datos sin cifrar de la región us-west-2. Se llama a la acción en la
región us-east-1.
&ReplicationSourceIdentifier=arn:aws:rds:us-west-2:123456789012:cluster:sample-
master-cluster
&DBClusterIdentifier=sample-replica-cluster
&Engine=aurora
&SignatureVersion=4
&Version=2014-10-31

606
&X-Amz-Date=20160201T001547Z
&X-Amz-Signature=a04c831a0b54b5e4cd236a90dcb9f5fab7185eb3b72b5ebe9a70a4e95790c8b7
snapshot de clúster de base de datos cifrado de la región us-west-2. Se llama a la acción en la región
us-east-1.
&KmsKeyId=my-us-east-1-key
&StorageEncrypted=true
&PreSignedUrl=https%253A%252F%252Frds.us-west-2.amazonaws.com%252F
%253FAction%253DCreateDBCluster
%2526DestinationRegion%253Dus-east-1
%2526KmsKeyId%253Dmy-us-east-1-key
%2526ReplicationSourceIdentifier%253Darn%25253Aaws%25253Ards%25253Aus-
west-2%25253A123456789012%25253Acluster%25253Asample-master-cluster
%2526SignatureMethod%253DHmacSHA256
%2526SignatureVersion%253D4
%2526Version%253D2014-10-31
%2526X-Amz-Algorithm%253DAWS4-HMAC-SHA256
%2526X-Amz-Credential%253DAKIADQKE4SARGYLE%252F20161117%252Fus-west-2%252Frds
%252Faws4_request
%2526X-Amz-Date%253D20161117T215409Z
%2526X-Amz-Expires%253D3600
%2526X-Amz-SignedHeaders%253Dcontent-type%253Bhost%253Buser-agent%253Bx-amz-
content-sha256%253Bx-amz-date
%2526X-Amz-Signature
%253D255a0f17b4e717d3b67fad163c3ec26573b882c03a65523522cf890a67fca613
&ReplicationSourceIdentifier=arn:aws:rds:us-west-2:123456789012:cluster:sample-
master-cluster
&Engine=aurora
&SignatureVersion=4
&Version=2014-10-31
&X-Amz-Date=20160201T001547Z
&X-Amz-Signature=a04c831a0b54b5e4cd236a90dcb9f5fab7185eb3b72b5ebe9a70a4e95790c8b7
2. Compruebe que el clúster de base de datos está disponible para el uso con la acción
DescribeDBClusters de la API de RDS, como se muestra en el siguiente ejemplo.
?Action=DescribeDBClusters
&SignatureVersion=4
&Version=2014-10-31
&X-Amz-Date=20160201T002223Z
&X-Amz-Signature=84c2e4f8fba7c577ac5d820711e34c6e45ffcd35be8a6b7c50f329a74f35f426

607
Cuando los resultados de DescribeDBClusters muestren el estado available, cree la instancia

principal del clúster de base de datos para que pueda comenzar la replicación. Para ello, use la acción
CreateDBInstance de la API de RDS, como se muestra en el siguiente ejemplo.
&DBInstanceClass=db.r3.large
&DBInstanceIdentifier=sample-replica-instance
&Engine=aurora
&SignatureVersion=4
&Version=2014-10-31
&X-Amz-Date=20160201T003808Z
&X-Amz-Signature=125fe575959f5bbcebd53f2365f907179757a08b5d7a16a378dfa59387f58cdb
Cuando la instancia de base de datos se ha creado y está disponible, comienza la replicación.

Puede determinar si la instancia de base de datos está disponible llamando al comando
DescribeDBInstances de la AWS CLI.
Visualización de réplicas entre regiones de Amazon Aurora

MySQL
Puede ver las relaciones de replicación entre regiones de sus clústeres de base de datos de
Amazon Aurora MySQL llamando al comando describe-db-clusters de la AWS CLI o
a la acción DescribeDBClusters de la API de RDS. En la respuesta, consulte el campo
ReadReplicaIdentifiers para ver los identificadores de clúster de base de datos de todos
los clústeres de base de datos de réplica de lectura entre regiones y compruebe el elemento
ReplicationSourceIdentifier para ver el ARN del clúster de base de datos de origen que es el
maestro de replicación.
Promoción de una réplica de lectura para convertirla en un clúster

de base de datos
Puede promover una réplica de lectura de Aurora MySQL a un clúster de base de datos independiente.
Cuando se promueve una réplica de lectura de Aurora MySQL, las instancias de base de datos se reinician
antes de que estén disponibles.
Normalmente, una réplica de lectura de Aurora MySQL se promueve a un clúster de base de datos
independiente como un esquema de recuperación de datos si el clúster de base de datos de origen
devuelve un error.
Para ello, cree primero una réplica de lectura y, a continuación, monitoree el clúster de base de datos de
origen para ver si se producen errores. En caso de error, haga lo siguiente:
1. Promueva la réplica de lectura.

2. Dirija el tráfico de la base de datos al clúster de base de datos promovido.
3. Cree una réplica de lectura de reemplazo que tenga el clúster de base de datos promovido como origen.

608
Cuando promueve una réplica de lectura, esta se convierte en un clúster de base de datos de Aurora
independiente. Este proceso de promoción puede tardar unos minutos o más, según el tamaño de la
réplica de lectura. Una vez que haya promovido la réplica de lectura a un nuevo clúster de base de datos,
este será como cualquier otro clúster de base de datos. Por ejemplo, podrá crear réplicas de lectura a
partir de él y realizar operaciones de restauración a un momento dado. También puede crear réplicas de
Aurora para el clúster de base de datos.
Como el clúster de base de datos promovido ya no es una réplica de lectura, no puede usarlo como
destino de la replicación.
Los siguientes pasos muestran el proceso general para promover una réplica de lectura a un clúster de
base de datos:
1. Detenga la escritura de transacciones en el clúster de base de datos de origen de la réplica

de lectura y espere hasta que se hayan realizado todas las actualizaciones en la réplica de
lectura. Las actualizaciones de la base de datos se producen en la réplica de lectura después de
completarse en el clúster de base de datos de origen y el retardo de esta replicación puede variar
considerablemente. Utilice la métrica Retraso de réplica para determinar cuándo se han completado
todas las actualizaciones en la réplica de lectura.
2. Promocione la réplica de lectura usando la opción Promote Read Replica (Promocionar réplica de
lectura) de la consola de Amazon RDS, el comando promote-read-replica-db-cluster de la
AWS CLI o la operación PromoteReadReplicaDBCluster de la API de Amazon RDS.
Elija una instancia de base de datos de Aurora MySQL para promover la réplica de lectura. Una vez
promovida la réplica de lectura, el clúster de base de datos de Aurora MySQL se promueve a un clúster
de base de datos independiente. La instancia de base de datos con la prioridad más alta se promueve
a la instancia de base de datos principal del clúster de base de datos. Las demás instancias de base de
datos se convierten en réplicas de Aurora.
Note
El proceso de promoción tarda algunos minutos en completarse. Cuando se promueve una

réplica de lectura, la replicación se detiene y las instancias de base de datos se reinician. Una
vez completado el reinicio, la réplica de lectura pasa a estar disponible como un nuevo clúster
de base de datos.
Consola
Para promover una réplica de lectura de Aurora MySQL a un clúster de base de datos
2. En la consola de Amazon RDS, elija Instances (Instancias).
Aparece el panel Instance (Instancia).

3. En el panel Instances (Instancias), seleccione la réplica de lectura que desea promover.
Las réplicas de lectura aparecen como instancias de base de datos de Aurora MySQL.
4. En Actions (Acciones), elija Promote read replica (Promover réplica de lectura).
5. En la página de confirmación, elija Promote Read Replica.
AWS CLI
Para promocionar una réplica de lectura a un clúster de base de datos, utilice el comando promote-
read-replica-db-cluster de la AWS CLI.
609
Replicación entre Aurora y MySQL o entre
Aurora y otro clúster de base de datos Aurora
Example

--db-cluster-identifier mydbcluster
Para Windows:

--db-cluster-identifier mydbcluster
API de RDS
Para promocionar una réplica de lectura a un clúster de base de datos, llame a

PromoteReadReplicaDBCluster.
Solución de problemas de las réplicas entre regiones de Amazon

Aurora MySQL
A continuación, puede encontrar una lista de mensajes de error frecuentes que pueden aparecer al crear
una réplica de lectura entre regiones de Amazon Aurora y las soluciones de los errores especificados.
Source cluster [DB cluster ARN] doesn't have binlogs enabled

Para resolver este problema, habilite el registro binario en el clúster de base de datos de origen. Para
obtener más información, consulte Antes de comenzar (p. 600).
Source cluster [DB cluster ARN] doesn't have cluster parameter group in sync on
writer
Este error aparece si se ha actualizado el parámetro binlog_format del clúster de base de datos pero
no se ha reiniciado su instancia principal. Reinicie la instancia principal (es decir, la de escritura) del clúster
de base de datos y vuelva a intentarlo.
Source cluster [DB cluster ARN] already has a read replica in this region
Solo puede tener un clúster de base de datos réplica de lectura con varias regiones por cada clúster de
base de datos en cada región de AWS. Para crear un nuevo clúster de base de datos entre regiones que
sea una réplica de lectura en una región de AWS concreta, debe eliminar el existente.
DB cluster [DB cluster ARN] requires a database engine upgrade for cross-region
replication support
Para resolver este problema, actualice la versión del motor de base de datos para todas las instancias del
clúster de base de datos de origen a la versión más reciente del motor de base de datos e intente de nuevo
crear una base de datos de réplica de lectura entre regiones.
Replicación entre Aurora y MySQL o entre Aurora y

otro clúster de base de datos Aurora
Dado que Amazon Aurora MySQL es compatible con MySQL, puede configurar la replicación entre una
base de datos MySQL y un clúster de base de datos Amazon Aurora MySQL. Es recomendable utilizar

610
la versión 5.5 o posterior de la base de datos de MySQL. Puede configurar la replicación de modo que el
clúster de base de datos Aurora MySQL sea el maestro de replicación o la réplica y puede replicar con una
instancia de base de datos MySQL en Amazon RDS, una base de datos MySQL externa a Amazon RDS u
otro clúster de base de datos Aurora MySQL.
También puede replicar con una instancia de base de datos MySQL en Amazon RDS o con un clúster
de base de datos Aurora MySQL en otra región de AWS. Cuando esté realizando una replicación entre
regiones de AWS, asegúrese de que los clústeres y las instancias de base de datos estén públicamente
accesibles. Los clústeres de base de datos Aurora MySQL deben formar parte de una subred pública de la
VPC.
Si desea configurar una replicación entre un clúster de base de datos Aurora MySQL y un clúster de base
de datos Aurora MySQL en otra región, puede crear un clúster de base de datos Aurora MySQL como
réplica de lectura en una región de AWS diferente del clúster de base de datos origen. Para obtener más
información, consulte Replicación de clústeres de base de datos Amazon Aurora MySQL entre distintas
regiones de AWS (p. 599).
Con Aurora MySQL 2.04 y versiones posteriores, puede replicar entre Aurora MySQL y una fuente
o destino externos que utilicen identificadores de transacciones globales (GTID) para la replicación.
Asegúrese de que los parámetros relacionados con GTID en el clúster de base de datos de Aurora MySQL
disponga de una configuración que sea compatible con el estado del GTID de la base de datos externa.
Para obtener información sobre como hacer esto, consulte Uso de replicación basada en GTID para Aurora
MySQL (p. 625).
Warning
Cuando replique entre Aurora MySQL y MySQL, asegúrese de usar únicamente tablas InnoDB.
Si tiene tablas de MyISAM que desea replicar, puede convertirlas a InnoDB antes de configurar la
replicación con el siguiente comando.
alter table <schema>.<table_name> engine=innodb, algorithm=copy;
La configuración de la replicación de MySQL con Aurora MySQL incluye los siguientes pasos, que se
describen en detalle en este tema:
1. Habilite el registro binario en el maestro de replicación (p. 611)
2. Conserve los registros binarios en el maestro de replicación hasta que dejen de ser
necesarios (p. 615)
3. Cree una instantánea del maestro de replicación (p. 617)
4. Cargue la instantánea en el destino de la réplica (p. 619)
5. Habilite la replicación en el destino de la réplica (p. 621)
6. Monitorice su réplica (p. 623)
Configuración de la replicación con MySQL o con otro clúster de

base de datos de Aurora
Para configurar la replicación de Aurora con MySQL, lleve a cabo los siguientes pasos.
1. Habilite el registro binario en el maestro de replicación

Puede encontrar instrucciones acerca del procedimiento para habilitar el registro binario en el maestro de
replicación de su motor de base de datos a continuación.

611
Motor de Instrucciones
base de
datos
Aurora Para habilitar el registro binario en un clúster de base de datos Aurora MySQL
Establezca el parámetro binlog_format en ROW, STATEMENT o MIXED. Se recomienda

usar MIXED a menos que se requiera un formato binlog específico. El parámetro
binlog_format es un parámetro de nivel de clúster que se encuentra en el grupo de
parámetros de clúster predeterminado. Si va a cambiar el parámetro binlog_format de
OFF a otro valor, debe reiniciar el clúster de base de datos de Aurora para que el cambio
tenga efecto.
Para obtener más información, consulte Parámetros del clúster de base de datos y
la instancia de base de datos Amazon Aurora (p. 261) y Trabajo con los grupos de
RDS Para habilitar el registro binario en una instancia de base de datos de Amazon RDS
MySQL
No puede habilitar el registro binario directamente para una instancia de base de datos de
Amazon RDS, pero puede habilitarlo por medio de uno de los siguientes procedimientos:
• Habilite los backups automatizados para la instancia de base de datos. Puede habilitar
backups automatizados cuando cree una instancia de base de datos o puede habilitar
backups modificando una instancia de base de datos ya existente. Para obtener más
información, consulte Creación de una instancia de base de datos que ejecuta el motor
de base de datos MySQL en la Guía del usuario de Amazon Relational Database
Service.
• Cree una réplica de lectura para la instancia de base de datos. Para obtener más
información, consulte Trabajo con réplicas de lectura de instancias de base de datos
MariaDB, MySQL y PostgreSQL en la Guía del usuario de Amazon Relational Database
Service.
MySQL Para configurar la replicación cifrada

(externo)
Para replicar los datos de forma segura con la versión 5.6 de Aurora MySQL, puede usar la
replicación cifrada.
Actualmente, la replicación cifrada con una base de datos MySQL externa solo es
compatible con la versión 5.6 de Aurora MySQL.
Note
Si no necesita usar la replicación cifrada, puede omitir estos pasos.
A continuación, se indican los requisitos previos para utilizar la replicación cifrada:
• La Capa de conexión segura (SSL) debe estar habilitada en la base de datos maestra
MySQL externa.
• Debe disponerse de una clave cliente y un certificado cliente para el clúster de base de
datos de Aurora MySQL.
Durante la replicación cifrada, el clúster de base de datos Aurora MySQL actúa como un
cliente en el servidor de base de datos MySQL. Los certificados y las claves del cliente de
Aurora MySQL son archivos con formato .pem.
1. Compruebe que esté preparado para la replicación cifrada:

612
base de
datos
• Si no tiene SSL habilitado en la base de datos maestra MySQL externa y no dispone
de una clave cliente y de un certificado cliente, habilite SSL en el servidor de base
de datos MySQL y genere la clave cliente y el certificado cliente necesarios.
• Si SSL está habilitado en la base de datos maestra externa, proporcione una clave
cliente y un certificado cliente para el clúster de base de datos Aurora MySQL. Si
no los tiene, genere una nueva clave y certificado para el clúster de base de datos
Aurora MySQL. Para firmar el certificado cliente, debe tener la clave de la entidad
de certificación que usó para configurar SSL en la base de datos maestra MySQL
externa.
Para obtener más información, consulte Creating SSL Certificates and Keys Using
openssl en la documentación de MySQL.
Necesita un certificado de la entidad de certificación, la clave cliente y el certificado

cliente.
2. Conéctese al clúster de base de datos Aurora MySQL como usuario maestro mediante
SSL.
Para obtener información acerca de la conexión a un clúster de base de datos Aurora

MySQL con SSL, consulte Uso de SSL con clústeres de base de datos de Aurora
MySQL (p. 501).
3. Ejecute el procedimiento almacenado mysql.rds_import_binlog_ssl_material
para importar la información de SSL en el clúster de base de datos Aurora MySQL.
Para el parámetro ssl_material_value, inserte la información de los archivos

con formato .pem para el clúster de base de datos Aurora MySQL en la carga JSON
correcta.
En el siguiente ejemplo se importa la información de SSL en un clúster de base de

datos Aurora MySQL. En los archivos con formato .pem, el código del cuerpo suele ser
más grande que el que se muestra en el ejemplo.
call mysql.rds_import_binlog_ssl_material(
'{"ssl_ca":"-----BEGIN CERTIFICATE-----
hz2ItxCih+PnDSUaw+WNQn/mZphTk/a/gU8jEzoOWbkM4yxyb/wB96xbiFveSFJuOp/
d6RJhJOI0iBXr
lsLnBItntckiJ7FbtxJMXLvvwJryDUilBMTjYtwB+QhYXUMOzce5Pjz5/i8SeJtjnV3iAoG/
cQk+0FzZ
qaeJAAHco+CY/5WrUBkrHmFJr6HcXkvJdWPkYQS3xqC0+FmUZofz221CBt5IMucxXPkX4rWi
+z7wB3Rb
-----END CERTIFICATE-----\n","ssl_cert":"-----BEGIN CERTIFICATE-----
d6RJhJOI0iBXr
cQk+0FzZ
+z7wB3Rb
-----END CERTIFICATE-----\n","ssl_key":"-----BEGIN RSA PRIVATE KEY-----

613
base de
datos
d6RJhJOI0iBXr
cQk+0FzZ
+z7wB3Rb
-----END RSA PRIVATE KEY-----\n"}');
Para obtener más información, consulte mysql_rds_import_binlog_ssl_material y Uso

de SSL con clústeres de base de datos de Aurora MySQL (p. 501).
Note
Después de ejecutar el procedimiento, los secretos se almacenan en

archivos. Para borrar los archivos más tarde, puede ejecutar el procedimiento
almacenado mysql_rds_remove_binlog_ssl_material.
Para habilitar el registro binario en una base de datos MySQL externa
1. En un shell de comando, detenga el servicio mysql.
sudo service mysqld stop
2. Edite el archivo my.cnf (este archivo se encuentra normalmente en /etc).
sudo vi /etc/my.cnf
Añada las opciones log_bin y server_id a la sección [mysqld]. La opción

log_bin proporciona un identificador de nombre de archivo para los archivos de log
binarios. La opción server_id proporciona un identificador único para el servidor en las
relaciones maestro-réplica.
Si no se requiere la replicación cifrada, asegúrese de que la base de datos MySQL

externa se inicia con los binlogs habilitados y SSL deshabilitado.
A continuación se indican las entradas pertinentes en el archivo /etc/my.cnf para los

datos sin cifrar.
log-bin=mysql-bin
server-id=2133421
sync_binlog=1
Si se requiere la replicación cifrada, asegúrese de que la base de datos MySQL externa

se inicia con SSL y los binlogs habilitados.
Las entradas del archivo /etc/my.cnf incluyen las ubicaciones del archivo .pem para el
servidor de base de datos MySQL.

614
base de
datos
log-bin=mysql-bin
server-id=2133421
sync_binlog=1
# Setup SSL.
ssl-ca=/home/sslcerts/ca.pem
ssl-cert=/home/sslcerts/server-cert.pem
ssl-key=/home/sslcerts/server-key.pem
Además, la opción sql_mode de la instancia de base de datos MySQL debe estar

definida como 0 o no se debe incluir en el archivo my.cnf.
Mientras está conectado a la base de datos MySQL externa, registre la posición del log
binario de la base de datos MySQL externa.
mysql> SHOW MASTER STATUS;
El resultado debería ser similar al siguiente:
+------------------+----------+--------------+------------------
+-------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |
Executed_Gtid_Set |
+------------------+----------+--------------+------------------
+-------------------+
| mysql-bin.000031 | 107 | | |
|
+------------------+----------+--------------+------------------
+-------------------+
1 row in set (0.00 sec)
Para obtener más información, consulte Setting the Replication Master Configuration en
la documentación de MySQL.
3. Inicie el servicio mysql.
sudo service mysqld start
2. Conserve los registros binarios en el maestro de replicación hasta que dejen de

ser necesarios
Cuando se utiliza la replicación de binlog de MySQL, Amazon RDS no administra el proceso de replicación.
Como resultado, debe asegurarse de que los archivos binlog del maestro de replicación se conservan
hasta que los cambios se hayan aplicado a la réplica. Este mantenimiento ayuda a garantizar que se
puede restaurar la base de datos maestra si se produce un error.
Puede encontrar instrucciones acerca del procedimiento para conservar logs binario para el motor de base
de datos a continuación.

615
base de
datos
Aurora Para conservar registros binarios en un clúster de base de datos Aurora MySQL
No tiene acceso a los archivos binlog de un clúster de base de datos Aurora MySQL.
Como resultado, debe elegir un plazo para conservar los archivos binlog en el maestro
de replicación que sea lo suficientemente largo para garantizar que los cambios se han
aplicado a la réplica antes de que Amazon RDS elimine el archivo binlog. Puede conservar
los archivos binlog en un clúster de base de datos Aurora MySQL durante un máximo de 90
días.
Si desea configurar una replicación con una base de datos de MySQL o una instancia de
base de datos de RDS MySQL como réplica y la base de datos para la que va a crear una
réplica es muy grande, elija un plazo más largo para conservar los archivos binlog hasta
que la copia inicial de la base de datos en la réplica se haya completado y el retardo de la
réplica haya llegado a 0.
Para definir el marco de tiempo de retención de binlog, utilice el procedimiento

mysql_rds_set_configuration y especifique un parámetro de configuración de 'binlog
retention hours' junto con el número de horas para retener los archivos binlog en el
clúster de base de datos, hasta un máximo de 2160 (90 días). El ejemplo siguiente define el
periodo de retención de los archivos binlog en 6 días:
CALL mysql.rds_set_configuration('binlog retention hours', 144);
Una vez iniciada la replicación, puede confirmar que los cambios se han aplicado a la
réplica ejecutando el comando SHOW SLAVE STATUS en la réplica y comprobando el
campo Seconds behind master (Segundos detrás del maestro). Si el campo Seconds
behind master (Segundos detrás del maestro) es 0, no hay retardo de réplica. Cuando no
haya retardo de réplica, reduzca el periodo de tiempo durante el que se deben retener los
archivos binlog definiendo el parámetro de configuración binlog retention hours en
un periodo más corto.
Si no especifica un valor para 'binlog retention hours' que sea mayor de 2160,
entonces se utiliza 2160.
RDS Para conservar los registros binarios en una instancia de base de datos de Amazon RDS
MySQL
Puede conservar los archivos binlog en una instancia de base de datos de Amazon RDS
mediante la definición de las horas de retención de archivos binlog, como en el caso de un
clúster de base de datos Aurora MySQL, tal como se ha descrito en la sección anterior.
También puede retener los archivos binlog en una instancia de base de datos de Amazon
RDS creando una réplica de lectura para la instancia de base de datos. Esta réplica de
lectura es temporal y solo se usa para conservar los archivos binlog. Una vez que se haya
creado la réplica de lectura, llame al procedimiento mysql_rds_stop_replication en la réplica
de lectura (el procedimiento mysql.rds_stop_replication solo está disponible para
las versiones 5.5, 5.6 y posteriores, y 5.7 y posteriores de MySQL). Mientras la replicación
está detenida, Amazon RDS no elimina ninguno de los archivos binlog del maestro de
replicación. Una vez que haya configurado la replicación con la réplica permanente, podrá
eliminar la réplica de lectura cuando el retardo de la réplica (campo Seconds behind master
(Segundos detrás del maestro)) entre el maestro de replicación y la réplica permanente
llegue a 0.

616
base de
datos
MySQL Para conservar los registros binarios en una base de datos MySQL externa
(externo)
Como los archivos binlog de una base de datos de MySQL externa no se administran con
Amazon RDS, se conservan hasta que se eliminan.
Una vez iniciada la replicación, puede confirmar que los cambios se han aplicado a la
réplica ejecutando el comando SHOW SLAVE STATUS en la réplica y comprobando el
campo Seconds behind master (Segundos detrás del maestro). Si el campo Seconds
behind master (Segundos detrás del maestro) es 0, no hay retardo de réplica. Cuando no
haya retardo de réplica, podrá eliminar los archivos binlog antiguos.
3. Cree una instantánea del maestro de replicación

Debe usar un snapshot del maestro de replicación para cargar una copia de línea de base de los datos en
la réplica y comenzar después a replicar desde ese punto.
Puede encontrar instrucciones acerca del procedimiento para crear un snapshot del maestro de replicación
de su motor de base de datos a continuación.
base de
datos
Aurora Para crear una instantánea de un clúster de base de datos Aurora MySQL
1. Cree un snapshot de clúster de base de datos de su clúster de base de datos de

Amazon Aurora. Para obtener más información, consulte Creación de una instantánea
2. Cree un nuevo clúster de base de datos de Aurora restaurando a partir del snapshot
de clúster de base de datos que acaba de crear. Asegúrese de conservar el mismo
grupo de parámetros de base de datos para el clúster de base de datos restaurado
que en el clúster de base de datos original. De este modo, se asegurará de que la
copia de su clúster de base de datos tiene el registro binario habilitado. Para obtener
más información, consulte Restauración de una instantánea de clúster de base de
datos (p. 319).
3. En la consola, elija Databases (Bases de datos) y elija la instancia principal (escritor) del
clúster de base de datos de Aurora restaurado para mostrar sus detalles. Desplácese
hasta Recent Events (Eventos recientes). Aparecerá un mensaje de evento que muestra
el nombre y la posición del archivo binlog. El mensaje de evento está en el siguiente
formato.
Binlog position from crash recovery is binlog-file-name binlog-position
Guarde los valores de nombre y posición del archivo binlog para cuando comience la
replicación.
También puede obtener el nombre y la posición del archivo binlog llamando al comando
describe-events desde la AWS CLI. A continuación se muestra un comando describe-
events de ejemplo con una salida de muestra.
PROMPT> aws rds describe-events

617
base de
datos
{
"Events": [
{
"EventCategories": [],
"SourceType": "db-instance",
"SourceArn": "arn:aws:rds:us-west-2:123456789012:db:sample-
restored-instance",
"Date": "2016-10-28T19:43:46.862Z",
"Message": "Binlog position from crash recovery is mysql-bin-
changelog.000003 4278",
"SourceIdentifier": "sample-restored-instance"
}
]
}
También puede obtener el nombre de archivo y la posición de binlog comprobando

el registro de errores de MySQL para obtener la última posición del archivo binlog de
MySQL o la entrada DB_CRASH_RECOVERY_BINLOG_POSITION.
4. Si el destino de réplica es un clúster de base de datos Aurora perteneciente a otra
cuenta de AWS, una base de datos MySQL externa o una instancia de base de datos
de RDS MySQL, no podrá cargar los datos desde una instantánea de clúster de base
de datos Amazon Aurora. En lugar de ello, cree un volcado del clúster de base de datos
Amazon Aurora conectándose a su clúster de base de datos con un cliente MySQL y
ejecutando el comando mysqldump. Recuerde ejecutar el comando mysqldump en la
copia del clúster de base de datos de Amazon Aurora que ha creado. A continuación se
muestra un ejemplo.
PROMPT> mysqldump --databases <database_name> --single-transaction

--order-by-primary -r backup.sql -u <local_user> -p
5. Cuando haya terminado de crear el volcado de los datos desde el clúster de base de
datos de Aurora que se acaba de crear, elimine ese clúster de base de datos, que ya no
se necesita.
RDS Para crear una instantánea de una instancia de la base de datos de Amazon RDS
MySQL
1. Cree una réplica de lectura para la instancia de base de datos de Amazon RDS. Para
obtener más información sobre cómo crear una réplica de lectura, consulte Creación de
una réplica de lectura en la Guía del usuario de Amazon Relational Database Service.
2. Conéctese a la réplica de lectura y detenga la replicación ejecutando el procedimiento
mysql_rds_stop_replication.
3. Mientras la réplica de lectura está en el estado Stopped (Detenido), conéctese a la
réplica de lectura y ejecute el comando SHOW SLAVE STATUS. Obtenga el nombre del
archivo de log binario actual del campo Relay_Master_Log_File y la posición del
archivo de log del campo Exec_Master_Log_Pos. Guarde estos valores para cuando
comience la replicación.
4. Con la réplica de lectura en el estado Stopped (Detenido), cree una instantánea de base
de datos la réplica de lectura. Para obtener más información acerca de la creación de
una instantánea de base de datos, consulte Creación de una instantánea de clúster de
5. Elimine la réplica de lectura.

618
base de
datos
MySQL Para crear una instantánea de una base de datos MySQL externa
(externo)
1. Antes de crear un snapshot, debe asegurarse de que la ubicación del binlog del
snapshot está actualizada con respecto a los datos de la instancia maestra. Para ello,
debe detener primero las operaciones de escritura en la instancia con el siguiente
comando:
mysql> FLUSH TABLES WITH READ LOCK;
2. Cree un volcado de su base de datos de MySQL con el comando mysqldump, como se

muestra a continuación:
PROMPT> sudo mysqldump --databases <database_name> --master-data=2 --

single-transaction \
--order-by-primary -r backup.sql -u <local_user> -p
3. Una vez que haya creado el snapshot, desbloquee las tablas de su base de datos de
MySQL con el siguiente comando:
mysql> UNLOCK TABLES;
4. Cargue la instantánea en el destino de la réplica

Si va a cargar datos desde un volcado de una base de datos MySQL que sea externa a Amazon RDS,
puede crear una instancia EC2 para copiar en ella los archivos del volcado y cargar a continuación los
datos en el clúster de base de datos o la instancia de base de datos desde esa instancia EC2. Con este
método, puede comprimir los archivos de volcado antes de copiarlos en la instancia EC2 con el fin de
reducir los costos de la red asociados con la copia de datos en Amazon RDS. También puede cifrar el
archivo o los archivos de volcado para proteger los datos mientras se transfieren por la red.
Puede encontrar instrucciones acerca del procedimiento para cargar la instantánea del maestro de
replicación en el destino de la réplica para su motor de base de datos a continuación.
base de
datos
Aurora Para cargar una instantánea en un clúster de base de datos Aurora MySQL
• Si la instantánea del maestro de replicación es una instantánea de clúster de base de

datos, puede restaurar a partir de la instantánea del clúster de base de datos para crear
un nuevo clúster de base de datos Aurora MySQL como destino de la réplica. Para
obtener más información, consulte Restauración de una instantánea de clúster de base
de datos (p. 319).
• Si la instantánea del maestro de replicación es una instantánea de base de datos, puede
migrar los datos de la instantánea de base de datos a un nuevo clúster de base de datos
Aurora MySQL. Para obtener más información, consulte Migración de datos a un clúster
de base de datos Amazon Aurora (p. 154).

619
base de
datos
• Si la instantánea del maestro de replicación es el resultado del comando mysqldump,
siga estos pasos:
1. Copie el resultado del comando mysqldump del maestro de replicación en una
ubicación que también pueda conectarse al clúster de base de datos Aurora MySQL.
2. Conéctese al clúster de base de datos Aurora MySQL mediante el comando mysql. A
continuación se muestra un ejemplo.
PROMPT> mysql -h <host_name> -port=3306 -u <db_master_user> -p
3. En el símbolo del sistema mysql, ejecute el comando source y pásele el nombre del
archivo de volcado de la base de datos para cargar los datos en el clúster de base de
datos Aurora MySQL, por ejemplo:
mysql> source backup.sql;
RDS Para cargar una instantánea en una instancia de base de datos de Amazon RDS
MySQL
1. Copie el resultado del comando mysqldump del maestro de replicación en una ubicación
que también pueda conectarse a su instancia de base de datos MySQL.
2. Conéctese a la instancia de base de datos MySQL usando el comando mysql. A
3. En el símbolo del sistema mysql, ejecute el comando source y pásele el nombre del
archivo de volcado de la base de datos para cargar los datos en la instancia de base de
datos MySQL, por ejemplo:
MySQL Para cargar una instantánea en una base de datos MySQL externa
(externo)
No puede cargar un snapshot de base de datos o un snapshot de clúster de base de datos
en una base de datos de MySQL externa. En su lugar, debe usar la salida del comando
mysqldump.
1. Copie la salida del comando mysqldump del maestro de replicación en una ubicación
que también pueda conectarse a su base de datos MySQL.
2. Conéctese a la base de datos de MySQL usando el comando mysql. A continuación se
muestra un ejemplo.
3. En el símbolo del sistema mysql, ejecute el comando source y pásele el nombre

del archivo de volcado de la base de datos para cargar los datos en la base de datos
MySQL. A continuación se muestra un ejemplo.

620
5. Habilite la replicación en el destino de la réplica

Antes de habilitar la replicación, se recomienda que realice una instantánea manual del clúster de base de
datos Aurora MySQL o del destino de la réplica de la instancia de base de datos MySQL en RDS. Si surge
un problema y tiene que restablecer la replicación con el clúster de base de datos o el destino de la réplica
de instancia de base de datos, puede restaurar el clúster de base de datos o la instancia de base de datos
desde esta instantánea en lugar de tener que volver a importar los datos en el destino de la réplica.
Además, cree un ID de usuario que solo se utilice para la replicación. A continuación se muestra un
ejemplo.
mysql> CREATE USER 'repl_user'@'<domain_name>' IDENTIFIED BY '<password>';
El usuario requiere los privilegios REPLICATION CLIENT y REPLICATION SLAVE. Conceda estos
privilegios al usuario.
GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'<domain_name>';
Si necesita usar la replicación cifrada, exija conexiones SSL al usuario de la replicación. Por ejemplo,
puede utilizar la siguiente instrucción para exigir el uso de conexiones SSL en la cuenta de usuario
repl_user.
GRANT USAGE ON *.* TO 'repl_user'@'<domain_name>' REQUIRE SSL;
Note
Si REQUIRE SSL no se incluye, la conexión de replicación podría cambiarse inadvertidamente por

una conexión sin cifrar.
Puede encontrar instrucciones acerca del procedimiento para habilitar la replicación para su motor de base
de datos a continuación.
base de
datos
Aurora Para habilitar la replicación desde un clúster de base de datos Aurora MySQL
1. Si el destino de la réplica del clúster de base de datos se creó a partir de una

instantánea de clúster de base de datos, conéctese al destino de la réplica del clúster
de base de datos y ejecute el comando SHOW MASTER STATUS. Obtenga el nombre del
archivo de log binario actual del campo File y la posición del archivo de log del campo
Position.
Si el destino de la réplica del clúster de base de datos se creó a partir de una

instantánea, necesitará el archivo binlog y la posición del binlog que son el punto de
partida para la replicación. Obtuvo esos valores del comando SHOW SLAVE STATUS
cuando creó el snapshot de su maestro de replicación.
2. Conéctese al clúster de base de datos y ejecute los procedimientos
mysql_rds_set_external_master y mysql_rds_start_replication para comenzar la
replicación con el maestro de replicación usando el nombre y la ubicación del archivo de
registro binario del paso anterior. A continuación se muestra un ejemplo.

621
base de
datos
CALL mysql.rds_set_external_master ('mydbinstance.123456789012.us-

east-1.rds.amazonaws.com', 3306,
'repl_user', '<password>', 'mysql-bin-changelog.000031', 107, 0);

RDS Para habilitar la replicación desde una instancia de base de datos de Amazon RDS
MySQL
1. Si el destino de la réplica de la instancia de base de datos se creó a partir de una
instantánea, necesitará el archivo binlog y la posición del binlog que son el punto de
partida para la replicación. Obtuvo esos valores del comando SHOW SLAVE STATUS
cuando creó el snapshot de su maestro de replicación.
2. Conéctese a la instancia de base de datos y ejecute los procedimientos
mysql_rds_set_external_master y mysql_rds_start_replication para comenzar la
replicación con el maestro de replicación usando el nombre y la ubicación del archivo de
registro binario del paso anterior. A continuación se muestra un ejemplo.
CALL mysql.rds_set_external_master ('mydbcluster.cluster-123456789012.us-

east-1.rds.amazonaws.com', 3306,
MySQL Para habilitar la replicación desde una base de datos MySQL externa
(externo)
1. Obtenga el archivo binlog y la posición del binlog que son el punto de partida para la
replicación. Obtuvo esos valores del comando SHOW SLAVE STATUS cuando creó el
snapshot de su maestro de replicación. Si el destino de la réplica de MySQL externa se
rellenó desde la salida del comando mysqldump con la opción --master-data=2, el
archivo binlog y la posición del binlog se incluirán en la salida. A continuación se muestra
un ejemplo.
--
-- Position to start replication or point-in-time recovery from
--
-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin-changelog.000031',

MASTER_LOG_POS=107;
2. Conéctese al destino de la réplica MySQL externa y ejecute los comandos CHANGE

MASTER TO y START SLAVE para comenzar la replicación con el maestro de replicación
usando el nombre y la ubicación del archivo de log binario del paso anterior, por ejemplo:
CHANGE MASTER TO
MASTER_HOST = 'mydbcluster.cluster-123456789012.us-
east-1.rds.amazonaws.com',
MASTER_PORT = 3306,
MASTER_USER = 'repl_user',
MASTER_PASSWORD = '<password>',
MASTER_LOG_FILE = 'mysql-bin-changelog.000031',
MASTER_LOG_POS = 107;
START SLAVE;

622
6. Monitorice su réplica
Al configurar una replicación de MySQL con un clúster de base de datos Aurora MySQL, debe monitorizar
los eventos de conmutación por error para el clúster de base de datos Aurora MySQL cuando se trate
del destino de la réplica. Si se produce una conmutación por error, el clúster de base de datos que es el
destino de la réplica se podrá volver a crear en un nuevo host con una dirección de red diferente. Para
obtener información acerca de la monitorización de los eventos de conmutación por error, consulte Uso de
las notificaciones de eventos de Amazon RDS (p. 465).
También puede monitorizar el retardo existente entre el maestro de replicación y el destino de la réplica
conectándose al destino de la réplica y ejecutando el comando SHOW SLAVE STATUS. En la salida del
comando, el campo Seconds Behind Master indica cuánto retardo tiene el destino de la réplica con
respecto al maestro.
Detener la replicación entre Aurora y MySQL o entre Aurora y

otro clúster de base de datos de Aurora
Para detener la replicación de binlog con una instancia de base de datos MySQL, una base de datos de
MySQL externa u otro clúster de base de datos de Aurora, siga estos pasos, que se describen en detalle
en este tema.
1. Detenga la replicación de binlog en el destino de la réplica (p. 623)
2. Deshabilite el registro binario en el maestro de replicación (p. 623)
1. Detenga la replicación de binlog en el destino de la réplica

Puede encontrar instrucciones acerca del procedimiento para detener la replicación del binlog para su
motor de base de datos a continuación.
base de
datos
Aurora Para detener la replicación del binlog en el destino de la réplica de un clúster de base de
datos Aurora MySQL
Conéctese al clúster de base de datos de Aurora que es el destino de la

réplica y llame al procedimiento mysql_rds_stop_replication. El procedimiento
mysql.rds_stop_replication solo está disponible para las versiones de MySQL 5.5 y
posteriores, 5.6 y posteriores, y 5.7 y posteriores.
RDS Para detener la replicación de binlog en una instancia de base de datos de Amazon RDS
MySQL
Conéctese a la instancia de base de datos de RDS que es el destino de la
réplica y llame al procedimiento mysql_rds_stop_replication. El procedimiento
mysql.rds_stop_replication solo está disponible para las versiones de MySQL 5.5 y
posteriores, 5.6 y posteriores, y 5.7 y posteriores.
MySQL Para detener la replicación de binlog en una base de datos MySQL externa
(externo)
Conéctese a la base de datos de MySQL y llame al comando STOP REPLICATION.
2. Deshabilite el registro binario en el maestro de replicación

Puede encontrar instrucciones acerca del procedimiento para deshabilitar el registro binario en el maestro
de replicación de su motor de base de datos a continuación.

623
base de
datos
Aurora Para deshabilitar el registro binario en un clúster de base de datos Amazon Aurora
1. Conéctese al clúster de base de datos Aurora que es el maestro de replicación y

establezca el periodo de tiempo de retención de binlog en 0. Para definir el periodo de
retención de binlog, use el procedimiento mysql_rds_set_configuration y especifique un
parámetro de configuración de binlog retention hours junto con el número de
horas que se deben conservar los archivos binlog en el clúster de base de datos, en este
caso 0, como se muestra en el siguiente ejemplo.
2. Establezca el parámetro binlog_format en OFF en el maestro de replicación. El

parámetro binlog_format es un parámetro de nivel de clúster que se encuentra en el
grupo de parámetros de clúster predeterminado.
Una vez que haya cambiado el valor del parámetro binlog_format, reinicie su clúster
de base de datos para que el cambio tenga efecto.
Para obtener más información, consulte Parámetros del clúster de base de datos y la
instancia de base de datos Amazon Aurora (p. 261) y Modificación de parámetros de un
grupo de parámetros de base de datos (p. 265).
RDS Para deshabilitar el registro binario en una instancia de base de datos de Amazon RDS
MySQL
No puede deshabilitar el registro binario directamente para una instancia de base de
datos de Amazon RDS, pero puede deshabilitarlo por medio de uno de los siguientes
procedimientos:
1. Deshabilite los backups automatizados para la instancia de base de datos. Puede

deshabilitar copias de seguridad automatizadas modificando una instancia de base
de datos ya existente y definiendo el valor de Backup Retention Period (Periodo de
retención de copia de seguridad) como 0. Para obtener más información, consulte
Modificación de una instancia de base de datos que ejecuta el motor de base de datos
MySQL y Trabajo con copias de seguridad en la Guía del usuario de Amazon Relational
Database Service.
2. Elimine todas las réplicas de lectura para la instancia de base de datos. Para obtener
más información, consulte Trabajo con réplicas de lectura de instancias de base de
datos MariaDB, MySQL y PostgreSQL en la Guía del usuario de Amazon Relational
Database Service.
MySQL Para deshabilitar el registro binario en una base de datos MySQL externa
(externo)
Conéctese a la base de datos de MySQL y llame al comando STOP REPLICATION.
1. En un shell de comando, detenga el servicio mysql,
sudo service mysqld stop
2. Edite el archivo my.cnf (este archivo se encuentra normalmente en /etc).
sudo vi /etc/my.cnf
Elimine las opciones log_bin y server_id de la sección [mysqld].

624
Uso de la replicación basada en GTID
base de
datos
Para obtener más información, consulte Setting the Replication Master Configuration en
3. Inicie el servicio mysql.
sudo service mysqld start
Uso de replicación basada en GTID para Aurora

MySQL
A continuación, puede conocer cómo utilizar los identificadores de transacciones globales (GTID con
replicación de registro binario (binlog)) entre un clúster de Aurora MySQL y un origen externo.
Note
Para Aurora, puede usar solo esta característica con clústeres de Aurora MySQL que usan la
replicación del binlog en una base de datos de MySQL externa o desde ella. La otra base de
datos puede ser una instancia de Amazon RDS MySQL, una base de datos de MySQL local o un
clúster de base de datos de Aurora en una región de AWS diferente. Para obtener información
sobre cómo configurar ese tipo de replicación, consulte Replicación entre Aurora y MySQL o entre
Aurora y otro clúster de base de datos Aurora (p. 610).
Si utiliza la replicación del binlog y no está familiarizado con la replicación basada en GTID con MySQL,
consulte Replication with Global Transaction Identifiers (Replicación con identificadores de transacciones
globales) en la documentación de MySQL para obtener información.
Note
La replicación basada en GTID es compatible con los clústeres compatibles con MySQL 5.7
en Aurora MySQL, versión 2.04 y versiones posteriores. La replicación basada en GTID no es
compatible con clústeres compatibles con MySQL 5.6 en Aurora MySQL, versión 1.
Temas
• Información general de identificadores de transacciones globales (GTID) (p. 625)
• Parámetros de replicación basada en GTID (p. 626)
• Configuración de la replicación basada en GTID para un clúster de Aurora MySQL (p. 627)
• Deshabilitación de replicación basada en GTID para un clúster de base de datos de Aurora
MySQL (p. 627)
Información general de identificadores de transacciones globales

(GTID)
Los identificadores de transacciones globales (GTID) son indentificadores únicos generados por
transacciones confirmadas por MySQL. Puede utilizar GTID para que la replicación del binlog sea más
simple y sencilla para la solución de problemas.
Note
Cuando Aurora sincroniza datos entre las instancias de base de datos en un clúster, ese
mecanismo de replicación no incluye el registro binario (binlog). Para Aurora MySQL, la

625
replicación basada de GTID solo se aplica cuando también utiliza la replicación del binlog para
realizar la replicación dentro o fuera de un clúster de base de datos de Aurora MySQL a partir de
una base de datos compatible con MySQL externa.
MySQL usa dos tipos distintos de transacciones para la replicación del binlog:
• Transacciones de GTID: transacciones que se identifican mediante GTID.

• Transacciones anónimas: transacciones que no tienen un GTID asignado.
En una configuración de replicación, los GTID son únicos en todas las instancias de base de datos. Los
GTID simplifican la configuración de replicación porque cuando se usan no es necesario hacer referencia a
las posiciones de los archivos de registro. Los GTID también facilitan el seguimiento de las transacciones
replicadas y determinan si los maestros y las réplicas son uniformes.
Normalmente utiliza la replicación basada en GTID con Aurora cuando efectúa la replicación desde
una base de datos compatible con MySQL externa en un clúster de Aurora. Puede configurar esta
configuración de replicación como parte de una migración desde una base de datos de Amazon RDS o
local en Aurora MySQL. Si la base de datos externa ya utiliza GTID, habilitar la replicación basada en GTID
para el clúster de Aurora simplifica el proceso de replicación.
Configure la replicación basada en GTID para un clúster de Aurora MySQL configurando primero los
parámetros de configuración relevantes en un grupo de parámetros de clúster de base de datos. A
continuación, asocie ese grupo de parámetros al clúster.
Parámetros de replicación basada en GTID

Use los parámetros siguientes para configurar replicación basada en GTID.
Parámetro Valores válidos Descripción
gtid_mode OFF, OFF_PERMISSIVE, OFF especifica que las nuevas transacciones son
ON_PERMISSIVE, ON anónimas (es decir, no tienen GTID) y que una
transacción debe ser anónima para replicarse.
OFF_PERMISSIVE especifica que las nuevas

transacciones son anónimas, pero que todas las
transacciones pueden replicarse.
ON_PERMISSIVE especifica que las nuevas

transacciones son de GTID, pero que todas las
transacciones pueden replicarse.
ON especifica que las nuevas transacciones son de

GTID y que una transacción debe ser de GTID para
poder replicarse.
enforce_gtid_consistency
OFF, ON, WARN OFF permite que las transacciones infrinjan la
uniformidad de GTID.
ON evita que las transacciones infrinjan la

uniformidad de GTID.
WARN permite que las transacciones infrinjan la

uniformidad de GTID, pero genera un aviso cuando
se proudce una infracción.

626
Para la replicación basada en GTID, utilice esta configuración para el grupo de parámetros de clúster de
base de datos para el clúster de base de datos de Aurora MySQL:
• ON y ON_PERMISSIVE se aplican solo a la replicación saliente de una instancia de base de datos de

RDS o un clúster de Aurora MySQL. Estos valores provocan que su instancia de base de datos de RDS
o el clúster de base de datos de Aurora utilicen GTID para transacciones que se replican en una base de
datos externa. ON requiere que la base de datos externa también utilice la replicación basada en GTID.
ON_PERMISSIVE hace que la replicación basada en GTID sea opcional en la base de datos externa.
• Si se establece OFF_PERMISSIVE, significa que sus instancias de base de datos de RDS o clúster de
base de datos de Aurora pueden aceptar la replicación entrante de una base de datos externa. Se puede
aplicar este procedimiento si la base de datos tanto si la base de datos utiliza la replicación basada en
GTID como si no.
• Si se establece OFF, significa que sus instancias de base de datos de RDS o clúster de base de
datos de Aurora solo aceptan la replicación entrante desde bases de datos externas que no utilizan la
replicación basada en GTID.
Tip
La replicación entrante es el escenario de replicación del binlog más frecuente para los clústeres
de Aurora MySQL. Para la replicación entrante, recomendamos que establezca el modo de GTID
en OFF_PERMISSIVE. Esta configuración permite la replicación entrante desde bases de datos
externas independientemente de la configuración de GTID en el origen de replicación.
Note
En la Consola de administración de AWS, el parámetro gtid_mode aparece como gtid-mode.
Configuración de la replicación basada en GTID para un clúster

de Aurora MySQL
Cuando la replicación basada en GTID está habilitada para un clúster de base de datos de Aurora MySQL,
la configuración de GTID se aplica a la replicación del binlog entrante y saliente.
Para habilitar la replicación basada en GTID para un clúster de Aurora MySQL, realice el siguiente
procedimiento:
1. Cree o edite un grupo de parámetros del clúster de base de datos con la siguiente configuración de
parámetros:
• gtid_mode – ON o ON_PERMISSIVE
• enforce_gtid_consistency – ON
2. Asocie el grupo de parámetros del clúster de base de datos con el clúster de Aurora MySQL. Para
ello, siga los procedimientos en Trabajo con los grupos de parámetros de base de datos y grupos de
Deshabilitación de replicación basada en GTID para un clúster de

base de datos de Aurora MySQL
Puede deshabilitar la replicación basada en GTID para un clúster de base de datos de Aurora MySQL. Si
realiza esta acción, significa que el clúster de Aurora no puede realizar la replicación del binlog interna o
externa con bases de datos externas que utilizan la replicación basada en GTID.

627
Note
En el siguiente procedimiento, réplica de lectura hace referencia al destino de replicación en una

configuración de Aurora con la replicación del binlog en una base de datos externa o desde ella.
No hace referencia a las instancias de base de datos de réplica de Aurora de solo lectura. Por
ejemplo, cuando un clúster de Aurora acepta la replicación entrante desde una fuente externa, la
instancia principal de Aurora funciona como la réplica de lectura para la replicación del binlog.
Para obtener más información sobre los procedimientos almacenados mencionados en esta sección,
consulte Procedimientos almacenados de Aurora MySQL (p. 692).
Para deshabilitar la replicación basada en GTID para un clúster de base de datos de Aurora
MySQL , realice el siguiente procedimiento:
1. En la instancia principal de Aurora, ejecute el siguiente procedimiento.
CALL mysql.rds_set_master_auto_position(0);
2. Restablezca gtid_mode en ON_PERMISSIVE .
a. Asegúrese de que el grupo de parámetros de clúster de base de datos asociado al clúster de

Aurora MySQL disponga de gtid_mode establecido en ON_PERMISSIVE.
Para obtener más información sobre el establecimiento de parámetros de configuración con

grupos de consultas, consulte Trabajo con los grupos de parámetros de base de datos y grupos
de parámetros de clúster de base de datos (p. 259).
b. Reinicie el clúster de base de datos de Aurora MySQL.
3. Restablezca gtid_mode en OFF_PERMISSIVE :
a. Asegúrese de que el grupo de parámetros de clúster de base de datos asociado al clúster de

Aurora MySQL disponga de gtid_mode establecido en OFF_PERMISSIVE.
4. a. En la instancia principal de Aurora de base de datos de , ejecute el comando SHOW MASTER
STATUS.
El resultado debería ser similar al siguiente.
File Position
------------------------------------
mysql-bin-changelog.000031 107
------------------------------------
Tenga en cuenta el archivo y la posición en su resultado.

b. En cada réplica de lectura, use la información de archivo y posición de su maestro en el paso
anterior para ejecutar la siguiente consulta.
SELECT MASTER_POS_WAIT(file, position);
Por ejemplo, si el nombre del archivo es mysql-bin-changelog.000031 y la posición es 107,

ejecute la siguiente instrucción.
SELECT MASTER_POS_WAIT(mysql-bin-changelog.000031, 107);

628
Integración de Aurora MySQL con los servicios de AWS
Si la réplica de lectura está después de la posición especificada, la consulta vuelve

inmediatamente. De no hacerlo, la función espera. Diríjase al siguiente paso cuando la consulta
devuelva todas las réplicas de lectura.
5. Restablezca los parámetros de GTID para deshabilitar la replicación basada en GTID:
a. Asegúrese de que el grupo de parámetros del clúster de base de datos asociado al clúster de
Aurora MySQL tenga la siguiente configuración de parámetros:
• gtid_mode – OFF
• enforce_gtid_consistency – OFF
Integración de Amazon Aurora MySQL con otros

servicios de AWS
Amazon Aurora MySQL se integra con otros servicios de AWS con el fin de permitirle ampliar su clúster de
base de datos Aurora MySQL para usar funcionalidades adicionales en la nube de AWS. El clúster de base
de datos de Aurora MySQL puede usar los servicios de AWS para hacer lo siguiente:
lambda_sync o lambda_async. Para obtener más información, consulte Invocación de una función de
Lambda con una función nativa de Aurora MySQL (p. 656).
• Cargar datos desde archivos de texto o XML almacenados en un bucket de Amazon Simple Storage
Service (Amazon S3) en el clúster de base de datos usando el comando LOAD DATA FROM S3 o LOAD
XML FROM S3. Para obtener más información, consulte Carga de datos en un clúster de base de datos
Amazon Aurora MySQL desde archivos de texto en un bucket de Amazon S3 (p. 641).
• Guardar datos en archivos de texto almacenados en un bucket de Amazon S3 desde su clúster de base
de datos usando el comando SELECT INTO OUTFILE S3. Para obtener más información, consulte
Grabación de datos desde un clúster de base de datos Amazon Aurora MySQL en archivos de texto de
Aurora protege la capacidad de obtener acceso a otros servicios de AWS por medio de AWS Identity
and Access Management (IAM). Puede conceder permiso para obtener acceso a otros servicios de
AWS mediante la creación de un rol de IAM con los permisos necesarios y la asociación del rol con el
clúster de base de datos. Para obtener detalles e instrucciones acerca del procedimiento para permitir
que un clúster de base de datos Aurora MySQL obtenga acceso a otros servicios de AWS en su nombre,
consulte Autorización a Amazon Aurora MySQL a obtener acceso a otros servicios de AWS en su
nombre (p. 629).
Autorización a Amazon Aurora MySQL a obtener

acceso a otros servicios de AWS en su nombre
Note
La integración con otros servicios de AWS está disponible para la versión 1.8 y posteriores
de Amazon Aurora MySQL. Algunas características de integración solo están disponibles
para versiones posteriores de Aurora MySQL. Para obtener más información acerca de las
versiones de Aurora, consulte Actualizaciones del motor de base de datos para Amazon Aurora
MySQL (p. 695).

629
Autorización a Aurora MySQL a obtener
acceso a otros servicios de AWS
Para que un clúster de base de datos Aurora MySQL pueda tener acceso a otros servicios en su nombre,
cree y configure un rol de AWS Identity and Access Management (IAM). Este rol autoriza a los usuarios de
las bases de datos del clúster de base de datos a tener acceso a otros servicios AWS. Para obtener más
información, consulte Configuración de roles de IAM para acceder a servicios de AWS (p. 630).
También debe configurar el clúster de base de datos de Aurora para permitir conexiones salientes hacia el
servicio AWS de destino. Para obtener más información, consulte Habilitación de la comunicación de red
de Amazon Aurora MySQL con otros servicios de AWS (p. 640).
Al hacerlo, los usuarios de base de datos podrán ejecutar las acciones siguientes con otros servicios de
AWS:
lambda_sync o lambda_async. O bien invoque de forma asíncrona una función de AWS Lambda con
el procedimiento mysql.lambda_async. Para obtener más información, consulte Invocación de una
función de Lambda con una función nativa de Aurora MySQL (p. 656).
• Cargar datos desde archivos de texto o XML almacenados en un bucket de Amazon S3 en el clúster
de base de datos usando la instrucción LOAD DATA FROM S3 o LOAD XML FROM S3. Para obtener
más información, consulte Carga de datos en un clúster de base de datos Amazon Aurora MySQL desde
archivos de texto en un bucket de Amazon S3 (p. 641).
• Guardar datos del clúster de base de datos en archivos de texto almacenados en un bucket de
Amazon S3 usando el comando SELECT INTO OUTFILE S3. Para obtener más información, consulte
Grabación de datos desde un clúster de base de datos Amazon Aurora MySQL en archivos de texto de
• Exportar datos de log a Amazon CloudWatch Logs MySQL. Para obtener más información, consulte
Publicación de registros de Amazon Aurora MySQL en Amazon CloudWatch Logs (p. 662).
Configuración de roles de IAM para acceder a servicios de AWS

Para permitir el acceso de un clúster de base de datos Aurora a otro servicio de AWS, haga lo siguiente:
1. Cree una política de IAM que otorgue permiso al servicio de AWS. Para obtener más información,
consulte:
• Creación de una política de IAM para acceder a los recursos de Amazon S3 (p. 630)
• Creación de una política de IAM para acceder a los recursos de AWS Lambda (p. 632)
• Creación de una política de IAM para acceder a los recursos de CloudWatch Logs (p. 633)
• Creación de una política de IAM para acceder a los recursos de AWS KMS (p. 635)
2. Cree un rol de IAM y adjúntele la política que ha creado. Para obtener más información, consulte
Creación de un rol de IAM que permita a Amazon Aurora acceder a los servicios de AWS (p. 635).
3. Asocie el rol de IAM al clúster de base de datos Aurora. Para obtener más información, consulte
Asociación de un rol de IAM con un clúster de base de datos Amazon Aurora MySQL (p. 636).
Creación de una política de IAM para acceder a los recursos de Amazon S3

Aurora puede tener acceso a recursos de Amazon S3 para cargar datos o para guardar datos desde un
clúster de base de datos Aurora. Sin embargo, primero debe crear una política de IAM que asigne los
permisos de bucket y objeto que hacen posible el acceso de Aurora a Amazon S3.
La tabla siguiente indica las características de Aurora con acceso a un bucket de Amazon S3 en su
nombre y los permisos de bucket y objeto mínimos requeridos por cada una.
630
Característica Permisos de bucket Permisos de objeto
LOAD DATA FROM S3 ListBucket GetObject
GetObjectVersion
LOAD XML FROM S3 ListBucket GetObject
GetObjectVersion
SELECT INTO OUTFILE S3 ListBucket AbortMultipartUpload
DeleteObject
GetObject
ListMultipartUploadParts
PutObject
Note
Es posible que se requieran otros permisos. Por ejemplo, si su bucket de Amazon S3 está cifrado,
debe añadir permisos kms:Decrypt.
Puede seguir los pasos indicados a continuación para crear una política de IAM que otorgue los permisos
mínimos necesarios para que Aurora tenga acceso a un bucket de Amazon S3 en su nombre. Para permitir
el acceso de Aurora a todos los buckets de Amazon S3 puede omitir estos pasos y usar la política de IAM
predefinida AmazonS3ReadOnlyAccess o AmazonS3FullAccess en lugar de crear la suya propia.
Para crear una política de IAM para dar acceso a los recursos de Amazon S3
1. Abra la consola de administración de IAM.

4. En la pestaña Visual editor (Editor visual), seleccione Choose a service (Elegir un servicio) y, a
continuación, S3.
5. Elija Expand all (Ampliar todo) en Actions (Acciones) y, a continuación, elija los permisos de bucket y
permisos de objeto necesarios para la política de IAM.
Los permisos de objeto se refieren a las operaciones de objeto en Amazon S3 y deben concederse
para los objetos de un bucket, y no para el bucket en sí. Para obtener más información acerca de los
permisos para operaciones de objeto en Amazon S3, consulte Permisos para operaciones de objetos.
6. Elija Resources (Recursos) y Add ARN (Añadir ARN) para bucket.
7. En el cuadro de diálogo Add ARN(s) (Añadir ARN), proporcione los detalles acerca de su recurso y
elija Add (Añadir).
Especifique el bucket de Amazon S3 al que se permitirá obtener acceso. Por ejemplo, si desea
conceder a Aurora acceso al bucket de Amazon S3 llamado example-bucket, establezca como
valor del Nombre de recurso de Amazon (ARN) arn:aws:s3:::example-bucket.
8. Si se lista el recurso object (objeto), elija Add ARN (Añadir ARN) para object (objeto).
9. En el cuadro de diálogo Add ARN(s) (Añadir ARN), proporcione los detalles acerca de su recurso.
Para el bucket de Amazon S3, especifique el bucket de Amazon S3 al que se permitirá obtener
acceso. Para el objeto, puede elegir Any (Cualquiera) para conceder permisos a cualquier objeto del
bucket.

631
Note
Puede establecer en Nombre de recurso de Amazon (ARN) un valor de ARN más específico
y que así Aurora solo tenga acceso a archivos o carpetas determinados de un bucket de
Amazon S3. Para obtener más información acerca del modo de definir una política de acceso
en Amazon S3, consulte Administración de permisos de acceso para los recursos de Amazon
S3.
10. (Opcional) Elija Add additional permissions (Añadir permisos adicionales) para añadir otro bucket de
Amazon S3 a la política y repita los pasos anteriores para el bucket.
Note
Puede repetir esto para añadir las instrucciones de permisos de bucket correspondientes a la
política para cada bucket de Amazon S3 al que deba obtener acceso Aurora. Opcionalmente,
también puede conceder acceso a todos los buckets y objetos de Amazon S3.
11. Elija Review policy (Revisar política).
12. En Name (Nombre), escriba un nombre para la política de IAM, por ejemplo,
AllowAuroraToExampleBucket. Utilizará este nombre al crear un rol de IAM y asociarlo al clúster
de base de datos Aurora. También puede añadir una descripción opcional en Description.
Creación de una política de IAM para acceder a los recursos de AWS Lambda
Puede crear una política de IAM que otorgue los permisos mínimos necesarios para que Aurora invoque
una función de AWS Lambda en su nombre.
La política siguiente añade los permisos que requiere Aurora para invocar una función de AWS Lambda en
su nombre.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowAuroraToExampleFunction",
"Effect": "Allow",
"Action": "lambda:InvokeFunction",
"Resource":
"arn:aws:lambda:<region>:<123456789012>:function:<example_function>"
}
]
}
mínimos necesarios para que Aurora invoque una función de AWS Lambda en su nombre. Para permitir
que Aurora invoque todas las funciones de AWS Lambda puede omitir estos pasos y usar la política
predefinida AWSLambdaRole en lugar de crear la suya propia.
Para crear una política de IAM que permita invocar las funciones de AWS Lambda
1. Abra la consola de IAM.

continuación, Lambda.

632
5. Elija Expand all (Ampliar todo) en Actions (Acciones) y, a continuación, elija los permisos de AWS
Lambda necesarios para la política de IAM.
Asegúrese de que InvokeFunction está seleccionado. Es el permiso mínimo necesario para

permitir a Amazon Aurora invocar una función de AWS Lambda.
6. Elija Recursos y Add ARN (Añadir ARN) para función.
7. En el cuadro de diálogo Add ARN(s) (Añadir ARN), proporcione los detalles acerca de su recurso.
Especifique la función de Lambda a la que se permitirá obtener acceso. Por ejemplo, si desea
conceder a Aurora acceso a una función de Lambda llamada example_function, establezca como
valor de ARN arn:aws:lambda:::function:example_function.
Para obtener más información acerca del modo de definir una política de acceso para AWS Lambda,
consulte Autenticación y control de acceso de AWS Lambda.
8. De forma opcional, elija Add additional permissions (Añadir permisos adicionales) para añadir otra
función de AWS Lambda a la directiva y repita los pasos anteriores para la función.
Note
Puede repetir esto para añadir las instrucciones de permisos de función correspondientes a la
política para cada función de AWS Lambda a la que deba obtener acceso Aurora.
9. Elija Review policy.
10. En Nombre, escriba un nombre para la política de IAM, por ejemplo,
AllowAuroraToExampleFunction. Utilizará este nombre al crear un rol de IAM y asociarlo al
clúster de base de datos Aurora. También puede añadir una descripción opcional en Description.
Creación de una política de IAM para acceder a los recursos de CloudWatch Logs
Aurora puede acceder a CloudWatch Logs para exportar datos de registros de auditoría desde un clúster
de base de datos Aurora. Sin embargo, primero debe crear una política de IAM que asigne los permisos de
grupo de registros y flujo de registros que hacen posible que Aurora acceda a CloudWatch Logs.
La siguiente política agrega los permisos que requiere Aurora para acceder a Amazon CloudWatch Logs
en su nombre y el número mínimo de permisos necesarios para crear grupos de registros y exportar datos.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "EnableCreationAndManagementOfRDSCloudwatchLogGroups",
"Effect": "Allow",
"Action": [
"logs:CreateLogGroup",
"logs:PutRetentionPolicy"
],
"Resource": [
"arn:aws:logs:*:*:log-group:/aws/rds/*"
]
},
{
"Sid": "EnableCreationAndManagementOfRDSCloudwatchLogStreams",
"Effect": "Allow",
"Action": [
"logs:CreateLogStream",
"logs:PutLogEvents",

633
"logs:DescribeLogStreams",
"logs:GetLogEvents"
],
"Resource": [
"arn:aws:logs:*:*:log-group:/aws/rds/*:log-stream:*"
]
}
]
}
mínimos necesarios para que Aurora tenga acceso a CloudWatch Logs en su nombre. Para conceder
acceso total de Aurora a CloudWatch Logs puede omitir estos pasos y usar la política de IAM predefinida
CloudWatchLogsFullAccess en lugar de crear la suya propia. Para obtener más información, consulte
Uso de políticas basadas en identidad (políticas de IAM) para CloudWatch Logs en la Guía del usuario de
Amazon CloudWatch.
Para crear una política de IAM para dar acceso a los recursos de CloudWatch Logs

4. En la pestaña Visual editor (Editor visual), elija Choose a service (Elegir un servicio) y, a continuación,
CloudWatch Logs.
5. Elija Expand all (Ampliar todo) en Actions (Acciones) y, a continuación, elija los permisos de Amazon
CloudWatch Logs necesarios para la política de IAM.
Compruebe que los permisos siguientes estén seleccionados:
• CreateLogGroup
• CreateLogStream
• DescribeLogStreams
• GetLogEvents
• PutLogEvents
• PutRetentionPolicy
6. Elija Resources (Recursos) y Add ARN (Añadir ARN) para log-group.
7. En el cuadro de diálogo Add ARN(s) (Añadir ARN), escriba log-group:/aws/rds/* para Log
Group Name y elija Add (Añadir).
8. Elija Add ARN (Añadir ARN) para log-stream.
9. En el cuadro de diálogo Add ARN(s) (Añadir ARN), escriba los siguientes valores:
• Log Group Name (Nombre del grupo de registro): log-group:/aws/rds/*

• Log Stream (Flujo de registro): log-stream
• Log Stream Name (Nombre del flujo de registro): *
10. En el cuadro de diálogo Add ARN(s) (Añadir ARN), seleccione Add (Añadir).
12. En Nombre, escriba un nombre para la política de IAM, por ejemplo, AmazonRDSCloudWatchLogs.
Utilizará este nombre al crear un rol de IAM y asociarlo al clúster de base de datos Aurora. También
puede añadir una descripción opcional en Description.
634
Creación de una política de IAM para acceder a los recursos de AWS KMS
Aurora puede obtener acceso a las claves de AWS Key Management Service usadas para cifrar sus copias
de seguridad de bases de datos. Sin embargo, primero debe crear una política de IAM que asigne los
permisos que hacen posible que Aurora obtenga acceso a las claves de KMS.
La política siguiente añade los permisos que requiere Aurora para obtener acceso a las claves de KMS en
su nombre.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"kms:Decrypt",
],
"Resource": "arn:aws:kms:<region>:<123456789012>:key/<key-ID>"
}
]
}
mínimos necesarios para que Aurora tenga acceso a las claves de KMS en su nombre.
Para crear una política de IAM para conceder acceso a sus claves de KMS

continuación, KMS.
5. En Actions (Acciones), elija Write (Escritura) y después elija Decrypt (Descifrar).
6. Elija Resources (Recursos) y después Add ARN (Añadir ARN).
7. En el cuadro de diálogo Add ARN(s) (Añadir ARN), escriba los siguientes valores:
• Región: especifique la región de AWS, como us-west-2.

• Cuenta: especifique el número de cuenta de usuario.
• Log Stream Name (Nombre del flujo de registros): especifique el ID de la clave de KMS.
8. En el cuadro de diálogo Add ARN(s) (Añadir ARN), seleccione Add (Añadir).
10. En Nombre, escriba un nombre para la política de IAM, por ejemplo, AmazonRDSKMSKey. Utilizará
este nombre al crear un rol de IAM y asociarlo al clúster de base de datos Aurora. También puede
añadir una descripción opcional en Description.
Creación de un rol de IAM que permita a Amazon Aurora acceder a los servicios
de AWS
Una vez creada una política de IAM para permitir a Aurora el acceso a recursos de AWS debe crear un rol
de IAM y asociarle la política de IAM.

635
Para crear un rol de IAM que permita al clúster de Amazon RDS comunicarse con otros servicios de AWS
en su nombre, siga estos pasos.
Para crear un rol de IAM que permita a Amazon RDS el acceso a los servicios de AWS

3. Elija Create role.
4. En AWS service, elija RDS.
5. En Select your use case (Seleccionar caso de uso), elija RDS – CloudHSM and Directory Service
(RDS - CloudHSM y Directory Service).
6. Elija Next: Permissions.
7. Elija Next: Tags (Siguiente: Etiquetas).
8. Elija Next: Review.
9. En Nombre de rol, escriba un nombre para el rol de IAM, por ejemplo, RDSLoadFromS3. También
puede añadir una descripción opcional en Role Description (Descripción de rol).
10. Elija Create Role.
12. En el campo Search (Buscar), especifique el nombre del rol creado y elija el nombre del rol cuando
aparezca en la lista.
13. En la pestaña Permissions, separe las siguientes funciones predeterminadas de la política:
• AmazonRDSDirectoryServiceAccess
• RDSCloudHsmAuthorizationRole
Para separar un rol, elija la X asociada al rol a la derecha y, a continuación, seleccione Detach
(Separar).
14. En la pestaña Permissions (Permisos), elija Attach policies (Asociar políticas).
15. En la página Asociar política, introduzca el nombre de su política en el campo Buscar.
16. Cuando aparezca en la lista, seleccione la política que ha definido anteriormente siguiendo las
instrucciones de alguna de las siguientes secciones:
• Creación de una política de IAM para acceder a los recursos de Amazon S3 (p. 630)
• Creación de una política de IAM para acceder a los recursos de AWS Lambda (p. 632)
• Creación de una política de IAM para acceder a los recursos de CloudWatch Logs (p. 633)
• Creación de una política de IAM para acceder a los recursos de AWS KMS (p. 635)
17. Elija Attach policy.
18. Realice los pasos que se indican en Asociación de un rol de IAM con un clúster de base de datos
Asociación de un rol de IAM con un clúster de base de datos Amazon Aurora

MySQL
Para permitir el acceso a otros servicios de AWS a los usuarios de un clúster de base de datos Amazon
Aurora debe asociar el rol que creó en Creación de un rol de IAM que permita a Amazon Aurora acceder a
los servicios de AWS (p. 635) con ese clúster.
Para asociar un rol de IAM con un clúster de base de datos es necesario hacer dos cosas:
• Añadir el rol a la lista de roles asociados del clúster de base de datos con la consola de RDS, el
comando add-role-to-db-cluster de la AWS CLI o la acción AddRoleToDBCluster de la API de RDS.

636
Puede añadir un máximo de cinco roles de IAM por cada clúster de base de datos Aurora.
• Establecer el ARN del rol de IAM asociado en el parámetro a nivel de clúster para el servicio de AWS de
que se trate.
En la tabla siguiente se indican los nombres de los parámetros a nivel de clúster para los roles de IAM
empleados en el acceso a otros servicios de AWS.
Parámetro de nivel de Descripción

clúster
Se utiliza al invocar una función de Lambda desde

aws_default_lambda_role
el clúster de base de datos.
Este parámetro ya no es necesario para exportar

aws_default_logs_role
datos de registros desde el clúster de base
de datos a Amazon CloudWatch Logs. Aurora
MySQL utiliza ahora un rol vinculado al servicio
para los permisos necesarios. Para obtener más
información acerca de los roles vinculados a
servicios, consulte Uso de roles vinculados a
servicios en Amazon Aurora (p. 207).
aws_default_s3_role Se utiliza al invocar la instrucción LOAD DATA

FROM S3, LOAD XML FROM S3 o SELECT INTO
OUTFILE S3 desde el clúster de base de datos.
El rol de IAM especificado en este parámetro

solo se usa cuando no se especifica un rol
de IAM para aurora_load_from_s3_role
o aurora_select_into_s3_role en la
instrucción correspondiente.
En las versiones anteriores de Aurora se usa

siempre el rol especificado en este parámetro.
Se utiliza al invocar la instrucción LOAD DATA

aurora_load_from_s3_role
FROM S3 o LOAD XML FROM S3 desde el
clúster de base de datos. Si no se especifica
un rol de IAM para este parámetro, se utiliza
el rol de IAM especificado en el parámetro
Para las versiones anteriores de Aurora este

parámetro no está disponible.
Se utiliza al invocar la instrucción SELECT INTO

aurora_select_into_s3_role
OUTFILE S3 desde el clúster de base de datos.
Si no se especifica un rol de IAM para este
parámetro, se utiliza el rol de IAM especificado en
el parámetro aws_default_s3_role.
Para las versiones anteriores de Aurora este

parámetro no está disponible.
Para asociar un rol de IAM que permita al clúster de Amazon RDS comunicarse con otros servicios de
AWS en su nombre, siga estos pasos.

637
Para asociar un rol de IAM a un clúster de base de datos Aurora con la consola
1. Abra la consola de RDS en https://console.aws.amazon.com/rds/.

3. Elija el nombre del clúster de base de datos de Aurora al que desea asociar un rol de IAM para
mostrar sus detalles.
4. En la pestaña Connectivity & security (Conectividad y seguridad), en la sección Manage IAM roles
(Administrar roles de IAM), elija el rol que desee añadir en Add IAM roles to this cluster (Añadir roles
de IAM a este clúster).
5. Seleccione Añadir rol.

6. (Opcional) Para dejar de asociar un rol de IAM a un clúster de base de datos y retirarle el permiso
correspondiente, elija el rol y Delete (Eliminar).
7. En la consola de RDS, elija Parameter groups (Grupos de parámetros) en el panel de navegación.
8. Si ya está usando un grupo de parámetros de base de datos personalizado, puede seleccionarlo para
usarlo en lugar de crear uno nuevo. Si utiliza el grupo de parámetros de clúster de base de datos
predeterminado, cree un nuevo grupo de parámetros de clúster de base de datos como se describe en
los pasos siguientes:
a. Elija Create parameter group.

b. En Parameter group family (Familia de grupo de parámetros), elija aurora5.6 para un clúster de
base de datos compatible con Aurora MySQL 5.6 o aurora-mysql5.7 para un clúster de base
de datos compatible con Aurora MySQL 5.7.
c. Para Tipo, elija DB Cluster Parameter Group (Grupo de parámetros de clúster de base de datos).
d. Para Nombre de grupo, escriba el nombre del nuevo grupo de parámetros de clúster de base de
datos.
e. En Descripción, escriba una descripción del nuevo grupo de parámetros de clúster de base de
datos.

638
f. Seleccione Create.
9. En la página Parameter groups (Grupos de parámetros), seleccione su grupo de parámetros de clúster
de base de datos y elija Edit (Editar) en Parameter group actions (Acciones de grupos de parámetros).
10. Establezca en los parámetros a nivel de clúster adecuados los valores de ARN de rol de IAM
correspondientes. Por ejemplo, puede establecer solo en el parámetro aws_default_s3_role el
valor arn:aws:iam::123456789012:role/AllowAuroraS3Role.
12. Para cambiar el grupo de parámetros del clúster de base de datos para su clúster de base de datos,
realice los siguientes pasos:
a. Elija Databases (Bases de datos) y, a continuación, seleccione el clúster de base de datos de

Aurora.
b. Elija Modify.
c. Desplácese hasta Database options (Opciones de base de datos) y establezca en DB cluster
parameter group (Grupo de parámetros de clúster de base de datos) el grupo de parámetros de
d. Elija Continue.
e. Verifique los cambios y elija Apply immediately (Aplicar inmediatamente).
f. Elija Modify Cluster (Modificar clúster).
g. Elija Databases (Bases de datos) y, a continuación, seleccione la instancia principal del clúster de
base de datos.
h. Para Actions (Acciones), elija Reboot (Reiniciar).
Una vez reiniciada la instancia, el rol de IAM se asocia al clúster de base de datos.
Para obtener más información acerca de los grupos de parámetros de clúster, consulte
Parámetros de Aurora MySQL (p. 678).

639
Para asociar un rol de IAM a un clúster de base de datos con la AWS CLI
1. Ejecute el comando add-role-to-db-cluster desde la AWS CLI para añadir los ARN de los roles
de IAM al clúster de base de datos, como se muestra a continuación.
PROMPT> aws rds add-role-to-db-cluster --db-cluster-identifier my-cluster --role-arn

arn:aws:iam::123456789012:role/AllowAuroraS3Role
PROMPT> aws rds add-role-to-db-cluster --db-cluster-identifier my-cluster --role-arn
arn:aws:iam::123456789012:role/AllowAuroraLambdaRole
2. Si utiliza el grupo de parámetros de clúster de base de datos predeterminado, cree un nuevo grupo de
parámetros de clúster de base de datos. Si ya está usando un grupo de parámetros de base de datos
personalizado, puede usarlo en lugar de crear uno nuevo.
Para crear un nuevo grupo de parámetros de clúster de base de datos, ejecute el comando create-
db-cluster-parameter-group desde la AWS CLI, como se muestra a continuación.
PROMPT> aws rds create-db-cluster-parameter-group --db-cluster-parameter-group-name

AllowAWSAccess \
--db-parameter-group-family aurora5.6 --description "Allow access to Amazon S3 and
AWS Lambda"
En el caso de un clúster de base de datos compatible con Aurora MySQL 5.7, especifique aurora-
mysql5.7 para --db-parameter-group-family.
3. Configure el parámetro o parámetros adecuados a nivel de clúster y los valores de ARN de rol de IAM
correspondientes dentro del grupo de parámetros de clúster de base de datos, como se muestra a
continuación.
PROMPT> aws rds modify-db-cluster-parameter-group --db-cluster-parameter-group-name

AllowAWSAccess \
--parameters
"ParameterName=aws_default_s3_role,ParameterValue=arn:aws:iam::123456789012:role/
AllowAuroraS3Role,method=pending-reboot" \
--parameters
"ParameterName=aws_default_lambda_role,ParameterValue=arn:aws:iam::123456789012:role/
AllowAuroraLambdaRole,method=pending-reboot"
4. Modifique el clúster de base de datos de modo que use el nuevo grupo de parámetros de clúster de
base de datos y, a continuación, reinicie el clúster, como se muestra a continuación.
PROMPT> aws rds modify-db-cluster --db-cluster-identifier my-cluster --db-cluster-

parameter-group-name AllowAWSAccess
PROMPT> aws rds reboot-db-instance --db-instance-identifier my-cluster-primary
Una vez reiniciada la instancia, los roles de IAM están asociados al clúster de base de datos.
Para obtener más información acerca de los grupos de parámetros de clúster, consulte Parámetros de
Habilitación de la comunicación de red de Amazon Aurora

MySQL con otros servicios de AWS
Para invocar funciones de AWS Lambda u obtener acceso a archivos de Amazon S3, la configuración de
red del clúster de base de datos Aurora debe permitir conexiones salientes a los puntos de enlace de tales

640
Carga de datos desde archivos de texto en Amazon S3
servicios. Cuando no puede conectar con un punto de enlace de servicio, Aurora devuelve el mensaje de
error siguiente si no puede conectarse a un punto de enlace.
ERROR 1871 (HY000): S3 API returned error: Network Connection
ERROR 1873 (HY000): Lambda API returned error: Network Connection. Unable to connect to
endpoint
Si observa estos mensajes al llamar a funciones de AWS Lambda o al intentar el acceso a archivos de
Amazon S3, compruebe si el clúster de base de datos Aurora es público o privado. Si el clúster de base de
datos de Aurora es privado, debe configurarlo para habilitar las conexiones.
Para que un clúster de base de datos de Aurora sea público debe estar marcado como accesible de forma
pública. Si observa los detalles del clúster de base de datos en la Consola de administración de AWS,
Publicly Accessible (Accesible públicamente) será Sí en tal caso. Además, el clúster de base de datos
debe encontrarse en una subred pública de una Amazon VPC. Para obtener más información acerca de
las instancias de bases de datos con acceso público, consulte Uso de una instancia de base de datos
en una VPC (p. 222). Para obtener más información acerca de las subredes de Amazon VPC públicas,
consulte VPC y subredes.
Si el clúster de base de datos de Aurora no es de acceso público y se encuentra en una subred pública
de una VPC, es privado. Es posible que tenga un clúster de bases de datos privado y que desee invocar
funciones de AWS Lambda o tener acceso a los archivos de Amazon S3. Si es así, configure el clúster
para que se pueda conectar a direcciones de Internet a través de la traducción de direcciones de red
(NAT). Como alternativa para Amazon S3 también puede configurar la VPC para que tenga un punto de
enlace de la VPC para Amazon S3 asociado a la tabla de ruteo del clúster de base de datos. Para obtener
más información acerca de la configuración de NAT en la VPC, consulte Gateways NAT. Para obtener más
información acerca de la configuración de puntos de enlace de la VPC, consulte Puntos de enlace de la
VPC.
Temas relacionados
Carga de datos en un clúster de base de datos

Amazon Aurora MySQL desde archivos de texto en un
bucket de Amazon S3
Puede utilizar la instrucción LOAD DATA FROM S3 o LOAD XML FROM S3 para cargar datos de archivos
almacenados en un bucket de Amazon S3.
Note
En Amazon Aurora MySQL versión 1.8 y posteriores se pueden cargar datos en una tabla desde
archivos de texto almacenados en un bucket de Amazon S3. Para obtener más información
acerca de las versiones de Aurora MySQL, consulte Actualizaciones del motor de base de datos
para Amazon Aurora MySQL (p. 695).
Esta característica no está disponible para clústeres de Aurora Serverless.
Acceso de Aurora a Amazon S3

Para poder cargar datos desde un bucket de Amazon S3, primero debe dar al clúster de base de datos
Aurora MySQL permiso para que obtenga acceso a Amazon S3.

641
Para conceder a Aurora MySQL acceso a Amazon S3
1. Cree una política de AWS Identity and Access Management (IAM) que asigne los permisos de bucket
y objeto que permiten que su clúster de base de datos Aurora MySQL obtenga acceso a Amazon S3.
Amazon S3 (p. 630).
2. Cree un rol de IAM y asocie la política de IAM que creó en Creación de una política de IAM para
acceder a los recursos de Amazon S3 (p. 630) al nuevo rol de IAM. Para obtener instrucciones,
consulte Creación de un rol de IAM que permita a Amazon Aurora acceder a los servicios de
AWS (p. 635).
3. Configure el parámetro de clúster de base de datos aurora_load_from_s3_role o
aws_default_s3_role con el Nombre de recurso de Amazon (ARN) del nuevo rol de IAM. Si no
se ha especificado un rol de IAM para aurora_load_from_s3_role, Aurora utilizará el rol de IAM
especificado en el parámetro aws_default_s3_role.
Si el clúster es parte de una base de datos global de Aurora, configure este parámetro para cada
clúster de Aurora en la base de datos global. Aunque solo el clúster principal de una base de datos
global de Aurora puede cargar datos, se puede promover otro clúster por parte del mecanismo de
conmutación por error y convertirse en clúster principal.
Para obtener más información acerca de los parámetros de clúster de base de datos, consulte
Parámetros del clúster de base de datos y la instancia de base de datos Amazon Aurora (p. 261).
4. Para permitir el acceso a Aurora MySQL a los usuarios de base de datos un clúster de base de
datos Amazon S3, asocie el rol que creó en Creación de un rol de IAM que permita a Amazon Aurora
acceder a los servicios de AWS (p. 635) con el clúster. Para una base de datos global de Aurora,
asocie el rol con cada clúster de Aurora en la base de datos global. Para obtener información acerca
de cómo asociar un rol de IAM con un clúster de base de datos, consulte Asociación de un rol de IAM
con un clúster de base de datos Amazon Aurora MySQL (p. 636).
5. Configure el clúster de base de datos Aurora MySQL para permitir conexiones salientes hacia Amazon
S3. Para obtener instrucciones, consulte Habilitación de la comunicación de red de Amazon Aurora
MySQL con otros servicios de AWS (p. 640).
Para una base de datos global de Aurora, habilite las conexiones de salida para cada clúster de
Aurora en la base de datos global.
Concesión de privilegios para cargar datos en Amazon Aurora

MySQL
El usuario de la base de datos que utiliza la instrucción LOAD DATA FROM S3 o LOAD XML FROM S3
debe tener el privilegio LOAD FROM S3 para poder hacerlo. El nombre de usuario maestro de un clúster
de base de datos tiene el privilegio LOAD FROM S3 de forma predeterminada. Para conceder el privilegio a
otro usuario, puede usar la instrucción siguiente:
GRANT LOAD FROM S3 ON *.* TO 'user'@'domain-or-ip-address'
El privilegio LOAD FROM S3 es específico de Amazon Aurora y no está disponible en las bases de datos
MySQL ni en las instancias de base de datos MySQL en RDS. Si ha configurado replicación entre un
clúster de base de datos Aurora como maestro y una base de datos MySQL como cliente, la instrucción
GRANT LOAD FROM S3 hace que la replicación se detenga con un error. Puede pasar por alto el error
para continuar la replicación. Para pasar por alto el error en una instancia de base de datos MySQL de
RDS, utilice el procedimiento mysql_rds_skip_repl_error. Para pasar por alto el error en una base de datos
MySQL, use la instrucción SET GLOBAL sql_slave_skip_counter.

642
Especificación de una ruta a un bucket de Amazon S3

La sintaxis para especificar una ruta de acceso a los archivos almacenados en un bucket de Amazon S3 es
la siguiente.
s3-region://bucket-name/file-name-or-prefix
La ruta incluye los siguientes valores:
• region (opcional): la región de AWS que contiene el bucket de Amazon S3 desde el que se va a
realizar la carga. Este valor es opcional. Si no se especifica el valor region, Aurora carga el archivo de
Amazon S3 desde la misma región en la que se encuentra el clúster de base de datos.
• bucket-name: el nombre del bucket de Amazon S3 que contiene los datos que se van a cargar.
Pueden usarse prefijos de objeto que identifiquen una ruta de carpeta virtual.
• file-name-or-prefix: el nombre del archivo de texto o el archivo XML de Amazon S3, o un prefijo
que identifica el archivo o los archivos de texto o XML que se van a cargar. También puede especificar
un archivo de manifiesto que identifique el archivo o los archivos de texto que se van a cargar. Para
obtener más información acerca de cómo utilizar un archivo de manifiesto para cargar archivos de texto
desde Amazon S3, consulte Uso de un manifiesto para especificar los archivos de datos que se deben
cargar (p. 645).
LOAD DATA FROM S3

Puede utilizar la instrucción LOAD DATA FROM S3 para cargar datos desde archivos de texto con
cualquier formato que sea compatible con la instrucción LOAD DATA INFILE de MySQL, como los datos
de texto delimitados por comas. No se admiten los archivos comprimidos.
Sintaxis
LOAD DATA FROM S3 [FILE | PREFIX | MANIFEST] 'S3-URI'

[REPLACE | IGNORE]
INTO TABLE tbl_name
[PARTITION (partition_name,...)]
[CHARACTER SET charset_name]
[{FIELDS | COLUMNS}
[TERMINATED BY 'string']
[[OPTIONALLY] ENCLOSED BY 'char']
[ESCAPED BY 'char']
]
[LINES
[STARTING BY 'string']
]
[IGNORE number {LINES | ROWS}]
[(col_name_or_user_var,...)]
[SET col_name = expr,...]
Parámetros
A continuación, puede encontrar una lista de los parámetros obligatorios y opcionales utilizados por
la instrucción LOAD DATA FROM S3. Puede encontrar más información acerca de algunos de estos
parámetros en LOAD DATA INFILE Syntax en la documentación de MySQL.
• FILE | PREFIX | MANIFEST: identifica si se deben cargar los datos de un solo archivo, de todos los
archivos que coincidan con un prefijo determinado o de todos los archivos del manifiesto especificado.
FILE es el valor predeterminado.

643
• S3-URI: especifica el URI del archivo de texto o de manifiesto que se debe cargar, o el prefijo de
Amazon S3 que se debe utilizar. Especifique el URI utilizando la sintaxis descrita en Especificación de
una ruta a un bucket de Amazon S3 (p. 643).
• REPLACE | IGNORE: determina la acción que se debe realizar si una fila de entrada tiene los mismos
valores de clave única que una fila existente en la tabla de la base de datos.
• Especifique REPLACE si desea que la fila de entrada sustituya la fila existente en la tabla.
• Especifique IGNORE si desea para descartar la fila de entrada. IGNORE es el valor predeterminado.
• INTO TABLE: identifica el nombre de la tabla de la base de datos en la que se deben cargar las filas de
entrada.
• PARTITION: requiere que todas las filas de entrada se inserten en las particiones identificadas por la
lista especificada que contiene los nombres de las particiones separados por comas. Si no se puede
insertar una fila de entrada en una de las particiones especificadas, la instrucción falla y se devuelve un
error.
• CHARACTER SET: identifica el conjunto de caracteres de los datos del archivo de entrada.
• FIELDS | COLUMNS: identifica cómo están delimitados los campos o las columnas del archivo de
entrada. De forma predeterminada, los campos están delimitados por tabuladores.
• LINES: identifica cómo están delimitadas las líneas del archivo de entrada. De forma predeterminada, las
líneas están delimitadas por un retorno de carro.
• IGNORE número LINES | ROWS: especifica que se deben omitir cierto número de líneas o filas al
principio del archivo de entrada. Por ejemplo, puede utilizar IGNORE 1 LINES para omitir una línea de
encabezado inicial que contiene los nombres de las columnas o IGNORE 2 ROWS para omitir las dos
primeras filas de datos del archivo de entrada.
• col_name_or_user_var, ... Especifica una lista separada por comas de uno o varios nombres de columna
o variables de usuario que identifican las columnas que se deben cargar por nombre. El nombre de una
variable de usuario utilizada para este propósito debe coincidir con el nombre de un elemento del archivo
de texto, con el prefijo @. Puede utilizar variables de usuario para almacenar los valores de los campos
correspondientes para utilizarlos posteriormente.
Por ejemplo, la siguiente instrucción carga la primera columna del archivo de entrada en la primera
columna de table1, y establece el valor de la columna table_column2 de table1 en el valor de
entrada de la segunda columna, dividido por 100.
LOAD DATA FROM S3 's3://mybucket/data.txt'

INTO TABLE table1
(column1, @var1)
SET table_column2 = @var1/100;
• SET: especifica una lista separada por comas que contiene operaciones de asignación que asignan
valores no incluidos en el archivo de entrada a las columnas de la tabla.
Por ejemplo, la siguiente instrucción asigna a las dos primeras columnas de table1 los valores de
las dos primeras columnas del archivo de entrada y, a continuación, asigna la fecha y hora actuales a
column3 de table1.
LOAD DATA FROM S3 's3://mybucket/data.txt'

INTO TABLE table1
(column1, column2)
SET column3 = CURRENT_TIMESTAMP;
Es posible utilizar subconsultas en el lado derecho de las asignaciones SET. Para una subconsulta que
devuelve un valor que se va a asignar a una columna, solo se puede utilizar una subconsulta escalar.
Además, no puede utilizar una subconsulta para seleccionar datos de la tabla que se está cargando.

644
No se puede utilizar la palabra clave LOCAL de la instrucción LOAD DATA FROM S3 para cargar datos de
un bucket de Amazon S3.
Uso de un manifiesto para especificar los archivos de datos que se deben cargar
Puede utilizar la instrucción LOAD DATA FROM S3 con la palabra clave MANIFEST para especificar un
archivo de manifiesto con formato JSON que enumera los archivos de texto que se cargarán en una tabla
del clúster de base de datos. Debe utilizar Aurora 1.11 o una versión posterior para usar la palabra clave
MANIFEST con la instrucción LOAD DATA FROM S3.
El siguiente esquema JSON describe el formato y el contenido de un archivo de manifiesto.
{
"$schema": "http://json-schema.org/draft-04/schema#",
"additionalProperties": false,
"definitions": {},
"id": "Aurora_LoadFromS3_Manifest",
"properties": {
"entries": {
"additionalItems": false,
"id": "/properties/entries",
"items": {
"additionalProperties": false,
"id": "/properties/entries/items",
"properties": {
"mandatory": {
"default": "false"
"id": "/properties/entries/items/properties/mandatory",
"type": "boolean"
},
"url": {
"id": "/properties/entries/items/properties/url",
"maxLength": 1024,
"minLength": 1,
"type": "string"
}
},
"required": [
"url"
],
"type": "object"
},
"type": "array",
"uniqueItems": true
}
},
"required": [
"entries"
],
"type": "object"
}
Cada url del manifiesto debe especificar una URL con el nombre del bucket y la ruta de objeto completa
del archivo, no solo un prefijo. Puede usar un manifiesto para cargar archivos de diferentes buckets o
regiones, o archivos que no comparten el mismo prefijo. Si no se especifica una región en la URL, se utiliza
la región del clúster de base de datos de destino de Aurora. En el siguiente ejemplo se muestra un archivo
de manifiesto que carga cuatro archivos desde distintos buckets.
{
"entries": [
{
"url":"s3://aurora-bucket/2013-10-04-customerdata",
"mandatory":true

645
},
{
"url":"s3-us-west-2://aurora-bucket-usw2/2013-10-05-customerdata",
"mandatory":true
},
{
"url":"s3://aurora-bucket/2013-10-04-customerdata",
"mandatory":false
},
{
"url":"s3://aurora-bucket/2013-10-05-customerdata"
}
]
}
La marca opcional mandatory especifica si LOAD DATA FROM S3 debe devolver un error en caso de que
no se encuentre el archivo. De forma predeterminada, la marca mandatory tiene el valor false. Sea cual
sea el valor de mandatory, LOAD DATA FROM S3 finaliza si no se encuentra ningún archivo.
Los archivos de manifiesto pueden tener cualquier extensión. En el siguiente ejemplo, se ejecuta
la instrucción LOAD DATA FROM S3 con el manifiesto del ejemplo anterior, que se denomina
customer.manifest.
LOAD DATA FROM S3 MANIFEST 's3-us-west-2://aurora-bucket/customer.manifest'

INTO TABLE CUSTOMER
FIELDS TERMINATED BY ','
LINES TERMINATED BY '\n'
(ID, FIRSTNAME, LASTNAME, EMAIL);
Una vez finalizada la instrucción, se escribe una entrada en la tabla aurora_s3_load_history para
cada archivo que se ha cargado correctamente.
Comprobación de los archivos cargados mediante la tabla aurora_s3_load_history

Cada vez que se ejecuta correctamente la instrucción LOAD DATA FROM S3, se actualiza la tabla
aurora_s3_load_history del esquema mysql con una entrada para cada archivo que se ha cargado.
Después de ejecutar la instrucción LOAD DATA FROM S3, puede comprobar qué archivos se han cargado
consultando la tabla aurora_s3_load_history. Para ver los archivos que se cargaron durante una
ejecución de la instrucción, utilice la cláusula WHERE para filtrar los registros utilizando el URI de Amazon
S3 del archivo de manifiesto utilizado en la instrucción. Si ha utilizado el mismo archivo de manifiesto
anteriormente, filtre los resultados utilizando el campo timestamp.
select * from mysql.aurora_s3_load_history where load_prefix = 'S3_URI';
En la siguiente tabla se describen los campos de la tabla aurora_s3_load_history.
Campo Descripción
load_prefix El URI que se especificó en la instrucción load. Este URI puede

mapearse a cualquiera de los elementos siguientes:
• Un solo archivo de datos para una instrucción LOAD DATA FROM

S3 FILE
• Un prefijo de Amazon S3 mapeado a varios archivos de datos para
una instrucción LOAD DATA FROM S3 PREFIX
• Un único archivo de manifiesto que contiene los nombres de los
archivos que se van a cargar para una instrucción LOAD DATA
FROM S3 MANIFEST

646
Campo Descripción
file_name El nombre de un archivo que se cargó en Aurora desde Amazon S3

utilizando el URI identificado en el campo load_prefix.
version_number El número de versión del archivo identificado por el campo

file_name que se cargó, si el bucket de Amazon S3 tiene un
número de versión.
bytes_loaded El tamaño del archivo cargado, en bytes.
load_timestamp La fecha y hora en que finalizó la instrucción LOAD DATA FROM S3.
Ejemplos
La siguiente instrucción carga datos desde un bucket de Amazon S3 que se encuentra en la misma región
que el clúster de base de datos Aurora. La instrucción lee los datos delimitados por comas del archivo
customerdata.txt que se encuentra en el bucket de Amazon S3 dbbucket y, a continuación, carga los
datos en la tabla store-schema.customer-table.
LOAD DATA FROM S3 's3://dbbucket/customerdata.csv'

INTO TABLE store-schema.customer-table
(ID, FIRSTNAME, LASTNAME, ADDRESS, EMAIL, PHONE);
La siguiente instrucción carga datos desde un bucket de Amazon S3 que se encuentra en una región que
no coincide con la del clúster de base de datos Aurora. La instrucción lee los datos delimitados por comas
de todos los archivos que coinciden con el prefijo de objeto employee-data que se encuentran en el
bucket my-data de Amazon S3 de la región us-west-2 y, a continuación, carga los datos en la tabla
employees.
LOAD DATA FROM S3 PREFIX 's3-us-west-2://my-data/employee_data'

INTO TABLE employees
(ID, FIRSTNAME, LASTNAME, EMAIL, SALARY);
La siguiente instrucción carga los datos de los archivos especificados en un archivo de manifiesto JSON
denominado q1_sales.json en la tabla sales.
LOAD DATA FROM S3 MANIFEST 's3-us-west-2://aurora-bucket/q1_sales.json'

INTO TABLE sales
(MONTH, STORE, GROSS, NET);
LOAD XML FROM S3

Puede utilizar la instrucción LOAD XML FROM S3 para cargar datos de archivos XML almacenados en un
bucket de Amazon S3 con uno de los tres formatos XML siguientes:
• Con los nombres de las columnas como atributos de un elemento <row>. El valor del atributo identifica
el contenido del campo de la tabla.
<row column1="value1" column2="value2" .../>

647
• Con los nombres de las columnas como elementos secundarios de un elemento <row>. El valor del
elemento secundario identifica el contenido del campo de la tabla.
<row>
<column1>value1</column1>
<column2>value2</column2>
</row>
• Con los nombres de las columnas en el atributo name de los elementos <field> de un elemento
<row>. El valor del elemento <field> identifica el contenido del campo de la tabla.
<row>
<field name='column1'>value1</field>
<field name='column2'>value2</field>
</row>
Sintaxis
LOAD XML FROM S3 'S3-URI'
[REPLACE | IGNORE]
INTO TABLE tbl_name
[PARTITION (partition_name,...)]
[ROWS IDENTIFIED BY '<element-name>']
[IGNORE number {LINES | ROWS}]
[(field_name_or_user_var,...)]
[SET col_name = expr,...]
Parámetros
A continuación, puede encontrar una lista de los parámetros obligatorios y opcionales utilizados por
la instrucción LOAD DATA FROM S3. Puede encontrar más información acerca de algunos de estos
parámetros en LOAD XML Syntax en la documentación de MySQL.
• FILE | PREFIX: identifica si se deben cargar los datos de un solo archivo o de todos los archivos que
coincidan con un prefijo determinado. FILE es el valor predeterminado.
• REPLACE | IGNORE: determina la acción que se debe realizar si una fila de entrada tiene los mismos
valores de clave única que una fila existente en la tabla de la base de datos.
• Especifique REPLACE si desea que la fila de entrada sustituya la fila existente en la tabla.
• Especifique IGNORE si desea para descartar la fila de entrada. IGNORE es el valor predeterminado.
• INTO TABLE: identifica el nombre de la tabla de la base de datos en la que se deben cargar las filas de
entrada.
• PARTITION: requiere que todas las filas de entrada se inserten en las particiones identificadas por la
lista especificada que contiene los nombres de las particiones separados por comas. Si no se puede
insertar una fila de entrada en una de las particiones especificadas, la instrucción falla y se devuelve un
error.
• CHARACTER SET: identifica el conjunto de caracteres de los datos del archivo de entrada.
• ROWS IDENTIFIED BY: establece el nombre del elemento que identifica una fila del archivo de entrada.
El valor predeterminado es <row>.
• IGNORE número LINES | ROWS: especifica que se deben omitir cierto número de líneas o filas al
principio del archivo de entrada. Por ejemplo, puede utilizar IGNORE 1 LINES para omitir la primera
línea del archivo de texto o IGNORE 2 ROWS para omitir las dos primeras filas de datos del archivo XML
de entrada.
• field_name_or_user_var, ... Especifica una lista separada por comas de uno o varios elementos XML o
variables de usuario que identifican los elementos que se deben cargar por nombre. El nombre de una

648
Almacenamiento de datos en
archivos de texto en Amazon S3
variable de usuario utilizada para este propósito debe coincidir con el nombre de un elemento del archivo
XML, con el prefijo @. Puede utilizar variables de usuario para almacenar los valores de los campos
correspondientes para utilizarlos posteriormente.
Por ejemplo, la siguiente instrucción carga la primera columna del archivo de entrada en la primera
columna de table1, y establece el valor de la columna table_column2 de table1 en el valor de
entrada de la segunda columna, dividido por 100.
LOAD XML FROM S3 's3://mybucket/data.xml'

INTO TABLE table1
(column1, @var1)
SET table_column2 = @var1/100;
• SET: especifica una lista separada por comas que contiene operaciones de asignación que asignan
valores no incluidos en el archivo de entrada a las columnas de la tabla.
Por ejemplo, la siguiente instrucción asigna a las dos primeras columnas de table1 los valores de
las dos primeras columnas del archivo de entrada y, a continuación, asigna la fecha y hora actuales a
column3 de table1.
LOAD XML FROM S3 's3://mybucket/data.xml'

INTO TABLE table1
(column1, column2)
SET column3 = CURRENT_TIMESTAMP;
Es posible utilizar subconsultas en el lado derecho de las asignaciones SET. Para una subconsulta que
devuelve un valor que se va a asignar a una columna, solo se puede utilizar una subconsulta escalar.
Además, no puede utilizar una subconsulta para seleccionar datos de la tabla que se está cargando.
Temas relacionados
• Integración de Amazon Aurora MySQL con otros servicios de AWS (p. 629)
• Grabación de datos desde un clúster de base de datos Amazon Aurora MySQL en archivos de texto de
un bucket de Amazon S3 (p. 649)
Grabación de datos desde un clúster de base de datos

Amazon Aurora MySQL en archivos de texto de un
bucket de Amazon S3
La instrucción SELECT INTO OUTFILE S3 permite consultar datos de un clúster de base de datos
Amazon Aurora MySQL y guardarlos directamente en archivos de texto almacenados en un bucket de
Amazon S3. Con este método puede evitar bajar primero los datos al cliente antes de copiarlos a Amazon
S3. La instrucción LOAD DATA FROM S3 puede usar los archivos así creados para cargar datos en un
clúster de base de datos Aurora. Para obtener más información, consulte Carga de datos en un clúster de
base de datos Amazon Aurora MySQL desde archivos de texto en un bucket de Amazon S3 (p. 641).
Note
Esta característica no está disponible para clústeres de Aurora Serverless.

649
Acceso de Aurora MySQL a Amazon S3

Para poder guardar datos en un bucket de Amazon S3, primero debe dar permiso al clúster de base de
datos Aurora MySQL para que tenga acceso a Amazon S3.
Para conceder a Aurora MySQL acceso a Amazon S3
1. Cree una política de AWS Identity and Access Management (IAM) que asigne los permisos de bucket
y objeto que permiten que su clúster de base de datos Aurora MySQL obtenga acceso a Amazon S3.
Amazon S3 (p. 630).
acceder a los recursos de Amazon S3 (p. 630) al nuevo rol de IAM. Para obtener instrucciones,
AWS (p. 635).
3. Configure el parámetro de clúster de base de datos aurora_select_into_s3_role o
aws_default_s3_role con el Nombre de recurso de Amazon (ARN) del nuevo rol de IAM. Si no se
ha especificado un rol de IAM para aurora_select_into_s3_role, Aurora utilizará el rol de IAM
especificado en el parámetro aws_default_s3_role.
Si el clúster es parte de una base de datos global de Aurora, configure este parámetro para cada
clúster de Aurora en la base de datos global.
4. Para permitir el acceso a Aurora MySQL a los usuarios de base de datos un clúster de base de
datos Amazon S3, asocie el rol que creó en Creación de un rol de IAM que permita a Amazon Aurora
acceder a los servicios de AWS (p. 635) con el clúster.
Para una base de datos global de Aurora, asocie el rol con cada clúster de Aurora en la base de datos
global.
Para obtener información acerca de cómo asociar un rol de IAM con un clúster de base de
datos, consulte Asociación de un rol de IAM con un clúster de base de datos Amazon Aurora
MySQL (p. 636).
5. Configure el clúster de base de datos Aurora MySQL para permitir conexiones salientes hacia Amazon
S3. Para obtener instrucciones, consulte Habilitación de la comunicación de red de Amazon Aurora
MySQL con otros servicios de AWS (p. 640).
Para una base de datos global de Aurora, habilite las conexiones de salida para cada clúster de
Aurora en la base de datos global.
Concesión de privilegios para guardar datos en Aurora MySQL

El usuario de la base de datos que utiliza la instrucción SELECT INTO OUTFILE S3 debe tener el
privilegio SELECT INTO S3 para poder hacerlo. El nombre de usuario maestro de un clúster de base de
datos tiene el privilegio SELECT INTO S3 de forma predeterminada. Para conceder el privilegio a otro
usuario, puede usar la instrucción siguiente:
GRANT SELECT INTO S3 ON *.* TO 'user'@'domain-or-ip-address'
El privilegio SELECT INTO S3 es específico de Amazon Aurora MySQL y no está disponible en las bases
de datos MySQL ni en las instancias de base de datos MySQL en RDS. Si ha configurado replicación entre
un clúster de base de datos Aurora MySQL como maestro y una base de datos MySQL como cliente, la
instrucción GRANT SELECT INTO S3 hace que la replicación se detenga con un error. Puede pasar por

650
alto el error para continuar la replicación. Para pasar por alto el error en una instancia de base de datos
MySQL de RDS, utilice el procedimiento mysql_rds_skip_repl_error. Para pasar por alto el error en una
base de datos MySQL, use la instrucción SET GLOBAL sql_slave_skip_counter.
Especificación de una ruta a un bucket de Amazon S3

La sintaxis para especificar una ruta donde almacenar los datos y los archivos de manifiesto en un bucket
de Amazon S3 es similar a la empleada en la instrucción LOAD DATA FROM S3 PREFIX, como se indica
a continuación:
s3-region://bucket-name/file-prefix
La ruta incluye los siguientes valores:
• region (opcional): región de AWS que contiene el bucket de Amazon S3 en el que se guardan los
datos. Este valor es opcional. Si no especifica el valor region, Aurora guarda los archivos en Amazon
S3 en la misma región en la que se encuentra el clúster de base de datos.
• bucket-name: nombre del bucket de Amazon S3 donde se guardan los datos. Pueden usarse prefijos
de objeto que identifiquen una ruta de carpeta virtual.
• file-prefix: prefijo de objeto de Amazon S3 que identifica los archivos que se guardan en Amazon
S3.
Los archivos de datos creados con la instrucción SELECT INTO OUTFILE S3 usan la ruta siguiente,
donde 00000 representa un número entero de cinco dígitos basado en cero.
s3-region://bucket-name/file-prefix.part_00000
Por ejemplo, supongamos que la instrucción SELECT INTO OUTFILE S3 especifica s3-us-west-2://
bucket/prefix como la ruta donde almacenar los archivos de datos y que crea tres archivos. El bucket
de Amazon S3 especificado contendrá los archivos de datos siguientes:
• s3-us-west-2://bucket/prefix.part_00000
Creación de un manifiesto con una lista de los archivos de datos

Puede utilizar la instrucción SELECT INTO OUTFILE S3 con la opción MANIFEST ON para crear un
archivo de manifiesto con formato JSON que enumera los archivos de texto creados por la instrucción. La
instrucción LOAD DATA FROM S3 puede usar el archivo de manifiesto para volver a cargar los archivos
de datos en un clúster de base de datos Aurora MySQL. Para obtener más información acerca de cómo
utilizar un archivo de manifiesto para cargar archivos de texto desde Amazon S3 en un clúster de base de
datos Aurora MySQL, consulte Uso de un manifiesto para especificar los archivos de datos que se deben
cargar (p. 645).
Los archivos de datos incluidos en el manifiesto creado con la instrucción SELECT INTO OUTFILE S3
se enumeran en el orden en que la instrucción los ha creado. Por ejemplo, supongamos que la instrucción
SELECT INTO OUTFILE S3 especificó s3-us-west-2://bucket/prefix como la ruta donde
almacenar los archivos de datos y que ha creado tres archivos de datos y un archivo de manifiesto. El
bucket de Amazon S3 especificado contendrá un archivo de manifiesto llamado s3-us-west-2://
bucket/prefix.manifest que contiene la información siguiente:
{
"entries": [

651
{
"url":"s3-us-west-2://bucket/prefix.part_00000"
},
{
},
{
}
]
}
SELECT INTO OUTFILE S3

Con la instrucción SELECT INTO OUTFILE S3 puede consultar datos de un clúster de base de datos y
guardarlos directamente en archivos de texto delimitado almacenados en un bucket de Amazon S3. No se
admiten los archivos comprimidos ni cifrados.
Sintaxis
SELECT
[ALL | DISTINCT | DISTINCTROW ]
[HIGH_PRIORITY]
[STRAIGHT_JOIN]
[SQL_SMALL_RESULT] [SQL_BIG_RESULT] [SQL_BUFFER_RESULT]
[SQL_CACHE | SQL_NO_CACHE] [SQL_CALC_FOUND_ROWS]
select_expr [, select_expr ...]
[FROM table_references
[PARTITION partition_list]
[WHERE where_condition]
[GROUP BY {col_name | expr | position}
[ASC | DESC], ... [WITH ROLLUP]]
[HAVING where_condition]
[ORDER BY {col_name | expr | position}
[ASC | DESC], ...]
[LIMIT {[offset,] row_count | row_count OFFSET offset}]
[PROCEDURE procedure_name(argument_list)]
INTO OUTFILE S3 's3_uri'
[export_options]
[MANIFEST {ON | OFF}]
[OVERWRITE {ON | OFF}]
export_options:
[{FIELDS | COLUMNS}
[[OPTIONALLY] ENCLOSED BY 'char']
[ESCAPED BY 'char']
]
[LINES
[STARTING BY 'string']
]
Parámetros
A continuación, puede encontrar una lista de los parámetros obligatorios y opcionales utilizados por la
instrucción SELECT INTO OUTFILE S3 que son específicos de Aurora.
• s3-uri: especifica el URI del prefijo de Amazon S3 utilizado. Especifique el URI utilizando la sintaxis
descrita en Especificación de una ruta a un bucket de Amazon S3 (p. 651).

652
• MANIFEST {ON | OFF}: indica si se crea o no un archivo de manifiesto en Amazon S3. El archivo de
manifiesto es un archivo en notación de objetos JavaScript (JSON) que puede usarse para cargar datos
en un clúster de base de datos Aurora con la instrucción LOAD DATA FROM S3 MANIFEST. Para
obtener más información acerca de LOAD DATA FROM S3 MANIFEST, consulte Carga de datos en
un clúster de base de datos Amazon Aurora MySQL desde archivos de texto en un bucket de Amazon
S3 (p. 641).
Si se especifica MANIFEST ON en la consulta, se creará el archivo de manifiesto en Amazon S3

después de haber creado y cargado todos los archivos de datos. El archivo de manifiesto se crea en la
ruta siguiente:
s3-region://bucket-name/file-prefix.manifest
Para obtener más información acerca del formato del contenido del archivo de manifiesto, consulte
Creación de un manifiesto con una lista de los archivos de datos (p. 651).
• OVERWRITE {ON | OFF}: indica si los archivos existentes en el bucket de Amazon S3 especificado se
sobrescriben. Si se especifica OVERWRITE ON, se sobrescribirán los archivos existentes con el prefijo
indicado en el URI especificado en s3-uri. En caso contrario, se produce un error.
Encontrará más información sobre otros parámetros en SELECT Syntax y LOAD DATA INFILE Syntax, de
Consideraciones
El número de archivos escritos en el bucket de Amazon S3 depende de la cantidad de datos que
seleccione la instrucción SELECT INTO OUTFILE S3 y del umbral de tamaño de archivo de Aurora
MySQL. Por defecto, el umbral de tamaño de archivo es 6 gigabytes (GB). Si el volumen de los datos
seleccionados por la instrucción es inferior al umbral de tamaño de archivo, se creará un solo archivo. En
caso contrario, se crearán varios. Las siguientes son otras consideraciones sobre los archivos que crea
esta instrucción:
• Aurora MySQL garantiza que las filas de los archivos de datos no se dividan entre archivos. Si hay varios
archivos, normalmente el tamaño de cada uno, salvo el último, será cercano al umbral de tamaño de
archivo. Sin embargo, en ocasiones, mantenerse por debajo del umbral de tamaño de archivo implicaría
dividir una fila entre dos archivos. En tal caso, Aurora MySQL crea un archivo de datos que mantiene la
fila completa, pero que puede tener un tamaño superior al umbral.
• Cada instrucción SELECT de Aurora MySQL se ejecuta como transacción atómica, por lo que una
instrucción SELECT INTO OUTFILE S3 que seleccione un gran volumen de datos puede llevar un
tiempo considerable. Si la instrucción falla por cualquier motivo, puede ser necesario comenzar desde el
principio y ejecutarla de nuevo. Sin embargo, si la instrucción falla, los archivos ya cargados en Amazon
S3 permanecerán en el bucket de Amazon S3 especificado. Entonces puede utilizar otra instrucción para
cargar los datos faltantes en lugar de comenzar de nuevo desde el principio.
• Si el volumen de datos que se seleccionan es grande (más de 25 GB), es recomendable usar varias
instrucciones SELECT INTO OUTFILE S3 para guardar los datos en Amazon S3. Cada instrucción
debe seleccionar una parte distinta de los datos que se deben guardar y también debe especificar un
valor file_prefix distinto en el parámetro s3-uri al guardar los archivos de datos. La partición de
los datos seleccionados en varias instrucciones facilita la recuperación en caso de errores de ejecución,
ya que si se produce un error al ejecutarse una de las instrucciones, solo se deberá volver a seleccionar
y cargar en Amazon S3 una parte de los datos. El uso de múltiples instrucciones también ayuda a evitar
una transacción única prolongada, lo que puede mejorar el desempeño.
• Si se ejecutan varias instrucciones SELECT INTO OUTFILE S3 en paralelo con el mismo valor
de file_prefix en el parámetro s3-uri para seleccionar datos y cargarlos en Amazon S3, el
comportamiento resultante no está definido.
• Aurora MySQL no carga en Amazon S3 los metadatos, como el esquema de tablas y los metadatos de
archivos.

653
• En algunos casos puede ser necesario volver a ejecutar una consulta SELECT INTO OUTFILE S3, por
ejemplo para recuperarse de un error. En estos casos, deberá eliminar los archivos de datos que haya
en el bucket de Amazon S3 con el prefijo especificado en s3-uri o bien deberá especificar OVERWRITE
ON en la consulta SELECT INTO OUTFILE S3.
La instrucción SELECT INTO OUTFILE S3 devuelve el número de error y la respuesta habituales de

MySQL en caso de éxito o error de la operación. Si no tiene acceso al número de error y la respuesta de
MySQL, la forma más sencilla de determinar cuándo ha terminado la operación es especificar MANIFEST
ON en la instrucción. El archivo de manifiesto es el último archivo que escribe la instrucción. En otras
palabras, si existe el archivo de manifiesto, la instrucción ha terminado de ejecutarse.
Actualmente no existe un modo de observar el progreso de la instrucción SELECT INTO OUTFILE S3

mientras se ejecuta. Sin embargo, supongamos que va a cargar una gran cantidad de datos de Aurora
MySQL en Amazon S3 con esta instrucción y que conoce el volumen de los datos seleccionados. En tal
caso puede estimar el progreso observando la creación de los archivos de datos en Amazon S3.
Para ello partimos del hecho de que se crea un archivo de datos en el bucket de Amazon S3
aproximadamente por cada 6 GB de datos seleccionados por la instrucción. Dividiendo el volumen de los
datos seleccionados entre 6 GB se obtiene el número estimado de archivos de datos que se crean. Así
puede estimar el progreso de la instrucción observando el número de archivos cargados en Amazon S3
durante la ejecución.
Ejemplos
La instrucción siguiente selecciona todos los datos de la tabla employees y los guarda en un bucket de
Amazon S3 situado en una región distinta de la del clúster de base de datos Aurora MySQL. La instrucción
crea archivos de datos en los que cada campo termina con un carácter coma (,) y cada fila termina con un
carácter de nueva línea (\n). La instrucción devuelve un error si en el bucket de Amazon S3 especificado
ya existen archivos con el prefijo especificado en sample_employee_data.
SELECT * FROM employees INTO OUTFILE S3 's3-us-west-2://aurora-select-into-s3-pdx/

sample_employee_data'
LINES TERMINATED BY '\n';
Amazon S3 situado en la misma región que el clúster de base de datos Aurora MySQL. La instrucción
crea archivos de datos en los que cada campo termina con un carácter coma (,) y cada fila termina
con un carácter de nueva línea (\n), y también crea un archivo de manifiesto. La instrucción devuelve
un error si en el bucket de Amazon S3 especificado ya existen archivos con el prefijo especificado en
sample_employee_data.
SELECT * FROM employees INTO OUTFILE S3 's3://aurora-select-into-s3-pdx/

MANIFEST ON;
Amazon S3 situado en una región distinta de la del clúster de base de datos Aurora. La instrucción crea
archivos de datos en los que cada campo termina con un carácter coma (,) y cada fila termina con un
carácter de nueva línea (\n). La instrucción sobrescribe los archivos que puedan existir en el bucket de
sample_employee_data con el prefijo especificado en Amazon S3.
SELECT * FROM employees INTO OUTFILE S3 's3-us-west-2://aurora-select-into-s3-pdx/


654
Invocación de una función Lambda desde Aurora MySQL

OVERWRITE ON;
Amazon S3 situado en la misma región que el clúster de base de datos Aurora MySQL. La instrucción
crea archivos de datos en los que cada campo termina con un carácter coma (,) y cada fila termina con
un carácter de nueva línea (\n), y también crea un archivo de manifiesto. La instrucción sobrescribe los
archivos que puedan existir en el bucket de sample_employee_data con el prefijo especificado en
Amazon S3.
SELECT * FROM employees INTO OUTFILE S3 's3://aurora-select-into-s3-pdx/

MANIFEST ON
OVERWRITE ON;
Temas relacionados
• Carga de datos en un clúster de base de datos Amazon Aurora MySQL desde archivos de texto en un
bucket de Amazon S3 (p. 641)
Invocación de una función de Lambda desde un

clúster de base de datos Amazon Aurora MySQL
Puede invocar una función AWS Lambda desde un clúster de base de datos Compatibilidad de Amazon
Aurora con MySQL con una función nativa o un procedimiento almacenado. Antes de invocar una función
Lambda desde Aurora MySQL, el clúster de base de datos Aurora debe tener acceso a Lambda.
A partir de la versión 1.16 de Aurora MySQL, el uso de un procedimiento almacenado está obsoleto. Para
los clústeres compatibles con Aurora MySQL 5.6 que usan la versión 1.16 y posterior de Aurora MySQL,
recomendamos encarecidamente el uso de una función nativa de Aurora MySQL.
Para los clústeres compatibles con Aurora MySQL 5.7, actualmente solo está disponible la técnica de
procedimientos almacenados.
Temas
• Acceso de Aurora a Lambda (p. 655)
• Invocación de una función de Lambda con una función nativa de Aurora MySQL (p. 656)
• Invocación de una función de Lambda con un procedimiento almacenado de Aurora MySQL (p. 658)
Acceso de Aurora a Lambda

Para poder invocar funciones Lambda desde Aurora MySQL, primero debe dar al clúster de base de datos
Aurora MySQL permiso para que obtenga acceso a Lambda.
Para conceder a Aurora MySQL acceso a Lambda
1. Cree una política de AWS Identity and Access Management (IAM) que asigne los permisos que
permiten que su clúster de base de datos Aurora MySQL invoque las funciones Lambda. Para

655
obtener instrucciones, consulte Creación de una política de IAM para acceder a los recursos de AWS
Lambda (p. 632).
acceder a los recursos de AWS Lambda (p. 632) al nuevo rol de IAM. Para obtener instrucciones,
AWS (p. 635).
3. Configure el parámetro de clúster de base de datos aws_default_lambda_role con el nombre de
recurso de Amazon (ARN) del nuevo rol de IAM.
Si el clúster es parte de una base de datos global de Aurora, aplique la misma configuración a cada
clúster de Aurora en la base de datos global.
4. Para permitir la invocación de funciones Aurora MySQL a los usuarios de base de datos un clúster de
base de datos Lambda, asocie el rol que creó en Creación de un rol de IAM que permita a Amazon
Aurora acceder a los servicios de AWS (p. 635) con el clúster. Para obtener información acerca de
cómo asociar un rol de IAM con un clúster de base de datos, consulte Asociación de un rol de IAM con
un clúster de base de datos Amazon Aurora MySQL (p. 636).
Si el clúster es parte de una base de datos global de Aurora, asocie el rol con cada clúster de Aurora
en la base de datos global.
5. Configure el clúster de base de datos Aurora MySQL para permitir conexiones salientes hacia
Lambda. Para obtener instrucciones, consulte Habilitación de la comunicación de red de Amazon
Si el clúster es parte de una base de datos global de Aurora, habilite las conexiones de salida para
cada clúster de Aurora en la base de datos global.
Invocación de una función de Lambda con una función nativa de

Aurora MySQL
Note
Puede llamar a las funciones nativas lambda_sync y lambda_async cuando utilice la versión
1.16 y posterior de Aurora MySQL. Para obtener más información acerca de las versiones de
Aurora MySQL, consulte Actualizaciones del motor de base de datos para Amazon Aurora
MySQL (p. 695).
Puede invocar una función de AWS Lambda desde un clúster de base de datos Aurora MySQL llamando
a las funciones nativas lambda_sync y lambda_async. Este método puede ser útil cuando se desea
integrar una base de datos que se ejecuta en Aurora MySQL con otros servicios de AWS. Por ejemplo, es
posible que desee enviar una notificación mediante Amazon Simple Notification Service (Amazon SNS)
siempre que se inserte una fila en una tabla específica de una base de datos.
Trabajo con funciones nativas para invocar una función de Lambda

Las funciones lambda_sync y lambda_async son funciones nativas integradas que invocan una función
de Lambda de forma síncrona o asíncrona. Cuando necesite saber el resultado de la ejecución de la
función invocada antes de realizar ninguna otra acción, use la función síncrona lambda_sync. Cuando no
necesite saber el resultado de la ejecución antes de realizar ninguna otra acción, use la función asíncrona
lambda_async.
Al usuario que invoca una función nativa se le debe conceder el privilegio INVOKE LAMBDA. Para
conceder este privilegio a un usuario, conéctese a la instancia de base de datos como usuario maestro y
ejecute la siguiente instrucción.

656
GRANT INVOKE LAMBDA ON *.* TO user@domain-or-ip-address
Puede revocar este privilegio ejecutando la siguiente instrucción.
REVOKE INVOKE LAMBDA ON *.* FROM user@domain-or-ip-address
Sintaxis de la función lambda_sync
Puede invocar la función lambda_sync de forma síncrona con el tipo de invocación RequestResponse.
La función devuelve el resultado de la invocación de Lambda en una carga JSON. La función presenta la
siguiente sintaxis.
lambda_sync (
lambda_function_ARN,
JSON_payload
)
Note
Puede usar disparadores para llamar Lambda en instrucciones de modificación de datos.

Recuerde que los disparadores no se ejecutan una vez por instrucción SQL, sino una vez por
fila modificada, de una en una. La ejecución de disparadores es sincrónica y la instrucción de
modificación de datos no devolverá el control hasta que se complete la ejecución del disparador.
Tenga cuidado al invocar una función de AWS Lambda desde disparadores de tablas que tengan
mucho tráfico de escritura. Los disparadores INSERT, UPDATE y DELETE se activan por filas.
Una gran carga de trabajo de escritura en una tabla con disparadores INSERT, UPDATE o
DELETE genera un gran número de llamadas a la función de AWS Lambda.
Parámetros de la función lambda_sync
La función lambda_sync tiene los siguientes parámetros.
lambda_function_ARN
El Nombre de recurso de Amazon (ARN) de la función Lambda que se va a invocar.

JSON_payload
La carga de la función de Lambda invocada, en formato JSON.
Note
Aurora MySQL no admite el análisis de JSON. El análisis de JSON no es necesario si una función
de Lambda devuelve un valor atómico, como un número o una cadena.
Ejemplo de la función lambda_sync
La siguiente consulta basada en lambda_sync invoca la función de Lambda BasicTestLambda de

forma síncrona mediante la función ARN. La carga de la función es {"operation": "ping"}.
SELECT lambda_sync(

657
'arn:aws:lambda:us-east-1:868710585169:function:BasicTestLambda',
'{"operation": "ping"}');
Sintaxis de la función lambda_async
Puede invocar la función lambda_async de forma asíncrona con el tipo de invocación Event. La función
devuelve el resultado de la invocación de Lambda en una carga JSON. La función presenta la siguiente
sintaxis.
lambda_async (
JSON_payload
)
Parámetros de la función lambda_async
La función lambda_async tiene los siguientes parámetros.
lambda_function_ARN

JSON_payload
La carga de la función de Lambda invocada, en formato JSON.
Note
Aurora MySQL no admite el análisis de JSON. El análisis de JSON no es necesario si una función
de Lambda devuelve un valor atómico, como un número o una cadena.
Ejemplo de la función lambda_async
La siguiente consulta basada en lambda_async invoca la función de Lambda BasicTestLambda de

forma asíncrona mediante la función ARN. La carga de la función es {"operation": "ping"}.
SELECT lambda_async(
'arn:aws:lambda:us-east-1:868710585169:function:BasicTestLambda',
'{"operation": "ping"}');
Temas relacionados
• Guía para desarrolladores de AWS Lambda
Invocación de una función de Lambda con un procedimiento

almacenado de Aurora MySQL
Puede invocar una función de AWS Lambda desde un clúster de base de datos Aurora MySQL llamando
al procedimiento mysql.lambda_async. Este método puede ser útil cuando se desea integrar una base
de datos que se ejecuta en Aurora MySQL con otros servicios de AWS. Por ejemplo, es posible que desee

658
enviar una notificación mediante Amazon Simple Notification Service (Amazon SNS) siempre que se
inserte una fila en una tabla específica de una base de datos.
Consideraciones sobre la versión de la plataforma Aurora MySQL

En la versión 1.8 y posterior de Aurora MySQL, puede usar el método de función nativa en lugar de estos
procedimientos almacenados para invocar una función Lambda. A partir de la versión 1.16 de Amazon
Aurora, el procedimiento almacenado mysql.lambda_async está obsoleto. Si usa la versión 1.16 o
posterior de Aurora, recomendamos encarecidamente que trabaje con funciones Lambda nativas en su
lugar. Para obtener más información acerca de las funciones nativas, consulte Trabajo con funciones
nativas para invocar una función de Lambda (p. 656).
Actualmente, en Aurora MySQL 2.*, no puede usar la técnica de función nativa para invocar una función
Lambda. Para los clústeres compatibles con Aurora MySQL 5.7, use la técnica de procedimientos
almacenados descrita en la siguiente sección.
Uso del procedimiento mysql.lambda_async para invocar una función Lambda

El procedimiento mysql.lambda_async es un procedimiento almacenado integrado que invoca una
función Lambda de forma asíncrona. Para utilizar este procedimiento, el usuario de la base de datos debe
tener privilegios de ejecución para el procedimiento almacenado mysql.lambda_async.
Sintaxis
El procedimiento mysql.lambda_async tiene la siguiente sintaxis.
CALL mysql.lambda_async (
lambda_function_input
)
Parámetros
El procedimiento mysql.lambda_async tiene los siguientes parámetros.
lambda_function_ARN

lambda_function_input
La cadena de entrada, en formato JSON, para la función Lambda invocada.
Ejemplos
Como práctica recomendada, es conveniente que encapsule las llamadas al procedimiento

mysql.lambda_async en un procedimiento almacenado que se pueda invocar desde distintos orígenes,
como los disparadores o el código del cliente. Esto puede ayudar a evitar los problemas de “discrepancia
de impedancia” y hacer que resulte más sencillo llamar a las funciones Lambda.
Note
Tenga cuidado al invocar una función de AWS Lambda desde disparadores de tablas que tengan
mucho tráfico de escritura. Los disparadores INSERT, UPDATE y DELETE se activan por filas.
Una gran carga de trabajo de escritura en una tabla con disparadores INSERT, UPDATE o
DELETE genera un gran número de llamadas a la función de AWS Lambda.
Aunque las llamadas al procedimiento mysql.lambda_async son asíncronas, los disparadores
son síncronos. Una instrucción que da como resultado un gran número de activaciones de

659
disparadores no espera a que finalice la llamada a la función de AWS Lambda, pero espera a que
finalicen los disparadores antes de devolver el control al cliente.
Example Ejemplo: Invocar una función de AWS Lambda para enviar correo electrónico
En el siguiente ejemplo se crea un procedimiento almacenado que puede llamarse desde el código de una
base de datos para enviar un mensaje de correo electrónico utilizando una función Lambda.
AWS Lambda Función
import boto3
ses = boto3.client('ses')
def SES_send_email(event, context):
return ses.send_email(
Source=event['email_from'],
Destination={
'ToAddresses': [
event['email_to'],
]
},
Message={
'Subject': {
'Data': event['email_subject']
},
'Body': {
'Text': {
'Data': event['email_body']
}
}
}
)
Procedimiento almacenado
DROP PROCEDURE IF EXISTS SES_send_email;

DELIMITER ;;
CREATE PROCEDURE SES_send_email(IN email_from VARCHAR(255),
IN email_to VARCHAR(255),
IN subject VARCHAR(255),
IN body TEXT) LANGUAGE SQL
BEGIN
CALL mysql.lambda_async(
'arn:aws:lambda:us-west-2:123456789012:function:SES_send_email',
CONCAT('{"email_to" : "', email_to,
'", "email_from" : "', email_from,
'", "email_subject" : "', subject,
'", "email_body" : "', body, '"}')
);
END
;;
DELIMITER ;
Llamada al procedimiento almacenado para invocar la función de AWS Lambda
mysql> call SES_send_email('example_from@amazon.com', 'example_to@amazon.com', 'Email

subject', 'Email content');

660
Example Ejemplo: Invocar una función de AWS Lambda para publicar un evento procedente de un
disparador
En el siguiente ejemplo se crea un procedimiento almacenado que publica un evento mediante Amazon
SNS. El código llama al procedimiento desde un disparador cuando se añade una fila a una tabla.
AWS Lambda Función
import boto3
sns = boto3.client('sns')
def SNS_publish_message(event, context):
return sns.publish(
TopicArn='arn:aws:sns:us-west-2:123456789012:Sample_Topic',
Message=event['message'],
Subject=event['subject'],
MessageStructure='string'
)
Procedimiento almacenado
DROP PROCEDURE IF EXISTS SNS_Publish_Message;

DELIMITER ;;
CREATE PROCEDURE SNS_Publish_Message (IN subject VARCHAR(255),
IN message TEXT) LANGUAGE SQL
BEGIN
CALL mysql.lambda_async('arn:aws:lambda:us-
west-2:123456789012:function:SNS_publish_message',
CONCAT('{ "subject" : "', subject,
'", "message" : "', message, '" }')
);
END
;;
DELIMITER ;
Tabla
CREATE TABLE 'Customer_Feedback' (

'id' int(11) NOT NULL AUTO_INCREMENT,
'customer_name' varchar(255) NOT NULL,
'customer_feedback' varchar(1024) NOT NULL,
PRIMARY KEY ('id')
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
Trigger
DELIMITER ;;
CREATE TRIGGER TR_Customer_Feedback_AI
AFTER INSERT ON Customer_Feedback
FOR EACH ROW
BEGIN
SELECT CONCAT('New customer feedback from ', NEW.customer_name), NEW.customer_feedback
INTO @subject, @feedback;
CALL SNS_Publish_Message(@subject, @feedback);
END
;;
DELIMITER ;

661
Publicación de registros de Aurora
MySQL en CloudWatch Logs
Inserción de una fila en la tabla para desencadenar la notificación
mysql> insert into Customer_Feedback (customer_name, customer_feedback) VALUES ('Sample

Customer', 'Good job guys!');
Temas relacionados
• Guía para desarrolladores de AWS Lambda
Publicación de registros de Amazon Aurora MySQL en

Amazon CloudWatch Logs
Puede configurar su clúster de base de datos Aurora MySQL para publicar datos de registros generales,
lentos, de auditoría y de errores en un grupo de registros en Amazon CloudWatch Logs. Con CloudWatch
Logs, puede realizar análisis en tiempo real de los datos de registro y utilizar CloudWatch para crear
alarmas y ver métricas. Puede utilizar CloudWatch Logs para almacenar los registros de registros en
almacenamiento de larga duración.
Para publicar logs en CloudWatch Logs, se deben habilitar los logs respectivos. Los logs de errores
están habilitados de forma predeterminada, pero debe habilitar explícitamente los demás tipos de logs.
Para obtener información acerca de habilitar registros en MySQL, consulte Selecting General Query and
Slow Query Log Output Destinations en la documentación de MySQL. Para obtener más información
acerca de cómo habilitar los registros de auditoría de Aurora MySQL, consulte Habilitar la auditoría
avanzada (p. 594).
Note
Tenga en cuenta lo siguiente:
• No puede publicar registros en CloudWatch Logs para la región China (Ningxia).

• Si la exportación de datos de log está deshabilitada, Aurora no elimina los grupos de logs
o flujos de logs. Si la exportación de datos de log está deshabilitada, los datos de log de
existentes seguirán disponibles en CloudWatch Logs, en función de la retención de logs y
seguirá incurriendo en gastos por los datos de log de auditoría almacenados. Puede eliminar
los flujos y los grupos de registros en la consola de CloudWatch Logs, la AWS CLI o la API de
CloudWatch Logs.
• Una forma alternativa de publicar los registros de auditoría en CloudWatch Logs consiste
en habilitar la auditoría avanzada y configurar el parámetro de base de datos nivel de
clúster server_audit_logs_upload en 1 El valor predeterminado para el parámetro
server_audit_logs_upload es 0.
Si usa este método alternativo, debe tener un rol de IAM para obtener acceso a CloudWatch
Logs y establecer el parámetro de nivel de clúster aws_default_logs_role en el ARN para
esta función. Para obtener información acerca de la creación del rol de , consulte Configuración
de roles de IAM para acceder a servicios de AWS (p. 630). Sin embargo, si tiene el rol
vinculado alservicio AWSServiceRoleForRDS, proporciona acceso a CloudWatch Logs y
anula cualquier función definida por el usuario. Para obtener información acerca de los roles
vinculados al servicio para Amazon RDS, consulte Uso de roles vinculados a servicios en
• Si no desea exportar logs de auditoría a CloudWatch Logs, asegúrese de que todos
los métodos de exportación de logs de auditoría estén deshabilitados. Estos métodos

662
son la Consola de administración de AWS, la AWS CLI, la API de RDS y el parámetro

server_audit_logs_upload.
• El procedimiento es ligeramente distinto para los clústeres de Aurora Serverless que el de
los clústeres aprovisionados. Los clústeres de Serverless cargan automáticamente todos
los tipos de registros que habilita a través de los parámetros de configuración. Por lo tanto,
habilita o deshabilita la carga de registros para clústeres de Serverless mediante la activación
y desactivación de diferentes tipos de registros en el grupo de parámetros de clústeres de
base de datos. No modifique la configuración del propio clúster a través de la Consola de
administración de AWS, la AWS CLI o la API de RDS. Para obtener información sobre la
habilitación de registros de MySQL para clústeres de Serverless, consulte Aurora Serverless y
grupos de parámetros (p. 106).
Consola
Puede publicar registros de Aurora MySQL para clústeres aprovisionados en CloudWatch Logs con la
consola.
Para publicar logs de Aurora MySQL desde la consola

3. Elija el clúster de base de datos de Aurora MySQL para el que desee publicar los datos de registro.
4. Para Actions (Acciones), elija Modify (Modificar).
5. En la sección Logs exports (Exportaciones de registros), elija los registros que desea comenzar a
publicar en CloudWatch Logs.
6. Elija Continue (Continuar), seguido de Modify DB Cluster (Modificar clúster de base de datos) en la
página de resumen.
AWS CLI
Puede publicar registros de Aurora MySQL para clústeres aprovisionados con la CLI de AWS. Para ello,
ejecute el comando modify-db-cluster de la AWS CLI con las siguientes opciones:
• --db-cluster-identifier: identificador de clúster de base de datos.

• --cloudwatch-logs-export-configuration: el ajuste de configuración para los tipos de registros
que habilitar para exportar a CloudWatch Logs para el clúster de base de datos.
También puede publicar registros de Aurora MySQL ejecutando uno de los siguientes comandos de la
AWS CLI:
• create-db-cluster
• restore-db-cluster-from-s3
• restore-db-cluster-from-snapshot
Ejecute uno de estos comandos de la AWS CLI con las siguientes opciones:
• --db-cluster-identifier: identificador de clúster de base de datos.

• --engine: el motor de base de datos.
• --enable-cloudwatch-logs-exports: el ajuste de configuración para los tipos de registros que
habilitar para exportar a CloudWatch Logs para el clúster de base de datos.

663
Podrían ser necesarias otras opciones en función del comando de la AWS CLI que se ejecute.
Example
El siguiente comando modifica un clúster de base de datos Aurora MySQL existente para publicar archivos
de registro en CloudWatch Logs.

--cloudwatch-logs-export-configuration '{"EnableLogTypes":
["error","general","slowquery","audit"]}'
Para Windows:

--cloudwatch-logs-export-configuration '{"EnableLogTypes":
["error","general","slowquery","audit"]}'
Example
El siguiente comando crea un clúster de base de datos Aurora MySQL para publicar archivos de registro
en CloudWatch Logs.

--engine aurora \
--enable-cloudwatch-logs-exports '["error","general","slowquery","audit"]'
Para Windows:

--engine aurora ^
--enable-cloudwatch-logs-exports '["error","general","slowquery","audit"]'
API de RDS
Puede publicar registros de Aurora MySQL para clústeres aprovisionados con la API de RDS. Para ello,
ejecute la acción ModifyDBCluster con las siguientes opciones:
• DBClusterIdentifier: identificador de clúster de base de datos.

• CloudwatchLogsExportConfiguration: el ajuste de configuración para los tipos de registros que
habilitar para exportar a CloudWatch Logs para el clúster de base de datos.
También puede publicar logs de Aurora MySQL con la API de RDS ejecutando una de las siguientes
acciones de API de RDS:
• CreateDBCluster

664
Modo lab de Aurora MySQL
• RestoreDBClusterFromS3
Ejecute la acción de la API de RDS con los siguientes parámetros:
• DBClusterIdentifier: identificador de clúster de base de datos.

• Engine: el motor de base de datos.
• EnableCloudwatchLogsExports: el ajuste de configuración para los tipos de registros que habilitar
para exportar a CloudWatch Logs para el clúster de base de datos.
Podrían ser necesarios otros parámetros en función del comando de la AWS CLI que ejecute.
Monitoreo de eventos de log en Amazon CloudWatch

Después de habilitar los eventos de registro de Aurora MySQL, puede monitorizar los eventos en Amazon
CloudWatch Logs. Se crea un nuevo grupo de registros automáticamente para el clúster de base de datos
Aurora con el siguiente prefijo, donde cluster-name representa el nombre del clúster de base de datos y
log_type representa el tipo de registro.
/aws/rds/cluster/cluster-name/log_type
Por ejemplo, si configura la función de exportación para que incluya el log de consultas lentas para un
clúster de base de datos denominado mydbcluster, los datos de consultas lentas se almacenan en el
grupo de logs /aws/rds/cluster/mydbcluster/slowquery.
Todos los eventos de todas las instancias de base de datos en un clúster de base de datos se envían a un
grupo de logs utilizando flujos de logs distintos.
Si ya existe un grupo de registros con el nombre especificado, Aurora utilizará dicho grupo de registros
para exportar los datos de registros para el clúster de base de datos Aurora. Puede utilizar la configuración
automática, como AWS CloudFormation, para crear grupos de logs con periodos de retención de log
predefinidos, filtros de métricas y acceso de cliente. De lo contrario, se crea un nuevo grupo de registros de
forma automática con el periodo de retención de registros predeterminado, Never Expire (Nunca expira),
en CloudWatch Logs. Puede utilizar la consola de CloudWatch Logs, la AWS CLI o la API de CloudWatch
Logs para modificar el periodo de retención de registros. Para obtener más información sobre cómo
cambiar los periodos de retención de registro en CloudWatch Logs, consulte Cambiar la retención de datos
de registro en CloudWatch Logs.
Puede utilizar la consola de CloudWatch Logs, la AWS CLI o la API de CloudWatch Logs para buscar
información en los eventos de registro para un clúster de base de datos. Para obtener más información
sobre la búsqueda y el filtrado de datos de registro, consulte Búsqueda y filtrado de datos de registros.
Modo lab de Amazon Aurora MySQL

El modo lab de Aurora se utiliza para habilitar características de Aurora que están disponibles en la actual
versión de base de datos Aurora, pero que no están habilitadas de manera predeterminada. Aunque no
se recomienda el uso de características del modo lab de Aurora en los clústeres de bases de datos de
producción, puede utilizar el modo lab de Aurora para habilitar estas características para los clústeres de
base de datos sus entornos de desarrollo y prueba. Para obtener más información sobre las características
de Aurora que están disponibles cuando está habilitado el modo lab de Aurora, consulte Características del
modo lab de Aurora (p. 666).

665
Características del modo lab de Aurora
El parámetro aurora_lab_mode es un parámetro en el nivel de la instancia que se encuentra en el

grupo de parámetros predeterminado. El parámetro está establecido en 0 (deshabilitado) en el grupo
de parámetros predeterminado. Para habilitar el modo lab de Aurora, cree un grupo de parámetros
personalizado, establezca el parámetro aurora_lab_mode en 1 (habilitado) en el grupo de parámetros
personalizado y modifique la instancia principal o la réplica de Aurora para que utilice el grupo de
parámetros personalizado. Para obtener información acerca de cómo modificar un grupo de parámetros de
base de datos, consulte Modificación de parámetros de un grupo de parámetros de base de datos (p. 265).
Para obtener información acerca de los grupos de parámetros y Amazon Aurora, consulte Parámetros de
Características del modo lab de Aurora

En la siguiente tabla, se muestran las características de Aurora que están disponibles cuando se habilita
el modo lab de Aurora. Debe habilitar el modo lab de Aurora para poder utilizar estas características.
Para obtener más información acerca del modo lab de Aurora, consulte Modo lab de Amazon Aurora
MySQL (p. 665).
Característica Descripción
Agrupación en lotes de análisis La agrupación en lotes de análisis de Aurora

MySQL acelera significativamente las consultas en
memoria orientadas a análisis. Esta característica
aumenta el desempeño de los análisis completos
de tablas, los análisis completos de índices y
los análisis de rangos de índices mediante el
procesamiento por lotes.
Combinaciones hash Esta característica puede mejorar el desempeño

de las consultas si necesita unir una gran cantidad
de datos mediante equijoin. Para obtener más
información sobre cómo usar esta característica,
consulte Trabajo con combinaciones hash en
DDL rápida Esta característica permite ejecutar una operación

ALTER TABLE nombre_tabla ADD COLUMN
nombre_columna definición_columna de manera
casi instantánea. La operación se completa sin
que sea necesario copiar la tabla y sin que haya
un impacto material en otras instrucciones DML.
Dado que no consume almacenamiento temporal
para una copia de la tabla, las instrucciones DDL
resultan prácticas incluso para tablas grandes en
clases de instancias pequeñas. El DDL rápido solo
se admite actualmente para añadir columnas que
se puedan anular, sin un valor predeterminado, al
final de una tabla. Para obtener más información
sobre cómo usar esta característica, consulte
Modificación de las tablas de Amazon Aurora con
operaciones DDL rápidas (p. 564).
Contención de filas activas Esta característica mejora sustancialmente el

rendimiento de las cargas de trabajo, ya que
muchas transacciones compiten por filas en la
misma página. La mejora consiste en cambiar el
algoritmo de liberación de bloqueo que usa Aurora.

666
Prácticas recomendadas con Amazon Aurora MySQL
Prácticas recomendadas con Amazon Aurora

MySQL
En este tema se proporciona información acerca de las prácticas recomendadas y las opciones para usar o
migrar datos en un clúster de base de datos de Amazon Aurora MySQL.
Temas
• Determinar a qué instancia de base de datos está conectado (p. 667)
• Uso de instancias T2 (p. 667)
• Invocar una función de AWS Lambda (p. 668)
• Uso de la captura previa de clave asíncrona en Amazon Aurora (p. 669)
• Uso de esclavos de replicación con varios subprocesos en Amazon Aurora MySQL (p. 671)
• Uso de Amazon Aurora para escalar las lecturas de una base de datos de MySQL (p. 671)
• Uso de Amazon Aurora para la recuperación de desastres con sus bases de datos de
MySQL (p. 674)
• Migración de MySQL a Amazon Aurora MySQL con un tiempo de inactividad reducido (p. 675)
• Uso de transacciones de XA con Amazon Aurora MySQL (p. 675)
• Trabajo con combinaciones hash en Aurora MySQL (p. 675)
• Uso de claves externas en Aurora MySQL (p. 677)
• Temas relacionados (p. 677)
Determinar a qué instancia de base de datos está

conectado
Puede determinar a qué instancia de base de datos un clúster de base de datos Aurora MySQL está
conectado comprobando la variable global innodb_read_only, como se muestra en el siguiente
ejemplo.
SHOW GLOBAL VARIABLES LIKE 'innodb_read_only';
La variable innodb_read_only se ajusta en ON si se ha conectado a una réplica de Aurora y en OFF si

se ha conectado a la instancia principal.
Este método puede resultar útil si se desea añadir lógica al código de la aplicación para equilibrar la carga
de trabajo o para garantizar que una operación de escritura utilice la conexión correcta.
Uso de instancias T2
Las instancias de Amazon Aurora MySQL que usan las clases de instancia de base de datos
db.t2.small o db.t2.medium son más adecuadas para las aplicaciones que no admiten una carga
de trabajo elevada durante un periodo de tiempo largo. Las instancias T2 se han diseñado para ofrecer
un desempeño de referencia moderado y la capacidad de poder ampliarlo a un nivel considerablemente
superior si así lo exige la carga de trabajo. Están pensadas para las cargas de trabajo que no utilizan
toda la CPU con frecuencia o de forma continua, pero que de vez en cuando necesitan ampliar sus
procesos. Recomendamos que se usen solo las clases de instancia de base de datos db.t2.small y
db.t2.medium para los servidores de desarrollo y de pruebas, o para otros servidores que no se utilicen
para la producción. Para obtener información detallada acerca de las instancias T2, consulte Instancias T2.

667
Invocar una función de AWS Lambda
No habilite el esquema de rendimiento de MySQL en instancias T2 de Amazon Aurora MySQL. Si el

esquema de desempeño está habilitado, la instancia T2 podría quedarse sin memoria.
Cuando use una instancia T2 para la instancia principal o réplicas de Aurora de un clúster de base de
datos de Aurora MySQL, le recomendamos lo siguiente:
• Si usa una instancia T2 como clase de instancia de base de datos en un clúster de base de datos, es
aconsejable que todas las instancias de ese clúster de base de datos usen la misma clase de instancia
de base de datos. Por ejemplo, si usa db.t2.medium para la instancia principal, es recomendable que
también use db.t2.medium para las réplicas de Aurora.
• Monitorice el saldo de crédito de su CPU (CPUCreditBalance) para asegurarse de que está en un
nivel sostenible. Es decir, que los créditos de la CPU se están acumulando a la misma velocidad a la que
se usan.
Cuando se agotan los créditos de CPU correspondientes a una instancia, se percibe una disminución
inmediata en la CPU disponible y un incremento en la latencia de lectura y escritura de la instancia. Esta
situación provoca una grave reducción del desempeño general de la instancia.
Si el saldo de crédito de la CPU no está en un nivel sostenible, es recomendable que modifique la

instancia de base de datos para que use una de las clases de instancia de base de datos R3 disponibles
(escalado del cálculo).
Para obtener más información acerca de las métricas de monitorización, consulte Monitorización de las
métricas de un clúster de base de datos Amazon Aurora (p. 384).
• Monitorice el retardo de las réplicas (AuroraReplicaLag) entre la instancia principal y las réplicas de
Aurora en su clúster de base de datos de Aurora MySQL.
Si una réplica de Aurora se queda sin créditos de CPU antes que la instancia principal, el retardo tras la
instancia principal provoca que la réplica de Aurora se reinicie con frecuencia. Este resultado es habitual
si una aplicación mantiene una carga elevada de operaciones de lectura distribuidas entre las réplicas
de Aurora en un clúster de base de datos de Aurora MySQL mientras la instancia principal tiene una
carga mínima de operaciones de escritura.
Si ve un aumento sostenido del retardo de las réplicas, asegúrese de que no se está agotando el saldo
de crédito de la CPU para las réplicas de Aurora en su clúster de base de datos.
Si el saldo de créditos de CPU no está en un nivel sostenible, es recomendable que modifique

la instancia de base de datos para que use una de las clases de instancia de base de datos R3
compatibles (escalado del cálculo).
• Mantenga el número de inserciones por transacción por debajo de 1 millón para los clústeres de base de
datos que tengan habilitado el registro binario.
Si el grupo de parámetros de su clúster de base de datos tiene el parámetro binlog_format definido

en un valor distinto de OFF, dicho clúster de base de datos puede experimentar condiciones de falta de
memoria si recibe transacciones que contengan más de 1 millón de filas para insertar. Puede monitorizar
la métrica de la memoria que se puede liberar (FreeableMemory) para determinar si su clúster de
base de datos se está quedando sin memoria. Luego puede comprobar la métrica de operaciones de
escritura (VolumeWriteIOPS) para ver si la instancia principal recibe una carga pesada de operaciones
de escritura. En ese caso, es recomendable que actualice su aplicación para limitar el número de
inserciones de una transacción a menos de 1 millón o que modifique la instancia para que utilice una de
las clases de instancia de base de datos R3 compatibles (escalado del cálculo).
Invocar una función de AWS Lambda

Si utiliza Amazon Aurora versión 1.16 o posterior, es recomendable que utilice las funciones nativas
lambda_sync y lambda_async para invocar funciones de Lambda.
668
Uso de la captura previa de clave asíncrona
Si utiliza el procedimiento obsoleto mysql.lambda_async, es recomendable integrar las llamadas

al procedimiento mysql.lambda_async en un procedimiento almacenado. Puede llamar a este
procedimiento almacenado desde distintos orígenes, como los disparadores o el código cliente.
Este método puede ayudar a evitar los problemas de discrepancia de la impedancia y facilitar a los
programadores de bases de datos la invocación de las funciones de Lambda.
Para obtener más información acerca de la invocación de funciones de Lambda desde Amazon Aurora,
consulte Invocación de una función de Lambda desde un clúster de base de datos Amazon Aurora
MySQL (p. 655).
Uso de la captura previa de clave asíncrona en

Amazon Aurora
Note
La característica de captura previa de clave asíncrona (AKP) está disponible para la versión 1.15
de Amazon Aurora MySQL y versiones posteriores. Para obtener más información acerca de las
versiones de Aurora MySQL, consulte Actualizaciones del motor de base de datos para Amazon
Amazon Aurora puede usar la AKP para mejorar el desempeño de las consultas que unen las tablas a
través de los índices. Esta característica mejora el desempeño al prever las filas necesarias para ejecutar
consultas en las que una consulta JOIN requiere el uso del algoritmo de combinación Batched Key Access
(BKA) y las características de optimización Multi-Range Read (MRR). Para obtener más información
acerca de BKA y MRR, consulte Block Nested-Loop and Batched Key Access Joins y Multi-Range Read
Optimization en la documentación de MySQL.
Para sacar máximo partido de la característica AKP, una consulta debe utilizar BKA y MRR. Por lo general,
dicho tipo de consulta se produce cuando la cláusula JOIN de una consulta utiliza un índice secundario,
pero requiere también algunas columnas del índice primario. Por ejemplo, puede usar la AKP cuando una
cláusula JOIN represente a un equijoin en los valores de índice entre una tabla exterior pequeña y una
interior grande, y el índice sea sumamente selectivo en la tabla grande. AKP trabaja conjuntamente con
BKA y MRR para llevar a cabo una búsqueda del índice secundario al primario durante la evaluación de
la cláusula JOIN. AKP identifica las filas necesarias para ejecutar la consulta durante la evaluación de la
cláusula JOIN. Seguidamente, utiliza un subproceso en segundo plano para cargar de manera asíncrona
las páginas que contienen dichas filas en la memoria antes de ejecutar la consulta.
Habilitación de la captura previa de clave asíncrona

Para habilitar la característica de AKP, establezca la configuración aurora_use_key_prefetch,
una variable de MySQL Server, en on. De forma predeterminada, este valor se establece en on.
No obstante, AKP no podrá habilitarse hasta que no habilite el algoritmo de combinación BKA y
deshabilite la característica MRR basada en el costo. Para ello, debe ajustar los valores siguientes de
optimizer_switch, una variable de MySQL Server:
• Establezca batched_key_access en on. Este valor controla el uso del algoritmo de combinación BKA.
De forma predeterminada, este valor se establece en off.
• Establezca mrr_cost_based en off. Este valor controla el uso de la característica MRR basada en el
costo. De forma predeterminada, este valor se establece en on.
En la actualidad, puede configurar estos valores únicamente en el nivel de sesión. El siguiente ejemplo
ilustra cómo configurar estos valores a fin de habilitar AKP para la sesión actual ejecutando las
instrucciones SET.

669
Uso de la captura previa de clave asíncrona
mysql> set @@session.aurora_use_key_prefetch=on;

mysql> set @@session.optimizer_switch='batched_key_access=on,mrr_cost_based=off';
Del mismo modo, puede usar las instrucciones SET para deshabilitar AKP y el algoritmo de combinación
BKA, y volver a habilitar la característica MRR basada en el costo para la sesión actual, como se muestra
en el ejemplo siguiente.
mysql> set @@session.aurora_use_key_prefetch=off;

mysql> set @@session.optimizer_switch='batched_key_access=off,mrr_cost_based=on';
Para obtener más información acerca de los cambios del optimizador batched_key_access y
mrr_cost_based, consulte Switchable Optimizations en la documentación de MySQL.
Optimización de consultas para la captura previa de clave

asíncrona
Puede confirmar si una consulta puede beneficiarse de la característica AKP. Para ello, utilice la
instrucción EXPLAIN con la palabra clave EXTENDED con el fin de perfilar la consulta antes de ejecutarla.
La instrucción EXPLAIN ofrece información acerca del plan de ejecución que se va a utilizar para una
consulta especificada.
En el resultado de la instrucción EXPLAIN, la columna Extra describe información adicional que se

incluye con el plan de ejecución. Si la característica AKP se aplica a una tabla que se ha utilizado en la
consulta, esta tabla incluye uno de los siguientes valores:
• Using Key Prefetching

• Using join buffer (Batched Key Access with Key Prefetching)
En el siguiente ejemplo se muestra el uso de EXPLAIN con EXTENDED para ver el plan de ejecución de
una consulta que puede beneficiarse de AKP.
mysql> explain extended select sql_no_cache

-> ps_partkey,
-> sum(ps_supplycost * ps_availqty) as value
-> from
-> partsupp,
-> supplier,
-> nation
-> where
-> ps_suppkey = s_suppkey
-> and s_nationkey = n_nationkey
-> and n_name = 'ETHIOPIA'
-> group by
-> ps_partkey having
-> sum(ps_supplycost * ps_availqty) > (
-> select
-> sum(ps_supplycost * ps_availqty) * 0.0000003333
-> from
-> partsupp,
-> supplier,
-> nation
-> where
-> ps_suppkey = s_suppkey
-> and s_nationkey = n_nationkey
-> and n_name = 'ETHIOPIA'
-> )

670
Uso de esclavos de replicación con varios
subprocesos en Amazon Aurora MySQL
-> order by
-> value desc;
+----+-------------+----------+------+-----------------------+---------------
+---------+----------------------------------+------+----------
+-------------------------------------------------------------+
| id | select_type | table | type | possible_keys | key | key_len |
ref | rows | filtered | Extra
|
+----+-------------+----------+------+-----------------------+---------------
+---------+----------------------------------+------+----------
+-------------------------------------------------------------+
| 1 | PRIMARY | nation | ALL | PRIMARY | NULL | NULL |
NULL | 25 | 100.00 | Using where; Using temporary; Using
filesort |
| 1 | PRIMARY | supplier | ref | PRIMARY,i_s_nationkey | i_s_nationkey | 5 |
dbt3_scale_10.nation.n_nationkey | 2057 | 100.00 | Using index
|
| 1 | PRIMARY | partsupp | ref | i_ps_suppkey | i_ps_suppkey | 4 |
dbt3_scale_10.supplier.s_suppkey | 42 | 100.00 | Using join buffer (Batched Key Access
with Key Prefetching) |
| 2 | SUBQUERY | nation | ALL | PRIMARY | NULL | NULL |
NULL | 25 | 100.00 | Using where
|
| 2 | SUBQUERY | supplier | ref | PRIMARY,i_s_nationkey | i_s_nationkey | 5 |
dbt3_scale_10.nation.n_nationkey | 2057 | 100.00 | Using index
|
| 2 | SUBQUERY | partsupp | ref | i_ps_suppkey | i_ps_suppkey | 4 |
dbt3_scale_10.supplier.s_suppkey | 42 | 100.00 | Using join buffer (Batched Key Access
with Key Prefetching) |
+----+-------------+----------+------+-----------------------+---------------
+---------+----------------------------------+------+----------
+-------------------------------------------------------------+
6 rows in set, 1 warning (0.00 sec)
Para obtener más información acerca del formato de salida ampliado EXPLAIN, consulte Extended
EXPLAIN Output Format en la documentación de productos de MySQL.
Uso de esclavos de replicación con varios

subprocesos en Amazon Aurora MySQL
De manera predeterminada, Aurora usa la replicación con un solo subproceso cuando se utiliza un clúster
de base de datos Aurora MySQL como esclavo de la replicación. Aunque Amazon Aurora no prohíbe la
replicación con varios subprocesos, Aurora MySQL ha heredado de MySQL varios problemas relativos a
dicha replicación con varios subprocesos. No es recomendable usar la replicación con varios subprocesos
en entornos de producción. Si la usa, es aconsejable que realice pruebas exhaustivas.
Para obtener más información acerca del uso de la replicación en Amazon Aurora, consulte Replicación
con Amazon Aurora (p. 48).
Uso de Amazon Aurora para escalar las lecturas de

una base de datos de MySQL
Puede usar Amazon Aurora con su instancia de base de datos MySQL para aprovechar las capacidades
de escalado de lectura de Amazon Aurora y ampliar la carga de trabajo de lectura para su instancia de
base de datos MySQL. Si desea usar Aurora para escalar la instancia de base de datos MySQL, cree un
clúster de base de datos Amazon Aurora MySQL y conviértalo en el esclavo de replicación de la instancia
de base de datos MySQL. Esto es válido para una instancia de base de datos MySQL en Amazon RDS o
para una base de datos MySQL que se ejecute fuera de Amazon RDS.

671
Uso de Amazon Aurora para escalar las
lecturas de una base de datos de MySQL
Para obtener más información acerca de la creación de un clúster de base de datos Amazon Aurora,
consulte Creación de un clúster de base de datos de Amazon Aurora (p. 85).
Cuando configure la replicación entre su instancia de base de datos MySQL y su clúster de base de datos
de Amazon Aurora, asegúrese de seguir estas directrices:
• Use la dirección del punto de enlace del clúster de base de datos Amazon Aurora cuando haga
referencia a su clúster de base de datos Amazon Aurora MySQL. Si se produce una conmutación por
error, la réplica de Aurora que se asciende a instancia principal del clúster de base de datos Aurora
MySQL seguirá usando la dirección del punto de enlace del clúster de base de datos.
• Mantenga los binlogs en la instancia maestra hasta que haya comprobado que se han aplicado en
la réplica de Aurora. Este mantenimiento garantiza que se puede restaurar la instancia maestra si se
produce un error.
Important
Si usa la replicación autoadministrada, será responsable de monitorizar y resolver los problemas

de replicación que se pueden producir. Para obtener más información, consulte Diagnóstico y
resolución de retardos entre réplicas de lectura (p. 896).
Note
Los permisos requeridos para comenzar la replicación en un clúster de base de datos Amazon
Aurora MySQL están restringidos y no están disponibles para su usuario maestro de Amazon
RDS. Por este motivo, debe usar los procedimientos mysql_rds_set_external_master y
mysql_rds_start_replication de Amazon RDS para configurar la replicación entre su clúster de
base de datos de Amazon Aurora MySQL y su instancia de base de datos MySQL.
Comenzar la replicación entre una instancia maestra externa y

una instancia de base de datos MySQL en Amazon RDS
1. Configure la instancia de base de datos MySQL de origen como de solo lectura:
mysql> FLUSH TABLES WITH READ LOCK;

mysql> SET GLOBAL read_only = ON;
2. Ejecute el comando SHOW MASTER STATUS en la instancia de base de datos MySQL para determinar
la ubicación del binlog. Se recibe un resultado similar al del siguiente ejemplo:
File Position
------------------------------------
mysql-bin-changelog.000031 107
------------------------------------
3. Copie la base de datos la instancia de base de datos MySQL externa en el clúster de base de datos
Amazon Aurora MySQL usando mysqldump. Para bases de datos muy grandes, recomendamos usar el
procedimiento de Importación de datos a una instancia de base de datos MySQL o MariaDB en Amazon
RDS con tiempo de inactividad reducido en la Guía del usuario de Amazon Relational Database Service.
mysqldump \
--databases <database_name> \
--single-transaction \
--compress \

672
Uso de Amazon Aurora para escalar las
lecturas de una base de datos de MySQL
--order-by-primary \
-u <local_user> \
-p <local_password> | mysql \
--host aurora_cluster_endpoint_address \
--port 3306 \
-u <RDS_user_name> \
-p <RDS_password>
Para Windows:
mysqldump ^
--databases <database_name> ^
--single-transaction ^
--compress ^
--order-by-primary ^
-u <local_user> ^
-p <local_password> | mysql ^
--host aurora_cluster_endpoint_address ^
--port 3306 ^
-u <RDS_user_name> ^
-p <RDS_password>
Note
Asegúrese de que no haya ningún espacio entre la opción -p y la contraseña que haya escrito.
Use las opciones --host, --user (-u), --port y -p del comando mysql para especificar el nombre
de host, el nombre de usuario, el puerto y la contraseña para conectarse a su clúster de base de datos
Aurora. El nombre de host es el nombre DNS del punto de enlace del clúster de base de datos Amazon
Aurora, por ejemplo, mydbcluster.cluster-123456789012.us-east-1.rds.amazonaws.com.
Puede encontrar el valor del punto de enlace en los detalles del clúster en la consola de administración
de Amazon RDS.
4. Haga que la instancia de base de datos MySQL de origen vuelva a admitir la escritura:
mysql> SET GLOBAL read_only = OFF;

mysql> UNLOCK TABLES;
Para obtener más información acerca de la creación de copias de seguridad para el uso con la
replicación, consulte Backing Up a Master or Slave by Making It Read Only en la documentación de
MySQL.
5. En la consola de administración de Amazon RDS, añada la dirección IP del servidor que aloja la base de
datos MySQL de origen al grupo de seguridad de VPC para el clúster de base de datos Amazon Aurora.
Para obtener más información acerca de la modificación de un grupo de seguridad de VPC, consulte
Grupos de seguridad de su VPC en la Guía del usuario de Amazon Virtual Private Cloud.
Es posible que también necesite configurar su red local para permitir las conexiones desde la dirección
IP de su clúster de base de datos de Amazon Aurora con el fin de que se pueda comunicar con la
instancia de MySQL de origen. Para encontrar la dirección IP del clúster de base de datos Amazon
Aurora, use el comando host.
host <aurora_endpoint_address>
El nombre de host es el nombre DNS del punto de enlace del clúster de base de datos Amazon Aurora.
6. Utilice el cliente que prefiera para conectarse a la instancia de MySQL externa y cree un usuario de
MySQL que se usará para la replicación. Esta cuenta se usa únicamente para la replicación y debe
estar limitada a su dominio para mejorar la seguridad. A continuación se muestra un ejemplo.
673
Uso de Amazon Aurora para la recuperación de
desastres con sus bases de datos de MySQL
CREATE USER 'repl_user'@'mydomain.com' IDENTIFIED BY '<password>';
7. Para la instancia de MySQL externa, conceda a REPLICATION CLIENT y a REPLICATION SLAVE

privilegios para el usuario de replicación. Por ejemplo, para conceder los privilegios REPLICATION
CLIENT y REPLICATION SLAVE en todas las bases de datos al usuario "repl_user" del dominio,
ejecute el siguiente comando.
GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'mydomain.com'

IDENTIFIED BY '<password>';
8. Tome una instantánea manual del clúster de base de datos de Aurora MySQL para que sea el esclavo
de la replicación antes de configurar la replicación. Si tiene que restablecer la replicación con el clúster
de base de datos como esclavo de replicación, puede restaurar el clúster de base de datos Aurora
MySQL desde esta instantánea en lugar de tener que importar los datos desde su instancia de base de
datos MySQL en un nuevo clúster de base de datos Aurora MySQL.
9. Convierta el clúster de base de datos de Amazon Aurora DB en la réplica. Conéctese al clúster de
base de datos de Amazon Aurora como usuario maestro e identifique la base de datos origen de
MySQL como maestro de replicación usando el procedimiento mysql_rds_set_external_master. Use el
nombre del archivo de registro maestro y la posición del registro maestro que determinó en el paso 2. A
CALL mysql.rds_set_external_master ('mymasterserver.mydomain.com', 3306,

10.En el clúster de base de datos de Amazon Aurora, ejecute el procedimiento mysql_rds_start_replication

para comenzar la replicación.
Una vez que haya establecido la replicación entre su instancia de base de datos MySQL de origen y su
clúster de base de datos Amazon Aurora, podrá añadir réplicas de Aurora a su clúster de base de datos
Amazon Aurora. A continuación, puede conectarse a las réplicas de Aurora para escalar la lectura de sus
datos. Para obtener más información acerca de la creación de una réplica de Aurora, consulte Adición de
réplicas de Aurora a un clúster de base de datos (p. 254).
Uso de Amazon Aurora para la recuperación de

desastres con sus bases de datos de MySQL
Puede usar Amazon Aurora con su instancia de base de datos MySQL para crear un backup fuera del sitio
para la recuperación de desastres. Si desea usar Aurora para la recuperación de desastres de su instancia
de base de datos MySQL, cree un clúster de base de datos Amazon Aurora y conviértalo en el esclavo de
replicación de su instancia de base de datos MySQL. Esto es válido para una instancia de base de datos
MySQL en Amazon RDS o para una base de datos MySQL que se ejecute fuera de Amazon RDS.
Important
Cuando configure la replicación entre una instancia de base de datos MySQL y un clúster de base
de datos Amazon Aurora MySQL, debe monitorizar la replicación para asegurarse de que sigue
estando en un estado correcto y repararla si es necesario.
Para obtener instrucciones acerca del modo de crear un clúster de base de datos Amazon Aurora
MySQL y convertirlo en un esclavo de replicación de su instancia de base de datos MySQL, siga el
procedimiento que se describe en Uso de Amazon Aurora para escalar las lecturas de una base de datos
de MySQL (p. 671).

674
Migración de MySQL a Amazon Aurora
MySQL con un tiempo de inactividad reducido
Migración de MySQL a Amazon Aurora MySQL con un

tiempo de inactividad reducido
Al importar datos desde una base de datos de MySQL que admita una aplicación en directo a un clúster
de base de datos de Amazon Aurora MySQL, puede que desee reducir la cantidad de tiempo que se
interrumpe el servicio mientras se produce la migración. Para ello, puede usar el procedimiento de
Importación de datos a una instancia de base de datos MySQL o MariaDB en Amazon RDS con tiempo de
inactividad reducido en la Guía del usuario de Amazon Relational Database Service. Este procedimiento
puede resultar especialmente útil al trabajar con una base de datos de gran tamaño. Puede usar dicho
procedimiento para reducir el costo de la importación, ya que minimiza la cantidad de datos que se
transfieren a AWS por la red.
El procedimiento muestra los pasos necesarios para transferir una copia de los datos de la base de datos
a una instancia Amazon EC2; e importar los datos en una nueva instancia de base de datos MySQL en
Amazon RDS. Dado que Amazon Aurora es compatible con MySQL, puede usar un clúster de base de
datos Amazon Aurora para la instancia de base de datos MySQL en Amazon RDS de destino.
Uso de transacciones de XA con Amazon Aurora

MySQL
No es recomendable usar transacciones de eXtended Architecture (XA) con Aurora MySQL, ya que
pueden provocar tiempos de recuperación prolongados si la transacción de XA se encuentra en el estado
PREPARED. Si debe usar transacciones de XA con Aurora MySQL, siga estas prácticas recomendadas:
• No deje ninguna transacción de XA abierta en el estado PREPARED.

• Mantenga las transacciones de XA tan pequeñas como sea posible.
Para obtener más información acerca del uso de transacciones de XA con MySQL, consulte XA
Transactions en la documentación de MySQL.
Trabajo con combinaciones hash en Aurora MySQL

Si necesita unir una gran cantidad de datos mediante equijoin, una combinación hash puede mejorar el
desempeño de las consultas. Puede habilitar las combinaciones hash para Aurora MySQL.
Una columna de combinación hash puede ser cualquier expresión compleja. En una columna de
combinación hash puede realizar comparaciones entre distintos tipos de datos de las formas siguientes:
• Puede comparar cualquier cosa en la categoría de tipos de datos numéricos precisos, como int,
bigint, numeric y bit.
• Puede comparar cualquier cosa en la categoría de tipos de datos numéricos aproximados, como float
y double.
• Puede comparar elementos en distintos tipos de cadena que tengan el mismo conjunto de caracteres y
la misma intercalación.
• Puede comparar elementos con tipos de datos de marca de fecha y hora si los tipos son los mismos.
Note
Los tipos de datos de categorías distintas no se pueden comparar.
Las siguientes restricciones se aplican a las combinaciones hash de Aurora MySQL:
• No se admiten las combinaciones externas de izquierda a derecha.

675
Trabajo con combinaciones hash
• No se admiten las semicombinaciones, como las subconsultas, a no ser que las subconsultas se
materialicen primero.
• No se admiten las actualizaciones o supresiones de varias tablas.
Note
Se admiten las actualizaciones o supresiones de una sola tabla.

• Las columnas de tipos de datos especiales y BLOB no pueden ser columnas de unión en una
combinación hash.
Habilitación de las combinaciones hash

Para habilitar las combinaciones hash, establezca optimizer_switch, una variable de MySQL Server,
en on. El parámetro optimizer_switch está configurado para las combinaciones hash on de forma
predeterminada. En el siguiente ejemplo se ilustra cómo habilitar las combinaciones hash.
mysql> SET optimizer_switch='hash_join=on';
Con esta configuración, el optimizador elige usar una combinación hash basada en el costo,
las características de la consulta y la disponibilidad de los recursos. Si la estimación del costo
es incorrecta, puede forzar al optimizador a elegir una combinación hash. Para ello, establezca
hash_join_cost_based, una variable de MySQL Server, en off. En el siguiente ejemplo se ilustra
cómo forzar al optimizador a elegir una combinación hash.
mysql> SET optimizer_switch='hash_join_cost_based=off';
Note
Actualmente, el modo lab de Aurora debe estar habilitado para usar las combinaciones hash para
Aurora MySQL. Para obtener información sobre cómo habilitar el modo lab de Aurora, consulte
Modo lab de Amazon Aurora MySQL (p. 665).
Optimización de consultas para combinaciones hash

Para averiguar si una consulta puede beneficiarse de usar una combinación hash, utilice antes la
instrucción EXPLAIN para perfilar la consulta. La instrucción EXPLAIN ofrece información acerca del plan
de ejecución que se va a utilizar para una consulta especificada
En el resultado de la instrucción EXPLAIN, la columna Extra describe información adicional que se

incluye con el plan de ejecución. Si se aplica una combinación hash a las tablas utilizadas en la consulta,
esta columna incluye valores similares a los siguientes:
• Using where; Using join buffer (Hash Join Outer table table1_name)
• Using where; Using join buffer (Hash Join Inner table table2_name)
En el siguiente ejemplo se muestra el uso de EXPLAIN para ver el plan de ejecución de una consulta hash
join (con combinación hash).
mysql> explain SELECT sql_no_cache * FROM hj_small, hj_big, hj_big2

-> WHERE hj_small.col1 = hj_big.col1 and hj_big.col1=hj_big2.col1 ORDER BY 1;
+----+-------------+----------+------+---------------+------+---------+------+------
+----------------------------------------------------------------+

676
Uso de claves externas
| id | select_type | table | type | possible_keys | key

| key_len | ref | rows | Extra
|
+----+-------------+----------+------+---------------+------+---------+------+------
+----------------------------------------------------------------+
| 1 | SIMPLE | hj_small | ALL | NULL | NULL | NULL | NULL | 6 | Using
temporary; Using filesort |
| 1 | SIMPLE | hj_big | ALL | NULL | NULL | NULL | NULL | 10 | Using
where; Using join buffer (Hash Join Outer table hj_big) |
| 1 | SIMPLE | hj_big2 | ALL | NULL | NULL | NULL | NULL | 15 | Using
where; Using join buffer (Hash Join Inner table hj_big2) |
+----+-------------+----------+------+---------------+------+---------+------+------
+----------------------------------------------------------------+
3 rows in set (0.04 sec)
En la salida, la Hash Join Inner table es la tabla utilizada para crear la tabla hash y la Hash Join
Outer table es la tabla usada para sondear la tabla hash.
Para obtener más información acerca del formato de salida ampliado EXPLAIN, consulte Extended
EXPLAIN Output Format en la documentación de productos de MySQL.
Uso de claves externas en Aurora MySQL

Le recomendamos encarecidamente que no ejecute instrucciones en lenguaje de definición de datos (DDL)
cuando la variable foreign_key_checks está definida en 0 (apagada).
Si tiene que insertar o actualizar filas que requieran una infracción transitoria de claves externas, siga estos
pasos:
1. Establezca foreign_key_checks en 0.
2. Realice sus cambios de lenguaje de manipulación de datos (DML).
3. Asegúrese de que los cambios completados no infrinjan ninguna restricción de claves externas.
4. Establezca foreign_key_checks en 1 (activado).
Además, siga estas otras prácticas recomendadas para restricciones de clave externa:
• Asegúrese de que sus aplicaciones cliente no establezcan la variable foreign_key_checks en 0

como parte de la variable init_connect.
• Si una restauración a partir de un backup lógico mysqldump deja de funcionar o está incompleta,
asegúrese de que foreign_key_checks esté definido en 1 antes de iniciar alguna otra operación en
la misma sesión. Un backup lógico establece foreign_key_checks en 0 cuando se inicia.
Temas relacionados
Referencia de Amazon Aurora MySQL

Esta referencia incluye información sobre los parámetros y las variables de estado de Aurora MySQL.
Temas
• Parámetros de Aurora MySQL (p. 678)
• Parámetros y variables de estado de MySQL inaplicables (p. 689)
• Eventos de Aurora MySQL (p. 690)
• Procedimientos almacenados de Aurora MySQL (p. 692)

677
Parámetros
Parámetros de Aurora MySQL

El clúster de base de datos Amazon Aurora MySQL se administra de la misma forma que otras instancias
de base de datos de Amazon RDS: utilizando los parámetros de un grupo de parámetros de base de
datos. Amazon Aurora difiere de otros motores de base de datos en que hay un clúster de base de datos
que contiene varias instancias de base de datos. Como resultado, algunos de los parámetros que utiliza
para administrar su clúster de base de datos de Aurora MySQL se aplican a todo el clúster. Los demás
parámetros se aplican solo a una instancia de base de datos determinada en el clúster de base de datos.
Los parámetros de nivel de clúster se administran en los grupos de parámetros de clúster de base de
datos. Los parámetros de nivel de instancia se administran en los grupos de parámetros de base de datos.
Todas las instancia de base de datos en un clúster de base de datos de Aurora MySQL son compatibles
con el motor de base de datos de MySQL. Sin embargo, debe aplicar algunos parámetros del motor de
base de datos de MySQL en el nivel de clúster. y administrarlos usando los grupos de parámetros de
clúster de base de datos. No puede detectar los parámetros de nivel del clúster en el grupo de parámetros
de base de datos para una instancia en un clúster de base de datos de Aurora. Después aparecerá una
lista de parámetros de nivel de clúster en este tema.
Puede administrar tanto los parámetros de nivel de clúster como los de nivel de instancia usando la
Consola de administración de AWS, la AWS CLI o la API de Amazon RDS. Hay comandos independientes
para administrar los parámetros de nivel de clúster y los parámetros de nivel de instancia. Por ejemplo,
puede utilizar el comando de la CLI modify-db-cluster-parameter-group para administrar parámetros de
nivel de clúster en un grupo de parámetros del clúster de base de datos. Puede utilizar el comando de
la CLI modify-db-parameter-group para administrar parámetros de nivel de instancia en un grupo de
parámetros de base de datos para una instancia de base de datos en un clúster de base de datos.
Puede ver tanto los parámetros de nivel de clúster como los de nivel de instancia en la consola o usando
la CLI o la API de RDS. Por ejemplo, puede utilizar el comando de la AWS CLI describe-db-cluster-
parameters para ver parámetros de nivel de clúster en un grupo de parámetros del clúster de base de
datos. Puede utilizar el comando de la CLI describe-db-parameters para ver parámetros de nivel de
instancia en un grupo de parámetros de base de datos para una instancia de base de datos en un clúster
de base de datos.
Para obtener más información acerca de los grupos de parámetros de base de datos, consulte Trabajo con
los grupos de parámetros de base de datos y grupos de parámetros de clúster de base de datos (p. 259).
Para conocer las reglas y restricciones para clústeres de Aurora Serverless, consulte Aurora Serverless y
grupos de parámetros (p. 106).
Temas
• Parámetros de nivel de clúster (p. 678)
• Parámetros de nivel de instancia (p. 681)
Parámetros de nivel de clúster

En la siguiente tabla se muestran todos los parámetros que afectan a todo el clúster de base de datos
Aurora MySQL.
Nombre del parámetro Modificable Notas
Sí
aurora_enable_replica_log_compression No aplica cambios a clústeres que formen
parte de una base de datos global de
Aurora.
Sí
aurora_enable_repl_bin_log_filtering No aplica cambios a clústeres que formen
parte de una base de datos global de
Aurora.

678
Parámetros
aurora_enable_zdr Sí Para obtener más información,

consulte Consideraciones sobre la alta
disponibilidad de la replicación de Amazon
aurora_load_from_s3_role Sí Para obtener más información, consulte

Carga de datos en un clúster de base
de datos Amazon Aurora MySQL desde
archivos de texto en un bucket de Amazon
S3 (p. 641).
aurora_select_into_s3_role Sí Para obtener más información, consulte

Grabación de datos desde un clúster de
base de datos Amazon Aurora MySQL en
archivos de texto de un bucket de Amazon
S3 (p. 649).
auto_increment_increment Sí
auto_increment_offset Sí
aws_default_lambda_role Sí Para obtener más información, consulte

Invocación de una función de Lambda
desde un clúster de base de datos Amazon
aws_default_s3_role Sí
binlog_checksum Sí
binlog_format Sí
binlog_row_image No
binlog_rows_query_log_events No
character-set-client-handshake Sí
character_set_client Sí
character_set_connection Sí
character_set_database Sí
character_set_filesystem Sí
character_set_results Sí
character_set_server Sí
collation_connection Sí
collation_server Sí
completion_type Sí
default_storage_engine No Los clústeres de Aurora MySQL usan el

motor de almacenamiento de InnoDB para
todos sus datos.

679
Parámetros
innodb_autoinc_lock_mode Sí
innodb_checksums No
innodb_cmp_per_index_enabled Sí
innodb_commit_concurrency Sí
innodb_data_home_dir No Aurora MySQL utiliza instancias

administradas en las que no accede al
sistema de archivos directamente.
innodb_file_per_table Sí
innodb_flush_log_at_trx_commit Sí
innodb_ft_max_token_size Sí
innodb_ft_min_token_size Sí
innodb_ft_num_word_optimize Sí
innodb_ft_sort_pll_degree Sí
innodb_online_alter_log_max_size Sí
innodb_optimize_fulltext_only Sí
innodb_page_size No
innodb_purge_batch_size Sí
innodb_purge_threads Sí
innodb_rollback_on_timeout Sí
innodb_rollback_segments Sí
innodb_spin_wait_delay Sí
innodb_strict_mode Sí
innodb_support_xa Sí
innodb_sync_array_size Sí
innodb_sync_spin_loops Sí
innodb_table_locks Sí
innodb_undo_directory No Aurora MySQL utiliza instancias

innodb_undo_logs Sí
innodb_undo_tablespaces No
lc_time_names Sí
lower_case_table_names Sí

680
Parámetros
master-info-repository Sí
master_verify_checksum Sí
server_audit_events Sí
server_audit_excl_users Sí
server_audit_incl_users Sí
server_audit_logging Sí Para conocer las instrucciones sobre la

carga de los registros en CloudWatch
Logs, consulte Publicación de registros
de Amazon Aurora MySQL en Amazon
server_id No
skip-character-set-client- Sí
handshake
skip_name_resolve No
sync_frm Sí
time_zone Sí
Parámetros de nivel de instancia

En la siguiente tabla se muestran todos los parámetros que afectan a una instancia de base de datos
concreta de un clúster de base de datos Aurora MySQL.
allow-suspicious-udfs No
aurora_lab_mode Sí Para obtener más información,

consulte Modo lab de Amazon Aurora
MySQL (p. 665).
aurora_oom_response Sí Para obtener más información, consulte

Problemas de memoria insuficiente de
autocommit Sí
automatic_sp_privileges Sí
back_log Sí
basedir No Aurora MySQL utiliza instancias

binlog_cache_size Sí
binlog_max_flush_queue_time Sí

681
Parámetros
binlog_order_commits Sí
binlog_stmt_cache_size Sí
bulk_insert_buffer_size Sí
concurrent_insert Sí
connect_timeout Sí
core-file No Aurora MySQL utiliza instancias

datadir No Aurora MySQL utiliza instancias

default_time_zone No
default_tmp_storage_engine Sí
default_week_format Sí
delay_key_write Sí
delayed_insert_limit Sí
delayed_insert_timeout Sí
delayed_queue_size Sí
div_precision_increment Sí
end_markers_in_json Sí
enforce_gtid_consistency A veces Modificable en Aurora MySQL, versión 2.04

y versiones posteriores.
eq_range_index_dive_limit Sí
event_scheduler Sí
explicit_defaults_for_timestamp Sí
flush No
flush_time Sí
ft_boolean_syntax No
ft_max_word_len Sí
ft_min_word_len Sí
ft_query_expansion_limit Sí
ft_stopword_file Sí

682
Parámetros
general_log Sí Para conocer las instrucciones sobre la

general_log_file No Aurora MySQL utiliza instancias

group_concat_max_len Sí
gtid-mode A veces Modificable en Aurora MySQL, versión 2.04

y versiones posteriores.
host_cache_size Sí
init_connect Sí
innodb_adaptive_hash_index Sí
innodb_adaptive_max_sleep_delay Sí
innodb_autoextend_increment Sí
No
innodb_buffer_pool_dump_at_shutdown
innodb_buffer_pool_dump_now No
innodb_buffer_pool_filename No
innodb_buffer_pool_load_abort No
innodb_buffer_pool_load_at_startupNo
innodb_buffer_pool_load_now No
innodb_buffer_pool_size Sí
innodb_change_buffer_max_size No Aurora MySQL no utiliza el búfer de cambio

de InnoDB en absoluto.
Sí
innodb_compression_failure_threshold_pct
innodb_compression_level Sí
innodb_compression_pad_pct_max Sí
innodb_concurrency_tickets Sí
innodb_file_format Sí
innodb_flush_log_at_timeout No
innodb_flushing_avg_loops No
innodb_force_load_corrupted No
innodb_ft_aux_table Sí

683
Parámetros
innodb_ft_cache_size Sí
innodb_ft_enable_stopword Sí
innodb_ft_server_stopword_table Sí
innodb_ft_user_stopword_table Sí
innodb_large_prefix Sí
innodb_lock_wait_timeout Sí
innodb_log_compressed_pages No
innodb_lru_scan_depth Sí
innodb_max_purge_lag Sí
innodb_max_purge_lag_delay Sí
innodb_monitor_disable Sí
innodb_monitor_enable Sí
innodb_monitor_reset Sí
innodb_monitor_reset_all Sí
innodb_old_blocks_pct Sí
innodb_old_blocks_time Sí
innodb_open_files Sí
innodb_print_all_deadlocks Sí
innodb_random_read_ahead Sí
innodb_read_ahead_threshold Sí
innodb_read_io_threads No
innodb_read_only No Aurora MySQL administra el estado de solo

lectura y lectura/escritura de las instancias
de base de datos según el tipo de clúster.
Por ejemplo, un clúster aprovisionado
dispone de una instancia de base de datos
de lectura/escritura (la instancia principal)
y mis otras instancias en el clúster son de
solo lectura (las réplicas de Aurora).
innodb_replication_delay Sí
innodb_sort_buffer_size Sí
innodb_stats_auto_recalc Sí
innodb_stats_method Sí
innodb_stats_on_metadata Sí

684
Parámetros
innodb_stats_persistent Sí
Sí
innodb_stats_persistent_sample_pages
Sí
innodb_stats_transient_sample_pages
innodb_thread_concurrency No
innodb_thread_sleep_delay Sí
interactive_timeout Sí
join_buffer_size Sí
keep_files_on_create Sí
key_buffer_size Sí
key_cache_age_threshold Sí
key_cache_block_size Sí
key_cache_division_limit Sí
local_infile Sí
lock_wait_timeout Sí
log-bin No
log_bin_trust_function_creators Sí
log_bin_use_v1_row_events Sí
log_error No
log_output Sí
log_queries_not_using_indexes Sí
log_slave_updates No
Sí
log_throttle_queries_not_using_indexes
log_warnings Sí
long_query_time Sí
low_priority_updates Sí
max_allowed_packet Sí
max_binlog_cache_size Sí
max_binlog_size No
max_binlog_stmt_cache_size Sí
max_connect_errors Sí

685
Parámetros
max_connections Sí Para obtener más información, consulte

Número máximo de conexiones a una
instancia de base de datos Aurora
MySQL (p. 545).
max_delayed_threads Sí
max_error_count Sí
max_heap_table_size Sí
max_insert_delayed_threads Sí
max_join_size Sí
max_length_for_sort_data Sí
max_prepared_stmt_count Sí
max_seeks_for_key Sí
max_sort_length Sí
max_sp_recursion_depth Sí
max_tmp_tables Sí
max_user_connections Sí
max_write_lock_count Sí
metadata_locks_cache_size Sí
min_examined_row_limit Sí
myisam_data_pointer_size Sí
myisam_max_sort_file_size Sí
myisam_mmap_size Sí
myisam_sort_buffer_size Sí
myisam_stats_method Sí
myisam_use_mmap Sí
net_buffer_length Sí
net_read_timeout Sí
net_retry_count Sí
net_write_timeout Sí
old-style-user-limits Sí
old_passwords Sí
optimizer_prune_level Sí

686
Parámetros
optimizer_search_depth Sí
optimizer_switch Sí
optimizer_trace Sí
optimizer_trace_features Sí
optimizer_trace_limit Sí
optimizer_trace_max_mem_size Sí
optimizer_trace_offset Sí
performance_schema Sí
pid_file No
plugin_dir No Aurora MySQL utiliza instancias

port No Aurora MySQL administra las propiedades

de conexión e implementa una
configuración coherente para todas las
instancias de base de datos en un clúster.
preload_buffer_size Sí
profiling_history_size Sí
query_alloc_block_size Sí
query_cache_limit Sí
query_cache_min_res_unit Sí
query_cache_size Sí
query_cache_type Sí
query_cache_wlock_invalidate Sí
query_prealloc_size Sí
range_alloc_block_size Sí
read_buffer_size Sí
read_only No Aurora MySQL administra el estado de solo

lectura y lectura/escritura de las instancias
de base de datos según el tipo de clúster.
Por ejemplo, un clúster aprovisionado
dispone de una instancia de base de datos
de lectura/escritura (la instancia principal)
y mis otras instancias en el clúster son de
solo lectura (las réplicas de Aurora).
read_rnd_buffer_size Sí

687
Parámetros
relay-log No
relay_log_info_repository Sí
relay_log_recovery No
safe-user-create Sí
secure_auth Sí
secure_file_priv No Aurora MySQL utiliza instancias

skip-slave-start No
skip_external_locking No
skip_show_database Sí
slave_checkpoint_group Sí
slave_checkpoint_period Sí
slave_parallel_workers Sí
slave_pending_jobs_size_max Sí
slave_sql_verify_checksum Sí
slow_launch_time Sí
slow_query_log Sí Para conocer las instrucciones sobre la

slow_query_log_file No Aurora MySQL utiliza instancias

socket No
sort_buffer_size Sí
sql_mode Sí
sql_select_limit Sí
stored_program_cache Sí
sync_binlog No
sync_master_info Sí
sync_relay_log Sí
sync_relay_log_info Sí

688
Parámetros y variables de estado de MySQL inaplicables
sysdate-is-now Sí
table_cache_element_entry_ttl No
table_definition_cache Sí
table_open_cache Sí
table_open_cache_instances Sí
temp-pool Sí
thread_handling No
thread_stack Sí
timed_mutexes Sí
tmp_table_size Sí
tmpdir No Aurora MySQL utiliza instancias

transaction_alloc_block_size Sí
transaction_prealloc_size Sí
tx_isolation Sí
updatable_views_with_limit Sí
validate-password No
validate_password_dictionary_file No
validate_password_length No
validate_password_mixed_case_countNo
validate_password_number_count No
validate_password_policy No
No
validate_password_special_char_count
wait_timeout Sí
Parámetros y variables de estado de MySQL

inaplicables
Debido a las diferencias de arquitectura entre Aurora MySQL y MySQL, algunos parámetros y variables de
estado de MySQL no se aplican a Aurora MySQL.
Los siguientes parámetros de MySQL no se aplican a Aurora MySQL:
• innodb_adaptive_flushing

689
Eventos de Aurora MySQL
• innodb_adaptive_flushing_lwm
• innodb_change_buffering
• innodb_checksum_algorithm
• innodb_doublewrite
• innodb_flush_method
• innodb_flush_neighbors
• innodb_io_capacity
• innodb_io_capacity_max
• innodb_log_buffer_size
• innodb_log_file_size
• innodb_log_files_in_group
• innodb_max_dirty_pages_pct
• innodb_use_native_aio
• innodb_write_io_threads
• thread_cache_size
Las siguientes variables de estado de MySQL no se aplican a Aurora MySQL:
• innodb_buffer_pool_bytes_dirty
• innodb_buffer_pool_pages_dirty
• innodb_buffer_pool_pages_flushed
Note
Estas listas no son exhaustivas.

He aquí algunos eventos de espera frecuentes de Aurora MySQL.
Note
Para obtener información sobre las convenciones de nomenclatura de los eventos de espera de
MySQL, consulte Performance Schema Instrument Naming Conventions en la documentación de
MySQL.
io/aurora_redo_log_flush
En este evento de espera, una sesión está escribiendo datos en el almacenamiento de Aurora. Este
evento de espera suele ser para una operación de E/S de escritura en Aurora MySQL.
io/aurora_respond_to_client
En este evento de espera, un subproceso está devolviendo el conjunto de resultados al cliente.

io/file/csv/data
En este evento de espera, hay subprocesos escribiendo en tablas CSV. Compruebe el uso de tablas
CSV. Una causa habitual de este evento es que se haya establecido log_output en una tabla.
io/file/innodb/innodb_data_file
En este evento de espera, hay subprocesos esperando a operaciones de E/S del almacenamiento.
Este evento es más frecuente en cargas de trabajo con gran intensidad de E/S. Las instrucciones
SQL que muestran una proporción grande comparativamente de este evento de espera pueden estar

690
ejecutando consultas intensivas de disco. También pueden estar solicitando datos que no pueden
satisfacerse desde el grupo de búfer de InnoDB. Para saberlo, compruebe los planes de consulta y
los porcentajes de éxito de la caché. Para obtener información, consulte Buffering and Caching en la
io/file/sql/binlog
En este evento de espera, hay un subproceso esperando por un archivo binlog que se está
escribiendo en disco.
io/socket/sql/client_connection
En este evento de espera, un subproceso está controlando una nueva conexión.

io/table/sql/handler
Este es un evento de espera de E/S de tabla. Normalmente, estos tipos de eventos pueden ir seguidos
de un evento anidado, como un evento de E/S de archivo. Para obtener más información sobre los
eventos "atom" y "molecule" del esquema de rendimiento, consulte Performance Schema Atom and
Molecule Events en la documentación de MySQL.
lock/table/sql/handler
Este evento de espera es un controlador de evento de espera de bloqueo de tabla. Para obtener más
información sobre los eventos "atom" y "molecule" del esquema de rendimiento, consulte Performance
Schema Atom and Molecule Events en la documentación de MySQL.
synch/cond/mysys/my_thread_var::suspend
En este evento de espera, hay subprocesos suspendidos mientras esperan por una condición. Por
ejemplo, este evento se produce cuando los subprocesos están esperando al bloqueo de nivel de
tabla. Recomendamos investigar la carga de trabajo para comprobar qué subprocesos podrían estar
adquiriendo bloqueos de tabla en la instancia de base de datos. Para obtener más información sobre
el bloqueo de tablas en MySQL, consulte Table Locking Issues en la documentación de MySQL.
synch/cond/sql/MDL_context::COND_wait_status
En este evento de espera, hay subprocesos esperando por un bloqueo de metadatos de tabla. Para
obtener más información, consulte Optimizing Locking Operations en la documentación de MySQL.
synch/cond/sql/MYSQL_BIN_LOG::COND_done
En este evento de espera, hay un subproceso esperando por un archivo binlog que se está
escribiendo en disco. La contención de logs binarios se puede producir en las bases de datos cuya
velocidad de cambio es muy alta.
synch/mutex/innodb/aurora_lock_thread_slot_futex
En este evento de espera, hay un subproceso esperando en un bloqueo de registro InnoDB. Si ve

este evento, compruebe si hay cargas de trabajo conflictivas en su base de datos. Para obtener
información, consulte InnoDB Locking en la documentación de MySQL.
synch/mutex/innodb/buf_pool_mutex
En este evento de espera, un subproceso ha adquirido un bloqueo en el grupo de búfer de InnoDB.

synch/mutex/sql/LOCK_open
En este evento de espera, se está utilizando LOCK_open para proteger varios objetos del diccionario
de datos. Este evento de espera indica que hay subprocesos esperando para adquirir estos bloqueos.
Normalmente, este evento se produce debido a una contención del diccionario de datos.
synch/mutex/sql/LOCK_table_cache
En este evento de espera, hay subprocesos esperando a adquirir un bloqueo de una instancia de
caché de tabla. Para obtener más información, consulte How MySQL Opens and Closes Tables en la

691
Procedimientos almacenados
synch/mutex/sql/LOG
En este evento de espera, hay subprocesos esperando por un bloqueo de log. Por ejemplo, un
subproceso podría esperar a un bloqueo para escribir en el archivo log de consultas lentas.
synch/mutex/sql/MYSQL_BIN_LOG::LOCK_commit
En este evento de espera, hay un subproceso esperando a adquirir un bloqueo con la intención de
efectuar una confirmación en el log binario. La contención de logs binarios se puede producir en las
bases de datos cuya velocidad de cambio es muy alta. Según la versión de MySQL, hay algunos
bloqueos que se utilizan para proteger la coherencia y durabilidad del log binario. En MySQL en
RDS, los logs binarios se utilizan para la replicación y para el proceso de backup automatizado. En
Aurora MySQL, los logs binarios no se necesitan para la replicación o los backups nativos. Están
deshabilitados de forma predeterminada, pero se pueden habilitar y utilizar para la replicación externa
o la captura de datos de cambios. Para obtener más información, consulte The Binary Log en la
synch/mutex/sql/MYSQL_BIN_LOG::LOCK_log
En este evento de espera, los subprocesos están bloqueando activamente el archivo log binario.
La contención de logs binarios se puede producir en las bases de datos cuya velocidad de cambio
es muy alta. Según la versión de MySQL, hay algunos bloqueos que se utilizan para proteger la
coherencia y durabilidad del log binario.
synch/rwlock/innodb/dict
En este evento de espera, hay subprocesos esperando por un rwlock aplicado al diccionario de datos
de InnoDB.
synch/rwlock/innodb/dict sys RW lock
En este evento de espera, hay subprocesos que están esperando por un rwlock aplicado al diccionario
de datos de InnoDB.
synch/rwlock/innodb/dict_operation_lock
En este evento de espera, hay subprocesos manteniendo bloqueos en operaciones del diccionario de
datos de InnoDB.
Procedimientos almacenados de Aurora MySQL

Puede invocar los siguientes procedimientos almacenados cuando esté conectado a la instancia principal
en un clúster de Aurora MySQL. Estos procedimientos controlan la forma en la que se replican las
transacciones desde una base de datos externa en Aurora MySQL o desde Aurora MySQL a una base de
datos externa. Para conocer cómo utilizar la replicación basada en identificadores de transacción global
(GTID) con Aurora MySQL, consulte Uso de replicación basada en GTID para Aurora MySQL (p. 625).
Temas
• mysql.rds_set_master_auto_position (p. 692)
• mysql.rds_set_external_master_with_auto_position (p. 693)
• mysql.rds_skip_transaction_with_gtid (p. 695)
mysql.rds_set_master_auto_position
Establece el modo de replicación en el que se debe basar ya sea en posiciones de archivos de registros
binarios o en identificadores de transacciones globales (GTID).
Sintaxis

692
CALL mysql.rds_set_master_auto_position (auto_position_mode);
Parámetros
auto_position_mode
Un valor que indicar si debe usarse la replicación de posición de los archivos de registro o la
replicación basada en GTID:
• 0: utilice el método de replicación basado en la posición del archivo de registro binario. El valor
predeterminado es 0.
• 1: utilice el método de replicación basado en GTID.
Notas de uso
Para un clúster de base de datos de Aurora MySQL, puede invocar este procedimiento almacenado
cuando esté conectado a la instancia principal.
El usuario maestro debe ejecutar el procedimiento mysql.rds_set_master_auto_position.
Para Aurora, este procedimiento es compatible con Aurora MySQL, versión 2.04 y versiones posteriores
compatibles con MySQL 5.7. La replicación basada en GTID no es compatible con Aurora MySQL 1.1 o
1.0.
mysql.rds_set_external_master_with_auto_position
Permite configurar una instancia principal de Aurora MySQL para aceptar la replicación entrante desde una
instancia MySQL externa. Este procedimiento también configura la replicación basada en identificadores
de transacciones globales (GTID).
Este procedimiento está disponible para Amazon RDS MySQL y Aurora MySQL. Funciona de forma
distinta según el contexto. Cuando se utiliza con Aurora MySQL, este procedimiento no configura la
replicación retrasada. Esta limitación se realiza porque Amazon RDS MySQL admite la replicación
retrasada, pero Aurora MySQL no.
Sintaxis
CALL mysql.rds_set_external_master_with_auto_position (
host_name
, host_port
, replication_user_name
, replication_user_password
, ssl_encryption
);
Parámetros
host_name
El nombre de host o la dirección IP de la instancia de MySQL que se ejecuta fuera de Aurora que se
convertirá en el maestro de replicación.
host_port
El puerto usado por la instancia de MySQL que se ejecuta fuera de Aurora que se configurará como
maestra de la replicación. Si la configuración de la red incluye la replicación de puertos SSH (Secure
Shell) que convierte el número de puerto, especifique el número de puerto expuesto por SSH.

693
replication_user_name
ID de un usuario con permisos REPLICATION CLIENT y REPLICATION SLAVE en la instancia de

MySQL que se ejecuta fuera de Aurora. Es recomendable que proporcione una cuenta que se use
solo para la replicación con la instancia externa.
replication_user_password
La contraseña del ID de usuario especificado en replication_user_name.

ssl_encryption
Esta opción no está implementada actualmente. El valor predeterminado es 0.
Notas de uso
El usuario maestro debe ejecutar el procedimiento

mysql.rds_set_external_master_with_auto_position. El usuario maestro ejecuta este
procedimiento en la instancia principal de un clúster de base de datos de Aurora MySQL que funciona
como un destino de replicación. Este puede ser el destino de replicación de una instancia de MySQL
externo o un clúster de base de datos Aurora MySQL.
1.0.
Antes de ejecutar mysql.rds_set_external_master_with_auto_position, configure la instancia

de base de datos de MySQL para que sea un maestro de replicación. Para conectar la instancia de
MySQL externa, especifique valores para replication_user_name y replication_user_password.
Estos valores deben indicar a un usuario de replicación que tiene permisos REPLICATION CLIENT y
REPLICATION SLAVE en la instancia externa de MySQL.
Para configurar una instancia externa de MySQL como maestro de replicación
1. Con el cliente de MySQL que prefiera, conéctese a la instancia externa de MySQL y cree una cuenta
de usuario que se usará para la replicación. A continuación se muestra un ejemplo.
CREATE USER 'repl_user'@'mydomain.com' IDENTIFIED BY 'SomePassW0rd'
2. En la instancia de MySQL externa, conceda a REPLICATION CLIENT y a REPLICATION SLAVE

privilegios para el usuario de replicación. En el siguiente ejemplo se conceden los privilegios
REPLICATION CLIENT y REPLICATION SLAVE en todas las bases de datos al usuario
'repl_user' de su dominio.
GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'mydomain.com'

IDENTIFIED BY 'SomePassW0rd'
Cuando invoque mysql.rds_set_external_master_with_auto_position, Amazon RDS registra

determinada información. Esta información es la hora, el usuario y una acción de "set master" en las
tablas de mysql.rds_history y mysql.rds_replication_status.
Para omitir una transacción específica basada en GTID que se sabe que causa un problema, puede usar el
procedimiento almacenado mysql.rds_skip_transaction_with_gtid (p. 695). Para obtener más información

694
Actualizaciones de Aurora MySQL
sobre el uso de la replicación basada en GTID, consulte Uso de replicación basada en GTID para Aurora
MySQL (p. 625).
Ejemplos
Cuando se ejecuta en una instancia principal de Aurora, el siguiente ejemplo configura el clúster de Aurora
para que actúe como réplica de lectura de una instancia de MySQL que se ejecuta fuera de Aurora.
call mysql.rds_set_external_master_with_auto_position(
'Externaldb.some.com',
3306,
'repl_user'@'mydomain.com',
'SomePassW0rd');
mysql.rds_skip_transaction_with_gtid
Omite la replicación de una transacción con el identificador de transacción global (GTID) especificado en
una instancia principal de Aurora.
Puede utilizar este procedimiento para la recuperación de desastres cuando se sabe que una transacción
de GTID específica causa un problema. Utilice este procedimiento almacenado para omitir la transacción
problemática. Entre los ejemplos de transacciones problemáticas se incluyen transacciones que inhabilitan
la replicación, eliminan datos importantes o provocan que la instancia de base de datos no esté disponible.
Sintaxis
CALL mysql.rds_skip_transaction_with_gtid (gtid_to_skip);
Parámetros
gtid_to_skip
El GTID de la transacción de replicación que se debe omitir.
Notas de uso
El usuario maestro debe ejecutar el procedimiento mysql.rds_skip_transaction_with_gtid.
1.0.
Actualizaciones del motor de base de datos para

Amazon Aurora MySQL
Amazon Aurora publica de forma periódica actualizaciones. Las actualizaciones se aplican a clústeres de
base de datos Aurora durante los períodos de mantenimiento del sistema. El momento en el que se aplican

695
Versiones de Aurora MySQL
las actualizaciones depende de la región y de la configuración del período de mantenimiento para el clúster
de la base de datos, así como del tipo de actualización.
Las actualizaciones se aplican a todas las instancias en un clúster de base de datos a la vez. Una
actualización requiere un reinicio de la base de datos en todas las instancias en un clúster de base
de datos, por lo que se producirán entre 20 y 30 segundos de inactividad. Puede ver o cambiar la
configuración del periodo de mantenimiento desde la Consola de administración de AWS.
Versiones de Aurora MySQL

Si bien Compatibilidad de Aurora con MySQL es compatible con los motores de base de datos MySQL,
Aurora MySQL incluye características específicas de Aurora MySQL y que solo están disponibles para
clústeres de base de datos Aurora MySQL.
Las versiones de Aurora usan el formato <versión principal>.<versión secundaria>. <versión

de parche>. Puede obtener la versión de su instancia de Aurora mediante una consulta de la variable del
sistema AURORA_VERSION. Para obtener la versión de Aurora, utilice una de las siguientes consultas.
select AURORA_VERSION();
select @@aurora_version;
Versiones del motor de Aurora MySQL

A partir de Aurora MySQL 2.03.2, las versiones del motor de Aurora tienen la siguiente sintaxis.
<mysql-major-version>.mysql_aurora.<aurora-mysql-version>
Por ejemplo, la versión del motor para Aurora MySQL 2.03.2 es la siguiente.
5.7.mysql_aurora.2.03.2
Note
Para Aurora MySQL 2.x, la versión del motor para Aurora MySQL versión 2.03.1 y anteriores es
5.7.12. En la actualidad, la versión del motor para todas las versiones de Aurora MySQL 1.x es
5.6.10a.
Puede especificar la versión del motor de Aurora MySQL en algunos comandos de la AWS CLI y
operaciones API de RDS. Por ejemplo, especifique la opción --engine-version al ejecutar los
comandos de la AWS CLI create-db-cluster y modify-db-cluster. Especifique el parámetro EngineVersion
al ejecutar las operaciones de la API de RDS CreateDBCluster y ModifyDBCluster.
Antes de Aurora MySQL 2.03.2, la versión del motor que mostraba la Consola de administración de
AWS seguía siendo la misma incluso tras actualizar el motor en el clúster. En Aurora MySQL 2.03.2 y
posteriores, la versión del motor en la Consola de administración de AWS incluye también la versión de
Aurora. La actualización del clúster cambia el valor mostrado. Para clústeres de Aurora administrados
mediante AWS CloudFormation, este cambio en el ajuste EngineVersion puede desencadenar acciones
en AWS CloudFormation. Para obtener información sobre cómo AWS CloudFormation trata los cambios en
el ajuste EngineVersion, consulte la documentación de AWS CloudFormation.

696
Actualizaciones de la base de datos y
parches para Amazon Aurora MySQL
Actualizaciones de la base de datos y parches para

Amazon Aurora MySQL
Hay dos formas de actualizar la versión secundaria de un clúster de base de datos o parchear un clúster
de base de datos:
• Modificación de la versión del motor (p. 697) (actualizando a la versión 2.03.2 y superiores,
únicamente)
• Aplicación de un mantenimiento pendiente a un clúster de base de datos de Aurora MySQL (p. 697)
Modificación de la versión del motor

Al actualizar a la versión 2.03.2 y superiores de Amazon Aurora MySQL, actualiza la versión secundaria
de un clúster de base de datos. Lo hace modificando la versión del motor del clúster de la base de datos
mediante la Consola de administración de AWS, la AWS CLI o la API de RDS.
Para modificar la versión del motor de un clúster de base de datos
• Mediante el uso de la consola de Amazon RDS: Complete los siguientes pasos:

1. Inicie sesión en la consola de Amazon RDS y elija Databases (Bases de datos).
2. Elija el clúster de base de datos que desea modificar.
3. Elija Modify.
4. Cambie la versión del motor de Aurora MySQL en la casilla DB engine version (Versión del motor de
base de datos).
5. Elija Continue y consulte el resumen de las modificaciones.
6. (Opcional) Seleccione Apply immediately (Aplicar inmediatamente) para aplicar los cambios
inmediatamente.
7. En la página de confirmación, seleccione Modify cluster (Modificar clúster).
• Utilizando la AWS CLI: llame al comando modify-db-cluster de la AWS CLI y especifique el nombre del
clúster de la base de datos para la opción --db-cluster-identifier y la versión del motor para la
opción --engine-version.
Por ejemplo, para actualizar a la versión 2.03.2 de Aurora MySQL, establezca la opción --engine-
version en 5.7.mysql_aurora.2.03.2. Especifique la opción --apply-immediately para
actualizar inmediatamente la versión del motor para su clúster de base de datos.
• Utilizando la API de Amazon RDS: llame a la operación de la API ModifyDBCluster y especifique el
nombre de su clúster de base de datos para el parámetro DBClusterIdentifier y la versión del
motor para el parámetro EngineVersion. Establezca el parámetro ApplyImmediately en true para
actualizar inmediatamente la versión del motor para el clúster de base de datos.
Aplicación de un mantenimiento pendiente a un clúster de base

de datos de Aurora MySQL
Al actualizar a una versión 1.x de Aurora MySQL, se mostrarán las nuevas versiones secundarias
del motor de base de datos y los parches como que tienen actualización de mantenimiento available
(disponible) para su clúster de base de datos. Puede actualizar o parchear la versión de la base de datos
para su clúster de base de datos aplicando la acción de mantenimiento disponible. Le recomendamos
aplicar la actualización primero en un clúster de base de datos que no sea de producción, para ver de qué
manera afectarán los cambios de la versión nueva a sus instancias y aplicaciones.
Para aplicar acciones de mantenimiento pendientes

697
Aplicación de parches sin tiempo de inactividad
• Mediante el uso de la consola de Amazon RDS: Complete los siguientes pasos:

1. Inicie sesión en la consola de Amazon RDS y elija Databases (Bases de datos).
2. Elija el clúster de base de datos que muestra una actualización de mantenimiento available
(disponible).
3. En Actions (Acciones), elija Upgrade now (Actualizar ahora) para actualizar inmediatamente la versión
de base de datos para su clúster de base de datos, o bien Upgrade at Next Window (Actualizar en el
siguiente periodo) para actualizarla durante el siguiente periodo de mantenimiento del clúster de base
de datos.
• Mediante la AWS CLI: llame al comando apply-pending-maintenance-action de la AWS CLI y especifique
el nombre de recurso de Amazon (ARN) del clúster de base de datos en la opción --resource-
id y system-update en la opción --apply-action. Establezca la opción --opt-in-type en
immediate para actualizar inmediatamente la versión de base de datos para su clúster de base de
datos, o bien next-maintenance para actualizarla durante el siguiente período de mantenimiento del
clúster.
• Mediante la API de Amazon RDS: llame a la operación ApplyPendingMaintenanceAction de la API
y especifique el nombre de recurso de Amazon (ARN) del clúster de base de datos en el parámetro
ResourceId y system-update en el parámetro ApplyAction. Establezca el parámetro OptInType
en immediate para actualizar inmediatamente la versión de base de datos para su clúster de base de
datos, o bien next-maintenance para actualizarla durante el siguiente período de mantenimiento del
clúster.
Para obtener más información acerca de cómo Amazon RDS administra actualizaciones de sistemas
operativos y bases de datos, consulte Mantenimiento de un clúster de base de datos de Amazon
Aurora (p. 340).
Note
Si su versión de Aurora MySQL actual es 1.14.x, pero es anterior a 1.14.4, solo puede actualizar a
1.14.4 (que admite las clases de instancia db.r4). Además, para actualizar de 1.14.x a una versión
secundaria de Aurora MySQL más alta, como 1.17, la versión de 1.14.x debe ser 1.14.4.

La característica de aplicación de parches sin tiempo de inactividad (ZDP) intenta, en la medida de lo
posible conservar las conexiones de cliente a través de un parche en el motor. Si la ZDP se ejecuta
correctamente, las sesiones de aplicación se conservan y el motor de base de datos se reinicia al
aplicar el parche. El reinicio del motor de base de datos puede causar una caída del rendimiento de
aproximadamente 5 segundos. ZDP está disponible en Aurora MySQL 1.13 (compatible con MySQL 5.6) y
versiones posteriores. No está disponible con la versión 2 de Aurora MySQL (compatible con MySQL 5.7).
Es posible que la ZDP no se ejecute correctamente bajo las siguientes condiciones:
• Hay en curso consultas o transacciones de ejecución prolongada. En Aurora MySQL 1.19 y versiones
posteriores, ZDP puede ejecutarse correctamente. En este caso, se cancelarán las transacciones
abiertas.
• El registro binario está habilitado o hay una replicación de registro binario en curso. En Aurora MySQL
1.19 y versiones posteriores, ZDP puede ejecutarse correctamente.
• Existen conexiones SSL abiertas.
• Se están utilizando tablas temporales o bloqueos de tabla, por ejemplo, durante las instrucciones DDL.
En Aurora MySQL 1.19 y versiones posteriores, ZDP puede ejecutarse correctamente. En este caso, se
cancelarán las transacciones abiertas.
• Existen cambios de parámetros pendientes.
Si no hubiera un período de tiempo apropiado para la ejecución de la ZDP debido a una o varias de estas
condiciones, la aplicación de parches vuelve al comportamiento estándar.

698
Temas relacionados
Note
• La ZDP se aplica solamente a la instancia principal de un clúster de base de datos. La ZDP no

es aplicable a las réplicas de Aurora.
• Las instrucciones preparadas no evitan la ZDP, pero no se conservan después de la ejecución
de esta.
Temas relacionados
• Actualizaciones del motor de base de datos para Amazon Aurora MySQL 2.0 (p. 699)
• Actualizaciones del motor de base de datos para Amazon Aurora MySQL 1.1 (p. 721)
• Errores de MySQL corregidos en las actualizaciones del motor de base de datos de Aurora
MySQL (p. 759)
• Características del modo lab de Aurora (p. 666)

Amazon Aurora MySQL 2.0
A continuación se indican actualizaciones del motor de base de datos Amazon Aurora 2.0:
• Actualizaciones del motor de base de datos de Aurora MySQL (08/07/2019) (versión 2.04.5) (p. 699)
• Actualizaciones del motor de base de datos de Aurora MySQL (25/03/2019) (versión 2.04) (p. 706)
• Actualizaciones del motor de base de datos de Aurora MySQL (07/02/2019) (p. 707) (versión 2.03.4)
• Actualizaciones del motor de base de datos de Aurora MySQL (11/10/2018) (p. 710) (versión 2.03)
Actualizaciones del motor de base de datos de Aurora MySQL

(08/07/2019) (versión 2.04.5)
Versión: 2.04.5
Aurora MySQL 2.04.5 ya está disponible con carácter general. Las versiones 2.x de Aurora MySQL son
compatibles con MySQL 5.7 y las versiones 1.x de Aurora MySQL son compatibles con MySQL 5.6.

699
Actualizaciones del motor de base de
datos para Amazon Aurora MySQL 2.0
Tiene la opción de actualizar los clústeres de base de datos Aurora MySQL 2.* existentes a Aurora
MySQL 2.04.5. No permitimos la actualización in situ de clústeres de Aurora MySQL 1.*. Esta restricción
se aplicará en las versiones posteriores de Aurora MySQL 2.*. Puede restaurar instantáneas de Aurora
MySQL 1.14.*, 1.15.*, 1.16.*, 1.17.*, 1.18.*, 1.19.*, 2.01.*, 2.02.*, 2.03.* y 2.04.* en Aurora MySQL 2.04.5.
Si tiene alguna duda, el equipo de AWS Support está disponible en los foros de la comunidad y a través de
AWS Premium Support. Para obtener más información, consulte Mantenimiento de un clúster de base de
Note
Para obtener información sobre cómo actualizar su clúster de base de datos de Aurora MySQL,
consulte Actualizaciones de la base de datos y parches para Amazon Aurora MySQL (p. 697).
Mejoras
• Se ha corregido una condición de carrera durante el crecimiento del volumen de almacenamiento que
provocaba que la base de datos se reiniciara.
• Se ha corregido un error de comunicación interna durante la apertura del volumen que provocaba que la
base de datos se reiniciara.
• Se ha añadido compatibilidad de la recuperación DDL para ALTER TABLE ALGORITHM=INPLACE en
las tablas particionadas.
• Se ha corregido un error con la recuperación DDL de ALTER TABLE ALGORITHM=COPY que provocaba
que la base de datos se reiniciara.
• Se ha mejorado la estabilidad de la réplica de Aurora en la carga de trabajo de eliminación pesada en el
escritor.
• Se ha solucionado el restablecimiento de una base de datos debido al bloqueo entre el subproceso
que realiza la sincronización del índice de búsqueda de texto completo y el subproceso que realiza la
expulsión de la tabla de búsqueda de texto completo de la caché del diccionario.
• Se ha solucionado un problema de estabilidad en el esclavo de binlog durante la replicación DDL
mientras la conexión al maestro de binlog era inestable.
• Se ha solucionado un problema de falta de memoria en el código de búsqueda de texto completo que
• Se ha solucionado un problema en el escritor de Aurora que provocaba su reinicio cuando se utilizaba el
volumen de 64 TB completo.
• Se ha solucionado una condición de carrera en la característica de esquema de rendimiento que
• Se ha solucionado un problema que provocaba anulaciones de conexiones cuando se gestionaba un
error en la administración de protocolos de red.
Comparación con Aurora MySQL, versión 1

Las siguientes características de Amazon Aurora MySQL se admiten en Aurora MySQL, versión 1
(compatible con MySQL 5.6), pero esas características no se admiten en Aurora MySQL, versión 2
(compatible con MySQL 5.7).
• Funciones nativas para la invocación síncrona de las funciones AWS Lambda. Para obtener más
información, consulte Invocación de una función de Lambda con una función nativa de Aurora
MySQL (p. 656).

700
Compatibilidad de MySQL 5.7

Aurora MySQL 2.04.5 es compatible con MySQL 5.7 e incluye características como la compatibilidad de
JSON, índices espaciales y columnas generadas. Aurora MySQL usa una implementación nativa de la
indexación espacial mediante curvas de orden z para multiplicar por 20 el rendimiento de escritura y por 10
el rendimiento de lectura en comparación con MySQL 5.7 para conjuntos espaciales.
Aurora MySQL 2.04.5 no admite actualmente las siguientes características de MySQL 5.7:


(29/05/2019) (versión 2.04.4)
version: 2.04.4
Al crear un nuevo clúster de base de datos de Aurora MySQL (incluida la restauración de instantáneas),
tiene la opción de elegir la compatibilidad con MySQL 5.7 o MySQL 5.6. No permitimos la actualización in
situ de los clústeres de Aurora MySQL 1.* ni la restauración desde una copia de seguridad de Amazon S3
en Aurora MySQL 2.04.4. Tenemos previsto quitar estas restricciones en una versión posterior de Aurora
MySQL 2.*.
Puede restaurar instantáneas de Aurora MySQL 1.14.*, 1.15.*, 1.16.*, 1.17.*, 1.18.*, 1.19.*, 2.01.*, 2.02.*,
2.03.* y 2.04* en Aurora MySQL 2.04.4.
Note
Actualmente, esta versión no está disponible en las regiones de AWS AWS GovCloud (US-West)
[us-gov-west-1], UE Estocolmo [eu-north-1], China (Ningxia) [cn-northwest-1] y Asia Pacífico
(Hong Kong) [ap-east-1]. Cuando esté disponible, enviaremos una notificación aparte.

701
Note
Mejoras
• Se ha solucionado un problema que podía causar errores al cargar datos en Aurora desde S3.
• Se ha solucionado un problema que podía causar errores al cargar datos de Aurora en S3.
• Se ha solucionado un problema que podía provocar un bloqueo cuando se trabajaba con tablas
particionadas.
• Se ha solucionado un problema con la característica de información sobre rendimiento, que no estaba
disponible en algunas regiones.

MySQL (p. 656).

Aurora MySQL 2.04.4 es compatible por conexión con MySQL 5.7 e incluye características como
la compatibilidad de JSON, índices espaciales y columnas generadas. Aurora MySQL usa una
implementación nativa de la indexación espacial mediante curvas de orden z para multiplicar por 20 el
rendimiento de escritura y por 10 el rendimiento de lectura en comparación con MySQL 5.7 para conjuntos
de datos espaciales.


702

(09/05/2019) (versión 2.04.3)
Versión: 2.04.3
MySQL 2.*.
2.03.* y 2.04.* en Aurora MySQL 2.04.3.
Note
Esta versión no está disponible en las regiones de AWS AWS GovCloud (US-West) [us-gov-
west-1] y China (Ningxia) [cn-northwest-1]. Cuando esté disponible, enviaremos una notificación
aparte.
Note
Mejoras
• Corrección de un error en la replicación de binlog que provocaba problemas en las instancias de Aurora
configuradas como esclavo de binlog.
• Solución de una condición de memoria insuficiente cuando se gestionaban grandes rutinas
almacenadas.
• Solución de un error en la gestión de determinados tipos de comandos ALTER TABLE.
• Solución de un problema con conexiones anuladas debido a un error en la gestión de protocolos de red.


703
MySQL (p. 656).



(02/05/2019) (versión 2.04.2)
Versión: 2.04.2
MySQL 2.*.
2.03.*, 2.04.0 y 2.04.1 en Aurora MySQL 2.04.2.
Note
Esta versión no está disponible en las regiones de AWS AWS GovCloud (US-West) [us-gov-
west-1] y China (Ningxia) [cn-northwest-1]. Cuando esté disponible, enviaremos una notificación
aparte.

704
Note
Mejoras
• Compatibilidad añadida para la replicación de binlog de SSL mediante certificados personalizados. Para
obtener más información sobre el uso de la replicación de binlog de SSL en Aurora MySQL, consulte
mysql_rds_import_binlog_ssl_material.
• Solución de un bloqueo en la instancia principal de Aurora que se producía cuando se optimizaba una
tabla con un índice de búsqueda de texto completo.
• Solución de un problema en las réplicas de Aurora en el que el rendimiento de determinadas consultas
que utilizaban SELECT(*) podían verse afectadas en las tablas con índices secundarios.
• Solución de una condición que provocó el error 1032 publicado.
• Mejora de la estabilidad de las réplicas de Aurora mediante la solución de varios bloqueos.
Integración de correcciones de errores de MySQL

• Error n.º 24829050: LA OPTIMIZACIÓN DE INDEX_MERGE_INTERSECTION GENERA RESULTADOS
DE CONSULTAS INCORRECTOS

MySQL (p. 656).



705


(25/03/2019) (versión 2.04.1)
Versión: 2.04.1
MySQL 2.*.
2.03.* y 2.04.0 en Aurora MySQL 2.04.1.
Note
Esta versión no está disponible en la región AWS GovCloud (US-West) [us-gov-west-1]. Cuando
esté disponible, enviaremos una notificación aparte.
Note
El procedimiento para actualizar su clúster de base de datos ha cambiado. Para obtener más
información, consulte Actualizaciones de la base de datos y parches para Amazon Aurora
MySQL (p. 697).
Mejoras
• Solución de un problema en el que una instantánea de Aurora MySQL 5.6 para versiones inferiores a
1.16 no podía restaurarse al clúster Aurora MySQL 5.7 más reciente.

(25/03/2019) (versión 2.04)
Versión: 2.04
Aurora MySQL 2.04 ya está disponible con carácter general. Las versiones 2.x de Aurora MySQL son
Al crear un nuevo clúster de base de datos de Aurora MySQL, incluidos los restaurados a partir de
instantáneas, tiene la opción de elegir la compatibilidad con MySQL 5.7 o MySQL 5.6. No permitimos la
actualización in situ de los clústeres de Aurora MySQL 1.* ni la restauración desde una copia de seguridad

706
de Amazon S3 en Aurora MySQL 2.04.0. Tenemos previsto quitar estas restricciones en una versión
posterior de Aurora MySQL 2.*.
Puede restaurar instantáneas de Aurora MySQL 1.19.*, 2.01.*, 2.02.* y 2.03.* en Aurora MySQL 2.04.0.
No puede restaurar las instantáneas de Aurora MySQL 1.14.* o inferiores, 1.15.*, 1.16.*, 1.17.* y 1.18.* en
Aurora MySQL 2.04.0. Esta restricción se ha eliminado en Aurora MySQL 2.04.1.
Note
Esta versión no está disponible en la región AWS GovCloud (US-West) [us-gov-west-1]. Cuando
esté disponible, enviaremos una notificación aparte.
Note
MySQL (p. 697).
Mejoras
• Admisión de la replicación basada en GTID. Para obtener más información sobre la replicación
basada en GTID con Aurora MySQL, consulte Uso de replicación basada en GTID para Aurora
MySQL (p. 625).
• Solución de un problema en el que la réplica de Aurora generaba un error Running in read-only
mode cuando una instrucción que eliminaba o actualizaba filas en una tabla temporal contenía una
subconsulta de InnoDB.

• Error n.º 26225783: MYSQL SE BLOQUEA EN CREATE TABLE (CREAR TABLA) (REPRODUCIBLE) ->
INNODB: EN LA ESPERA DEL SEMÁFORO.

(07/02/2019)
Versión: 2.03.4
Al crear un nuevo clúster de base de datos de Aurora MySQL (incluida la restauración a partir de
instantáneas), puede elegir la compatibilidad con MySQL 5.7 o MySQL 5.6.
No permitimos la actualización in situ de los clústeres de Aurora MySQL 1.* a Aurora MySQL 2.03.4 ni la
restauración a Aurora MySQL 2.03.4 desde una copia de seguridad de Amazon S3. Tenemos previsto
quitar estas restricciones en una versión posterior de Aurora MySQL 2.*.
Note
Esta versión no está disponible en las regiones AWS GovCloud (US-West) [us-gov-west-1] y
China (Pekín) [cn-north-1]. Cuando esté disponible, enviaremos una notificación aparte.

707
Note
MySQL (p. 697).
Mejoras
• Admisión de la intercalación que no distingue mayúsculas y minúsculas y que distingue acentos de
UTF8MB4 Unicode 9.0, utf8mb4_0900_as_ci.

(18/01/2019)
Versión: 2.03.3
Note
Note
MySQL (p. 697).
Mejoras
• Solución de un problema en el que la réplica de Aurora podía bloquearse cuando se ejecutaba un
análisis pasado en un índice.
• Solución de un problema en el que la réplica Aurora podía reiniciarse cuando la instancia principal de
Aurora ejecutara operaciones DLL in situ en tablas particionadas.
• Solución de un problema cuando una réplica de Aurora podía reiniciarse durante la invalidación de la
caché de consultas después de una operación DDL en la instancia principal de Aurora.
• Solución de un problema cuando una réplica de Aurora podía reiniciarse durante una consulta SELECT
en una tabla cuando la instancia principal de Aurora ejecutaba un truncado en esa tabla.
• Solución de un problema de resultado erróneo con tablas temporales MyISAM en las que solo se
accedía a columnas indexadas.
• Solucionado un problema en registros lentos que generaban valores grandes incorrectos para
query_time y lock_time periódicamente después de aproximadamente 40 000 consultas.
• Solución de un problema en el que un esquema denominado "tmp" podía provocar que la migración de
RDS MySQL a Aurora MySQL se bloqueara.

708
• Solución de un problema en el que el registro de auditoría podía tener eventos que faltaban durante la
rotación de registros.
• Solución de un problema en el que la instancia principal de Aurora restaurada de una instantánea de
Aurora 5.6 podía reiniciarse cuando la característica de DDL en línea rápida en el modo de laboratorio
estaba habilitada.
• Solución de un problema en el que el uso de la CPU está originado al 100 % por el subproceso de
estadísticas del diccionario.
• Solución de un problema en el que la réplica de Aurora podía reiniciarse cuando se ejecutaba una
instrucción CHECK TABLE.

• Error n.º 25361251: COMPORTAMIENTO INCORRECTO EN LA INSERCIÓN EN LA CLAVE DE
DUPLICACIÓN EN SP
• Error n.º 26734162: COMPORTAMIENTO INCORRECTO EN LA INSERCIÓN DE BLOB + EN LA
ACTUALIZACIÓN DE LA CLAVE DE DUPLICACIÓN
• Error n.º 27460607: COMPORTAMIENTO INCORRECTO DE IODKU CUANDO LA TABLA DE ORIGEN
DE LA SELECCIÓN DE INSERCIÓN ESTÁ VACÍA
• Error n.º 22343910: LA SELECCIÓN DE UN VALOR DISTINTO NO DEVUELVE FILAS DIFERENTES
EN 5.7
• Error n.º 23074801: Eliminar de las tablas unidas donde se produce un error en el uso de la tabla
derivada con el error 1093
• Error n.º 25287633: GCOLS: COMPORTAMIENTO INCORRECTO DE LOS CAMBIOS DE CONJUNTO
DE CARACTERES.

(09/01/2019)
Versión: 2.03.2
Note
Note
MySQL (p. 697).

709
Mejoras
• Selector de versión de Aurora: a partir de Aurora MySQL 2.03.2, puede seleccionar varias versiones
de Aurora compatibles con MySQL 5.7 en la Consola de administración de AWS. Para obtener más
información, consulte Versiones del motor de Aurora MySQL (p. 696).

(24/10/2018)
Versión: 2.03.1
Al crear un nuevo clúster de base de datos de Aurora MySQL, puede elegir la compatibilidad con MySQL
5.7 o MySQL 5.6. Al restaurar una instantánea compatible con MySQL 5.6, puede elegir la compatibilidad
con MySQL 5.7 o MySQL 5.6.
Puede restaurar instantáneas de Aurora MySQL 1.14.*, 1.15.*, 1.16.*, 1.17.*, 1.18.*, 2.01.*, 2.02.* y 2.03
en Aurora MySQL 2.03.1.
Note
Mejoras
• Se ha corregido un error por el que el escritor de Aurora podía reiniciarse al ejecutar la detección de
bloqueo para transacciones.

(11/10/2018)
Versión: 2.03
Puede restaurar instantáneas de Aurora MySQL 1.14.*, 1.15.*, 1.16.*, 1.17.*, 1.18.*, 2.01.* y 2.02.* en
Aurora MySQL 2.03.
No permitimos la actualización in situ de los clústeres de Aurora MySQL 1.* a Aurora MySQL 2.03 ni la
restauración a Aurora MySQL 2.03 desde una copia de seguridad de Amazon S3. Tenemos previsto quitar
estas restricciones en una versión posterior de Aurora MySQL 2.*.

710
Note
Mejoras
• El esquema de rendimiento está disponible.
• Se ha corregido un error en el que las sesiones zombis con estado de canceladas podían consumir más
CPU.
• Se ha corregido un error de bloqueo temporal que se producía cuando una transacción de solo lectura
adquiría un bloqueo en un registro del escritor de Aurora.
• Se ha corregido un error por el que la réplica de Aurora sin carga de trabajo de clientes podía hacer un
mayor uso de la CPU.
• Se han corregido varios errores que podían provocar que la réplica de Aurora en el escritor de Aurora se
reiniciase.
• Se ha añadido una funcionalidad para omitir el registro de diagnóstico cuando se alcance el límite de
rendimiento del disco.
• Se ha corregido un error de fuga de memoria cuando binlog está habilitado en el escritor de Aurora.
Integración de correcciones de errores de la edición de la comunidad de MySQL

• REVERSE SCAN ON A PARTITIONED TABLE DOES ICP - ORDER BY DESC (error n.º 24929748).
• JSON_OBJECT CREATES INVALID JSON CODE (error n.º 26867509).
• INSERTING LARGE JSON DATA TAKES AN INORDINATE AMOUNT OF TIME (error n.º 22843444).
• PARTITIONED TABLES USE MORE MEMORY IN 5.7 THAN 5.6 (error n.º 25080442).

(08/10/2018)
Versión: 2.02.5
Aurora MySQL 2.02.5. También puede realizar una actualización in situ de Aurora MySQL 2.01.* o 2.02.* a
Aurora MySQL 2.02.5.
El esquema de rendimiento está deshabilitado para esta versión de Aurora MySQL 5.7. Actualice a Aurora
2.03 para obtener compatibilidad con el esquema de rendimiento.

711
Note
Mejoras
• Se ha corregido un error por el que la réplica de Aurora se podía reiniciar al realizar un análisis inverso
en una tabla.

(21/09/2018)
Versión: 2.02.4
Aurora MySQL 2.02.4. También puede realizar una actualización in situ de Aurora MySQL 2.01.* o 2.02.* a
Aurora MySQL 2.02.4.
Mejoras
• Se ha corregido un error de estabilidad relacionado con los índices de búsqueda de texto completo en
tablas restauradas de una instantánea de Aurora MySQL 5.6.

(23/08/2018)
Versión: 2.02.3

712
Puede restaurar instantáneas de Aurora MySQL 1.14.*, 1.15.*, 1.16.*, 1.17.*, 2.01.* y 2.02.* en Aurora
MySQL 2.02.3. También puede realizar una actualización in situ de Aurora MySQL 2.01.* o 2.02.* a Aurora
MySQL 2.02.3.
Note
Comparación con Aurora MySQL 5.6

MySQL (p. 656).

Aurora MySQL 2.01 es compatible con MySQL 5.7 e incluye características como la compatibilidad de
Aurora MySQL 2.01 no admite actualmente las siguientes características de MySQL 5.7:
• Identificadores de transacciones globales (GTID). Aurora MySQL admite GTID en la versión 2.04 y
superior.

713

• Protocolo X
Diferencias de CLI entre Aurora MySQL 2.x y Aurora MySQL 1.x

• El nombre de motor de Aurora MySQL 2.x es aurora-mysql; el nombre de motor de Aurora MySQL 1.x
sigue siendo aurora.
• La versión de motor de Aurora MySQL 2.x es 5.7.12; la versión de motor de Aurora MySQL 1.x sigue
siendo 5.6.10ann.
• El grupo de parámetros predeterminado de Aurora MySQL 2.x es default.aurora-mysql5.7; el
grupo de parámetros predeterminado de Aurora MySQL 1.x sigue siendo default.aurora5.6.
• El nombre de familia del grupo de parámetros de clúster de base de datos Aurora MySQL 2.x es
aurora-mysql5.7; el nombre de familia del grupo de parámetros de base de datos Aurora MySQL 1.x
sigue siendo aurora5.6.
Consulte en la documentación de Aurora el conjunto completo de comandos de la CLI y las diferencias

entre Aurora MySQL 2.x y Aurora MySQL 1.x.
Mejoras
• Se ha corregido un error por el que una réplica de Aurora se podía reiniciar usando restauraciones de
cursor optimistas durante la lectura de registros.
• Se ha actualizado el valor predeterminado del parámetro
innodb_stats_persistent_sample_pages a 128 para mejorar las estadísticas de índice.
• Se ha corregido un error por el que la réplica de Aurora se podía reiniciar cuando accedía a una tabla
pequeña que se estaba modificando en ese momento en la instancia principal de Aurora.
• Se ha corregido ANALYZE TABLE para detener el vaciado de la caché de definición de tabla.
• Se ha corregido un error por el que la réplica principal de Aurora o una réplica de Aurora podía
reiniciarse cuando se convertía una consulta de punto de datos geoespaciales a un intervalo de
búsqueda.

(04/06/2018)
Versión: 2.02.2
Puede restaurar instantáneas de Aurora MySQL 1.14*, 1.15*, 1.16*, 1.17*, 2.01* y 2.02 en Aurora MySQL
2.02.2. También puede realizar una actualización in situ de Aurora MySQL 2.01* o 2.02. a Aurora MySQL
2.02.2.

714
Note

MySQL (p. 656).

superior.

715

• Protocolo X

siendo 5.6.10ann.

Mejoras
• Se ha corregido un error por el que Aurora Writer se reiniciaba algunas veces al realizar un seguimiento
del progreso de las réplicas de Aurora.
• Se ha corregido un error por el que una réplica de Aurora se iniciaba o generaba un error cuando se
obtenía acceso a una tabla particionada después de ejecutar instrucciones de creación o borrado de
índices en la tabla en el escritor de Aurora.
• Se ha corregido un error por el que una tabla de una réplica de Aurora estaba inaccesible mientras se
aplicaban los cambios causados por la ejecución de las instrucciones de columna ALTER table ADD/
DROP en el escritor de Aurora.

(03/05/2018)
Versión: 2.02
Puede restaurar instantáneas de Aurora MySQL 1.14*, 1.15*, 1.16*, 1.17* y 2.01* en Aurora MySQL 2.02.
También puede realizar una actualización in situ de Aurora MySQL 2.01* a Aurora MySQL 2.02.
No permitimos la actualización in situ de los clústeres de Aurora MySQL 1.x a Aurora MySQL 2.02 ni la
estas restricciones en una versión posterior de Aurora MySQL 2.x.

716

MySQL (p. 656).

superior.
• Protocolo X


717
siendo 5.6.10ann.

Mejoras
• Se ha corregido un error por el que Aurora Writer se reiniciaba al ejecutar instrucciones INSERT y al
usar la optimización Fast Insert.
• Se ha corregido un error por el que la réplica de Aurora se reiniciaba al ejecutar instrucciones ALTER
DATABASE en la réplica de Aurora.
• Se ha corregido un error por el que Aurora Replica se reiniciaba al ejecutar consultas en tablas que se
acababan de liberar de Aurora Writer.
• Se ha corregido un error por el que la réplica de Aurora se reiniciaba al establecer
innodb_adaptive_hash_index en OFF en la réplica de Aurora.
• Se ha corregido un error por el que la réplica de Aurora se reiniciaba al ejecutar consultas TRUNCATE
TABLE en el escritor de Aurora.
• Se ha corregido un error por el que Aurora Writer se bloqueaba en algunos casos al ejecutar
instrucciones INSERT. En un clúster de varios nodos, esto podía dar lugar a una conmutación por error.
• Se ha corregido una fuga de memoria asociada con el establecimiento de variables de sesión.
• Se ha corregido un error por el que Aurora Writer se bloqueaba en algunos casos relacionados con la
anulación del purgado de tablas con columnas generadas.
• Se ha corregido un error por el que Aurora Writer se reiniciaba algunas veces al habilitar el registro
binario.

• La combinación izquierda devuelve resultados en el lado externo (error n.º 22833364).

(13/03/2018)
Versión: 2.01.1
Puede restaurar instantáneas de Aurora MySQL 1.14*, 1.15*, 1.16* y 1.17* en Aurora MySQL 2.01.1.
No permitimos la actualización in situ de los clústeres de Aurora MySQL 1.x a Aurora MySQL 2.01.1 ni
la restauración a Aurora MySQL 2.01.1 desde una copia de seguridad de Amazon S3. Tenemos previsto
quitar estas restricciones en una versión posterior de Aurora MySQL 2.x.

718

MySQL (p. 656).
Actualmente, Aurora MySQL 2.01.1 no admite las características añadidas en Aurora MySQL versión

superior.
• Protocolo X


719
siendo 5.6.10ann.

Mejoras
• Se corrigió un problema con la restauración de instantáneas por el que los permisos de base de datos
específicos de Aurora se creaban incorrectamente cuando se restauraba una instantánea compatible
con MySQL 5.6 con compatibilidad con MySQL 5.7.
• Se agregó compatibilidad con las restauraciones de instantáneas de 1.17.

(06/02/2018)
Versión: 2.01
Aurora MySQL 2.01 ya está disponible con carácter general. En el futuro, las versiones 2.x de Aurora
MySQL serán compatibles con MySQL 5.7 y las versiones 1.x de Aurora MySQL serán compatibles con
MySQL 5.6.
Al crear un nuevo clúster de base de datos de Aurora MySQL, incluidos los restaurados a partir de
instantáneas, puede elegir la compatibilidad con MySQL 5.7 o MySQL 5.6.
Puede restaurar instantáneas de Aurora MySQL 1.14*, 1.15* y 1.16* en Aurora MySQL 2.01.
No permitimos la actualización in situ de los clústeres de Aurora MySQL 1.x a Aurora MySQL 2.01 ni la
estas restricciones en una versión posterior de Aurora MySQL 2.x.

MySQL (p. 656).

720

superior.
• Protocolo X

siendo 5.6.10ann.


Amazon Aurora MySQL 1.1
A continuación se indican actualizaciones del motor de base de datos Amazon Aurora 1.1:

721
• Actualizaciones del motor de base de datos de Aurora MySQL: 13/03/2018 (p. 737) (versión 1.14.4)
• Actualizaciones del motor de base de datos de Aurora MySQL: 07/08/2017 (p. 739) (versión 1.14)
• Actualizaciones del motor de base de datos de Aurora MySQL: 10/11/2016 (p. 748) (versiones 1.9.0,
1.9.1)
• Actualizaciones del motor de base de datos de Aurora MySQL: 16/10/2015 (p. 756) (versiones 1.2, 1.3)

(05/06/2019)
versión: 1.19.2
Aurora MySQL 1.19.2 ya está disponible con carácter general. Todos los clústeres de base de datos
de Aurora MySQL nuevos compatibles con MySQL 5.6, incluidos los que se hayan restaurado a partir
de instantáneas, se pueden crear con 1.17.8, 1.19.0, 1.19.1 o 1.19.2. Tiene la opción, aunque no es
obligatorio, de actualizar clústeres de base de datos existentes a Aurora MySQL 1.19.2. Para usar una
versión anterior, puede crear nuevos clústeres de base de datos en Aurora MySQL 1.14.4, Aurora MySQL
1.15.1, Aurora MySQL 1.16, Aurora MySQL 1.17.8 o Aurora MySQL 1.18. Puede hacerlo a través de la
AWS CLI o la API de Amazon RDS y especificando la versión del motor.

722
Note
Actualmente, esta versión no está disponible en las regiones de AWS AWS GovCloud (US-West)
[us-gov-west-1], UE Estocolmo [eu-north-1], China (Ningxia) [cn-northwest-1] y Asia Pacífico
(Hong Kong) [ap-east-1]. Cuando esté disponible, enviaremos una notificación aparte.
Note
MySQL (p. 697).
Mejoras
• Se ha solucionado un problema que podía causar errores al cargar datos en Aurora desde Amazon S3.
• Se ha solucionado un problema que podía causar errores al cargar datos desde Aurora hasta Amazon
S3.
• Se ha solucionado un problema que creaba sesiones zombi con estado de canceladas.
• Se ha solucionado un problema que podía provocar un bloqueo cuando se trabajaba con tablas
particionadas.
• Se ha solucionado un problema relacionado con la replicación del binlog de la creación de
desencadenadores.

(09/05/2019)
Versión: 1.19.1
Aurora MySQL nuevos compatibles con MySQL 5.6, incluidos los que se hayan restablecido a partir
de instantáneas, se crearán con 1.17.8, 1.19.0 o 1.19.1. Tiene la opción, aunque no es obligatorio, de
actualizar clústeres de base de datos existentes a Aurora MySQL 1.19.1. Para usar una versión anterior,
puede crear nuevos clústeres de base de datos en Aurora MySQL 1.14.4, Aurora MySQL 1.15.1, Aurora
MySQL 1.16, Aurora MySQL 1.17.8 o Aurora MySQL 1.18. Puede hacerlo a través de la AWS CLI o la API
de Amazon RDS y especificando la versión del motor.
Note
Note
MySQL (p. 697).

723
Mejoras
• Corrección de un error en la replicación de binlog que provocaba problemas en las instancias de Aurora
configuradas como esclavo de binlog.
• Solución de un error en la gestión de determinados tipos de comandos ALTER TABLE.
• Solución de un problema con conexiones anuladas debido a un error en la gestión de protocolos de red.

(07/02/2019)
Versión: 1.19.0
Aurora MySQL nuevos compatibles con MySQL 5.6, incluidos los que se hayan restablecido a partir de
instantáneas, se crearán con 1.17.8 o 1.19.0. Tiene la opción, aunque no es obligatorio, de actualizar
clústeres de base de datos existentes a Aurora MySQL 1.19.0. Para usar una versión anterior, puede crear
nuevos clústeres de base de datos en Aurora MySQL 1.14.4, Aurora MySQL 1.15.1, Aurora MySQL 1.16,
Aurora MySQL 1.17.8 o Aurora MySQL 1.18.0. Puede hacerlo a través de la AWS CLI o la API de Amazon
RDS y especificando la versión del motor.
Note
Note
MySQL (p. 697).
Características
• Selector de versión de Aurora: a partir de Aurora MySQL 1.19.0, puede seleccionar varias versiones
de Aurora compatibles con MySQL 5.6 en la consola de Amazon RDS. Para obtener más información,
consulte Versiones del motor de Aurora MySQL (p. 696).
Mejoras
• Solución de un problema de estabilidad relacionado con la consulta CHECK TABLE en una réplica de
Aurora.
• Introducción de una nueva variable de usuario global aurora_disable_hash_join para deshabilitar
el operador hash join.
• Solución de un problema de estabilidad cuando se genera la fila de salida durante varios operadores
hash join de tabla.
• Solución de un problema en el que se devolvía un resultado erróneo debido a un cambio de plan durante
la comprobación de aplicabilidad del operador hash join.
• La característica de creación de parches sin actividad es compatible con las transacciones de
ejecuciones prolongadas. Esta mejora se aplicará cuando se actualice de la versión 1.19 a una superior.

724
• La característica de creación de parches sin actividad es ahora compatible cuando binlog está habilitado.
Esta mejora se aplicará cuando se actualice de la versión 1.19 a una superior.
• Solución de un problema que provocaba un pico en el uso de la CPU en le réplica de Aurora no
relacionada con la carga de trabajo.
• Solución de una condición de carrera en el administrador de bloqueos que generaba el reinicio de la
base de datos.
• Solución de una condición de carrera en el administrador de bloqueos para mejorar la estabilidad de las
instancias de Aurora.
• Mejora de la estabilidad del detector de bloqueos dentro del componente del administrador de bloqueos.
• Prohibición de la operación INSERT en una tabla si InnoDB detecta que el índice está dañado.
• Solución de un problema de estabilidad en DLL rápida.
• Mejora de la estabilidad de Aurora mediante la reducción del consumo de memoria en una agrupación
en lotes de análisis para una subconsulta de una sola fila.
• Solución de un problema de estabilidad que se generaba después de eliminar una clave externa cuando
la variable del sistema foreign_key_checks se establecía en 0.
• Solución de un problema en la característica de prevención de memoria insuficiente en el que se
sobrescribían erróneamente los cambios en el valor table_definition_cache realizados por el
usuario.
• Solución de problemas de estabilidad en la característica de prevención de memoria insuficiente.
• Solución de un problema que establecía query_time y lock_time en slow_query_log en valores
no utilizados.
• Solución de un problema de estabilidad de consulta en paralelo activada por la gestión inadecuada de la
intercalación de cadenas internamente.
• Solución de un problema de estabilidad de consulta en paralelo generado por una búsqueda de índice
secundario.
• Solución de un problema de estabilidad de consulta en paralelo generado por una actualización de
varias tablas.

• ERROR N.º 32917: DETECTAR ARCHIVOS DE GRUPO TEMPORAL HUÉRFANOS Y
GESTIONARLOS CON FLUIDEZ
• ERROR N.º 63144: CREAR TABLA SI NO EXISTE BLOQUEO DE METADATOS DEMASIADO
RESTRICTIVO

(20/09/2018)
Versión: 1.18.0
instantáneas, se crearán en Aurora MySQL 1.18.0. Tiene la opción, aunque no es obligatorio, de actualizar
clústeres de base de datos existentes a Aurora MySQL 1.18.0. Puede crear nuevos clústeres de base de
datos en Aurora MySQL 1.14.4, Aurora MySQL 1.15.1, Aurora MySQL 1.16 o Aurora MySQL 1.17.6. Puede
hacerlo a través de la AWS CLI o la API de Amazon RDS y especificando la versión del motor.
Con la versión 1.18.0 de Aurora MySQL, estamos utilizando un modelo de aplicación de parches en
clúster. Se aplican parches a todos los nodos de un clúster de base de datos Aurora al mismo tiempo.

725
Características
• Parallel Query está disponible con esta versión para nuevos usuarios e instantáneas restauradas. La
consulta paralela de Aurora MySQL es una optimización que paraleliza algunos de los cálculos y E/S
del procesamiento de consultas con un uso intensivo de datos. El trabajo que se paraleliza incluye la
recuperación de filas del almacenamiento, la extracción de valores de columna y la determinación de
qué filas coinciden con las condiciones de la cláusula WHERE y de las cláusulas JOIN. Este trabajo con
uso intensivo de los datos se delega (en términos de optimización de base de datos, se baja de posición)
a varios nodos de la capa de almacenamiento distribuido de Aurora. Sin una consulta paralela, cada
consulta transfiere todos los datos analizados a un solo nodo del clúster de Aurora MySQL (el nodo
principal) y realiza ahí todos los procesamientos de consultas.
• Cuando hay habilitada una característica de consulta en paralelo, el motor de Aurora MySQL
determina automáticamente cuándo las consultas pueden aprovecharla, sin requerir cambios de SQL
como sugerencias o atributos de tabla.
Para obtener más información, consulte Trabajar con Consultas en paralelo de Amazon Aurora
MySQL (p. 566).
• OOM Avoidance (Prevención de OOM): esta característica supervisa la memoria del sistema y realiza
un seguimiento de la memoria que consumen varios componentes de la base de datos. Una vez que el
sistema funciona con poca memoria, realiza una lista de acciones para liberar esa memoria de varios
de los componentes sometidos a un seguimiento para tratar de evitar que la base de datos se quede
sin memoria (OOM) y, por tanto, se reinicie. Esta característica de mejor esfuerzo está habilitada de
forma predeterminada para las instancias t2 y puede habilitarse en otros tipos de instancia mediante
un nuevo parámetro de instancia llamado aurora_oom_response. El parámetro de nivel de instancia
toma una cadena de acciones separadas por comas que una instancia de base de datos debe realizar
cuando el nivel de memoria es bajo. Entre las acciones válidas se encuentran "print", "tune", "decline",
"kill_query" o cualquier combinación de estas. La existencia de una cadena vacía significa que no se
deberían haber tomado acciones y deshabilita de forma eficaz la característica. Tenga en cuenta que la
acción predeterminada de la característica es "print, tune". Ejemplo de uso:
• "print": solo imprime las consultas que consumen una gran cantidad de memoria.
• "tune": ajusta las cachés de tablas internas para liberar memoria en el sistema.
• "decline": declina nuevas consultas una vez que la instancia tiene poca memoria.
• "kill_query": anula las consultas en orden descendente de consumo de memoria hasta que la memoria
de la instancia esté por encima del umbral bajo. Las instrucciones en lenguaje de definición de datos
(DDL) no se cancelan.
• "print, tune": realiza las acciones descritas para "print" y "tune".
• "tune, decline, kill_query": realiza las acciones descritas para "tune", "decline", and "kill_query".
Para obtener más información sobre la gestión de las condiciones de memoria insuficiente y otros
consejos de solución de problemas, consulte Problemas de memoria insuficiente de Amazon Aurora
MySQL (p. 895).

(17/01/2019)
Versión: 1.17.8

726
nuevos clústeres de base de datos en Aurora MySQL 1.14.4, 1.15.1, 1.16 o 1.17.7. Puede hacerlo a través
de la AWS CLI o la API de Amazon RDS y especificando la versión del motor.
Note
Mejoras
• Se ha solucionado un error de rendimiento que incrementaba el uso de la CPU en una réplica de Aurora
tras reiniciar.
• Se ha solucionado un problema se estabilidad para consultas SELECT que utilizan unión de hash.

• BUG #13418638: CREAR TABLA SI NO EXISTE BLOQUEO DE METADATOS DEMASIADO
RESTRICTIVO

(08/10/2018)
Versión: 1.17.7
Note
Mejoras
• La variable de estado InnoDB innodb_buffer_pool_size ya es visible públicamente para que los
clientes puedan modificarla.

727
• Se ha corregido un problema en el clúster de Aurora que se producía durante las conmutaciones por
error.
• Se ha mejorado la disponibilidad del clúster corrigiendo un problema de recuperación DDL que se
producía después de una operación TRUNCATE.
• Se ha corregido un problema de estabilidad relacionado con la actualización de la tabla
mysql.innodb_table_stats, que se activa mediante las operaciones DDL.
• Se han corregido problemas de estabilidad de la réplica de Aurora producidos durante la invalidación de
la caché de consultas después de una operación DDL.
• Se ha corregido un problema de estabilidad producido por un acceso a la memoria no válido durante la
expulsión de la caché de diccionario periódica en segundo plano.

• Error n.º 16208542: La operación DROP INDEX en una columna de clave externa provoca la ausencia
de una tabla.
• Error n.º 76349: fuga de memoria en add_derived_key().
• Error n.º 16862316: Para tablas con particiones, las consultas podrían devolver resultados diferentes en
función de su si se usó Index Merge.
• Error n.º 17588348: Las consultas que usan la optimización (consulte Index Merge Optimization) podrían
devolver resultados no válidos cuando se ejecutan en tablas particionadas con HASH.

(06/09/2018)
Versión: 1.17.6
Note
Mejoras
• Se ha corregido un problema de estabilidad en el lector de Aurora con las consultas SELECT mientras
que el escritor de Aurora está realizando operaciones DDL en la misma tabla.
• Se ha corregido un problema de estabilidad debido a la creación y eliminación de los registros DDL de
tablas temporales que usan el motor en memoria o montón.
• Se ha corregido un problema de estabilidad en el esclavo de binlog cuando las instrucciones DDL se
replicaban mientras la conexión al maestro de binlog era inestable.

728
• Se ha corregido un problema de estabilidad producido al escribir en el registro de consultas lentas.

• Se ha corregido un error con la tabla de estado de réplica que mostraba información incorrecta del LAG
del lector de Aurora.

• Para una instrucciónALTER TABLE a la que se le cambió el nombre o modificó el valor predeterminado
de una columna BINARY, la alteración se realizó usando una copia de tabla y no in situ. (Error n.º 67141,
error n.º 14735373, error n.º 69580 y error n.º 17024290)
• Una unión exterior entre una tabla normal y una derivada que son implícitamente grupos podría provocar
una salida del servidor. (Error n.º 16177639)

(14/08/2018)
Versión: 1.17.5
Note
Mejoras
• Se ha corregido un problema en el que un escritor de Aurora podría experimentar un reinicio después de
aplicar un parche en un clúster de Aurora usando la característica Aplicación de parches sin tiempo de
inactividad.

(07/08/2018)
Versión: 1.17.4

729
Note
Mejoras
• Mejoras de la replicación:
• Reducción del tráfico de red, porque no se transmiten los registros binlog a las réplicas del clúster.
Esta mejora está habilitada de forma predeterminada.
• Reducción del tráfico de red, porque se comprimen los mensajes de replicación. Esta mejora está
habilitada de forma predeterminada para las clases de instancia 8xlarge y 16xlarge. Estas instancias
tan grandes pueden soportar un volumen intenso de tráfico de escritura que da lugar a un tráfico de
red sustancial para los mensajes de replicación.
• Correcciones en la caché de consultas de réplica.
• Se ha corregido un problema que hacía que ORDER BY LOWER(col_name) pudiese producir un orden
incorrecto al usar la intercalación utf8_bin.
• Se ha corregido un problema que hacía que las instrucciones DDL (sobre todo las TRUNCATE TABLE)
pudieran causar problemas en las réplicas de Aurora, tales como inestabilidad o tablas ausentes.
• Se ha corregido un problema que hacía que los sockets quedasen en un estado semiabierto al reiniciar
los nodos de almacenamiento.
• Están disponibles los siguientes nuevos parámetros de clúster de base de datos:
• aurora_enable_zdr: permite conexiones abiertas en una réplica de Aurora para mantenerse activa
durante el reinicio de la réplica.
• aurora_enable_replica_log_compression: habilita la compresión de las cargas de replicación
para mejorar el uso del ancho de banda de red entre las réplicas maestra y de Aurora.
• aurora_enable_repl_bin_log_filtering: habilita el filtro de registros de replicación que no
pueden usar las réplicas de Aurora en el maestro.

(05/06/2018)
Versión: 1.17.3
datos en Aurora MySQL 1.14.4, Aurora MySQL 1.15.1 o Aurora MySQL 1.16. Puede hacerlo a través de la
Note

730
Mejoras
• Se ha corregido un error por el que una réplica de Aurora se podía reiniciar usando restauraciones de
cursor optimistas durante la lectura de registros.
• Se ha corregido un error por el que un escritor de Aurora se reiniciaba al intentar terminar una sesión de
MySQL (kill "<ID de sesión>") con el esquema de rendimiento habilitado.
• Se ha corregido un error por el que Aurora Writer se reiniciaba al calcular un umbral para la recopilación
de elementos no utilizados.
• Se ha corregido un error por el que un escritor de Aurora se reiniciaba algunas veces al realizar un
seguimiento de una réplica de Aurora en la aplicación log.
• Se ha corregido un error con la caché de consultas cuando la confirmación automática estaba
desactivada que podía causar lecturas obsoletas.

(27/04/2018)
Versión: 1.17.2
datos en Aurora MySQL 1.14.4, Aurora MySQL 1.15.1 o Aurora MySQL 1.16. Puede hacerlo a través de la
Mejoras
• Se ha corregido un problema que causaba reinicios durante determinadas operaciones de partición de
DDL.
• Se ha corregido un problema que hacía que se deshabilitara la opción para invocar funciones de AWS
Lambda a través de funciones de Aurora MySQL nativas.
• Se ha corregido un problema con la invalidación de la caché que causaba reinicios en las réplicas de
Aurora.
• Se ha corregido un problema en el administrador de bloqueos que causaba reinicios.

(23/03/2018)
Versión: 1.17.1
Aurora MySQL 1.17.1 ya está disponible con carácter general. Todos los clústeres de bases de datos
nuevos, incluidos los que se hayan restablecido a partir de instantáneas, se crearán en Aurora MySQL

731
1.17.1. Tiene la opción, aunque no es obligatorio, de actualizar clústeres de base de datos existentes a
Aurora MySQL 1.17.1. Puede crear nuevos clústeres de base de datos en Aurora MySQL 1.15.1, Aurora
MySQL 1.16, o Aurora MySQL 1.17. Puede hacerlo a través de la AWS CLI o la API de Amazon RDS y
especificando la versión del motor.
clúster. Se aplican parches a todos los nodos de un clúster de base de datos Aurora al mismo tiempo. En
esta versión se corrigen algunos problemas de motor conocidos, además de aplicar regresiones.
Note
Hay un problema en la última versión del motor de Aurora MySQL. Después de la actualización a
1.17.1, la versión del motor se notifica incorrectamente como 1.17. Si actualizó a 1.17.1, puede
confirmar la actualización marcando la columna Maintenance (Mantenimiento) para el clúster
de base de datos en la Consola de administración de AWS. Si muestra none, el motor se ha
actualizado a 1.17.1.
Mejoras
• Se corrigió un problema en la recuperación de log binario que prolongaba los tiempos de recuperación
en las situaciones con archivos de índice de log binario grandes, lo que podía suceder si los logs
binarios se alternaban con mucha frecuencia.
• Se corrigió un problema en el optimizador de consultas que generaba un plan de consultas poco eficaz
para las tablas particionadas.
• Se corrigió un problema en el optimizador de consultas debido al cual se generaba una consulta de
intervalo en el reinicio del motor de base de datos.

(13/03/2018)
Versión: 1.17
Aurora MySQL 1.17 ya está disponible con carácter general. Las versiones 1.x de Aurora MySQL
son compatibles con MySQL 5.6 y no con MySQL 5.7. Todos los clústeres de bases de datos nuevos
compatibles con la versión 5.6, incluidos los que se hayan restablecido a partir de instantáneas, se crearán
en Aurora 1.17. Tiene la opción, aunque no es obligatorio, de actualizar clústeres de base de datos
existentes a Aurora 1.17. Puede crear nuevos clústeres de base de datos en Aurora 1.14.1, Aurora 1.15.1
o Aurora 1.16. Puede hacerlo a través de la CLI de AWS o la API de Amazon RDS y especificando la
versión del motor.
Con la versión 1.17 de Aurora, estamos utilizando un modelo de aplicación de parches en clúster. Se
aplican parches a todos los nodos de un clúster de base de datos Aurora al mismo tiempo. Admitimos la
aplicación de parches sin tiempo de inactividad, en la medida de lo posible, para conservar las conexiones
de cliente durante este proceso. Para obtener más información, consulte Mantenimiento de un clúster de
AWS Premium Support.

La aplicación de parches sin tiempo de inactividad (ZDP) intenta, en la medida de lo posible conservar las
conexiones de cliente a través de un parche en el motor. Para obtener más información acerca de ZDP,
consulte Aplicación de parches sin tiempo de inactividad (p. 698).

732
Nuevas características
• Aurora MySQL ahora admite la compresión de bloqueo, que optimiza el uso de memoria del
administrador de bloqueos. A partir de la versión 1.17, puede usar esta característica sin habilitar el
modo lab.
Mejoras
• Se corrigió un problema que se ha observado principalmente en las instancias con pocos núcleos por
el que un solo núcleo podría tener una utilización del 100 % de la CPU, aunque la base de datos esté
inactiva.
• Se mejoró el desempeño de la obtención de logs binarios de los clústeres de Aurora.
• Se corrigió un problema por el que las réplicas de Aurora intentan escribir estadísticas de tabla en el
almacenamiento persistente y se bloquean.
• Se corrigió un problema por el que la memoria caché de consultas no funcionaba del modo previsto en
las réplicas de Aurora.
• Se corrigió una condición de carrera en el administrador de bloqueos que generaba el reinicio del motor.
• Se corrigió un problema por el que los bloqueos que tomaban las transacciones de solo lectura y
confirmación automática generaban un reinicio del motor.
• Se corrigió un problema por el que algunas consultas no se escriben en los logs de auditoría.
• Se corrigió un problema en la recuperación de determinadas operaciones de mantenimiento de
particiones en la conmutación por error.

• LAST_INSERT_ID se replica incorrectamente si se usan filtros de replicación (error n.º 69861)
• La consulta devuelve resultados distintos en función de la configuración INDEX_MERGE (error n.º
16862316)
• Nueva ejecución de procedimiento de consulta de la rutina almacenada, plan de consulta poco eficiente
(error n.º 16346367)
• INNODB FTS: confirmación en FTS_CACHE_APPEND_DELETED_DOC_IDS (error n.º 18079671)
• Confirmación RBT_EMPTY(INDEX_CACHE->WORDS) en ALTER TABLE CHANGE COLUMN (error n.º
17536995)
• La búsqueda de texto completo de INNODB no encuentra ningún registro cuando hay puntos de
guardado (error n.º 70333, error n.º 17458835)

(11/12/2017)
Versión: 1.16
Aurora MySQL 1.16 ya está disponible con carácter general. Todos los clústeres de bases de datos
nuevos, incluidos los que se hayan restablecido a partir de instantáneas, se crearán en Aurora 1.16. Tiene
la opción, aunque no es obligatorio, de actualizar clústeres de base de datos existentes a Aurora 1.16.
Puede crear nuevos clústeres de base de datos en Aurora 1.14.1 o Aurora 1.15.1. Puede hacerlo a través
Con la versión 1.16 de Aurora, estamos utilizando un modelo de aplicación de parches en clúster. Se
aplican parches a todos los nodos de un clúster de base de datos Aurora al mismo tiempo. Estamos
habilitando la aplicación de parches sin tiempo de inactividad, en la medida de lo posible, para conservar

733
las conexiones de cliente durante este proceso. Para obtener más información, consulte Mantenimiento de
AWS Premium Support en http://aws.amazon.com/support.

• Aurora MySQL admite ahora invocaciones de AWS Lambda síncronas a través de la función nativa
lambda_sync(). También está disponible la función nativa lambda_async(), que se puede utilizar
como alternativa al procedimiento almacenado existente para invocación a Lambda asíncrona. Para
obtener más información, consulte Invocación de una función de Lambda desde un clúster de base de
datos Amazon Aurora MySQL (p. 655).
• Aurora MySQL ahora admite combinaciones hash para acelerar las consultas equijoin. Aunque el
optimizador basado en el costo de Aurora puede decidir automáticamente cuándo se deben utilizar
combinaciones hash, también es posible forzar su uso en un plan de consultas. Para obtener más
información, consulte Trabajo con combinaciones hash en Aurora MySQL (p. 675).
• Aurora MySQL admite ahora la agrupación en lotes de análisis para acelerar significativamente las
consultas en memoria orientadas a análisis. Esta característica aumenta el desempeño de los análisis
completos de tablas, los análisis completos de índices y los análisis de rangos de índices mediante el
procesamiento por lotes.
Mejoras
• Se ha corregido un error donde las réplicas de lectura se bloqueaban al ejecutar consultas en tablas que
se acababan de soltar en el maestro.
• Se ha corregido un problema al reiniciar el escritor en un clúster de base de datos con un número muy
grande de índices FULLTEXT da lugar a una recuperación que tarda más de lo previsto.
• Se ha corregido un problema donde el vaciado de registros binarios provoca incidentes LOST_EVENTS
en eventos de binlog.
• Se han corregido problemas de estabilidad con el programador cuando está habilitado el esquema de
desempeño.
• Se ha corregido un problema donde una subconsulta que utiliza tablas temporales podría devolver
resultados parciales.

Ninguna

(20/11/2017)
Versión: 1.15.1
nuevos, incluidos los que se hayan restablecido a partir de instantáneas, se crearán en Aurora 1.15.1.
Tiene la opción, aunque no es obligatorio, de actualizar clústeres de base de datos existentes a Aurora

734
1.15.1. Puede crear nuevos clústeres de base de datos en Aurora 1.14.1. Puede hacerlo a través de la
Con la versión 1.15.1 de Aurora, estamos utilizando un modelo de aplicación de parches en clúster. Se
aplican parches a todos los nodos de un clúster de base de datos Aurora al mismo tiempo. Estamos
habilitando la aplicación de parches sin tiempo de inactividad, en la medida de lo posible, para conservar
las conexiones de cliente durante este proceso. Para obtener más información, consulte Mantenimiento de
Si tiene alguna duda, el equipo de AWS Support está disponible en los foros de la comunidad y a través
de AWS Premium Support en http://aws.amazon.com/support. Para obtener más información, consulte
Mantenimiento de un clúster de base de datos de Amazon Aurora (p. 340).

Mejoras
• Se ha corregido un problema del selector de segmentos adaptativo por el que una solicitud de
lectura podía elegir el mismo segmento dos veces y crear un pico en la latencia de lectura en ciertas
condiciones.
• Se ha corregido un problema que se producía por una optimización de Aurora MySQL para el
programador de subprocesos. Este problema se manifiesta en la aparición de errores falsos al escribir
en el registro lento mientras que las consultas asociadas se ejecutan correctamente.
• Se ha corregido un problema en la estabilidad de las réplicas de lectura en volúmenes grandes (> 5 TB).
• Se ha corregido un problema en el que el recuento de subprocesos de empleado se incrementa
continuamente debido a un recuento falso de las conexiones pendientes.
• Se ha corregido un problema de los bloqueos de tabla que provocaba esperas de semáforo prolongadas
durante las cargas de trabajo de inserción.
• Se han revertido las siguientes correcciones de errores de MySQL en Aurora MySQL 1.15:
• La instancia de MySQL se paraliza “realizando el índice SYNC” (error n.º 73816)
• Confirmación RBT_EMPTY(INDEX_CACHE->WORDS) en ALTER TABLE CHANGE COLUMN (error
n.º 17536995)
• La búsqueda de Fulltext de InnoDB no encuentra ningún registro cuando hay puntos de guardado
(error n.º 70333)

Ninguna

(24/10/2017)
Versión: 1.15
nuevos, incluidos los que se hayan restablecido a partir de instantáneas, se crearán en Aurora 1.15. Tiene
la opción, aunque no es obligatorio, de actualizar clústeres de base de datos existentes a Aurora 1.15.
Puede crear nuevos clústeres de base de datos en Aurora 1.14.1. Puede hacerlo a través de la AWS CLI o
la API de Amazon RDS y especificando la versión del motor.

735
Con la versión 1.15 de Aurora, estamos utilizando un modelo de aplicación de parches en clúster.
Se aplican parches a todos los nodos de un clúster de base de datos Aurora al mismo tiempo. Las
actualizaciones exigen el reinicio de la base de datos, por lo que se producirán entre 20 y 30 segundos
de inactividad. A continuación, podrá volver a utilizar los clústeres de la base de datos. Si los clústeres de
base de datos están ejecutando actualmente Aurora 1.14 o Aurora 1.14.1, la característica de aplicación
de parches sin tiempo de inactividad de Aurora MySQL podría permitir que las conexiones cliente con
la instancia principal de Aurora MySQL persistieran durante la actualización, en función de la carga de
trabajo.

• Captura previa de clave asíncrona: la captura previa de clave asíncrona (AKP) es una característica
destinada a mejorar el rendimiento de las combinaciones de índices sin almacenar en caché; para ello,
efectúa una captura previa de las claves en la memoria antes de que sean necesarias. El principal
caso de uso para el que está destinada la AKP es una combinación de índices entre una tabla exterior
pequeña y una interior grande, donde el índice es sumamente selectivo en la tabla grande. Asimismo,
si está habilitada la interfaz Multi-Range Read (MRR), AKP se utilizará para llevar a cabo una búsqueda
del índice secundario al primario. Es posible que, en algunos casos, las instancias más pequeñas
que tienen restricciones de memoria puedan utilizar AKP, dada la cardinalidad de claves correcta.
Para obtener más información, consulte Uso de la captura previa de clave asíncrona en Amazon
Aurora (p. 669).
• DDL rápida: hemos ampliado la característica que se introdujo en Aurora 1.13 (p. 740) a las
operaciones que incluyen valores predeterminados. Con esta extensión, la DDL rápida se aplica a
operaciones que añaden una columna que se puede anular, con o sin un valor predeterminado, al final
de una tabla. La característica sigue estando en el modo lab de Aurora. Para obtener más información,
consulte Modificación de las tablas de Amazon Aurora con operaciones DDL rápidas (p. 564).
Mejoras
• Se ha solucionado un error de cálculo durante la optimización de consultas espaciales WITHIN/
CONTAINS que anteriormente producían un conjunto de resultados vacío.
• Se ha corregido el comando SHOW VARIABLE para mostrar el valor del parámetro
innodb_buffer_pool_size actualizado cada vez que se cambia en el grupo de parámetros.
• Se ha mejorado la estabilidad de la instancia principal durante la inserción masiva en un tabla que se ha
modificado mediante DDL rápida cuando la indexación hash adaptativa está deshabilitada y el registro
que se va a insertar es el primero de una página.
• Se ha mejorado la estabilidad de Aurora cuando el usuario intenta establecer el valor del parámetro del
clúster de base de datos server_audit_events en default.
• Se ha solucionado un problema que producía que un cambio en el conjunto de caracteres de la base de
datos para una instrucción ALTER TABLE que estuviera ejecutándose en la instancia principal de Aurora
no se replicara en las réplicas de Aurora hasta que se reiniciaban.
• Se ha mejorado la estabilidad solucionando una condición de carrera en la instancia principal que
anteriormente le permitía registrar una réplica de Aurora aunque la instancia principal hubiera cerrado su
propio volumen.

736
• Se ha mejorado el rendimiento de la instancia principal durante la creación de índices en una tabla de

gran tamaño cambiando el protocolo de bloqueo para permitir instrucciones en lenguaje de manipulación
de datos (DML) simultáneas durante la creación del índice.
• Se ha solucionado una incoherencia de los metadatos de InnoDB durante la consulta ALTER TABLE
RENAME que ha mejorado la estabilidad. Ejemplo: cuando se cambia cíclicamente el nombre de las
columnas de la tabla t1(c1, c2) a t1(c2,c3) dentro de la misma instrucción ALTER.
• Se ha mejorado la estabilidad de las réplicas de Aurora cuando una réplica de Aurora no tiene ninguna
carga de trabajo activa y la instancia principal no responde.
• Se ha mejorado la disponibilidad de las réplicas de Aurora cuando la réplica de Aurora mantiene un
bloqueo explícito en una tabla y bloquea el subproceso de replicación para evitar que aplique ningún
cambio de DDL que se reciba de la instancia principal.
• Se ha mejorado la estabilidad de la instancia principal cuando se añaden una clave externa y una
columna a una tabla al mismo tiempo desde dos sesiones distintas y la DDL rápida está habilitada.
• Se ha mejorado la estabilidad del subproceso de purga en la instancia principal cuando hay mucha
carga de trabajo de escritura bloqueando el truncado de los registros de deshacer hasta que se hayan
purgado.
• Se ha mejorado la estabilidad corrigiendo la orden de liberación del bloqueo durante el proceso de
confirmación de transacciones que borran tablas.
• Se ha corregido un defecto de las réplicas de Aurora por el cual la instancia de base de datos no podía
completar el inicio y avisaba de que ya se estaba utilizando el puerto 3306.
• Se ha corregido una condición de carrera en la que una consulta SELECT se ejecutaba en determinadas
tablas information_schema (innodb_trx, innodb_lock, innodb_lock_waits) y aumentaba la inestabilidad del
clúster.

• CREATE USER acepta el hash de contraseña y complemento, pero no el hash de contraseña (error n.º
78033)
• El motor de partición añade campos al conjunto de bits de lectura para poder devolver entradas
ordenadas desde un índice particionado. Debido a esto, el búfer de combinaciones intenta leer campos
innecesarios. Se ha solucionado este problema no añadiendo todos los campos de la partición a
read_set, sino que solo se realiza la ordenación en los campos de prefijo ya establecidos en read_set.
Se ha añadido un DBUG_ASSERT que, si realiza key_cmp, se debe leer al menos el primer campo
(error n.º 16367691).
• La instancia de MySQL se paraliza “realizando el índice SYNC” (error n.º 73816)
• Confirmación RBT_EMPTY(INDEX_CACHE->WORDS) en ALTER TABLE CHANGE COLUMN (error n.º
17536995)
• La búsqueda de Fulltext de InnoDB no encuentra ningún registro cuando hay puntos de guardado (error
n.º 70333)
Actualizaciones del motor de base de datos de Aurora MySQL:

13/03/2018
Versión: 1.14.4
Aurora MySQL 1.14.4 ya está disponible con carácter general. Puede crear nuevos clústeres de base de
datos en Aurora 1.14.4 mediante la CLI de AWS o la API de Amazon RDS y especificando la versión del
motor. Tiene la opción, aunque no es obligatorio, de actualizar clústeres de base de datos 1.14.x existentes
a Aurora 1.14.4.
Con la versión 1.14.4 de Aurora, estamos utilizando un modelo de aplicación de parches en un clúster. Se
aplican parches a todos los nodos de un clúster de base de datos Aurora al mismo tiempo. Admitimos la

737
aplicación de parches sin tiempo de inactividad, en la medida de lo posible, para conservar las conexiones
de cliente durante este proceso. Para obtener más información, consulte Mantenimiento de un clúster de

• Aurora MySQL ahora admite las clases de instancia db.r4.
Mejoras
• Se corrigió un problema por el que se generaban LOST_EVENTS al escribir eventos de log binario
grandes.

• Los eventos que se pueden ignorar no funcionan y no se prueban (error n.º 74683)
• NEW->OLD ASSERT FAILURE 'GTID_MODE > 0' (error n.º 20436436)

22/09/2017
Versión: 1.14.1
1.14.1. Aurora MySQL 1.14.1 también es una actualización obligatoria para los clústeres de bases de
datos existentes de Aurora MySQL. Para obtener más información, consulte Announcement: Extension
to Mandatory Upgrade Schedule for Amazon Aurora en el sitio web de los foros para desarrolladores de
AWS.
clúster. Se aplican parches a todos los nodos de un clúster de base de datos Aurora MySQL al mismo
tiempo. Las actualizaciones exigen el reinicio de la base de datos, por lo que se producirán entre 20 y
30 segundos de inactividad. A continuación, podrá volver a utilizar los clústeres de la base de datos. Si
los clústeres de base de datos están ejecutando actualmente la versión 1.13 o posterior, la característica
de aplicación de parches sin tiempo de inactividad de Aurora MySQL podría permitir que las conexiones
cliente con la instancia principal de Aurora MySQL persistieran durante la actualización, en función de la
carga de trabajo.
Mejoras
• Se han corregido las condiciones de carrera asociadas a las inserciones y la purga para mejorar la
estabilidad de la característica de DDL rápida, que sigue estando en el modo lab de Aurora MySQL.

738

07/08/2017
Versión: 1.14
1.14. Aurora MySQL 1.14 también es una actualización obligatoria para los clústeres de bases de datos
existentes de Aurora MySQL. Enviaremos una notificación con el calendario para declarar obsoletas las
versiones anteriores de Aurora MySQL.
Con la versión 1.14 de Aurora MySQL, estamos utilizando un modelo de aplicación de parches en clúster.
Se aplican parches a todos los nodos de un clúster de base de datos Aurora al mismo tiempo. Las
actualizaciones exigen el reinicio de la base de datos, por lo que se producirán entre 20 y 30 segundos
de inactividad. A continuación, podrá volver a utilizar los clústeres de la base de datos. Si los clústeres de
base de datos están ejecutando actualmente la versión 1.13, la característica de aplicación de parches
sin tiempo de inactividad de Aurora podría permitir que las conexiones cliente con la instancia principal de
Aurora persistieran durante la actualización, en función de la carga de trabajo.

Mejoras
• Se ha corregido un error incorrecto de "no se encuentra el registro" que se produce cuando se encuentra
un registro en el índice secundario pero no en el principal.
• Se ha solucionado un problema de estabilidad que se puede producir si una aserción defensiva (añadida
en la versión 1.12) es demasiado fuerte cuando una escritura individual abarca más de 32 páginas. Esta
situación se puede producir, por ejemplo, con valores BLOB de gran tamaño.
• Se ha solucionado un problema de estabilidad debido a incoherencias entre la caché del espacio de
tabla y la caché del diccionario.
• Se ha solucionado un problema en el que una réplica de Aurora deja de responder después de que
supere el número máximo de intentos de conexión a la instancia principal. Ahora una réplica de Aurora
se reinicia si el período de inactividad supera el período de tiempo de un latido que utiliza la instancia
principal para la comprobación de estado.
• Se ha solucionado un bloqueo en directo que se puede producir en condiciones de simultaneidad muy
alta cuando una conexión intenta adquirir un bloqueo de metadatos (MDL) exclusivo mientras se emite
un comando, como ALTER TABLE.
• Se ha solucionado un problema de estabilidad en una réplica de lectura de Aurora en presencia de
lecturas anticipadas lógicas/paralelas.
• Se ha mejorado LOAD FROM S3 de dos formas:
1. Mejor control de los errores de tiempo de espera de Amazon S3 utilizando la operación de reintento
de SDK además de la operación de reintento existente.
2. Optimización del desempeño al cargar archivos muy grandes o un gran número de archivos
almacenando en caché y reutilizando el estado del cliente.
• Se han solucionado los siguientes problemas de estabilidad con la característica de DDL rápida para las
operaciones ALTER TABLE:
1. Cuando la instrucción ALTER TABLE tiene varios comandos ADD COLUMN y los nombres de las
columnas no están en orden ascendente.

739
2. Cuando la cadena del nombre de la columna que se va a actualizar y su cadena de nombre

correspondiente, que se obtienen de la tabla del sistema interna, son diferentes en un carácter de
terminación nulo (/0).
3. En determinadas operaciones de división de árbol B.
4. Cuando la tabla tiene una clave principal de longitud variable.
• Se ha solucionado un problema de estabilidad con las réplicas de Aurora cuando se tarda demasiado
en conseguir que su caché del índice de búsqueda de texto completo (FTS) sea coherente con la de
la instancia principal. Esto puede ocurrir si aún no se han vaciado en el disco una gran parte de las
entradas del índice FTS que se acaban de crear en la instancia principal.
• Se ha solucionado un problema se estabilidad que se puede producir durante la creación de índices.
• Nueva infraestructura que realiza un seguimiento del consumo de memoria por conexión y la telemetría
asociada que se utilizarán para crear estrategias para evitar problemas de falta de memoria (OOM).
• Se ha solucionado un problema en el que ANALYZE TABLE se permitía incorrectamente en las réplicas
de Aurora. Ahora se ha bloqueado.
• Se ha solucionado un problema de estabilidad provocado por un interbloqueo extraño como resultado de
una condición de carrera entre una lectura anticipada lógica y la purga.

• Una búsqueda de texto completo combinada con tablas derivadas (subconsultas de la cláusula FROM)
producía una salida del servidor. Ahora, si una operación de texto completo depende de una tabla
derivada, el servidor produce un error que indica que no se puede realizar una búsqueda de texto
completo en una tabla materializada. (Error n.º 68751 y error n.º 16539903)

15/05/2017
Versión: 1.13
Note
Hemos habilitado una nueva característica, SELECT INTO OUTFILE S3, en Aurora MySQL
versión 1.13 después del lanzamiento inicial y hemos actualizado las notas de la versión para
reflejar ese cambio.
1.13. Tiene la opción, aunque no es obligatorio, de actualizar clústeres de base de datos existentes
a Aurora MySQL 1.13. Con la versión 1.13 de Aurora, estamos utilizando un modelo de aplicación de
parches en clúster. Se aplican parches a todos los nodos de un clúster de base de datos Aurora al mismo
tiempo. Estamos habilitando la aplicación de parches sin tiempo de inactividad, en la medida de lo posible,
para conservar las conexiones de cliente durante este proceso. Para obtener más información, consulte

Características nuevas:
• SELECT INTO OUTFILE S3: Aurora MySQL ahora le permite cargar los resultados de una consulta en
uno o varios archivos de un bucket de Amazon S3. Para obtener más información, consulte Grabación

740
de datos desde un clúster de base de datos Amazon Aurora MySQL en archivos de texto de un bucket
de Amazon S3 (p. 649).
Mejoras:
• Se ha implementado el truncamiento de archivos de registro con formato CSV al iniciar el motor para
evitar un tiempo de recuperación prolongado. Las tablas general_log_backup, general_log,
slow_log_backup y slow_log no sobreviven ahora a un reinicio de base de datos.
• Se ha corregido un problema por el que la migración de una base de datos llamada test producía un
error.
• Se ha mejorado la estabilidad en el recolector de elementos no utilizados del administrador de bloqueos
reutilizando los segmentos de bloqueo correctos.
• Se ha mejorado la estabilidad del administrador de bloqueos eliminando aserciones no válidas durante el
algoritmo de detección de interbloqueos.
• Se ha vuelto a habilitar la replicación asíncrona y se ha corregido un problema asociado que notificaba
un retardo de réplica incorrecto bajo una carga de trabajo nulo o de solo lectura. Las mejoras de la
canalización de replicación que se introdujeron en la versión 1.10. Estas mejoras se introdujeron para
aplicar actualizaciones de flujos de registro a la caché del búfer de una réplica de Aurora. Esto ayuda a
mejorar la estabilidad y el rendimiento de la lectura en réplicas de Aurora.
• Se ha corregido un error que hacía que autocommit=OFF produjera el bloqueo de eventos programados
y se mantuvieran abiertas transacciones prolongadas hasta que se reiniciara el servidor.
• Se ha corregido un error que producía que los registros de consultas generales, de auditoría y lentas no
pudieran registrar consultas controladas por una confirmación manual.
• Se ha mejorado el desempeño de la característica de lectura anticipada lógica (LRA) hasta 2,5 veces.
Esto se hizo permitiendo que operaciones de recuperación (fetch) previas continuaran en páginas
intermedias en un árbol B.
• Se ha agregado la validación de parámetros para variables de auditoría para recortar espacios
innecesarios.
• Se ha corregido una regresión, introducida en Aurora MySQL versión 1.11, por la que las consultas
podían devolver resultados incorrectos cuando se utilizaba la opción SQL_CALC_FOUND_ROWS y se
invocaba la función FOUND_ROWS().
• Se ha corregido un problema de estabilidad cuando la lista de bloqueo de metadatos se formaba
incorrectamente.
• Se ha mejorado la estabilidad cuando se establece sql_mode en PAD_CHAR_TO_FULL_LENGTH y se
ejecuta el comando SHOW FUNCTION STATUS WHERE Db='string'.
• Se ha corregido un caso inusual, en el que las instancias no se mostraban después de una actualización
de versión de Aurora debido a una comprobación de coherencia de volumen falso.
• Se ha corregido el problema de rendimiento, introducido en Aurora MySQL versión 1.12, en el que se
reducía el rendimiento del escritor de Aurora cuando los usuarios tenían un número elevado de tablas.
• Se ha mejorado un problema de estabilidad cuando el escritor de Aurora se configura como esclavo de
binlog y el número de conexiones se acerca a 16 000.
• Se ha corregido un problema inusual, en el que una réplica de Aurora podía reiniciarse cuando se
bloqueaba una conexión a la espera de un bloqueo de metadatos durante la ejecución de DDL en el
principal de Aurora.

• Con una tabla de InnoDB vacía, no es posible disminuir el valor auto_increment mediante la instrucción
ALTER TABLE, incluso cuando la tabla está vacía. (Error n.º 69882)

741
• Las consultas MATCH() ... que utilizan una cadena larga como argumento para AGAINST() podrían
producir un error cuando se ejecutan en una tabla de InnoDB con un índice de búsqueda de texto
completo. (Error n.º 17640261)
• El tratamiento de SQL_CALC_FOUND_ROWS en combinación con ORDER BY y LIMIT podría dar lugar
a resultados incorrectos para FOUND_ROWS(). (Error n.º 68458 y error n.º 16383173)
• ALTER TABLE no permite cambiar la nulabilidad de la columna si existe una clave externa. (Error n.º
77591)

05/04/2017
Versión: 1.12
Aurora MySQL 1.12 es ahora la versión preferida para la creación de clústeres de bases de datos nuevos,
incluidas las restauraciones a partir de instantáneas.
Esta no es una actualización obligatoria para clústeres existentes. Tendrá la opción de realizar la
actualización de clústeres existentes a la versión 1.12 una vez que finalicemos la aplicación del parche
en toda la flota a la 1.11 (consulte las notas de la versión (p. 743) 1.11 de Aurora y el anuncio en el
foro correspondiente). Con la versión 1.12 de Aurora, estamos utilizando un modelo de aplicación de
parches en clúster. Se aplican parches a todos los nodos de un clúster de base de datos Aurora al mismo
tiempo. Para obtener más información, consulte Mantenimiento de un clúster de base de datos de Amazon
Aurora (p. 340).
• DDL rápida: Aurora MySQL permite ahora ejecutar una operación ALTER TABLE tbl_name ADD
COLUMN col_name column_definition de manera casi instantánea. La operación se completa sin
que sea necesario copiar la tabla y sin que haya un impacto material en otras instrucciones DML.
Dado que no consume almacenamiento temporal para una copia de la tabla, las instrucciones DDL
resultan prácticas incluso para tablas grandes en clases de instancias pequeñas. El DDL rápido solo
se admite actualmente para añadir columnas que se puedan anular, sin un valor predeterminado, al
final de una tabla. Esta característica está disponible actualmente en el modo lab de Aurora. Para
obtener más información, consulte Modificación de las tablas de Amazon Aurora con operaciones DDL
rápidas (p. 564).
• Mostrar estado de volumen: hemos agregado un nuevo comando de monitorización, SHOW VOLUME
STATUS, para mostrar el número de nodos y discos en un volumen. Para obtener más información,
consulte Visualización del estado del volumen para un clúster de base de datos de Aurora (p. 565).
Mejoras
• Se han implementado cambios para bloquear la compresión y reducir aún más la memoria asignada por
objeto de bloqueo. Esta mejora está disponible en el modo lab.
• Se ha corregido un problema que producía que la métrica trx_active_transactions disminuyera
rápidamente incluso cuando la base de datos estaba inactiva.
• Se ha corregido un mensaje de error no válido relativo a sintaxis de consulta de inserción de errores al
simular un error en discos y nodos.
• Se han corregido múltiples problemas relacionados con las condiciones de carrera y bloqueos
temporales inactivos en el administrador de bloqueos.
• Se ha corregido un problema que provocaba el desbordamiento del búfer en el optimizador de consultas.
• Se ha corregido un problema de estabilidad en réplicas de lectura de Aurora cuando los nodos de
almacenamiento subyacentes experimentaban un bajo nivel de memoria disponible.

742
• Se ha corregido un problema por el que las conexiones inactivas persistían más allá de la configuración
del parámetro wait_timeout.
• Se ha corregido un problema por el que query_cache_size devolvía un valor no esperado después
del reinicio de la instancia.
• Se ha corregido un problema de desempeño producido cuando el subproceso de diagnóstico sondeaba
la red con demasiada frecuencia si las escrituras no avanzaban hacia el almacenamiento.

• Volver a cargar una tabla desalojada mientras estaba vacía provocaba el restablecimiento del valor
AUTO_INCREMENT. (Error n.º 21454472 y error n.º 77743)
• No se encontraba un registro del índice en la restauración debido a incoherencias en la estructura de
purge_node_t. La incoherencia producía mensajes de advertencia y de error, por ejemplo, “error in sec
index entry update”, “unable to purge a record” y “tried to purge sec index entry not marked for deletion”.
(Error n.º 19138298, error n.º 70214, error n.º 21126772 y error n.º 21065746)
• El cálculo incorrecto del tamaño de pila para la operación qsort conduce al desbordamiento de la pila.
(Error n.º 73979)
• No se encuentra el registro en un índice cuando se produce la restauración. (Error n.º 70214 y error n.º
72419)
• ALTER TABLE agrega la columna TIMESTAMP en la actualización. CURRENT_TIMESTAMP inserta
datos ZERO. (Error n.º 17392)

23/02/2017
Versión: 1.11
Aplicaremos parches a todos los clústeres de base de datos de Aurora MySQL con la última versión
durante un breve período después del lanzamiento. Se aplican parches a los clústeres de base de datos
mediante el procedimiento heredado con un período de inactividad de unos 5 a 30 segundos.
La aplicación de parches se produce durante el período de mantenimiento del sistema que ha especificado
para cada una de sus instancias de base de datos. Puede ver o cambiar este período utilizando la Consola
de administración de AWS. Para obtener más información, consulte Mantenimiento de un clúster de base
de datos de Amazon Aurora (p. 340).
También puede aplicar el parche inmediatamente en la Consola de administración de AWS eligiendo un

clúster de base de datos, Cluster Actions (Acciones de clúster) y, a continuación, Upgrade Now (Actualizar
ahora).
Con la versión 1.11 de Aurora MySQL, estamos utilizando un modelo de aplicación de parches en clúster.
Se aplican parches a todos los nodos de un clúster de base de datos Aurora al mismo tiempo.
• Opción MANIFEST para LOAD DATA FROM S3: LOAD DATA FROM S3 se publicó en la versión 1.8.
Las opciones para este comando se han ampliado. Ahora, puede especificar una lista de archivos para
cargarlos en un clúster de base de datos Aurora desde Amazon S3 utilizando un archivo de manifiesto.
Esto facilita la carga de datos desde archivos específicos en una o más ubicaciones, frente a la carga
de datos desde un solo archivo mediante la opción FILE o desde varios archivos que tienen la misma
ubicación y prefijo utilizando la opción PREFIX. El formato del archivo de manifiesto es el mismo que
utiliza Amazon Redshift. Para obtener más información sobre cómo usar LOAD DATA FROM S3 con la
opción MANIFEST, consulte Uso de un manifiesto para especificar los archivos de datos que se deben
cargar (p. 645).

743
• Indexación espacial habilitada de manera predeterminada: esta característica se lanzó en el modo lab
de la versión 1.10 y ahora está activa de manera predeterminada. La indexación espacial mejora el
desempeño de las consultas en conjuntos de datos grandes, para consultas que usan datos espaciales.
Para obtener más información acerca del uso de la indexación espacial, consulte Amazon Aurora
MySQL y los datos espaciales (p. 497).
• Cambio del momento de realización de auditorías avanzadas: esta característica se lanzó en la versión
1.10.1 para proporcionar una instalación de alto rendimiento para auditar la actividad de las bases
de datos. En esta versión, se ha cambiado la precisión de las marcas de tiempo de los registros
de auditoría: de un segundo a un microsegundo. Unas marcas de tiempo más precisas permiten
comprender mejor cuándo se produjo un evento de auditoría. Para obtener más información acerca de
auditorías, consulte Uso de auditorías avanzadas con un clúster de base de datos de Amazon Aurora
MySQL (p. 593).
Mejoras
• Se ha modificado el parámetro thread_handling para evitar que se configure con opciones distintas a
multiple-connections-per-thread, que es el único modelo admitido por el grupo de subprocesos
de Aurora.
• Se ha corregido un problema provocado al establecer los parámetros buffer_pool_size o
query_cache_size en valores mayores que los de la memoria total del clúster de base de datos. En
esta circunstancia, Aurora establece el parámetro modificado en el valor predeterminado, por lo que el
clúster de base de datos puede iniciarse y no bloquearse.
• Se ha corregido un problema en la caché de consultas por el que una transacción obtenía resultados de
lectura obsoletos si otra transacción invalidaba la tabla.
• Se ha corregido un problema por el que archivos binlog marcados para su eliminación se eliminaban
después de un pequeño retardo, en lugar inmediatamente.
• Se ha corregido un problema por el que una base de datos creada con el nombre tmp se trataba como
una base de datos del sistema almacenada en un almacenamiento efímero y no se conservaba en el
almacenamiento distribuido de Aurora.
• Se ha modificado el comportamiento de SHOW TABLES para excluir determinadas tablas del sistema
interno. Este cambio ayuda a evitar conmutaciones por error innecesarias causadas por el bloqueo por
parte de mysqldump de todos los archivos que se muestran en SHOW TABLES. Esto evita, a su vez,
escrituras en la tabla del sistema interno, que dan lugar a la conmutación por error.
• Se ha corregido un problema por el que una réplica de Aurora se reiniciaba incorrectamente al crearse
una tabla temporal a partir de una consulta que invocaba una función cuyo argumento era una columna
de una tabla de InnoDB.
• Se ha corregido un problema relacionado con un conflicto de bloqueo de metadatos en un nodo de
réplica de Aurora. Este problema provocaba que la réplica de Aurora quedara por detrás del clúster de
base de datos principal y acabara reiniciándose.
• Se ha corregido un bloqueo temporal inactivo en la canalización de replicación en nodos del lector, que
provocaba que la réplica de Aurora quedara rezagada y acabara reiniciándose.
• Se ha corregido un problema por el que las réplicas de Aurora se retrasaban demasiado con volúmenes
cifrados superiores a 1 terabyte (TB).
• Se ha mejorado la detección de bloqueo temporal inactivo de réplicas de Aurora utilizando un método
mejorado para leer la hora del reloj del sistema.
• Se ha corregido un problema por el que una réplica de Aurora podía reiniciarse dos veces en lugar de
una después de la anulación del registro por parte del escritor.
• Se ha corregido un problema de ralentización de desempeño de consultas de réplicas de Aurora que se
producía cuando estadísticas transitorias causaban discrepancias en las estadísticas de las columnas de
índice no únicas.
• Se ha corregido un problema por el que una réplica de Aurora podía bloquearse cuando una instrucción
DDL se replicaba en la réplica de Aurora al mismo tiempo que dicha réplica de Aurora procesaba una
consulta relacionada.

744
• Se han modificado las mejoras de la canalización de replicación que se introdujeron en la versión

1.10: de habilitado a deshabilitado (como valor predeterminado). Estas mejoras se introdujeron para
aplicar actualizaciones de flujos de registro a la caché del búfer de una réplica de Aurora. Si bien
esta característica ayuda a mejorar el rendimiento de la lectura y la estabilidad en réplicas de Aurora,
aumenta el retardo de la réplica en determinadas cargas de trabajo.
• Se ha corregido un problema por el que la incidencia simultánea de una instrucción DDL en curso y de
lectura anticipada en paralelo pendiente en la misma tabla causaba un error de aserción durante la fase
de confirmación de la instrucción DDL.
• Se han mejorado el registro general y el registro de consultas lentas para que sobrevivan al reinicio del
• Se ha corregido un problema de memoria insuficiente para determinadas consultas de ejecución
prolongada reduciendo el consumo de memoria en el módulo ACL.
• Se ha corregido un problema de reinicio que se producía cuando una tabla tenía índices no espaciales,
había predicados espaciales en la consulta, el planificador decidía utilizar un índice no espacial y dicho
planificador insertaba incorrectamente la condición espacial en el índice.
• Se ha corregido un problema por el que el clúster de base de datos se reiniciaba cuando se producía
una eliminación, actualización o purga de objetos geoespaciales muy grandes que se almacenan
externamente (como los LOB).
• Se ha corregido un problema por el que la simulación de errores mediante ALTER SYSTEM SIMULATE
… FOR INTERVAL no funcionaba correctamente.
• Se ha corregido un problema de estabilidad causado por una aserción no válida o una invariable
incorrecta en el administrador de bloqueos.
• Se han deshabilitado las dos mejoras siguientes en la búsqueda de texto completo de InnoDB,
introducidas en la versión 1.10, porque crearon problemas de estabilidad en algunas cargas de trabajo
exigentes:
• Actualización de la caché solo después de una solicitud de lectura a una réplica de Aurora para
mejorar la velocidad de replicación de la caché del índice de búsqueda de texto completo.
• Descarga de la tarea de sincronización de la caché en un subproceso separado en cuanto el tamaño
de la caché traspasa el 10 % del tamaño total, para evitar que las consultas MySQL se paralicen
demasiado tiempo durante la sincronización de la caché de FTS en disco. (Errores n.º 22516559 y n.º
73816).

• La ejecución de la clave externa DROP de la tabla ALTER simultáneamente con otra operación DROP
causa la desaparición de la tabla. (Error n.º 16095573)
• Algunas consultas de INFORMATION SCHEMA que usaban ORDER BY no aplicaban una optimización
de la operación filesort como antes. (Error n.º 16423536)
• FOUND_ROWS () devuelve un recuento erróneo de filas en una tabla. (Error n.º 68458)
• El servidor se bloquea en lugar de dar un error cuando hay demasiadas tablas temporales abiertas.
(Error n.º 18948649)

12/01/2017
Versión: 1.10.1
La versión 1.10.1 de Aurora MySQL es una versión opcional, que no se utiliza para aplicar parches a las
instancias de base de datos. Está disponible para la creación de instancias de Aurora nuevas y para la
actualización de instancias existentes. También puede aplicar el parche eligiendo un clúster en la consola
de Amazon RDS, Cluster Actions (Acciones de clúster) y, a continuación, Upgrade Now (Actualizar ahora).

745
La aplicación de parches exige el reinicio de la base de datos, por lo que se producirán entre 5 y 30
segundos de inactividad. Posteriormente, podrá volver a utilizar los clústeres de la base de datos. Este
parche utiliza un modelo de aplicación de parches en clúster. Se aplican parches a todos los nodos de un
clúster de Aurora al mismo tiempo.
• Auditoría avanzada: Aurora MySQL proporciona una característica de auditoría avanzada de alto
rendimiento que puede utilizar para auditar la actividad de la base de datos. Para obtener más
información acerca de cómo habilitar y utilizar la auditoría avanzada, consulte Uso de auditorías
avanzadas con un clúster de base de datos de Amazon Aurora MySQL (p. 593).
Mejoras
• Se ha corregido un problema con la indexación espacial al crear una columna y agregarle un índice en la
misma instrucción.
• Se ha corregido un problema por el que las estadísticas espaciales no se conservaban en un reinicio de

14/12/2016
Versión: 1.10
• Aplicación de parche sin tiempo de inactividad: esta característica permite la aplicación de un parche
a una instancia de base de datos sin ningún tiempo de inactividad. Es decir, las actualizaciones de la
base de datos se realizan sin desconectar las aplicaciones cliente ni reiniciar la base de datos. Este
enfoque aumenta la disponibilidad de sus clústeres de base de datos Aurora durante el período de
mantenimiento. Tenga en cuenta que los datos temporales como los que se encuentran en el esquema
de desempeño se restablecen durante el proceso de actualización. Esta característica se aplica a
parches entregados por el servicio durante un período de mantenimiento, así como a parches iniciados
por el usuario.
Cuando se inicia la aplicación de un parche, el servicio se asegura de que no haya bloqueos abiertos,
transacciones o tablas temporales y espera, a continuación, el período apropiado durante el cual
pueda aplicarse el parche y reiniciarse la base de datos. Las sesiones de aplicación se conservan, si
bien se produce una caída en el desempeño mientras la aplicación del parche está en curso (durante
aproximadamente 5 segundos). Si no puede encontrarse un período apropiado, se recurrirá a una
aplicación de parches estándar de manera predeterminada.
La aplicación de parches sin tiempo de inactividad tiene lugar en la medida de lo posible, sujeta a
determinadas limitaciones según se describe a continuación:
• Esta característica es aplicable en la actualidad a la aplicación de parches a clústeres de base de
datos de un nodo o instancias de escritor en clústeres de base de datos de varios nodos.
• Las conexiones SSL no se admiten junto con esta característica. Si hay conexiones SSL activas,
Amazon Aurora MySQL no realizará una aplicación de parches sin tiempo de inactividad. En su lugar,
intentará ver periódicamente si las conexiones SSL han terminado. Si han terminado, se inicia la
aplicación de parches sin tiempo de inactividad. Si las conexiones SSL se conservan después de más
de un par de segundos, se inicia la aplicación de parches estándar con tiempo de inactividad.
• La característica está disponible en Aurora 1.10 y versiones posteriores. En el futuro, identificaremos
cualquier versión o parche que no pueda aplicarse mediante la aplicación de parches sin tiempo de
inactividad.

746
• Esta característica no es aplicable si la replicación basada en registro binario está activa.

• Indexación espacial: la indexación espacial mejora el rendimiento de las consultas en conjuntos de datos
grandes, para consultas que usan datos espaciales. Para obtener más información acerca del uso de la
indexación espacial, consulte Amazon Aurora MySQL y los datos espaciales (p. 497).
Esta característica está deshabilitada de forma predeterminada y puede activarse habilitando el modo
lab de Aurora. Para obtener información, consulte Modo lab de Amazon Aurora MySQL (p. 665).
• Mejoras de la canalización de replicación: Aurora MySQL utiliza ahora un mecanismo mejorado
para aplicar actualizaciones de flujos de registro a la caché del búfer de una réplica de Aurora. Esta
característica mejora el desempeño de lectura y la estabilidad en réplicas de Aurora cuando hay una
gran carga de escritura en el principal, así como una carga de lectura significativa en la réplica. Esta
característica está habilitada de forma predeterminada.
• Mejora del rendimiento para cargas de trabajo con lecturas en caché: Aurora MySQL utiliza ahora un
algoritmo simultáneo sin bloqueos para implementar vistas de lectura, lo que optimiza el rendimiento
para consultas de lectura proporcionadas por la caché del búfer. Como consecuencia de esta y otras
mejoras, Amazon Aurora MySQL puede lograr un rendimiento de hasta 625 000 lecturas por segundo,
en comparación con las 164 000 lecturas por segundo de MySQL 5.7, para una carga de trabajo
solamente de SELECT de SysBench.
• Mejora del rendimiento para cargas de trabajo con contención de filas activas: Aurora MySQL utiliza un
nuevo algoritmo de publicación bloqueo que mejora el rendimiento, en especial cuando hay contención
de página activa (es decir, muchas transacciones compiten por las filas en la misma página). En
pruebas con la herramienta para el análisis comparativo TPC-C, esto puede producir una mejora
en el rendimiento de hasta 16 veces en transacciones por minuto con respecto a MySQL 5.7. Esta
característica está deshabilitada de forma predeterminada y puede activarse habilitando el modo lab de
Aurora. Para obtener información, consulte Modo lab de Amazon Aurora MySQL (p. 665).
Mejoras
• Se ha mejorado la velocidad de replicación de la caché del índice de búsqueda de texto completo. Esto
se logra actualizando la caché solo después de una solicitud de lectura a una réplica de Aurora. Este
enfoque evita cualquier lectura del disco por parte del subproceso de replicación.
• Se ha corregido un problema por el que la invalidación de la caché del diccionario no funcionaba en una
réplica de Aurora para tablas que tenían un carácter especial en el nombre de la base de datos o de la
tabla.
• Se ha corregido un problema de STUCK IO durante la migración de datos para nodos de
almacenamiento distribuidos cuando la administración del nivel de actividad de almacenamiento está
habilitada.
• Se ha corregido un problema en el administrador de bloqueos por el que una comprobación de
aserción no funcionaba para el subproceso de espera de bloqueo de transacción al prepararse para la
restauración o la confirmación de una transacción.
• Se ha corregido un problema al abrir una tabla de diccionario dañada actualizando correctamente el
recuento de referencias en las entradas de las tablas.
• Se ha corregido un problema por el que el punto de lectura mínimo del clúster de base de datos podía
interrumpirse por réplicas de Aurora lentas.
• Se ha corregido una fuga de memoria potencial en la caché de consultas.
• Se ha corregido un problema por el que la réplica de Aurora colocaba un bloqueo en la fila de una tabla
cuando se utilizaba una consulta en una instrucción IF de un procedimiento almacenado.

• La UNIÓN de tablas derivadas devuelve resultados incorrectos con cláusulas '1=0/false'. (Error n.º
69471)

747
• El servidor se bloquea en ITEM_FUNC_GROUP_CONCAT::FIX_FIELDS en la segunda ejecución del

procedimiento almacenado. (Error n.º 20755389)
• Evitar que las consultas MySQL se paralicen demasiado tiempo durante la sincronización de la caché
de FTS. Para ello, se descarga la tarea de sincronización de la caché en un subproceso separado, en
cuanto el tamaño de la caché traspasa el 10 % del tamaño total. (Errores n.º 22516559 y n.º 73816)

10/11/2016
Versión: 1.9.0, 1.9.1
• Creación de índice mejorada: la implementación para crear índices secundarios funciona ahora
generando el índice de abajo arriba, lo cual elimina divisiones innecesarias de páginas. Esto puede
disminuir el tiempo necesario para crear un índice o reconstruir una tabla en hasta un 75 % (para una
clase de instancia de base de datos db.r3.8xlarge). Esta característica estaba disponible en el
modo lab de la versión 1.7 de Aurora MySQL, y ahora está habilitada, de manera predeterminada, en
Aurora 1.9 y versiones posteriores. Para obtener información, consulte Modo lab de Amazon Aurora
MySQL (p. 665).
• Compresión de bloqueo (modo lab): esta implementación reduce significativamente la cantidad de
memoria que consume el administrador de bloqueos en hasta un 66 %. El administrador de bloqueos
puede adquirir más bloqueos de filas sin encontrarse con una excepción de memoria insuficiente. Esta
característica está deshabilitada de forma predeterminada y puede activarse habilitando el modo lab de
Aurora. Para obtener información, consulte Modo lab de Amazon Aurora MySQL (p. 665).
• Esquema de rendimiento: Aurora MySQL admite ahora esta característica, con un impacto mínimo en
el rendimiento. En nuestras pruebas con SysBench, la habilitación del esquema de desempeño podía
degradar el desempeño de MySQL en hasta un 60 %.
Las pruebas con SysBench de un clúster de base de datos Aurora mostraron un impacto en el
desempeño 4 veces inferior al de MySQL. La ejecución de la clase de instancia de base de datos
db.r3.8xlarge produjo 100 000 operaciones SQL de escritura por segundo y más de 550 000
operaciones SQL de lectura por segundo, incluso con el esquema de desempeño habilitado.
• Mejora de la contención de filas activas: esta característica reduce la utilización de la CPU y aumenta
el rendimiento cuando un número elevado de conexiones obtiene acceso a un pequeño número de
filas activas. Esta característica también elimina error 188 cuando se produce la contención de filas
activas.
• Tratamiento de memoria insuficiente mejorado: cuando se ejecutan instrucciones SQL de bloqueo
no esenciales y se sobrepasa el grupo de memoria reservado, Aurora fuerza la restauración de
esas instrucciones SQL. Esta característica libera memoria y evita que el motor se bloquee debido a
excepciones de memoria insuficiente.
• Selector de lectura inteligente: esta implementación mejora la latencia de lectura eligiendo el segmento
de almacenamiento óptimo entre diferentes segmentos para cada lectura. De este modo, se optimiza el
rendimiento de lectura. Las pruebas con SysBench muestran un aumento del rendimiento de hasta un
27 % para cargas de trabajo de escritura .
Mejoras
• Se ha corregido un problema por el que la réplica de Aurora se encontraba con un bloqueo compartido
durante el inicio del motor.
• Se ha corregido un bloqueo potencial de una réplica de Aurora cuando el puntero de vista de lectura en
el sistema de purga era NULL.

748

26/10/2016
Versión: 1.8.1
Mejoras
• Se ha corregido un problema por el que inserciones masivas, que utilizaban disparadores e invocaban
procedimientos de AWS Lambda, no funcionaban.
• Se ha corregido un problema por el que no se podían migrar catálogos cuando se desactivaba
globalmente la confirmación automática.
• Se ha resuelto un error de conexión con Aurora al usar SSL y se ha mejorado el grupo Diffie-Hellman
para hacer frente a los ataques de LogJam.

• OpenSSL cambió los parámetros de longitud de la clave Diffie-Hellman debido al problema con LogJam.
(Error n.º 18367167)

18/10/2016
Versión: 1.8
• Integración de AWS Lambda: ahora puede invocar de manera asíncrona una función de AWS Lambda
desde un clúster de base de datos Aurora mediante el procedimiento mysql.lambda_async. Para
obtener más información, consulte Invocación de una función de Lambda desde un clúster de base de
datos Amazon Aurora MySQL (p. 655).
• Cargar datos desde Amazon S3: ahora puede cargar archivos de texto o XML desde un bucket de
Amazon S3 en el clúster de base de datos Aurora usando los comandos LOAD DATA FROM S3 o LOAD
XML FROM S3. Para obtener más información, consulte Carga de datos en un clúster de base de datos
Amazon Aurora MySQL desde archivos de texto en un bucket de Amazon S3 (p. 641).
• Migración de catálogo: Aurora conserva ahora los metadatos de catálogo en el volumen del clúster
para admitir el control de versiones. Esto permite la migración fluida de catálogo entre versiones y
restauraciones.
• Mantenimiento y aplicación de parches en el nivel de grupo: Aurora administra ahora actualizaciones
de mantenimiento para un clúster de base de datos completo. Para obtener más información, consulte
Mejoras
• Se ha corregido un problema por el que la réplica de Aurora se bloqueaba cuando no se concedía un
bloqueo de metadatos a una tabla DDL en proceso.
• Permite que las réplicas de Aurora modifiquen tablas que no sean de InnoDB para facilitar la rotación de
archivos CSV de registro generales y lentos donde log_output=TABLE.
• Se ha corregido un retardo en la actualización de estadísticas desde la instancia primaria a una réplica
de Aurora. Sin esta corrección, las estadísticas de la réplica de Aurora pueden desactualizarse respecto
de las estadísticas de la instancia principal y dar lugar a un plan de consultas diferente (y posiblemente
con un desempeño inferior) en una réplica de Aurora.

749
• Se ha corregido una condición de carrera que garantizaba que una réplica de lectura no adquiría
bloqueos.
• Se ha corregido una situación inusual por la que una réplica de Aurora que se registraba (o dejaba de
estar registrada) en la instancia principal generaba errores.
• Se ha corregido una condición de carrera que podía llevar a un interbloqueo en instancias
db.r3.large al abrir o cerrar un volumen.
• Se ha corregido un problema de memoria insuficiente que podía producirse debido a una combinación
de una carga de trabajo de escritura grande y errores en el servicio de almacenamiento distribuido de
Aurora.
• Se ha corregido un problema de consumo elevado de CPU debido al giro del subproceso de purga en
presencia de una transacción de ejecución prolongada.
• Se ha corregido un problema en la ejecución de consultas de esquemas para obtener información sobre
bloqueos bajo una carga pesada.
• Se ha corregido un problema con un proceso de diagnóstico que podía, en casos inusuales, hacer que
las escrituras de Aurora en nodos de almacenamiento se paralizaran y reiniciaran o se conmutaran por
error.
• Se ha corregido una condición por la que una tabla creada correctamente podría eliminarse durante
una recuperación de bloqueo si este se producía mientras se estaba aplicando una instrucción CREATE
TABLE [if not exists].
• Se ha corregido un caso por el que un procedimiento de rotación de registro se interrumpía cuando el
registro general y el registro lento no se almacenaban en el disco mediante la migración de catálogo.
• Se ha corregido un bloqueo cuando se creaba una tabla temporal dentro de una función definida por el
usuario y, a continuación, se utilizaba dicha función en la lista de selección de la consulta.
• Se ha corregido un bloqueo que se producía al reproducir eventos de GTID. Aurora MySQL no admite
GTID.
Integración de correcciones de errores de MySQL:

• Al suprimir todos los índices en una columna con varios índices, InnoDB no podía bloquear una
operación DROP INDEX cuando una restricción de clave externa requería un índice. (Error n.º
16896810)
• Solución para bloqueo de restricción al agregar clave externa. (Error n.º 16413976)
• Se ha corregido un bloqueo al recuperar un cursor en un procedimiento almacenado y analizar o vaciar
la tabla al mismo tiempo. (Error n.º 18158639)
• Se ha corregido un error de incremento automático cuando un usuario alteraba una tabla para cambiar
el valor AUTO_INCREMENT a un valor inferior al valor máximo de la columna de incremento automático.
(Error n.º 16310273)

20/09/2016
Versión: 1.7.1
Mejoras
• Se corrige un problema por el que una réplica de Aurora se bloquea si la caché de búsqueda de texto
completo de InnoDB está llena.
• Se corrige un problema por el que el motor de base de datos se bloquea si un subproceso de trabajo en
el grupo de subprocesos se espera a sí mismo.

750
• Se corrige un problema por el que la réplica de Aurora se bloquea si un bloqueo de metadatos en una
tabla causa un interbloqueo.
• Se corrige un problema por el que el motor de base de datos se bloquea debido a una condición de
carrera entre dos subprocesos de trabajo en el grupo de subprocesos.
• Se corrige un problema por el que se produce una conmutación por error innecesaria bajo una carga
pesada si el agente de monitorización no detecta el avance de operaciones de escritura al subsistema
de almacenamiento distribuido.

30/08/2016
Versión: 1.7.0
• Programador con reconocimiento de NUMA: el programador de tareas para el motor de Aurora
MySQL cuenta ahora con reconocimiento de acceso a memoria no uniforme (NUMA). Esto minimiza
la contención de sockets entre varias CPU, lo que produce un desempeño mejorado para la clase de
instancia de base de datos db.r3.8xlarge.
• La lectura anticipada en paralelo funciona de manera asíncrona en segundo plano: se ha revisado la
lectura anticipada en paralelo a fin de mejorar el rendimiento mediante un subproceso dedicado para
reducir la contención de subprocesos.
• Creación de índice mejorada (modo lab): la implementación para crear índices secundarios funciona
ahora generando el índice de abajo arriba, lo cual elimina divisiones innecesarias de páginas. Esto
puede disminuir el tiempo necesario para crear un índice o reconstruir una tabla. Esta característica
está deshabilitada de forma predeterminada y puede activarse habilitando el modo lab de Aurora. Para
obtener información, consulte Modo lab de Amazon Aurora MySQL (p. 665).
Mejoras
• Se ha corregido un problema por el que el establecimiento de una conexión tardaba demasiado tiempo
si se producía un pico en el número de conexiones solicitadas para una instancia.
• Se ha corregido un problema por el que se producía un bloqueo si se ejecutaba ALTER TABLE en una
tabla con particiones que no utilizaba InnoDB.
• Se ha corregido un problema por el que una carga de trabajo con muchas escrituras podía causar una
conmutación por error.
• Se ha corregido una aserción errónea que causaba un error si se ejecutaba RENAME TABLE en una
tabla con particiones.
• Se ha mejorado la estabilidad al anular una transacción durante una gran carga de trabajo de
inserciones.
• Se ha corregido un problema por el que índices de búsqueda de texto no eran viables en una réplica de
Aurora.

• Mejora de la escalabilidad mediante la división del bloqueo LOCK_grant. (Puerto WL n.º 8355)
• La apertura del cursor en SELECT en el procedimiento almacenado causa un error de segmentación.
(Error de puerto n.º 16499751)
• MySQL da un resultado incorrecto con algunos usos especiales. (Error n.º 11751794)
• Bloqueo en GET_SEL_ARG_FOR_KEYPART: causado por el parche para el error n.º 11751794. (Error
n.º 16208709)

751
• Resultados incorrectos para una consulta simple realizada por GROUP BY. (Error n.º 17909656)
• Filas adicionales en la consulta de semicombinación (semijoin) con predicados de rango. (Error n.º
16221623)
• Agregar una cláusula ORDER BY tras una subconsulta IN podría provocar la devolución de filas
duplicadas. (Error n.º 16308085)
• Bloqueo con el comando EXPLAIN para una consulta con examen amplio para GROUP BY, MyISAM.
(Error n.º 16222245)
• El examen de índice amplio con predicado de entero entre comillas devuelve datos aleatorios. (Error n.º
16394084)
• Si el optimizador estaba utilizando un examen de índice amplio, el servidor podía detenerse mientras
intentaba crear una tabla temporal. (Error n.º 16436567)
• COUNT(DISTINCT) no debe contar valores NULL, pero se cuentan cuando el optimizador utiliza el
examen de índice amplio. (Error n.º 17222452)
• Si una consulta tenía las funciones MIN()/MAX() y aggregate_function(DISTINCT) (por ejemplo,
SUM(DISTINCT)) y se ejecutaba utilizando el examen de índice amplio, los valores de los resultados de
MIN()/MAX() se establecían incorrectamente. (Error n.º 17217128)

01/06/2016
Versión: 1.6.5
• Almacenamiento eficiente de registros binarios: el almacenamiento eficiente de registros binarios está
ahora habilitado de manera predeterminada para todos los clústeres de base de datos Aurora MySQL y
no puede configurarse. El almacenamiento eficiente de registros binarios se introdujo en la actualización
de abril de 2016. Para obtener más información, consulte Actualizaciones del motor de base de datos de
Aurora MySQL: 06/04/2016 (p. 752).
Mejoras
• Se ha mejorado la estabilidad para réplicas de Aurora cuando la instancia principal se encuentra con
mucha carga de trabajo.
• Se ha mejorado la estabilidad para réplicas de Aurora al ejecutar consultas en tablas con particiones y
tablas con caracteres especiales en el nombre de la tabla.
• Se han corregidos problemas de conexión al usar conexiones seguras.

• EL ESCLAVO NO PUEDE CONTINUAR LA REPLICACIÓN DESPUÉS DE LA RECUPERACIÓN DEL
BLOQUEO DEL PRINCIPAL (error de puerto n.º 17632285)

06/04/2016
Versión: 1.6
Esta actualización incluye las siguientes mejoras:

752
• Lectura anticipada en paralelo: la lectura anticipada en paralelo está ahora habilitada de manera
predeterminada para todos los clústeres de base de datos Aurora MySQL y no puede configurarse.
La lectura anticipada en paralelo se introdujo en la actualización de diciembre de 2015. Para
obtener más información, consulte Actualizaciones del motor de base de datos de Aurora MySQL:
03/12/2015 (p. 755).
Además de habilitar la lectura anticipada en paralelo de manera predeterminada, esta versión incluye las
siguientes mejoras:
• Mejora de la lógica para que la lectura anticipada en paralelo sea menos agresiva, lo cual es
beneficioso cuando su clúster de base de datos se encuentra con muchas cargas de trabajo paralelas.
• Mejora de la estabilidad en tablas más pequeñas.
• Almacenamiento eficiente de registros binarios (modo lab): los archivos de registro binario MySQL
se almacenan ahora de manera más eficiente en Aurora MySQL. La nueva implementación de
almacenamiento permite la eliminación de archivos de registro binarios mucho antes. Asimismo, mejora
el rendimiento del sistema para una instancia en un clúster de base de datos de Aurora MySQL que es el
maestro de la replicación del registro binario.
Para habilitar el almacenamiento eficiente de registros binarios, establezca el parámetro

aurora_lab_mode en 1 en el grupo de parámetros para la instancia principal o la réplica de Aurora. El
parámetro aurora_lab_mode es un parámetro en el nivel de la instancia que se encuentra, de manera
predeterminada, en el grupo de parámetros default.aurora5.6. Para obtener información acerca
de cómo modificar un grupo de parámetros de base de datos, consulte Modificación de parámetros de
un grupo de parámetros de base de datos (p. 265). Para obtener información acerca de los grupos de
parámetros y Aurora MySQL, consulte Parámetros de Aurora MySQL (p. 678).
Active el almacenamiento eficiente de logs binarios únicamente para instancias de un clúster de base de
datos de Aurora MySQL y que sean instancias maestras de replicación del registro binario de MySQL.
• Variable del sistema AURORA_VERSION: ahora puede obtener la versión Aurora de su clúster de base
de datos Aurora MySQL mediante una consulta de la variable del sistema AURORA_VERSION.
Para obtener la versión de Aurora, utilice una de las siguientes consultas:
select AURORA_VERSION();
select @@aurora_version;
show variables like '%version';
También puede ver la versión de Aurora en la Consola de administración de AWS cuando modifique
un clúster de base de datos o llamando al comando describe-db-engine-versions de la AWS CLI o a la
acción DescribeDBEngineVersions de la API.
• Métrica de uso de la memoria del administrador de bloqueos: la información sobre el uso de la memoria
del administrador de bloqueos ahora está disponible como métrica.
Para obtener la métrica de uso de la memoria del administrador de bloqueos, utilice una de las
siguientes consultas:
show global status where variable_name in ('aurora_lockmgr_memory_used');
select * from INFORMATION_SCHEMA.GLOBAL_STATUS where variable_name in

('aurora_lockmgr_memory_used');

753
Mejoras
• Se ha mejorado la estabilidad durante la recuperación de transacciones binlog y XA.
• Se ha corregido un problema de memoria derivado de un número elevado de conexiones.
• Se ha mejorado la precisión de las siguientes métricas: Read Throughput, Read IOPS, Read
Latency, Write Throughput, Write IOPS, Write Latency y Disk Queue Depth.
• Se ha corregido un problema de estabilidad que causaba un reinicio lento en instancias grandes
después de un bloqueo.
• Simultaneidad mejorada en el diccionario de datos con respecto a mecanismos de sincronización y
desalojo de la caché.
• Mejoras de la estabilidad y del desempeño para réplicas de Aurora:
• Se ha corregido un problema de estabilidad para réplicas de Aurora durante cargas de trabajo
intensas o en ráfagas para la instancia principal.
• Se ha mejorado un retardo de réplica para instancias db.r3.4xlarge y db.r3.8xlarge.
• Se ha mejorado el desempeño reduciendo la contención entre la aplicación de registros y lecturas
simultáneas en una réplica de Aurora.
• Se ha corregido un problema para la actualización de estadísticas en réplicas de lectura para
estadísticas recién creadas o actualizadas.
• Se ha mejorado la estabilidad para réplicas de lectura cuando hay muchas transacciones en la
instancia principal y lecturas simultáneas en las réplicas de Aurora en los mismos datos.
• Se ha mejorado la estabilidad para réplicas de Aurora al ejecutar las instrucciones UPDATE y DELETE
con instrucciones JOIN.
• Se ha mejorado la estabilidad para réplicas de Aurora al ejecutar instrucciones INSERT … SELECT.

• BACKPORT Bug #18694052 FIX FOR ASSERTION `!M_ORDERED_REC_BUFFER' FAILED TO 5.6
• SEGV IN MEMCPY(), HA_PARTITION::POSITION (Error de puerto n.º 18383840)
• WRONG RESULTS WITH PARTITIONING,INDEX_MERGE AND NO PK (Error de puerto n.º 18167648)
• FLUSH TABLES FOR EXPORT: ASSERTION IN HA_PARTITION::EXTRA (Error de puerto n.º
16943907)
• SERVER CRASH IN VIRTUAL HA_ROWS HANDLER::MULTI_RANGE_READ_INFO_CONST (Error de
puerto n.º 16164031)
• RANGE OPTIMIZER CRASHES IN SEL_ARG::RB_INSERT() (Error de puerto n.º 16241773)

11/01/2016
Versión: 1.5
Mejoras
• Se ha corregido una pausa de 10 segundos en las operaciones de escritura para instancias inactivas
durante implementaciones de almacenamiento de Aurora.
• La lectura anticipada lógica funciona ahora cuando se establece innodb_file_per_table en No.
Para obtener más información acerca de la lectura anticipada lógica, consulte Actualizaciones del motor
de base de datos de Aurora MySQL: 03/12/2015 (p. 755).

754
• Se han corregido problemas con réplicas de Aurora que vuelven a conectarse con la instancia principal.
Esta mejora también corrige un problema cuando se especifica un valor grande para el parámetro
quantity al probar errores de réplica de Aurora mediante consultas de inserción de errores. Para
obtener más información, consulte Prueba de un error de una réplica de Aurora (p. 562).
• Mejora de la monitorización de réplicas de Aurora que se quedan rezagadas y se reinician.
• Se ha corregido un problema que provocaba el retardo de una réplica de Aurora, la anulación de su
registro y, a continuación, su reinicio.
• Se ha corregido un problema al ejecutar el comando show innodb status durante un interbloqueo.
• Se ha corregido un problema de conmutaciones por error de instancias grandes durante un desempeño
de escritura elevado.

• Se ha abordado una corrección incompleta de la búsqueda de texto completa de MySQL que afecta a
tablas en las que el nombre de la base de datos comienza por un dígito. (Error de puerto n.º 17607956)

03/12/2015
Versión: 1.4
• Inserción rápida: acelera las inserciones paralelas ordenadas por clave principal. Para obtener más
información, consulte Mejoras de desempeño de Amazon Aurora MySQL (p. 496).
• Rendimiento de lectura de conjuntos de datos de gran tamaño: Aurora MySQL detecta automáticamente
una carga de trabajo con muchas E/S y lanza más subprocesos para aumentar el rendimiento del
clúster de la base de datos. El programador de Aurora analiza la actividad de E/S y decide ajustar
dinámicamente el número óptimo de subprocesos en el sistema. Para ello, realiza un ajuste rápido entre
cargas de trabajo con muchas E/S y la CPU con baja sobrecarga.
• Lectura anticipada en paralelo: mejora el rendimiento de exámenes de árbol B que son demasiado
grandes para la memoria disponible en su instancia principal o réplica de Aurora (incluidas las consultas
de rango). La lectura anticipada en paralelo detecta automáticamente patrones de lectura de página
y páginas de recuperación (fetch) previas en la caché del búfer antes de que se necesiten. La lectura
anticipada en paralelo funciona en varias tablas al mismo tiempo dentro de la misma transacción.
Mejoras:
• Se han corregido breves problemas de disponibilidad de la base de datos Aurora durante la
implementación de almacenamiento de Aurora.
• Aplicación correcta del límite max_connection.
• Se ha mejorado la purga de binlog donde Aurora es el principal de binlog y la base de datos se reinicia
después de una carga de datos grande.
• Se han corregido problemas de administración de la memoria con la caché de la tabla.
• Se ha agregado compatibilidad con páginas de gran tamaño en la caché del búfer de memoria
compartida para una recuperación más rápida.
• Se ha corregido un problema por el que el almacenamiento local de subprocesos no se inicializaba.
• Se permiten conexiones de 16 K de manera predeterminada.
• Grupo de subprocesos dinámico para cargas de trabajo pesadas de E/S.

755
• Se ha corregido un problema de invalidación correcta de vistas que afecta a UNION en la caché de

consultas.
• Se ha corregido un problema de estabilidad con el subproceso de estadísticas del diccionario.
• Se ha corregido una fuga de memoria en el subsistema del diccionario relacionado con el desalojo de la
caché.
• Se ha corregido un problema de alta latencia de lectura en réplicas de Aurora cuando hay una carga de
escritura muy baja en el principal.
• Se han corregido problemas de estabilidad en réplicas de Aurora al realizar operaciones en tablas con
particiones DDL como, por ejemplo, ALTER TABLE ... REORGANIZE PARTITION en el principal.
• Se han corregido problemas de estabilidad en réplicas de Aurora durante el crecimiento de volumen.
• Se ha corregido un problema de desempeño en exámenes en índices que no están en un clúster en
• Corrección del problema de estabilidad que provoca el retardo de las réplicas de Aurora, la anulación de
su registro y, a continuación, su reinicio.

• SEGV en FTSPARSE(). (Error n.º 16446108)
• El diccionario de datos de InnoDB no se actualiza al cambiar el nombre de la columna. (Error n.º
19465984)
• Bloqueo de FTS después de cambiar el nombre de la tabla en una base de datos diferente. (Error n.º
16834860)
• La imposibilidad de preparar el disparador en tablas truncadas causa el error 1054. (Error n.º 18596756)
• Los cambios en los metadatos podrían causar problemas con la ejecución del disparador. (Error n.º
18684393)
• No se elige la materialización para el campo UTF8 VARCHAR largo. (Error n.º 17566396)
• Plan de ejecución no adecuado para ORDER BY con límite X. (Error n.º 16697792)
• Adaptación de error n.º 11765744 A 5.1, 5.5 Y 5.6. (Error n.º 17083851)
• Problema de exclusión mutua en SQL/SQL_SHOW.CC que produce SIG6. Origen probable
FILL_VARIABLES. (Error n.º 20788853)
• Adaptación de error n.º 18008907 a versiones 5.5+. (Error n.º 18903155)
• Adaptar corrección para un error de desbordamiento de pila en MySQL 5.7. (Error n.º 19678930)

16/10/2015
Versiones: 1.2, 1.3
Correcciones
• Se ha resuelto un problema de memoria insuficiente en el nuevo administrador de bloqueos con
transacciones de ejecución prolongada.
• Se ha resuelto la vulnerabilidad de seguridad al replicar bases de datos MySQL que no están diseñadas
para RDS.
• Actualización para garantizar reintentos correctos de las escrituras de cuórum tras errores de
almacenamiento.
• Actualización para notificar los retardos de réplica con mayor exactitud.

756
• Se ha mejorado el desempeño reduciendo la contención cuando muchas transacciones simultáneas

tratan de modificar la misma fila.
• Se ha resuelto la invalidación de la caché de consultas para vistas que se crean uniendo dos tablas.
• Se ha deshabilitado la caché de consultas para transacciones con aislamiento UNCOMMITTED_READ.
Mejoras
• Mejor desempeño para consultas de catálogo lentas en cachés semiactivas.
• Se ha mejorado la simultaneidad en las estadísticas del diccionario.
• Mejor estabilidad para el nuevo administrador de recursos de la caché de consultas, la administración de
extensión, los archivos almacenados en el almacenamiento inteligente de Amazon Aurora y la escritura
por lotes de registros.

• La anulación de una consulta dentro de innodb provoca que se acabe bloqueando con una aserción.
(Error n.º 1608883)
• No se puede crear un subproceso nuevo para el programador de eventos, ejecución de eventos o nueva
conexión, y no se escribe ningún mensaje en el registro de errores. (Error n.º 16865959)
• Si una conexión cambiara su base de datos predeterminada y otra conexión ejecutara simultáneamente
SHOW PROCESSLIST, la segunda conexión podría obtener acceso a la memoria no válida al tratar de
mostrar la memoria de la base de datos predeterminada de la primera conexión. (Error n.º 11765252)
• PURGE BINARY LOGS por diseño no elimina archivos de registro binario que se están utilizando o
están activos, pero no se proporciona ninguna notificación cuando sucede esto. (Error n.º 13727933)
• Para algunas instrucciones, podrían producirse fugas de memoria cuando el optimizador elimina
cláusulas de subconsultas innecesarias. (Error n.º 15875919)
• Durante el cierre, el servidor podría intentar bloquear una exclusión mutua que no se ha inicializado.
(Error n.º 16016493)
• Una instrucción preparada que utilizó GROUP_CONCAT() y una cláusula ORDER BY que nombró varias
columnas podrían provocar la suspensión del servidor. (Error n.º 16075310)
• Faltaba la instrumentación del esquema de desempeño para los subprocesos de trabajo del esclavo.
(Error n.º 16083949)
• STOP SLAVE podría provocar un interbloqueo si se emite simultáneamente con una instrucción
como SHOW STATUS, que recupera los valores para una o más variables de estado
Slave_retried_transactions, Slave_heartbeat_period, Slave_received_heartbeats, Slave_last_heartbeat o
Slave_running. (Error n.º 16088188)
• Una consulta de texto completo que utiliza el modo booleano podría devolver cero resultados en algunos
casos en los que el término de búsqueda es una frase entrecomillada. (Error n.º 16206253)
• El intento del optimizador de eliminar cláusulas de la subconsulta redundante producía una aserción al
ejecutar una instrucción preparada con una subconsulta en la cláusula ON de una combinación en una
subconsulta. (Error n.º 16318585)
• GROUP_CONCAT inestable, bloqueo en ITEM_SUM::CLEAN_UP_AFTER_REMOVAL. (Error n.º
16347450)
• Intentar sustituir la lista predeterminada de palabras excluidas de búsqueda de texto
completo (FTS) de InnoDB creando una tabla de InnoDB con la misma estructura que
INFORMATION_SCHEMA.INNODB_FT_DEFAULT_STOPWORD genera un error. (Error n.º 16373868)
• Después de que el subproceso de cliente en un esclavo realice una operación FLUSH TABLES WITH
READ LOCK, seguida de algunas actualizaciones en el principal, el esclavo se bloquea al ejecutar
SHOW SLAVE STATUS. (Error n.º 16387720)
• Al analizar una cadena de búsqueda delimitada, por ejemplo, "abc-def"en una búsqueda de texto
completo, InnoDB utiliza ahora los mismos delimitadores de palabras que MyISAM. (Error n.º 16419661)

757
• Bloqueo en FTS_AST_TERM_SET_WILDCARD. (Error n.º 16429306)

• SEGFAULT en FTS_AST_VISIT() para la prueba FTS RQG. (Error n.º 16435855)
• Para las compilaciones de depuración, cuando el optimizador elimina un Item_ref que señalaba a una
subconsulta, se produce una salida del servidor. (Error n.º 16509874)
• La búsqueda de texto completo en tablas de InnoDB produce un error en búsquedas de frases literales
combinadas con los operadores + o -. (Error n.º 16516193)
• START SLAVE produce un error cuando se inicia el servidor con las opciones --master-info-
repository=TABLE relay-log-info-repository=TABLE y con la confirmación automática establecida en 0,
junto con --skip-slave-start. (Error n.º 16533802)
• Resultados de búsqueda de texto completo (FTS) de InnoDB muy grandes podrían consumir una
cantidad excesiva de memoria. (Error n.º 16625973)
• En compilaciones de depuración, podría producirse una aserción en OPT_CHECK_ORDER_BY al usar
datos binarios directamente en una cadena de búsqueda, ya que estos podrían incluir bytes NULL y
otros caracteres no significativos. (Error n.º 16766016)
• Para algunas instrucciones, podrían producirse fugas de memoria cuando el optimizador elimina
cláusulas de subconsultas innecesarias. (Error n.º 16807641)
• Fue posible causar un interbloqueo después de emitir FLUSH TABLES WITH READ LOCK con STOP
SLAVE en una conexión nueva en el esclavo y, a continuación, emitir SHOW SLAVE STATUS mediante
la conexión original. (Error n.º 16856735)
• GROUP_CONCAT() con un separador no válido podría provocar una suspensión del servidor. (Error n.º
16870783)
• El servidor realiza un bloqueo excesivo en las exclusiones mutuas LOCK_active_mi y active_mi-
>rli->data_lock para cualquier instrucción con el "patrón" SHOW STATUS LIKE, incluso cuando
dicho patrón no se corresponde con las variables de estado que utilizan esas exclusiones mutuas
(Slave_heartbeat_period, Slave_last_heartbeat, Slave_received_heartbeats, Slave_retried_transactions y
Slave_running). (Error n.º 16904035)
• Una búsqueda de texto completo con el modificador IN BOOLEAN MODE produce un error de aserción.
(Error n.º 16927092)
• La búsqueda de texto completo en tablas de InnoDB produce un error en búsquedas que utilizaron el
operador booleano +. (Error n.º 17280122)
• Interbloqueo de 4 direcciones: zombies, purga de binlogs, mostrar lista de procesos y mostrar binlogs
(Error n.º 17283409)
• Cuando se anula y reinicia un subproceso SQL que espera un bloqueo de confirmación, se provoca la
omisión de una transacción en el esclavo. (Error n.º 17450876)
• Se produce un error de búsqueda de texto completo de InnoDB debido a un token "sin terminar". La
cadena y la longitud de la cadena deben transmitirse para realizar la comparación de cadenas. (Error n.º
17659310)
• Un número elevado de tablas de InnoDB con particiones podría consumir mucha más memoria, si se
utilizan en MySQL 5.6 o 5.7, que la memoria empleada por las mismas tablas en versiones anteriores de
MySQL Server. (Error n.º 17780517)
• Para consultas de texto completo, no comprobar que num_token es inferior a max_proximity_item podría
producir una aserción. (Error n.º 18233051)
• Determinadas consultas para las tablas INFORMATION_SCHEMA TABLES y COLUMNS podrían
producir un uso excesivo de memoria cuando hay un número elevado de tablas de InnoDB vacías. (Error
n.º 18592390)
• Al confirmar una transacción, ahora se utiliza un indicador para comprobar si se ha creado un
subproceso, en lugar de comprobar el subproceso en sí, que utiliza más recursos (en particular cuando
se ejecuta el servidor con master_info_repository=TABLE). (Error n.º 18684222)
• Si un subproceso de cliente en un esclavo ejecuta una operación FLUSH TABLES WITH READ LOCK
mientras el principal ejecuta una instrucción DML, la ejecución de SHOW SLAVE STATUS en el mismo
cliente se bloquea y causa un interbloqueo. (Error n.º 19843808)

758
Errores de MySQL corregidos en las
actualizaciones de Aurora MySQL
• Ordenar por un resultado de GROUP_CONCAT() podría provocar una suspensión del servidor. (Error n.º
19880368)

24/08/2015
Versión: 1.1
• Mejoras de estabilidad de la replicación al replicar con una base de datos MySQL (replicación de
binlog). Para obtener más información acerca de la replicación de Aurora MySQL con MySQL, consulte
Replicación con Amazon Aurora (p. 48).
• Un límite de 1 gigabyte (GB) en el tamaño de los logs de retransmisión acumulados para un clúster de
base de datos de Aurora MySQL que es un esclavo de replicación. Esto mejora la administración de
archivos para los clústeres de base de datos Aurora.
• Mejoras de estabilidad en las áreas de lectura anticipada, relaciones claves externas recursivas y
replicación de Aurora.
• Integración de correcciones de errores de MySQL.
• Las bases de datos de InnoDB con nombres que comienzan con un dígito causan un error de
analizador de búsqueda de texto completo (FTS). (Error n.º 17607956)
• Las búsquedas de texto completo de InnoDB producen un error en bases de datos cuyos nombres
comienzan con un dígito. (Error n.º 17161372)
• Para bases de datos InnoDB en Windows, el ID de objeto de búsqueda de texto completo (FTS) no
está en el formato hexadecimal esperado. (Error n.º 16559254)
• Una regresión de código introducida en MySQL 5.6 afecta negativamente al desempeño de DROP
TABLE y ALTER TABLE. Esto podría provocar una disminución del rendimiento entre MySQL Server
5.5.x y 5.6.x. (Error n.º 16864741)
• Registro simplificado para reducir el tamaño de los archivos de registro y la cantidad de almacenamiento
que necesitan.
Errores de MySQL corregidos en las actualizaciones

del motor de base de datos de Aurora MySQL
La siguiente sección identifica errores de MySQL corregidos por actualizaciones del motor de base de
datos Aurora MySQL.
Temas
• Errores de MySQL corregidos en las actualizaciones del motor de base de datos de Aurora MySQL
2.x (p. 759)
• Errores de MySQL corregidos en las actualizaciones del motor de base de datos de Aurora MySQL
1.x (p. 760)
Errores de MySQL corregidos en las actualizaciones del motor de

base de datos de Aurora MySQL 2.x
La versión de Aurora compatible con MySQL 5.7 contiene todas las correcciones de errores de MySQL
hasta MySQL 5.7.12. La siguiente tabla identifica errores de MySQL adicionales corregidos por
actualizaciones del motor de base de datos Aurora MySQL y en qué actualización se corrigieron.

759
Actualización del Versión Errores de MySQL corregidos

motor de base de
datos
Actualizaciones 2.03 • REVERSE SCAN ON A PARTITIONED TABLE DOES ICP -

del motor de ORDER BY DESC (error n.º 24929748).
base de datos de • JSON_OBJECT CREATES INVALID JSON CODE (error n.º
Aurora MySQL 26867509).
(11/10/2018) (p. 710)
• INSERTING LARGE JSON DATA TAKES AN INORDINATE
AMOUNT OF TIME (error n.º 22843444).
• PARTITIONED TABLES USE MORE MEMORY IN 5.7 THAN 5.6
(error n.º 25080442).
Actualizaciones 2.02 La combinación izquierda devuelve resultados en el lado externo

del motor de (error n.º 22833364)
base de datos de
Aurora MySQL
(03/05/2018) (p. 716)
Actualizaciones 2.04.2 Error n.º 24829050: LA OPTIMIZACIÓN DE

del motor de INDEX_MERGE_INTERSECTION GENERA RESULTADOS DE
base de datos de CONSULTAS INCORRECTOS
Aurora MySQL
(02/05/2019) (versión
2.04.2) (p. 704)
Errores de MySQL corregidos en las actualizaciones del motor de

base de datos de Aurora MySQL 1.x
La versión de Aurora compatible con MySQL 5.6 contiene todas las correcciones de errores de MySQL
hasta MySQL 5.6.10. La siguiente tabla identifica errores de MySQL adicionales corregidos por
actualizaciones del motor de base de datos Aurora MySQL y en qué actualización se corrigieron.

motor de base de
datos
Actualizaciones 1.1 • Las bases de datos de InnoDB con nombres que comienzan con
del motor de un dígito causan un error de analizador de búsqueda de texto
base de datos de completo (FTS). (Error n.º 17607956)
Aurora MySQL: • Las búsquedas de texto completo de InnoDB producen un error en
24/08/2015 (p. 759) bases de datos cuyos nombres comienzan con un dígito. (Error n.º
17161372)
• Para bases de datos InnoDB en Windows, el ID de objeto
de búsqueda de texto completo (FTS) no está en el formato
hexadecimal esperado. (Error n.º 16559254)
• Una regresión de código introducida en MySQL 5.6 afecta
negativamente al desempeño de DROP TABLE y ALTER TABLE.
Esto podría provocar una disminución del rendimiento entre
MySQL Server 5.5.x y 5.6.x. (Error n.º 16864741)
Actualizaciones 1.2, 1.3 • La anulación de una consulta dentro de innodb provoca que se
del motor de acabe bloqueando con una aserción. (Error n.º 1608883)

760

motor de base de
datos
base de datos de • No se puede crear un subproceso nuevo para el programador de
Aurora MySQL: eventos, ejecución de eventos o nueva conexión, y no se escribe
16/10/2015 (p. 756) ningún mensaje en el registro de errores. (Error n.º 16865959)
• Si una conexión cambiara su base de datos predeterminada y otra
conexión ejecutara simultáneamente SHOW PROCESSLIST, la
segunda conexión podría obtener acceso a la memoria no válida al
tratar de mostrar la memoria de la base de datos predeterminada
de la primera conexión. (Error n.º 11765252)
• PURGE BINARY LOGS por diseño no elimina archivos de
registro binario que se están utilizando o están activos, pero no se
proporciona ninguna notificación cuando sucede esto. (Error n.º
13727933)
• Para algunas instrucciones, podrían producirse fugas de memoria
cuando el optimizador elimina cláusulas de subconsultas
innecesarias. (Error n.º 15875919)
• Durante el cierre, el servidor podría intentar bloquear una
exclusión mutua que no se ha inicializado. (Error n.º 16016493)
• Una instrucción preparada que utilizó GROUP_CONCAT() y
una cláusula ORDER BY que nombró varias columnas podrían
provocar la suspensión del servidor. (Error n.º 16075310)
• Faltaba la instrumentación del esquema de desempeño para los
subprocesos de trabajo del esclavo. (Error n.º 16083949)
• STOP SLAVE podría provocar un interbloqueo si se emite
simultáneamente con una instrucción como SHOW STATUS,
que recupera los valores para una o más variables de
estado Slave_retried_transactions, Slave_heartbeat_period,
Slave_received_heartbeats, Slave_last_heartbeat o Slave_running.
(Error n.º 16088188)
• Una consulta de texto completo que utiliza el modo booleano
podría devolver cero resultados en algunos casos en los que
el término de búsqueda es una frase entrecomillada. (Error n.º
16206253)
• El intento del optimizador de eliminar cláusulas de la subconsulta
redundante producía una aserción al ejecutar una instrucción
preparada con una subconsulta en la cláusula ON de una
combinación en una subconsulta. (Error n.º 16318585)
• GROUP_CONCAT inestable, bloqueo en
ITEM_SUM::CLEAN_UP_AFTER_REMOVAL. (Error n.º 16347450)
• Intentar sustituir la lista predeterminada de palabras
excluidas de búsqueda de texto completo (FTS) de InnoDB
creando una tabla de InnoDB con la misma estructura que
INFORMATION_SCHEMA.INNODB_FT_DEFAULT_STOPWORD
genera un error. (Error n.º 16373868)
• Después de que el subproceso de cliente en un esclavo realice
una operación FLUSH TABLES WITH READ LOCK, seguida de
algunas actualizaciones en el principal, el esclavo se bloquea al
ejecutar SHOW SLAVE STATUS. (Error n.º 16387720)
• Al analizar una cadena de búsqueda delimitada, por ejemplo, "abc-
def"en una búsqueda de texto completo, InnoDB utiliza ahora

761

motor de base de
datos
los mismos delimitadores de palabras que MyISAM. (Error n.º
16419661)
• Bloqueo en FTS_AST_TERM_SET_WILDCARD. (Error n.º
16429306)
• SEGFAULT en FTS_AST_VISIT() para la prueba FTS RQG. (Error
n.º 16435855)
• Para las compilaciones de depuración, cuando el optimizador
elimina un Item_ref que señalaba a una subconsulta, se produce
una salida del servidor. (Error n.º 16509874)
• La búsqueda de texto completo en tablas de InnoDB produce
un error en búsquedas de frases literales combinadas con los
operadores + o -. (Error n.º 16516193)
• START SLAVE produce un error cuando se inicia el servidor
con las opciones --master-info-repository=TABLE relay-log-info-
repository=TABLE y con la confirmación automática establecida en
0, junto con --skip-slave-start. (Error n.º 16533802)
• Resultados de búsqueda de texto completo (FTS) de InnoDB muy
grandes podrían consumir una cantidad excesiva de memoria.
(Error n.º 16625973)
• En compilaciones de depuración, podría producirse una aserción
en OPT_CHECK_ORDER_BY al usar datos binarios directamente
en una cadena de búsqueda, ya que estos podrían incluir bytes
NULL y otros caracteres no significativos. (Error n.º 16766016)
• Para algunas instrucciones, podrían producirse fugas de memoria
cuando el optimizador elimina cláusulas de subconsultas
innecesarias. (Error n.º 16807641)
• Fue posible causar un interbloqueo después de emitir FLUSH
TABLES WITH READ LOCK con STOP SLAVE en una conexión
nueva en el esclavo y, a continuación, emitir SHOW SLAVE
STATUS mediante la conexión original. (Error n.º 16856735)
• GROUP_CONCAT() con un separador no válido podría provocar
una suspensión del servidor. (Error n.º 16870783)
• El servidor realiza un bloqueo excesivo en las exclusiones
mutuas LOCK_active_mi y active_mi->rli->data_lock para
cualquier instrucción con el "patrón" SHOW STATUS
LIKE, incluso cuando dicho patrón no se corresponde
con las variables de estado que utilizan esas exclusiones
mutuas (Slave_heartbeat_period, Slave_last_heartbeat,
Slave_received_heartbeats, Slave_retried_transactions y
Slave_running). (Error n.º 16904035)
• Una búsqueda de texto completo con el modificador IN BOOLEAN
MODE produce un error de aserción. (Error n.º 16927092)
• La búsqueda de texto completo en tablas de InnoDB produce un
error en búsquedas que utilizaron el operador booleano +. (Error
n.º 17280122)
• Interbloqueo de 4 direcciones: zombies, purga de binlogs, mostrar
lista de procesos y mostrar binlogs (Error n.º 17283409)

762

motor de base de
datos
• Cuando se anula y reinicia un subproceso SQL que espera
un bloqueo de confirmación, se provoca la omisión de una
transacción en el esclavo. (Error n.º 17450876)
• Se produce un error de búsqueda de texto completo de InnoDB
debido a un token "sin terminar". La cadena y la longitud de
la cadena deben transmitirse para realizar la comparación de
cadenas. (Error n.º 17659310)
• Un número elevado de tablas de InnoDB con particiones podría
consumir mucha más memoria, si se utilizan en MySQL 5.6 o 5.7,
que la memoria empleada por las mismas tablas en versiones
anteriores de MySQL Server. (Error n.º 17780517)
• Para consultas de texto completo, no comprobar que num_token
es inferior a max_proximity_item podría producir una aserción.
(Error n.º 18233051)
• Determinadas consultas para las tablas INFORMATION_SCHEMA
TABLES y COLUMNS podrían producir un uso excesivo de
memoria cuando hay un número elevado de tablas de InnoDB
vacías. (Error n.º 18592390)
• Al confirmar una transacción, ahora se utiliza un indicador para
comprobar si se ha creado un subproceso, en lugar de comprobar
el subproceso en sí, que utiliza más recursos (en particular cuando
se ejecuta el servidor con master_info_repository=TABLE). (Error
n.º 18684222)
• Si un subproceso de cliente en un esclavo ejecuta una operación
FLUSH TABLES WITH READ LOCK mientras el principal ejecuta
una instrucción DML, la ejecución de SHOW SLAVE STATUS en
el mismo cliente se bloquea y causa un interbloqueo. (Error n.º
19843808)
• Ordenar por un resultado de GROUP_CONCAT() podría provocar
una suspensión del servidor. (Error n.º 19880368)

763

motor de base de
datos
Actualizaciones 1.4 • SEGV en FTSPARSE(). (Error n.º 16446108)

del motor de • El diccionario de datos de InnoDB no se actualiza al cambiar el
base de datos de nombre de la columna. (Error n.º 19465984)
Aurora MySQL:
• Bloqueo de FTS después de cambiar el nombre de la tabla en una
03/12/2015 (p. 755)
base de datos diferente. (Error n.º 16834860)
• La imposibilidad de preparar el disparador en tablas truncadas
causa el error 1054. (Error n.º 18596756)
• Los cambios en los metadatos podrían causar problemas con la
ejecución del disparador. (Error n.º 18684393)
• No se elige la materialización para el campo UTF8 VARCHAR
largo. (Error n.º 17566396)
• Plan de ejecución no adecuado para ORDER BY con límite X.
(Error n.º 16697792)
• Adaptación de error n.º 11765744 A 5.1, 5.5 Y 5.6. (Error n.º
17083851)
• Problema de exclusión mutua en SQL/SQL_SHOW.CC que
produce SIG6. Origen probable FILL_VARIABLES. (Error n.º
20788853)
• Adaptación de error n.º 18008907 a versiones 5.5+. (Error n.º
18903155)
• Adaptar corrección para un error de desbordamiento de pila en
MySQL 5.7. (Error n.º 19678930)
Actualizaciones 1.5 • Se ha abordado una corrección incompleta de la búsqueda

del motor de de texto completa de MySQL que afecta a tablas en las que el
base de datos de nombre de la base de datos comienza por un dígito. (Error de
Aurora MySQL: puerto n.º 17607956)
11/01/2016 (p. 754)
Actualizaciones 1.6 • BACKPORT Bug #18694052 FIX FOR ASSERTION `!

del motor de M_ORDERED_REC_BUFFER' FAILED TO 5.6 (Error de puerto n.º
base de datos de 18305270)
Aurora MySQL: • SEGV IN MEMCPY(), HA_PARTITION::POSITION (Error de puerto
06/04/2016 (p. 752) n.º 18383840)
• WRONG RESULTS WITH PARTITIONING,INDEX_MERGE AND
NO PK (Error de puerto n.º 18167648)
• FLUSH TABLES FOR EXPORT: ASSERTION IN
HA_PARTITION::EXTRA (Error de puerto n.º 16943907)
• SERVER CRASH IN VIRTUAL HA_ROWS
HANDLER::MULTI_RANGE_READ_INFO_CONST (Error de
puerto n.º 16164031)
• RANGE OPTIMIZER CRASHES IN SEL_ARG::RB_INSERT()
Actualizaciones 1.6.5 • EL ESCLAVO NO PUEDE CONTINUAR LA REPLICACIÓN

del motor de DESPUÉS DE LA RECUPERACIÓN DEL BLOQUEO DEL
base de datos de PRINCIPAL (error de puerto n.º 17632285)
Aurora MySQL:
01/06/2016 (p. 752)

764

motor de base de
datos
Actualizaciones 1.7 • Mejora de la escalabilidad mediante la división del bloqueo

del motor de LOCK_grant. (Puerto WL n.º 8355)
base de datos de • La apertura del cursor en SELECT en el procedimiento
Aurora MySQL: almacenado causa un error de segmentación. (Error de puerto n.º
30/08/2016 (p. 751) 16499751)
• MySQL da un resultado incorrecto con algunos usos especiales.
(Error n.º 11751794)
• Bloqueo en GET_SEL_ARG_FOR_KEYPART: causado por el
parche para el error n.º 11751794. (Error n.º 16208709)
• Resultados incorrectos para una consulta simple realizada por
GROUP BY. (Error n.º 17909656)
• Filas adicionales en la consulta de semicombinación (semijoin) con
predicados de rango. (Error n.º 16221623)
• Agregar una cláusula ORDER BY tras una subconsulta IN podría
provocar la devolución de filas duplicadas. (Error n.º 16308085)
• Bloqueo con el comando EXPLAIN para una consulta con examen
amplio para GROUP BY, MyISAM. (Error n.º 16222245)
• El examen de índice amplio con predicado de entero entre comillas
devuelve datos aleatorios. (Error n.º 16394084)
• Si el optimizador estaba utilizando un examen de índice amplio,
el servidor podía detenerse mientras intentaba crear una tabla
temporal. (Error n.º 16436567)
• COUNT(DISTINCT) no debe contar valores NULL, pero se
cuentan cuando el optimizador utiliza el examen de índice amplio.
(Error n.º 17222452)
• Si una consulta tenía las funciones MIN()/MAX() y
aggregate_function(DISTINCT) (por ejemplo, SUM(DISTINCT))
y se ejecutaba utilizando el examen de índice amplio, los valores
de los resultados de MIN()/MAX() se establecían incorrectamente.
(Error n.º 17217128)
Actualizaciones 1.8 • Al suprimir todos los índices en una columna con varios índices,
del motor de InnoDB no podía bloquear una operación DROP INDEX cuando
base de datos de una restricción de clave externa requería un índice. (Error n.º
Aurora MySQL: 16896810)
18/10/2016 (p. 749) • Solución para bloqueo de restricción al agregar clave externa.
(Error n.º 16413976)
• Se ha corregido un bloqueo al recuperar un cursor en un
procedimiento almacenado y analizar o vaciar la tabla al mismo
tiempo. (Error n.º 18158639)
• Se ha corregido un error de incremento automático
cuando un usuario alteraba una tabla para cambiar el valor
AUTO_INCREMENT a un valor inferior al valor máximo de la
columna de incremento automático. (Error n.º 16310273)

765

motor de base de
datos
Actualizaciones 1.8.1 • OpenSSL cambió los parámetros de longitud de la clave Diffie-

del motor de Hellman debido al problema con LogJam. (Error n.º 18367167)
base de datos de
Aurora MySQL:
26/10/2016 (p. 749)
Actualizaciones 1.10 • La UNIÓN de tablas derivadas devuelve resultados incorrectos con

del motor de cláusulas '1=0/false'. (Error n.º 69471)
base de datos de • El servidor se bloquea en
Aurora MySQL: ITEM_FUNC_GROUP_CONCAT::FIX_FIELDS en la segunda
14/12/2016 (p. 746) ejecución del procedimiento almacenado. (Error n.º 20755389)
• Evitar que las consultas MySQL se paralicen demasiado tiempo
durante la sincronización de la caché de FTS. Para ello, se
descarga la tarea de sincronización de la caché en un subproceso
separado, en cuanto el tamaño de la caché traspasa el 10 % del
tamaño total. (Errores n.º 22516559 y n.º 73816)
Actualizaciones 1.11 • La ejecución de la clave externa DROP de la tabla ALTER

del motor de simultáneamente con otra operación DROP causa la desaparición
base de datos de de la tabla. (Error n.º 16095573)
Aurora MySQL: • Algunas consultas de INFORMATION SCHEMA que usaban
23/02/2017 (p. 743) ORDER BY no aplicaban una optimización de la operación filesort
como antes. (Error n.º 16423536)
• FOUND_ROWS () devuelve un recuento erróneo de filas en una
tabla. (Error n.º 68458)
• El servidor se bloquea en lugar de dar un error cuando hay
demasiadas tablas temporales abiertas. (Error n.º 18948649)
Actualizaciones 1.12 • Volver a cargar una tabla desalojada mientras estaba vacía
del motor de provocaba el restablecimiento del valor AUTO_INCREMENT.
base de datos de (Error n.º 21454472 y error n.º 77743)
Aurora MySQL: • No se encontraba un registro del índice en la restauración debido
05/04/2017 (p. 742) a incoherencias en la estructura de purge_node_t. La incoherencia
producía mensajes de advertencia y de error, por ejemplo, “error in
sec index entry update”, “unable to purge a record” y “tried to purge
sec index entry not marked for deletion”. (Error n.º 19138298, error
n.º 70214, error n.º 21126772 y error n.º 21065746)
• El cálculo incorrecto del tamaño de pila para la operación qsort
conduce al desbordamiento de la pila. (Error n.º 73979)
• No se encuentra el registro en un índice cuando se produce la
restauración. (Error n.º 70214 y error n.º 72419)
• ALTER TABLE agrega la columna TIMESTAMP en la
actualización. CURRENT_TIMESTAMP inserta datos ZERO. (Error
n.º 17392)

766

motor de base de
datos
Actualizaciones 1.13 • Volver a cargar una tabla desalojada mientras estaba vacía
del motor de provocaba el restablecimiento del valor AUTO_INCREMENT.
base de datos de (Error n.º 21454472 y error n.º 77743)
Aurora MySQL: • No se encontraba un registro del índice en la restauración debido
15/05/2017 (p. 740) a incoherencias en la estructura de purge_node_t. La incoherencia
producía mensajes de advertencia y de error, por ejemplo, “error in
sec index entry update”, “unable to purge a record” y “tried to purge
sec index entry not marked for deletion”. (Error n.º 19138298, error
n.º 70214, error n.º 21126772 y error n.º 21065746)
• El cálculo incorrecto del tamaño de pila para la operación qsort
conduce al desbordamiento de la pila. (Error n.º 73979)
• No se encuentra el registro en un índice cuando se produce la
restauración. (Error n.º 70214 y error n.º 72419)
• ALTER TABLE agrega la columna TIMESTAMP en la
actualización. CURRENT_TIMESTAMP inserta datos ZERO. (Error
n.º 17392)
Actualizaciones 1.14 Una búsqueda de texto completo combinada con tablas derivadas
del motor de (subconsultas de la cláusula FROM) producía una salida del servidor.
base de datos de Ahora, si una operación de texto completo depende de una tabla
Aurora MySQL: derivada, el servidor produce un error que indica que no se puede
07/08/2017 (p. 739) realizar una búsqueda de texto completo en una tabla materializada.
(Error n.º 68751 y error n.º 16539903)
Actualizaciones 1.14.4 • Los eventos que se pueden ignorar no funcionan y no se prueban

del motor de (error n.º 74683)
base de datos de • NEW->OLD ASSERT FAILURE 'GTID_MODE > 0' (error n.º
Aurora MySQL: 20436436)
13/03/2018 (p. 737)
Actualizaciones 1.15 • CREATE USER acepta el hash de contraseña y complemento,

del motor de pero no el hash de contraseña (error n.º 78033)
base de datos de • El motor de partición añade campos al conjunto de bits de
Aurora MySQL lectura para poder devolver entradas ordenadas desde un índice
(24/10/2017) (p. 735) particionado. Debido a esto, el búfer de combinaciones intenta
leer campos innecesarios. Se ha solucionado este problema
no añadiendo todos los campos de la partición a read_set, sino
que solo se realiza la ordenación en los campos de prefijo ya
establecidos en read_set. Se ha añadido un DBUG_ASSERT que,
si realiza key_cmp, se debe leer al menos el primer campo (error
n.º 16367691).
• La instancia de MySQL se paraliza “realizando el índice
SYNC” (error n.º 73816)
• Confirmación RBT_EMPTY(INDEX_CACHE->WORDS) en ALTER
TABLE CHANGE COLUMN (error n.º 17536995)
• La búsqueda de Fulltext de InnoDB no encuentra ningún registro
cuando hay puntos de guardado (error n.º 70333)

767

motor de base de
datos
Actualizaciones 1.15.1 • Revertido: la instancia de MySQL se paraliza “realizando el índice

del motor de SYNC” (error n.º 73816)
base de datos de • Revertido: confirmación RBT_EMPTY(INDEX_CACHE->WORDS)
Aurora MySQL en ALTER TABLE CHANGE COLUMN (error n.º 17536995)
(20/11/2017) (p. 734)
• Revertido: la búsqueda de Fulltext de InnoDB no encuentra ningún
registro cuando hay puntos de guardado (error n.º 70333)
Actualizaciones 1,17 • LAST_INSERT_ID se replica incorrectamente si se usan filtros de

del motor de replicación (error n.º 69861)
base de datos de • La consulta devuelve resultados distintos en función de la
Aurora MySQL configuración INDEX_MERGE (error n.º 16862316)
(13/03/2018) (p. 732)
• Nueva ejecución de procedimiento de consulta de la rutina
almacenada, plan de consulta poco eficiente (error n.º 16346367)
• InnoDB FTS: confirmación en
FTS_CACHE_APPEND_DELETED_DOC_IDS (error n.º 18079671)
• Confirmación RBT_EMPTY(INDEX_CACHE->WORDS) en ALTER
TABLE CHANGE COLUMN (error n.º 17536995)
• La búsqueda de Fulltext de InnoDB no encuentra ningún registro
cuando hay puntos de guardado (error n.º 70333, error n.º
17458835)
Actualizaciones 1.17.6 • Para una instrucción ALTER TABLE a la que se le cambió el

del motor de nombre o modificó el valor predeterminado de una columna
base de datos de BINARY, la alteración se realizó usando una copia de tabla y no in
Aurora MySQL situ. (Error n.º 67141, error n.º 14735373, error n.º 69580 y error
(06/09/2018) (p. 728) n.º 17024290)
• Una unión exterior entre una tabla normal y una derivada que son
implícitamente grupos podría provocar una salida del servidor.
(Error n.º 16177639)
Actualizaciones 1.17.7 • La operación DROP INDEX en una columna de clave externa

del motor de provoca la ausencia de una tabla. (Error n.º 16208542)
base de datos de • Fuga de memoria en add_derived_key(). (Error n.º 76349)
Aurora MySQL
• Para tablas con particiones, las consultas podrían devolver
(08/10/2018) (p. 727)
resultados diferentes en función de su si se usó Index Merge.
(Error n.º 16862316)
• Las consultas que usan la optimización index_merge (consulte
Index Merge Optimization) podrían devolver resultados no válidos
cuando se ejecutan en tablas particionadas con HASH. (Error n.º
17588348)
Actualizaciones 1.17.8 • ERROR N.º 13418638: CREAR TABLA SI NO EXISTE BLOQUEO

del motor de DE METADATOS DEMASIADO RESTRICTIVO
base de datos de
Aurora MySQL
(17/01/2019) (p. 726)

768

motor de base de
datos
Actualizaciones 1.19.0 • ERROR N.º 32917: DETECTAR ARCHIVOS DE GRUPO

del motor de TEMPORAL HUÉRFANOS Y GESTIONARLOS CON FLUIDEZ
base de datos de • ERROR N.º 63144: CREAR TABLA SI NO EXISTE BLOQUEO DE
Aurora MySQL METADATOS DEMASIADO RESTRICTIVO
(07/02/2019) (p. 724)

769
Seguridad con Aurora PostgreSQL
Uso de Amazon Aurora PostgreSQL

Amazon Aurora PostgreSQL es un motor de base de datos relacional completamente administrado,
compatible con PostgreSQL y de conformidad con ACID, que combina la velocidad y la fiabilidad
de las bases de datos comerciales de tecnología avanzada con la sencillez y la rentabilidad de las
bases de datos de código abierto. Aurora PostgreSQL es un reemplazo instantáneo para PostgreSQL
que simplifica y hace más rentable configurar, usar y escalar las implementaciones de PostgreSQL
nuevas y ya existentes, lo que le permitirá centrarse en su negocio y sus aplicaciones. Amazon RDS
proporciona administración para Aurora mediante la gestión de tareas de base de datos rutinarias como
el aprovisionamiento, la aplicación de parches, las copias de seguridad, la recuperación, la detección de
errores y la reparación. Amazon RDS también proporciona herramientas de migración que le permiten
convertir sus aplicaciones de Amazon RDS para PostgreSQL a Aurora PostgreSQL con un solo botón.
Aurora PostgreSQL puede trabajar con muchos estándares del sector. Por ejemplo, puede utilizar las
bases de datos de Aurora PostgreSQL para crear aplicaciones compatibles con HIPAA y para almacenar
información relacionada con la sanidad, incluida información sanitaria protegida (PHI) bajo un acuerdo
de asociación comercial (BAA) con AWS. Para obtener más información sobre BAA con AWS, consulte
Conformidad con HIPAA.
Temas
• Seguridad con Amazon Aurora PostgreSQL (p. 770)
• Migración de datos a Amazon Aurora con compatibilidad con PostgreSQL (p. 772)
• Administración de Amazon Aurora PostgreSQL (p. 795)
• Replicación con Amazon Aurora PostgreSQL (p. 796)
• Integración de Amazon Aurora PostgreSQL con otros servicios de AWS (p. 802)
• Administración de planes de ejecución de consultas para Aurora PostgreSQL (p. 802)
• Recuperación rápida después de una conmutación por error con la administración de caché del clúster
para Aurora PostgreSQL (p. 831)
• Actualización de una versión del motor de un clúster de base de datos de Aurora
PostgreSQL (p. 835)
• Prácticas recomendadas con Amazon Aurora PostgreSQL (p. 838)
• Referencia de Amazon Aurora PostgreSQL (p. 846)
• Actualizaciones del motor de base de datos para Amazon Aurora PostgreSQL (p. 856)
Seguridad con Amazon Aurora PostgreSQL

La seguridad de Amazon Aurora PostgreSQL se administra en tres niveles:
de datos e instancias de base de datos Aurora, se usa AWS Identity and Access Management (IAM).
Cuando se conecta a AWS con credenciales de IAM, la cuenta de IAM debe tener políticas de IAM que
otorguen los permisos necesarios para realizar operaciones de administración de Amazon RDS. Para
obtener más información, consulte Administración de identidad y acceso en Amazon Aurora (p. 163).
consola de Amazon RDS en https://console.aws.amazon.com/rds.
• Los clústeres de base de datos Aurora se deben crear en una Amazon Virtual Private Cloud (VPC). Para
controlar qué dispositivos e instancias Amazon EC2 pueden abrir conexiones al punto de enlace y al

770
Restricción de la administración de contraseñas
puerto de la instancia de base de datos los clústeres de base de datos Aurora en una VPC, debe usar
un grupo de seguridad de VPC. Las conexiones con el punto de enlace y el puerto se pueden realizar
por medio de la Capa de conexión segura (SSL). Además, las reglas del firewall de su compañía pueden
controlar si los dispositivos que se ejecutan en ella pueden abrir conexiones a una instancia de base de
datos. Para obtener más información acerca de las VPC, consulte VPC Amazon Virtual Private Cloud y
Aurora PostgreSQL solo admite clases de instancia db.r4 y db.t3 con la VPC predeterminada. En el caso
de la tenencia de una VPC predeterminada, la VPC se ejecuta en hardware compartido. En el caso de la
tenencia de una VPC dedicada, la VPC se ejecuta en una instancia de hardware dedicada. Para obtener
más información sobre las clases de instancias, consulte Selección de la clase de instancia de base
de datos (p. 61). Para obtener más información sobre la tenencia de VPC predeterminada y dedicada,
consulte Instancias dedicadas en la Guía del usuario de Amazon EC2 para instancias de Linux.
• Para autenticar el inicio de sesión y los permisos de un clúster de base de datos Amazon Aurora, puede
seguir el mismo procedimiento que con una instancia independiente de PostgreSQL.
Los comandos como CREATE ROLE, ALTER ROLE, GRANT y REVOKE funcionan de la misma forma que
en las bases de datos locales, al igual que la modificación directa de las tablas de los esquemas de las
bases de datos. Para obtener más información, consulte Autenticación de cliente en la documentación
de PostgreSQL.
Note
El mecanismo de autenticación mediante desafío-respuesta discontinuo (SCRAM) no es

compatible con Aurora PostgreSQL.
Cuando se crea una instancia de base de datos de Amazon Aurora PostgreSQL, el usuario maestro tiene
los siguientes privilegios predeterminados:
• LOGIN
• NOSUPERUSER
• INHERIT
• CREATEDB
• CREATEROLE
• NOREPLICATION
• VALID UNTIL 'infinity'
Para proporcionar servicios de administración para cada clúster de base de datos, se crea el usuario
rdsadmin cuando se crea el clúster de base de datos. Al intentar eliminar, cambiar de nombre, cambiar la
contraseña o cambiar los privilegios de la cuenta rdsadmin, se producirá un error.
Restricción de la administración de contraseñas

Puede restringir quién puede gestionar las contraseñas de usuarios de bases de datos a un rol especial. Al
hacerlo, podrá tener un mayor control sobre la administración de contraseñas del lado del cliente.
Puede habilitar la restricción de la administración de contraseñas con el parámetro estático

rds.restrict_password_commands y usar un rol denominado rds_password. Cuando el parámetro
rds.restrict_password_commands se establece en 1, solo los usuarios que sean miembros del
rol rds_password podrán ejecutar determinados comandos SQL. Los comandos SQL restringidos son
comandos que modifican las contraseñas de usuario de las bases de datos y el tiempo de vencimiento de
las contraseñas.
Para utilizar la administración de contraseñas restringida, su /el clúster de base de datos

de Amazon Aurora para PostgreSQL 10.6 o una versión posterior. Dado que el parámetro

771
Migración de datos a Aurora PostgreSQL
rds.restrict_password_commands es estático, para cambiarlo se requiere un reinicio de la base de

datos.
Cuando una base de datos tiene habilitada la restricción en la administración de contraseñas, si

intenta ejecutar comandos SQL restringidos, obtiene el siguiente error: ERROR: debe ser miembro de
rds_password para alterar las contraseñas.
A continuación figuran algunos ejemplos de comandos SQL que quedan restringidos cuando está
habilitada la restricción de la administración de contraseñas.
postgres=> CREATE ROLE myrole WITH PASSWORD 'mypassword';

postgres=> CREATE ROLE myrole WITH PASSWORD 'mypassword' VALID UNTIL '2020-01-01';
postgres=> ALTER ROLE myrole WITH PASSWORD 'mypassword' VALID UNTIL '2020-01-01';
postgres=> ALTER ROLE myrole WITH PASSWORD 'mypassword';
postgres=> ALTER ROLE myrole VALID UNTIL '2020-01-01';
postgres=> ALTER ROLE myrole RENAME TO myrole2;
Algunos comandos ALTER ROLE que incluyen RENAME TO podrían quedar también restringidos. La
restricción podría deberse a que el cambio de nombre de un rol de PostgreSQL con una contraseña MD5
borra la contraseña.
El rol rds_superuser tiene pertenencia al tol rds_password de forma predeterminada y esto no se

puede cambiar. Puede otorgar a otros roles pertenencia al rol rds_password mediante el comando SQL
GRANT. Recomendamos que dé pertenencia a rds_password solamente a unos cuantos roles que utilice
únicamente para la administración de contraseñas. Estos roles requieren el atributo CREATEROLE para
modificar otros roles.
Asegúrese de que comprueba los requisitos de las contraseñas del lado del cliente, como el vencimiento
y la complejidad necesaria. Recomendamos que restrinja los cambios relacionados con las contraseñas
mediante su propia utilidad del lado del cliente. Esta utilidad debería tener un rol que pertenezca a
rds_password y cuente con el atributo de rol CREATEROLE.
Migración de datos a Amazon Aurora con

compatibilidad con PostgreSQL
Tiene varias opciones para migrar datos desde una base de datos a un clúster de base de datos de
Compatibilidad de Amazon Aurora con PostgreSQL. Las opciones de migración dependen también de
la base de datos desde la que se realiza la migración y del tamaño de los datos que se van a migrar. A
continuación se muestran sus opciones:
Migración desde una instancia de base de datos PostgreSQL de RDS
Puede migrar datos directamente a partir de una instantánea de base de datos PostgreSQL en
Amazon RDS a un clúster de base de datos de Aurora PostgreSQL. Para obtener más información,
consulte Migración de una instantánea de base de datos PostgreSQL de RDS a un clúster de base de
datos de Aurora PostgreSQL (p. 773).
También puede migrar desde una instancia de base de datos PostgreSQL en RDS creando una
réplica de lectura de Aurora PostgreSQL de una instancia de base de datos PostgreSQL. Cuando el
retraso de réplica entre la instancia de base de datos PostgreSQL y la réplica de lectura de Aurora
PostgreSQL es cero, puede detener la replicación. En este momento, puede convertir la réplica de
lectura de Aurora en un clúster de base de datos de Aurora PostgreSQL independiente de lectura y
escritura. Para obtener más información, consulte Migración de datos desde una instancia de base de
datos PostgreSQL de RDS a un clúster de base de datos Aurora PostgreSQL utilizando una réplica de
lectura de Aurora (p. 775).

772
Migración de una instantánea de
base de datos PostgreSQL de RDS
Migración desde una base de datos no compatible con PostgreSQL
Puede utilizar AWS Database Migration Service (AWS DMS) para migrar datos desde una base de
datos que no sea compatible con PostgreSQL. Para obtener más información acerca de AWS DMS,
consulte ¿Qué es AWS Database Migration Service?
Importación de datos de Amazon S3
Puede realizar la migración mediante la importación de datos de Amazon S3 en una tabla que
pertenece a un clúster de base de datos de Aurora PostgreSQL para una instancia de base de datos
PostgreSQL de RDS. Para obtener más información, consulte Importación de datos de Amazon S3 en
un clúster de base de datos Aurora PostgreSQL (p. 784).
Para obtener una lista de regiones de AWS en las que está disponible Aurora, consulte Amazon Aurora en
la AWS General Reference.
Migración de una instantánea de base de datos

PostgreSQL de RDS a un clúster de base de datos de
Aurora PostgreSQL
Para crear un clúster de base de datos Aurora PostgreSQL, puede migrar una instantánea de base de
datos de una instancia de base de datos PostgreSQL de RDS. El nuevo clúster de base de datos Aurora
PostgreSQL se completa con los datos de la instancia de base de datos de PostgreSQL de RDS original.
La instantánea de base de datos debe haberse creado a partir de una instancia de base de datos de RDS
que ejecute la versión 9.6.1 o 9.6.3 de PostgreSQL. Para obtener más información acerca de la creación
de una instantánea de base de datos, consulte Creación de una instantánea de base de datos.
En algunos casos, la instantánea de base de datos puede no estar en la región de AWS en la que desee
ubicar los datos. Si es así, utilice la consola de Amazon RDS para copiar la instantánea de base de datos
en esa región de AWS. Para obtener más información acerca de la copia de una instantánea de base de
datos, consulte Copia de una instantánea de base de datos.
Al migrar la instantánea de base de datos con la consola, esta realiza las acciones necesarias para crear
tanto el clúster de base de datos como la instancia principal.
También puede elegir que el nuevo clúster de base de datos de Aurora PostgreSQL se cifre en reposo
mediante una clave de cifrado de AWS Key Management Service (AWS KMS). Esta opción solo está
disponible para las instantáneas de base de datos no cifradas.
Para migrar una instantánea de base de datos PostgreSQL con la consola de RDS, realice el
siguiente procedimiento:
2. Elija Snapshots (Instantáneas).
3. En la página Snapshots (Instantáneas), elija la instantánea que desea migrar a un clúster de base de
datos de Aurora PostgreSQL.
4. Elija Migrate Database (Migrar base de datos).
5. Defina los siguientes valores en la página Migrate Database (Migrar base de datos):
• DB Instance Class (Clase de instancia de base de datos): elija una clase de instancia de base de
datos que tenga el almacenamiento y la capacidad requeridos para la base de datos, por ejemplo
db.r3.large. Los volúmenes de clúster de Aurora aumentarán automáticamente a medida que
se incremente la cantidad de datos en la base de datos, hasta un tamaño máximo de 64 tebibytes
(TiB). Por lo tanto, solo tiene que elegir una clase de instancia de base de datos que se adapte a

773
Migración de una instantánea de
base de datos PostgreSQL de RDS
sus necesidades actuales de almacenamiento. Para obtener más información, consulte Información
general del almacenamiento de Aurora (p. 25).
• DB Instance Identifier (Identificador de instancia de base de datos): especifique un nombre para
el clúster de base de datos que sea único para su cuenta en la región de AWS que elija. Este
identificador se utiliza en las direcciones de punto de enlace para las instancias del clúster de base
de datos. Puede optar por agregar al nombre información como la región de AWS y el motor de
base de datos que ha elegido (por ejemplo, aurora-cluster1).
El identificador de instancias de bases de datos tiene las siguientes limitaciones:

• Debe incluir entre 1 y 63 caracteres alfanuméricos o guiones.
• No puede terminar con un guion ni contener dos guiones consecutivos.
• Debe ser único para todas las instancias de base de datos por cada cuenta de AWS y por región
de AWS.
• VPC: si ya dispone de una VPC, puede utilizar dicha VPC con su clúster de base de datos Aurora
PostgreSQL eligiendo el identificador de la VPC, por ejemplo vpc-a464d1c1. Para obtener
información acerca del uso de una VPC, consulte Cómo crear una VPC para el uso con Amazon
Aurora (p. 211).
De lo contrario, puede optar por hacer que Amazon RDS cree una VPC por usted eligiendo Create a
new VPC (Crear una VPC nueva).
• Subnet Group (Grupo de subred): si dispone de un grupo de subred existente, puede utilizarlo con
su clúster de base de datos Aurora PostgreSQL eligiendo el identificador del grupo de subred, por
ejemplo, gs-subnet-group1.
De lo contrario, puede optar por hacer que Amazon RDS cree un grupo de subred eligiendo Create
a new subnet group (Crear un grupo de subred nuevo).
• Publicly Accessible (Accesible públicamente): elija No para especificar que solo pueden obtener
acceso a las instancias de su clúster de base de datos los recursos que se encuentran dentro de su
VPC. Elija Yes (Sí) para especificar que los recursos de la red pública pueden obtener acceso a las
instancias de su clúster de base de datos. El valor predeterminado es Yes (Sí).
Note
No es necesario que su clúster de base de datos de producción esté en una subred

pública, ya que solo los servidores de su aplicación necesitan acceso a su clúster de base
de datos. Si su clúster de base de datos no necesita estar en una subred pública, defina
Publicly Accessible (Accesible públicamente) como No.
• Availability Zone (Zona de disponibilidad): elija la zona de disponibilidad para alojar la instancia
principal de su clúster de base de datos Aurora PostgreSQL. Para hacer que Amazon RDS elija un
valor de Availability Zone (Zona de disponibilidad), elija No Preference (Sin preferencia).
• Database Port (Puerto de base de datos): especifique el puerto predeterminado que se utilizará al
conectar a instancias del clúster de base de datos Aurora PostgreSQL. El valor predeterminado es
5432.
Note
Es posible que se encuentre detrás de un firewall de una compañía que no permite el

acceso a los puertos predeterminados, como el puerto predeterminado de PostgreSQL,
el 5432. En este caso, proporcione un valor de puerto permitido por el firewall corporativo.
Recuerde el valor del puerto cuando se conecte más adelante al clúster de base de datos
de Aurora PostgreSQL.
• Enable Encryption (Habilitar cifrado): elija Yes (Sí) para que el nuevo clúster de base de datos
Aurora PostgreSQL se cifre "en reposo". Si elige Yes (Sí), tendrá que elegir también una clave de
cifrado AWS KMS como valor para Master
Versión de API Key (Clave maestra).
2014-10-31
774
Migración de una instancia de base de datos PostgreSQL
de RDS mediante una réplica de lectura de Aurora
• Auto Minor Version Upgrade (Actualización automática de versiones secundarias): seleccione

Enable auto minor version upgrade (Habilitar actualización automática de versiones secundarias)
si desea habilitar su clúster de base de datos Aurora PostgreSQL para recibir actualizaciones de
las versiones secundarias del motor de base de datos PostgreSQL automáticamente cuando estén
disponibles.
La opción Auto Minor Version Upgrade (Actualización automática a versiones secundarias) solo
es válida para las actualizaciones secundarias de las versiones del motor de PostgreSQL para su
clúster de base de datos Aurora PostgreSQL. No tiene validez para los parches periódicos que se
utilizan para mantener la estabilidad del sistema.
6. Elija Migrate (Migrar) para migrar la instantánea de base de datos.
7. Elija Instances y, a continuación, seleccione el icono de flecha para mostrar la información detallada
del clúster de base de datos y monitorizar el progreso de la migración. En la página de detalles,
encontrará el punto de enlace del clúster que se utiliza para conectar a la instancia principal del clúster
de base de datos. Para obtener más información acerca de la conexión a un clúster de base de datos
de Aurora PostgreSQL, consulte Conexión a un clúster de base de datos Amazon Aurora (p. 148).
Migración de datos desde una instancia de base de

datos PostgreSQL de RDS a un clúster de base de
datos Aurora PostgreSQL utilizando una réplica de
lectura de Aurora
Puede migrar desde una instancia de base de datos PostgreSQL a un clúster de base de datos Aurora
PostgreSQL utilizando una réplica de lectura de Aurora. Cuando necesite migrar de una instancia de base
de datos PostgreSQL de RDS en un clúster de base de datos Aurora PostgreSQL, le recomendamos
utilizar este enfoque.
En este caso, Amazon RDS utiliza la funcionalidad de replicación de streaming del motor de base de datos
PostgreSQL para crear un tipo especial de clúster de base de datos para la instancia de base de datos
PostgreSQL de origen. Este tipo de clúster de base de datos se denomina "réplica de lectura de Aurora".
Las actualizaciones realizadas en la instancia de base de datos PostgreSQL de origen se replican de
forma asíncrona en la réplica de lectura de Aurora.
Temas
• Información general de la migración de datos mediante una réplica de lectura de Aurora (p. 775)
• Preparación para la migración de datos mediante una réplica de lectura de Aurora (p. 776)
• Creación de una réplica de lectura de Aurora (p. 777)
• Promoción de una réplica de lectura de Aurora (p. 783)
Información general de la migración de datos mediante una

réplica de lectura de Aurora
Para migrar desde una instancia de base de datos PostgreSQL de RDS a un clúster de base de datos
PostgreSQL de Aurora, recomendamos crear una réplica de lectura de Aurora de la instancia de base de
datos PostgreSQL de origen. Cuando el retraso de réplica entre la instancia de base de datos PostgreSQL
y la réplica de lectura de Aurora PostgreSQL es cero, puede detener la replicación. En este momento,
puede promocionar la réplica de lectura de Aurora para que sea un clúster de base de datos Aurora
PostgreSQL independiente. Este clúster de base de datos independiente puede aceptar cargas de
escritura.

775
Esta migración puede tardar un tiempo considerable, aproximadamente varias horas por tebibyte (TiB)
de datos. Durante la migración, la instancia de PostgreSQL en Amazon RDS acumulará segmentos
de registro de escritura previa (WAL). Asegúrese de que la instancia de Amazon RDS tenga suficiente
capacidad de almacenamiento para estos segmentos.
Cuando se crea una réplica de lectura de Aurora de una instancia de base de datos de PostgreSQL,
Amazon RDS crea una instantánea de base de datos de la instancia de base de datos de PostgreSQL de
origen. Esta instantánea es privada para Amazon RDS y no supone ningún gasto. Amazon RDS migra
a continuación los datos de la instantánea de base de datos a la réplica de lectura de Aurora. Una vez
que se migran los datos de la instantánea de base de datos al nuevo clúster de base de datos Aurora
PostgreSQL, RDS comenzará la replicación entre la instancia de base de datos PostgreSQL y el clúster de
base de datos Aurora PostgreSQL.
Solo puede tener una réplica de lectura de Aurora para una instancia de base de datos PostgreSQL. Si
intenta crear una réplica de lectura de Aurora para la instancia de PostgreSQL en Amazon RDS y ya tiene
una réplica de lectura, la solicitud será rechazada.
Note
Pueden surgir problemas de replicación a causa de las diferencias de características entre Aurora
PostgreSQL y la versión del motor de PostgreSQL de la instancia de base de datos PostgreSQL
en RDS que es la instancia maestra de la replicación. Solo puede replicar desde una instancia
de PostgreSQL en Amazon RDS que sea compatible con la versión de Aurora PostgreSQL
en cuestión. Por ejemplo, si la versión admitida de Aurora PostgreSQL es la 9.6.3, la instancia
de base de datos PostgreSQL en Amazon RDS debe ejecutar la versión 9.6.1 o posterior. Si
se produce un error, puede encontrar ayuda en el foro de la comunidad de Amazon RDS o
contactando con AWS Support.
Para obtener más información sobre las réplicas de lectura de PostgreSQL, consulte Trabajo con réplicas
de lectura en la Guía del usuario de Amazon RDS.
Preparación para la migración de datos mediante una réplica de

lectura de Aurora
Para migrar datos de su instancia de PostgreSQL para RDS en un clúster de Aurora PostgreSQL,
asegúrese de que su instancia disponga de una capacidad de almacenamiento suficiente. Esta capacidad
de almacenamiento es para los segmentos de registro de escritura previa (WAL) que se acumulan
durante la migración. Existen varias métricas que puede utilizar para comprobarlo y que se describen a
continuación.
FreeStorageSpace Espacio de almacenamiento disponible.
Unidades: bytes
OldestReplicationSlotLag Tamaño de retardo de datos de WAL en la replica

con mayor retardo.
Unidades: megabytes
RDSToAuroraPostgreSQLReplicaLag Cantidad de tiempo en segundos de retardo de un

clúster de base de datos de Aurora PostgreSQL
con respecto a la instancia de base de datos de
RDS de origen.
TransactionLogsDiskUsage Espacio en disco utilizado por los logs de

transacciones.

776
Unidades: megabytes
Para obtener más información sobre la monitorización de una instancia de RDS, consulte Monitoring
(Monitorización) en la Guía del usuario de Amazon RDS.
Creación de una réplica de lectura de Aurora

Puede crear una réplica de lectura de Aurora para una instancia de base de datos PostgreSQL por medio
de la consola o de la AWS CLI.
Consola
Para crear una réplica de lectura de Aurora a partir de una instancia de base de datos PostgreSQL
3. Elija la instancia de base de datos PostgreSQL que desea usar como origen para la réplica de
lectura de Aurora y elija Create Aurora Read Replica (Crear réplica de lectura de Aurora) en Actions
(Acciones).
4. Elija las especificaciones del clúster de base de datos que desee usar para la réplica de lectura de
Aurora y que se describen en la tabla siguiente.

777
Multi-AZ Deployment (Implementación Elija Create Replica in Different Zone (Crear réplica en otra
Multi-AZ) zona) para crear la instancia de escritura del nuevo clúster
de base de datos en otra zona de disponibilidad de la
región de AWS de destino. Para obtener más información
acerca del uso de varias zonas de disponibilidad, consulte
Elección de Regiones y zonas de disponibilidad (p. 64).
DB instance identifier (Identificador de Especifique un nombre para la instancia principal de su

instancias de bases de datos) clúster de base de datos de réplica de lectura de Aurora.
Este identificador se utiliza en la dirección del punto de
enlace de la instancia principal del nuevo clúster de base
de datos.

• Debe incluir entre 1 y 63 caracteres alfanuméricos o

guiones.
consecutivos.
AWS.
El clúster de réplica de lectura de Aurora se crea a partir

de una instantánea de la instancia de base de datos
de origen. Por lo tanto, el nombre de usuario principal
y la contraseña principal de la réplica de lectura de
Aurora coinciden con el nombre de usuario principal y
la contraseña principal de la instancia de base de datos
origen.
Virtual Private Cloud (VPC) Elija la VPC que alojará el clúster de base de datos. Elija
Create new VPC (Crear una VPC) para que Amazon
RDS cree una VPC automáticamente. Para obtener más
de datos (p. 86).
Subnet group Elija el grupo de subredes de base de datos que desea

utilizar para el clúster de base de datos. Elija Create
new DB subnet group (Crear nuevo grupo de subredes
de base de datos) para que Amazon RDS cree un
grupo de subredes de base de datos. Para obtener más
de datos (p. 86).

778
Public accessibility (Acceso público) Elija Yes (Sí) para asignar al clúster de base de datos una
dirección IP pública; de lo contrario, seleccione No. Las
instancias del clúster de base de datos pueden ser una
combinación de instancias de base de datos públicas y
privadas. Para obtener más información acerca del modo
Internet. (p. 223).

VPC security groups Elija uno o varios grupos de seguridad de VPC para
proteger el acceso de red al clúster de base de datos.
Elija Create new VPC security group (Crear un grupo de
seguridad de VPC) para que Amazon RDS cree un grupo
de seguridad de VPC automáticamente. Para obtener más
de datos (p. 86).
Los clústeres de base de datos de Aurora PostgreSQL
utilizan de forma predeterminada el puerto 5432 de
PostgreSQL. Los firewalls de algunas compañías bloquean
las conexiones a este puerto. Si el firewall de su compañía
DB Parameter Group (Grupo de Elija un grupo de parámetros de base de datos para el

parámetros de base de datos) clúster de base de datos PostgreSQL de Aurora. Aurora
cuenta con un grupo de parámetros de base de datos
predeterminado que puede utilizar. Si lo prefiere, puede
crear su propio grupo de parámetros de base de datos.
Para obtener más información acerca de los grupos de
parámetros de base de datos, consulte Trabajo con los
grupos de parámetros de base de datos y grupos de
DB cluster parameter group (Grupo Elija un grupo de parámetros de clúster de base de datos
de parámetros de clúster de base de para el clúster de base de datos Aurora PostgreSQL.
datos) Aurora cuenta con un grupo de parámetros de clúster de
base de datos predeterminado que puede utilizar. Si lo
prefiere, puede crear su propio grupo de parámetros de
clúster de base de datos. Para obtener más información
acerca de los grupos de parámetros de clúster de base de
datos, consulte Trabajo con los grupos de parámetros de
base de datos y grupos de parámetros de clúster de base
de datos (p. 259).

779
Cifrado Elija Enable encryption (Habilitar cifrado) para que el nuevo

clúster de base de datos de Aurora se cifre en reposo.
Si elige Enable encryption (Habilitar cifrado), seleccione
también una clave de cifrado de AWS KMS como valor de
Master key (Clave maestra).
Prioridad Elija una prioridad de conmutación por error para el

clúster de base de datos. Si no elije un valor, el ajuste
Aurora (p. 314).
Backup retention period (Periodo de Elija el tiempo (entre 135 y 35 días) durante el que Aurora
retención de copia de seguridad) conservará las copias de seguridad de la base de datos.
Los backups se pueden utilizar para las restauraciones
a un momento dado (PITR) de la base de datos con una

Monitoring Role Solo está disponible si eligió Enable Enhanced Monitoring

(Habilitar monitorización mejorada). El rol de AWS Identity
and Access Management (IAM) que se debe usar para la
monitorización mejorada. Para obtener más información,
consulte Configuración y habilitación de la monitorización
mejorada (p. 395).
Granularity (Grado de detalle) Solo está disponible si eligió Enable Enhanced Monitoring
(Habilitar monitorización mejorada). Defina el intervalo,
en segundos, en el que se recopilan las métricas para el
Auto minor version upgrade Elija Yes (Sí) para habilitar el clúster de base de datos
(Actualización automática de de Aurora PostgreSQL para recibir actualizaciones de
versiones secundarias) las versiones secundarias del motor de base de datos
PostgreSQL automáticamente cuando estén disponibles.
La opción Auto minor version upgrade (Actualización

automática a versiones secundarias) solo se aplica a
las actualizaciones de las versiones secundarias del
motor de base de datos PostgreSQL para el clúster de
base de datos Aurora PostgreSQL. No tiene validez para
los parches periódicos que se utilizan para mantener la
estabilidad del sistema.
Maintenance window (Periodo de Elija el intervalo de tiempo semanal durante el que se

mantenimiento) puede llevar a cabo el mantenimiento del sistema.
5. Elija Create read replica (Crear réplica de lectura).

780
AWS CLI
Para crear una réplica de lectura de Aurora a partir de una instancia de base de datos PostgreSQL de
origen, use los comandos create-db-cluster y create-db-instance de la AWS CLI para crear un clúster
de base de datos de Aurora PostgreSQL nuevo. Cuando llame al comando create-db-cluster, incluya el
parámetro --replication-source-identifier para identificar el Nombre de recurso de Amazon
(ARN) de la instancia de base de datos PostgreSQL de origen. Para obtener más información sobre los
ARN de Amazon RDS, consulte Amazon Relational Database Service (Amazon RDS) en la AWS General
Reference.
No especifique el nombre de usuario maestro, la contraseña maestra o el nombre de base de datos.

La réplica de lectura de Aurora utiliza el mismo nombre de usuario maestro, la contraseña maestra y el
nombre de base de datos que la instancia de base de datos PostgreSQL.
aws rds create-db-cluster --db-cluster-identifier sample-replica-cluster --engine aurora-

postgresql \
--db-subnet-group-name mysubnetgroup --vpc-security-group-ids sg-c7e5b0d2 \
--replication-source-identifier arn:aws:rds:us-west-2:123456789012:db:master-
postgresql-instance
Para Windows:
aws rds create-db-cluster --db-cluster-identifier sample-replica-cluster --engine aurora-

postgresql ^
--db-subnet-group-name mysubnetgroup --vpc-security-group-ids sg-c7e5b0d2 ^
--replication-source-identifier arn:aws:rds:us-west-2:123456789012:db:master-
postgresql-instance
Si usa la consola para crear un clúster de base de datos Aurora, RDS crea automáticamente la instancia
principal de la réplica de lectura de Aurora del clúster de base de datos. Si usa la CLI para crear una
réplica de lectura de Aurora, debe crear expresamente la instancia principal del clúster de base de datos.
La instancia principal es la primera instancia que se crea en un clúster de base de datos.
Puede crear una instancia principal para el clúster de base de datos con el comando de la CLI create-
db-instance y los siguientes parámetros:

• --db-instance-class

• --engine aurora-postgresql
El motor de base de datos que se debe utilizar.
En el siguiente ejemplo, creará una instancia principal denominada myreadreplicainstance para el

clúster de base de datos denominado myreadreplicacluster. Realice esta tarea mediante la clase de
instancia de base de datos especificada en myinstanceclass.
Example

781

--engine aurora-postgresql
Para Windows:

--engine aurora-postgresql
API de RDS
Para crear una réplica de lectura de Aurora a partir de una instancia de base de datos PostgreSQL de
origen, use las operaciones de la API de RDS CreateDBCluster y CreateDBInstance para crear una
instancia principal y un clúster de base de datos de Aurora nuevos. No especifique el nombre de usuario
maestro, la contraseña maestra o el nombre de base de datos. La réplica de lectura de Aurora utiliza el
mismo nombre de usuario maestro, la contraseña maestra y el nombre de base de datos que la instancia
de base de datos PostgreSQL.
Puede crear un nuevo clúster de base de datos de Aurora para una réplica de lectura de Aurora a partir de
una instancia de base de datos de PostgreSQL de origen. Para ello, use la operación de la API de RDS
CreateDBCluster con los siguientes parámetros:

• DBSubnetGroupName
El nombre del grupo de subredes de la base de datos que desea asociar con este clúster de base de
datos.
• Engine=aurora-postgresql
El nombre del motor que se debe utilizar.

• ReplicationSourceIdentifier
El nombre de recurso de Amazon (ARN) de la instancia de base de datos PostgreSQL de origen. Para
(Amazon RDS) en la Referencia general de Amazon Web Services.
• VpcSecurityGroupIds
La lista de grupos de seguridad de VPC de Amazon EC2 que asociar a este clúster de base de datos.
En el siguiente ejemplo, creará un clúster de base de datos denominado myreadreplicacluster

desde una instancia de base de datos PostgreSQL de origen. Este clúster tiene un ARN establecido
en mysqlmasterARN. El clúster se asocia a un grupo de subredes de base de datos denominado
mysubnetgroup y a un grupo de seguridad de VPC denominado mysecuritygroup.
Example
&DBSubnetGroupName=mysubnetgroup

782
&Engine=aurora-postgresql
&ReplicationSourceIdentifier=mysqlmasterARN
&SignatureVersion=4
&Version=2014-10-31
&VpcSecurityGroupIds=mysecuritygroup
&X-Amz-Date=20150927T164851Z
&X-Amz-Signature=6a8f4bd6a98f649c75ea04a6b3929ecc75ac09739588391cd7250f5280e716db
Si usa la consola para crear un clúster de base de datos Aurora, Amazon RDS crea automáticamente la
instancia principal de la réplica de lectura de Aurora del clúster de base de datos. Si usa la CLI para crear
una réplica de lectura de Aurora, debe crear expresamente la instancia principal del clúster de base de
datos. La instancia principal es la primera instancia que se crea en un clúster de base de datos.
Puede crear una instancia principal para el clúster de base de datos con la operación CreateDBInstance
de la API de RDS y los siguientes parámetros:

• DBInstanceClass
• DBInstanceIdentifier

• Engine=aurora-postgresql
El nombre del motor que se debe utilizar.
En este ejemplo, creará una instancia principal denominada myreadreplicainstance para el clúster de
base de datos denominado myreadreplicacluster. Realice esta tarea mediante la clase de instancia
de base de datos especificada en myinstanceclass.
Example
&DBInstanceClass=myinstanceclass
&DBInstanceIdentifier=myreadreplicainstance
&Engine=aurora-postgresql
&SignatureVersion=4
&Version=2014-09-01
&X-Amz-Date=20140424T194844Z
&X-Amz-Signature=bee4aabc750bf7dad0cd9e22b952bd6089d91e2a16592c2293e532eeaab8bc77
Promoción de una réplica de lectura de Aurora

Una vez que se complete la migración, puede promover la réplica de lectura de Aurora a un clúster de
base de datos independiente. Después, puede dirigir sus aplicaciones cliente al punto de enlace para la
réplica de lectura de Aurora. Para obtener más información acerca de los puntos de enlace de Aurora,

783
Importación de datos S3 en Aurora PostgreSQL
consulte Administración de conexiones de Amazon Aurora (p. 3). La promoción debería concluir con
bastante rapidez. No podrá eliminar la instancia de base de datos PostgreSQL maestra ni desvincular la
instancia de base de datos y la réplica de lectura de Aurora hasta que finalice la promoción.
Antes de promocionar la réplica de lectura de Aurora, detenga la escritura de transacciones en la instancia

de base de datos PostgreSQL de origen. A continuación, espere hasta que el retardo de la réplica de
lectura de Aurora llegue a 0.
Una vez que promocione la réplica de lectura, confirme que la promoción se haya completado. Para ello,
elija Instances (Instancias) en el panel de navegación y confirme que hay un evento Promoted Read
Replica cluster to stand-alone database cluster (Clúster de réplica de lectura promocionado a clúster de
base de datos independiente) para su réplica de lectura. Una vez que haya finalizado la promoción, la
instancia de base de datos PostgreSQL maestra y la réplica de lectura de Aurora se desvincularán. En ese
momento, podrá eliminar de forma segura la instancia de base de datos si lo desea.
Consola
Para promover una réplica de lectura de Aurora a un clúster de base de datos Aurora
3. Elija la instancia de base de datos la réplica de lectura de Aurora y elija Promote Read Replica
(Promocionar réplica de lectura) en Actions (Acciones).
4. Elija Promote Read Replica.
AWS CLI
Para promocionar una réplica de lectura de Aurora a un clúster de base de datos independiente, utilice el
comando promote-read-replica-db-cluster de la AWS CLI.
Example

Para Windows:

Importación de datos de Amazon S3 en un clúster de

base de datos Aurora PostgreSQL
Puede importar datos de Amazon S3 en una tabla que pertenece a un un clúster de base de datos Aurora
PostgreSQL. Para hacerlo, puede utilizar la extensión aws_s3 de PostgreSQL que proporciona Aurora
PostgreSQL .
Para obtener información adicional sobre cómo almacenar datos con Amazon S3, consulte Crear un
bucket en la Guía de introducción a Amazon Simple Storage Service. Para obtener instrucciones sobre
cómo cargar un archivo en un bucket de Amazon S3, consulte Añadir un objeto a un bucket en la Guía de
introducción a Amazon Simple Storage Service.

784
Temas
• Recopilación e importación de datos de Amazon S3 (p. 785)
• Utilización de un rol de IAM para acceder a un archivo de Amazon S3 (p. 786)
• Utilización de credenciales de seguridad para acceder a un archivo de Amazon S3 (p. 789)
• Gestión de formatos de archivo de Amazon S3 (p. 790)
• Referencia de funciones (p. 792)
Recopilación e importación de datos de Amazon S3

Para importar datos almacenados en un bucket de Amazon S3 en una tabla de base de datos de
PostgreSQL, recopile la siguiente información y utilice la función aws_s3.table_import_from_s3,
como se describe.
Para importar datos de S3 en Aurora PostgreSQL , realice el siguiente procedimiento:
1. Inicie psql y utilice el siguiente comando para instalar las extensiones de PostgreSQL requeridas.
Entre estas se incluyen las extensiones aws_s3 y aws_commons.
psql=> CREATE EXTENSION aws_s3 CASCADE;

NOTICE: installing required extension "aws_commons"
La extensión aws_s3 proporciona la función aws_s3.table_import_from_s3 (p. 792) que se utiliza

para importar datos de Amazon S3.
2. Proporcione permiso para acceder al archivo de Amazon S3 que desee importar. Para hacerlo, cree
un rol de AWS Identity and Access Management (IAM) que tenga acceso al bucket de Amazon S3
en el que se encuentra el archivo. A continuación, asigne el rol al clúster de base de datos Aurora
PostgreSQL .
Para obtener información detallada sobre cómo configurar un rol de IAM para proporcionar permiso de
acceso, consulte Utilización de un rol de IAM para acceder a un archivo de Amazon S3 (p. 786).
3. Recopile la información requerida para la función table_import_from_s3 realizando los siguientes
pasos:
a. Obtenga la siguiente información para el archivo de Amazon S3 que desee importar:
• Nombre de bucket: un bucket es un contenedor para objetos o archivos de Amazon S3.

• Ruta de archivo: la ruta de archivo localiza el archivo en el bucket de Amazon S3.
• Región de AWS: la región de AWS es la ubicación del bucket de Amazon S3.
Para descubrir cómo obtener esta información, consulte Ver un objeto en la Guía de introducción
a Amazon Simple Storage Service.
b. Utilice al función aws_commons.create_s3_uri (p. 794) para crear una estructura
aws_commons._s3_uri_1 para contener esta información de archivo, como se muestra en el
ejemplo siguiente.
psql=> SELECT aws_commons.create_s3_uri(

'sample_s3_bucket',
'sample.csv',
'us-east-1'
) AS s3_uri \gset
Posteriormente, debe incluir esta estructura aws_commons._s3_uri_1 en el parámetro

s3_info para la llamada a la función aws_s3.table_import_from_s3 (p. 792).

785
c. Identifique la tabla de base de datos de PostgreSQL en la que colocar los datos. Por ejemplo, a
continuación se incluye un ejemplo de tabla de base de datos t1.
psql=> CREATE TABLE t1 (bid bigint PRIMARY KEY, name varchar(80));
4. Después de completar las tareas de preparación, utilice la función

aws_s3.table_import_from_s3 (p. 792) para importar datos de Amazon S3.
A continuación se muestra un ejemplo típico de PostgreSQL utilizando psql.
psql=> SELECT aws_s3.table_import_from_s3(

't1',
'',
'(format csv)',
:'s3_uri'
);
• t1: nombre de la tabla en el clúster de base de datos de PostgreSQL en la que copiar los datos.
• '': lista opcional de columnas en la tabla de la base de datos. Puede utilizar este parámetro para indicar
qué columnas de los datos de S3 van en las columnas de la tabla. Si no se especifica ninguna columna,
se copian en la tabla todas las columnas. Para obtener un ejemplo de uso de una lista de columnas,
consulte Importación de un archivo de Amazon S3 que utiliza un delimitador personalizado (p. 790).
• (format csv): argumentos de COPY de PostgreSQL. El proceso de copia utiliza los argumentos y el
formato del comando COPY de PostgreSQL. En el ejemplo anterior, el comando COPY utiliza el formato
de archivo de valores separados con coma (CSV) para copiar los datos. Para más ejemplos, consulte
Gestión de formatos de archivo de Amazon S3 (p. 790).
• s3_uri: una estructura que contiene la información que identifica el archivo de Amazon S3.
Para obtener más información sobre esta función, consulte aws_s3.table_import_from_s3 (p. 792).
Utilización de un rol de IAM para acceder a un archivo de

Amazon S3
Antes de cargar datos desde un archivo de Amazon S3, otorgue permiso a su clúster de base de datos
Aurora PostgreSQL para acceder a Amazon S3. Para hacerlo, cree un rol de IAM que tenga acceso al
bucket de Amazon S3 y, a continuación, asigne el rol a su clúster de base de datos. De esta forma, no
tiene que facilitar ni administrar información adicional de credenciales.
Para dar a un clúster de base de datos Aurora PostgreSQL acceso a Amazon S3 a través de un
rol de IAM, realice el siguiente procedimiento:
1. Cree una política de IAM para proporcionar los permisos de bucket y objeto que permitan que su
clúster de base de datos Aurora PostgreSQL acceda a Amazon S3.
Incluya las siguientes acciones requeridas en la política para permitir la transferencia de archivos
desde un bucket de Amazon S3 a Aurora PostgreSQL:
• GetObject
• ListBucket
Para obtener información adicional sobre cómo crear una política de IAM para Aurora PostgreSQL,
consulte Creación y uso de una política de IAM para el acceso a bases de datos de IAM (p. 183).

786
El siguiente comando de la AWS CLI crea una política de IAM llamada rds-s3-integration-
policy con estas opciones. Otorga acceso a un bucket llamado your-s3-bucket-arn.
Note
Después de crear la política, anote el nombre de recurso de Amazon (ARN) de la política.

Necesita el ARN para un paso posterior del proceso de importación.
Example
aws iam create-policy \

--policy-name rds-s3-integration-policy \
--policy-document '{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "s3integration",
"Action": [
"s3:GetObject",
"s3:ListBucket",
"s3:PutObject"
],
"Effect": "Allow",
"Resource": [
"arn:aws:s3:::your-s3-bucket-arn",
"arn:aws:s3:::your-s3-bucket-arn/*"
]
}
]
}'
Para Windows:
aws iam create-policy ^

--policy-name rds-s3-integration-policy ^
--policy-document '{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "s3integration",
"Action": [
"s3:GetObject",
"s3:ListBucket",
"s3:PutObject"
],
"Effect": "Allow",
"Resource": [
"arn:aws:s3:::your-s3-bucket-arn",
"arn:aws:s3:::your-s3-bucket-arn/*"
]
}
]
}'
2. Cree un rol de IAM que Aurora PostgreSQL pueda asumir en su nombre para acceder a sus buckets
de Amazon S3. Para obtener más información, consulte Crear una función para delegar permisos a un
usuario de IAM en la Guía del usuario de IAM.

787
El siguiente ejemplo muestra cómo se usa el comando de la AWS CLI para crear un rol con el nombre
rds-s3-integration-role.
Example
aws iam create-role \

--role-name rds-s3-integration-role \
--assume-role-policy-document '{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "rds.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}'
Para Windows:
aws iam create-role ^

--role-name rds-s3-integration-role ^
--assume-role-policy-document '{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "rds.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}'
3. Asocie la política de IAM que creó al rol de IAM creado.
El siguiente comando de la AWS CLI asocia la política creada anteriormente al rol rds-s3-
integration-role. Sustituya your-policy-arn por el ARN de la política anotado en el paso
anterior.
Example
aws iam attach-role-policy \

--policy-arn your-policy-arn \
--role-name rds-s3-integration-role
Para Windows:
aws iam attach-role-policy ^

--policy-arn your-policy-arn ^
--role-name rds-s3-integration-role

788
4. Añada el rol de IAM al clúster de base de datos de Aurora PostgreSQL mediante Consola de
administración de AWS o AWS CLI, como se describe a continuación.
Consola
Para añadir un rol de IAM para un clúster de base de datos de PostgreSQL utilizando la consola
2. Seleccione el nombre de clúster de base de datos de PostgreSQL para mostrar sus detalles.
3. En la pestaña Connectivity & security (Conectividad y seguridad), en la sección Manage IAM roles
(Administrar roles de IAM), elija el rol que desee añadir en Add IAM roles to this instance (Añadir roles
de IAM a esta instancia).
4. En Feature Feature (Característica), elija s3Import.
5. Seleccione Add role (Añadir rol).
AWS CLI
Para añadir un rol de IAM para un clúster de base de datos de PostgreSQL mediante la CLI,
realice el siguiente procedimiento:
• Utilice el siguiente comando para añadir el rol al clúster de base de datos de PostgreSQL
mydbcluster. Sustituya your-role-arn por el ARN del rol anotado en el paso anterior. Utilice
s3Import para el valor de la opción --feature-name.
Example
aws rds add-role-to-db-cluster \

--feature-name s3Import \
--role-arn your-role-arn \
--region us-west-2
Para Windows:
aws rds add-role-to-db-cluster ^

--feature-name s3Import ^
--role-arn your-role-arn ^
--region us-west-2
Utilización de credenciales de seguridad para acceder a un

archivo de Amazon S3
Permita el acceso a un archivo de Amazon S3 proporcionando un rol de IAM o un parámetro
credentials en la llamada de función aws_s3.table_import_from_s3 (p. 792).
El parámetro credentials es una estructura de tipo aws_commons._aws_credentials_1, que

contiene credenciales de AWS. Utilice la función aws_commons.create_aws_credentials (p. 794)
para establecer la clave de acceso y la clave secreta en una estructura
aws_commons._aws_credentials_1, como se muestra a continuación.

789
psql=> SELECT aws_commons.create_aws_credentials(

'<sample_access_key>', '<sample_secret_key>', '')
AS creds \gset
Tras crear la estructura aws_commons._aws_credentials_1 , utilice la función

aws_s3.table_import_from_s3 (p. 792) para importar los datos, como se muestra a continuación.

't', '', '(format csv)',
:'s3_uri',
:'creds'
);
O bien puede incluir la llamada a la función aws_commons.create_aws_credentials (p. 794) insertada

dentro de la llamada a la función aws_s3.table_import_from_s3.

't', '', '(format csv)',
:'s3_uri',
aws_commons.create_aws_credentials('<sample_access_key>', '<sample_secret_key>', '')
);
Gestión de formatos de archivo de Amazon S3

Los siguientes ejemplos muestran cómo especificar diferentes tipos de archivos al importar.
Temas
• Importación de un archivo de Amazon S3 que utiliza un delimitador personalizado (p. 790)
• Importación de un archivo comprimido (gzip) de Amazon S3 (p. 791)
• Importación de un archivo de Amazon S3 codificado (p. 791)
Note
Los siguientes ejemplos utilizan el método de rol IAM para proporcionar acceso al archivo
de Amazon S3. Por lo tanto, no hay parámetros de credenciales en las llamadas a la función
aws_s3.table_import_from_s3.
Importación de un archivo de Amazon S3 que utiliza un delimitador personalizado

El siguiente ejemplo muestra cómo importar un archivo que utiliza un delimitador de cliente. También
muestra cómo controlar dónde colocar los datos en la tabla de la base de datos usando el parámetro
column_list de la función aws_s3.table_import_from_s3 (p. 792).
En este ejemplo, supongamos que la siguiente información está organizada en columnas delimitadas por
barras verticales en el archivo de Amazon S3.
1|foo1|bar1|elephant1
...
Para importar un archivo que utiliza un delimitador de cliente
1. Cree una tabla en la base de datos para los datos importados.

790
psql=> CREATE TABLE test (a text, b text, c text, d text, e text);

CREATE TABLE
2. Utilice el siguiente formulario de la función aws_s3.table_import_from_s3 (p. 792) para importar datos
desde el archivo de Amazon S3.
Puede incluir la llamada a la función aws_commons.create_s3_uri (p. 794) insertada dentro de la

llamada a la función aws_s3.table_import_from_s3 para especificar el archivo.

'test',
'a,b,d,e',
'DELIMITER ''|''',
aws_commons.create_s3_uri('sampleBucket', 'pipeDelimitedSampleFile', 'us-east-2')
);
Los datos se encuentran ahora en la tabla en las siguientes columnas.
psql=> SELECT * FROM test;

a | b | c | d | e
---+------+---+---+------+-----------
1 | foo1 | | bar1 | elephant1
Importación de un archivo comprimido (gzip) de Amazon S3

El siguiente ejemplo muestra cómo importar un archivo comprimido con gzip desde Amazon S3.
Asegúrese de que el archivo contenga los siguientes metadatos de Amazon S3:
• Clave: Content-Encoding
• Valor: gzip
Para obtener más información sobre la adición de estos valores a los metadatos de Amazon S3, consulte
¿Cómo puedo añadir metadatos a un objeto de S3? en la Guía del usuario de la consola de Amazon
Simple Storage Service.
Importe el archivo gzip en su clúster de base de datos Aurora PostgreSQL como se muestra a
continuación.
psql=> CREATE TABLE test_gzip(id int, a text, b text, c text, d text);

CREATE TABLE
'test_gzip', '', '(format csv)',
'myS3Bucket', 'test-data.gz', 'us-east-2'
);
Importación de un archivo de Amazon S3 codificado

El siguiente ejemplo muestra cómo importar un archivo desde Amazon S3 que tenga codificación
Windows-1252.

'test_table', '', 'encoding ''WIN1252''',

791
aws_commons.create_s3_uri('sampleBucket', 'SampleFile', 'us-east-2')

);
Referencia de funciones
Funciones
• aws_s3.table_import_from_s3 (p. 792)
• aws_commons.create_s3_uri (p. 794)
• aws_commons.create_aws_credentials (p. 794)
aws_s3.table_import_from_s3
Importa datos de Amazon S3 en una tabla Aurora PostgreSQL. La extensión aws_s3 proporciona la
función aws_s3.table_import_from_s3.
Los tres parámetros obligatorios son table_name, column_list y options. Estos identifican la tabla de
la base de datos y especifican cómo se copian los datos en la tabla.
También puede utilizar estos parámetros:
• El parámetro s3_info especifica el archivo Amazon S3 que se va a importar. Cuando utilice este
parámetro, se proporciona acceso a Amazon S3 mediante un rol de IAM para el clúster de base de datos
de PostgreSQL.
aws_s3.table_import_from_s3 (
table_name text,
column_list text,
options text,
s3_info aws_commons._s3_uri_1
)
• El parámetro credentials especifica las credenciales para acceder a Amazon S3. Cuando utilice este
parámetro, no utilice un rol de IAM.
table_name text,
column_list text,
options text,
s3_info aws_commons._s3_uri_1,
credentials aws_commons._aws_credentials_1
)
Los parámetros aws_s3.table_import_from_s3 se describen en la siguiente tabla:
Parámetro Descripción
table_name Cadena de texto obligatoria que contiene el nombre de la tabla de la base de datos de
PostgreSQL a la que importar los datos.
column_listCadena de texto obligatoria que contiene una lista opcional de las columnas de la tabla de
la base de datos de PostgreSQL en la que se copiarán los datos. Si la cadena está vacía,
se utilizan todas las columnas de la tabla. Para ver un ejemplo, consulte Importación de
un archivo de Amazon S3 que utiliza un delimitador personalizado (p. 790).
options Cadena de texto obligatoria que contiene argumentos para el comando COPY de
PostgreSQL. Estos argumentos especifican cómo se copian los datos en la tabla

792
PostgreSQL. Para obtener más detalles, consulte la documentación de COPY de
PostgreSQL.
s3_info Tipo compuesto aws_commons._s3_uri_1 que contiene la siguiente información sobre

el objeto de S3:
• bucket: el nombre de bucket de Amazon S3 que contiene el archivo.

• file_path: la ruta de Amazon S3 del archivo.
• region: la región de AWS en la que se encuentra el archivo.
Para crear una estructura compuesta aws_commons._s3_uri_1, consulte

aws_commons.create_s3_uri (p. 794).
credentialsTipo compuesto aws_commons._aws_credentials_1 que contiene las siguientes

credenciales para usar en la operación de importación:
• Clave de acceso
• Clave secreta
• Token de sesión
Para crear una estructura compuesta aws_commons._aws_credentials_1, consulte

aws_commons.create_aws_credentials (p. 794).
Parámetros alternativos
Como ayuda en las pruebas, puede utilizar un conjunto de parámetros expandido en lugar de los
parámetros s3_info y credentials. A continuación, se incluyen variaciones de sintaxis adicionales
para la función aws_s3.table_import_from_s3.
• En lugar de utilizar el parámetro s3_info para identificar un archivo de Amazon S3, utilice la
combinación de los parámetros bucket, file_path y region. Con esta forma de la función, se facilita
acceso a Amazon S3 mediante un rol de IAM en la instancia de base de datos de PostgreSQL.
table_name text,
column_list text,
options text,
bucket text,
file_path text,
region text
)
• En lugar de utilizar el parámetro credentials para especificar el acceso a Amazon S3, utilice la
combinación de parámetros access_key, session_key y session_token.
table_name text,
column_list text,
options text,
bucket text,
file_path text,
region text,
access_key text,
secret_key text,
session_token text

793
Busque las descripciones de estos parámetros alternativos en la siguiente tabla.
bucket Cadena de texto que incluye el nombre del bucket de Amazon S3 que contiene el archivo.
file_path Cadena de texto que contiene la ruta de Amazon S3 del archivo.
region Cadena de texto que contiene la región de AWS en la que se encuentra el archivo.
access_key Cadena de texto que contiene la clave de acceso que se va a utilizar para la operación de
importación. El valor predeterminado es NULL.
secret_key Cadena de texto que contiene la clave secreta que se va a usar para la operación de
importación. El valor predeterminado es NULL.
(Opcional) Cadena de texto que contiene la clave de la sesión que se va a utilizar para la
session_token
operación de importación. El valor predeterminado es NULL.
aws_commons.create_s3_uri
Crea una estructura aws_commons._s3_uri_1 para contener la información de archivos de Amazon S3.
Debe utilizar los resultados de la función aws_commons.create_s3_uri en el parámetro s3_info de la
función aws_s3.table_import_from_s3 (p. 792). La sintaxis de la función es la siguiente:
aws_commons.create_s3_uri(
bucket text,
file_path text,
region text
)
Los parámetros de la función aws_commons.create_s3_uri se describen en la siguiente tabla.
bucket Cadena de texto obligatoria que contiene el nombre del bucket de Amazon S3 del
archivo.
file_path Cadena de texto obligatoria que contiene la ruta de Amazon S3 del archivo.
region Cadena de texto obligatoria que contiene la región de AWS en la que se encuentra el
archivo.
aws_commons.create_aws_credentials
Establece una clave de acceso y una clave secreta en una estructura
aws_commons._aws_credentials_1. Utilice los resultados de la función
aws_commons.create_aws_credentials en el parámetro credentials de la función
aws_s3.table_import_from_s3 (p. 792). La sintaxis de la función es la siguiente:
aws_commons.create_aws_credentials(
access_key text,
secret_key text,

794
Administración de Aurora PostgreSQL
session_token text
)
Los parámetros de la función aws_commons.create_aws_credentials se describen en la siguiente

tabla.
access_key Cadena de texto obligatoria que contiene la clave de acceso que se va a utilizar para
importar un archivo de Amazon S3. El valor predeterminado es NULL.
secret_key Cadena de texto obligatoria que contiene la clave secreta que se va a utilizar para
importar un archivo de Amazon S3. El valor predeterminado es NULL.
session_tokenCadena de texto opcional que contiene el token de la sesión que se va a utilizar para
importar un archivo de Amazon S3. El valor predeterminado es NULL. Tenga en cuenta
que si facilita un session_token opcional, puede usar credenciales temporales.
Administración de Amazon Aurora PostgreSQL

En las siguientes secciones se analiza la administración del desempeño y el escalado de un clúster de
base de datos de Amazon Aurora PostgreSQL.
Temas
• Escalado de las instancias de base de datos Aurora PostgreSQL (p. 795)
• Número máximo de conexiones a una instancia de base de datos Aurora PostgreSQL (p. 795)
Escalado de las instancias de base de datos Aurora

PostgreSQL
Puede escalar las instancias de base de datos Aurora PostgreSQL de dos formas, mediante el escalado de
instancia y mediante el escalado de lectura. Para obtener más información acerca del escalado de lectura,
consulte Escalado de lectura (p. 258).
Puede escalar el clúster de base de datos Aurora PostgreSQL como considere necesario modificando la
clase de instancia de base de datos para cada instancia de base de datos del clúster de base de datos.
Aurora PostgreSQL admite varias clases de instancia de base de datos optimizadas para Aurora. Para
obtener especificaciones detalladas de las clases de instancia de base de datos admitidas por Aurora
PostgreSQL, consulte Especificaciones de hardware para todas las clases de instancia de base de datos
disponibles para Aurora (p. 62).
Número máximo de conexiones a una instancia de

base de datos Aurora PostgreSQL
El número máximo de conexiones permitidas a una instancia de base de datos Aurora PostgreSQL viene
determinado por el parámetro max_connections del grupo de parámetros de nivel de instancia para la
instancia de base de datos. De forma predeterminada, este valor se establece en la ecuación siguiente:
LEAST({DBInstanceClassMemory/9531392},5000).
Al establecer el parámetro max_connections en esta ecuación, se garantiza que el número de

conexiones permitidas se escala correctamente con el tamaño de la instancia. Por ejemplo, suponga que

795
Replicación con Aurora PostgreSQL
la clase de instancia de base de datos es db.r4.large y que tiene 15,25 gibibytes (GiB) de memoria. En este
caso, el número máximo de conexiones permitidas es 1 660, como se muestra en la siguiente ecuación:
LEAST( (15.25 * 1000000000) / 9531392 ), 5000) = 1600
En la siguiente tabla se indica el valor resultante predeterminado de max_connections para cada clase
de instancia de base de datos disponible para Aurora PostgreSQL. Puede aumentar el número máximo
de conexiones de su instancia de base de datos Aurora PostgreSQL escalando la instancia hasta una
clase de instancia de base de datos con más memoria o definiendo un valor más grande para el parámetro
max_connections, hasta un máximo de 262 143.
Clase de Valor predeterminado de max_connections

instancia
db.r4.large 1600
db.r4.xlarge 3200
db.r4.2xlarge 5000
db.r4.4xlarge 5000
db.r4.8xlarge 5000
db.r4.16xlarge 5000
db.r5.large 1600
db.r5.xlarge 3300
db.r5.2xlarge 5000
db.r5.4xlarge 5000
db.r5.12xlarge 5000
db.r5.24xlarge 5000
Replicación con Amazon Aurora PostgreSQL

A continuación se describe la replicación con Amazon Aurora PostgreSQL, incluido cómo monitorizar la
replicación.
Temas
• Uso de réplicas de Aurora (p. 796)
• Monitorización de la replicación de Aurora PostgreSQL (p. 797)
• Uso de la replicación lógica de PostgreSQL con Aurora (p. 797)
Uso de réplicas de Aurora

disponibilidad que abarca un clúster de base de datos dentro de una región de AWS. El volumen del
clúster de base de datos consta de varias copias de los datos del clúster de base de datos. No obstante,

796
Monitorización de la replicación
los datos del volumen del clúster se representan como un único volumen lógico para la instancia de base
de datos de escritor principal y para las réplicas de Aurora del clúster de base de datos. Para obtener más
información acerca de las réplicas de Aurora, consulte Réplicas de Aurora (p. 48).
las operaciones de lectura en el volumen del clúster. La instancia de base de datos de escritor administra
operaciones de escritura. El volumen del clúster se comparte entre todas las instancias en su clúster de
base de datos Aurora PostgreSQL. Por lo tanto, no es necesaria ninguna tarea adicional para replicar
una copia de los datos para cada réplica de Aurora. En cambio, las réplicas de lectura de PostgreSQL
deben aplicar, en un solo subproceso, todas las operaciones de escritura de la instancia de base de datos
maestra a su almacén de datos local. Esta limitación puede afectar a la capacidad de las réplicas de
lectura de PostgreSQL de admitir grandes volúmenes de tráfico de escritura.
Note
Al reiniciar la instancia de base de datos de escritor de un clúster de base de datos de Amazon

Aurora, también se reinician automáticamente las réplicas de Aurora de dicho clúster. El reinicio
automático restablece un punto de entrada que garantiza la coherencia de lectura/escritura en
todo el clúster de base de datos.
Monitorización de la replicación de Aurora PostgreSQL

El escalado de lectura y la alta disponibilidad dependen de un tiempo de retardo mínimo. Puede
monitorizar el retardo de una réplica de Aurora con respecto a la instancia de base de datos de escritor
del clúster de base de datos Aurora PostgreSQL mediante la monitorización de la métrica ReplicaLag
de Amazon CloudWatch. Como las réplicas de Aurora leen desde el mismo volumen de clúster que la
instancia de base de datos de escritor, la métrica ReplicaLag tiene un significado diferente para un
clúster de base de datos Aurora PostgreSQL. La métrica ReplicaLag de una réplica de Aurora indica el
retardo de la caché de página de la réplica de Aurora con respecto a la de la instancia de base de datos de
escritor.
Para obtener más información acerca de la monitorización de instancias de RDS y de las métricas de
CloudWatch, consulte Monitorización de un clúster de base de datos de Amazon Aurora (p. 363).
Uso de la replicación lógica de PostgreSQL con

Aurora
La replicación lógica de PostgreSQL proporciona un control detallado sobre la replicación y sincronización
de las partes de una base de datos. Por ejemplo, puede usar la replicación lógica para replicar una tabla
individual de una base de datos.
A continuación encontrará información acerca de cómo trabajar con la replicación lógica de PostgreSQL
y Amazon Aurora. Para obtener información más detallada acerca de la implementación de PostgreSQL
en la replicación lógica, consulte la sección sobre replicación lógica y la sección sobre conceptos de
descodificación lógica.
Note
La replicación lógica está disponible con la versión 2.2.0 de Aurora PostgreSQL (compatible con
PostgreSQL 10.6) y posteriores.
A continuación encontrará información acerca de cómo trabajar con la replicación lógica de PostgreSQL y
Amazon Aurora.
Temas
• Configuración de la replicación lógica (p. 798)
• Ejemplo de replicación lógica de una tabla de base de datos (p. 799)

797
Uso de la replicación lógica
• Replicación lógica mediante el AWS Database Migration Service (p. 800)
Configuración de la replicación lógica

Para usar la replicación lógica, primero debe establecer el parámetro rds.logical_replication para
un grupo de parámetros del clúster. A continuación, debe configurar las bases de datos de publicador y de
suscriptor.
La replicación lógica usa un modelo de publicación y suscripción. Los publicadores y los suscriptores son
los nodos. La publicación se define en un publicador y corresponde a un conjunto de cambios generados
desde una o varias tablas de base de datos. La suscripción define la conexión a otra base de datos y una
o varias publicaciones a las que se suscribe. La suscripción se define en un suscriptor. La publicación y la
suscripción realizan la conexión entre las bases de datos de publicador y de suscriptor.
Note
A fin de realizar la replicación lógica para una base de datos PostgreSQL, su cuenta de usuario de
AWS necesita el rol rds_superuser.
Para habilitar la replicación lógica de PostgreSQL con Aurora
1. Cree un nuevo grupo de parámetros de clúster de base de datos a fin de usarlo para la replicación
lógica, tal como se describe en Creación de un grupo de parámetros de clúster de base de
datos (p. 264). Utilice los siguientes valores:
• En Parameter group family (Familia de grupo de parámetros), elija aurora-postgres10 o posterior.

• En Type (Tipo), elija DB Cluster Parameter Group (Grupo de parámetros de clúster de base de
datos).
2. Modifique el grupo de parámetros de clúster, tal como se describe en Modificación de parámetros
de un grupo de parámetros de clúster de base de datos (p. 269). Establezca el parámetro estático
rds.logical_replication en 1.
Habilitar el parámetro rds.logical_replication afecta al rendimiento del clúster de base de

datos.
Para configurar un publicador para la replicación lógica
1. Establezca el grupo de parámetros del clúster de publicador:
• Para usar un clúster de base de datos Aurora PostgreSQL para el publicador, la versión del motor
debe ser la 10.6 o posterior. Haga lo siguiente:
1. Modifique el grupo de parámetros de clúster para establecerlo en el grupo que ha creado tras
habilitar la replicación lógica. Para obtener detalles acerca cómo modificar un clúster de base
de datos de Aurora PostgreSQL, consulte Modificación de un clúster de base de datos Amazon
Aurora (p. 235).
2. Reinicie el clúster de base de datos para que se apliquen los cambios en los parámetros
estáticos. El grupo de parámetros del clúster incluye un cambio en el parámetro estático
rds.logical_replication.
• Para usar un nuevo clúster de base de datos Aurora PostgreSQL para el publicador, cree dicho
clúster con los siguientes valores. Para obtener detalles acerca de cómo crear un clúster de base de
datos Aurora PostgreSQL, consulte Creación de un clúster de base de datos (p. 87).
1. Elija el motor de Amazon Aurora y elija la edición PostgreSQL-compatible.
2. En DB engine version (Versión del motor de base de datos), elija un motor de Aurora PostgreSQL
que sea compatible con PostgreSQL 10.6 o posterior.
3. En DB cluster parameter group (Grupo de parámetros del clúster de base de datos), elija el grupo
que ha creado tras habilitar la replicación lógica.

798
2. Modifique las reglas de entrada del grupo de seguridad para que el publicador permita al suscriptor
conectarse. Normalmente, esto se hace incluyendo la dirección IP del suscriptor en el grupo de
seguridad. Para obtener detalles acerca de cómo modificar un grupo de seguridad, consulte Grupos
de seguridad de su VPC en la Guía del usuario de Amazon Virtual Private Cloud.
Ejemplo de replicación lógica de una tabla de base de datos

Para implementar la replicación lógica, use los comandos de PostgreSQL CREATE PUBLICATION y
CREATE SUBSCRIPTION.
En este ejemplo, los datos de la tabla se replican desde una base de datos Aurora PostgreSQL como
publicador en una base de datos de RDS for PostgreSQL como suscriptor. Una vez configurado el
mecanismo de replicación lógica, los cambios en el publicador se envían ininterrumpidamente al suscriptor
a medida que se producen.
Para configurar la replicación lógica de este ejemplo, haga lo siguiente:
1. Configure un clúster de base de datos Aurora PostgreSQL como publicador. Para hacerlo, cree un
nuevo clúster de base de datos Aurora PostgreSQL, tal como se describe al configurar el publicador en
Configuración de la replicación lógica (p. 798).
2. Configure la base de datos de publicador. Cree una tabla mediante la siguiente instrucción SQL en la
base de datos de publicador.
CREATE TABLE LogicalReplicationTest (a int PRIMARY KEY);
3. Inserte datos en la base de datos de publicador mediante la siguiente instrucción SQL.
INSERT INTO LogicalReplicationTest VALUES (generate_series(1,10000));
4. Cree una publicación en el publicador mediante la siguiente instrucción SQL.
CREATE PUBLICATION testpub FOR TABLE LogicalReplicationTest;
5. Cree una base de datos para que sea su suscriptora.
En este ejemplo, cree una base de datos de Amazon RDS for PostgreSQL. Asegúrese de usar la
versión 10.4 o una versión posterior del motor de base de datos PostgreSQL, que admite la replicación
lógica. Para obtener detalles acerca de la creación de una instancia de base de datos PostgreSQL
de RDS, consulte Creación de una instancia de base de datos que ejecuta el motor de base de datos
PostgreSQL en la Guía del usuario de Amazon RDS.
6. Configure la base de datos de suscriptor. En este ejemplo, cree una tabla como la creada para el
publicador mediante la siguiente instrucción SQL.
CREATE TABLE LogicalReplicationTest (a int PRIMARY KEY);
7. Compruebe que hay datos en la tabla del publicador, pero ninguno todavía en el suscriptor utilizando la
siguiente instrucción SQL en ambas bases de datos.
SELECT count(*) FROM LogicalReplicationTest;
8. Cree una suscripción en el suscriptor. Use la siguiente instrucción SQL en la base de datos de
suscriptor y los siguientes valores para obtener información del clúster de publicador:
• host: la instancia de base de datos de escritor del clúster de publicador.
• puerto: el puerto en el que la instancia de base de datos de escritor está a la escucha. El valor
predeterminado de PostgreSQL es 5432.

799
• dbname: el nombre de base de datos del clúster de publicador.
CREATE SUBSCRIPTION testsub CONNECTION

'host=publisher-cluster-writer-endpoint port=5432 dbname=db-name user=user
password=password'
PUBLICATION testpub;
Una vez creada la suscripción, se crea una ranura de replicación lógica en el publicador.
9. Para comprobar en este ejemplo que se replican los datos iniciales en el suscriptor, use la siguiente
instrucción SQL en la base de datos de suscriptor.
SELECT count(*) FROM LogicalReplicationTest;
Todo cambio adicional en el publicador se replicará en el suscriptor.
Replicación lógica mediante el AWS Database Migration Service

Puede usar el AWS Database Migration Service (AWS DMS) para replicar una base de datos o parte de
una base de datos. Use AWS DMS para migrar sus datos de una base de datos Aurora PostgreSQL a otra
base de datos comercial o de código abierto. Para obtener más información acerca de AWS DMS, consulte
la Guía del usuario de AWS Database Migration Service.
En el siguiente ejemplo se muestra cómo configurar la replicación lógica desde una base de datos Aurora
PostgreSQL como publicador y, a continuación, usar AWS DMS para la migración. En este ejemplo, migra
los datos de una tabla de base de datos a una base de datos PostgreSQL de RDS como suscriptor. El
publicador y suscriptor usados en este ejemplo son los mismos que los creados en Ejemplo de replicación
lógica de una tabla de base de datos (p. 799).
Para configurar la replicación lógica con AWS DMS, necesita detalles acerca de su publicador y suscriptor
de Amazon RDS. Concretamente, necesita detalles acerca de la instancia de base de datos de escritor del
publicador y la instancia de base de datos de suscriptor.
Obtenga la siguiente información para la instancia de base de datos de escritor del publicador:
• Identificador de la nube virtual privada (VPC)

• Grupo de subredes
• Zona de disponibilidad (AZ)
• Grupo de seguridad de VPC
• ID de instancia de base de datos
Obtenga la siguiente información para la instancia de base de datos de suscriptor:
• ID de instancia de base de datos

• Motor de origen
Para usar AWS DMS para la replicación lógica con Aurora PostgreSQL
1. Prepare la base de datos de publicador para trabajar con AWS DMS.
Para ello, tanto PostgreSQL 10.x como bases de datos posteriores requieren que aplique funciones
contenedoras de AWS DMS a la base de datos de publicador. Para obtener detalles acerca de este
paso y pasos posteriores, consulte las instrucciones en Uso de PostgreSQL versión 10.x y posterior
como origen para AWS DMS en la Guía del usuario de AWS Database Migration Service.

800
2. Inicie sesión en la Consola de administración de AWS y abra la consola de AWS DMS en https://
console.aws.amazon.com/dms. En la parte superior derecha, elija la misma región de AWS en la que
se encuentran el publicador y el suscriptor.
3. Cree una instancia de replicación de AWS DMS.
Elija valores que sean los mismos que para la instancia de base de datos de escritor de su publicador.
Entre estos se incluyen los siguientes:
• En VPC, elija la misma VPC que para la instancia de base de datos de escritor.
• En el Replication Subnet Group (Grupo de subredes de replicación), elija el mismo grupo de
subredes que para la instancia de base de datos de escritor.
• En la Availability zone (Zona de disponibilidad), elija la misma zona que para la instancia de base de
datos de escritor.
• En el VPC Security Group (Grupo de seguridad de VPC), elija el mismo grupo que para la instancia
de base de datos de escritor.
4. Cree un punto de enlace de AWS DMS para el origen. Especifique el publicador como punto de enlace
de origen mediante los siguientes valores:
• En Endpoint type (Tipo de punto de enlace), elija Source endpoint (Punto de enlace de origen).
• Elija Select RDS DB Instance (Seleccionar instancia de base de datos de RDS).
• En RDS Instance (Instancia RDS), elija el identificador de base de datos de la instancia de base de
datos de escritor del publicador.
• En Source engine (Motor de origen), elija postgres.
5. Cree un punto de enlace de AWS DMS para el destino. Especifique el suscriptor como punto de
enlace de destino mediante los siguientes valores:
• En Endpoint type (Tipo de punto de enlace), elija Target endpoint (Punto de enlace de destino).
• Elija Select RDS DB Instance (Seleccionar instancia de base de datos de RDS).
• En RDS Instance (Instancia RDS), elija el identificador de base de datos de la instancia de base de
datos de suscriptor.
• Elija un valor para Source engine (Motor de origen). Por ejemplo, si el suscriptor es una base de
datos PostgreSQL de RDS, elija postgres.
6. Cree una tarea de migración de bases de datos de AWS DMS.
Debe usar una tarea de migración de bases de datos para especificar qué tablas de base de datos se
van a migrar, asignar los datos mediante un esquema de destino y crear tablas nuevas en la base de
datos de destino. Como mínimo, use los siguientes valores para Task configuration (Configuración de
tareas):
• En Replication instance (Instancia de replicación), elija la instancia de replicación que creó en un

paso anterior.
• En Source database endpoint (Punto de enlace de base de datos de origen), elija el origen del
publicador que creó en un paso anterior.
• En Target database endpoint (Punto de enlace de base de datos de destino), elija el destino del
suscriptor que creó en un paso anterior.
El resto de los detalles de la tarea dependen de su proyecto de migración. Para obtener más
información acerca de la especificación de todos los detalles de las tareas de DMS, consulte Working
with AWS DMS Tasks (Trabajo con las tareas de AWS DMS) en la Guía del usuario de AWS Database
Migration Service.
Una vez creada la tarea, AWS DMS comienza a migrar datos del publicador al suscriptor.
801
Integración de Aurora PostgreSQL con los servicios de AWS
Integración de Amazon Aurora PostgreSQL con

otros servicios de AWS
Amazon Aurora se integra con otros servicios de AWS con el fin de permitirle ampliar su clúster de base de
datos Aurora PostgreSQL para usar funcionalidades adicionales en la nube de AWS. El clúster de base de
datos de Aurora PostgreSQL puede usar los servicios de AWS para hacer lo siguiente:
• Recopilar, ver y evaluar rápidamente el rendimiento de las instancias de base de datos Aurora
PostgreSQL con Performance Insights de Amazon RDS. Performance Insights amplía las características
de monitorización existentes de Amazon RDS para ilustrar el desempeño de la base de datos y le ayuda
a analizar cualquier problema que le afecte. Con el panel de Performance Insights, puede visualizar la
carga de la base de datos y filtrarla por esperas, instrucciones SQL, hosts o usuarios.
Para obtener más información acerca de Performance Insights, consulte Uso de Performance Insights de
• Añada o quite de forma automática réplicas de Aurora con Aurora Auto Scaling. Para obtener más
información, consulte Uso de Auto Scaling de Amazon Aurora con réplicas de Aurora (p. 297).
Temas relacionados
Administración de planes de ejecución de consultas

para Aurora PostgreSQL
Con la administración de planes de consultas para Compatibilidad de Amazon Aurora con PostgreSQL,
puede controlar cuándo y cómo cambian los planes de ejecución de consultas. La administración de
planes de consultas tiene dos objetivos principales:
• Evitar la regresión de los planes cuando cambia el sistema de la base de datos

• Controlar cuándo puede usar nuevos planes el optimizador de consultas
La calidad y coherencia de la optimización de consultas tienen un impacto importante en el rendimiento y

la estabilidad de cualquier sistema de administración de bases de datos relacionales (RDBMS). A través
de los optimizadores de consultas se crea un plan de ejecución de consultas para una instrucción SQL
en un momento específico. A medida que las condiciones se modifiquen, el optimizador podría elegir un
plan diferente que afectase el rendimiento de manera negativa. Una serie de cambios puede provocar
que el optimizador de consultas elija un plan distinto y se produzca una regresión del rendimiento. Entre
estos cambios se incluyen los cambios en estadísticas, restricciones, configuración del entorno, enlaces de
parámetros de consultas y actualizaciones de software. La regresión es un problema importante para las
aplicaciones de alto rendimiento.
Mediante la administración de planes de consultas, es posible controlar los planes de ejecución para un
conjunto de instrucciones que desee gestionar. Puede hacer lo siguiente:
• Obligar al optimizador a elegir a partir de un número limitado de planes buenos y conocidos para mejorar
la estabilidad de los planes.
• Optimizar los planes de manera centralizada y, a continuación, distribuir los mejores planes globalmente.
• Identificar índices fuera de uso y evaluar el impacto de crear o anular un índice.

802
Habilitar la administración de planes de consultas
• Detectar automáticamente un nuevo plan de costo mínimo que el optimizador haya descubierto.
• Probar características de optimizador nuevas con un menor nivel de riesgo, porque puede optar por
aprobar únicamente las modificaciones de planes que mejoren el rendimiento.
Temas
• Habilitar la administración de planes de consultas para Aurora PostgreSQL (p. 803)
• Habilitación de la administración de planes de consultas (p. 804)
• Aspectos básicos de la administración de planes de consultas (p. 804)
• Prácticas recomendadas para la administración de planes de consultas (p. 807)
• Examinar planes en la vista apg_plan_mgmt.dba_plans (p. 808)
• Capturar planes de ejecución (p. 811)
• Uso de planes administrados (p. 814)
• Mantenimiento de planes de ejecución (p. 817)
• Referencia de parámetros para la administración de planes de consultas (p. 822)
• Referencia de funciones para la administración de planes de consultas (p. 826)
Habilitar la administración de planes de consultas para

Aurora PostgreSQL
La administración de planes de consultas está disponible en Amazon Aurora PostgreSQL, versión 2.1.0 y
posteriores.
Para habilitar la administración de planes de consultas

2. Cree un nuevo grupo de parámetros en el nivel de la instancia para usarlo en la administración de
planes de consultas. Para obtener más información, consulte Creación de un grupo de parámetros de
3. Cree un nuevo grupo de parámetros en el nivel del clúster para usarlo en la administración de planes
de consultas. Para obtener más información, consulte Creación de un grupo de parámetros de clúster
de base de datos (p. 264).
4. Abra el grupo de parámetros en el nivel del clúster y establezca el parámetro
rds.enable_plan_management en 1. Para obtener más información, consulte Modificación de
parámetros de un grupo de parámetros de clúster de base de datos (p. 269).
5. Reinicie la instancia de base de datos para habilitar esta nueva configuración.
6. Conéctese a una instancia de base de datos con un cliente como psql.
7. Cree la extensión apg_plan_mgmt para su instancia de base de datos. A continuación se muestra un
ejemplo.
psql my-database
my-database=> CREATE EXTENSION apg_plan_mgmt;
Si crea la extensión apg_plan_mgmt en la base de datos predeterminada template1, la extensión

de administración del plan de consultas estará disponible en cada nueva base de datos que cree.
Note
Para crear la extensión apg_plan_mgmt, necesita el rol rds_superuser. Al crear la

extensión apg_plan_mgmt, se crea el rol apg_plan_mgmt. Se debe conceder a los
usuarios el rol apg_plan_mgmt para administrar la extensión apg_plan_mgmt.

803
Habilitación de la administración de planes de consultas
Habilitación de la administración de planes de

consultas
Si ha instalado la versión de administración de planes de consulta 1.0, recomendamos fehacientemente
que actualice a la versión 1.0.1.
Para actualizar, ejecute los siguientes comandos en el nivel de instancia de la base de datos o el clúster.
ALTER EXTENSION apg_plan_mgmt UPDATE TO '1.0.1';

SELECT apg_plan_mgmt.validate_plans('update_plan_hash');
SELECT apg_plan_mgmt.reload();
Aspectos básicos de la administración de planes de

consultas
Puede administrar cualquier instrucción SELECT, INSERT, UPDATE, or DELETE con la administración
de planes de consulta, independientemente de lo compleja que sea la instrucción. Las instrucciones
SQL preparadas, dinámicas, integradas y de modo inmediato son compatibles. Se pueden usar todas las
características del lenguaje PostgreSQL, incluidas las tablas con particiones, la seguridad en el nivel de fila
y las expresiones de tabla comunes recursivas (CTE).
Note
En la actualidad, no puede capturar planes de instrucciones dentro de una función PL/pgSQL.
Temas
• Realización de una captura de plan manual (p. 804)
• Ver planes capturados (p. 805)
• Uso de las instrucciones administradas y el hash SQL (p. 805)
• Uso de la captura de planes automática (p. 806)
• Validación de planes (p. 806)
• Aprobación de nuevos planes que mejoran el rendimiento (p. 806)
• Eliminación de planes (p. 807)
Realización de una captura de plan manual

Para capturar planes para instrucciones específicas, utilice el modo de captura manual como en el
siguiente ejemplo.
/* Turn on manual capture */

SET apg_plan_mgmt.capture_plan_baselines = manual;
EXPLAIN SELECT COUNT(*) from pg_class; -- capture the plan baseline
SET apg_plan_mgmt.capture_plan_baselines = off; -- turn off capture
SET apg_plan_mgmt.use_plan_baselines = true; -- turn on plan usage
Puede ejecutar instrucciones SELECT, INSERT, UPDATE o DELETE, o puede incluir la instrucción
EXPLAIN como se muestra arriba. Utilice EXPLAIN para capturar un plan sin la sobrecarga o los efectos
secundarios potenciales de ejecutar la instrucción. Para obtener más información acerca de la captura
manual, consulte Captura manual de planes para instrucciones SQL específicas (p. 812).

804
Conceptos básicos
Ver planes capturados

Cuando se ejecuta EXPLAIN SELECT en el ejemplo anterior, el optimizador guarda el plan. Para
ello, inserta una fila en la vista apg_plan_mgmt.dba_plans y confirma el plan en una transacción
autónoma. Puede ver los contenidos de la vista apg_plan_mgmt.dba_plans si se le ha concedido el
rol apg_plan_mgmt. En la siguiente consulta se muestran algunas columnas importantes de la vista
dba_plans.
SELECT sql_hash, plan_hash, status, enabled, plan_outline, sql_text::varchar(40)

FROM apg_plan_mgmt.dba_plans
ORDER BY sql_text, plan_created;
Cada fila mostrada representa un plan administrado. En el ejemplo anterior se muestra la siguiente
información.
• sql_hash: ID de la instrucción administrada para la que es el plan.

• plan_hash: ID del plan administrado.
• status: estado del plan. El optimizador puede ejecutar un plan aprobado.
• enabled: valor que indica si el plan está habilitado para usar o deshabilitado y no se puede usar.
• plan_outline: detalles del plan administrado.
Para obtener más información sobre la vista de apg_plan_mgmt.dba_plans, consulte Examinar planes
en la vista apg_plan_mgmt.dba_plans (p. 808).
Uso de las instrucciones administradas y el hash SQL

Una instrucción administrada es una instrucción SQL capturada por el optimizador mediante la
administración del plan de consultas. Puede especificar qué instrucciones SQL se han de capturar como
instrucciones administradas mediante captura manual o automática:
• Para la captura manual, facilita las instrucciones específicas al optimizador, como se muestra en el
ejemplo anterior.
• Para la captura automática, el optimizador captura planes para instrucciones que se ejecutan varias
veces. La captura automática se muestra en un ejemplo posterior.
En la vista apg_plan_mgmt.dba_plans, puede identificar una instrucción administrada con un

valor hash SQL. El hash SQL se calcula sobre una representación normalizada de la instrucción SQL
que elimina algunas diferencias, como los valores literales. El uso de la normalización implica que,
cuando varias instrucciones SQL se diferencian únicamente en sus valores literales o de parámetro, se
representan mediante el mismo hash SQL en la vista apg_plan_mgmt.dba_plans. Por tanto, puede
haber varios planes para el mismo hash SQL y cada plan resultará óptimo según diferentes condiciones.
Cuando el optimizador procesa cualquier instrucción SQL, utiliza las siguientes reglas para crear la
instrucción SQL normalizada:
• Elimina cualquier comentario de bloque al principio

• Elimina la palabra clave EXPLAIN y las opciones EXPLAIN, si existen
• Elimina los espacios finales
• Elimina todos los literales
• Conserva los espacios en blanco y las mayúsculas para su legibilidad
Por ejemplo, vamos a tomar la siguiente instrucción.

805
Conceptos básicos
/*Leading comment*/ EXPLAIN SELECT /* Query 1 */ * FROM t WHERE x > 7 AND y = 1;
El optimizador normaliza esta instrucción de la siguiente forma.
SELECT /* Query 1 */ * FROM t WHERE x > CONST AND y = CONST;
Uso de la captura de planes automática

Utilice la captura de planes automática si quiere capturar planes para todas las instrucciones SQL de
su aplicación, o si no puede usar la captura manual. Con la captura de planes automática, de forma
predeterminada, el optimizador captura planes para instrucciones que se ejecuten al menos dos veces.
Siga estos pasos para utilizar la captura de planes automática.
1. Active la captura de planes automática configurando apg_plan_mgmt.capture_plan_baselines

como automatic en el grupo de parámetros para la instancia de la base de datos. Para obtener más
información, consulte Modificación de parámetros de un grupo de parámetros de base de datos (p. 265).
2. Reinicie la instancia de la base de datos.
A medida que se ejecuta la aplicación, el optimizador captura los planes para cualquier instrucción que
se ejecute más de una vez. El optimizador siempre establece el estado del primer plan capturado de
una instrucción administrada en approved. Un conjunto de planes aprobados para una instrucción
administrada se denomina base de referencia del plan.
A medida que la aplicación sigue ejecutándose, puede que el optimizador encuentre planes adicionales
para las instrucciones administradas. El optimizador establece el estado de los planes adicionales
capturados en unapproved.
El conjunto de todos los planes capturados para una instrucción administrada se denomina historial del
plan. Posteriormente, podrá decidir si los planes unapproved rinden apropiadamente y cambiarlos a
approved, rejected o preferred utilizando la función apg_plan_mgmt.evolve_plan_baselines
o la función apg_plan_mgmt.set_plan_status.
Para desactivar la captura de planes automática, establezca

apg_plan_mgmt.capture_plan_baselines en off en el grupo de parámetros para la instancia de la
base de datos. A continuación, reinicie la base de datos para que se aplique la configuración.
Para obtener más información acerca de la captura de planes, consulte Capturar planes de
ejecución (p. 811).
Validación de planes
Los planes administrados pueden volverse no válidos ("obsoletos") cuando se eliminan los objetos de los
que dependen, como un índice. Para encontrar y eliminar todos los planes obsoletos, utilice la función
apg_plan_mgmt.validate_plans.
SELECT apg_plan_mgmt.validate_plans('delete');
Para obtener más información, consulte Validación de planes (p. 818).
Aprobación de nuevos planes que mejoran el rendimiento

Al utilizar sus planes administrados, puede comprobar si planes más nuevos y de menor costo que haya
descubierto el optimizador resultan más rápidos que el plan de costo mínimo que ya existe en la base de

806
Prácticas recomendadas para la
administración de planes de consultas
referencia del plan. Para realizar la comparación de rendimiento y aprobar opcionalmente los planes más
rápidos, llame a la función apg_plan_mgmt.evolve_plan_baselines.
El siguiente ejemplo aprueba automáticamente cualquier plan sin aprobar que esté habilitado y resulte al
menos un 10 por ciento más rápido que el plan de costo mínimo de la referencia de planes.
SELECT apg_plan_mgmt.evolve_plan_baselines(
sql_hash,
plan_hash,
1.1,
'approve'
)
WHERE status = 'Unapproved' AND enabled = true;
Cuando se ejecuta la función apg_plan_mgmt.evolve_plan_baselines, recopila estadísticas

de rendimiento y las guarda en la vista apg_plan_mgmt.dba_plans en las columnas
planning_time_ms, execution_time_ms, cardinality_error, total_time_benefit_ms y
execution_time_benefit_ms. La función apg_plan_mgmt.evolve_plan_baselines también
actualiza las columnas last_verified o last_validated timestamps, en cuyo caso verá la hora
más reciente a la que se hayan recopilado las estadísticas de rendimiento.
SELECT sql_hash, plan_hash, status, last_verified, sql_text::varchar(40)

ORDER BY last_verified DESC; -- value updated by evolve_plan_baselines()
Para obtener más información sobre la verificación de planes, consulte Evaluación del rendimiento de los
planes (p. 817).
Eliminación de planes
El optimizador elimina planes automáticamente si no se han ejecutado o seleccionado como el
plan de costo mínimo para el periodo de retención de planes. El periodo de retención de planes
predeterminado es de 32 días. Para aplicar el periodo de retención de planes, establezca el parámetro
apg_plan_mgmt.plan_retention_period.
También puede revisar el contenido de la vista apg_plan_mgmt.dba_plans y eliminar los planes que
no quiera mediante la función apg_plan_mgmt.delete_plan. Para obtener más información, consulte
Eliminación de planes (p. 820).
Prácticas recomendadas para la administración de

planes de consultas
Plantéese la posibilidad de usar un estilo de administración de planes proactivo o reactivo. Estos estilos
de administración de planes se diferencian en el cuánto y el cómo se aprueban los nuevos planes para su
uso.
Administración de planes proactiva para evitar la regresión del

rendimiento
Con la administración de planes proactiva, aprueba manualmente nuevos planes después de haber
verificado que son más rápidos. Haga esto para evitar la regresión del rendimiento en el plan. Siga estos
pasos para una administración de planes proactiva:
1. En un entorno de desarrollo, identifique las instrucciones SQL que causen un mayor impacto en el
rendimiento del sistema. Después, capture los planes para estas instrucciones según se describen

807
Examinar planes en la vista dba_plans
en Captura manual de planes para instrucciones SQL específicas (p. 812) y Captura de planes
automática (p. 812).
2. Exporte los planes capturados desde el entorno de desarrollo e impórtelos al entorno de producción.
Para obtener más información, consulte Importación y exportación de planes (p. 821).
3. En producción, ejecute su aplicación y fuerce el uso de planes administrados aprobados. Para obtener
más información, consulte Uso de planes administrados (p. 814). Cuando se ejecute la aplicación,
añada nuevos planes también a medida que el optimizador los descubra. Para obtener más información,
consulte Captura de planes automática (p. 812).
4. Analice los planes no aprobados y apruebe los que muestren un buen rendimiento. Para obtener más
información, consulte Evaluación del rendimiento de los planes (p. 817).
5. Mientras la aplicación continúa ejecutándose, el optimizador empezará a utilizar los nuevos planes,
según resulte conveniente.
Administración de planes reactiva para detectar y reparar la

regresión del rendimiento
Con la administración de planes reactiva, puede monitorizar su aplicación a medida que se ejecuta para
detectar los planes que causan regresiones del rendimiento. Cuando detecte regresiones, puede rechazar
manualmente o reparar los planes defectuosos. Siga estos pasos para una administración de planes
reactiva:
1. Mientras se ejecute su aplicación, fuerce el uso de planes administrados y añada automáticamente los
planes recién descubiertos como no aprobados. Para obtener más información, consulte Uso de planes
administrados (p. 814) y Captura de planes automática (p. 812).
2. Monitorización de su aplicación en ejecución para detectar regresiones de rendimiento.
3. Cuando descubra una regresión del plan, configure el estado del plan en rejected. La próxima vez
que el optimizador ejecute la instrucción SQL, ignora automáticamente el plan rechazado y emplea un
plan aprobado diferente en su lugar. Para obtener más información, consulte Rechazar o deshabilitar
planes más lentos (p. 818).
En algunos casos, puede que prefiera reparar un plan defectuoso en lugar de rechazarlo, deshabilitarlo
o eliminarlo. Utilice la extensión pg_hint_plan para experimentar con la mejora de un plan. Con
pg_hint_plan, puede utilizar comentarios especiales para decirle al optimizador que anule cómo
crea un plan habitualmente. Para obtener más información, consulte Corrección de planes mediante
pg_hint_plan (p. 819).
Examinar planes en la vista

apg_plan_mgmt.dba_plans
La administración de planes de consultas ofrece una nueva vista SQL para que utilicen los administradores
de bases de datos (DBA), denominada apg_plan_mgmt.dba_plans. Cada base de datos de una
instancia de base de datos tiene su propia vista apg_plan_mgmt.dba_plans.
Esta vista contiene el historial de planes para todas las instrucciones administradas. Cada plan
administrado se identifica mediante una combinación de un valor hash SQL y un valor hash de plan. Con
estos identificadores, puede usar herramientas como Performance Insights de Amazon RDS para seguir el
rendimiento individual de los planes. Para obtener más información sobre Performance Insights, consulte
Uso de Performance Insights de Amazon RDS.
Note
El acceso a la vista apg_plan_mgmt.dba_plans está restringido a usuarios que tengan el rol

apg_plan_mgmt.

808
Consulta de planes administrados

Para consultar una lista de los planes administrados, utilice una instrucción SELECT en la vista
apg_plan_mgmt.dba_plans. El siguiente ejemplo muestra algunas columnas en la vista dba_plans,
como el status, que identifica los planes aprobados y no aprobados.
SELECT sql_hash, plan_hash, status, enabled, stmt_name

FROM apg_plan_mgmt.dba_plans;
sql_hash | plan_hash | status | enabled | stmt_name

------------+-----------+------------+---------+------------
1984047223 | 512153379 | approved | t | rangequery
1984047223 | 512284451 | unapproved | t | rangequery
(2 rows)
Referencia de la vista apg_plan_mgmt.dba_plans

Las columnas de la información del plan en la vista apg_plan_mgmt.dba_plans incluyen lo siguiente.
Columna dba_plans Descripción
cardinality_error Medición del error entre la cardinalidad estimada contra la cardinalidad

real. La cardinalidad es el número de filas de la tabla que procesará el
plan. Si el error de cardinalidad es grande, aumenta la probabilidad de
que el plan no resulte óptimo. Esta columna se rellena mediante la función
apg_plan_mgmt.evolve_plan_baselines (p. 826).
compatibility_levelEl nivel de características del optimizador de Aurora PostgreSQL.
created_by El usuario autenticado (session_user) que ha creado el plan.
enabled Un indicador de si el plan está habilitado o deshabilitado. Todos los planes

están habilitados de forma predeterminada. Puede deshabilitar los planes para
evitar que el optimizador los use. Para modificar este valor, use la función
apg_plan_mgmt.set_plan_enabled (p. 828).
Los parámetros y valores Grand Unified Configuration (GUC) de PostgreSQL

environment_variables
que ha anulado el optimizador en el momento de capturar el plan.
El costo de configuración del optimizador estimado antes de que entregue las

estimated_startup_cost
filas de una tabla.
El costo de configuración del optimizador estimado para entregar la última fila

estimated_total_cost
de una tabla.
El beneficio en tiempo de ejecución, en milisegundos, de

execution_time_benefit_ms
habilitar el plan. Esta columna se rellena mediante la función
execution_time_ms El tiempo estimado, en milisegundos, que se ejecutaría el plan. Esta columna se

rellena mediante la función apg_plan_mgmt.evolve_plan_baselines (p. 826).
has_side_effects Un valor que indica que la instrucción SQL es una instrucción en lenguaje de
manipulación de datos (DML) o una instrucción SELECT que contiene una
función VOLATILE.
last_used Este valor se actualiza a la fecha actual siempre que el plan sea
ejecutado o cuando el plan sea el plan de costo mínimo del optimizador

809

de consultas. Este valor se almacena en la memoria compartida
y se vacía en el disco periódicamente. Para obtener el valor más
actualizado, lea la fecha de la memoria compartida llamando a la función
apg_plan_mgmt.plan_last_used(sql_hash, plan_hash) en lugar de
leer el valor last_used. Para obtener más información, consulte el parámetro
apg_plan_mgmt.plan_retention_period (p. 824).
last_validated La fecha y hora más recientes en las que se comprobó que el plan se podría
recrear mediante la función apg_plan_mgmt.validate_plans (p. 830) o la
función apg_plan_mgmt.evolve_plan_baselines (p. 826).
last_verified La fecha y hora más recientes en las que se verificó un plan como el que mejor
rendimiento ofrece para los parámetros especificados mediante la función
origin Cómo se capturó el plan con el parámetro

apg_plan_mgmt.capture_plan_baselines (p. 822). Entre los valores válidos se
incluyen los siguientes:
M: el plan se capturó mediante captura de planes manual.
A: el plan se capturó mediante captura de planes automática.
param_list Los valores de parámetros que se pasaron a la instrucción si es una instrucción

preparada.
plan_created La fecha y hora en que se creó el plan.
plan_hash El identificador del plan. La combinación de plan_hash y sql_hash identifica

un plan específico de forma unívoca.
plan_outline Una representación del plan que se utiliza para recrear el plan de ejecución
real, y es independiente de la base de datos. Los operadores del árbol se
corresponden con los operadores que aparecen en el resultado de EXPLAIN.
planning_time_ms El tiempo real de ejecución del planificador, en milisegundos. Esta columna se

rellena mediante la función apg_plan_mgmt.evolve_plan_baselines (p. 826).
queryId Un hash de instrucción, calculado por la extensión pg_stat_statements.

No es un identificador estable ni independiente de la base de datos, ya que
depende de los identificadores de objetos (OID).
sql_hash Un valor hash del texto de la instrucción SQL, normalizado con los literales
eliminados.
sql_text El texto completo de la instrucción SQL.

810
Capturar planes de ejecución
status El estado de un plan, que determina cómo utiliza un plan el optimizador. Entre
los valores válidos se incluyen los siguientes. No distingue entre mayúsculas y
minúsculas.
• approved: un plan utilizable que el optimizador puede elegir para

ejecutar. El optimizador ejecuta el plan menos costoso a partir de un
conjunto de planes aprobados para una instrucción administrada (base
de referencia). Para restaurar un plan como aprobado, utilice la función
• unapproved: un plan capturado que no ha verificado para su uso. Para
obtener más información, consulte Evaluación del rendimiento de los
planes (p. 817).
• rejected: un plan que el optimizador no utilizará. Para obtener más
información, consulte Rechazar o deshabilitar planes más lentos (p. 818).
• preferred: un plan que ha determinado como plan preferido para emplear
para una instrucción administrada.
Si el costo mínimo del optimizador no es un plan aprobado o preferido,

puede reducir la sobrecarga de cumplimiento del plan. Para ello, realice
un subconjunto de los planes aprobados preferred. Cuando el costo
mínimo del optimizador no sea un plan approved, se seleccionará un plan
preferred antes que uno approved.
Para restaurar un plan como preferred, utilice la función

apg_plan_mgmt.set_plan_status (p. 829).
stmt_name El nombre de la instrucción SQL dentro de una instrucción PREPARE. Este

valor es una cadena vacía para una instrucción preparada sin nombre. Este
valor es NULL para una instrucción no preparada.
El beneficio en tiempo total, en milisegundos, de habilitar este plan. Este valor

total_time_benefit_ms
tiene en cuenta tanto el tiempo de planificación como el de ejecución.
Si este valor es negativo, existe una desventaja al habilitar

este plan. Esta columna se rellena mediante la función

Puede capturar planes de ejecución para instrucciones SQL específicas mediante una captura del plan
manual. También puede capturar todos los planes (o los más lentos o volátiles) que se pongan en marcha
dos o más veces mientras se ejecuta su aplicación utilizando la captura de planes automática.
Al capturar planes, el optimizador establece el estado del primer plan capturado de una instrucción
administrada en approved. El optimizador establece el estado de cualquier plan adicional capturado para
una instrucción administrada en unapproved. Sin embargo, puede guardarse ocasionalmente más de un
plan con el estado approved. Esto puede ocurrir cuando se crean varios planes para una instrucción en
paralelo, y antes de que se confirme el primer plan para la instrucción.
Para controlar el número máximo de planes que se pueden capturar y almacenar en la vista dba_plans,
establezca el parámetro apg_plan_mgmt.max_plans en su grupo de parámetros en el nivel de la
instancia de la base de datos. Un cambio en el parámetro apg_plan_mgmt.max_plans requiere un
reinicio de la instancia de la base de datos para que surta efecto un nuevo valor. Para obtener más
información, consulte el parámetro apg_plan_mgmt.max_plans (p. 823).

811
Temas
• Captura manual de planes para instrucciones SQL específicas (p. 812)
• Captura de planes automática (p. 812)
• Uso de estadísticas para identificar instrucciones SQL (p. 813)
Captura manual de planes para instrucciones SQL específicas

Si tiene un conjunto conocido de instrucciones SQL para administrar, ponga las instrucciones en un archivo
de script SQL y capture manualmente los planes. A continuación se muestra un ejemplo psql de cómo
capturar planes de consulta manualmente para un conjunto de instrucciones SQL.
psql> SET apg_plan_mgmt.capture_plan_baselines = manual;

psql> \i my-statements.sql
psql> SET apg_plan_mgmt.capture_plan_baselines = off;
Tras capturar un plan para cada instrucción SQL, el optimizador añade una nueva fila a la vista
apg_plan_mgmt.dba_plans.
Recomendamos que utilice instrucciones EXPLAIN o EXPLAIN EXECUTE en el archivo de script de SQL.
Asegúrese de que incluye suficientes variaciones en los valores de parámetros para capturar todos los
planes de interés.
Si conoce un plan mejor que el plan de costo mínimo del optimizador, puede que sea capaz de forzar al
optimizador a que use el plan mejor. Para ello, especifique una o más sugerencias del optimizador. Para
obtener más información, consulte Corrección de planes mediante pg_hint_plan (p. 819). Para comparar
el rendimiento de los planes unapproved y approved y aprobarlos, rechazarlos o eliminarlos, consulte
Evaluación del rendimiento de los planes (p. 817).
Captura de planes automática

Utilice la captura de planes automática para situaciones como la siguiente:
• No sabe las instrucciones SQL específicas que quiere administrar.

• Tiene cientos o miles de instrucciones SQL que administrar.
• Su aplicación usa una API de cliente. Por ejemplo, JDBC utiliza instrucciones preparadas sin nombre o
instrucciones en modo masivo que no se pueden expresar en SQL en PostgreSQL.
Para capturar planes automáticamente
1. Active la captura de planes automática configurando apg_plan_mgmt.capture_plan_baselines

como automatic en el grupo de parámetros para la instancia de la base de datos. Para obtener
más información, consulte Modificación de parámetros de un grupo de parámetros de base de
datos (p. 265).
3. A medida que se ejecuta la aplicación, el optimizador captura los planes para cada instrucción SQL
que se ejecute al menos dos veces.
A medida que se ejecuta la aplicación con los ajustes de parámetro del administrador de planes
de consulta predeterminados, el optimizador captura los planes para cada instrucción SQL que se
ejecute al menos dos veces. La captura de todos los planes con los valores predeterminados tiene
una sobrecarga de tiempo de ejecución muy pequeña y puede habilitarse en producción.
Puede modificar algunos parámetros para capturar planes para instrucciones que tengan el mayor
impacto sobre el rendimiento, que se ejecuten durante el mayor tiempo o que muestren el rendimiento

812
más volátil. Sin embargo, este modo ampliado de la captura de planes automática tiene una
sobrecarga de rendimiento notable.
Para desactivar la captura de planes automática, realice el siguiente parámetro:
• En el parámetro apg_plan_mgmt.capture_plan_baselines, establezca el valor off desde el

grupo de parámetros de base de datos.
Para medir el rendimiento de los planes sin aprobar y aprobar, rechazar o eliminar dichos planes, consulte
Evaluación del rendimiento de los planes (p. 817).
También puede identificar qué instrucciones SQL capturar automáticamente en función de las propiedades
estadísticas de las instrucciones. Para obtener más información, consulte Uso de estadísticas para
identificar instrucciones SQL (p. 813).
Uso de estadísticas para identificar instrucciones SQL

Con la captura automática de planes, puede identificar las instrucciones SQL que quiera administrar
por sus propiedades estadísticas. Para acceder a las estadísticas de las instrucciones SQL, instale la
extensión pg_stat_statements.
La administración de planes de consulta facilita parámetros que acceden a estas estadísticas. Puede
configurar estos parámetros para que faciliten criterios al optimizador, de modo que pueda identificar qué
instrucciones SQL administrar. Durante la captura de planes automática, el optimizador captura planes
para instrucciones que se ajusten a criterios estadísticos.
Utilice los siguientes parámetros para definir criterios estadísticos para las instrucciones SQL que quiera
administrar.
apg_plan_mgmt.pgss_min_calls Cuántas veces se ha ejecutado la instrucción. Para

obtener más información, consulte el parámetro
apg_plan_mgmt.pgss_min_calls (p. 823).
El tiempo total de ejecución de la instrucción. Para

apg_plan_mgmt.pgss_min_total_time_ms
apg_plan_mgmt.pgss_min_total_time_ms (p. 824).
El tiempo medio de ejecución de la instrucción. Para

apg_plan_mgmt.pgss_min_mean_time_ms
apg_plan_mgmt.pgss_min_mean_time_ms (p. 823).
La desviación estándar del tiempo de ejecución de la instrucción.

apg_plan_mgmt.pgss_min_stddev_time_ms
Para obtener más información, consulte el parámetro
apg_plan_mgmt.pgss_min_stddev_time_ms (p. 824).
Note
El rendimiento de su aplicación se verá afectado si usa estas estadísticas para identificar qué
instrucciones SQL administrar.
Antes de que pueda usar estadísticas para identificar qué instrucciones quiere administrar, debe instalar
la extensión pg_stat_statements. Para obtener información sobre la instalación y otros aspectos,
consulte la Documentación sobre pg_stats_statements de PostgreSQL.

813
Uso de planes administrados
El siguiente procedimiento muestra cómo identificar instrucciones SQL para administrarlas en función de
criterios estadísticos y capturar planes automáticamente para todas las instrucciones coincidentes.
Para capturar planes en función de las estadísticas de las instrucciones SQL
Note
Establezca los siguientes parámetros apg_plan_mgmt en el grupo de parámetros para su

instancia de base de datos y después reiníciela. Para obtener más información acerca de los
grupos de parámetros, consulte Modificación de parámetros de un grupo de parámetros de base
de datos (p. 265).
1. Active la captura automática de planes estableciendo el parámetro

apg_plan_mgmt.capture_plan_baselines en automatic.
2. Configure apg_plan_mgmt.use_plan_baselines como true para forzar que el optimizador use
planes administrados a medida que se siguen capturando más planes. Configure un valor de false si
solo quiere capturar planes y no utilizarlos.
3. Establezca los criterios estadísticos para identificar qué instrucciones SQL quiere administrar.
Por ejemplo, si configura apg_plan_mgmt.pgss_min_calls en 3 le estará diciendo al optimizador

que guarde planes solamente para instrucciones que se ejecuten al menos 3 veces. Si configura
apg_plan_mgmt.pgss_min_total_time_ms en 30000 le estará diciendo al optimizador que
guarde planes para instrucciones que se ejecuten durante 30 segundos o más.
5. Habilite la extensión pg_stat_statements para hacer que las estadísticas de las instrucciones SQL
estén disponibles para esta instancia de base de datos.
CREATE EXTENSION IF NOT EXISTS pg_stat_statements;
A medida que se ejecuta la aplicación, el optimizador captura los planes para cada instrucción coincidente.

Para que el optimizador use los planes capturados para sus instrucciones administradas, establezca el
parámetro apg_plan_mgmt.use_plan_baselines en true. A continuación figura el ejemplo de una
instancia local.
SET apg_plan_mgmt.use_plan_baselines = true;
Mientras se ejecuta la aplicación, esta configuración hace que el optimizador utilice el plan de costo
mínimo, preferido o aprobado que sea válido y esté habilitado para cada instrucción administrada.
Cómo selecciona el optimizador qué plan ejecutar

El costo de un plan de ejecución es un cálculo que realiza el optimizador para comparar planes distintos. El
costo del optimizador es una función de varios factores que incluye las operaciones de CPU e I/O que usa
el plan. Para obtener más información acerca de los costos del planificador de consultas de PostgreSQL,
consulte la documentación de PostgreSQL sobre planificación de consultas.
En el siguiente gráfico de flujo se muestra cómo el optimizador del administrador de planes de consulta
elige qué plan ejecutar.

814
El flujo es el siguiente:
1. Cuando el optimizador procesa cada una de las instrucciones SQL, genera un plan de costo mínimo.

815
2. Sin la administración de planes de consulta, el optimizador se limita a ejecutar el plan generado.

El optimizador utiliza la administración de planes de consulta si establece una o ambas de las
configuraciones de parámetros siguientes:
• apg_plan_mgmt.capture_plan_baselines a manual o automatic
• De apg_plan_mgmt.use_plan_baselines a true
3. El optimizador ejecuta inmediatamente el plan generado si se dan estas dos condiciones siguientes:
• El plan del optimizador ya está en la vista apg_plan_mgmt.dba_plans para la instrucción SQL.
• El estado del plan es approved o preferred.
4. El optimizador realiza el procesamiento del plan de captura si el parámetro
apg_plan_mgmt.capture_plan_baselines es manual o automatic.
Para obtener más información sobre cómo el optimizador captura los planes, consulte Capturar planes
de ejecución (p. 811).
5. El optimizador ejecuta el plan generado si apg_plan_mgmt.use_plan_baselines es false.
6. Si el plan del optimizador no está en la vista apg_plan_mgmt.dba_plans, el optimizador captura el
plan como un nuevo plan unapproved.
7. El optimizador ejecuta el plan generado si se dan estas dos condiciones siguientes:
• El plan del optimizador no es un plan rejected ni disabled.
• El costo total del plan es menor que el umbral del plan de ejecución sin aprobar.
El optimizador no ejecuta planes deshabilitados ni ningún plan que tenga el estado de

rechazado. En la mayoría de casos, el optimizador no ejecuta planes sin aprobar. Sin
embargo, el optimizador se ejecuta como plan sin aprobar si establece un valor para el
parámetro apg_plan_mgmt.unapproved_plan_execution_threshold y el costo
total del plan es menor que el umbral. Para obtener más información, consulte el parámetro
apg_plan_mgmt.unapproved_plan_execution_threshold (p. 824).
8. Si la instrucción administrada tiene algún plan preferido habilitado y válido, el optimizador ejecuta el que
tenga costo mínimo.
Un plan válido es aquel que el optimizador puede elegir para ejecutar. Los planes administrados pueden
dejar de ser válidos por varios motivos. Por ejemplo, los planes dejan de ser válidos cuando los objetos
de los que dependen se eliminan, como un índice o una partición de una tabla con particiones.
9. El optimizador determina el plan de costo mínimo de entre los planes aprobados por la instrucción
administrada que estén habilitados y sean válidos. A continuación, el optimizador ejecuta el plan
aprobado con costo mínimo.
Analizar qué plan utilizará el optimizador

Cuando el parámetro apg_plan_mgmt.use_plan_baselines está establecido en true, puede utilizar
instrucciones SQL EXPLAIN ANALYZE para hacer que el optimizador muestre el plan que usaría si fuera a
ejecutar la consulta. A continuación se muestra un ejemplo.
EXPLAIN ANALYZE EXECUTE rangeQuery (1,10000);

QUERY PLAN
--------------------------------------------------------------------------
Aggregate (cost=393.29..393.30 rows=1 width=8) (actual time=7.251..7.251 rows=1 loops=1)
-> Index Only Scan using t1_pkey on t1 t (cost=0.29..368.29 rows=10000 width=0)
(actual time=0.061..4.859 rows=10000 loops=1)
Index Cond: ((id >= 1) AND (id <= 10000))
Heap Fetches: 10000
Planning time: 1.408 ms
Execution time: 7.291 ms
Note: An Approved plan was used instead of the minimum cost plan.
SQL Hash: 1984047223, Plan Hash: 512153379

816
Mantenimiento de planes de ejecución
El optimizador indica qué plan ejecutará, pero tenga en cuenta que en este ejemplo ha encontrado un
plan con menor costo. En ese caso, capture este plan de costo mínimo activando la captura de planes
automática, como se describe en Captura de planes automática (p. 812).
El optimizador captura los planes nuevos como sin aprobar. Utilice la función
apg_plan_mgmt.evolve_plan_baselines para comparar planes y cambiarlos a aprobado,
rechazado o deshabilitado. Para obtener más información, consulte Evaluación del rendimiento de los
planes (p. 817).

La administración de planes de consultas ofrece técnicas y funciones para añadir, mantener y mejorar
planes de ejecución.
Temas
• Evaluación del rendimiento de los planes (p. 817)
• Validación de planes (p. 818)
• Corrección de planes mediante pg_hint_plan (p. 819)
• Eliminación de planes (p. 820)
• Importación y exportación de planes (p. 821)
Evaluación del rendimiento de los planes

Después de que el optimizador capture los planes como sin aprobar, utilice la función
apg_plan_mgmt.evolve_plan_baselines para comparar planes en función de su rendimiento
real. Según el resultado de sus experimentos de rendimiento, podrá cambiar el estado de
un plan de no aprobado a aprobado o rechazado. También puede decidir utilizar la función
apg_plan_mgmt.evolve_plan_baselines para deshabilitar temporalmente un plan si no se ajusta a
sus requisitos.
Temas
• Aprobar planes mejores (p. 817)
• Rechazar o deshabilitar planes más lentos (p. 818)
Aprobar planes mejores

El siguiente ejemplo muestra cómo cambiar el estado de los planes administrados a aprobados mediante
la función apg_plan_mgmt.evolve_plan_baselines.
SELECT apg_plan_mgmt.evolve_plan_baselines (
sql_hash,
plan_hash,
min_speedup_factor := 1.0,
action := 'approve'
)
FROM apg_plan_mgmt.dba_plans WHERE status = 'unapproved';
NOTICE: rangequery (1,10000)

NOTICE: Baseline [ Planning time 0.761 ms, Execution time 13.261 ms]
NOTICE: Baseline+1 [ Planning time 0.204 ms, Execution time 8.956 ms]
NOTICE: Total time benefit: 4.862 ms, Execution time benefit: 4.305 ms
NOTICE: Unapproved -> Approved
evolve_plan_baselines
-----------------------

817
0
(1 row)
El resultado muestra un informe de rendimiento para la instrucción rangequery con vinculaciones de

parámetros de 1 y 10 000. El nuevo plan no aprobado (Baseline+1) es mejor que el plan aprobado
previamente (Baseline). Para confirmar que el nuevo plan no está aprobado, compruebe la vista
apg_plan_mgmt.dba_plans.
SELECT sql_hash, plan_hash, status, enabled, stmt_name

sql_hash | plan_hash | status | enabled | stmt_name

------------+-----------+----------+---------+------------
1984047223 | 512153379 | Approved | t | rangequery
1984047223 | 512284451 | Approved | t | rangequery
(2 rows)
El plan administrado incluye ahora dos planes aprobados que componen la base de referencia del
plan de la instrucción. También puede llamar a la función apg_plan_mgmt.set_plan_status para
establecer directamente el campo de estado de un plan a 'approved', 'rejected', 'unapproved' o
'preferred'.
Rechazar o deshabilitar planes más lentos

Para rechazar o deshabilitar planes, pase 'reject' o 'disable' como parámetro de acción a la
función apg_plan_mgmt.evolve_plan_baselines. En este ejemplo se deshabilita cualquier plan
capturado sin aprobar que resulte al menos un 10 por ciento más lento que el mejor plan aprobado para la
instrucción.
SELECT apg_plan_mgmt.evolve_plan_baselines(
sql_hash, -- The managed statement ID
plan_hash, -- The plan ID
1.1, -- number of times faster the plan must be
'disable' -- The action to take. This sets the enabled field to false.
)
WHERE status = 'Unapproved' AND -- plan is Unapproved
origin = 'Automatic'; -- plan was auto-captured
También puede establecer un plan directamente como rechazado o deshabilitado. Para

establecer directamente el campo habilitado de un plan como true o false, llame a la función
apg_plan_mgmt.set_plan_enabled. Para establecer directamente el campo estado de un plan como
'approved', 'rejected' o 'unapproved', llame a la función 'preferred'.
Validación de planes
Use la función apg_plan_mgmt.validate_plans para eliminar o deshabilitar planes no válidos.
Los planes pueden volverse no válidos u obsoletos cuando se eliminan los objetos de los que dependen,
como un índice o una tabla. Sin embargo, puede que un plan deje de ser válido solo temporalmente si el
objeto eliminado se recrea. Si un plan no válido puede pasar a ser válido posteriormente, es posible que
prefiera deshabilitar un plan no válido o no hacer nada en lugar de eliminarlo.
Para encontrar y eliminar todos los planes que no sean válidos y no se hayan utilizado en la última
semana, utilice la función apg_plan_mgmt.validate_plans de la siguiente forma.
SELECT apg_plan_mgmt.validate_plans(sql_hash, plan_hash, 'delete')

818
WHERE last_used < (current_date - interval '7 days');
Para habilitar o deshabilitar un plan directamente, utilice la función

apg_plan_mgmt.set_plan_enabled.
Corrección de planes mediante pg_hint_plan

El optimizador de consultas está bien diseñado para encontrar un plan óptimo para todas las instrucciones,
y en la mayoría de los casos el optimizador encuentra un plan bueno. Sin embargo, ocasionalmente podría
detectar que existe un plan mucho mejor que el generado por el optimizador. Dos formas recomendadas
de hacer que el optimizador genere un plan deseado son incluir la extensión pg_hint_plan o establecer
variables de Grand Unified Configuration (GUC) en PostgreSQL:
• Extensión pg_hint_plan: especifique un "consejo" para modificar cómo funciona el planificador

mediante la extensión pg_hint_plan de PostgreSQL. Para instalar y obtener más información sobre
cómo usar la extensión pg_hint_plan, consulte la documentación de pg_hint_plan.
• Variables GUC: anule uno o varios parámetros del modelo de costos u otros parámetros del optimizador,
como from_collapse_limit o GEQO_threshold.
Al usar una de estas técnicas para forzar que el optimizador de consultas utilice un plan, también puede
utilizar la administración de planes de consulta para capturar y forzar el uso del nuevo plan.
Puede utilizar la extensión pg_hint_plan para cambiar el orden de las combinaciones, los métodos
de combinación o las rutas de acceso para una instrucción SQL. Puede utilizar un comentario SQL
con sintaxis pg_hint_plan especial para modificar cómo crea un plan el optimizador. Por ejemplo,
supongamos que la instrucción SQL del problema tiene una combinación bidireccional.
SELECT *
FROM t1, t2
WHERE t1.id = t2.id;
A continuación, supongamos que el optimizador elige el orden de combinación (t1, t2), pero que sabemos
que el orden de combinación (t2, t1) es más rápido. El siguiente consejo fuerza al optimizador a utilizar el
orden de combinación más rápido (t2, t1). Incluya EXPLAIN de modo que el optimizador genere un plan
para la instrucción SQL pero no ejecute la instrucción. (No se muestra el resultado).
/*+ Leading ((t2 t1)) */ EXPLAIN SELECT *

FROM t1, t2
Los siguientes pasos muestran cómo utilizar pg_hint_plan.
Para modificar el plan generado por el optimizador y capturar el plan con pg_hint_plan
1. Active el modo de captura manual.
SET apg_plan_mgmt.capture_plan_baselines = manual;
2. Especifique un consejo para la instrucción SQL que le interese.
/*+ Leading ((t2 t1)) */ EXPLAIN SELECT *

FROM t1, t2

819
Tras la ejecución, el optimizador captura el plan en la vista apg_plan_mgmt.dba_plans. El plan

capturado no incluye la sintaxis del comentario especial pg_hint_plan porque la administración del
plan de consultas normaliza la instrucción eliminando los comentarios al principio.
3. Ver los planes administrados utilizando la vista apg_plan_mgmt.dba_plans.
SELECT sql_hash, plan_hash, status, sql_text, plan_outline

4. Establezca el estado del plan en preferred. De este modo, se asegurará de que el optimizador
decida ejecutarlo en lugar de seleccionarlo del conjunto de planes aprobados cuando el plan de costo
mínimo no sea yaapproved o preferred.
SELECT apg_plan_mgmt.set_plan_status(<sql-hash>, <plan-hash>, 'preferred' );
5. Desactivar la captura de planes manual y forzar el uso de planes administrados.
SET apg_plan_mgmt.capture_plan_baselines = false;

SET apg_plan_mgmt.use_plan_baselines = true;
Ahora, cuando se ejecuta la instrucción SQL original, el optimizador elegirá un plan approved o
preferred. Si el plan de costo mínimo no es approved ni preferred, el optimizador elegirá el plan
preferred.
Eliminación de planes
Elimine planes que no se hayan utilizado durante mucho tiempo o que ya no resulten relevantes. Cada
plan tiene una fecha last_used que utiliza el optimizador cada vez que ejecuta un plan o lo elige como
plan de costo mínimo para una instrucción. Utilice la fecha last_used para determinar si un plan se ha
utilizado recientemente y si sigue siendo relevante.
Por ejemplo, puede utilizar la función apg_plan_mgmt.delete_plan de la siguiente manera. De esta

forma, se eliminan todos los planes que no se hayan seleccionado como plan de costo mínimo o que no
se hayan ejecutado en al menos 31 días. Sin embargo, en este ejemplo no se eliminan los planes que se
hayan rechazado explícitamente.
SELECT SUM(apg_plan_mgmt.delete_plan(sql_hash, plan_hash))

WHERE last_used < (current_date - interval '31 days')
AND status <> 'rejected';
Para eliminar los planes que ya no sean válidos y que no espere que recuperen su validez, utilice la
función apg_plan_mgmt.validate_plans. Para obtener más información, consulte Validación de
planes (p. 818).
Puede implementar su propia política para eliminar planes. Los planes se eliminan
automáticamente cuando la fecha actual - last_used es mayor que el valor del parámetro
apg_plan_mgmt.plan_retention_period, que de forma predeterminada es de 32 días. Puede
especificar un intervalo más largo o implementar su propia política de retención de planes llamando
directamente a la función delete_plan.
Important
Si no limpia los planes, podría quedarse eventualmente sin memoria compartida dedicada a la
administración de planes de consulta. Para controlar cuánta memoria tendrá disponible para
los planes administrados, utilice el parámetro apg_plan_mgmt.max_plans. Establezca este
parámetro en su grupo de parámetros en el nivel de la instancia de base de datos y reiníciela

820
para que surtan efecto los cambios. Para obtener más información, consulte el parámetro
apg_plan_mgmt.max_plans (p. 823).
Importación y exportación de planes

Puede exportar sus planes administrados e importarlos en otra instancia de base de datos.
Para exportar planes administrados.
Un usuario autorizado puede copiar cualquier subconjunto de la tabla apg_plan_mgmt.plans a otra

tabla, y después guardarlo mediante el comando pg_dump. A continuación se muestra un ejemplo.
CREATE TABLE plans_copy AS SELECT *

FROM apg_plan_mgmt.plans [ WHERE predicates ] ;
% pg_dump --table apg_plan_mgmt.plans_copy -Ft mysourcedatabase > plans_copy.tar
DROP TABLE apg_plan_mgmt.plans_copy;
Para importar planes administrados.
1. Copie el archivo .tar de los planes administrados exportados al sistema en el que desee restaurar los
planes.
2. Utilice el comando pg_restore para copiar el archivo tar en una nueva tabla.
% pg_restore --dbname mytargetdatabase -Ft plans_copy.tar
3. Combine la tabla plans_copy con la tabla apg_plan_mgmt.plans, como se muestra en el

siguiente ejemplo.
Note
En algunos casos, puede volcar de una versión de la extensión apg_plan_mgmt y restaurar

a una versión diferente. En estos casos, las columnas de la tabla de planes puede ser
diferente. De ser así, ponga un nombre explícito a las columnas en lugar de usar SELECT *.
INSERT INTO apg_plan_mgmt.plans SELECT * FROM plans_copy

ON CONFLICT ON CONSTRAINT plans_pkey
DO UPDATE SET
status = EXCLUDED.status,
enabled = EXCLUDED.enabled,
-- Save the most recent last_used date
--
last_used = CASE WHEN EXCLUDED.last_used > plans.last_used
THEN EXCLUDED.last_used ELSE plans.last_used END,
-- Save statistics gathered by evolve_plan_baselines, if it ran:
--
estimated_startup_cost = EXCLUDED.estimated_startup_cost,
estimated_total_cost = EXCLUDED.estimated_total_cost,
planning_time_ms = EXCLUDED.planning_time_ms,
execution_time_ms = EXCLUDED.execution_time_ms,
estimated_rows = EXCLUDED.estimated_rows,
actual_rows = EXCLUDED.actual_rows,
total_time_benefit_ms = EXCLUDED.total_time_benefit_ms,
execution_time_benefit_ms = EXCLUDED.execution_time_benefit_ms;
4. Vuelva a cargar los planes administrados en la memoria compartida y elimine la tabla de planes
temporal.
SELECT apg_plan_mgmt.reload(); -- refresh shared memory

DROP TABLE plans_copy;

821
Referencia de parámetros para la
Referencia de parámetros para la administración de

planes de consultas
La extensión apg_plan_mgmt proporciona los siguientes parámetros.
Parámetros
• apg_plan_mgmt.capture_plan_baselines (p. 822)
• apg_plan_mgmt.max_databases (p. 822)
• apg_plan_mgmt.max_plans (p. 823)
• apg_plan_mgmt.pgss_min_calls (p. 823)
• apg_plan_mgmt.pgss_min_mean_time_ms (p. 823)
• apg_plan_mgmt.pgss_min_stddev_time_ms (p. 824)
• apg_plan_mgmt.pgss_min_total_time_ms (p. 824)
• apg_plan_mgmt.plan_retention_period (p. 824)
• apg_plan_mgmt.unapproved_plan_execution_threshold (p. 824)
• apg_plan_mgmt.use_plan_baselines (p. 825)
Establezca los parámetros de administración del plan de consultas en el nivel apropiado:
• Establézcalos en el nivel del clúster para que todas las instancias de bases de datos tengan los mismos
ajustes. Para obtener más información, consulte Modificación de parámetros de un grupo de parámetros
• Establézcalos en el nivel de la instancia de base de datos para aislar los ajustes en una instancia de
base de datos individual. Para obtener más información, consulte Modificación de parámetros de un
grupo de parámetros de base de datos (p. 265).
• Establézcalos en una sesión de cliente específica, como un psql, para aislar los valores únicamente para
esa sesión.
Debe establecer los parámetros apg_plan_mgmt.max_databases y apg_plan_mgmt.max_plans en

el nivel del clúster o de la instancia de la base de datos.
apg_plan_mgmt.capture_plan_baselines
Habilita la captura de planes de ejecución para instrucciones SQL.
SET apg_plan_mgmt.capture_plan_baselines = [off | automatic |manual]
Valor Descripción
off Deshabilita la captura de planes. Esta es la opción predeterminada.
automatic Habilita la captura de planes para instrucciones SQL subsiguientes que satisfagan los
criterios de elegibilidad.
manual Habilita la captura de planes para instrucciones SQL subsiguientes.
apg_plan_mgmt.max_databases
Establece el número máximo de objetos de base de datos que podrían usar la administración de planes de
consulta. Un objeto de base de datos es lo que se crea con la instrucción SQL CREATE DATABASE.

822
Important
Establezca apg_plan_mgmt.max_databases en el nivel de instancia de base de datos o

clúster. Requiere un reinicio de la instancia de la base de datos para que surta efecto un nuevo
valor.
Valor Valor predeterminado Descripción
Entero positivo 10 Un valor entero positivo.
apg_plan_mgmt.max_plans
Establece el número máximo de planes que se pueden capturar en la vista apg_plan_mgmt.dba_plans.
Important
Establezca apg_plan_mgmt.max_plans en el nivel de instancia de base de datos o clúster.

Requiere un reinicio de la instancia de la base de datos para que surta efecto un nuevo valor.
Valor Valor Descripción

predeterminado
integer 1 000 Un valor entero positivo mayor o igual que 10.
apg_plan_mgmt.pgss_min_calls
Establece el número máximo de llamadas a pg_stat_statements elegibles para la captura de planes.
SET apg_plan_mgmt.pgss_min_calls = integer-value;
Entero positivo 2 Un valor entero positivo mayor o igual que 2.
Notas de uso
Requiere la instalación de la extensión pg_stat_statements. Para obtener más información, consulte

esta sección en la documentación de pg_stats_statements de PostgreSQL.
apg_plan_mgmt.pgss_min_mean_time_ms
Valor mínimo de pg_stat_statements mean_time para ser elegible para la captura de plan.
SET apg_plan_mgmt.pgss_min_mean_time_ms = double-value;
Número positivo 0.0 Un número positivo mayor o igual que 0.0.
Notas de uso

823
Requiere la instalación de la extensión pg_stat_statements . Para obtener más información, consulte

apg_plan_mgmt.pgss_min_stddev_time_ms
Valor mínimo de pg_stat_statements stddev_time para ser elegible para la captura de plan.
SET apg_plan_mgmt.pgss_min_stddev_time_ms = double-value;
Notas de uso

apg_plan_mgmt.pgss_min_total_time_ms
Valor mínimo de pg_stat_statements total_time para ser elegible para la captura de plan.
SET apg_plan_mgmt.pgss_min_total_time_ms = double-value;
Notas de uso

apg_plan_mgmt.plan_retention_period
El número de días que se conservan los planes en la vista apg_plan_mgmt.dba_plans antes de
eliminarlos automáticamente. Se elimina un plan cuando para la fecha actual ha transcurrido esta cantidad
de días desde la fecha last_used del plan.
SET apg_plan_mgmt.plan_retention_period_ = integer-value;

predeterminado
Entero positivo 32 Un valor entero positivo mayor o igual que 32, que representa los
días.
apg_plan_mgmt.unapproved_plan_execution_threshold
Un umbral de costos total calculado para el plan, bajo el cual el optimizador ejecuta un plan sin aprobar.
De forma predeterminada, el optimizador no ejecuta planes sin aprobar. Sin embargo, puede establecer un

824
umbral de ejecución para los planes sin aprobar más rápidos. Con esta configuración, el optimizador omite
la sobrecarga de aplicar solo los planes aprobados.
SET apg_hint_plan.unapproved_plan_execution_threshold = integer-value;

predeterminado
Entero positivo 0 Un valor entero positivo mayor o igual que 0. Un valor de 0 indica que
no se ejecutan planes sin aprobar cuando use_plan_baselines es
true.
Con el siguiente ejemplo, el optimizador ejecutará un plan sin aprobar si el costo estimado es de menos de
550, incluso si use_plan_baselines es true.
SET apg_plan_mgmt.unapproved_plan_execution_threshold = 550;
apg_plan_mgmt.use_plan_baselines
Forzar al optimizador a utilizar planes administrados para instrucciones administradas.
SET apg_hint_plan.use_plan_baselines = [true | false];
Valor Descripción
true Forzar el uso de planes administrados. Cuando se ejecuta una instrucción SQL y es
una instrucción administrada en la vista apg_plan_mgmt.dba_plans, el optimizador
selecciona un plan administrado en el siguiente orden.
1. El plan preferido de costo mínimo válido y habilitado.

2. El plan aprobado de costo mínimo válido y habilitado.
3. El plan sin aprobar de costo mínimo válido, habilitado y
que cumpla el umbral, si está establecido con el parámetro
apg_plan_mgmt.unapproved_plan_execution_threshold.
4. El plan de costo mínimo generado por el optimizador.
false (Predeterminado) No usar planes administrados. El optimizador utilizará su plan de costo

mínimo generado.
Notas de uso
Cuando use_plan_baselines es true, el optimizador toma las siguientes decisiones de ejecución:
1. Si el costo estimado del plan del optimizador está por debajo de

unapproved_plan_execution_threshold, lo ejecuta; si no:
2. Si el plan está approved o preferred, lo ejecuta; si no:
3. Ejecutar un plan preferred de costo mínimo, si es posible; si no:
4. Ejecutar un plan approved de costo mínimo, si es posible; si no:
5. Ejecutar el plan de costo mínimo del optimizador.

825
Referencia de funciones para la
Referencia de funciones para la administración de

planes de consultas
La extensión apg_plan_mgmt proporciona las siguientes funciones.
Funciones
• apg_plan_mgmt.delete_plan (p. 826)
• apg_plan_mgmt.evolve_plan_baselines (p. 826)
• apg_plan_mgmt.plan_last_used (p. 828)
• apg_plan_mgmt.reload (p. 828)
• apg_plan_mgmt.set_plan_enabled (p. 828)
• apg_plan_mgmt.set_plan_status (p. 829)
• apg_plan_mgmt.validate_plans (p. 830)
apg_plan_mgmt.delete_plan
Eliminar un plan administrado.
Sintaxis
apg_plan_mgmt.delete_plan(
sql_hash,
plan_hash
)
Valor de retorno
Devuelve 0 si la eliminación se ha realizado correctamente o -1 si en la eliminación se ha producido un

error.
Parámetros
sql_hash El ID sql_hash de la instrucción SQL

administrada por el plan.
plan_hash El ID plan_hash del plan administrado.
apg_plan_mgmt.evolve_plan_baselines
Comprueba si un plan ya aprobado es más rápido o si un plan identificado por el optimizador de consultas
como plan de costo mínimo es más rápido.
Sintaxis
apg_plan_mgmt.evolve_plan_baselines(
sql_hash,
plan_hash,
min_speedup_factor,
action
)

826
Valor de retorno
El número de planes que no han sido más rápidos que el mejor plan aprobado.
Parámetros
sql_hash El ID sql_hash de la instrucción SQL administrada por el plan.
plan_hash El ID plan_hash del plan administrado. Utilice NULL para referirse a todos
los planes que tengan el mismo valor del ID de sql_hash.
min_speedup_factor El factor de aceleración mínimo es el número de veces más rápido que debe
ser un plan en relación con los planes ya aprobados para aprobarlo. Este
factor puede ser también el número de veces más lento que debe ser un plan
para rechazarlo o deshabilitarlo.
Este valor es un número flotante positivo.
action La acción que va a realizar la función. Entre los valores válidos se incluyen los
siguientes. No distingue entre mayúsculas y minúsculas.
• 'disable': deshabilitar cada plan coincidente que no cumpla el factor de

aceleración mínimo.
• 'approve': habilitar cada plan coincidente que cumpla el factor de
aceleración mínimo y establecer su estado en approved.
• 'reject': para cada plan coincidente que no cumpla el factor de
aceleración mínimo, establecer su estado en rejected.
• NULL: la función se limita a devolver el número de planes que no tienen
beneficios de rendimiento porque no cumplen el factor de aceleración
mínimo.
Notas de uso
Establecer planes específicos como aprobados, rechazados o deshabilitados en función de si el tiempo

de planificación más el de ejecución es más rápido que el mejor plan aprobado por un factor que puede
configurar. El parámetro de acción puede establecerse en 'approve' o 'reject' para aprobar o
rechazar automáticamente un plan que cumpla los criterios de rendimiento. Como alternativa, podría
establecerse como " (cadena vacía) para realizar el experimento de rendimiento y producir un informe, sin
realizar ninguna acción.
Puede evitar una nueva ejecución sin sentido de la función apg_plan_mgmt.evolve_plan_baselines

para un plan en el que se ha ejecutado recientemente. Para ello, restrinja los planes a los planes
sin aprobar creados recientemente. Como alternativa, puede evitar la ejecución de la función
apg_plan_mgmt.evolve_plan_baselines en cualquier plan aprobado que tenga una marca temporal
last_verified reciente.
Realizar un experimento de rendimiento para comparar el tiempo de planificación más el de ejecución

para cada plan en relación con los demás planes de la base de referencia. En algunos casos, solo hay un
plan para una instrucción, y el plan está aprobado. En tal caso, compare el tiempo de planificación más
ejecución del plan con el tiempo de planificación más ejecución de no usar ningún plan.
El beneficio (o desventaja) incremental de cada plan queda registrado en la vista

apg_plan_mgmt.dba_plans de la columna total_time_benefit_ms. Si este valor es positivo, existe
un beneficio de rendimiento medible al incluir este plan en la base de referencia.

827
Además de recopilar el tiempo de planificación y ejecución de cada plan candidato, la columna

last_verified de la vista apg_plan_mgmt.dba_plans se actualiza con el current_timestamp. La
marca temporal last_verified se podría utilizar para evitar la ejecución de esta función de nuevo en un
plan cuyo rendimiento se haya verificado recientemente.
apg_plan_mgmt.plan_last_used
Devuelve la fecha last_used del plan especificado de la memoria compartida.
Sintaxis
apg_plan_mgmt.plan_last_used(
sql_hash,
plan_hash
)
Valor de retorno
Devuelve la fecha last_used.
Parámetros
sql_hash El ID sql_hash de la instrucción SQL

administrada por el plan.
apg_plan_mgmt.reload
Vuelve a cargar los planes en la memoria compartida desde la vista apg_plan_mgmt.dba_plans.
Sintaxis
apg_plan_mgmt.reload()
Valor de retorno
Ninguno.
Parámetros
Ninguno.
Notas de uso
Llame a reload para las siguientes situaciones:
• Utilícelo para actualizar la memoria compartida de una réplica de solo lectura inmediatamente, en lugar
de esperar a que los nuevos planes propaguen la réplica.
• Se utiliza tras importar los planes administrados.
apg_plan_mgmt.set_plan_enabled
Habilitar o deshabilitar un plan administrado.

828
Sintaxis
apg_plan_mgmt.set_plan_enabled(
sql_hash,
plan_hash,
[true | false]
)
Valor de retorno
Devuelve 0 si el ajuste se ha realizado correctamente o -1 si en el ajuste se ha producido un error.
Parámetros
enabled Valor booleano de verdadero o falso:
• Un valor de true habilita el plan.

• Un valor de false deshabilita el plan.
apg_plan_mgmt.set_plan_status
Establece el estado de un plan administrado como aprobado, sin aprobar, rechazado o preferido.
Sintaxis
apg_plan_mgmt.set_plan_status(
sql_hash,
plan_hash,
status
)
Valor de retorno
Devuelve 0 si el ajuste se ha realizado correctamente o -1 si en el ajuste se ha producido un error.
Parámetros
status Una cadena con uno de los siguientes valores, no distingue entre mayúsculas y
minúsculas:
• approved
• unapproved
• rejected

829
• preferred
Para obtener más información acerca de estos valores de la tarea, consulte status en
Referencia de la vista apg_plan_mgmt.dba_plans (p. 809).
apg_plan_mgmt.validate_plans
Validar que el optimizador aún puede recrear planes. El optimizador valida planes aprobados, sin aprobar
y preferidos, independientemente de si el plan está habilitado o deshabilitado. Los planes rechazados no
se validan. Opcionalmente, puede usar la función apg_plan_mgmt.validate_plans para eliminar o
deshabilitar planes no válidos.
Sintaxis
apg_plan_mgmt.validate_plans(
sql_hash,
plan_hash,
action)
apg_plan_mgmt.validate_plans(
action)
Valor de retorno
Número de planes no válidos.
Parámetros
plan_hash El ID plan_hash del plan administrado. Utilice NULL para referirse a todos los planes
para el mismo valor del ID de sql_hash.
action La acción que va a realizar la función para los planes no válidos. Entre los valores de
cadena válidos se incluyen los siguientes. No distingue entre mayúsculas y minúsculas.
• 'disable': los planes no válidos se deshabilitan.

• 'delete': los planes no válidos se eliminan.
• NULL: la función se limita a devolver el número de planes no válidos. No se realiza
ninguna otra acción.
• '': una cadena vacía produce un mensaje que indica el número de planes válidos y no
válidos.
Cualquier otro valor se trata como una cadena vacía.
Notas de uso
Utilice el formulario validate_plans(action) para validar todos los planes administrados para las
instrucciones administradas en toda la vista apg_plan_mgmt.dba_plans.

830
Recuperación rápida después de una conmutación por error
Utilice el formulario validate_plans(sql_hash, plan_hash, action) para validar un plan

administrado especificado con plan_hash, para una instrucción administrada especificada con
sql_hash.
Utilice el formulario validate_plans(sql_hash, NULL, action) para validar todos los planes
administrados para una instrucción administrada especificada con sql_hash.
Recuperación rápida después de una conmutación

por error con la administración de caché del clúster
para Aurora PostgreSQL
Para la recuperación rápida de la instancia de base de datos del escritor en sus clústeres de Aurora
PostgreSQL si se produce una conmutación por error, utilice la administración de caché del clúster para
Amazon Aurora PostgreSQL. La administración de caché del clúster garantiza que el rendimiento de la
aplicación se mantiene si se produce una conmutación por error.
En una situación de conmutación por error típica, puede que observe una degradación del rendimiento
temporal, pero acusada, después de la conmutación por error. Esta degradación se produce porque
cuando se inicia la instancia de base de datos de conmutación por error, la caché del búfer está vacía. Una
caché vacía se conoce también como caché fría. Una caché fría degrada el rendimiento porque la instancia
de base de datos tiene que realizar la lectura a partir del disco inferior en lugar de aprovechar los valores
almacenados en la caché del búfer.
Con la administración de la caché del clúster, establecerá una instancia de base de datos del lector
específica como destino de conmutación por error. La administración de la caché del clúster garantiza
que los datos en la caché del lector designada se mantiene sincronizada con los datos en la caché de la
instancia de la base de datos del escritor. La caché del lector designado con los valores precompletados se
conoce como caché templada. Si se produce una conmutación por error, el lector designado utiliza valores
en su caché templada de inmediato cuando se promociona en la nueva instancia de base de datos del
escritor. Este enfoque proporciona a su aplicación un rendimiento de recuperación mucho mejor.
Temas
• Configuración de la administración de la caché del clúster (p. 831)
• Supervisión de la caché del búfer (p. 834)
Configuración de la administración de la caché del

clúster
Note
La gestión de la caché del clúster es compatible con los clústeres de base de datos Aurora
PostgreSQL de las versiones 9.6.11 y superiores, y las versiones 10.5 y superiores.
Para configurar la administración de la caché del clúster, realice los siguientes pasos.
Pasos de configuración
• Habilitación de la administración de la caché del clúster (p. 832)
• Establecimiento de la prioridad de la capa de promoción para la instancia de base de datos del
escritor (p. 832)
• Establecimiento de la prioridad de la capa de promoción para una instancia de base de datos del
lector (p. 833)

831
Configuración de la administración de la caché del clúster
Note
Deje que transcurra al menos un minuto después de completar estos pasos para que la gestión de
la caché del clúster esté totalmente operativa.
Habilitación de la administración de la caché del clúster

Para habilitar la gestión de la caché del clúster para un clúster de base de datos, modifique su grupo de
parámetros estableciendo el parámetro apg_ccm_enabled en 1 como se describe a continuación.
Para habilitar la administración de la caché del clúster, realice el siguiente procedimiento:
3. En la lista, elija el grupo de parámetros para el clúster de base de datos Aurora PostgreSQL.
El clúster de base de datos debe utilizar un grupo de parámetros distinto al predeterminado, ya que no
puede cambiar los valores en un grupo de parámetros predeterminado.
5. Establezca el valor del parámetro del clúster de apg_ccm_enabled en 1.
6. Elija Save changes (Guardar cambios).
AWS CLI
Para habilitar la administración de la caché del clúster para el clúster de base de datos de Aurora
PostgreSQL, utilice el comando modify-db-cluster-parameter-group de la AWS CLI con los
siguientes parámetros necesarios:
• --parameters
Example
aws rds modify-db-cluster-parameter-group \

--db-cluster-parameter-group-name my-db-cluster-parameter-group \
--parameters "ParameterName=apg_ccm_enabled,ParameterValue=1,ApplyMethod=immediate"
Para Windows:
aws rds modify-db-cluster-parameter-group ^

--db-cluster-parameter-group-name my-db-cluster-parameter-group ^
--parameters "ParameterName=apg_ccm_enabled,ParameterValue=1,ApplyMethod=immediate"
Establecimiento de la prioridad de la capa de promoción para la

instancia de base de datos del escritor
Asegúrese de que la prioridad de la promoción sea tier-0para la instancia de base de datos del escritor
del clúster de base de datos de Aurora PostgreSQL. La prioridad de la capa de promoción es un valor

832
Configuración de la administración de la caché del clúster
que especifica el orden en el que se promociona el lector de Aurora en la instancia de base de datos del
escritor después de un error. Los valores válidos con de 0 a 15, donde 0 es la primera prioridad y 15 la
última. Para obtener más información sobre la capa de promoción, consulte Tolerancia a errores para un
Para establecer la prioridad de la promoción para la instancia de base de datos del escritor en
tier-0, realice el siguiente procedimiento
3. Elija la instancia de base de datos del escritor del clúster de base de datos de Aurora PostgreSQL.
4. Elija Modify. Aparece la página Modify DB Instance.
5. En el panel Failover (Conmutación por error), elija tier-0 para Priority (Prioridad).
7. Para aplicar los cambios inmediatamente después de guardarlos, elija Apply immediately (Aplicar
inmediatamente).
8. Seleccione Modify DB Instance (Modificar instancia de base de datos) para guardar los cambios.
AWS CLI
Para configurar la prioridad de la capa de promoción en 0 para la instancia de base de datos del escritor
mediante la AWS CLI, invoque el comando modify-db-instance con los siguientes parámetros necesarios:
• --promotion-tier
• --apply-immediately
Example

--db-instance-identifier writer-db-instance \
--promotion-tier 0 \
--apply-immediately
Para Windows:

--db-instance-identifier writer-db-instance ^
---promotion-tier 0 ^
--apply-immediately
Establecimiento de la prioridad de la capa de promoción para una

instancia de base de datos del lector
Configure una instancia de base de datos del lector para la administración de la caché del clúster. Para
ello, elija un lector del clúster de Aurora PostgreSQL que sea la misma clase de instancia que la instancia
de base de datos del escritor. A continuación, establezca su prioridad de la capa de promoción en 0.

833
Supervisión de la caché del búfer
La prioridad de la capa de promoción es un valor que especifica el orden en el que se promociona el lector
de Aurora en la instancia de base de datos del escritor después de un error. Los valores válidos con de 0 a
15, donde 0 es la primera prioridad y 15 la última.
Para establecer la prioridad de la promoción para la instancia de base de datos del escritor en
tier-0, realice el siguiente procedimiento:
3. Elija una instancia de base de datos del lector del clúster de base de datos de Aurora PostgreSQL que
sea la misma clase de instancia que la instancia de base de datos del escritor.
4. Elija Modify. Aparece la página Modify DB Instance.
5. En el panel Failover (Conmutación por error), elija tier-0 para Priority (Prioridad).
7. Para aplicar los cambios inmediatamente después de guardarlos, elija Apply immediately (Aplicar
inmediatamente).
8. Seleccione Modify DB Instance (Modificar instancia de base de datos) para guardar los cambios.
AWS CLI
Para configurar la prioridad de la capa de promoción en 0 para la instancia de base de datos del lector
mediante la AWS CLI, invoque el comando modify-db-instance con los siguientes parámetros necesarios:
• --promotion-tier
• --apply-immediately
Example

--db-instance-identifier reader-db-instance \
--promotion-tier 0 \
--apply-immediately
Para Windows:

--db-instance-identifier reader-db-instance ^
---promotion-tier 0 ^
--apply-immediately
Supervisión de la caché del búfer

Después de configurar la gestión de la caché del clúster, podrá monitorizar el estado de la sincronización
entre la caché del búfer de la instancia de base de datos del escritor y la caché del búfer en caliente
del lector designado. Para examinar el contenido de la caché del búfer en la instancia de base de datos

834
Actualización de la versión del motor
del escritor y la instancia de base de datos del lector designada, utilice el módulo pg_buffercache
de PostgreSQL. Para obtener más información, consulte la documentación de PostgreSQL sobre
pg_buffercache.
Uso de la función aurora_ccm_status
La administración de la caché del clúster también proporciona la función aurora_ccm_status. Utilice

la función aurora_ccm_status en la instancia de base de datos del escritor para obtener la siguiente
información sobre el progreso del calentamiento de la caché en el lector designado:
• buffers_sent_last_minute: la cantidad de búferes enviados al lector designado en el último

minuto.
• buffers_sent_last_scan: la cantidad de búferes enviados al lector designado durante el último
análisis completo de la caché del búfer.
• buffers_found_last_scan: la cantidad de búferes identificados como de acceso frecuente y
que tienen que enviarse durante el último análisis completo de la caché del búfer. Los búferes ya
almacenados en la caché en el lector designado no se envían.
• buffers_sent_current_scan: la cantidad de búferes enviados hasta el momento durante el análisis
actual.
• buffers_found_current_scan: la cantidad de búferes identificados como de acceso frecuente en el
análisis actual.
• current_scan_progress: la cantidad de búferes visitados hasta el momento durante el análisis
actual.
En el siguiente ejemplo se muestra cómo utilizar la función aurora_ccm_status para convertir algunos
de sus resultados en una tasa templada y un porcentaje templado.
SELECT buffers_sent_last_minute*8/60 AS warm_rate_kbps,

100*(1.0-buffers_sent_last_scan/buffers_found_last_scan) AS warm_percent
FROM aurora_ccm_status();
Actualización de una versión del motor de un

clúster de base de datos de Aurora PostgreSQL
Amazon Aurora proporciona versiones posteriores de cada motor de base de datos compatible, por lo que
puede mantener el clúster al día. Las nuevas versiones pueden incluir correcciones de errores, mejoras de
seguridad y otras mejoras para el motor de base de datos. Cuando Amazon Aurora es compatible con una
nueva versión de un motor de base de datos, puede elegir cuándo y cómo actualizar sus clústeres de base
de datos.
Hay dos tipos de actualizaciones: actualizaciones de versiones principales y actualizaciones de versiones

secundarias. En general, una actualización de la versión principal del motor puede introducir cambios
incompatibles con las aplicaciones existentes. Por contraste, una actualización de una versión secundaria
solo incluye cambios compatibles con las versiones anteriores de las aplicaciones.
La secuencia del número de versión es específica para cada motor de base de datos. Por ejemplo,
Aurora PostgreSQL 9.6 y 10.5 son versiones principales del motor, y la actualización de cualquier versión
9.6 a cualquier versión 10.x es una actualización de versión principal. Las versiones 9.6.8 y 9.6.9 de
Aurora PostgreSQL son versiones secundarias, y la actualización de 9.6.8 a 9.6.9 es una actualización
de versiones secundarias. Para determinar la versión de un clúster de base de datos de Aurora, siga las
instrucciones de Actualizaciones de Amazon Aurora (p. 361).

835
Actualización manual de la versión del motor
Temas
• Actualización manual de la versión del motor (p. 836)
• Actualización automática de la versión secundaria del motor (p. 837)
Actualización manual de la versión del motor

Para realizar una actualización de versiones secundarias de un clúster de base de datos de Aurora
PostgreSQL, utilice las siguientes instrucciones para la Consola de administración de AWS, la AWS CLI
o la API de RDS. Actualmente Aurora PostgreSQL no es compatible con las actualizaciones de versiones
principales in situ. Sin embargo, puede migrar de una versión principal a otro utilizando herramientas de
carga y de volcado como las utilidades de PostgreSQL pg_dump y pg_restore.
Actualizar la versión del motor de un clúster de base de datos con la consola

Para actualizar la versión del motor de un clúster de base de datos con la consola
2. En el panel de navegación, elija Databases (Bases de datos) y, a continuación, elija el clúster de base
de datos que desea actualizar.
3. Elija Modify. Aparece la página Modify DB cluster (Modificar clúster de base de datos).
4. Para DB engine version, elija la nueva versión.
6. Para aplicar los cambios inmediatamente, elija Apply immediately. Si se selecciona esta opción, puede
producirse una interrupción en algunos casos. Para obtener más información, consulte Modificación de
7. En la página de confirmación, revise los cambios. Si son correctos, elija Modify Cluster (Modificar
clúster) para guardarlos.
Actualizar la versión del motor de un clúster de base de datos con la AWS CLI
Para actualizar la versión del motor de un clúster de base de datos, utilice el comando modify-db-cluster de
la CLI. Especifique los siguientes parámetros:

• --engine-version: número de versión del motor de base de datos al que se va a actualizar. Para
obtener información sobre versiones de motores válidas, utilice el comando describe-db-engine-versions
de la AWS CLI.
• --no-apply-immediately: para aplicar los cambios en la siguiente ventana de mantenimiento. Para
aplicar los cambios inmediatamente, use --apply-immediately.
Example

--engine-version new_version \

836
Actualización automática de la versión secundaria del motor
Para Windows:

--engine-version new_version ^
Actualizar la versión del motor de un clúster de base de datos con la API de RDS
Para actualizar la versión del motor de un clúster de base de datos, utilice la acción ModifyDBCluster.
Especifique los siguientes parámetros:
• DBClusterIdentifier: nombre del clúster de base de datos, por ejemplo, mydbcluster.

• EngineVersion: número de versión del motor de base de datos al que se va a actualizar. Para obtener
información sobre versiones de motores válidas, utilice la operación DescribeDBEngineVersions.
• ApplyImmediately: indica si se deben aplicar los cambios inmediatamente o en la siguiente ventana
de mantenimiento. Para aplicar los cambios inmediatamente, establezca el valor en true. Para aplicar
los cambios en el siguiente periodo de mantenimiento, establezca el valor en false.
Actualización automática de la versión secundaria del

motor
Una versión secundaria del motor es una actualización de una versión del motor de base de datos dentro
de una versión principal del motor. Por ejemplo, una versión principal del motor podría ser la 5.7 y contener
las versiones secundarias del motor 5.7.22 y 5.7.23.
Si quiere que Amazon Aurora actualice la versión del motor de base de datos de una base de datos
automáticamente, puede habilitar las actualizaciones de versiones secundarias automáticamente para la
base de datos. Cuando se designa una versión secundaria del motor como versión secundaria del motor
preferida, cada base de datos que reúna las dos siguientes condiciones se actualiza automáticamente a la
versión secundaria del motor:
• La base de datos ejecuta una versión secundaria del motor de la base de datos menor que la versión
secundaria del motor preferida.
• La base de datos tiene habilitadas las actualizaciones automáticas de versiones secundarias.
Puede controlar si las actualizaciones automáticas de versiones secundarias están habilitadas para una
instancia de base de datos al realizar las siguientes tareas:
• Creación de un clúster de base de datos de Amazon Aurora (p. 85)

• Modificación de un clúster de base de datos de Amazon Aurora (p. 235)
Note
Modifique la instancia de base de datos de escritor para controlar si las actualizaciones

automáticas de versiones secundarias están habilitadas para todo el clúster de base de datos.
• Restauración de un clúster de base de datos desde una instantánea (p. 319)
Note
Al restaurar un clúster de base de datos desde una instantánea, puede controlar si las
actualizaciones automáticas de versiones secundarias están habilitadas para el clúster de base
de datos únicamente al usar la consola.
• Restauración de un clúster de base de datos a un momento especificado (p. 338)

837
Prácticas recomendadas con Aurora PostgreSQL
Note
Al restaurar un clúster de base de datos a un momento específico, puede controlar si las

actualizaciones automáticas de versiones secundarias están habilitadas para el clúster de base
de datos únicamente al usar la consola.
A realizar estas tareas, puede controlar si está habilitada la actualización automática de versiones
secundarias para el clúster de la base de datos de las siguientes formas:
• Con la consola, establezca la opción Auto minor version upgrade (Actualización automática de versiones
secundarias).
• Con la AWS CLI, establezca la opción --auto-minor-version-upgrade|--no-auto-minor-
version-upgrade.
• Con la API de RDS, establezca el parámetro AutoMinorVersionUpgrade.
Puede recibir una notificación de evento de Amazon RDS cuando esté disponible una nueva actualización
de la versión secundaria del motor para una de sus bases de datos. Para recibir notificaciones, suscríbase
a la notificación de eventos de Amazon RDS mediante Amazon Simple Notification Service (Amazon SNS).
Para obtener más información, consulte Uso de las notificaciones de eventos de Amazon RDS (p. 465).
Para determinar si una actualización de mantenimiento, como una actualización de la versión del motor de
base de datos, está disponible para su clúster de base de datos, puede utilizar la consola, la AWS CLI o la
API de RDS. También puede actualizar manualmente la versión de la base de datos y ajustar el periodo de
mantenimiento. Para obtener más información, consulte Mantenimiento de un clúster de base de datos de
Prácticas recomendadas con Amazon Aurora

PostgreSQL
En este tema se proporciona información acerca de las prácticas recomendadas y las opciones para usar o
migrar datos en un clúster de base de datos de Amazon Aurora PostgreSQL.
Conmutación por error rápida con Amazon Aurora

PostgreSQL
Puede hacer varias cosas para que una conmutación por error tenga un desempeño más rápido con
Aurora PostgreSQL. En esta sección se explica cada una de ellas:
• Establezca, agresivamente, paquetes keepalive de TCP para asegurarse de que las consultas que se
ejecutan durante más tiempo y siguen a la espera de una respuesta del servidor se cancelen antes de
que venza el tiempo de espera de lectura en caso de producirse un error.
• Establezca, agresivamente, los tiempos de inactividad de la caché de DNS de Java para garantizar que
el punto de conexión de solo lectura de Aurora pueda desplazarse correctamente por nodos de solo
lectura en posteriores intentos de conexión.
• Establezca las variables de tiempo de inactividad, que se utilizan en la cadena de la conexión de JDBC,
con los valores más bajos posibles. Utilice objetos de conexión independientes para consultas de
ejecución corta y prolongada.
• Utilice los puntos de enlace de Aurora de lectura y escritura que se proporcionan para establecer una
conexión al clúster.

838
Conmutación por error rápida
• Utilice las API de RDS para probar la respuesta de la aplicación ante errores del lado del servidor.
Asimismo, puede usar una herramienta para supresión de paquetes para probar la respuesta de la
aplicación ante errores del lado del cliente.
Configuración de parámetros Keepalive de TCP

El proceso keepalive de TCP es sencillo: cuando configura una conexión TCP, asocia una serie de
temporizadores. Cuando el temporizador keepalive llega a cero, usted envía un paquete de sondeo
keepalive. Si recibe una respuesta a su sondeo keepalive, puede presuponer que la conexión sigue en
funcionamiento.
Al habilitar parámetros keepalive de TCP y configurarlos agresivamente, se garantiza que si su cliente ya

no puede conectarse a la base de datos, se cierra rápidamente cualquier conexión activa. Esta acción
permite a la aplicación reaccionar de manera apropiada, como por ejemplo a la hora de elegir un host
nuevo al que conectarse.
Es necesario establecer los siguientes parámetros keepalive de TCP:
• tcp_keepalive_time controla el tiempo, en segundos, después del cual se envía un paquete

keepalive si el socket no ha enviado datos (los ACK no se consideran datos). Recomendamos la
siguiente configuración:
tcp_keepalive_time = 1
• tcp_keepalive_intvl controla el tiempo, en segundos, entre el envío de posteriores
paquetes keepalive después de que se envía el paquete inicial (configúrelo con el parámetro
tcp_keepalive_time). Recomendamos la siguiente configuración:
tcp_keepalive_intvl = 1
• tcp_keepalive_probes es la cantidad de sondeos keepalive sin confirmar que tienen lugar antes de
que se produzca la notificación a la aplicación. Recomendamos la siguiente configuración:
tcp_keepalive_probes = 5
Esta configuración debería realizar una notificación a la aplicación en un plazo de cinco segundos cuando
la base de datos deja de responder. Es posible configurar un valor de tcp_keepalive_probes más elevado
si los paquetes keepalive se suprimen con frecuencia dentro de la red de la aplicación. Esto posteriormente
incrementa el tiempo que se tarda en detectar un error real, pero ofrece más capacidad de búfer en redes
de menos confianza.
Configuración de parámetros keepalive de TCP en Linux
1. Le recomendamos que, cuando pruebe el modo de configurar parámetros keepalive de TCP, lo haga
mediante la línea de comando con los siguientes comandos: tenga en cuenta que esta configuración
sugerida es para todo el sistema, lo cual significa que afecta al resto de aplicaciones que crean
sockets con la opción SO_KEEPALIVE activada.
sudo sysctl net.ipv4.tcp_keepalive_time=1

sudo sysctl net.ipv4.tcp_keepalive_intvl=1
sudo sysctl net.ipv4.tcp_keepalive_probes=5
2. Una vez que ha encontrado una configuración que funciona para su aplicación, esta configuración
debe almacenarse de forma persistente agregando las siguientes líneas (incluido cualquier cambio
realizado) a /etc/sysctl.conf:
tcp_keepalive_time = 1
tcp_keepalive_intvl = 1

839
tcp_keepalive_probes = 5
Para obtener información sobre la configuración de parámetros keepalive de TCP en Windows, consulte
Things You May Want to Know About TCP Keepalive.
Configuración de su aplicación para una conmutación por error

rápida
Esta sección trata sobre varios cambios de configuración específicos para Aurora PostgreSQL. La
documentación para la instalación y la configuración general del controlador JDBC está disponible a través
del sitio JDBC de PostgreSQL.
Reducción de los tiempos de espera de la caché de DNS

Cuando su aplicación trata de establecer una conexión después de una conmutación por error, el nuevo
escritor Aurora PostgreSQL será un lector anterior, que puede encontrarse mediante el punto de enlace
read only (solo lectura) de Aurora, antes de que las actualizaciones de DNS se hayan propagado por
completo. Establecer el TTL de DNS de Java en un valor bajo ayuda a desplazarse por los nodos del lector
en intentos de conexión posteriores.
// Sets internal TTL to match the Aurora RO Endpoint TTL

java.security.Security.setProperty("networkaddress.cache.ttl" , "1");
// If the lookup fails, default to something like small to retry
java.security.Security.setProperty("networkaddress.cache.negative.ttl" , "3");
Configuración de una cadena de conexión de Aurora PostgreSQL para

conmutaciones por error rápidas
Para hacer uso de la conmutación por error rápida de Aurora PostgreSQL, la cadena de conexión de su
aplicación debería tener una lista de hosts (destacado en negrita en el siguiente ejemplo) en lugar de un
solo host. Mostramos aquí una cadena de conexión de ejemplo que podría utilizar para conectarse a un
clúster de Aurora PostgreSQL:
jdbc:postgresql://myauroracluster.cluster-c9bfei4hjlrd.us-east-1-
beta.rds.amazonaws.com:5432,
myauroracluster.cluster-ro-c9bfei4hjlrd.us-east-1-beta.rds.amazonaws.com:5432
/postgres?user=<masteruser>&password=<masterpw>&loginTimeout=2
&connectTimeout=2&cancelSignalTimeout=2&socketTimeout=60
&tcpKeepAlive=true&targetServerType=master&loadBalanceHosts=true
Para una mejor disponibilidad y evitar depender de una API de RDS, la mejor opción para conectarse
es mantener un archivo con una cadena de host desde la que su aplicación lee cuando establece una
conexión a la base de datos. Esta cadena de host tendrá todos los puntos de enlace de Aurora disponibles
para el clúster. Para obtener más información acerca de los puntos de enlace de Aurora, consulte
Administración de conexiones de Amazon Aurora (p. 3). Por ejemplo, podría almacenar los puntos de
enlace en un archivo localmente, como el siguiente:
myauroracluster.cluster-c9bfei4hjlrd.us-east-1-beta.rds.amazonaws.com:5432,
Su aplicación realizará una lectura de este archivo para rellenar la sección host de la cadena de conexión
de JDBC. Cambiar el nombre del clúster de base de datos hace que estos puntos de enlace cambien;
asegúrese de que su aplicación controle ese evento si se produjera.
Otra opción consiste en usar una lista de nodos de instancia de base de datos:

840
my-node1.cksc6xlmwcyw.us-east-1-beta.rds.amazonaws.com:5432,
my-node4.cksc6xlmwcyw.us-east-1-beta.rds.amazonaws.com:5432
El beneficio de este enfoque es que el controlador de la conexión JDBC de PostgreSQL recorrerá todos los
nodos de esta lista para encontrar una conexión válida, mientras que al usar puntos de enlace de Aurora
solo se probarán dos nodos en cada intento de conexión. El inconveniente de usar nodos de instancia
de base de datos es que si agrega o elimina nodos de su clúster y la lista de puntos de enlace de la
instancia se queda obsoleta, el controlador de la conexión podría no encontrar nunca el host correcto al
que conectarse.
Configurar los siguientes parámetros, de manera agresiva, contribuye a garantizar que su aplicación no
tenga que esperar demasiado para conectarse a cualquier host.
• loginTimeout: controla cuánto tiempo espera su aplicación para iniciar sesión en la base de datos
después de que se ha establecido una conexión de socket.
• connectTimeout: controla cuánto tiempo espera el socket para establecer una conexión con la base
de datos.
Es posible modificar otros parámetros de la aplicación para acelerar el proceso de conexión, dependiendo
del grado de agresividad deseado.
• cancelSignalTimeout: en algunas aplicaciones, sería conveniente enviar algún tipo de señal de

cancelación para una consulta cuyo tiempo se haya agotado. Si esta señal de cancelación se encuentra
en su ruta de conmutación por error, debería plantearse configurarla agresivamente para evitar enviar
esta señal a un host inoperativo.
• socketTimeout: este parámetro controla cuánto tiempo espera el socket a que se produzcan las
operaciones de lectura. Es posible usar este parámetro como tiempo de espera de consulta "global"
para garantizar que nunca se supere este valor. Una buena práctica consiste en tener un controlador
de conexiones que ejecute consultas con una vida útil corta y establezca un valor más bajo y, al mismo
tiempo, tener otro controlador con una vida útil larga y un valor más elevado. De este modo, puede
confiar en que los parámetros keepalive de TCP cancelen consultas en ejecución prolongada si el
servidor deja de funcionar.
• tcpKeepAlive: habilite este parámetro para asegurarse de que se respeten los parámetros keepalive
de TCP configurados.
• targetServerType: puede usarse este parámetro para controlar si el controlador se conecta a un
nodo de lectura (esclavo) o de escritura (principal). Los posibles valores son: any, master, slave y
preferSlave. El valor preferSlave intenta establecer una conexión con un lector en primer lugar,
pero utiliza el escritor y se conecta a él si no es posible establecer una conexión con el lector.
• loadBalanceHosts: cuando se establece en true, este parámetro hace que la aplicación se conecte
a un host aleatorio elegido entre una lista de hosts candidatos.
Otras opciones para la obtención de la cadena de host

Puede obtener la cadena de host de diferentes lugares, entre incluida la función
aurora_replica_status, y mediante la API de Amazon RDS.
Su aplicación puede conectarse a cualquier instancia de base de datos del clúster de base de datos
y consultar la función aurora_replica_status para determinar quién es el escritor del clúster
o para encontrar cualquier otro nodo lector del clúster. Puede utilizar esta función para reducir la
cantidad de tiempo que se tarda en encontrar un host al que conectarse, si bien en ciertos casos la
función aurora_replica_status podría mostrar información obsoleta o incompleta en determinadas
situaciones de error de la red.

841
Una buena manera de garantizar que su aplicación puede encontrar un nodo al que conectarse es
intentando conectarse al punto de conexión del escritor del clúster y, a continuación, al punto de conexión
del lector del clúster hasta que pueda establecer una conexión legible. Estos puntos de enlace no cambian
a menos que modifique el nombre de su clúster de base de datos. En general, pueden dejarse como
miembros estáticos de su aplicación o almacenarse en un archivo de recursos desde el cual lea dicha
aplicación.
Una vez que se establece una conexión con uno de estos puntos de enlace, puede llamar a la función
aurora_replica_status para obtener información sobre el resto del clúster. Por ejemplo, el siguiente
comando obtiene información con la función aurora_replica_status.
postgres=> select server_id, session_id, highest_lsn_rcvd,

cur_replay_latency_in_usec, now(), last_update_timestamp from
aurora_replica_status();
server_id | session_id |
vdl | highest_lsn_rcvd | cur_replay_latency |
now | last_update_time
-----------------------------------+---------------------------
-----------+-----------+------------------+--------------------+-
------------------------------+-------
mynode-1 | 3e3c5044-02e2-11e7-b70d-95172646d6ca |
594220999 | 594221001 | 201421 | 2017-03-07
19:50:24.695322+00 | 2017-03-07 19:50:23+00
mynode-2 | 1efdd188-02e4-11e7-becd-f12d7c88a28a |
594220999 | 594221001 | 201350 | 2017-03-07
19:50:24.695322+00 | 2017-03-07 19:50:23+00
mynode-3 | MASTER_SESSION_ID |
594220999 | | | 2017-03-07
19:50:24.695322+00 | 2017-03-07 19:50:23+00
(3 rows)
Así por ejemplo, la sección hosts de su cadena de conexión podría empezar con los puntos de enlace del
clúster del escritor y del lector:
myauroracluster.cluster-c9bfei4hjlrd.us-east-1-beta.rds.amazonaws.com:5432,
Ante esta situación, su aplicación tratará de establecer una conexión a cualquier tipo de nodo, principal o
esclavo. Una vez que se ha conectado, una buena práctica consiste en examinar en primer lugar el estado
de lectura-escritura del nodo consultando el resultado del comando SHOW transaction_read_only.
Si el valor de retorno de la consulta es OFF, significa que se ha conectado correctamente al

nodo principal. Si el valor de retorno es ON y su aplicación requiere una conexión de lectura-
escritura, puede llamar a la función aurora_replica_status para determinar el server_id con
session_id='MASTER_SESSION_ID'. Esta función le proporciona el nombre del nodo principal. Puede
utilizar esto junto con "endpointPostfix", que se describe a continuación.
Un aspecto al que hay que estar atento es cuando se conecta a una réplica que tiene datos obsoletos.
Cuando esto ocurre, la función aurora_replica_status podría mostrar información desfasada. Es
posible establecer un umbral de obsolescencia en el nivel de la aplicación y examinarlo analizando la
diferencia entre la hora del servidor y la hora de la última actualización (last_update_time). En general,
su aplicación debería evitar estar entre dos hosts debido a la información en conflicto que devuelve
la función aurora_replica_status. Es decir, su aplicación debería pecar por exceso a la hora de probar
todos los hosts conocidos en primer lugar en vez de seguir ciegamente los datos devueltos por la función
aurora_replica_status.
API
Puede encontrar, mediante programación, la lista de instancias con AWS SDK para Java, concretamente
con la API DescribeDbClusters. Se muestra aquí un breve ejemplo de cómo podría hacer esto en Java 8:

842
AmazonRDS client = AmazonRDSClientBuilder.defaultClient();

DescribeDBClustersRequest request = new DescribeDBClustersRequest()
.withDBClusterIdentifier(clusterName);
DescribeDBClustersResult result =
rdsClient.describeDBClusters(request);
DBCluster singleClusterResult = result.getDBClusters().get(0);
String pgJDBCEndpointStr =
singleClusterResult.getDBClusterMembers().stream()
.sorted(Comparator.comparing(DBClusterMember::getIsClusterWriter)
.reversed()) // This puts the writer at the front of the list
.map(m -> m.getDBInstanceIdentifier() + endpointPostfix + ":" +
singleClusterResult.getPort()))
.collect(Collectors.joining(","));
pgJDBCEndpointStr contendrá una lista con formato de puntos de enlace, por ejemplo:
my-node2.cksc6xlmwcyw.us-east-1-beta.rds.amazonaws.com:5432
La variable "endpointPostfix" puede ser una constante establecida por su aplicación, o bien puede
obtenerse consultando la API DescribeDBInstances en una instancia individual del clúster. Este valor
permanece constante dentro de una región y para un cliente individual, por lo que no sería necesaria una
llamada a la API si mantiene este valor en un archivo de recursos que pueda leer su aplicación. En el
ejemplo anterior, se establecería en:
.cksc6xlmwcyw.us-east-1-beta.rds.amazonaws.com
Para fines de disponibilidad, una buena práctica sería utilizar, de manera predeterminada, los puntos de
enlace de Aurora de su clúster de base de datos si la API no responde o tarda demasiado en responder.
Se garantiza que los puntos de enlace estén actualizados en el tiempo que se tarda en actualizar el
registro de DNS (habitualmente menos de 30 segundos). Esto se puede almacenar de nuevo en un archivo
de recursos que su aplicación consume.
Prueba de conmutación por error

En todos los casos, debe tener un clúster de base de datos con un valor >= 2 instancias de base de datos
en él.
Desde el lado del servidor, algunas API pueden causar una interrupción del servicio que se puede usar
para probar cómo responden sus aplicaciones:
• FailoverDBCluster: tratará de promover a escritor una instancia de base de datos nueva en su clúster de
base de datos
public void causeFailover() {

/*
* See http://docs.aws.amazon.com/sdk-for-java/v1/developer-guide/basics.html for
more details on setting up an RDS client
*/
final AmazonRDS rdsClient = AmazonRDSClientBuilder.defaultClient();
FailoverDBClusterRequest request = new FailoverDBClusterRequest();

request.setDBClusterIdentifier("cluster-identifier");
rdsClient.failoverDBCluster(request);
}

843
• RebootDBInstance: la conmutación por error no está garantizada en esta API. No obstante, desactivará
la base de datos en el escritor y puede usarse para probar cómo responde su aplicación ante la
supresión de conexiones, (tenga en cuenta que el parámetro ForceFailover no es aplicable en motores
Aurora y debería usar la API FailoverDBCluster en su lugar)
• ModifyDBCluster: la modificación del puerto causará una interrupción cuando los nodos del clúster
comiencen a escuchar en un puerto nuevo. En general, su aplicación puede responder a este error
garantizando que únicamente ella controle los cambios de puerto y pueda actualizar debidamente
los puntos de enlace de los que depende. Otras posibilidades consisten en que alguien actualice
manualmente el puerto cuando se hagan modificaciones en el nivel de la API, o bien que se realicen
consultas a la API de RDS en su aplicación para determinar si el puerto ha cambiado.
• ModifyDBInstance: si se modifica DBInstanceClass, se provocará una interrupción
• DeleteDBInstance: si se elimina el maestro/escritor, provocará que una nueva instancia de base de
datos se promueva a escritor en su clúster de base de datos
Desde el lado de la aplicación/cliente, si está utilizando Linux, puede probar cómo responde la aplicación
ante supresiones repentinas de paquetes en función del puerto, del host o si no se envían o reciben
paquetes keepalive de TCP mediante iptables.
Ejemplo de conmutaciones por error rápidas

El siguiente ejemplo de código ilustra cómo una aplicación podría configurar un administrador del
controlador de Aurora PostgreSQL. La aplicación llamará a getConnection(...) cuando necesite
una conexión. Es posible que una llamada a esa función no encuentre un host válido, por ejemplo, si
no se encuentra ningún escritor, pero targetServerType se ha establecido en "master". En tal caso, la
aplicación que realiza la llamada simplemente vuelve a intentarlo. Esto puede integrarse fácilmente en
un concentrador de conexiones para evitar forzar el reintento hacia la aplicación. La mayoría de los
concentradores de conexiones le permiten especificar una cadena de conexión de JDBC, por lo que su
aplicación podría llamar a getJdbcConnectionString(...) y pasarla al concentrador para usar una
conmutación por error más rápida en Aurora PostgreSQL.
import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.SQLException;
import java.sql.Statement;
import java.util.ArrayList;
import java.util.stream.Collectors;
import java.util.stream.IntStream;
import org.joda.time.Duration;
public class FastFailoverDriverManager {

private static Duration LOGIN_TIMEOUT = Duration.standardSeconds(2);
private static Duration CONNECT_TIMEOUT = Duration.standardSeconds(2);
private static Duration CANCEL_SIGNAL_TIMEOUT = Duration.standardSeconds(1);
private static Duration DEFAULT_SOCKET_TIMEOUT = Duration.standardSeconds(5);
public FastFailoverDriverManager() {
try {
Class.forName("org.postgresql.Driver");
} catch (ClassNotFoundException e) {
e.printStackTrace();
}
/*
* RO endpoint has a TTL of 1s, we should honor that here. Setting this
aggressively makes sure that when
* the PG JDBC driver creates a new connection, it will resolve a new different RO
endpoint on subsequent attempts

844
* (assuming there is > 1 read node in your cluster)

*/
java.security.Security.setProperty("networkaddress.cache.ttl" , "1");
// If the lookup fails, default to something like small to retry
java.security.Security.setProperty("networkaddress.cache.negative.ttl" , "3");
}
public Connection getConnection(String targetServerType) throws SQLException {

return getConnection(targetServerType, DEFAULT_SOCKET_TIMEOUT);
}
public Connection getConnection(String targetServerType, Duration queryTimeout) throws

SQLException {
Connection conn =
DriverManager.getConnection(getJdbcConnectionString(targetServerType, queryTimeout));
/*
* A good practice is to set socket and statement timeout to be the same thing
since both
* the client AND server will kill the query at the same time, leaving no running
queries
* on the backend
*/
Statement st = conn.createStatement();
st.execute("set statement_timeout to " + queryTimeout.getMillis());
st.close();
return conn;
}
private static String urlFormat = "jdbc:postgresql://%s"

+ "/postgres"
+ "?user=%s"
+ "&password=%s"
+ "&loginTimeout=%d"
+ "&connectTimeout=%d"
+ "&cancelSignalTimeout=%d"
+ "&socketTimeout=%d"
+ "&targetServerType=%s"
+ "&tcpKeepAlive=true"
+ "&ssl=true"
+ "&loadBalanceHosts=true";
public String getJdbcConnectionString(String targetServerType, Duration queryTimeout) {
return String.format(urlFormat,
getFormattedEndpointList(getLocalEndpointList()),
CredentialManager.getUsername(),
CredentialManager.getPassword(),
LOGIN_TIMEOUT.getStandardSeconds(),
CONNECT_TIMEOUT.getStandardSeconds(),
CANCEL_SIGNAL_TIMEOUT.getStandardSeconds(),
queryTimeout.getStandardSeconds(),
targetServerType
);
}
private List<String> getLocalEndpointList() {

/*
* As mentioned in the best practices doc, a good idea is to read a local resource
file and parse the cluster endpoints.
* For illustration purposes, the endpoint list is hardcoded here
*/
List<String> newEndpointList = new ArrayList<>();
newEndpointList.add("myauroracluster.cluster-c9bfei4hjlrd.us-east-1-
beta.rds.amazonaws.com:5432");
newEndpointList.add("myauroracluster.cluster-ro-c9bfei4hjlrd.us-east-1-
beta.rds.amazonaws.com:5432");

845
Solución de problemas de almacenamiento
return newEndpointList;
}
private static String getFormattedEndpointList(List<String> endpoints) {

return IntStream.range(0, endpoints.size())
.mapToObj(i -> endpoints.get(i).toString())
.collect(Collectors.joining(","));
}
}
Solución de problemas de almacenamiento

Si la cantidad de memoria necesaria por una operación de ordenación o creación de índices supera la
cantidad de memoria disponible, Aurora PostgreSQL escribe los datos por encima de este límite en el
espacio de almacenamiento. Cuando escribe los datos, usa el mismo espacio de almacenamiento que
para almacenar los logs de errores y mensajes. Si las funciones de ordenación o creación de índices
superan la memoria disponible, podría quedarse sin espacio de almacenamiento local. Si tiene problemas
con la falta de espacio de almacenamiento para Aurora PostgreSQL, puede volver a configurar las
funciones de ordenación de datos para que usen más memoria o reducir el periodo de retención de datos
de sus archivos de registro de PostgreSQL. Para obtener más información acerca de cómo cambiar el
periodo de retención de los logs, consulte Archivos de registro de base de datos de PostgreSQL (p. 491).
Referencia de Amazon Aurora PostgreSQL

Parámetros de Amazon Aurora PostgreSQL
El clúster de base de datos Amazon Aurora se administra de la misma forma que otras instancias de
base de datos de Amazon RDS: utilizando los parámetros de un grupo de parámetros de base de datos.
Amazon Aurora difiere de otros motores de base de datos en que hay un clúster de base de datos que
contiene varias instancias de base de datos. Como resultado, algunos de los parámetros que se usan para
administrar el clúster de base de datos de Amazon Aurora afectan a todo el clúster, mientras que otros
parámetros solo afectan a una instancia de base de datos concreta del clúster de base de datos.
Los parámetros de nivel de clúster se administran en los grupos de parámetros de clúster de base de
datos. Los parámetros de nivel de instancia se administran en los grupos de parámetros de base de
datos. Aunque cada instancia de base de datos de un clúster de base de datos de Aurora PostgreSQL
es compatible con el motor de base de datos PostgreSQL, algunos de los parámetros del motor de base
de datos PostgreSQL se deben aplicar en el nivel de clúster y se administran usando los grupos de
parámetros de clúster de base de datos. Los parámetros de nivel de clúster no se encuentran en el grupo
de parámetros de base de datos para una instancia de base de datos de un clúster de base de datos de
Aurora PostgreSQL y se enumeran más adelante en este tema.
Puede administrar tanto los parámetros de nivel de clúster como los de nivel de instancia usando la
consola de Amazon RDS, la AWS CLI o la API de Amazon RDS. Hay comandos independientes para
administrar los parámetros de nivel de clúster y los parámetros de nivel de instancia. Por ejemplo, puede
usar el comando modify-db-cluster-parameter-group de la AWS CLI para administrar los parámetros de
nivel de clúster de un grupo de parámetros de clúster de base de datos y usar el comando modify-db-
parameter-group de la AWS CLI para administrar los parámetros de nivel de instancia de un grupo de
parámetros de base de datos para una instancia de base de datos un clúster de base de datos.
Puede ver tanto los parámetros de nivel de clúster como los de nivel de instancia en la consola de Amazon
RDS o usando la AWS CLI o la API de Amazon RDS. Por ejemplo, puede usar el comando describe-db-
cluster-parameters de la AWS CLI para ver los parámetros de nivel de clúster de un grupo de parámetros
de clúster de base de datos y usar el comando describe-db-parameters de la AWS CLI para ver los

846
Parámetros
parámetros de nivel de instancia de un grupo de parámetros de base de datos para una instancia de base
de datos un clúster de base de datos.
Parámetros de nivel de clúster

En la siguiente tabla se muestran todos los parámetros que afectan a todo el clúster de base de datos
Aurora PostgreSQL.
Nombre del parámetro Modificable
apg_ccm_enabled Sí
archive_command No
archive_timeout No
array_nulls Sí
autovacuum Sí
autovacuum_analyze_scale_factor Sí
autovacuum_analyze_threshold Sí
autovacuum_freeze_max_age Sí
autovacuum_max_workers Sí
autovacuum_multixact_freeze_max_age Sí
autovacuum_naptime Sí
autovacuum_vacuum_cost_delay Sí
autovacuum_vacuum_cost_limit Sí
autovacuum_vacuum_scale_factor Sí
autovacuum_vacuum_threshold Sí
autovacuum_work_mem Sí
backslash_quote Sí
client_encoding Sí
data_directory No
datestyle Sí
default_tablespace Sí
default_with_oids Sí
extra_float_digits Sí
huge_pages No
intervalstyle Sí

847
Parámetros
lc_monetary Sí
lc_numeric Sí
lc_time Sí
log_autovacuum_min_duration Sí
max_prepared_transactions Sí
password_encryption No
port No
rds.enable_plan_management Sí
rds.extensions No
rds.force_autovacuum_logging_level Sí
rds.force_ssl Sí
rds.logical_replication Sí
rds.restrict_password_commands Sí
server_encoding No
ssl Sí
synchronous_commit Sí
timezone Sí
track_commit_timestamp Sí
vacuum_cost_delay Sí
vacuum_cost_limit Sí
vacuum_cost_page_hit Sí
vacuum_cost_page_miss Sí
vacuum_defer_cleanup_age Sí
vacuum_freeze_min_age Sí
vacuum_freeze_table_age Sí
vacuum_multixact_freeze_min_age Sí
vacuum_multixact_freeze_table_age Sí
wal_buffers Sí
Parámetros de nivel de instancia

En la siguiente tabla se muestran todos los parámetros que afectan a una instancia de base de datos
concreta de un clúster de base de datos Aurora PostgreSQL.

848
Parámetros
apg_plan_mgmt.capture_plan_baselines Sí
apg_plan_mgmt.max_databases Sí
apg_plan_mgmt.max_plans Sí
apg_plan_mgmt.pgss_min_calls Sí
apg_plan_mgmt.pgss_min_mean_time_ms Sí
apg_plan_mgmt.pgss_min_stddev_time_ms Sí
apg_plan_mgmt.pgss_min_total_time_ms Sí
apg_plan_mgmt.plan_retention_period Sí
apg_plan_mgmt.unapproved_plan_execution_threshold Sí
apg_plan_mgmt.use_plan_baselines Sí
application_name Sí
authentication_timeout Sí
auto_explain.log_analyze Sí
auto_explain.log_buffers Sí
auto_explain.log_format Sí
auto_explain.log_min_duration Sí
auto_explain.log_nested_statements Sí
auto_explain.log_timing Sí
auto_explain.log_triggers Sí
auto_explain.log_verbose Sí
auto_explain.sample_rate Sí
backend_flush_after Sí
bgwriter_flush_after Sí
bytea_output Sí
check_function_bodies Sí
checkpoint_flush_after Sí
checkpoint_timeout No
client_min_messages Sí
config_file No
constraint_exclusion Sí
cpu_index_tuple_cost Sí

849
Parámetros
cpu_operator_cost Sí
cpu_tuple_cost Sí
cursor_tuple_fraction Sí
db_user_namespace No
deadlock_timeout Sí
debug_pretty_print Sí
debug_print_parse Sí
debug_print_plan Sí
debug_print_rewritten Sí
default_statistics_target Sí
default_transaction_deferrable Sí
default_transaction_isolation Sí
default_transaction_read_only Sí
effective_cache_size Sí
effective_io_concurrency Sí
enable_bitmapscan Sí
enable_hashagg Sí
enable_hashjoin Sí
enable_indexonlyscan Sí
enable_indexscan Sí
enable_material Sí
enable_mergejoin Sí
enable_nestloop Sí
enable_seqscan Sí
enable_sort Sí
enable_tidscan Sí
escape_string_warning Sí
exit_on_error No
force_parallel_mode Sí
from_collapse_limit Sí
geqo Sí

850
Parámetros
geqo_effort Sí
geqo_generations Sí
geqo_pool_size Sí
geqo_seed Sí
geqo_selection_bias Sí
geqo_threshold Sí
gin_fuzzy_search_limit Sí
gin_pending_list_limit Sí
hba_file No
hot_standby_feedback Sí
ident_file No
idle_in_transaction_session_timeout Sí
join_collapse_limit Sí
lc_messages Sí
listen_addresses No
lo_compat_privileges No
log_connections Sí
log_destination Sí
log_directory No
log_disconnections Sí
log_duration Sí
log_error_verbosity Sí
log_executor_stats Sí
log_file_mode No
log_filename Sí
log_hostname Sí
log_line_prefix No
log_lock_waits Sí
log_min_duration_statement Sí
log_min_error_statement Sí
log_min_messages Sí

851
Parámetros
log_parser_stats Sí
log_planner_stats Sí
log_replication_commands Sí
log_rotation_age Sí
log_rotation_size Sí
log_statement Sí
log_statement_stats Sí
log_temp_files Sí
log_timezone No
log_truncate_on_rotation No
logging_collector No
maintenance_work_mem Sí
max_connections Sí
max_files_per_process Sí
max_locks_per_transaction Sí
max_replication_slots Sí
max_stack_depth Sí
max_standby_archive_delay No
max_standby_streaming_delay No
max_wal_senders Sí
max_worker_processes Sí
min_parallel_relation_size Sí
old_snapshot_threshold Sí
operator_precedence_warning Sí
parallel_setup_cost Sí
parallel_tuple_cost Sí
pg_hint_plan.debug_print Sí
pg_hint_plan.enable_hint Sí
pg_hint_plan.enable_hint_table Sí
pg_hint_plan.message_level Sí
pg_hint_plan.parse_messages Sí

852
Parámetros
pg_stat_statements.max Sí
pg_stat_statements.save Sí
pg_stat_statements.track Sí
pg_stat_statements.track_utility Sí
pgaudit.log Sí
pgaudit.log_catalog Sí
pgaudit.log_level Sí
pgaudit.log_parameter Sí
pgaudit.log_relation Sí
pgaudit.log_statement_once Sí
pgaudit.role Sí
postgis.gdal_enabled_drivers Sí
quote_all_identifiers Sí
random_page_cost Sí
rds.force_admin_logging_level Sí
rds.log_retention_period Sí
rds.rds_superuser_reserved_connections Sí
rds.superuser_variables No
replacement_sort_tuples Sí
restart_after_crash No
row_security Sí
search_path Sí
seq_page_cost Sí
session_replication_role Sí
shared_buffers Sí
shared_preload_libraries Sí
sql_inheritance Sí
ssl_ca_file No
ssl_cert_file No
ssl_ciphers No
ssl_key_file No

853
Parámetros
standard_conforming_strings Sí
statement_timeout Sí
stats_temp_directory No
superuser_reserved_connections No
synchronize_seqscans Sí
syslog_facility No
tcp_keepalives_count Sí
tcp_keepalives_idle Sí
tcp_keepalives_interval Sí
temp_buffers Sí
temp_tablespaces Sí
track_activities Sí
track_activity_query_size Sí
track_counts Sí
track_functions Sí
track_io_timing Sí
transaction_deferrable Sí
transaction_read_only Sí
transform_null_equals Sí
unix_socket_directories No
unix_socket_group No
unix_socket_permissions No
update_process_title Sí
wal_receiver_status_interval Sí
wal_receiver_timeout Sí
wal_sender_timeout Sí
work_mem Sí
xmlbinary Sí
xmloption Sí

854
Eventos de Amazon Aurora PostgreSQL
Eventos de Amazon Aurora PostgreSQL

He aquí algunos eventos de espera frecuentes de Aurora PostgreSQL.
BufferPin:BufferPin
En este evento de espera, una sesión está esperando para obtener acceso a un búfer de datos
durante un periodo en el que ninguna otra sesión puede examinar ese búfer. Las esperas de pines del
búfer pueden prolongarse si otro proceso contiene un cursor abierto que leyó por última vez datos del
búfer en cuestión.
Client:ClientRead
En este evento de espera, una sesión está recibiendo datos desde un cliente de la aplicación. Esta
espera podría ser habitual durante cargas de datos masivos mediante la instrucción COPY o para
aplicaciones que pasan datos a Aurora utilizando muchos recorridos de ida y vuelta entre el cliente y
la base de datos. Un número elevado de esperas de lecturas de clientes por transacción podría indicar
excesivos recorridos de ida y vuelta, como por ejemplo paso de parámetros. Debería comparar esto
con el número previsto de declaraciones por transacción.
IO:DataFilePrefetch
En este evento de espera, una sesión está esperando una captura previa asíncrona del
almacenamiento de Aurora.
IO:DataFileRead
En este evento de espera, una sesión está leyendo datos desde el almacenamiento de Aurora.
Podría tratarse de un evento de espera típico para cargas de trabajo intensivas de E/S. Las
instrucciones SQL que muestran una proporción comparativamente grande de este evento de espera
en comparación con otras instrucciones SQL podrían estar utilizando un plan de consultas ineficaz que
exige la lectura de grandes cantidades de datos.
IO:XactSync
En este evento de espera, una sesión está emitiendo una función de CONFIRMACIÓN o
RESTAURACIÓN, que exige la persistencia de los cambios de la actual transacción. Aurora; está
esperando a que el almacenamiento de Aurora confirme la persistencia.
Esta espera surge con frecuencia cuando se produce una alta tasa de actividad de confirmación
en el sistema. En ocasiones es posible aliviar esta espera modificando aplicaciones para confirmar
transacciones por lotes. Es posible que vea esta espera al mismo tiempo que la CPU espera en
un caso en el que la carga de la base de daos supera el número de CPU virtuales (vCPU) para
la instancia de base de datos. En este caso, la persistencia del almacenamiento podría estar
compitiendo por la CPU con cargas de trabajo de base de datos con un uso intensivo de la CPU. Para
mitigar esta situación, puede tratar de reducir esas cargas de trabajo o realizar un escalado vertical a
una instancia de base de datos con más vCPU.
Lock:transactionid
En este evento de espera, una sesión está tratando de modificar datos modificados por otra sesión
y está esperando la confirmación o la restauración de la transacción de la otra sesión. Es posible
investigar la sesiones de bloqueo y de espera en la vista pg_locks.
LWLock:buffer_content
En este evento de espera, una sesión está esperando para leer o escribir una página de datos en la
memoria mientras otra sesión bloquea esa página para la escritura. La contención intensa de escritura
para una sola página (página activa), debido a actualizaciones frecuentes del mismo fragmento de
dato por muchas sesiones, podría llevar a la prevalencia de este evento de espera. El uso excesivo
de limitaciones de claves externas podría aumentar la duración del bloqueo y, en consecuencia, a

855
Actualizaciones de Aurora PostgreSQL
un aumento de la contención. Deberían investigarse las cargas de trabajo con esperas elevadas
de buffer_content para el uso de limitaciones de claves externas con el fin de determinar si las
limitaciones son necesarias. Además, la reducción del fillfactor en la tabla principal distribuirá la clave
en una parte mayor del bloque y podrá reducir la contención en la página.
LWLock:SubtransControlLock
En este evento de espera, una sesión está buscando o manipulando la relación principal/secundaria
entre una transacción y una transacción secundaria. Las dos causas más habituales de uso de la
transacción secundaria son puntos de guardado y bloques de la excepción de PL/pgSQL. El evento de
espera puede ocurrir si se produce una consulta de datos elevada que se actualiza simultáneamente
desde las transacciones secundarias. Debe investigar si es posible reducir el uso de puntos de
guardado y de bloques de excepción, o reducir consultas concurrentes en las filas que se están
actualizando.
Para obtener una lista completa de eventos de espera de PostgreSQL, consulte la tabla de eventos de
espera de PostgreSQL.

En el siguiente tema, encontrará información sobre versiones y actualizaciones específicas de
Compatibilidad de Amazon Aurora con PostgreSQL. Para obtener más información sobre las
actualizaciones que se aplican de manera general a Aurora, consulte Actualizaciones de Amazon
Aurora (p. 361).
Temas
• Identificación de la versión de Amazon Aurora PostgreSQL (p. 856)
• Actualización de la versión del motor de Amazon Aurora PostgreSQL (p. 857)
• Versiones del motor de base de datos para Amazon Aurora PostgreSQL (p. 857)
Identificación de la versión de Amazon Aurora

PostgreSQL
Amazon Aurora incluye algunas características que son generales para Aurora y están disponibles para
todos los clústeres de base de datos Aurora. Aurora incluye otras características específicas de un
motor de base de datos en particular compatible con Aurora. Estas características están disponibles solo
para aquellos clústeres de base de datos Aurora que usan ese motor de base de datos, como Aurora
PostgreSQL.
Una instancia de base de datos Aurora; proporciona dos números de versión, el número de versión de
Aurora y el número de versión del motor de base de datos Aurora. Para obtener más información acerca
del número de versión de Aurora, consulte Versiones de Amazon Aurora (p. 361).
Para obtener el número de versión del motor de base de datos de Aurora para una instancia de base
de datos de Aurora PostgreSQL, realice una consulta mediante el parámetro de tiempo de ejecución
SERVER_VERSION. Para obtener el número de versión del motor de base de datos de Aurora, use la
consulta siguiente.
SHOW SERVER_VERSION;

856
Actualización
Actualización de la versión del motor de Amazon

Aurora PostgreSQL
Para obtener más información sobre la actualización de la versión del motor de Amazon Aurora
PostgreSQL, consulte Actualización de una versión del motor de un clúster de base de datos de Aurora
Versiones del motor de base de datos para Amazon

Aurora PostgreSQL
A continuación, puede encontrar información sobre las actualizaciones en el motor de base de datos de
Compatibilidad de Aurora con PostgreSQL.
La siguiente tabla muestra la versión de PostgreSQL con la que es compatible cada versión de Aurora
PostgreSQL.
Aurora con compatibilidad con PostgreSQL Versión de PostgreSQL compatible
Versión 2.3 (p. 857) 10.7
Versión 2.2 (p. 859) 10.6
Versión 2.1 (p. 860) 10.5
Versión 2.0 (p. 861) 10.4
Versión 1.5 (p. 862) 9.6.12
Versión 1.4 (p. 864) 9.6.11
Versión 1.3 (p. 865) 9.6.9
Versión 1.2 (p. 867) 9.6.8
Versión 1.1 (p. 869) 9.6.6 (obsoleto)
Versión 1.0 (p. 870) 9.6.3 (obsoleto)
Las siguientes actualizaciones estás disponibles para Aurora PostgreSQL.
Versión 2.3
Esta versión de Aurora PostgreSQL es compatible con PostgreSQL 10.7. Para obtener más información
acerca de las mejoras en la versión 10.7, consulte Versión 10.7 de PostgreSQL.
Versiones de parche
• Versión 2.3.3 (p. 857)
• Versión 2.3.1 (p. 858)
• Versión 2.3.0 (p. 858)
Versión 2.3.3
Puede encontrar las siguientes mejoras en esta actualización del motor.

857
Versiones del motor de Aurora PostgreSQL
Mejoras
1. Se ha proporcionado una corrección de adaptación para el problema de seguridad de la comunidad de

PostgreSQL CVE-2019-10130.
3. Se ha corregido un error en el que el streaming de la actividad de datos podría consumir un tiempo
excesivo en la CPU.
4. Se ha solucionado un error en el que los subprocesos paralelos que escanean el índice de árbol B
podrían bloquearse después de una lectura de disco.
5. Se ha solucionado un error en el que el uso del predicado not in en una expresión de tabla común
(CTE) podría devolver el siguiente error: "ERROR: bad levelsup for CTE" (ERROR: SUP de nivel
incorrecto para CTE).
6. Se ha solucionado un problema en el que el proceso de reproducción del nodo de lectura podía
bloquearse cuando se aplicaba una modificación en un índice del árbol de búsqueda generalizado
(GiST).
7. Se ha solucionado un problema en el que las páginas de asignación de visibilidad podían contener bits
de bloqueo incorrectos después de una conmutación por error en un nodo de lectura.
8. Se ha optimizado el tráfico de registro entre el nodo de escritura y nodos de lectura durante el
mantenimiento del índice.
9. Se ha solucionado un problema en el que las consultas sobre los nodos de lectura pueden bloquearse
cuando se realiza un examen del índice del árbol B.
10.Se ha solucionado un error en el que se podía bloquear una consulta que se ha optimizado para la
eliminación de uniones internas redundantes.
11.La función aurora_stat_memctx_usage informa ahora del número de instancias de un nombre de
contexto determinado.
12.Se ha solucionado un problema en el que la función aurora_stat_memctx_usage informaba de
resultados incorrectos.
13.Se ha solucionado un problema en el que el proceso de reproducción del nodo de lectura podía esperar
a que se cancelaran consultas conflictivas más allá del valor max_standby_streaming_delay
configurado.
14.La información adicional se registra ahora en los nodos de lectura cuando las conexiones activas entran
en conflicto con el proceso de retransmisión.
15.Se ha proporcionado una solución de adaptación para el error de la comunidad de PostgreSQL n.º
15677, en el que se podía producir un bloqueo cuando se eliminaba desde una tabla particionada.
Versión 2.3.1
Mejoras
1. Se han soluciona varios errores relacionados con la recuperación previa de E/S que ha producido el
bloqueo del motor.
Versión 2.3.0

858
1. Ahora Aurora PostgreSQL realiza una recuperación previa de E/S mientras examina los índices de árbol
B. Esto mejora significativamente el rendimiento de los exámenes de árbol B en los datos que no se han
recuperado.
Mejoras
1. Se ha solucionado un error que hacía que los nodos de lectura pudieran tener un error del tipo "se han
tomado demasiados LWLocks".
2. Se han abordado numerosos problemas que impedían que los nodos de lectura arrancaran cuando el
clúster tenía una carga de trabajo de escritura elevada.
3. Se ha solucionado un problema que hacía que el uso de la función aurora_stat_memctx_usage()
pudiera provocar un bloqueo.
4. Se ha mejorado la estrategia de sustitución de la caché que usan los exámenes de tabla para minimizar
las pérdidas de caché del búfer.
Versión 2.2
Versiones de parche
• Versión 2.2.1 (p. 859)
• Versión 2.2.0 (p. 860)
Versión 2.2.1
Mejoras
1. Estabilidad mejorada de replicación lógica.

2. Corrección de un error que podría provocar un error al ejecutar consultas. El mensaje informativo podría
ser: "El segmento CLOG 123 no existe: No existe ese archivo o directorio".
3. Aumento del tamaño compatible de contraseñas IAM a 8 KB.
4. Mejora de la coherencia del rendimiento en cargas de trabajo de escritura de alto rendimiento.
5. Corrección de un error que podía provocar que se bloqueara una réplica de lectura durante un reinicio.
ser: "ERROR DE SQL: Intentando leer el EOF pasado de relación".
7. Corrección de un error que podía provocar un aumento del uso de la memoria después de un reinicio.
8. Corrección de un error que podía provocar que se produjera un error en una transacción con un gran
número de subtransacciones.
9. Combinación de un parche de la comunidad PostgreSQL que soluciona posibles errores cuando
se utilizan índices GIN. Para obtener más información, consulte https://git.postgresql.org/gitweb/?
p=postgresql.git;a=commit;h=f9e66f2fbbb49a493045c8d8086a9b15d95b8f18.
10.Corrección de un error que podía provocar que se produjera un error al importar una instantánea de
RDS para PostgreSQL .

859
Versión 2.2.0
1. Adición de la característica de administración restringida de contraseñas. La característica de

administración restringida de contraseñas restringida le permite restringir quién puede administrar
contraseñas de usuarios y cambios en el vencimiento de las contraseñas mediante el parámetro
rds.restrict_password_commands y el rol rds_password. Para obtener más información,
consulte Restricción de la administración de contraseñas (p. 771).
Versión 2.1
Versiones de parche
• Versión 2.1.1 (p. 860)
• Versión 2.1.0 (p. 860)
Versión 2.1.1
Mejoras
9. Corrección de un error que podía provocar que se produjera un error al importar una instantánea de
Versión 2.1.0
1. Disponibilidad general de la administración de planes de consulta de Aurora, que permite a los clientes
controlar y administrar los planes de consulta que utilizan sus aplicaciones, controlar la selección de
planes del optimizador de consultas y garantizar un rendimiento de la aplicación alto y estable. Para

860
obtener más información, consulte Administración de planes de ejecución de consultas para Aurora
2. Actualización de la extensión libprotobuf a la versión 1.3.0. Esto lo utiliza la extensión PostGIS.
3. Actualización de la extensión pg_similarity a la versión 1.0.
4. Actualización de la extensión log_fdw a la versión 1.1.
5. Actualización de la extensión pg_hint_plan a la versión 1.3.1.
Mejoras
1. El tráfico de red entre el nodo de escritura y el de lectura ahora está comprimido para reducir el uso
de la red. Esto reduce las posibilidades de que no esté disponible el nodo de lectura debido a una
saturación de la red.
2. Se ha implementado un subsistema escalable y de alto rendimiento para las subtransacciones
PostgreSQL. Esto mejora el rendimiento de las aplicaciones que hacen un uso extensivo de los puntos
de guardado y los controladores de excepciones PL/pgSQL.
3. El rol rds_superuser ahora puede establecer los siguientes parámetros en un nivel por sesión, de
base de datos o de rol:
• log_duration
• log_error_verbosity
• log_executor_stats
• log_lock_waits
• log_min_duration_statement
• log_min_error_statement
• log_min_messages
• log_parser_stats
• log_planner_stats
• log_replication_commands
• log_statement_stats
• log_temp_files
4. Se ha corregido un error por el que el comando SQL "ALTER FUNCTION... OWNER TO ..." podría
producir el error "nombre cualificado impropio (demasiados nombres con puntos)".
5. Se ha corregido un problema por el que se podría producir un bloqueo al confirmar una transacción con
más de dos millones de subtransacciones.
6. Se ha corregido un error en el código comunitario de PostgreSQL relacionado con los índices GIN que
podría causar que el volumen de almacenamiento de Aurora no esté disponible.
7. Se ha corregido un error que provocaba que una réplica de Aurora PostgreSQL de una instancia de
RDS para PostgreSQL diera un error al iniciarse, con el siguiente error: "PANIC: no se ha podido
localizar un registro de punto de comprobación válido".
8. Se ha corregido un error por el que el envío de un parámetro no válido a la función
aurora_stat_backend_waits podría causar un bloqueo.
Problemas conocidos
1. La extensión pageinspect no es compatible en Aurora PostgreSQL.
Versión 2.0

861
Versiones de parche
• Versión: 2.0.1 (p. 862)
• Versión 2.0.0 (p. 862)
Versión: 2.0.1
Mejoras
Versión 2.0.0
Mejoras
1. Esta versión contiene todas las correcciones, características y mejoras presentes en Versión
1.3 (p. 865).
2. El usuario puede configurar el límite de tamaño de los archivos temporales. Necesita la función
rds_superuser para modificar el parámetro temp_file_limit.
3. Actualización de la biblioteca GDAL, usada por la extensión PostGIS.
4. Actualización de la extensión ip4r a la versión 2.1.1.
5. Actualización de la extensión pg_repack a la versión 1.4.3.
6. Actualización de la extensión plv8 a la versión 2.1.2.
7. Consultas paralelas: cuando crea una instancia de Aurora PostgreSQL version 2.0 nueva, se
habilitan consultas paralelas para el grupo de parámetros default.postgres10. El parámetro
max_parallel_workers_per_gather se configura en 2 de manera predeterminada, pero es posible
modificarlo para que sea compatible con sus requisitos de carga de trabajo específicos.
8. Corrección de un error en el que los nodos de lectura podían bloquearse después de un tipo específico
de cambio de espacio libre del nodo de escritura.
Versión 1.5
Esta versión de Aurora PostgreSQL es compatible con PostgreSQL 9.6.12. Para obtener más información
sobre las mejoras en la versión 9.6.12, consulte Versión 9.6.12 de PostgreSQL.

862
Versiones de parche
• Versión 1.5.2 (p. 863)
• Versión 1.5.1 (p. 863)
• Versión 1.5.0 (p. 863)
Versión 1.5.2
Mejoras

2. Se ha solucionado un problema en el que el proceso de reproducción del nodo de lectura podía
bloquearse cuando se aplicaba una modificación en un índice del árbol de búsqueda generalizado
(GiST).
3. Se ha solucionado un problema en el que las páginas de asignación de visibilidad podían contener bits
de bloqueo incorrectos después de una conmutación por error en un nodo de lectura.
4. Se ha solucionado un problema en el que se informaba incorrectamente el error "la relación relation-
name no existe".
5. Se ha optimizado el tráfico de registro entre el nodo de escritura y nodos de lectura durante el
mantenimiento del índice.
6. Se ha solucionado un problema en el que las consultas sobre los nodos de lectura pueden bloquearse
cuando se realiza un examen del índice del árbol B.
7. La función aurora_stat_memctx_usage informa ahora del número de instancias de un nombre de
contexto determinado.
8. Se ha solucionado un problema en el que la función aurora_stat_memctx_usage informaba de
resultados incorrectos.
9. Se ha solucionado un problema en el que el proceso de reproducción del nodo de lectura podía esperar
a que se cancelaran consultas conflictivas más allá del valor max_standby_streaming_delay
configurado.
10.La información adicional se registra ahora en los nodos de lectura cuando las conexiones activas entran
en conflicto con el proceso de retransmisión.
Versión 1.5.1
Mejoras
1. Se han soluciona varios errores relacionados con la recuperación previa de E/S que ha producido el
bloqueo del motor.
Versión 1.5.0
1. Ahora Aurora PostgreSQL realiza una recuperación previa de E/S mientras examina los índices de árbol
B. Esto mejora significativamente el rendimiento de los exámenes de árbol B en los datos que no se han
recuperado.

863
Mejoras
1. Se han abordado numerosos problemas que impedían que los nodos de lectura arrancaran cuando el
clúster tenía una carga de trabajo de escritura elevada.
2. Se ha solucionado un problema que hacía que el uso de la función aurora_stat_memctx_usage()
pudiera provocar un bloqueo.
3. Se ha mejorado la estrategia de sustitución de la caché que usan los exámenes de tabla para minimizar
las pérdidas de caché del búfer.
Versión 1.4
acerca de las mejoras en la versión 9.6.11, consulte Versión 9.6.11 de PostgreSQL.
1. Adición de compatibilidad con la extensión pg_similarity, versión 1.0.
Mejoras
1.3 (p. 865).
2. El tráfico de red entre el nodo de escritura y el de lectura ahora está comprimido para reducir el uso
de la red. Esto reduce las posibilidades de que no esté disponible el nodo de lectura debido a una
saturación de la red.
3. Mejora del rendimiento de subtracciones en las cargas de trabajo de alta simultaneidad.
4. Actualización de la extensión pg_hint_plan a la versión 1.2.3.
5. Solución de un problema en el que un sistema ocupado, una confirmación con millones de
subtracciones (y a veces con marcas temporales de confirmación habilitadas) puede provocar que
Aurora se bloquee.
6. Solución de un problema en el que la instrucción INSERT con VALUES podía fallar con el mensaje
"Intentando leer el EOF anterior de relación".
7. Actualización de la extensión apg_plan_mgmt a la versión 1.0.1. La extensión apg_plan_mgmt se
utiliza con una administración de planes de consulta. Para obtener más información sobre cómo instalar,
actualizar y utilizar la extensión apg_plan_mgmt, consulte Administración de planes de ejecución de
consultas para Aurora PostgreSQL (p. 802).
Entre las nuevas características de la extensión apg_plan_mgmt se incluyen las siguientes:

a. Nuevo parámetro update_plan_hash disponible para la función validate_plans. Este
parámetro actualiza plan_hash para los planes que no se pueden reproducir exactamente. El
parámetro update_plan_hash también le permite solucionar un plan mediante la reescritura de
SQL. A continuación, puede registrar el plan en buen estado como un plan Approved para el SQL
original. A continuación, se muestra un ejemplo de cómo se utiliza update_plan_hash.
UPDATE apg_plan_mgmt.dba_plans SET plan_hash = new _plan_hash, plan_outline

= good_plan_outline
WHERE sql_hash = bad_plan_sql_hash AND plan_hash = bad_plan_plan_hash;
SELECT apg_plan_mgmt.validate_plans(bad_plan_sql_hash, bad_plan_plan_hash,
'update_plan_hash');
SELECT apg_plan_mgmt.reload();
b. Nueva función get_explain_stmt disponible que genera texto de una instrucción EXPLAIN para la
instrucción SQL especificada. Incluye los parámetros sql_hash, plan_hash y explain_options.

864
El parámetro explain_options puede ser cualquier lista separada por comas de opciones
EXPLAIN válidas como se muestra a continuación.
analyze,verbose,buffers,hashes,format json
Si el parámetro explain_options es NULL o hay una cadena vacía, la

funciónget_explain_stmt genera una instrucción EXPLAIN simple.
Para crear una instrucción EXPLAIN para su carga de trabajo o una parte de ella, utilice las opciones
\a , \t y \o para redirigir la salida a un archivo. Por ejemplo, puede crear una instrucción EXPLAIN
para las instrucciones con mejor clasificación (top-K) mediante la vista pg_stat_statements de
PostgreSQL ordenada por total_time en el orden DESC.
c. La ubicación precisa del operador de consultas paralelas Gather está determinada por el costo y
puede cambiar ligeramente con el paso del tiempo. Para evitar estas diferencias de invalidación del
plan completo, la administración de planes de consulta computa ahora el mismo plan_hash incluso
si los operadores Gather se trasladan a diferentes lugares en el árbol de planes.
d. Se ha añadido compatibilidad a las instrucciones no parametrizadas dentro de las funciones pl/pgsql.
e. La sobrecarga se reduce cuando la extensión apg_plan_mgmt se instala en varias bases de datos
en el mismo clúster cuando se accede de forma simultánea a dos o más bases de datos. Además,
esta versión corrigió un error en esta área que provocó que los planes no se almacenaran en la
memoria compartida.
Las mejoras apg_plan_mgmt extension incluyen las siguientes:

a. Mejoras en la función evolve_plan_baselines.
i. La función evolve_plan_baselines computa ahora una métrica cardinality_error en
todos los nodos del plan. Mediante esta métrica, puede identificar cualquier plan en el que el error
de estimación de cardinalidad es grande y la calidad del plan en más dudosa. Las instrucciones de
ejecución prolongadas con valores cardinality_error altos son candidatos de alta prioridad
para el ajuste de consultas.
ii. Los informes generados por evolve_plan_baselines incluyen ahora sql_hash, plan_hash y
el plan status.
iii. Ahora puede permitir que evolve_plan_baselines apruebe planes Rejected anteriormente.
iv. El significado de speedup_factor para evolve_plan_baselines es ahora relativo al plan de
referencia. Por ejemplo, un valor de 1,1 ahora significa que es un 10 por ciento más rápido que el
plan de referencia. Un valor de 0,9 significa que es un 10 por ciento inferior al plan de referencia.
La comparación se realiza con el tiempo de ejecución solo en lugar del tiempo total.
v. La función evolve_plan_baselines calienta ahora la caché de una forma nueva. Lo hace
mediante la ejecución del plan de referencia, ejecutándolo de nuevo y, a continuación, ejecutando
el plan de candidatos una vez. Anteriormente, evolve_plan_baselines ejecutaba el plan de
candidatos dos veces. Este enfoque se ha añadido significativamente al tiempo de ejecución,
especialmente para los planes de candidatos lentos. Sin embargo, la ejecución del plan de
candidatos dos veces es más fiable cuando este utiliza un índice que no se utilizan en el plan de
referencia.
b. La administración del plan de consulta ya no guarda planes que hagan referencia a vistas o tablas del
sistema, tablas temporales o a las propias tablas de administración del plan de consulta.
c. Entre las correcciones de errores se incluye el almacenamiento en caché inmediato de un plan
cuando se guarda y la corrección de un error que provocaba que el back-end terminara.
Versión 1.3
acerca de las mejoras en la versión 9.6.9, consulte Versión 9.6.9 de PostgreSQL.
865
Versiones de parche
• Versión 1.3.2 (p. 866)
• Versión 1.3.0 (p. 866)
Versión 1.3.2
1. Adición del evento de espera ProcArrayGroupUpdate.
Mejoras
Versión 1.3.0
Mejoras
1.2 (p. 867).
2. Actualización de la biblioteca GDAL, usada por la extensión PostGIS.
3. Se han actualizado las siguientes extensiones de PostgreSQL:
• ip4r se ha actualizado a la versión 2.1.1.
• pgaudit se ha actualizado a la versión 1.1.1.
• pg_repack se ha actualizado a la versión 1.4.3.
• plv8 se ha actualizado a la versión 2.1.2.
4. Se ha corregido un problema en el sistema de monitorización que podría causar de manera incorrecta
una conmutación por error cuando el uso del disco local es elevado.
5. Corrección de un error que provocaba que Aurora PostgreSQL se bloqueara reiteradamente e informara
de lo siguiente:
PANIC: new_record_total_len (8201) must be less than BLCKSZ (8192), rmid (6),
info (32)

866
6. Corrección de un error que provocaba que un nodo de lectura de Aurora PostgreSQL no pudiera volver
a unirse a un clúster debido a la recuperación de una caché de búfer grande. Es improbable que el
problema se produzca en instancias distintas a r4.16xlarge.
7. Corrección de un error por el que la inserción en una página de hoja índice GIN vacía importada de
versiones de motor anteriores a 9.4 podía causar que el volumen de almacenamiento de Aurora no
estuviera disponible.
8. Se ha corregido un problema por el que, en circunstancias inusuales, un bloqueo durante la
confirmación de una transacción podría provocar la pérdida de datos CommitTs correspondientes a la
transacción de confirmación. La durabilidad real de la transacción no se ha visto afectada por este error.
9. Corrección de un error en la extensión PostGIS por el que PostGIS podía bloquearse en la función
gserialized_gist_picksplit_2d().
10.Se ha mejorado la estabilidad de nodos de solo lectura durante tráfico de escritura intenso en instancias
más pequeñas que r4.8xl. Esto aborda específicamente una situación en la que el ancho de banda de la
red entre el escritor y el lector está limitada.
11.Se ha corregido un error que provocaba que una instancia Aurora PostgreSQL que actuaba como
destino de la replicación de una instancia de RDS para PostgreSQL se bloqueara con el siguiente error:
FATAL: could not open file "base/16411/680897_vm": No such file or directory"

during "xlog redo at 782/3122D540 for Storage/TRUNCATE"
12.Se ha corregido una fuga de memoria en nodos de solo lectura por el que el tamaño del montón del
"proceso de repetición WAL de Aurora" continuará creciendo. Esto puede observarse a través de la
monitorización mejorada.
13.Corrección de un error que provocaba que Aurora PostgreSQL no se iniciara y se notificara el siguiente
mensaje en el registro de PostgreSQL:
FATAL: Storage initialization failed.

14.Se ha corregido una limitación de rendimiento en cargas de trabajo de escritura intensas que causaba
esperas en eventos LWLock:buffer_content e IO:ControlFileSyncUpdate.
15.Corrección de un error en el que los nodos de lectura podían bloquearse después de un tipo específico
de cambio de espacio libre del nodo de escritura.
Versión 1.2
sobre las mejoras en la versión 9.6.8, consulte Versión 9.6.8 de PostgreSQL.
Versiones de parche
• Versión 1.2.2 (p. 867)
• Versión 1.2.0 (p. 868)
Versión 1.2.2
1. Adición del evento de espera ProcArrayGroupUpdate.
Mejoras

867

Versión 1.2.0
1. Se ha incorporado la función aurora_stat_memctx_usage(). Esta función informa del uso del

contexto de memoria interno para cada backend de PostgreSQL. Puede usar esta función para que le
ayude a saber por qué determinados backends consumen grandes cantidades de memoria.
Mejoras
1.1 (p. 869).
2. Se han actualizado las siguientes extensiones de PostgreSQL:
• pg_hint_plan se ha actualizado a la versión 1.2.2
• plv8 se ha actualizado a la versión 2.1.0
3. Se ha mejorado la eficacia del tráfico entre los nodos de escritura y lectura.
4. Se ha mejorado el desempeño del establecimiento de conexiones.
5. Se han mejorado los datos de diagnóstico proporcionados en el archivo log de errores de PostgreSQL
cuando se produce un error de memoria insuficiente.
6. Se han realizado varias correcciones para mejorar la fiabilidad y el rendimiento de la importación de
instantáneas de Amazon RDS para PostgreSQL a Compatibilidad de Aurora con PostgreSQL.
7. Se han realizado varias correcciones para mejorar la fiabilidad y el desempeño de los nodos de lectura
de Aurora PostgreSQL.
8. Se ha solucionado un error por el cual una instancia que de alguna manera está inactiva puede generar
tráfico de lectura innecesario en un volumen de almacenamiento de Aurora.
9. Se ha corregido un error que permitía tener valores de secuencia duplicados durante una inserción.
El problema solo se produce cuando se migra una instantánea de RDS para PostgreSQL a Aurora
PostgreSQL. La solución evita que se produzca el problema al realizar la migración. Se pueden seguir
produciendo errores de claves duplicadas para las instancias migradas antes de esta versión.
10.Se ha corregido un error por el que una instancia de RDS para PostgreSQL migrada a Aurora
PostgreSQL mediante replicación se podía quedar sin memoria durante las operaciones de inserción o
actualización de índices de GIST o experimentar otros problemas con los índices de GIST.
11.Se ha corregido un error por el que la operación "vacuum" no podía actualizar el valor
pg_database.datfrozenxid correspondiente para una base de datos.

868
12.Se ha corregido un error por el que un bloqueo al crear un nuevo MultiXact (bloqueo de nivel de fila
sostenido) podía hacer que Aurora PostgreSQL se bloqueara indefinidamente al obtener acceso por
primera vez a la misma relación una vez reiniciado el motor.
13.Corrección de un error por el que un back-end de PostgreSQL no podía terminarse ni cancelarse
después de invocar una llamada fdw.
14.Se ha corregido un error por el que una vCPU era utilizada completamente en todo momento por
el daemon de almacenamiento de Aurora. Este problema es especialmente evidente en clases de
instancias más pequeñas, como r4.large, en las que el uso de la CPU puede llegar hasta el 25 o el 50
por ciento cuando están inactivas.
15.Se ha solucionado un error por el que un nodo de escritura de Aurora PostgreSQL podía conmutar por
error falsamente.
16.Se ha solucionado un error por el que, en raras ocasiones, un nodo de lectura de Aurora PostgreSQL
podía generar el mensaje:
"FATAL: lock buffer_io is not held"

17.Se ha solucionado un error por el que las entradas de relcache obsoletas podían detener el vaciado
de relaciones y permitir que el sistema casi reiniciara los ID de transacción. La solución es un puerto
de un parche de la comunidad de PostgreSQL programado para su lanzamiento en una futura versión
secundaria.
18.Se ha solucionado un error debido al cual, si se producía un error al ampliar una relación, Aurora podía
dejar de funcionar al analizar la relación parcialmente ampliada.
Versión 1.1
sobre las mejoras de la versión 9.6.6, consulte Versión 9.6.6 de PostgreSQL.
Puede encontrar las siguientes mejoras en esta actualización del motor:
1. Se ha incorporado la extensión aurora_stat_utils. Esta extensión incluye dos funciones:

• aurora_wait_report() para la monitorización de eventos de espera
• aurora_log_report() para la monitorización de escritura de registros log
2. Se ha agregado compatibilidad con las siguientes extensiones:
• orafce 3.6.1
• pgrouting 2.4.2
• postgresql-hll 2.10.2
• prefix 1.2.6
Mejoras
1.0.11 (p. 870).
2. Actualizaciones de las siguientes extensiones de PostgreSQL:
• Extensión postgis actualizada a la versión 2.3.4
• Biblioteca geos actualizada a la versión 3.6.2
• pg_repack actualizada a la versión 1.4.2
3. Se ha habilitado el acceso a la relación pg_statistic.
4. Se ha deshabilitado el parámetro guc "effective_io_concurrency", ya que no se aplica al almacenamiento
de Aurora.

869
5. Se ha cambiado el parámetro guc "hot_standby_feedback" a no modificable y se ha establecido el valor

en "1".
6. Se ha mejorado el desempeño de lectura de páginas del montón durante una operación de limpieza.
7. Se ha mejorado el desempeño de la resolución de conflictos de instantáneas en los nodos de lectura.
8. Se ha mejorado el desempeño de la adquisición de instantáneas de transacción en los nodos de lectura.
9. Se ha mejorado el desempeño de escritura de las actualizaciones de metapáginas GIN.
10.Se ha mejorado el desempeño de recuperación de caché de búfer durante el inicio.
11.Se ha corregido un problema que provocaba un bloqueo del motor de base de datos al inicio durante la
recuperación de las transacciones preparadas.
12.Se ha corregido un problema que podría provocar la imposibilidad de iniciar un nodo de lectura cuando
hay una gran cantidad de transacciones preparadas.
13.Se ha corregido un problema que podría provocar que un nodo de lectura notificara lo siguiente:
ERROR: could not access status of transaction 6080077
DETAIL:* *Could not open file "pg_subtrans/005C": No such file or directory.

14.Se ha corregido un problema que podría provocar el error siguiente al efectuar la replicación de RDS
PostgreSQL a Aurora PostgreSQL:
FATAL: lock buffer_content is not held
CONTEXT: xlog redo at 46E/F1330870 for Storage/TRUNCATE: base/13322/8058750 to 0 blocks flags

7
15.Se ha corregido un error que podría provocar que Aurora PostgreSQL se bloqueara durante la repetición
de un registro WAL multixact al efectuar la replicación de RDS PostgreSQL a Aurora PostgreSQL.
16.Se han realizado varias mejoras en la fiabilidad de la importación de instantáneas de RDS PostgreSQL
a Aurora PostgreSQL.
Versión 1.0
sobre las mejoras de la versión 9.6.3, consulte Versión 9.6.3 de PostgreSQL.
Esta versión incluye las siguientes versiones de parche:
Versiones de parche
• Versión 1.0.11 (p. 870)
• Versión 1.0.10 (p. 871)
• Versión 1.0.9 (p. 871)
• Versión 1.0.8 (p. 871)
• Versión 1.0.7 (p. 871)
Versión 1.0.11
1. Corrige un problema en la ejecución de consultas paralelas que puede generar resultados incorrectos.
2. Corrige un problema con el tratamiento de mapas de visibilidad durante la replicación desde Amazon
RDS para PostgreSQL que pueden provocar que el volumen de almacenamiento de Aurora deje de
estar disponible.
3. Corrige la extensión pg-repack.
4. Implementa mejoras para mantener actualizados los nodos.

870
5. Corrige problemas que pueden provocar un bloqueo del motor.
Versión 1.0.10
Esta actualización incluye una nueva característica. Ahora puede replicar una instancia de base de datos
PostgreSQL de Amazon RDS en Aurora PostgreSQL. Para obtener más información, consulte Replicación
con Amazon Aurora PostgreSQL (p. 796).
1. Agrega el registro de errores cuando existe una memoria caché y un cambio de parámetro provoca que
no coincidan la memoria caché de búfer, un formato de almacenamiento o el tamaño.
2. Corrige un problema que provoca un reinicio del motor si hay un valor de parámetro incompatible para
páginas de gran tamaño.
3. Mejora el tratamiento varias instrucciones TRUNCATE TABLE durante una repetición de un log de
escritura previa (WAL) en un nodo de lectura.
4. Reduce la sobrecarga de memoria estática para disminuir los errores de memoria insuficiente.
5. Corrige un problema que puede provocar errores de memoria insuficiente al realizar una inserción con
un índice GiST.
6. Mejora la importación de instantáneas desde PostgreSQL de RDS, al quitar el requisito de que se deba
realizar un vaciado en las páginas no inicializadas.
7. Corrige un problema que provoca que las transacciones preparadas vuelvan al estado anterior después
de un bloqueo del motor.
8. Implementa mejoras para evitar que los nodos de lectura se queden obsoletos.
9. Implementa mejoras para reducir el tiempo de inactividad con un reinicio del motor.
10.Corrige problemas que pueden provocar un bloqueo del motor.
Versión 1.0.9
En esta actualización del motor, corregimos un problema que puede provocar que el volumen de
almacenamiento de Aurora deje de estar disponible al importar una instantánea desde PostgreSQL de
RDS con páginas no inicializadas.
Versión 1.0.8
1. Corrige un problema que impedía que se iniciara el motor si el parámetro de instancia

shared_preload_libraries contenía pg_hint_plan.
2. Corrige el error que indica que el intento de recuperar el bloque de montón XXX está más allá del final
del montón (YYY bloques), que se puede producir durante los exámenes en paralelo.
3. Mejora la eficacia de la recuperación previa en las lecturas para una limpieza.
4. Corrige problemas en la importación de instantáneas desde PostgreSQL de RDS, que puede no
realizarse si hay archivos pg_internal.init incompatibles en la instantánea de origen.
5. Corrige un problema que puede provocar que se bloquee un nodo de lectura con un mensaje que indica
que el proceso de repetición WAL de Aurora (PID XXX) terminó con la señal 11, error de segmentación.
Este problema se produce cuando el lector aplica un cambio de mapa de visibilidad para una página de
mapa de visibilidad que no está en caché.
Versión 1.0.7
Es la primera versión de Amazon Compatibilidad de Aurora con PostgreSQL disponible con carácter
general.

871
Directrices operativas básicas de Amazon Aurora
Prácticas recomendadas con

Amazon Aurora
En este tema se proporciona información acerca de prácticas recomendadas generales y las opciones
para usar o migrar datos en un clúster de base de datos de Amazon Aurora.
Algunas de las prácticas recomendadas para Amazon Aurora son específicas de un motor de base de
datos determinado. Para obtener más información acerca de las prácticas recomendadas de Aurora
específicas de un motor de base de datos, consulte lo siguiente:
Motor de base de datos Prácticas recomendadas
Amazon Aurora MySQL Consulte Prácticas recomendadas con Amazon Aurora

MySQL (p. 667)
Amazon Aurora PostgreSQL Consulte Prácticas recomendadas con Amazon Aurora

PostgreSQL (p. 838)
Note
Para ver recomendaciones frecuentes para Aurora, consulte Uso de recomendaciones de Amazon
Aurora (p. 440).
Temas
• Directrices operativas básicas de Amazon Aurora (p. 872)
• Recomendaciones de RAM de las instancias de base de datos (p. 873)
• Monitorización de Amazon Aurora (p. 873)
• Trabajo con los grupos de parámetros de base de datos y grupos de parámetros de clúster de base de
datos (p. 873)
• Vídeo de presentación de las prácticas recomendadas de Amazon Aurora (p. 874)
Directrices operativas básicas de Amazon Aurora

A continuación se detallan las directrices operativas básicas que se deben seguir al trabajar con Amazon
Aurora. El Acuerdo de nivel de servicios de Amazon RDS requiere que se sigan estas directrices:
• Monitorice el uso de la memoria, la CPU y el almacenamiento. Amazon CloudWatch se puede configurar

para notificar cuándo cambian los patrones de uso o cuándo se está llegando al límite de capacidad de
la implementación con el fin de mantener el rendimiento y la disponibilidad del sistema.
• Si la aplicación cliente almacena en caché los datos del Servicio de nombres de dominio (DNS) de las
instancias de base de datos, defina un valor de tiempo de vida (TTL) de menos de 30 segundos. Como
la dirección IP subyacente de una instancia de base de datos puede cambiar tras una conmutación por
error, almacenar datos DNS en la caché durante un periodo de tiempo largo puede llevar a errores de
conexión si la aplicación intenta conectarse a una dirección IP que ya no esté en servicio. Los clústeres
de base de datos de Aurora con múltiples réplicas de lectura pueden tener errores de conexión también
cuando las conexiones usan el punto de enlace del lector y una de las instancias de réplica de lectura
está en mantenimiento o se elimina.

872
Recomendaciones de RAM de
las instancias de base de datos
• Pruebe la conmutación por error de su clúster de base de datos para entender cuánto tarda el proceso
para su caso de uso y para asegurarse de que la aplicación que obtiene acceso a su clúster de base de
datos puede conectarse automáticamente al nuevo clúster de base de datos tras una conmutación por
error.
Recomendaciones de RAM de las instancias de

base de datos
Para optimizar el rendimiento, asigne suficiente RAM para que el conjunto de trabajo resida casi por
completo en la memoria. Para determinar si el conjunto de trabajo está en la memoria casi en su totalidad,
examine la siguiente métrica en Amazon CloudWatch:
• VolumeReadIOPS: esto mide el número medio de operaciones de E/S de lectura desde un volumen de
clúster, indicado a intervalos de 5 minutos. El valor de VolumeReadIOPS debe ser pequeño y estable.
Si observa que sus operaciones de E/S de lectura aumentan o son superiores a lo habitual, deberá
investigar las instancias de base de datos en su clúster de base de datos para ver qué instancias de
base de datos están causando el aumento de E/S.
• BufferCacheHitRatio: esta métrica mide el porcentaje de solicitudes que se responden desde
la caché del búfer de una instancia de base de datos en su clúster de base de datos. Esta métrica
proporciona información sobre la cantidad de datos que se está sirviendo desde la memoria. Si la tasa
de aciertos es baja, se trata de una buena indicación de que sus consultas a esta instancia de base de
datos van al disco la mayoría de las veces. En este caso, debería investigar su carga de trabajo para ver
qué consultas están provocando este comportamiento.
Si tras investigar su carga de trabajo determina que necesita más memoria, el escalado de la clase de
instancia de base de datos a una clase con más RAM podría ser útil. Una vez que lo haya hecho, puede
investigar las métricas de arriba y seguir ampliando según sea necesario. Para obtener más información
acerca de la monitorización de un clúster de base de datos, consulte Monitorización de las métricas de un
clúster de base de datos Amazon Aurora (p. 384).
Monitorización de Amazon Aurora

Amazon Aurora proporciona diversas métricas de Amazon CloudWatch que se pueden monitorizar
para determinar el estado y el rendimiento de un clúster de base de datos Aurora. Puede utilizar varias
herramientas, como la consola de administración de Amazon RDS, la interfaz de línea de comandos (CLI)
de AWS y la API de CloudWatch para ver las métricas de Aurora. Para obtener más información, consulte
Monitorización de un clúster de base de datos de Amazon Aurora (p. 363).
Trabajo con los grupos de parámetros de base de

datos y grupos de parámetros de clúster de base de
datos
Es recomendable que pruebe los cambios de los grupos de parámetros de base de datos y de grupos de
parámetro de clústeres de base de datos en un clúster de base de datos prueba antes de aplicar cambios
de grupos de parámetros al clúster de base de datos de producción. Si se configuran de forma incorrecta
los parámetros del motor de base de datos, pueden producirse efectos adversos no deseados, como la
degradación del rendimiento y la inestabilidad del sistema.

873
Vídeo de presentación de las prácticas
recomendadas de Amazon Aurora
Tenga cuidado siempre que modifique los parámetros del motor de base de datos y cree una copia de
seguridad del clúster de base de datos antes de modificar un grupo de parámetros de base de datos. Para
obtener información acerca del procedimiento para realizar la copia de seguridad del clúster de base de
datos, consulte Backup y restauración de un clúster de base de datos de Amazon Aurora (p. 314).
Vídeo de presentación de las prácticas

recomendadas de Amazon Aurora
La conferencia AWS Summit de 2016 celebrada en Chicago incluyó una presentación de las prácticas
recomendadas para crear y configurar un clúster de base de datos Amazon Aurora seguro y de alta
disponibilidad. Puede ver aquí un vídeo de la presentación.

874
Información general de una prueba de concepto de Aurora
Ejecución de una prueba de concepto

de Amazon Aurora
A continuación, encontrará una explicación de cómo configurar una prueba de concepto de Aurora. Una
prueba de concepto es una investigación que se realiza para ver si Aurora se adapta bien a su aplicación.
La prueba de concepto le ayuda a comprender las características de Aurora en el contexto de sus propias
aplicaciones de base de datos y cuál es el rendimiento de Aurora en comparación con el de su entorno de
base de datos actual. También es útil para ver cuánto trabajo tendrá que dedicar a trasladar datos, migrar
código SQL, ajustar el rendimiento y adaptar los procedimientos de administración actuales.
En este tema, se proporciona información e instrucciones generales para los procedimientos y decisiones
de tipo general que deben adoptarse al ejecutar una prueba de concepto. Si desea consultar instrucciones
detalladas, haga clic en los enlaces siguientes para llegar a la documentación de temas específicos.
Información general de una prueba de concepto de

Aurora
Con una prueba de concepto de Amazon Aurora aprenderá cuánto le costará migrar los datos y las
aplicaciones SQL existentes a Aurora. En dicha prueba, se aplican a escala aspectos importantes de
Aurora, con un volumen de datos y una actividad representativos de su entorno de producción. El objetivo
es asegurarse y confiar en que los puntos fuertes de Aurora estarán a la altura de los retos que le impulsan
a ampliar su infraestructura de base de datos anterior. Cuando acabe la prueba de concepto, tendrá un
plan sólido para realizar una comparación a mayor escala del rendimiento y la prueba de aplicación. En
este punto, ya comprenderá cuáles son los principales elementos que tiene que desarrollar para llegar a
una implementación de producción.
El siguiente consejo sobre prácticas recomendadas puede serle útil para evitar errores que se producen
con frecuencia y que pueden provocar problemas durante la comparación. Sin embargo, en este tema no
se cubre el proceso detallado paso a paso de realización de una comparación y un ajuste del rendimiento.
Este procedimiento varía en función de la carga de trabajo y de las características de Aurora que use.
Para obtener información detallada, consulte la documentación relacionada con el rendimiento, como
Administración del desempeño y el escalado para clústeres de base de datos Aurora (p. 257), Mejoras de
desempeño de Amazon Aurora MySQL (p. 496), Administración de Amazon Aurora PostgreSQL (p. 795) y
Uso de Performance Insights de Amazon RDS (p. 402).
La información que se proporciona en este tema se aplica principalmente a aplicaciones en las que la
organización escribe el código y diseña el esquema, y que son compatibles con los motores de base
de datos de código abierto MySQL y PostgreSQL. Si va a probar una aplicación comercial o un código
generado por un marco de aplicaciones, puede que no tenga suficiente flexibilidad para aplicar todas
las directrices. En dicho caso, póngase en contacto con el representante de AWS para saber si existen
prácticas recomendadas o casos prácticos de Aurora para su tipo de aplicación.
1. Identifique sus objetivos

Al evaluar Aurora como parte de una prueba de concepto, usted elige las medidas que van a realizarse y
cómo determinar si un ejercicio se ha realizado correctamente.
Tiene que asegurarse de que la funcionalidad completa de la aplicación sea compatible con Aurora.
Como Aurora es compatible por conexión con MySQL 5.6 y MySQL 5.7, así como con PostgreSQL

875
2. Conozca las características de su carga de trabajo
9.6 y PostgreSQL 10.4, la mayoría de las aplicaciones desarrolladas para estos motores también son
compatibles con Aurora. Sin embargo, debe validar la compatibilidad aplicación por aplicación.
Por ejemplo, algunas de las opciones de configuración de un clúster de Aurora influyen en si se puede o se
deben usar características determinadas de la base de datos. Puede comenzar, por ejemplo, por un clúster
de Aurora de ámbito más general, conocido como clúster aprovisionado. Después, puede que le interese
decidir si una configuración especializada como una consulta paralela o sin servidor le sería útil a su carga
de trabajo.
Formúlese las siguientes preguntas para establecer y cuantificar sus objetivos:
• ¿Es compatible Aurora con todos los casos de uso funcionales de su carga de trabajo?
• ¿Qué volumen de conjunto de datos o nivel de carga quiere? ¿Puede escalar a dicho nivel?
• ¿Cuáles son sus requisitos específicos de latencia o desempeño de consultas? ¿Puede conseguirlos?
• ¿Cuál es el tiempo mínimo de inactividad planificada o sin planificar aceptable para su carga de trabajo?
¿Puede conseguirlo?
• ¿Cuáles son las métricas necesarias para un funcionamiento eficiente? ¿Puede monitorizarlas con
precisión?
• ¿Es compatible Aurora con sus objetivos empresariales concretos como, por ejemplo, una reducción de
costos, el aumento de la implementación o la velocidad de aprovisionamiento? ¿Tiene alguna forma de
cuantificar dichos objetivos?
• ¿Puede cumplir todos los requisitos de seguridad y conformidad de su carga de trabajo?
Reserve tiempo para mejorar sus conocimientos sobre los motores de base de datos y las capacidades de
plataforma de Aurora, y revise la documentación del servicio. Tome nota de todas las características que le
pueden ser útiles para obtener los resultados deseados. Por ejemplo, puede interesarle la característica de
consolidación de cargas de trabajo que se describe en la publicación del blog de bases de datos de AWS
que trata de cómo planificar y optimizar Amazon Aurora con compatibilidad de MySQL para cargas de
trabajo consolidadas. También puede interesarle la característica de escalado en función de la demanda,
que se describe en Uso de Auto Scaling de Amazon Aurora con réplicas de Aurora (p. 297), en la Guía del
usuario de Amazon Aurora, u otras características como las ganancias de rendimiento o las operaciones
de bases de datos simplificadas.
2. Conozca las características de su carga de

trabajo
Evalúe Aurora en el contexto del caso de uso para el que está destinado. Aurora es una buen opción
para las cargas de trabajo de procesamiento de transacciones online (OLTP). También puede ejecutar
informes en el clúster que contiene los datos OLTP en tiempo real sin aprovisionar un clúster de almacén
de datos independiente. Para saber si su caso de uso entra dentro de estas categorías, averigüe si tiene
las siguientes características:
• Un alto grado de simultaneidad, con decenas, centenas o miles de clientes a la vez.

• Un alto volumen de consultas con baja latencia (de milisegundos a segundos).
• Transacciones breves en tiempo real.
• Patrones de consulta altamente selectivos, con búsquedas basadas en índices.
• En el caso de HTAP, consultas analíticas que pueden aprovechar la característica de consultas paralelas
de Aurora.
Cuando se elige una base de datos, uno de los factores clave es la velocidad de los datos. Si la velocidad
es elevada, los datos se insertan y se actualizan con mucha frecuencia. En un sistema de este tipo, puede

876
3. Practique con la consola o la CLI
haber miles de conexiones y centenares de miles de consultas simultáneas que leen una base de datos y
escriben en ella. Por lo general, las consultas que se realizan en sistemas de alta velocidad afectan a un
número relativamente pequeño de filas y suelen obtener acceso a varias columnas de la misma fila.
Aurora está diseñado para trabajar con datos de alta velocidad. En función de la carga de trabajo, un
clúster de Aurora con una única instancia de base de datos r4.16xlarge puede procesar más de 600 000
instrucciones SELECT por segundo. Aquí también, según la carga de trabajo, un clúster de este tipo puede
procesar 200 000 instrucciones INSERT, UPDATE y DELETE por segundo. Aurora es una base de datos
de almacenamiento de filas especialmente adecuada para cargas de trabajo OLTP de alto volumen, alto
desempeño y alto paralelismo.
Aurora también puede ejecutar consultas en el mismo clúster que gestiona la carga de trabajo OLTP.
Aurora admite hasta 15 réplicas (p. 48), cada una de las cuales está, de media, a 10 o 20 milisegundos de
la instancia principal. Los analistas pueden consultar los datos OLTP en tiempo real sin copiar los datos
en un clúster de almacenes de datos independiente. Dado que los clústeres de Aurora pueden usar la
característica de consulta en paralelo, puede descargar un gran volumen de trabajo de procesamiento,
filtrado y agregación en el subsistema de almacenamiento de Aurora de distribución masiva.
Aproveche esta fase de planificación para familiarizarse con las capacidades de Aurora, otros servicios de
AWS, la Consola de administración de AWS y la AWS CLI. Además, compruebe cómo funcionan con otras
herramientas que tiene previsto utilizar en la prueba de concepto.
3. Practique con la Consola de administración de

AWS o con la AWS CLI
En el siguiente paso, tendrá que practicar con la Consola de administración de AWS o con AWS CLI para
familiarizarse con estas herramientas y con Aurora.
Practique con la Consola de administración de AWS

Las siguientes actividades iniciales que se realizan con clústeres de la base de datos Aurora tienen como
objetivo principal familiarizarlo con el entorno de la Consola de administración de AWS y hacerle practicar
la configuración y la modificación de clústeres de Aurora. Si usa motores de base de datos compatibles
con MySQL y PostgreSQL junto con Amazon RDS, puede aprovechar sus conocimientos cuando utilice
Aurora.
Aproveche el modelo de almacenamiento compartido y las características de Aurora como la replicación

y las instantáneas; puede tratar clústeres completos de bases de datos como si fueran otro tipo de objeto
que puede manipular a su voluntad. Puede configurar, eliminar y cambiar con frecuencia la capacidad de
los clústeres de Aurora durante la prueba de concepto. Las elecciones de capacidad, configuración de
base de datos y disposición física de los datos que realice al principio no lo limitan.
Para comenzar, configure un clúster de Aurora vacío. Elija el tipo de capacidad provisioned (aprovisionado)
y la ubicación regional para sus experimentos iniciales.
Establezca conexión con el clúster mediante un programa cliente como una aplicación de línea de
comandos de SQL. Al principio establezca conexión utilizando el punto de enlace del clúster. Conéctese
al punto de enlace para realizar cualquier operación de escritura, como instrucciones de lenguaje de
definición de datos (DDL) y procesos de extracción, transformación y carga (ETL). Más adelante, en la
prueba de concepto, conectará sesiones de uso intensivo de consultas usando el punto de enlace del
lector, que se encargará de distribuir la carga de trabajo de las consultas entre numerosas instancias de
base de datos del clúster.
Escale el clúster añadiendo más réplicas de Aurora. Para informarse sobre estos procedimientos, consulte
Replicación con Amazon Aurora (p. 48). Aumente o reduzca el escalado de las instancias de base de datos

877
Practique con la CLI
cambiando la clase de instancia de AWS. Comprenda cómo Aurora simplifica estos tipos de operaciones,
ya que si más adelante sus estimaciones iniciales de la capacidad del sistema demuestran ser poco
precisas, pueda modificarlas sin tener que volver a comenzar.
Cree una instantánea y restáurela en otro clúster.
Examine las métricas del clúster para ver la actividad en el tiempo y cómo las métricas se aplican a las
instancias de base de datos del clúster.
Al principio puede serle útil familiarizarse con el uso de la Consola de administración de AWS para realizar
estas tareas. Cuando comprenda qué puede hacer con Aurora, puede automatizar dichas operaciones con
la AWS CLI. En las secciones siguientes encontrará información detallada acerca de los procedimientos y
las prácticas recomendadas de estas actividades durante el período de prueba de concepto.
Practique con la AWS CLI

Recomendamos que automatice los procedimientos de implementación y administración, incluso en un
entorno de prueba de concepto. Para ello, familiarícese con la AWS CLI si todavía no está familiarizado.
Si usa motores de base de datos compatibles con MySQL y PostgreSQL junto con Amazon RDS, sus
conocimientos le serán útiles cuando utilice Aurora.
Normalmente, Aurora trabaja con grupos de instancias de bases de datos ordenadas en clústeres.
Esto hace que en muchas operaciones se tenga que determinar qué instancias de base de datos están
asociadas a un clúster y luego se realicen operaciones administrativas en bucle en todas las instancias.
Por ejemplo, puede automatizar pasos como la creación de clústeres de Aurora y luego escalarlos
mediante ampliación con clases de instancias más grandes o ampliarlos con instancias de bases de datos
adicionales. Esta característica es útil si desea repetir cualquier etapa de su prueba de concepto y explorar
escenarios condicionales con diferentes tipos de configuraciones de clústeres de Aurora.
Aprenda cuáles son las capacidades y limitaciones de las herramientas de implementación de

infraestructura como AWS CloudFormation. Puede darse el caso de que actividades que realiza en
un contexto de prueba de concepto no sean adecuadas en un entorno de producción. Por ejemplo, el
comportamiento de AWS CloudFormation en una modificación consiste en crear una instancia nueva y
eliminar la actual, incluidos sus datos. Para obtener más información acerca de este comportamiento,
consulte Comportamientos de actualización de los recursos de la pila en la Guía del usuario de AWS
CloudFormation.
4. Cree su clúster de Aurora

Con Aurora, puede explorar escenarios condicionales añadiendo instancias de base de datos al clúster
y escalando mediante ampliación las instancias de base de datos a clases de instancias más potentes.
También puede crear clústeres con distintos ajustes de configuración para que ejecuten la misma carga de
trabajo uno al lado de otro. Aurora aporta una gran flexibilidad que le permite configurar, eliminar y volver a
configurar clústeres de bases de datos. Teniendo en cuenta estas técnicas, le será útil practicarlas en las
etapas iniciales del proceso de prueba de concepto. Para informarse de los procedimientos generales para
crear clústeres de Aurora, consulte Creación de un clúster de base de datos de Amazon Aurora (p. 85).
Para practicar, comience con un clúster que tenga la configuración que indicamos más abajo. Omita este
paso solo si tiene en mente algunos casos de uso específicos. Por ejemplo, puede que le interese omitir
este paso si su caso de uso necesita un tipo especializado de clúster de Aurora, O bien, puede que le
interese omitirlo si necesita una combinación específica de motor de base de datos y versión.
• Amazon Aurora.
• Compatibilidad con MySQL 5.6. Esta combinación de motor de base de datos y versión tiene la
compatibilidad de más amplio espectro con otras características de Aurora.

878
5. Configure el esquema
• Desactive quick create (Creación rápida). Para la prueba de concepto, le recomendamos que preste
mucha atención a todos los ajustes que elija a fin de que pueda crear clústeres idénticos o muy
parecidos más adelante.
• Regional. El ajuste Global se utiliza en escenarios de alta disponibilidad específicos. Puede probarlo más
adelante, después de los experimentos funcionales y de rendimiento iniciales.
• Un escritor y varios lectores. Este es el clúster de tipo general de uso más extendido. Esta configuración
persiste durante toda la vida del clúster. Por lo tanto, si más adelante experimenta con otros tipos de
clústeres, como una consulta sin servidor o paralela, cree otros clústeres y compare los resultados y
analícelos en cada uno de ellos.
• Elija la plantilla Dev/Test (Desarrollo/Prueba). Esta opción no es significativa para sus actividades de
prueba de concepto.
• Para Instance Size (Tamaño de instancia), elija Memory Optimized (Optimizado para memoria) y una de
las clases de instancias xlarge. Más adelante, podrá subir o bajar el nivel de la clase de instancia.
• En Multi-AZ Deployment (Implementación Multi-AZ), elija Create Replica in Different Zone (Crear réplica
en otra zona). En muchos de los aspectos más útiles de Aurora se usan clústeres compuestos por
numerosas instancias de base de datos. En todos los clústeres nuevos es normal comenzar siempre por
dos instancias de base de datos como mínimo. Si se usa una zona de disponibilidad diferente para la
otra instancia de base de datos, será más fácil probar diferentes escenarios de alta disponibilidad.
• Cuando elija un nombre para una instancia de base de datos, utilice una convención de nomenclatura
genérica. Nunca se refiera a una instancia de base de datos del clúster como la instancia "principal"
o "escritora", ya que, según las necesidades, esto rol lo asumirán instancias de base de datos
diferentes. Le recomendamos que use algo parecido a clustername-az-serialnumber; por ejemplo
myprodappdb-a-01. De esta manera, puede identificar de forma exclusiva la instancia de base de
datos y su ubicación.
• Configure la retención de la copia de seguridad en un valor elevado para el clúster de Aurora. Si el
período de retención es largo, puede realizar una recuperación a un momento dado (PITR) para un
período de 35 días como máximo. Podrá restablecer la base de datos en un estado conocido después
de haber ejecutado las pruebas con instrucciones DDL y de lenguaje de manipulación de datos (DML).
También puede hacer una recuperación si por error borra o cambia datos.
• Habilite las características adicionales de recuperación, registro y monitorización al crear el clúster.
Active todas las opciones de Backtrack, Performance Insights (Información sobre rendimiento),
Monitoring (Monitorización) y Log exports (Exportaciones de registro). Con estas opciones habilitadas,
puede probar la idoneidad de características como el backtracking, la monitorización mejorada o la
información sobre rendimiento en su carga de trabajo. También puede estudiar fácilmente el rendimiento
y la resolución de problemas durante la prueba de concepto.
5. Configure el esquema
En el clúster de Aurora, configure las bases de datos, tablas, índices, claves externas y otros objetos del
esquema para su aplicación. Si se está trasladando desde un sistema de base de datos compatible con
MySQL o PostgreSQL, esta etapa será probablemente sencilla y fácil. Tendrá que usar la misma línea de
comandos y sintaxis de SQL u otras aplicaciones cliente con las que ya está familiarizado con su motor de
base de datos.
Para generar instrucciones SQL en el clúster, busque el punto de enlace de clúster y suministre el valor
como parámetro de conexión a su aplicación cliente. Encontrará el punto de enlace del clúster en la
pestaña Connectivity (Conectividad) de la página de detalles del clúster. El punto de enlace del clúster es
el que está etiquetado como Writer (Escritor). El otro punto de enlace, etiquetado como Reader (Lector),
representa una conexión de solo lectura que se puede proporcionar a usuarios finales que ejecuten
informes u otras consultas de solo lectura. Para obtener ayuda con problemas relativos a la conexión del
clúster, consulte Conexión a un clúster de base de datos Amazon Aurora (p. 148).
Si migra el esquema y los datos desde otro sistema de base de datos, en este punto probablemente
tendrá que introducir algún cambio. Los cambios de esquema se efectúan para que coincida con la

879
6. Importe los datos
sintaxis de SQL y las capacidades disponibles en Aurora. En este punto puede excluir algunas columnas,
restricciones, desencadenantes u otros objetos del esquema. Esta operación es útil, sobre todo si los
objetos requieren un trabajo adicional para que sean compatibles con Aurora y no son especialmente
importantes para sus objetivos en la prueba de concepto.
Si realiza la migración desde un sistema de base de datos cuyo motor subyacente no sea el mismo que el
de Aurora, sopese la posibilidad de usar la Herramienta de conversión de esquemas de AWS (AWS SCT)
para simplificar el proceso. Para obtener información detallada, consulte Guía del usuario de AWS Schema
Conversion Tool. Para obtener información detallada de tipo general sobre las actividades de migración y
portabilidad, consulte el documento técnico de AWS Aurora Migration Handbook.
Durante esta etapa, puede detectar si la configuración del esquema es poco eficiente en algunos aspectos
como, por ejemplo, en la estrategia de indexación u otras estructuras de tabla como tablas con particiones.
Esta baja eficiencia puede incrementarse si implementa la aplicación en un clúster que tenga numerosas
instancias de base de datos y una carga de trabajo elevada. Decida si debe ajustar ahora estos aspectos
del rendimiento o bien si esperará a actividades posteriores, como la prueba de referencia completa.
6. Importe los datos

Durante la prueba de concepto, tiene que importar los datos, o una muestra representativa de ellos, desde
su antiguo sistema de base de datos. Si es práctico, configure como mínimo algunos datos en cada una
de las tablas. Esto es útil para probar la compatibilidad de todos los tipos de datos y las características
del esquema. Cuando haya probado las características básicas de Aurora, aumente la cantidad de datos.
Cuando termine la prueba de concepto, deberá poder probar sus herramientas de ETL, consultas y carga
de trabajo en general con un conjunto de datos que sea lo suficientemente grande como para obtener
conclusiones precisas.
Para importar los datos de la copia de seguridad lógica o física a Aurora, puede usar varias técnicas.
Para obtener información detallada, consulte Migración de datos a un clúster de base de datos de
Amazon Aurora MySQL (p. 502) o Migración de datos a Amazon Aurora con compatibilidad con
PostgreSQL (p. 772), según el motor de base de datos que use en la prueba de concepto.
Experimente con las tecnologías y las herramientas ETL que esté pensando utilizar. Vea cuáles son las
que mejor se adaptan a sus necesidades. Tenga en cuenta tanto el desempeño como la flexibilidad. Por
ejemplo, algunas herramientas ETL realizan una transferencia única, mientras que otras utilizan una
replicación en curso desde el sistema antiguo hasta Aurora.
Si realiza la migración desde un sistema compatible con MySQL hasta Aurora MySQL, puede usar
las herramientas de transferencia de datos nativas. Es el mismo caso que si migra desde un sistema
compatible con PostgreSQL hasta Aurora PostgreSQL. Si migra desde un sistema de base de datos que
usa un motor subyacente que no es el mismo que el de Aurora, puede experimentar con AWS Database
Migration Service (AWS DMS). Para obtener más detalles acerca de AWS DMS, consulte la Guía del
usuario de AWS Database Migration Service.
Para obtener información detallada sobre las actividades de migración y portabilidad, consulte el
documento técnico de AWS Aurora Migration Handbook.
7. Migre su código SQL

La prueba de SQL y las aplicaciones asociadas es más o menos laboriosa, en función de los diferentes
casos. El nivel de trabajo depende, en concreto, de si la migración se efectúa desde un sistema compatible
con MySQL o PostgreSQL, o desde otro tipo de sistema.
• Si la migración se efectúa desde RDS MySQL o PostgreSQL, los cambios que SQL necesita son tan
pequeños que puede probar el código SQL original con Aurora e incorporar manualmente los cambios
necesarios.

880
8. Especifique las opciones de configuración
• Igualmente, si efectúa la migración desde una base de datos local compatible con MySQL o
PostgreSQL, puede probar el código SQL original e incorporar manualmente los cambios.
• Si realiza la migración desde otra base de datos comercial, los cambios que debe efectuar en SQL son
más extensos. En dicho caso, piense en utilizar AWS SCT.
Durante esta etapa, puede detectar si la configuración del esquema es poco eficiente en algunos aspectos
como, por ejemplo, en la estrategia de indexación u otras estructuras de tabla como tablas con particiones.
Decida si debe ajustar ahora estos aspectos del rendimiento o bien si esperará a actividades posteriores,
como la prueba de referencia completa.
Puede verificar la lógica de conexión de la base de datos en su aplicación. Para aprovechar el

procesamiento distribuido de Aurora, es posible que deba usar conexiones diferentes para las operaciones
de lectura y escritura, así como tener sesiones relativamente cortas para las operaciones de consulta. Para
obtener más información acerca de las conexiones, consulte 9. Conéctese a Aurora (p. 881).
Tenga en cuenta si ha tenido que transigir o hacer concesiones para solucionar problemas en la base de
datos de producción. Integre tiempo en el programa de realización de la prueba de concepto para introducir
mejoras en las consultas y el diseño de esquema. Para evaluar si puede obtener fácilmente beneficios en
el rendimiento, los costos operativos y la escalabilidad, pruebe las aplicaciones original y modificada, una
al lado de la otra, en clústeres de Aurora diferentes.
Para obtener información detallada sobre las actividades de migración y portabilidad, consulte el
documento técnico de AWS Aurora Migration Handbook.
8. Especifique las opciones de configuración

Al efectuar la prueba de concepto de Aurora, tiene la posibilidad también de revisar los parámetros de
configuración de la base de datos. Probablemente la configuración de MySQL o PostgreSQL ya esté
ajustada para el rendimiento y la escalabilidad de su entorno actual. El subsistema de almacenamiento
de Aurora está adaptado y ajustado a un entorno basado en la nube distribuido con un subsistema de
almacenamiento de alta velocidad. En consecuencia, muchas configuraciones de motor de base de datos
antiguas no se pueden aplicar. Le recomendamos que realice los experimentos iniciales con los ajustes de
configuración de Aurora predeterminados. Vuelva a aplicar la configuración de su entorno actual solo si se
producen atascos de rendimiento o de escalabilidad. Si está interesado en este tema, puede profundizar
consultando en la entrada de AWS Database Blog de introducción al motor de almacenamiento de Aurora.
Aurora facilita la reutilización de los ajustes de configuración óptimos para una aplicación o un caso de
uso determinado. En vez de editar un archivo de configuración independiente por cada instancia de base
de datos, administre conjuntos de parámetros que después asignará a clústeres enteros o a instancias
de bases de datos específicas. Por ejemplo, la configuración de la zona horaria se aplica a todas las
instancias de base de datos del clúster, y puede ajustar el valor del tamaño de la memoria caché de la
página para cada instancia de base de datos.
Comience con uno de los conjuntos de parámetros predeterminados y aplique cambios solo a aquellos
parámetros que tenga que ajustar. Para obtener información detallada acerca de cómo trabajar con grupos
de parámetros, consulte Parámetros del clúster de base de datos y la instancia de base de datos Amazon
Aurora (p. 261). Para informarse de los ajustes de configuración que se pueden o no se pueden aplicar
a clústeres de Aurora, consulte Parámetros de Aurora MySQL (p. 678) o Parámetros de Amazon Aurora
PostgreSQL (p. 846) según el motor de base de datos.
9. Conéctese a Aurora
Cuando realice la configuración inicial del esquema y los datos, y ejecute las consultas de ejemplo, verá
que puede conectarse a diferentes puntos de enlace de un clúster de Aurora. El punto de enlace que

881
9. Conéctese a Aurora
use dependerá de si la operación es de lectura, como una instrucción SELECT, o de escritura, como
una instrucción CREATE o INSERT. A medida que aumente la carga de trabajo en un clúster de Aurora y
experimente con características de Aurora, es importante que la aplicación asigne cada operación al punto
de enlace adecuado.
Si usa el punto de enlace del clúster destinado a operaciones de escritura, se conectará siempre a una
instancia de base de datos del clúster que tenga capacidad de lectura-escritura. De forma predeterminada,
solo una instancia de base de datos de un clúster de Aurora tiene capacidad de lectura-escritura. Esta
instancia de la base de datos se conoce como la instancia principal. Si la instancia principal original deja de
esta disponible, Aurora activa un mecanismo de conmutación por error y otra instancia de base de datos
pasa a ocupar el lugar de la principal.
Igualmente, si dirige instrucciones SELECT al punto de enlace del lector, extiende el trabajo de
procesamiento de consultas a las instancias de base de datos del clúster. Cada conexión del lector se
asigna a una instancia de base de datos diferente mediante una resolución DNS de turno rotativo. Si
efectúa la mayor parte del trabajo de consulta en las réplicas de Aurora de base de datos de solo lectura,
reducirá la carga de la instancia principal y la liberará para que pueda gestionar las instrucciones DDL y
DML.
Al utilizar estos puntos de enlace, reducirá la dependencia de los nombres de host no modificables y, al
mismo tiempo, ayudará a la aplicación a recuperarse más rápidamente de los errores de las instancias de
base de datos.
Note
Aurora también tiene puntos de enlace personalizados que usted crea. Normalmente, estos
puntos de enlace no se necesitan durante una prueba de concepto.
Las réplicas de Aurora están sujetas a un retraso de réplica, aunque por lo general dicho retraso sea
de 10 a 20 milisegundos. Puede monitorizar el retraso de replicación y decidir si entra dentro del rango
de requisitos de coherencia de sus datos. A veces, las consultas de lectura pueden necesitar que la
coherencia de lectura sea sólida (coherencia de lectura después de escritura). En dichos casos, puede
seguir utilizando para ellas el punto de enlace del clúster y no el punto de enlace del lector.
Para aprovechar plenamente las capacidades de Aurora para la ejecución en paralelo distribuida, puede
que tenga que cambiar la lógica de conexión. El objetivo es evitar enviar todas las solicitudes de lectura a
la instancia principal. Las réplicas de Aurora de solo lectura están a la espera, listas para hacerse cargo de
las instrucciones SELECT. Codifique la lógica de aplicación para que use el punto de enlace adecuado para
cada tipo de operación. Siga estas instrucciones generales:
• Evite utilizar una única cadena de conexión no modificable para todas las sesiones de base de datos.
• Si es práctico, escriba operaciones como instrucciones DDL o DML en las funciones, en el código de
aplicación cliente. De esta forma, puede hacer que diferentes tipos de operaciones usen conexiones
específicas.
• Cree funciones diferentes para operaciones de consulta. Aurora asigna cada nueva conexión que se
realice al punto de enlace del lector a una réplica de Aurora diferente a fin de equilibrar la carga de las
aplicaciones con un uso elevado de la lectura.
• En el caso de las operaciones que usan conjuntos de consultas, cierre y vuelva a abrir la conexión
al punto de enlace del lector cuando acabe cada conjunto de consultas relacionadas. Agrupe las
conexiones si esta característica está disponible en su pila de software. Dirigir las consultas a diferentes
conexiones ayuda a Aurora a distribuir la carga de trabajo de lectura entre las instancias de bases de
datos del clúster.
Para obtener información general acerca de la administración de conexiones y los puntos de enlace
de Aurora, consulte Conexión a un clúster de base de datos Amazon Aurora (p. 148). Para profundizar
en el tema, consulte Manual de administrador de bases de datos MySQL de Aurora: administración de
conexiones.

882
10. Ejecute la carga de trabajo
10. Ejecute la carga de trabajo

Una vez que haya establecido los valores de esquema, datos y configuración, puede empezar a practicar
con el clúster ejecutando la carga de trabajo. La carga de trabajo que use en la prueba de concepto
debe reflejar los principales aspectos de su carga de trabajo de producción. Le recomendamos que las
decisiones que tome sobre el rendimiento se basen siempre en pruebas y cargas de trabajo reales, y no en
referencias sintéticas como sysbench o TPC-C. Cuando sea práctico, recopile medidas que se basen en su
esquema, sus patrones de consulta y su volumen de uso.
Además de tener en cuenta el aspecto práctico, replique las condiciones reales en las que se ejecutará la
aplicación. Por ejemplo, normalmente se ejecuta el código de aplicación en instancias Amazon EC2, en la
misma región de AWS y en la misma Virtual Private Cloud (VPC) que el clúster de Aurora. Si la aplicación
de producción se ejecuta en varias instancias EC2 que se extienden por varias zonas de disponibilidad,
configure el entorno de la prueba de concepto de la misma manera. Para obtener más información sobre
las regiones de AWS, consulte Regiones y zonas de disponibilidad en la Guía del usuario de Amazon RDS.
Para obtener más información acerca del servicio Amazon VPC, consulte ¿Qué es Amazon VPC? en la
Guía del usuario de Amazon VPC.
Una vez que haya comprobado que las características básicas de su aplicación funcionan y que puede
obtener acceso a los datos a través de Aurora, puede practicar aspectos del clúster de Aurora. Puede que
le interese practicar características como conexiones simultáneas con equilibrio de carga, transacciones
simultáneas y replicaciones automáticas.
Cuando llegue a este punto, debería estar ya familiarizado con los mecanismos de transferencia de datos
y, por lo tanto, poder ejecutar pruebas con una proporción más grande de datos de muestra.
En esta etapa puede estudiar cómo repercuten los cambios en los ajustes de configuración como, por
ejemplo, los límites de memoria o los de conexión. Repase los procedimientos que ha explorado en 8.
Especifique las opciones de configuración (p. 881).
También puede experimentar con mecanismos como la creación y restauración de instantáneas. Por
ejemplo, puede crear clústeres con clases de instancias de AWS diferentes, números de réplicas de
AWS diferentes, etc. Luego, en cada clúster, puede restaurar la misma instantánea que contiene su
esquema y todos los datos. Para obtener información detallada sobre este ciclo, consulte Creación de una
instantánea de clúster de base de datos (p. 317) y Restauración de una instantánea de clúster de base de
datos (p. 319).
11. Medición del rendimiento

Las prácticas recomendadas de esta área están diseñadas para garantizar que se configuren las
herramientas y los procesos adecuados para aislar rápidamente los comportamientos anormales durante
las operaciones de carga de trabajo. También se configuran para que pueda identificar de forma fiable
todas las causes aplicables.
Siempre puede ver el estado actual de su clúster o examinar las tendencias a lo largo del tiempo,
consultando la pestaña Monitoring (Monitorización). Esta pestaña está disponible en la página de detalles
de la consola de cada clúster o de la instancia de base de datos de Aurora. En ella se muestran las
métricas del servicio de monitorización de Amazon CloudWatch en forma de gráficos. Puede filtrar las
métricas por nombre, por instancia de base de datos y por período de tiempo.
Para tener a su disposición más opciones en la pestaña Monitoring (Monitorización), habilite Enhanced
Monitoring (Monitorización mejorada) y Performance Insights (Información sobre rendimiento) en la
configuración del clúster. También puede habilitar más adelante estas opciones si no las ha seleccionado
al configurar el clúster.
El rendimiento se mide principalmente basándose en los gráficos que muestran la actividad de todo el
clúster de Aurora. Puede verificar si las réplicas de Aurora tienen tiempos de carga y respuesta similares.

883
11. Medición del rendimiento
También puede ver cómo se divide el trabajo entre la instancia principal de lectura-escritura y las réplicas
de Aurora de solo lectura. Si detecta un desequilibrio en las instancias de base de datos o un problema
que afecta a una sola instancia de base de datos, consulte la pestaña Monitoring (Monitorización) de la
instancia afectada.
Cuando haya configurado el entorno y la carga de trabajo real para que emulen su aplicación de
producción, podrá evaluar el rendimiento de Aurora. A continuación le indicamos las preguntas más
importantes que tiene que plantearse:
• ¿Cuántas consultas por segundo procesa Aurora? Para saber la respuesta, consulte las métricas de
Throughput (Desempeño) para ver las cifras de diversos tipos de operaciones.
• ¿Cuánto tiempo tarda, en promedio, Aurora en procesar una consulta determinada? Para saber
la respuesta, consulte las métricas de Latency (Latencia) para ver las cifras de diversos tipos de
operaciones.
Para realizar estas consultas, busque la pestaña Monitoring (Monitorización) de un clúster de Aurora
determinado en la consola de RDS, tal y como se indica a continuación.
Si puede hacerlo, establezca valores de referencia para estas métricas en su entorno actual. Si esta
operación no es práctica, cree una base de referencia en el clúster de Aurora ejecutando una carga de
trabajo que sea equivalente a su aplicación de producción. Por ejemplo, ejecute su carga de trabajo de
Aurora con un número similar de usuarios y consultas simultáneos. Luego observe cómo cambian los
valores a medida que va experimentando con diferentes clases de instancias, tamaños de clúster, ajustes
de configuración, etc.
Si los resultados del desempeño no están a la altura de lo que esperaba, profundice en la investigación de
los factores que repercuten en el rendimiento de la base de datos para su carga de trabajo. Igualmente, si
las cifras de la latencia son superiores a lo que esperaba, profundice en las causas. Para ello, monitorice

884
12. Pruebe la alta disponibilidad de Aurora
las métricas secundarias del servidor de base de datos (CPU, memoria, etc.). De esta forma podrá ver
si las instancias de base de datos están próximas a sus límites. También podrá saber cuánta capacidad
adicional les queda a las instancias de bases de datos para gestionar más consultas simultáneas,
consultas para tablas más grandes, etc.
Tip
Para detectar valores de métricas que se salen de los rangos previstos, configure alarmas de
CloudWatch.
Cuando evalúe la capacidad y el tamaño de clúster ideales de Aurora, puede encontrar la configuración
que obtiene el rendimiento máximo de la aplicación sin aprovisionar recursos en exceso. En este sentido,
un factor importante es encontrar el tamaño adecuado de las instancias de base de datos de clúster de
Aurora. Comience seleccionando un tamaño de instancia cuya capacidad de memoria y CPU sea similar a
la de su entorno de producción actual. Recopile las cifras de desempeño y latencia de la carga de trabajo
con ese tamaño de instancia. Luego, escale el tamaño al siguiente tamaño más grande. Compruebe si los
resultados del desempeño y la latencia mejoran. Reduzca también el tamaño de la instancia para ver si
los resultados de la latencia y el desempeño siguen siendo los mismos. Su objetivo es obtener el máximo
desempeño, con el nivel de latencia más bajo, en la instancia más pequeña posible.
Tip
Dé a los clústeres de Aurora y a las instancias de base de datos la capacidad suficiente como
para poder gestionar los picos de tráfico repentinos e impredecibles. Para las bases de datos
críticas para el trabajo, deje como mínimo un 20 % de espacio de CPU y de capacidad de
memoria libre.
Ejecute pruebas de rendimiento el tiempo suficiente como para medir el rendimiento de la base de datos
en un estado constante y flexible. Puede que tenga que ejecutar la carga de trabajo durante varios minutos
o incluso unas cuantas horas para llegar a este estado constante. Es normal que, al principio de una
ejecución, haya algunas variaciones. Estas variaciones se deben a que cada réplica de Aurora activa sus
cachés en función de las consultas SELECT que gestiona.
El mejor rendimiento de Aurora se obtiene con cargas de trabajo transaccionales en las que hay
numerosos usuarios y consultas simultáneos. Para asegurarse de que la carga sea suficiente para un
rendimiento óptimo, ejecute referencias con multiprocesos, o bien ejecute varias instancias de las pruebas
de rendimiento a la vez. Mida el rendimiento con centenares o incluso miles de subprocesos cliente a la
vez. Simule el número de subprocesos simultáneos que prevé tener en su entorno de producción. También
puede ejecutar pruebas de estrés adicionales con más subprocesos para medir la escalabilidad de Aurora.

Muchas de las principales características de Aurora tienen una alta disponibilidad. Se trata de las
características de replicación automática, conmutación por error automática, copia de seguridad
automática con restauración a un momento dado y capacidad para añadir instancias de base de datos al
clúster. La seguridad y la fiabilidad de dichas características es importante para las aplicaciones críticas.
La evaluación de estas características requiere adoptar una visión específica. En las actividades
anteriores, como la medición del rendimiento, se observaba el rendimiento del sistema cuando todo
funcionaba correctamente. Sin embargo, para probar la alta disponibilidad, es preciso enfocar la
observación desde el estudio de las peores situaciones que puedan producirse. Ha de tener en cuenta
distintos tipos de errores, incluso si tales casos son excepcionales. Por ejemplo, puede introducir
problemas a propósito para asegurarse de que el sistema se recupere deprisa y correctamente.
Tip
Para una prueba de concepto, configure todas las instancias de base de datos de un clúster de
Aurora con la misma clase de instancia de AWS. Con ello, será posible probar las características

885
de disponibilidad de Aurora sin grandes cambios en el rendimiento ni la escalabilidad, ya que saca

fuera de línea las instancias de base de datos para simular los errores.
Le recomendamos que use como mínimo dos instancias en cada clúster de Aurora. Las instancias de base
de datos de un clúster de Aurora pueden extenderse hasta un máximo de tres zonas de disponibilidad
(AZ). Ubique las dos o tres primeras instancias de base de datos de cada AZ diferente. Cuando comience
a utilizar clústeres más grandes, extienda sus instancias de base de datos a todas las AZ de la región de
AWS. Al hacerlo aumentará su capacidad de tolerancia a errores. Aunque un problema afecte a una AZ
entera, Aurora puede realizar una conmutación por error a una instancia de base de datos de otra AZ. Si
tiene un clúster con más de tres instancias, distribuya las instancias de base de datos de la forma más
homogénea posible entre las tres AZ.
Tip
El almacenamiento de un clúster de Aurora no depende de las instancias de base de datos. El

almacenamiento de cada clúster de Aurora se extiende siempre a tres AZ.
Cuando pruebe las características de alta disponibilidad, use siempre instancias de base de
datos con capacidad idéntica en el clúster de prueba. Con esto evitará cambios imprevistos en el
rendimiento, la latencia, etc. siempre que una instancia de base de datos sustituya a otra.
Para aprender a simular condiciones de error para probar las características de alta disponibilidad,
consulte Pruebas de Amazon Aurora por medio de consultas de inserción de errores (p. 561).
En la ejecución de la prueba de concepto, uno de los objetivos es encontrar el número ideal de instancias
de bases de datos y la clase de instancia óptima para dichas instancias de base de datos. Para ello, tiene
que equilibrar los requisitos de alta disponibilidad y rendimiento.
En Aurora, cuantas más instancias de bases de datos tenga en un clúster, más beneficiada saldrá la
alta disponibilidad. Si tiene más instancias de base de datos, mejorará también la escalabilidad de las
aplicaciones que realicen un uso intensivo de la lectura. Aurora puede distribuir numerosas conexiones
para consultas SELECT entre las réplicas de Aurora de solo lectura.
Por otra parte, si limita el número de instancias de base de datos reducirá el tráfico de replicación desde
el nodo principal. El tráfico de replicación consume ancho de banda de red, que es otro aspecto del
rendimiento y la escalabilidad generales. Por lo tanto, para las aplicaciones OLTP de uso intensivo de
escritura, es mejor que se incline por un número más pequeño de instancias de base de datos grandes
que por muchas instancias de base de datos pequeñas.
En un clúster de Aurora típico, una instancia de base de datos (la instancia principal) gestiona todas
las instrucciones DDL y DML. Las demás instancias de base de datos (las réplicas de Aurora) solo se
encargan de las instrucciones SELECT. Aunque las instancias de base de datos no realizan exactamente la
misma cantidad de trabajo, recomendamos que use la misma clase de instancia para todas las instancias
de base de datos del clúster. Así, si se produce un error y Aurora promociona una instancia de base de
datos de solo lectura como la nueva instancia principal, dicha instancia principal tendrá la misma capacidad
que antes.
Si tiene que utilizar instancias de base de datos con capacidades diferentes en el mismo clúster, configure
niveles de conmutación por error para las instancias de base de datos. Estos niveles determinarán el
orden de promoción de las réplicas de Aurora mediante el mecanismo de conmutación por error. Ponga
las instancias de base de datos que sean mucho más grandes o pequeñas que las demás en un nivel de
conmutación por error más bajo. Así se asegurará de que se sean las últimas en ser elegidas para una
promoción.
Practique las características de recuperación de datos de Aurora, como la restauración automática a

un momento dado, las instantáneas manuales y su restauración, y el backtracking de clústeres. Si es
pertinente, copie instantáneas en otras regiones de AWS y restáurelas en otras regiones de AWS para
imitar escenarios de recuperación de desastres (DR).
Investigue los requisitos de su organización para los objetivos de tiempo de recuperación (RTO), los
objetivos de punto de recuperación (RPO) y la redundancia geográfica. La mayoría de las organizaciones

886
13. Qué hacer a continuación
agrupan estos elementos en la categoría más general de recuperación de desastres. Evalúe las
características de alta disponibilidad de Aurora descritas en esta sección en el contexto de su proceso de
recuperación de desastres, a fin de asegurarse de que los requisitos de RTO y RPO se cumplan.

Al finalizar un proceso de prueba de concepto realizado correctamente, confirmará que Aurora es una
solución adecuada para usted basándose en la carga de trabajo prevista. A lo largo del proceso anterior,
ha comprobado cómo funciona Aurora en un entorno operativo realista y ha medido su funcionamiento de
acuerdo con sus criterios de éxito.
Después de configurar su entorno de base de datos y ejecutarlo con Aurora, puede pasar a los pasos
de evaluación más detallados que lo conducirán a la migración e implementación de producción finales.
Según cuál sea su situación, dichos pasos adicionales se incluirán o no en el proceso de prueba de
concepto. Para obtener información detallada sobre las actividades de migración y portabilidad, consulte el
documento técnico de AWS Manual de migración de Aurora.
En otro paso adicional, estudie las configuraciones de seguridad adecuadas para su carga de trabajo y
diseñadas para cumplir los requisitos de seguridad de un entorno de producción. Planifique los controles
que deben implantarse para proteger el acceso a las credenciales de usuario maestro del clúster de
Aurora. Defina los roles y las responsabilidades de los usuarios de la base de datos para controlar el
acceso a los datos almacenados en el clúster de Aurora. Tenga en cuenta los requisitos de acceso a
la base de datos de las aplicaciones, scripts y herramientas o servicios de terceros. Explore servicios
y características de AWS como AWS Secrets Manager y la autenticación de AWS Identity and Access
Management (IAM).
Cuando llegue a este punto, debería conocer los procedimientos y las prácticas recomendadas para
ejecutar pruebas de referencia con Aurora. Puede darse el caso de que necesite realizar un ajuste
adicional del rendimiento. Para obtener información detallada, consulteAdministración del desempeño y
el escalado para clústeres de base de datos Aurora (p. 257), Mejoras de desempeño de Amazon Aurora
MySQL (p. 496), Administración de Amazon Aurora PostgreSQL (p. 795) y Uso de Performance Insights de
Amazon RDS (p. 402). Si realiza un ajuste adicional, tiene que estar familiarizado con las métricas que ha
recopilado durante la prueba de concepto. En un paso siguiente, podría tener que crear clústeres nuevos
con opciones diferentes para los ajustes de configuración, el motor de base de datos y la versión de la
base de datos. O bien, podría tener que crear tipos especializados de clústeres de Aurora para adaptarse a
las necesidades de casos de uso específicos.
Por ejemplo, puede explorar clústeres de consulta en paralelo de Aurora para aplicaciones de
procesamiento de transacciones híbridas o procesamiento analítico (HTAP). Si una distribución geográfica
extensa es fundamental para la recuperación de desastres o para minimizar la latencia, puede explorar
bases de datos globales de Aurora. Si su carga de trabajo es intermitente o utiliza Aurora en un escenario
de desarrollo y prueba, puede explorar clústeres de Aurora Serverless.
Sus clústeres de producción también podrán necesitar grandes volúmenes de conexiones de entrada. Para
aprender dichas técnicas, consulte el documento técnico de AWS Manual de administrador de bases de
datos MySQL de Aurora: administración de conexiones.
Si, después de la prueba de concepto, decide que su caso de uso no es adecuado para Aurora, considere
los siguientes servicios de AWS:
• Para casos de uso estrictamente analíticos, las cargas de trabajo disponen de un formato de
almacenamiento en columnas y otras características más adecuadas para cargas de trabajo OLAP. Los
servicios de AWS que tratan estos casos de uso son los siguientes:
• Amazon Redshift
• Amazon EMR
• Amazon Athena

887
• Muchas cargas de trabajo disponen de una combinación de Aurora con uno o varios de estos servicios.
Puede mover datos entre estos servicios con los siguientes productos:
• AWS Glue.
• AWS DMS.
• Importación desde Amazon S3, tal y como se describe en la Guía del usuario de Amazon Aurora .
• Exportación a Amazon S3, tal y como se describe en la Guía del usuario de Amazon Aurora.
• Numerosas herramientas ETL conocidas más.

888
Límites en Amazon Aurora
Límites de Amazon Aurora

En este tema se describen los límites de recursos y las restricciones de nomenclatura para Amazon
Aurora.
Temas
• Límites en Amazon Aurora (p. 889)
• Restricciones de la nomenclatura en Amazon Aurora (p. 890)
• Límites de tamaño de archivo de Amazon Aurora (p. 891)
Límites en Amazon Aurora

Cada cuenta de AWS tiene límites del número de recursos de Amazon Aurora que se pueden crear por
cada región de AWS. Una vez que se alcance el límite de un recurso, las llamadas adicionales para crear
ese recurso dejan de funcionar con una excepción.
En la siguiente tabla se muestran los recursos y sus límites por región.
Recurso Límite predeterminado
Clústeres 40
Grupos de parámetros de clústeres 50
Solicitudes de copia de instantáneas entre regiones 5
Instancias de base de datos 40
Suscripciones de eventos 20
Instantáneas manuales 100
Instantáneas de clústeres manuales 100
Grupos de parámetros 50
Instancias reservadas 40
Reglas por grupo de seguridad de VPC 50 de entrada y 50 de

salida
Grupos de seguridad de la VPC 5
Grupos de subredes 50
Subredes por grupo de subredes 20
Etiquetas por recurso 50
Note
De forma predeterminada, puede tener un total de 40 instancias de base de datos. Si su

aplicación requiere más instancias de base de datos, puede solicitar instancias de base de datos

889
Restricciones de la nomenclatura en Amazon Aurora
adicionales usando mediante el formulario de solicitud Solicitar límite de instancia de base de

datos de RDS.
Restricciones de la nomenclatura en Amazon

Aurora
En la siguiente tabla se describen las restricciones de la nomenclatura en Amazon Aurora.
DB instance identifier • Debe contener de 1 a 63 caracteres alfanuméricos o

guiones.
consecutivos.
• Debe ser único para todas las instancias de base de datos
por cada cuenta de AWS y por cada región.
Nombre de base de datos Las restricciones de los nombres de base de datos difieren
para cada motor de base de datos.
Amazon Aurora MySQL
• Debe contener de 1 a 64 caracteres alfanuméricos.

• No puede ser una palabra reservada por el motor de base
de datos.

• Debe comenzar con una letra o un guion bajo. Los
caracteres subsiguientes pueden ser letras, guiones bajos o
dígitos (0-9).
de datos.
Nombre de usuario maestro Las restricciones de los nombres de usuario maestros difieren
para cada motor de base de datos.
Amazon Aurora MySQL

de datos.

de datos.

890
Límites de tamaño de archivo de Amazon Aurora
Contraseña maestra La contraseña del usuario de base de datos maestro puede

ser cualquier carácter ASCII imprimible, excepto "/", """ o "@".
Las restricciones de las contraseñas difieren para cada motor
de base de datos.
Amazon Aurora MySQL
• Debe contener entre 8 y 41 caracteres.
• Debe contener entre 8 y 128 caracteres.
Nombre del grupo de parámetros de • Debe contener de 1 a 255 caracteres alfanuméricos.

base de datos • El primer carácter debe ser una letra.
• Los guiones están permitidos, pero el nombre no puede
terminar por un guion o contener dos guiones seguidos.
Nombre del grupo de subred de DB • Debe contener de 1 a 255 caracteres.

• Se permiten los caracteres alfanuméricos, guiones, guiones
bajos y puntos.
Límites de tamaño de archivo de Amazon Aurora

Con Aurora, el límite de tamaño de la tabla solo está restringido por el tamaño del volumen de clúster de
Aurora. Por tanto, el tamaño máximo de una tabla en un clúster de base de datos Aurora MySQL es de 64
tebibytes (TiB) y para un clúster de base de datos Aurora PostgreSQL es de 32 TiB. Le recomendamos
que siga estas prácticas recomendadas de diseño de tabla, como la partición de tablas grandes.

891
No puede conectarse a la instancia de base de datos
Solución de problemas de Aurora

Utilice las siguientes secciones como ayuda para solucionar los problemas que puedan presentarse con
instancias de base de datos en Amazon RDS y Aurora.
Temas
• No puede conectarse a la instancia de base de datos de Amazon RDS (p. 892)
• Problemas de seguridad de Amazon RDS (p. 893)
• Restablecimiento de la contraseña del rol del propietario de la instancia de base de datos (p. 894)
• Interrupción o reinicio de una instancia de base de datos de Amazon RDS (p. 894)
• Los cambios de parámetros de base de datos de Amazon RDS no surten efecto (p. 895)
• Problemas de memoria insuficiente de Amazon Aurora MySQL (p. 895)
• Problemas de replicación de Amazon Aurora MySQL (p. 896)
• Error de falta de espacio en el dispositivo (p. 899)
Para obtener información sobre los problemas de depuración del uso de la API de Amazon RDS, consulte
Solución de problemas de aplicaciones en Aurora (p. 901).
No puede conectarse a la instancia de base de

datos de Amazon RDS
Cuando no puede conectarse a una instancia de base de datos, estas suelen ser las causas habituales:
• Las reglas de acceso impuestas por el firewall local y las direcciones IP de entrada a las que autorizó el
acceso a su instancia de base de datos en el grupo de seguridad de la instancia no están sincronizadas.
Lo más probable es que el problema se encuentre en las reglas de entrada de su grupo de seguridad.
De manera predeterminada, las instancias de base de datos no permiten el acceso; este se concede
a través de un grupo de seguridad. Para conceder el acceso, debe crear su propio grupo de seguridad
con reglas de entrada y salida específicas para la situación. Si es necesario, añada reglas al grupo de
seguridad asociado con la VPC que permita el tráfico entrante y saliente de la instancia de base de datos
a la fuente. Puede especificar una dirección IP, un rango de direcciones IP u otro grupo de seguridad de
VPC.
Para obtener más información acerca de la configuración de un grupo de seguridad, consulte

Proporcionar acceso al clúster de base de datos en la VPC mediante la creación de un grupo de
seguridad (p. 53).
• El puerto que especificó cuando creó la instancia de base de datos no puede usarse para enviar o recibir
comunicaciones debido a las restricciones del firewall local. En este caso, consulte al administrador de
red para determinar si su red permite el uso del puerto especificado para comunicación de entrada y
salida.
• La instancia de base de datos está en proceso de creación y aún no está disponible. Dependiendo del
tamaño de la instancia de base de datos, es posible que la instancia tarde hasta 20 minutos en estar
disponible.

892
Comprobar la conexión a la instancia de base de datos
Comprobar una conexión a una instancia de base de

datos de Amazon RDS
Puede comprobar la conexión a una instancia de base de datos con herramientas habituales de Windows
o Linux.
Desde un terminal de Linux o Unix, puede comprobar la conexión escribiendo lo siguiente (sustituya <DB-
instance-endpoint> por el punto de conexión y <port> por el puerto de su instancia de base de
datos):
nc -zv <DB-instance-endpoint> <port>
Por ejemplo, a continuación se muestra un comando de ejemplo y el valor de retorno:
nc -zv postgresql1.c6c8mn7tsdgv0.us-west-2.rds.amazonaws.com 8299
Connection to postgresql1.c6c8mn7tsdgv0.us-west-2.rds.amazonaws.com 8299 port [tcp/vvr-

data] succeeded!
Los usuarios de Windows pueden usar Telnet para comprobar la conexión a una instancia de base de
datos. Tenga en cuenta que las acciones de Telnet solo se admiten para la comprobación de la conexión.
Si la conexión es correcta, la acción no devuelve ningún mensaje. Si la conexión no es correcta, recibe un
mensaje de error como el siguiente:
C:\>telnet sg-postgresql1.c6c8mntzhgv0.us-west-2.rds.amazonaws.com 819
Connecting To sg-postgresql1.c6c8mntzhgv0.us-west-2.rds.amazonaws.com...Could not open

connection to the host, on port 819: Connect failed
Si las acciones de Telnet indican que la conexión es correcta, el grupo de seguridad se ha configurado
correctamente.
Note
Amazon RDS no acepta el tráfico del Protocolo de mensaje de control de Internet (ICMP), ping
incluido.
Solución de problemas de autenticación de conexión

Si puede conectarse a su instancia de base de datos, pero recibe errores de autenticación, sería
aconsejable restablecer la contraseña de usuario maestro para la instancia de base de datos. Puede
hacerlo modificando la instancia de RDS.
Problemas de seguridad de Amazon RDS

Para evitar problemas de seguridad, no utilice nunca su nombre de usuario maestro de AWS y contraseña
para una cuenta de usuario. La práctica recomendada es que utilice su cuenta maestra de AWS para
crear usuarios de IAM y que los asigne a cuentas de usuarios de base de datos. También puede utilizar su
cuenta maestra para crear, si fuera necesario, otras cuentas de usuario.
Para obtener más información sobre la creación de usuarios de IAM, consulte Creación de un usuario de
IAM (p. 50).

893
Mensaje de error "No se pudieron recuperar los
atributos de cuenta. Determinadas funciones
de la consola pueden estar deterioradas".
Mensaje de error "No se pudieron recuperar los

atributos de cuenta. Determinadas funciones de la
consola pueden estar deterioradas".
Existen varios motivos por los que podría obtener este error. Podría ser porque a su cuenta le faltan
permisos o porque no se ha configurado correctamente la cuenta. Si su cuenta es nueva, es posible que
no haya esperado a que esté lista. Si se trata de una cuenta existente, podría carecer de permisos en sus
políticas de acceso para realizar determinadas acciones, como crear una instancia de base de datos. Para
solucionar este problema, el administrador de IAM debe proporcionar los roles necesarios a su cuenta.
Para obtener más información, consulte la documentación de IAM.
Restablecimiento de la contraseña del rol del

propietario de la instancia de base de datos
Puede restablecer los permisos asignados para la instancia de base de datos restableciendo la contraseña
maestra. Por ejemplo, si se queda sin acceso al rol db_owner en la base de datos SQL Server, puede
restablecer la contraseña del rol db_owner modificando la contraseña maestra de la instancia de base
de datos. Cambiar la contraseña de la instancia de base de datos le permitirá obtener de nuevo acceso a
la instancia de base de datos, obtener acceso a las bases de datos usando la contraseña modificada de
db_owner y restaurar los privilegios del rol db_owner que puedan haber sido revocados accidentalmente.
La contraseña de la instancia de base de datos se puede cambiar por medio de la consola de Amazon
RDS, el comando modify-db-instance de la AWS CLI o la acción ModifyDBInstance.
Interrupción o reinicio de una instancia de base de

datos de Amazon RDS
Una interrupción de instancia de base de datos puede producirse al reiniciar una instancia de base de
datos, cuando dicha instancia se pone en un estado que impide el acceso a ella y cuando se reinicia la
base de datos. El reinicio puede producirse cuando reinicia manualmente su instancia de base de datos o
cuando cambia una configuración de base de datos que exige un reinicio para surtir efecto.
Cuando se modifica una configuración para una instancia de base de datos, puede determinar cuándo se
aplica el cambio utilizando la configuración Apply Immediately.
El reinicio de una instancia de base de datos solo se produce cuando cambia una configuración que exige
un reinicio o cuando efectúa un reinicio manualmente. El reinicio puede producirse inmediatamente si
cambia una configuración y solicita que el cambio surta efecto de inmediato, o bien puede producirse
durante el período de mantenimiento de la instancia de base de datos.
El reinicio de la instancia de base de datos se produce inmediatamente en una de las siguientes

situaciones:
• El usuario cambia el período de retención de copia de seguridad de una instancia de base de datos, de
cero a un valor distinto de cero o viceversa, y Apply Immediately se establece en true.
• El usuario cambia la clase de la instancia de base de datos y Apply Immediately se establece en true.
El reinicio de la instancia de base de datos se produce durante el período de mantenimiento en una de las
siguientes situaciones:

894
Los cambios de parámetros no surten efecto
• El usuario cambia el período de retención de copia de seguridad de una instancia de base de datos, de
cero a un valor distinto de cero o viceversa, y Apply Immediately se establece en false.
• El usuario cambia la clase de la instancia de base de datos y Apply Immediately se establece en false.
Cuando se cambia un parámetro estático en un grupo de parámetros de base de datos, el cambio no

surtirá efecto hasta que se reinicie la instancia de base de datos asociada al grupo. El cambio requiere
un reinicio manual; la instancia de base de datos no se reiniciará automáticamente durante el período de
mantenimiento.
Los cambios de parámetros de base de datos de

Amazon RDS no surten efecto
Si cambia un parámetro en un grupo de parámetros de base de datos, pero observa que los cambios
no surten efecto, lo más probable es que deba reiniciar la instancia de base de datos asociada al grupo.
Cuando se cambia un parámetro dinámico, el cambio surtirá efecto inmediatamente; cuando cambie un
parámetro estático, el cambio no surtirá efecto hasta que se reinicie la instancia de base de datos asociada
al grupo de parámetros.
Puede reiniciar una instancia de base de datos utilizando la consola de RDS o llamando explícitamente
a la acción RebootDbInstance de la API (sin conmutación por error, si la instancia de base de datos
está en un Multi-AZ deployment). El requisito de reiniciar la instancia de base de datos asociada después
de cambiar los parámetros estáticos ayuda a mitigar el riesgo de que una configuración errónea de
parámetros afecte a una llamada a la API como, por ejemplo, llamar a ModifyDBInstance para
cambiar la clase de instancia de base de datos. Para obtener más información, consulte Modificación de
parámetros de un grupo de parámetros de base de datos (p. 265).
Problemas de memoria insuficiente de Amazon

Aurora MySQL
El parámetro de nivel de instancia aurora_oom_response de Aurora MySQL puede permitir que
la instancia de base de datos monitoricela memoria del sistema y calcule la memoria consumida por
diferentes declaraciones y conexiones. Si el sistema funciona con poca memoria, puede realizar una lista
de acciones para liberar esa memoria para tratar de evitar reinicios de la base de datos y provocados por
falta de memoria (OOM). El parámetro de nivel de instancia toma una cadena de acciones separadas por
comas que una instancia de base de datos debe realizar cuando el nivel de memoria es bajo. Entre las
acciones válidas se encuentran print, tune, decline, kill_query o cualquier combinación de estas.
La existencia de una cadena vacía significa que no se deberían haber tomado acciones y deshabilita de
forma eficaz la característica.
Los siguientes ejemplos de uso corresponden al parámetro aurora_oom_response:
• print: solo imprime las consultas que consumen una gran cantidad de memoria.
• tune: ajusta las cachés de tablas internas para liberar memoria en el sistema.
• decline: declina nuevas consultas una vez que la instancia tiene poca memoria.
• kill_query: anula las consultas en orden descendente de consumo de memoria hasta que la memoria
de la instancia esté por encima del umbral bajo. No se anulan as instrucciones DDL.
• print, tune: realiza acciones descritas para print y tune.
• tune, decline, kill_query: realiza las acciones descritas para tune, decline y kill_query.

895
Problemas de replicación de Aurora MySQL
Para las clases de instancia de base de datos db.t2 el parámetro aurora_oom_response se establece
en print, tune de forma predeterminada. Para todas las demás clases de instancia de base de datos,
el valor del parámetro está vacío de forma predeterminada (deshabilitado).
Problemas de replicación de Amazon Aurora

MySQL
Algunos problemas de replicación de MySQL y MariaDB también se aplican a Aurora MySQL. Puede
diagnosticar y corregir estos problemas.
Diagnóstico y resolución de retardos entre réplicas de

lectura
Después de crear una réplica de lectura de MySQL o MariaDB y de que dicha réplica esté disponible,
Amazon RDS replica en primer lugar los cambios realizados en la instancia de base de datos de origen
desde el momento en que se inició la operación de creación de la réplica. Durante esta fase, el retardo
de la replicación para la réplica de lectura será mayor que 0. También puede monitorizar este retardo en
Amazon CloudWatch viendo la métrica AuroraBinlogReplicaLag de Amazon RDS.
La métrica AuroraBinlogReplicaLag indica el valor del campo Seconds_Behind_Master del

comando SHOW SLAVE STATUS de MySQL o MariaDB. Para obtener más información, consulte SHOW
SLAVE STATUS. Cuando la métrica AuroraBinlogReplicaLag llegue a 0, la réplica estará funcionando
al mismo ritmo que la instancia de base de datos de origen. Si la métrica AuroraBinlogReplicaLag
devuelve -1, la replicación podría no estar activa. Para solucionar problemas de error de replicación,
consulte Diagnóstico y resolución de un error de replicación de lectura de MySQL o MariaDB (p. 897). Un
valor AuroraBinlogReplicaLag de -1 también puede significar que el valor Seconds_Behind_Master
no se puede determinar o es NULL.
La métrica AuroraBinlogReplicaLag devuelve -1 durante una interrupción de la red o cuando

se aplica un parche durante el período de mantenimiento. En este caso, espere a que se restaure la
conectividad de la red o a que finalice el período de mantenimiento antes de volver a comprobar la métrica
AuroraBinlogReplicaLag.
Como la tecnología de replicación de lectura de MySQL y MariaDB es asíncrona, se deben esperar

aumentos ocasionales de la métrica BinLogDiskUsage en la instancia de base de datos de origen y de
la métrica AuroraBinlogReplicaLag en la réplica de lectura. Por ejemplo, puede darse un volumen
elevado de operaciones de escritura en la instancia de base de datos de origen en paralelo, mientras
que las operaciones de escritura en la réplica de lectura se serializan usando un único subproceso E/
S, y pueden generar un retardo entre la instancia de origen y la réplica de lectura. Para obtener más
información acerca de las réplicas de lectura y MySQL, consulte Replication Implementation Details en la
documentación de MySQL. Para obtener más información acerca de las réplicas de lectura y MariaDB,
vaya a Replication Overview en la documentación de MariaDB.
Puede hacer varias cosas para reducir el retardo entre las actualizaciones de una instancia de base de
datos de origen y las actualizaciones posteriores de la réplica de lectura:
• Configure la clase de instancia de base de datos de la réplica de lectura para que tenga un tamaño de
almacenamiento comparable al de la instancia de base de datos de origen.
• Asegúrese de que la configuración de parámetros de los grupos de parámetros de base de datos
utilizados en la instancia de base de datos de origen y la réplica de lectura sean compatibles. Para
obtener más información y un ejemplo, consulte el análisis del parámetro max_allowed_packet en la
siguiente sección.

896
Diagnóstico y resolución de un error de
replicación de lectura de MySQL o MariaDB
• Deshabilite la caché de consultas. Para tablas que se modifican a menudo, el uso de la caché de
consultas puede aumentar el retardo de réplica porque la caché se bloquea y actualiza con frecuencia.
Si esto fuera así, podría ver menos retardo de réplica si deshabilita la caché de consultas. Puede
deshabilitar la caché de consultas estableciendo query_cache_type parameter en 0 en el grupo de
parámetros de base de datos para la instancia de base de datos. Para obtener más información sobre la
caché de consultas, consulte Query Cache Configuration.
• Prepare el grupo del búfer en la réplica de lectura para InnoDB para MySQL, InnoDB para MariaDB
10.2 o superior, o XtraDB para MariaDB 10.1 o inferior. Si tiene un conjunto pequeño de tablas que se
actualiza con frecuencia y está utilizando el esquema de tablas InnoDB o XtraDB, puede volcar esas
tablas en la réplica de lectura. Al hacer esto, el motor de base de datos examina las filas de esas tablas
desde el disco y, a continuación, las almacena en la caché en el grupo del búfer, que puede reducir el
retardo de réplica. A continuación se muestra un ejemplo.
PROMPT> mysqldump \
-h <endpoint> \
--port=<port> \
-u=<username> \
-p <password> \
database_name table1 table2 > /dev/null
Para Windows:
PROMPT> mysqldump ^
-h <endpoint> ^
--port=<port> ^
-u=<username> ^
-p <password> ^
database_name table1 table2 > /dev/null
Diagnóstico y resolución de un error de replicación de

lectura de MySQL o MariaDB
Amazon RDS monitoriza el estado de la replicación de las réplicas de lectura. Actualiza el campo
Replication State (Estado de replicación) de la instancia de la réplica de lectura a Error si la replicación
se detiene por cualquier motivo. Puede revisar los detalles del error asociado que muestran los motores
de MySQL o MariaDB visualizando el campo Replication Error. También se generan eventos que
indican el estado de la réplica de lectura, entre los que se incluyen RDS-EVENT-0045 (p. 471), RDS-
EVENT-0046 (p. 471) y RDS-EVENT-0047 (p. 470). Para obtener más información acerca de los eventos
y la suscripción a ellos, consulte Uso de las notificaciones de eventos de Amazon RDS (p. 465). Si
aparece un mensaje de error de MySQL, revise el error en la documentación sobre los mensajes de error
de MySQL. Si aparece un mensaje de error de MariaDB, revise el error en la documentación sobre los
mensajes de error de MariaDB.
Estas son algunas de las situaciones comunes que pueden causar errores de replicación:
• El valor para el parámetro max_allowed_packet es inferior al parámetro max_allowed_packet para

la instancia de base de datos de origen.
El parámetro max_allowed_packet es un parámetro personalizado que se puede definir en un

grupo de parámetros de base de datos y que se usa para especificar el tamaño máximo de lenguaje
de manipulación de datos (DML) que se puede ejecutar en la base de datos. Si el valor del parámetro
max_allowed_packet para la instancia de base de datos de origen el inferior al valor del parámetro
max_allowed_packet para la réplica de lectura, el proceso de replicación puede generar un error

897
Error Slave Down or Disabled
y detener la replicación. El error más común es packet bigger than 'max_allowed_packet'

bytes. Puede resolver el error haciendo que el origen y la réplica de lectura usen grupos de parámetros
de base de datos con los mismos valores del parámetro max_allowed_packet.
• Escritura en tablas en una réplica de lectura. Si desea crear índices en una réplica de lectura, debe
establecer el parámetro read_only en 0 para crear los índices. Si se escribe en las tablas de la réplica
de lectura, puede interrumpirse la replicación.
• Uso de un motor de almacenamiento no transaccional como MyISAM. Las réplicas de lectura requieren
un motor de almacenamiento transaccional. La replicación solo se admite para los siguientes motores de
almacenamiento: InnoDB para MySQL, InnoDB para MariaDB 10.2 o superior, o XtraDB para MariaDB
10.1 o inferior.
Puede convertir una tabla MyISAM a InnoDB con el siguiente comando:
alter table <schema>.<table_name> engine=innodb;

• Uso de consultas no deterministas que no sean seguras, como SYSDATE(). Para obtener más
información, consulte Determination of Safe and Unsafe Statements in Binary Logging.
Los siguientes pasos pueden ayudar a solucionar su error de replicación:
• Si se encuentra ante un error lógico y decide que es seguro hacer caso omiso, siga los pasos que se
describen en Omisión del error de replicación actual. La instancia de base de datos MySQL o MariaDB
debe estar ejecutando una versión que incluya el procedimiento mysql_rds_skip_repl_error. Para
obtener más información, consulte mysql_rds_skip_repl_error.
• Si se encuentra ante un problema de posición de binlog, puede cambiar la posición de repetición del
esclavo con el comando mysql_rds_next_master_log. La instancia de base de datos MySQL o
MariaDB debe estar ejecutando una versión que admita el comando mysql_rds_next_master_log
para cambiar la posición de repetición del esclavo. Para obtener información sobre la versión, consulte
mysql_rds_next_master_log.
• Si se encuentra ante un problema de desempeño temporal debido a una carga de DML elevada, puede
establecer el parámetro innodb_flush_log_at_trx_commit en 2 en el grupo de parámetros de
base de datos en la réplica de lectura. Hacer esto puede ayudar a la réplica de lectura a ponerse al
corriente, si bien reduce temporalmente las propiedades de atomicidad, coherencia, aislamiento y
durabilidad (ACID).
• Puede eliminar la réplica de lectura y crear una instancia usando el mismo identificador de instancias
de bases de datos. De este modo, el punto de conexión seguirá siendo el mismo que en la réplica de
lectura antigua.
Si se corrige un error de replicación, Replication State cambia a replicating. Para obtener más información,
consulte Solución de problemas de una réplica de lectura de MySQL o MariaDB.
Error Slave Down or Disabled

Cuando se llama al comando mysql.rds_skip_repl_error, puede aparecer el siguiente mensaje de
error: Slave is down or disabled.
Este mensaje de error aparece porque la replicación se ha detenido y no se puede reiniciar.
Si tiene que omitir un número de errores elevado, el retardo de réplica puede aumentar por encima
del periodo de retención predeterminado para los archivos de registro binarios. En este caso, puede
producirse un error fatal debido a que los archivos de registro binario se están limpiando antes de
reproducirse de nuevo en la réplica. Esta limpieza hace que la replicación se detenga y ya no se puede
llamar al comando mysql.rds_skip_repl_error para omitir los errores de replicación.

898
Error de falta de espacio en el dispositivo
Puede mitigar este problema incrementando el número de horas que los archivos de registro binarios se
retienen en el maestro de replicación. Después de incrementar el tiempo de retención de los archivos
binlog, puede reiniciar la replicación y llamar al comando mysql.rds_skip_repl_error si es necesario.
Para definir el tiempo de retención de binlog, use el procedimiento mysql_rds_set_configuration y

especifique un parámetro de configuración de "binlog retention hours" junto con el número de horas para
retener los archivos binlog en el clúster de base de datos, hasta un máximo de 720 (30 días). El ejemplo
siguiente define el periodo de retención de los archivos binlog en 48 horas:
Error de falta de espacio en el dispositivo

Podría encontrarse con el siguiente mensaje de error de Amazon Aurora:
ERROR 3 (HY000): Error writing file '/rdsdbdata/tmp/XXXXXXXX' (Errcode: 28 - No space left

on device)
Cada instancia de base de datos en un clúster de base de datos Amazon Aurora utiliza almacenamiento
SSD local para almacenar tablas temporales para una sesión. Este almacenamiento local de una tabla
temporal no crece automáticamente como el volumen del clúster de Aurora. En lugar de eso, la cantidad
de almacenamiento local es limitada. El límite se basa en la clase de instancia de base de datos para las
instancias en su clúster de base de datos. Para encontrar la cantidad de almacenamiento SSD local para
los tipos de instancia optimizados para memoria, vaya a Tipos de instancias de Amazon EC2.
Si su carga de trabajo no puede modificarse para disminuir la cantidad de almacenamiento temporal

necesario, puede ampliar sus instancias de base de datos para usar una clase de instancia de base de
datos con más almacenamiento SSD local.

899
Uso de la API de consulta
Referencia a la Interfaz de
programación de aplicaciones (API)
de Amazon RDS
Además de la Consola de administración de AWS y la AWS Command Line Interface (AWS CLI), Amazon
Relational Database Service (Amazon RDS) también proporciona una interfaz de programación de
aplicaciones (API). Puede utilizar la API para automatizar las tareas de administración de instancias de
base de datos y otros objetos en Amazon RDS.
• Para ver una lista de acciones de la API ordenada alfabéticamente, consulte el tema relacionado con las
acciones de la API.
• Para ver una lista de tipos de datos ordenada alfabéticamente, consulte el tema relacionado con los tipos
de datos.
• Para ver una lista de parámetros de consulta comunes, consulte el tema relacionado con los parámetros
comunes.
• Para ver las descripciones de los códigos de error, consulte el tema relacionado con los errores
comunes.
Para obtener más información acerca de la AWS CLI, consulte la documentación de referencia de la AWS
Command Line Interface de Amazon RDS.
Temas
• Uso de la API de consulta (p. 900)
• Solución de problemas de aplicaciones en Aurora (p. 901)
Uso de la API de consulta

En las siguientes secciones se explican los parámetros y la autenticación de solicitudes que se utilizan con
la API de consulta.
Parámetros de consulta
Las solicitudes basadas en consultas HTTP son solicitudes HTTP que utilizan el verbo HTTP GET o POST
y un parámetro de consulta denominado Action.
Cada solicitud de consulta debe incluir algunos parámetros comunes para realizar la autenticación y la
selección de una acción.
Algunas operaciones toman listas de parámetros. Estas listas se especifican utilizando la notación
param.n. Los valores de n son números enteros a partir de 1.
Para obtener más información acerca de las regiones y los puntos de enlace de Amazon RDS, vaya a
Amazon Relational Database Service (RDS) en la sección Regiones y puntos de enlace de la Referencia
general de Amazon Web Services.

900
Autenticación de solicitudes de consulta
Autenticación de solicitudes de consulta

Solo se pueden enviar solicitudes de consulta a través de HTTPS, y cada una de ellas debe incluir una
firma. Debe utilizar Signature Version 4 o Signature Version 2 de AWS. Para obtener más información,
consulte Proceso de firma de Signature Version 4 y Proceso de firma de Signature Version 2.
Solución de problemas de aplicaciones en Aurora

Amazon RDS proporciona errores específicos y descriptivos para ayudarle a solucionar problemas durante
la interacción con la API de Amazon RDS.
Temas
• Recuperación de errores (p. 901)
• Consejos para la solución de problemas (p. 901)
Para obtener más información sobre la solución de problemas para instancias de base de datos de
Amazon RDS, consulte Solución de problemas de Aurora (p. 892).
Recuperación de errores
Normalmente, conviene que una aplicación compruebe si una solicitud generó un error antes de emplear
tiempo en procesar los resultados. La forma más fácil de averiguar si se ha producido un error, consiste en
buscar un nodo Error en la respuesta de la API de Amazon RDS.
La sintaxis XPath permite comprobar fácilmente si hay un nodo Error, y ofrece un método sencillo
de recuperar el mensaje de error y su código. El fragmento de código siguiente utiliza Perl y el módulo
XML::XPath para determinar si se ha producido un error durante una solicitud. Si es así, el código imprime
el primer mensaje de error y su código en la respuesta.
use XML::XPath;
my $xp = XML::XPath->new(xml =>$response);
if ( $xp->find("//Error") )
{print "There was an error processing your request:\n", " Error code: ",
$xp->findvalue("//Error[1]/Code"), "\n", " ",
$xp->findvalue("//Error[1]/Message"), "\n\n"; }
Consejos para la solución de problemas

Recomendamos los siguientes procesos para diagnosticar y solucionar problemas con la API de Amazon
RDS.
• Comprobar que Amazon RDS está funcionando normalmente en la región de AWS de destino visitando
http://status.aws.amazon.com
• Comprobar la estructura de la solicitud
Cada operación de Amazon RDS tiene una página de referencia en la Referencia de la API de Amazon
RDS. Compruebe que está utilizando los parámetros correctamente. Con el fin de obtener ideas sobre
lo que podría estar mal, examine las solicitudes de muestra o los escenarios de usuario para ver si esos
ejemplos realizan operaciones similares.
• Visitar el foro
Existe un foro de la comunidad de desarrolladores de Amazon RDS donde puede buscar soluciones a
los problemas que otras personas han experimentado al utilizar este servicio. Para ver el foro, vaya a

901
Consejos para la solución de problemas
https://forums.aws.amazon.com/

902
Historial de revisión
• Última actualización de la documentación: 9 de julio de 2019
• Versión de API actual: 2014-10-31
En la siguiente tabla se describen cambios importantes en la Guía del usuario de Amazon Aurora. Para
obtener notificaciones sobre las actualizaciones de esta documentación, puede suscribirse a una fuente
RSS. Para obtener más información sobre Amazon Relational Database Service (Amazon RDS), consulte
la Guía del usuario de Amazon Relational Database Service.
Note
Antes del 31 de agosto de 2018, Amazon Aurora se documentaba en la Guía del usuario de
Amazon Relational Database Service. Para ver el historial de revisión anterior de Aurora, consulte
Historial de revisión en la Guía del usuario de Amazon Relational Database Service.
update-history-change update-history-description update-history-date
Aurora PostgreSQL admite Puede usar Amazon Aurora July 9, 2019

Aurora Serverless (p. 903) Serverless con Aurora
PostgreSQL. Un clúster de base
se inicia, se cierra y escala
automáticamente su capacidad
informática en función de las
necesidades de la aplicación.
Para obtener más información,
consulte Uso de Amazon Aurora
Serverless.
Versiones de Aurora PostgreSQL La versión 2.3.3 de July 3, 2019

2.3.3 y 1.5.2 (p. 903) Compatibilidad de Amazon
Aurora con PostgreSQL está
disponible y es compatible con
PostgreSQL 10.7. La versión
1.5.2 de Compatibilidad de
Amazon Aurora con PostgreSQL
está disponible y es compatible
con PostgreSQL 9.6.12. Para
obtener más información,
consulte Versiones del motor
de base de datos para Amazon
Aurora PostgreSQL.
Versiones de Aurora PostgreSQL La versión 2.3.1 de July 2, 2019

2.3.1 y 1.5.1 (p. 903) Compatibilidad de Amazon
Aurora con PostgreSQL está
PostgreSQL 10.7. La versión
1.5.1 de Compatibilidad de
Amazon Aurora con PostgreSQL
está disponible y es compatible
con PostgreSQL 9.6.12. Para

903

Aurora PostgreSQL.
Clonación entre cuentas para Ahora puede clonar el volumen July 2, 2019
Aurora MySQL (p. 903) del clúster para un clúster de
base de datos Aurora MySQL
entre cuentas de AWS. Autorice
el uso compartido a través
de AWS Resource Access
Manager (AWS RAM). El
volumen del clúster clonado
utiliza un mecanismo de copia
en escritura, que solo requiere
almacenamiento adicional para
los datos nuevos o modificados.
Para obtener más información
sobre la clonación de Aurora,
consulte Clonación de bases de
datos en un clúster de bases de
datos Aurora.
Aurora PostgreSQL admite Ahora puede crear clústeres June 20, 2019
clases de instancia de base de de base de datos de Aurora
datos db.t3 (p. 903) PostgreSQL que utilicen las
clases de instancia de base de
datos db.t3. Para obtener más
información, consulte Clase de
Compatibilidad para la Ahora puede importar datos June 19, 2019

importación de datos desde de un archivo Amazon S3 en
Amazon S3 para Aurora una tabla en un clúster de base
PostgreSQL (p. 903) de datos Aurora PostgreSQL.
consulte Importación de datos de
Amazon S3 en un clúster de base
de datos Aurora PostgreSQL.
Aurora PostgreSQL proporciona Compatibilidad de Aurora con June 11, 2019

ahora una recuperación de PostgreSQL proporciona ahora
conmutación por error rápida con administración de caché del
una administración de caché del clúster para garantizar una
clúster (p. 903) recuperación rápida de la
principal en caso de una
conmutación por error. Para
consulte Recuperación rápida
después de una conmutación por
error con la administración de
caché del clúster.

904
Aurora PostgreSQL versión La versión 2.3 de Compatibilidad May 30, 2019

2.3 (p. 903) de Amazon Aurora con
PostgreSQL está disponible y es
compatible con PostgreSQL 10.7.
consulte versión 2.3.
Aurora PostgreSQL admite la Ahora, Compatibilidad de May 30, 2019

monitorización de bases de Aurora con PostgreSQL incluye
datos mediante secuencias secuencias de actividades
de actividades de la base de de la base de datos, que
datos (p. 903) proporcionan una secuencia de
datos prácticamente en tiempo
real de la actividad de su base
de datos relacional. Para obtener
más información, consulte Uso
de secuencias de actividades de
la base de datos.
API de datos de Aurora Puede obtener acceso a May 30, 2019

Serverless generalmente clústeres de Aurora Serverless
disponible (p. 903) con aplicaciones basadas en
servicios web mediante la API
de datos. Para obtener más
información, consulte la sección
Uso de la API de datos para
Aurora Serverless.
Recomendaciones de Amazon Amazon Aurora proporciona May 22, 2019

Aurora (p. 903) ahora recomendaciones
automatizadas de recursos
de Aurora. Para obtener más
información, consulte Uso de
recomendaciones de Amazon
Aurora.
Versiones de Aurora Las siguientes versiones de May 21, 2019

PostgreSQL1.2.2, 1.3.2, 2.0.1, parches para Compatibilidad de
2.1.1, 2.2.1 (p. 903) Amazon Aurora con PostgreSQL
están ahora disponibles e
incluyen las versiones 1.2.2,
1.3.2, 2.0.1, 2.1.1 y 2.2.1.
Aurora PostgreSQL.

905
Compatibilidad de Performance Ahora puede utilizar Performance May 13, 2019

Insights para Aurora Global Insights con Aurora Global
Database (p. 903) Database. Para obtener
información sobre Performance
Insights para Aurora, consulte
Uso de Performance Insights
de Amazon RDS. Para obtener
información sobre bases de
datos globales de Aurora,
consulte Funcionamiento de
bases de datos globales de
Aurora.
Versión de Aurora PostgreSQL La versión 1.4 de Compatibilidad May 9, 2019

1.4 (p. 903) de Amazon Aurora con
PostgreSQL está disponible y
es compatible con PostgreSQL
9.6.11. Para obtener más
información, consulte versión
1.4.
La característica Información Performance Insights de Amazon May 3, 2019

sobre rendimiento está RDS está ahora disponible para
disponible para Aurora MySQL las versiones de Aurora MySQL
5.7 (p. 903) 2.x, que son compatibles con
MySQL 5.7. Para obtener más
información, consulte Uso de
Performance Insights Amazon
RDS.
Las bases de datos globales de Ahora puede crear bases de April 30, 2019
Aurora están disponibles en más datos globales de Aurora en
regiones de AWS (p. 903) la mayoría de las regiones
de AWS en las que Aurora
está disponible. Para obtener
información sobre bases de
datos globales de Aurora,
consulte Funcionamiento con
bases de datos globales de
Amazon Aurora.
Capacidad mínima de 1 para La configuración de capacidad April 29, 2019

Aurora Serverless (p. 903) mínima que puede utilizar para
un clúster de Aurora Serverless
es 1. Anteriormente, el mínimo
era 2. Para obtener información
sobre la especificación de
valores de capacidad de
Aurora Serverless, consulte
Configuración de la capacidad de
un clúster de base de datos de
Aurora Serverless.

906
Acción de tiempo de espera de Ahora puede especificar la April 29, 2019

Aurora Serverless (p. 903) acción que realizar cuando se
agote el tiempo de espera de un
cambio de capacidad de Aurora
Serverless. Para obtener más
información, consulte Acción de
tiempo de espera para cambios
de capacidad.
Facturación por Amazon RDS se factura ahora April 25, 2019

segundo (p. 903) en incrementos de 1 segundo
en todas las regiones de
AWS, excepto AWS GovCloud
(EE.UU.) para las instancias bajo
demanda. Para obtener más
información, consulte Facturación
de instancias de base de datos
para Aurora.
Uso compartido de instantáneas Con Aurora Serverless, las April 17, 2019
de Aurora Serverless en regiones instantáneas están siempre
de AWS (p. 903) cifradas. Si cifra la instantánea
con su propia clave AWS Key
Management Service, puede
ahora copiar o compartir la
instantánea en las regiones de
AWS. Para obtener información
sobre las instantáneas
de clústeres de base de
datos de Aurora Serverless,
consulte Aurora Serverless e
instantáneas.
Restauración de copias de Ahora puede crear una copia April 17, 2019
seguridad de MySQL 5.7 desde de seguridad de una base de
Amazon S3 (p. 903) datos de MySQL, versión 5.7,
almacenarla en Amazon S3 y
luego restaurar el archivo de
copia de seguridad en un nuevo
clúster de base de datos de
Aurora MySQL. Para obtener
más información, consulte
Migración de datos desde una
base de datos MySQL externa a
un clúster de base de datos de
Aurora MySQL.
Tutorial de prueba de concepto Puede aprender cómo realizar April 16, 2019
de Aurora (p. 903) una prueba de concepto para
probar su aplicación y carga de
trabajo con Aurora. Para ver
el tutorial completo, consulte
Realización de una prueba de
concepto de Aurora.

907
Nuevos parámetros modificables Ahora puede modificar April 4, 2019

para Aurora Serverless (p. 903) los siguientes parámetros
de base de datos para un
clúster de Aurora Serverless:
innodb_file_format,
innodb_file_per_table,
innodb_large_prefix,
innodb_lock_wait_timeout,
innodb_monitor_disable,
innodb_monitor_enable,
innodb_monitor_reset,
innodb_monitor_reset_all,
innodb_print_all_deadlocks,
log_warnings,
net_read_timeout,
net_retry_count,
net_write_timeout,
sql_mode y tx_isolation.
Para obtener más información
sobre los parámetros de
configuración para clústeres
de Aurora Serverless, consulte
Aurora Serverless y grupos de
parámetros.
Aurora PostgreSQL admite las Ahora puede crear clústeres April 4, 2019
clases de instancia de base de de base de datos de Aurora
datos db.r5 (p. 903) PostgreSQL que utilicen las
clases de instancia de base de
datos db.r5. Para obtener más
información, consulte Clase de
Replicación lógica de Aurora Ahora puede utilizar la replicación March 28, 2019
PostgreSQL (p. 903) lógica de PostgreSQL para
replicar partes de una base de
datos para un clúster de base
consulte Uso de la replicación
lógica de PostgreSQL.

908
Compatibilidad de GTID para Puede utilizar ahora la replicación March 25, 2019
Aurora MySQL 2.04 (p. 903) con la característica de ID de
transacción global (GTID) de
MySQL 5.7. Esta característica
simplifica la realización de la
replicación del registro binario
(binlog) entre Aurora MySQL
y una base de datos externa
compatible con MySQL 5.7.
La replicación puede utilizar
el clúster de Aurora MySQL
como fuente o destino. Esta
característica está disponible
para Aurora MySQL 2.04 y
versiones superiores. Para
obtener más información sobre
la replicación basada en GTID y
Aurora MySQL, consulte Uso de
replicación basada en GTID para
Aurora MySQL.
Carga de registros de Aurora en Ahora puede disponer de February 25, 2019

Amazon CloudWatch (p. 903) registros de base de datos de
carga de Aurora en CloudWatch
para un clúster de Aurora
Serverless. Para obtener
Visualización de clústeres
de base de datos de Aurora
Serverless. Como parte de esta
mejora, ahora puede definir
valores para parámetros de nivel
de instancia en un grupo de
parámetros de clúster de base de
datos y esos valores se aplican
a todas las instancias de base
de datos en el clúster a no ser
que los sobrescriba en el grupo
de parámetros de base de datos.
consulte Funcionamiento con
grupos de parámetros de base
de datos y grupos de parámetros
Aurora MySQL admite las clases Ahora puede crear clústeres February 25, 2019
de instancia de base de datos de base de datos de Aurora
db.r5 (p. 903) MySQL que utilicen las clases de
instancia de base de datos db.r5.
consulte Clase de instancia de
base de datos.

909
Aurora MySQL admite clases Ahora puede crear clústeres February 25, 2019
de instancia de base de datos de base de datos de Aurora
db.t3 (p. 903) MySQL que utilicen las clases de
instancia de base de datos db.t3.
consulte Clase de instancia de
base de datos.
Contadores de Performance Ahora puede añadir contadores February 19, 2019

Insights para Aurora de rendimiento a sus gráficos
MySQL (p. 903) de Performance Insights para
las instancias de base de datos
de Aurora MySQL. Para obtener
Componentes del panel de
Aurora PostgreSQL, versión La versión 2.2.0 de February 13, 2019

2.2.0 (p. 903) Compatibilidad de Aurora con
PostgreSQL está disponible y es
compatible con PostgreSQL 10.6.
consulte Versión 2.2.0.
Amazon RDS Performance Amazon RDS Performance February 6, 2019

Insights admite la visualización Insights es ahora compatible
de más texto SQL para Aurora con la visualización de más texto
MySQL (p. 903) SQL en el panel de Performance
Insights para instancias de base
de datos de Aurora MySQL.
consulte Visualización de
más texto SQL en el panel de
Amazon RDS Performance Amazon RDS Performance January 24, 2019

Insights admite la visualización Insights es ahora compatible
de más texto SQL para Aurora con la visualización de más texto
PostgreSQL (p. 903) SQL en el panel de Performance
Insights para instancias de base
consulte Visualización de
más texto SQL en el panel de

910
Facturación de copias de Puede usar las métricas January 3, 2019

seguridad de Aurora (p. 903) de Amazon CloudWatch
TotalBackupStorageBilled,
SnapshotStorageUsed y
BackupRetentionPeriodStorageUsed
para monitorizar el uso del
espacio de sus copias de
seguridad de Aurora. Para
obtener más información
sobre cómo usar las métricas
de CloudWatch, consulte
Información general sobre la
monitorización. Para obtener
más información sobre cómo
administrar un servicio de
almacenamiento para los
datos de copia de seguridad,
consulte Descripción del uso de
almacenamiento de copias de
seguridad de Aurora.
Contadores de Performance Ahora puede añadir contadores December 6, 2018

Insights (p. 903) de rendimiento a sus gráficos
de Performance Insights. Para
consulte Componentes del panel
de Performance Insights.
Bases de datos globales de Ahora puede crear bases de November 28, 2018
Aurora (p. 903) datos globales de Aurora. Una
abarca varias regiones de AWS,
habilitando lecturas globales de
baja latencia y la recuperación
de desastres de interrupciones
regionales. Para obtener más
información, consulte Trabajo con
bases de datos globales Amazon
Aurora.
Editor de consultas para Aurora Puede ejecutar instrucciones November 20, 2018
Serverless (Beta) (p. 903) SQL en la consola de Amazon
RDS de clústeres de Aurora
Serverless. Para obtener
más información, consulte la
sección sobre cómo usar el
editor de consultas para Aurora
Serverless.
Aurora PostgreSQL, versión 2.1 La versión 2.1 de Compatibilidad November 20, 2018
(p. 903) de Aurora con PostgreSQL está
PostgreSQL 10.5. Para obtener
Versión 2.1.

911
Administración de planes de Compatibilidad de Aurora con November 20, 2018

consultas en Aurora PostgreSQL PostgreSQL proporciona ahora
(p. 903) administración de planes de
consultas, la cual puede usar
para administrar planes de
ejecución de consultas de
PostgreSQL. Para obtener más
sobre administración de planes
de ejecución de consultas para
Aurora PostgreSQL.
API de datos para Aurora Puede obtener acceso a November 20, 2018
Serverless (Beta) (p. 903) clústeres de Aurora Serverless
con aplicaciones basadas en
servicios web mediante la API
Uso de la API de datos para
Aurora Serverless.
Compatibilidad de TLS para Los clústeres de Aurora November 19, 2018

Aurora Serverless (p. 903) Serverless admiten el cifrado
TLS/SSL. Para obtener más
información, consulte TLS/SSL
para Aurora Serverless.
Puntos de enlace Ahora puede crear puntos November 12, 2018

personalizados (p. 903) de enlace que se asocien
a un conjunto arbitrario de
instancias de base de datos.
Esta característica ayuda
con equilibrio de carga y alta
disponibilidad para clústeres de
Aurora donde algunas instancias
de base de datos tienen una
capacidad o una configuración
distintas de otras. Puede usar
puntos de enlace personalizados
en lugar de conectarse a una
específica a través de su punto
de enlace de instancia. Para
consulte la sección sobre
administración de conexiones de
Amazon Aurora.
Compatibilidad de autenticación Compatibilidad de Aurora con November 8, 2018

de IAM en Aurora PostgreSQL PostgreSQL ahora admite la
(p. 903) autenticación de IAM. Para
consulte la sección sobre
autenticación de bases de datos
de IAM.

912
Grupos de parámetros Ahora puede especificar October 15, 2018

personalizados para restaurar un grupo de parámetros
y recuperación a un momento personalizados cuando restaure
dado (p. 903) una instantánea o realice una
operación de recuperación
a un momento dado. Para
consulte el tema relacionado
con la restauración desde una
instantánea de clúster de base
de datos y el tema relacionado
con la restauración de un clúster
de base de datos a un momento
especificado.
Eliminación de protección para Al habilitar la protección contra September 26, 2018

clústeres de base de datos de eliminación para un clúster de
Aurora (p. 903) base de datos, ningún usuario
podrá eliminar dicha base
información, consulte el tema
relacionado con la eliminación de
una instancia de base de datos
en un clúster de base de datos.
Aurora PostgreSQL, versión 2.0 La versión 2.0 de Compatibilidad September 25, 2018
(p. 903) de Aurora con PostgreSQL está
PostgreSQL 10.4. Para obtener
Versión 2.0.
Característica de detención/inicio Ahora puede detener o iniciar un September 24, 2018

de Aurora (p. 903) clúster completo de Aurora con
una sola operación. Para obtener
más información, consulte el
tema donde se explica cómo
detener e iniciar un clúster de
base de datos Aurora.
Característica de consulta Aurora MySQL ahora ofrece September 20, 2018

en paralelo de Aurora una opción para paralelizar el
MySQL (p. 903) trabajo de E/S para consultas
en la infraestructura de
almacenamiento de Aurora.
Esta característica acelera
las consultas analíticas con
uso intensivo de datos, que
suelen ser las operaciones que
requieren más tiempo en una
carga de trabajo. Para obtener
más información, consulte el
tema donde se explica cómo
trabajar con consultas en paralelo
para Aurora MySQL.

913
Aurora PostgreSQL, versión 1.3 Aurora PostgreSQL, versión September 11, 2018
(p. 903) 1.3 está ahora disponible y es
compatible con PostgreSQL
9.6.9. Para obtener más
información, consulte Versión
1.3.
Nueva guía (p. 903) Esta es la primera versión de August 31, 2018
la Guía del usuario de Amazon
Aurora.

914

Aurora Ug

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Aurora Ug

Cargado por

Copyright:

Formatos disponibles

Amazon Aurora

Guía del usuario de Aurora

Amazon Aurora: Guía del usuario de Aurora

Versión de API 2014-10-31

Zona horaria local para los clústeres de base de datos ........................................................... 68

Versión de API 2014-10-31

Permisos de roles vinculados a servicios para Amazon Aurora ............................................... 208

Versión de API 2014-10-31

Almacenamiento de copia de seguridad .............................................................................. 316

Versión de API 2014-10-31

Uso de secuencias de actividades de la base de datos ......................................................... 449

Versión de API 2014-10-31

Consultas en paralelo y constructos de SQL ....................................................................... 581

Versión de API 2014-10-31

Importación de datos S3 en Aurora PostgreSQL .................................................................. 784

Versión de API 2014-10-31

10. Ejecute la carga de trabajo ................................................................................................. 883

Versión de API 2014-10-31

¿Qué es Amazon Aurora?

Versión de API 2014-10-31

• Uso de Amazon Aurora Global Database (p. 29)

Clústeres de base de datos Amazon Aurora

El clúster de Aurora muestra la separación de la capacidad informática y almacenamiento. Por ejemplo,

Versión de API 2014-10-31

Administración de conexiones de Amazon Aurora

Tipos de puntos de enlace de Aurora

Punto de enlace de clúster

Versión de API 2014-10-31

Un punto de enlace personalizado de un clúster de Aurora representa un conjunto de instancias de

Versión de API 2014-10-31

Visualización de los puntos de enlace para un clúster

Uso del punto de enlace de clúster

Versión de API 2014-10-31

Uso del punto de enlace del lector

Uso de puntos de enlace personalizados

Versión de API 2014-10-31

Especificación de propiedades para puntos de enlace

Reglas de afiliación para puntos de enlace personalizados

Versión de API 2014-10-31

Administración de puntos de enlace personalizados

Versión de API 2014-10-31

Creación de un punto de enlace personalizado

Versión de API 2014-10-31

Versión de API 2014-10-31

No puede seleccionar el tipo de punto de enlace personalizado de ANY o READER en la Consola de

El siguiente comando crea un punto de enlace personalizado asociado a un clúster específico. En un

Para Linux, OS X o Unix:

aws rds create-db-cluster-endpoint --db-cluster-endpoint-identifier custom-endpoint-doc-

aws rds modify-db-cluster-endpoint --db-cluster-endpoint-identifier custom-endpoint-doc-

aws rds create-db-cluster-endpoint --db-cluster-endpoint-identifier custom-endpoint-doc-

aws rds modify-db-cluster-endpoint --db-cluster-endpoint-identifier custom-endpoint-doc-

Visualización de puntos de enlace personalizados

Versión de API 2014-10-31

Versión de API 2014-10-31

Versión de API 2014-10-31

Versión de API 2014-10-31

Para Linux, OS X o Unix:

aws rds describe-db-cluster-endpoints --region region_name \

aws rds describe-db-cluster-endpoints --region region_name ^

A continuación, se muestran algunos resultados de ejemplo de un comando describe-db-cluster-

Versión de API 2014-10-31

Edición de un punto de enlace personalizado

Consola de administración de AWS