Aurora Ug
Aurora Ug
Aurora Ug
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.
Amazon Aurora Guía del usuario de Aurora
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
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)
• 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.
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)
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
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 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
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
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.
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
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.
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.
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)
• Ejemplo de AWS CLI integral para puntos de enlace personalizados (p. 19)
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.
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.
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.
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
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.
AWS CLI
Para crear un punto de enlace personalizado con la AWS CLI, ejecute el comando create-db-cluster-
endpoint.
Para Windows:
API de RDS
Para crear un punto de enlace personalizado con la API de RDS, ejecute la acción
CreateDBClusterEndpoint.
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.
Tras crear algunos puntos de enlace personalizados para ese clúster, se muestran en la sección Endpoints
(Puntos de enlace).
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.
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.
Para Windows:
{
"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",
"Status": "available",
"DBClusterIdentifier": "custom-endpoint-demo",
"EndpointType": "READER"
},
{
"CustomEndpointType": "ANY",
"DBClusterEndpointIdentifier": "powers-of-2",
"ExcludedMembers": [],
"DBClusterIdentifier": "custom-endpoint-demo",
"Status": "available",
"EndpointType": "CUSTOM",
"Endpoint": "powers-of-2.cluster-custom-123456789012.ca-central-1.rds.amazonaws.com",
"StaticMembers": [
"custom-endpoint-demo-04",
"custom-endpoint-demo-08",
"custom-endpoint-demo-01",
"custom-endpoint-demo-02"
],
"DBClusterEndpointResourceIdentifier": "cluster-endpoint-W7PE3TLLFNSHXQKFU6J6NV5FHU",
"DBClusterEndpointArn": "arn:aws:rds:ca-central-1:111122223333:cluster-endpoint:powers-
of-2"
},
{
"CustomEndpointType": "ANY",
"DBClusterEndpointIdentifier": "eight-and-higher",
"ExcludedMembers": [
"custom-endpoint-demo-04",
"custom-endpoint-demo-02",
"custom-endpoint-demo-07",
"custom-endpoint-demo-05",
"custom-endpoint-demo-03",
"custom-endpoint-demo-06",
"custom-endpoint-demo-01"
],
"DBClusterIdentifier": "custom-endpoint-demo",
"Status": "available",
"EndpointType": "CUSTOM",
"Endpoint": "eight-and-higher.cluster-custom-123456789012.ca-
central-1.rds.amazonaws.com",
"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.
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).
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.
Para Windows:
API de RDS
Para editar un punto de enlace personalizado con la API de RDS, ejecute la acción
ModifyDBClusterEndpoint.html.
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.
Para Windows:
API de RDS
Para eliminar un punto de enlace personalizado con la API de RDS, ejecute la acción
DeleteDBClusterEndpoint.
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.
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
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.
"custom-endpoint-demo-09"
],
"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.
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
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.
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.
$ 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 |
+-------------------------+
$ 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-07 |
+-------------------------+
$ 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-01 |
+-------------------------+
$ mysql -h big-instances.cluster-custom-123456789012.ca-central-1.rds.amazonaws.com -u
$MYUSER -p
mysql> select @@aurora_server_id;
+-------------------------+
| @@aurora_server_id |
+-------------------------+
| custom-endpoint-demo-10 |
+-------------------------+
$ mysql -h big-instances.cluster-custom-123456789012.ca-central-1.rds.amazonaws.com -u
$MYUSER -p
mysql> select @@aurora_server_id;
+-------------------------+
| @@aurora_server_id |
+-------------------------+
| custom-endpoint-demo-09 |
+-------------------------+
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
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.
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).
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)
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.
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.
Para obtener información acerca del almacenamiento de datos de Aurora, consulte Amazon RDS for
Aurora Pricing.
Temas
• Reparación automática del almacenamiento (p. 26)
• Calentamiento de caché que puede sobrevivir (p. 26)
• Recuperación de bloqueos (p. 26)
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).
• 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.
• 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.
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).
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
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).
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)
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.
Temas
• Ventajas de Aurora Global Database (p. 30)
• Limitaciones actuales de Aurora Global Database (p. 30)
• 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.
• 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.
• 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.
Note
5. Seleccione Create.
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
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.
Para Windows:
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.
Para Windows:
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.
Para Windows:
Para obtener más información acerca de las opciones adicionales, consulte create-db-
instance.
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.
Para Windows:
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.
Para Windows:
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.
Para Windows:
API de RDS
Para crear una base de datos de Aurora global con la API de RDS, ejecute la acción CreateGlobalCluster.
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.
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:
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).
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.
Para Windows:
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.
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
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.
Para Windows:
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.
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.
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:
Para Windows:
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.
• 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
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.
Para ver las propiedades que se aplican a toda una base de datos global de Aurora, seleccione esa base
de datos global.
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,
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.
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.
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:
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.
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).
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.
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
Para los clústeres de Aurora que componen la base de datos global de Aurora, realice los
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.
Configure cada clúster de la base de datos global de Aurora 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).
Guardar datos de consulta en S3
Para los clústeres de Aurora que componen la base de datos global de Aurora, realice los
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
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.
Configure cada clúster de la base de datos global de Aurora 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).
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).
• 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
Aurora MySQL (p. 596).
Para obtener más información sobre cómo replicar con Aurora PostgreSQL, consulte Replicación con
Amazon Aurora PostgreSQL (p. 796).
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.
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.
Si se ha inscrito en AWS, pero no ha creado un usuario de IAM para usted, puede crearlo en la consola de
IAM.
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
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
Versión de API 2014-10-31
51
Amazon Aurora Guía del usuario de Aurora
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.
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.
• 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.
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
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.
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).
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.
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)
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).
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
• 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).
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.
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:
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. 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
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.
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).
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. 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.
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. Elija Subnet groups y, a continuación, el grupo de subredes de base de datos gs-subnet-group1.
3. Elija Eliminar.
4. Elija Eliminar.
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. 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.
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)
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)
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.
• 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.
• 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.
A continuación se muestran las consideraciones del motor de base de datos para las clases de instancia
de base de datos:
• 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).
versiones
posteriores
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.
En la siguiente tabla se muestran las regiones en las que Aurora PostgreSQL está disponible actualmente.
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.
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.
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
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.
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
• 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
Amazon Aurora (p. 314).
• 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)
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.
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).
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.
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.
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
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.
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.
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
10xlarge 80 160
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.
• 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
• 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.
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
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 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 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.
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 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.
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.
De forma alternativa, elija Back para editar la instancia de base de datos reservada.
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
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 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.
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 muestra en el siguiente ejemplo.
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.
Para Windows:
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 en el siguiente ejemplo.
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.
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.
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
&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>
<Duration>31536000</Duration>
<OfferingType>Partial Upfront</OfferingType>
<CurrencyCode>USD</CurrencyCode>
<RecurringCharges/>
<FixedPrice>227.5</FixedPrice>
<ProductDescription>mysql</ProductDescription>
<UsagePrice>0.046</UsagePrice>
<MultiAZ>false</MultiAZ>
<ReservedDBInstancesOfferingId>649fd0c8-cf6d-47a0-bfa6-060f8e75e95f</
ReservedDBInstancesOfferingId>
<DBInstanceClass>db.m1.small</DBInstanceClass>
</ReservedDBInstancesOffering>
</ReservedDBInstancesOfferings>
</DescribeReservedDBInstancesOfferingsResult>
<ResponseMetadata>
<RequestId>5e4ec40b-2978-11e1-9e6d-771388d6ed6b</RequestId>
</ResponseMetadata>
</DescribeReservedDBInstancesOfferingsResponse>
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 muestra en el siguiente ejemplo.
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.
https://rds.us-east-1.amazonaws.com/
?Action=PurchaseReservedDBInstancesOffering
&ReservedDBInstanceId=MyReservation
&ReservedDBInstancesOfferingId=438012d3-4052-4cc7-b2e3-8d3372e0e706
&DBInstanceCount=10
&SignatureMethod=HmacSHA256
&SignatureVersion=4
&Version=2014-09-01
&X-Amz-Algorithm=AWS4-HMAC-SHA256
&X-Amz-Credential=AKIADQKE4SARGYLE/20140415/us-east-1/rds/aws4_request
&X-Amz-Date=20140415T232655Z
&X-Amz-SignedHeaders=content-type;host;user-agent;x-amz-content-sha256;x-amz-date
&X-Amz-Signature=c2ac761e8c8f54a8c0727f5a87ad0a766fbb0024510b9aa34ea6d1f7df52fb11
<PurchaseReservedDBInstancesOfferingResponse xmlns="http://rds.amazonaws.com/
doc/2014-10-31/">
<PurchaseReservedDBInstancesOfferingResult>
<ReservedDBInstance>
<OfferingType>Partial Upfront</OfferingType>
<CurrencyCode>USD</CurrencyCode>
<RecurringCharges/>
<ProductDescription>mysql</ProductDescription>
<ReservedDBInstancesOfferingId>649fd0c8-cf6d-47a0-bfa6-060f8e75e95f</
ReservedDBInstancesOfferingId>
<MultiAZ>true</MultiAZ>
<State>payment-pending</State>
<ReservedDBInstanceId>MyReservation</ReservedDBInstanceId>
<DBInstanceCount>10</DBInstanceCount>
<StartTime>2011-12-18T23:24:56.577Z</StartTime>
<Duration>31536000</Duration>
<FixedPrice>123.0</FixedPrice>
<UsagePrice>0.123</UsagePrice>
<DBInstanceClass>db.m1.small</DBInstanceClass>
</ReservedDBInstance>
</PurchaseReservedDBInstancesOfferingResult>
<ResponseMetadata>
<RequestId>7f099901-29cf-11e1-bd06-6fe008f046c3</RequestId>
</ResponseMetadata>
</PurchaseReservedDBInstancesOfferingResponse>
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 en el siguiente ejemplo.
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
&SignatureMethod=HmacSHA256
&SignatureVersion=4
&Version=2014-09-01
&X-Amz-Algorithm=AWS4-HMAC-SHA256
&X-Amz-Credential=AKIADQKE4SARGYLE/20140420/us-west-2/rds/aws4_request
&X-Amz-Date=20140420T162211Z
&X-Amz-SignedHeaders=content-type;host;user-agent;x-amz-content-sha256;x-amz-date
&X-Amz-Signature=3312d17a4c43bcd209bc22a0778dd23e73f8434254abbd7ac53b89ade3dae88e
<DescribeReservedDBInstancesResponse xmlns="http://rds.amazonaws.com/doc/2014-10-31/">
<DescribeReservedDBInstancesResult>
<ReservedDBInstances>
<ReservedDBInstance>
<OfferingType>Partial Upfront</OfferingType>
<CurrencyCode>USD</CurrencyCode>
<RecurringCharges/>
<ProductDescription>mysql</ProductDescription>
<ReservedDBInstancesOfferingId>649fd0c8-cf6d-47a0-bfa6-060f8e75e95f</
ReservedDBInstancesOfferingId>
<MultiAZ>false</MultiAZ>
<State>payment-failed</State>
<ReservedDBInstanceId>MyReservation</ReservedDBInstanceId>
<DBInstanceCount>1</DBInstanceCount>
<StartTime>2010-12-15T00:25:14.131Z</StartTime>
<Duration>31536000</Duration>
<FixedPrice>227.5</FixedPrice>
<UsagePrice>0.046</UsagePrice>
<DBInstanceClass>db.m1.small</DBInstanceClass>
</ReservedDBInstance>
<ReservedDBInstance>
<OfferingType>Partial Upfront</OfferingType>
<CurrencyCode>USD</CurrencyCode>
<RecurringCharges/>
<ProductDescription>mysql</ProductDescription>
<ReservedDBInstancesOfferingId>649fd0c8-cf6d-47a0-bfa6-060f8e75e95f</
ReservedDBInstancesOfferingId>
<MultiAZ>false</MultiAZ>
<State>payment-failed</State>
<ReservedDBInstanceId>MyReservation</ReservedDBInstanceId>
<DBInstanceCount>1</DBInstanceCount>
<StartTime>2010-12-15T01:07:22.275Z</StartTime>
<Duration>31536000</Duration>
<FixedPrice>227.5</FixedPrice>
<UsagePrice>0.046</UsagePrice>
<DBInstanceClass>db.m1.small</DBInstanceClass>
</ReservedDBInstance>
</ReservedDBInstances>
</DescribeReservedDBInstancesResult>
<ResponseMetadata>
<RequestId>23400d50-2978-11e1-9e6d-771388d6ed6b</RequestId>
</ResponseMetadata>
</DescribeReservedDBInstancesResponse>
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).
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).
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/.
• 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.
Consola
Para crear un clúster de base de datos Aurora mediante 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 en https://
console.aws.amazon.com/rds/.
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.
3. En el panel de navegación, seleccione Databases (Bases de datos).
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.
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.
Una página Specify DB details (Especificar detalles de la base de datos) típica tiene un aspecto similar
al 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)
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).
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.
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).
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
de base de datos. Para obtener más información, consulte
Etiquetado de recursos de Amazon RDS (p. 349).
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.
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).
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.
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.
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.
Para Windows:
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.
Para Windows:
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.
Para Windows:
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.
Para Windows:
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.
Para Windows:
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.
Para Windows:
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.
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)
Sencillez
Aurora Serverless elimina gran parte de la complejidad de la administración de las instancias de base
de datos y la capacidad.
Escalabilidad
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.
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
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.
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.
Versión de API 2014-10-31
102
Amazon Aurora Guía del usuario de Aurora
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
No se permite SSL.
REQUIRED
Aurora Serverless utiliza certificados comodín. Si utiliza el cliente mysql para conectarse, actualmente
deberá usar el comando mysql compatible con MySQL 8.0.
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
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.
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.
aplicación cliente. También se escala a capacidad cero cuando no hay conexiones durante un periodo de
5 minutos.
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:
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.
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.
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).
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.
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.
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.
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
instancia de base de datos.
• 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.
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
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
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.
• 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
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).
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).
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).
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).
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.
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
un clúster de base de datos Amazon Aurora (p. 148).
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.
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.
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.
Para Windows:
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.
Para Windows:
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.
Cuando restaure una instantánea en un clúster de base de datos de Aurora Serverless, podrá establecer
los siguientes valores específicos:
• 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
datos, Aurora reanudará automáticamente la capacidad de procesamiento y se escalará para controlar el
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
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, seleccione la región de AWS
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).
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.
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
un clúster de base de datos Amazon Aurora (p. 148).
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.
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.
Para Windows:
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.
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.
• 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
datos, Aurora reanudará automáticamente la capacidad de procesamiento y se escalará para controlar el
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.
6. Elija Continue.
7. Elija Modify Cluster (Modificar clúster).
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:
Para Windows:
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 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.
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
Aurora Serverless (p. 104).
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:
En este ejemplo, se establece la capacidad de un clúster de base de datos Aurora Serverless denominado
sample-cluster en 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
capacidad válidos se incluyen los siguientes:
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 creó los clústeres de base de datos Aurora Serverless.
3. En el panel de navegación, seleccione Databases (Bases de datos).
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.
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.
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.
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
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).
Para conectarse a un clúster de base de datos de Aurora Serverless, use el punto de enlace de base de
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
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
Serverless (p. 144).
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
Región Enlace
UE (Irlanda) rds-data.eu-west-1.amazonaws.com
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.
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.
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.
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
Para Windows:
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.
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.
La API de datos proporciona las operaciones siguientes para ejecutar instrucciones SQL.
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.
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.
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.
CLOB STRING
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)
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)
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.
Para Windows:
{
"transactionId": "ABC1234567890xyz"
}
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
• --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.
• --database (opcional): el nombre de la base de datos.
• --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.
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.
Para Windows:
{
"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.
Para Windows:
{
"numberOfRecordsUpdated": 1
}
El siguiente comando de la CLI ejecuta una única instrucción SQL con parámetros.
Para Windows:
{
"numberOfRecordsUpdated": 1
}
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.
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.
Para Windows:
{
"generatedFields": [],
"numberOfRecordsUpdated": 0
}
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.
• --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.
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.
Para Windows:
Note
No incluya saltos de línea en la opción --parameter-sets.
Por ejemplo, el siguiente comando de la CLI finaliza una transacción SQL y confirma los cambios.
Para Windows:
{
"transactionStatus": "Transaction Committed"
}
Por ejemplo, el comando de la AWS CLI siguiente revierte una transacción SQL.
Para Windows:
{
"transactionStatus": "Rollback Complete"
}
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)
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'
}
],
[
{
'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'
}
]
]
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'
response2 = rdsData.execute_statement(
resourceArn = cluster_arn,
secretArn = secret_arn,
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]
response2 = rdsData.execute_statement(
resourceArn = cluster_arn,
secretArn = secret_arn,
database = 'mydb',
parameters = paramSet,
sql = 'insert into employees(first_name, last_name)
VALUES(:firstname, :lastname)')
'numberOfRecordsUpdated': 1}
response2['numberOfRecordsUpdated']
1
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.
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
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'
tr = rdsData.begin_transaction(
resourceArn = cluster_arn,
secretArn = secret_arn,
database = 'mydb')
response3 = rdsData.execute_statement(
resourceArn = cluster_arn,
secretArn = secret_arn,
database = 'mydb',
sql = 'insert into employees(first_name, last_name) values('XIULAN', 'WANG')',
transactionId = tr)
cr = rdsData.commit_transaction(
resourceArn = cluster_arn,
secretArn = secret_arn,
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
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.
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)
Puede ejecutar una instrucción SELECT y recopilar los resultados con una aplicación Java.
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;
}
}
Puede iniciar una transacción SQL, ejecutar una o varias instrucciones SQL y luego confirmar los cambios
con una aplicación Java.
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.
Si no especifica un ID de transacción, los cambios que se generen a partir de la llamada se
confirmarán automáticamente.
package com.amazonaws.rdsdata.examples;
import com.amazonaws.services.rdsdata.AWSRDSData;
import com.amazonaws.services.rdsdata.AWSRDSDataClient;
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;
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.
package com.amazonaws.rdsdata.examples;
import com.amazonaws.services.rdsdata.AWSRDSData;
import com.amazonaws.services.rdsdata.AWSRDSDataClient;
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;
rdsData.batchExecuteStatement(request);
}
}
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)
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).
Para solventar este problema, asegúrese de que cada fila en un conjunto de resultados sea 64 KB o
menos.
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.
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
documentación de MySQL.
• 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 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).
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
Serverless (p. 125).
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",
"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.
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 creó los clústeres de base de datos Aurora Serverless a los que quiera consultar.
3. En el panel de navegación, seleccione Databases (Bases de datos).
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).
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
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.
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).
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.
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:
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
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.
• 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
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).
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
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.
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:
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.
• 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
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).
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).
Para obtener más información, consulte Migración de datos a un clúster de base de datos de Amazon
Aurora MySQL (p. 502).
Para obtener más información, consulte Migración de datos a Amazon Aurora con compatibilidad con
PostgreSQL (p. 772).
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
Amazon Aurora (p. 158).
• 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.
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)
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:
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)
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)
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.
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)
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.
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.
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.
• 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
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.
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.
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:
Canadá (Central)
China (Pekín)
China (Ningxia)
UE (Fráncfort)
UE (Irlanda)
UE (Londres)
UE (París)
UE Estocolmo
• 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.
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).
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
Amazon Aurora (p. 170).
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.
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).
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.
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.
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.
• 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
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.
Para obtener más información acerca de la administración de identidades y acceso para Aurora, continúe
con las páginas siguientes:
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)
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.
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.
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": [
"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.
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).
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).
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.
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)
• 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)
• 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.
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.
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": "*"
}
]
}
{
"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*",
"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).
Para ver una lista de acciones de Aurora en la Acciones definidas por Amazon RDSGuía del usuario de
IAM.
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
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
{
"Version":"2012-10-17",
"Statement":[
{
"Sid":"AllowRDSDescribe",
"Effect":"Allow",
"Action":"rds:Describe*",
"Resource":"*"
}
]
}
{
"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"
]
}
]
}
{
"Version":"2012-10-17",
"Statement":[
{
"Sid":"AllowDevTestCreate",
"Effect":"Allow",
"Action":[
"rds:ModifyDBInstance",
"rds:CreateDBSnapshot"
],
"Resource":"*",
"Condition":{
"StringEquals":{
"rds:db-tag/stage":[
"development",
"test"
]
}
}
}
]
}
{
"Version":"2012-10-17",
"Statement":[
{
"Sid":"DenyDelete1",
"Effect":"Deny",
"Action":"rds:DeleteDBInstance",
"Resource":"arn:aws:rds:us-west-2:123456789012:db:my-mysql-instance"
}
]
}
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.
"Version":"2012-10-17",
"Statement":[
{
"Sid":"AllowMySQLCreate",
"Effect":"Allow",
"Action":"rds:CreateDBInstance",
"Resource":"*",
"Condition":{
"StringEquals":{
"rds:DatabaseEngine":"mysql"
},
"Bool":{
"rds:MultiAz": false
}
}
}
]
}
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",
"Action":"rds:CreateDBInstance",
"Resource":"*",
"Condition":{
"StringEquals":{
"rds:DatabaseClass":[
"db.r3.8xlarge",
"db.m4.10xlarge"
]
}
}
},
{
"Sid":"DenyPIOPSCreate",
"Effect":"Deny",
"Action":"rds:CreateDBInstance",
"Resource":"*",
"Condition":{
"NumericNotEquals":{
"rds:Piops":"0"
}
}
}
]
{
"Version" : "2012-10-17",
"Statement" : [{
"Effect" : "Allow",
"Action" : [ "rds:AddTagsToResource", "rds:RemoveTagsFromResource"
],
"Resource" : "*",
"Condition" : { "streq" : { "rds:req-tag/stage" : [ "test", "qa",
"production" ] } }
}
]
}
}
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
En la tabla siguiente, se enumeran los identificadores de etiqueta de RDS que puede usar en un elemento
Condition.
"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":"*"
}
]
}
Para ver una lista de acciones de Aurora en la Acciones definidas por Amazon RDSGuía del usuario de
IAM.
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.
{
"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",
"Action":"rds:CreateDBInstance",
"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).
{
"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"
}
}
}
]
}
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.
• 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)
• 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.
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).
• 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.
• 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.
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.
Para habilitar o deshabilitar la autenticación de IAM para un clúster de base de datos existente
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.
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
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.
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
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.
• 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
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.
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.
{
"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.
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.
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.
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)
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)
En el siguiente ejemplo se muestra cómo obtener un token de autenticación firmado mediante la AWS CLI.
• --hostname: el nombre de host del clúster de base de datos a los que desea obtener acceso.
rdsmysql.cdgmuqiadpid.us-west-2.rds.amazonaws.com:3306/?Action=connect&DBUser=jane_doe&X-
Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Expires=900...
• --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 )"
+---------------+-------------+
| Variable_name | Value
|
+---------------+-------------+
| ... | ...
| Ssl_cipher | AES256-SHA
|
| ... | ...
| Ssl_version | TLSv1.1
|
| ... | ...
+-----------------------------+
Temas
• Generación de un token de autenticación de IAM (p. 189)
• 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 )"
• --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...
• 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.
Temas
• Generación de un token de autenticación de IAM (p. 190)
• 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.
package com.amazonaws.codesamples;
import com.amazonaws.auth.DefaultAWSCredentialsProviderChain;
import com.amazonaws.services.rds.auth.GetIamAuthTokenRequest;
import com.amazonaws.services.rds.auth.RdsIamAuthTokenGenerator;
return authToken;
}
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.DefaultAWSCredentialsProviderChain;
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;
//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")) {
canonicalQueryString += "&";
}
}
String canonicalHeaders = "host:" + hostName + ":" + port + '\n';
requestWithoutSignature = hostName + ":" + port + "/?" + canonicalQueryString;
+ e.getMessage(), e);
}
}
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:
package com.amazonaws.samples;
import com.amazonaws.services.rds.auth.RdsIamAuthTokenGenerator;
import com.amazonaws.services.rds.auth.GetIamAuthTokenRequest;
import com.amazonaws.auth.BasicAWSCredentials;
import com.amazonaws.auth.DefaultAWSCredentialsProviderChain;
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;
//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;
clearSslProperties();
/**
* This method returns a connection to the db instance authenticated using IAM Database
Authentication
* @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);
.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();
}
/**
* 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");
}
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)
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.
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.
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.
En este caso, Mary pide a su administrador que actualice sus políticas para que pueda realizar la acción
iam:PassRole.
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
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.
Para comenzar de inmediato, consulte Creación del primer grupo y usuario delegado de IAM en la Guía del
usuario de IAM.
• 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.
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).
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
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 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
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
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).
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.
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.
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
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 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).
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).
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.
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).
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).
• 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.
• 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
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.
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
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.
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
mismo número de puerto que especificó para la regla de grupo de seguridad de VPC (sg-dbsrv1) que
creó en el paso 3.
Para obtener más información acerca del uso de una VPC, consulte VPC Amazon Virtual Private Cloud y
Amazon Aurora (p. 211).
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).
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).
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.
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.
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
Amazon Aurora Guía del usuario de Aurora
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.
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.
ni mantenga de forma activa. Sin embargo, debe eliminar todos los clústeres para poder eliminar el rol
vinculado al servicio.
Para comprobar si la función vinculada al servicio tiene una sesión activa en la consola de IAM
Si desea eliminar la función de AWSServiceRoleForRDS, primero debe eliminar todos sus clústeres de
base de datos.
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
en la Guía del usuario de IAM.
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.
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.
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
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, elija la región de AWS en la
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.
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
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.
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.
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.
Para crear un grupo de subredes de base de datos para el uso con un clúster de base de datos de Aurora
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.
• 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:
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 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).
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.
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.
Para activar ClassicLink entre una instancia de base de datos de una VPC y una instancia EC2
que no esté en una 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 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.
• 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.
• 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).
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)
• 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.
• 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.
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.
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).
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:
Para obtener instrucciones sobre cómo crear subredes, consulte Creación de una VPC con subredes
públicas y privadas (p. 228).
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.
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).
8. Seleccione Create.
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.
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.
Amazon Aurora Creación de un clúster de base de datos de Amazon Aurora (p. 85)
Note
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
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.
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
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:
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).
Anote el ID del grupo de seguridad, ya que lo necesitará más tarde en este tutorial.
Versión de API 2014-10-31
229
Amazon Aurora Guía del usuario de Aurora
Tutorial: Creación de una Amazon VPC para
utilizarla con una instancia de base de datos
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.
2. Abra la consola de Amazon VPC en https://console.aws.amazon.com/vpc/.
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).
5. En la página Edit inbound rules (Editar reglas de entrada), seleccione Add Rule (Añadir regla).
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.
• 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.
• 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.
• 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).
6. Seleccione Create.
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.
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)
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)
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.
• 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).
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
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 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:
Example
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:
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.
Consola
Para iniciar un clúster de Aurora
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 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
siguientes parámetros:
Example
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.
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
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
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 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
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).
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).
Para Windows:
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
Amazon Aurora (p. 239).
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).
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.
Consola
Para modificar una instancia de base de datos en un clúster de base de datos
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 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
Configuración para Amazon Aurora (p. 239).
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.
O bien, elija Back para editar los cambios o Cancel para cancelarlos.
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
Configuración para Amazon Aurora (p. 239).
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
Para Windows:
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
Configuración para Amazon Aurora (p. 239).
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).
Mediante la API
de RDS, realice
una llamada a
ModifyDBInstance y
establezca el parámetro
CACertificateIdentifier.
Mediante la API
de RDS, realice
una llamada a
ModifyDBCluster y
establezca el parámetro
Port.
Mediante la API
de RDS, realice
una llamada a
ModifyDBInstance y
establezca el parámetro
NewDBInstanceIdentifier.
Mediante la API
de RDS, realice
una llamada a
ModifyDBCluster y
establezca el parámetro
CloudwatchLogsExportConfiguration.
Mediante la API
de RDS, realice
una llamada a
ModifyDBCluster y
establezca el parámetro
MasterUserPassword.
Mediante la API
de RDS, realice
una llamada a
ModifyDBCluster y
establezca el parámetro
VpcSecurityGroupIds.
--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
--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.
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
AWS, la AWS CLI o la API de RDS.
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
clúster de base de datos de Aurora (p. 348).
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
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/.
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
ocultar una instancia de base de datos en una VPC desde
Internet. (p. 223).
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).
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.
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.
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.
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-
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.
Para Windows:
El comando siguiente crea una nueva réplica de Aurora compatible con MySQL 5.6 llamada sample-
instance-us-west-2a.
Para Windows:
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.
Temas
• Escalado del almacenamiento (p. 258)
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.
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
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.
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)
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
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 :
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
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:
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)
• 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
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.
Consola
Para crear un grupo de parámetros de base de datos
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 el panel de navegación, seleccione Parameter groups (Grupos de parámetros).
3. Elija Create parameter group.
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”.
• --db-parameter-group-name
• --db-parameter-group-family
• --description
Para mostrar todas las familias de grupos de parámetros disponibles, use el siguiente comando:
Note
Example
Para Windows:
--db-parameter-group-name mydbparametergroup ^
--db-parameter-group-family aurora5.6 ^
--description "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
Consola
Para crear un grupo de parámetros de clúster de base de datos
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 el panel de navegación, seleccione Parameter groups (Grupos de parámetros).
3. Elija Create parameter group.
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”.
• --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:
Note
Example
Para Windows:
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
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.
Consola
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 el panel de navegación, seleccione Parameter groups (Grupos de parámetros).
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.
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:
• --db-parameter-group-name
• --parameters
Amazon RDS no permite pasar varios valores de parámetros delimitados por comas para un solo
parámetro.
Example
"ParameterName=max_allowed_packet,ParameterValue=1024,ApplyMethod=immediate"
Para Windows:
"ParameterName=max_allowed_packet,ParameterValue=1024,ApplyMethod=immediate"
DBPARAMETERGROUP mydbparametergroup
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:
• DBParameterGroupName
• Parameters
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.
Consola
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 el panel de navegación, seleccione Parameter groups (Grupos de parámetros).
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 desea modificar. Puede desplazarse por los parámetros
utilizando las teclas de flecha de la parte superior derecha del cuadro de diálogo.
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:
• --db-cluster-parameter-group-name
• --parameters
Amazon RDS no permite pasar varios valores de parámetros delimitados por comas para un solo
parámetro.
Example
"ParameterName=server_audit_logs_upload,ParameterValue=1,ApplyMethod=immediate"
Para Windows:
"ParameterName=server_audit_logs_upload,ParameterValue=1,ApplyMethod=immediate"
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:
• DBClusterParameterGroupName
• Parameters
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
parámetros 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
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 el panel de navegación, seleccione Parameter groups (Grupos de parámetros).
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
Para Windows:
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
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
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 el panel de navegación, seleccione Parameter groups (Grupos de parámetros).
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.
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
Para Windows:
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
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
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 el panel de navegación, seleccione Parameter groups (Grupos de parámetros).
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.
Para Windows:
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.
Consola
Para obtener una lista de todos los grupos de parámetros de clúster de base de datos de una
cuenta de AWS
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 el panel de navegación, seleccione Parameter groups (Grupos de parámetros).
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.
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
DBCLUSTERPARAMETERGROUPS arn:aws:rds:us-west-2:1234567890:cluster-
pg:mydbclusterparametergroup mydbclusterparametergroup aurora5.6 My new cluster
parameter group
Para Windows:
DBCLUSTERPARAMETERGROUPS arn:aws:rds:us-west-2:1234567890:cluster-
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.
Consola
Para ver los valores de los parámetros de un grupo de parámetros de base de datos
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 el panel de navegación, seleccione Parameter groups (Grupos 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.
• --db-parameter-group-name
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.
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.
• DBParameterGroupName
Consola
Para ver los valores de los parámetros de un grupo de parámetros de clúster de base de datos
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 el panel de navegación, seleccione Parameter groups (Grupos de parámetros).
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.
• --db-cluster-parameter-group-name
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.
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.
• DBClusterParameterGroupName
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 el panel de navegación, seleccione Parameter groups (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).
Sintaxis
{FormulaVariable}
{FormulaVariable*Integer}
{FormulaVariable*Integer/Integer}
{FormulaVariable/Integer}
AllocatedStorage
Devuelve el número del puerto utilizado para conectarse a la instancia de base de datos.
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
Multiplica las expresiones, devolviendo el producto de las expresiones. Los decimales de las
expresiones se truncan, no se redondean.
Sintaxis
expression * expression
IF()
Devuelve un argumento.
Sintaxis
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 el valor más pequeño de una lista de números enteros o fórmulas de parámetros.
Sintaxis
LEAST(argument1, argument2,...argumentn)
Sintaxis
SUM(argument1, argument2,...argumentn)
LEAST({DBInstanceClassMemory/393040}, 20000)
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.
• 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.
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:
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 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.
• --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.
--restore-type copy-on-write \
--use-latest-restorable-time
Para Windows:
Note
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)
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)
Consola
Para conceder permisos para clonar su clúster con 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 en https://
console.aws.amazon.com/rds/.
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 Windows:
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.
API de RAM
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:
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 el panel de navegación, elija Snapshots (Instantáneas).
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.
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
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.
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)
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
Los resultados del comando anterior muestran todas las invitaciones para clonar clústeres, incluidas
las que ya haya aceptado o rechazado.
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
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
Para Windows:
Para aceptar invitaciones para compartir el clúster de alguien utilizando las API de RAM y RDS
Consola
Para clonar un clúster de Aurora propiedad de otra cuenta de AWS 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 en https://
console.aws.amazon.com/rds/.
2. En el panel de navegación, seleccione Databases (Bases de datos).
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.
--restore-type=copy-on-write \
--use-latest-restorable-time
Para Windows:
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.
Para Windows:
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. 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*",
Versión de API 2014-10-31
293
Amazon Aurora Guía del usuario de Aurora
Clonación entre cuentas
"kms:DescribeKey"
],
"Resource": "*"
},
{
"Sid": "Allow attachment of persistent resources",
"Effect": "Allow",
"Principal": {"AWS": [
"arn:aws:iam::account_id:user/KeyUser",
"arn:aws:iam::account_id:root"
]},
"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.
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.
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. 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*",
"kms:DescribeKey"
],
"Resource": "*"
},
{
"Sid": "Allow attachment of persistent resources",
"Effect": "Allow",
"Principal": {"AWS": [
"arn:aws:iam::account_id:user/KeyUser",
"arn:aws:iam::account_id:root"
]},
"Action": [
"kms:CreateGrant",
"kms:ListGrants",
"kms:RevokeGrant"
],
"Resource": "*",
"Condition": {"Bool": {"kms:GrantIsForAWSResource": true}}
}
]
}
AWS CLI
Para comprobar si un clúster de base de datos es un clon entre cuentas utilizando la AWS CLI
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.
...
},
{
"EarliestRestorableTime": "2019-04-09T16:01:07.398Z",
"Engine": "aurora",
"EngineVersion": "5.6.10a",
"CrossAccountClone": true,
...
},
{
"StorageEncrypted": false,
"DBClusterArn": "arn:aws:rds:us-east-1:12345678:cluster:cluster-abcdefgh",
"Engine": "aurora",
"EngineVersion": "5.6.10a",
}
]
}
API de RDS
Para comprobar si un clúster de base de datos es un clon entre cuentas utilizando la API de RDS
El siguiente ejemplo muestra un valor de devolución que demuestra los clústeres clonados tanto
reales como potenciales.
{
"DBClusters": [
{
"EarliestRestorableTime": "2019-05-01T21:17:54.106Z",
"Engine": "aurora",
"EngineVersion": "5.6.10a",
"CrossAccountClone": false,
...
},
{
"EarliestRestorableTime": "2019-04-09T16:01:07.398Z",
"Engine": "aurora",
"EngineVersion": "5.6.10a",
"CrossAccountClone": true,
...
},
{
"StorageEncrypted": false,
"DBClusterArn": "arn:aws:rds:us-east-1:12345678:cluster:cluster-abcdefgh",
"Engine": "aurora",
"EngineVersion": "5.6.10a"
}
]
}
• 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).
• 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).
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
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).
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.
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.
• 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.
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.
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)
Para añadir una política de Auto Scaling a un clúster de base de datos Aurora
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 el panel de navegación, seleccione Databases (Bases de datos).
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:
• 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.
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
réplicas de 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
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
Example
Para Windows:
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:
• 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,
por ejemplo cluster:myscalablecluster.
• 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
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
}
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)
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:
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"
}
}
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":
{
"MetricName": "CPUUtilization",
"Namespace": "AWS/RDS",
"Dimensions": [
{"Name": "DBClusterIdentifier","Value": "my-db-cluster"},
{"Name": "Role","Value": "READER"}
],
"Statistic": "Average",
"Unit": "Percent"
}
}
Example
En el siguiente ejemplo se describe una configuración de seguimiento de destino para una política de
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.
{
"TargetValue": 40.0,
"PredefinedMetricSpecification":
{
"PredefinedMetricType": "RDSReaderAverageCPUUtilization"
},
"ScaleInCooldown": 600,
"ScaleOutCooldown": 300
}
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
API de Auto Scaling de aplicaciones.
Example
En el siguiente ejemplo se describe una configuración de seguimiento de destino para una política de
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.
{
"TargetValue": 40.0,
"PredefinedMetricSpecification":
{
"PredefinedMetricType": "RDSReaderAverageCPUUtilization"
},
"DisableScaleIn": true
}
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:
Example
Para Windows:
--service-namespace rds ^
--scalable-dimension rds:cluster:ReadReplicaCount ^
--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
siguientes parámetros:
Example
POST / HTTP/1.1
Host: autoscaling.us-east-2.amazonaws.com
Accept-Encoding: identity
Content-Length: 219
X-Amz-Target: AnyScaleFrontendService.PutScalingPolicy
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
{
"PolicyName": "myscalablepolicy",
"ServiceNamespace": "rds",
"ResourceId": "cluster:myscalablecluster",
"ScalableDimension": "rds:cluster:ReadReplicaCount",
"PolicyType": "TargetTrackingScaling",
"TargetTrackingScalingPolicyConfiguration": {
"TargetValue": 40.0,
"PredefinedMetricSpecification":
{
"PredefinedMetricType": "RDSReaderAverageCPUUtilization"
}
}
}
Para editar una política de Auto Scaling para un clúster de base de datos Aurora
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 el panel de navegación, seleccione Databases (Bases de datos).
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.
• 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).
Para eliminar una política de Auto Scaling para un clúster de base de datos Aurora
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 el panel de navegación, seleccione Databases (Bases de datos).
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).
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:
Example
Para Windows:
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:
Example
POST / HTTP/1.1
Host: autoscaling.us-east-2.amazonaws.com
Accept-Encoding: identity
Content-Length: 219
X-Amz-Target: AnyScaleFrontendService.DeleteScalingPolicy
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
{
"PolicyName": "myscalablepolicy",
"ServiceNamespace": "rds",
"ResourceId": "cluster:myscalablecluster",
"ScalableDimension": "rds:cluster:ReadReplicaCount"
}
Temas relacionados
• Integración de Aurora con otros servicios de AWS (p. 297)
Temas relacionados
• Administración de un clúster de base de datos de Amazon Aurora (p. 232)
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)
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
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.
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.
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).
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).
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
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 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.
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
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
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 el panel de navegación, seleccione Instances (Instancias).
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).
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
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
Example
Para Windows:
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
siguientes parámetros:
• DBClusterIdentifier
• DBClusterSnapshotIdentifier
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.
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).
Para restaurar un clúster de base de datos desde una instantánea de clúster de base de datos
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 el panel de navegación, elija Snapshots (Instantáneas).
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.
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
Para Windows:
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:
• DBClusterIdentifier
• SnapshotIdentifier
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).
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.
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).
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.
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
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
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.
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.
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.
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 el panel de navegación, elija Snapshots (Instantáneas).
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.
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
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:
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
Para Windows:
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:
Example
https://rds.us-west-1.amazonaws.com/
?Action=CopyDBClusterSnapshot
&CopyTags=true
&SignatureMethod=HmacSHA256
&SignatureVersion=4
&SourceDBSnapshotIdentifier=arn%3Aaws%3Ards%3Aus-east-1%3A123456789012%3Acluster-
snapshot%3Aaurora-cluster1-snapshot-20130805
&TargetDBSnapshotIdentifier=myclustersnapshotcopy
&Version=2013-09-09
&X-Amz-Algorithm=AWS4-HMAC-SHA256
&X-Amz-Credential=AKIADQKE4SARGYLE/20140429/us-west-1/rds/aws4_request
&X-Amz-Date=20140429T175351Z
&X-Amz-SignedHeaders=content-type;host;user-agent;x-amz-content-sha256;x-amz-date
&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:
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
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
Para Linux, OS X o Unix:
Para Windows:
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:
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
https://rds.us-east-1.amazonaws.com/
?Action=CopyDBClusterSnapshot
&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
&SignatureMethod=HmacSHA256
&SignatureVersion=4
&SourceDBClusterSnapshotIdentifier=arn%3Aaws%3Ards%3Aus-
west-2%3A123456789012%3Acluster-snapshot%3Aaurora-cluster1-snapshot-20161115
&TargetDBClusterSnapshotIdentifier=myclustersnapshotcopy
&Version=2014-10-31
&X-Amz-Algorithm=AWS4-HMAC-SHA256
&X-Amz-Credential=AKIADQKE4SARGYLE/20161117/us-east-1/rds/aws4_request
&X-Amz-Date=20161117T221704Z
&X-Amz-SignedHeaders=content-type;host;user-agent;x-amz-content-sha256;x-amz-date
&X-Amz-Signature=da4f2da66739d2e722c85fcfd225dc27bba7e2b8dbea8d8612434378e52adccf
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.
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.
https://rds.us-west-2.amazonaws.com/
?Action=ModifyDBClusterSnapshotAttribute
&AttributeName=restore
&DBClusterSnapshotIdentifier=manual-snapshot1
&SignatureMethod=HmacSHA256&SignatureVersion=4
&ValuesToAdd.member.1=123451234512
&ValuesToAdd.member.2=123456789012
&Version=2014-10-31
&X-Amz-Algorithm=AWS4-HMAC-SHA256
&X-Amz-Credential=AKIADQKE4SARGYLE/20150922/us-west-2/rds/aws4_request
&X-Amz-Date=20150922T220515Z
&X-Amz-SignedHeaders=content-type;host;user-agent;x-amz-content-sha256;x-amz-date
&X-Amz-Signature=ef38f1ce3dab4e1dbf113d8d2a265c67d17ece1999ffd36be85714ed36dddbb3
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.
https://rds.us-west-2.amazonaws.com/
?Action=CopyDBClusterSnapshot
&CopyTags=true
&SignatureMethod=HmacSHA256
&SignatureVersion=4
&SourceDBClusterSnapshotIdentifier=arn:aws:rds:us-west-2:987654321:cluster-
snapshot:aurora-cluster1-snapshot-20130805
&TargetDBClusterSnapshotIdentifier=dbclustersnapshot1
&Version=2013-09-09
&X-Amz-Algorithm=AWS4-HMAC-SHA256
&X-Amz-Credential=AKIADQKE4SARGYLE/20150922/us-west-2/rds/aws4_request
&X-Amz-Date=20140429T175351Z
&X-Amz-SignedHeaders=content-type;host;user-agent;x-amz-content-sha256;x-amz-date
&X-Amz-Signature=9164337efa99caf850e874a1cb7ef62f3cea29d0b448b9e0e7c53b288ddffed2
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.
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.
https://rds.us-west-2.amazonaws.com/
?Action=ModifyDBClusterSnapshotAttribute
&AttributeName=restore
&DBClusterSnapshotIdentifier=manual-snapshot1
&SignatureMethod=HmacSHA256&SignatureVersion=4
&ValuesToAdd.member.1=123451234512
&ValuesToAdd.member.2=123456789012
&Version=2014-10-31
&X-Amz-Algorithm=AWS4-HMAC-SHA256
&X-Amz-Credential=AKIADQKE4SARGYLE/20150922/us-west-2/rds/aws4_request
&X-Amz-Date=20150922T220515Z
&X-Amz-SignedHeaders=content-type;host;user-agent;x-amz-content-sha256;x-amz-date
&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).
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.
https://rds.us-west-2.amazonaws.com/
?Action=CopyDBClusterSnapshot
&CopyTags=true
&SignatureMethod=HmacSHA256
&SignatureVersion=4
&SourceDBClusterSnapshotIdentifier=arn:aws:rds:us-west-2:987654321:cluster-
snapshot:aurora-cluster1-snapshot-20130805
&TargetDBClusterSnapshotIdentifier=dbclustersnapshot1
&Version=2013-09-09
&X-Amz-Algorithm=AWS4-HMAC-SHA256
&X-Amz-Credential=AKIADQKE4SARGYLE/20150922/us-west-2/rds/aws4_request
&X-Amz-Date=20140429T175351Z
&X-Amz-SignedHeaders=content-type;host;user-agent;x-amz-content-sha256;x-amz-date
&X-Amz-Signature=9164337efa99caf850e874a1cb7ef62f3cea29d0b448b9e0e7c53b288ddffed2
• 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
clúster de base de datos (p. 319).
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:
• 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.
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.
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.
{
"Id": "key-policy-1",
"Version": "2012-10-17",
"Statement": [
{
"Sid": "Allow use of the key",
"Effect": "Allow",
"Principal": {"AWS": [
"arn:aws:iam::111122223333:user/KeyUser",
"arn:aws:iam::444455556666:root"
]},
"Action": [
"kms:CreateGrant",
"kms:Encrypt",
"kms:Decrypt",
"kms:ReEncrypt*",
"kms:GenerateDataKey*",
"kms:DescribeKey"
],
"Resource": "*"
},
{
"Sid": "Allow attachment of persistent resources",
"Effect": "Allow",
"Principal": {"AWS": [
"arn:aws:iam::111122223333:user/KeyUser",
"arn:aws:iam::444455556666:root"
]},
"Action": [
"kms:CreateGrant",
"kms:ListGrants",
"kms:RevokeGrant"
],
"Resource": "*",
"Condition": {"Bool": {"kms:GrantIsForAWSResource": true}}
}
]
}
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:GenerateDataKey*",
"kms:DescribeKey",
"kms:CreateGrant",
"kms:RetireGrant"
],
"Resource": ["arn:aws:kms:us-west-2:111122223333:key/c989c1dd-a3f2-4a5d-8d96-
e793d082ab26"]
},
{
"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.
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
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 el panel de navegación, elija Snapshots (Instantáneas).
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 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
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 el panel de navegación, elija Snapshots (Instantáneas).
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.
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.
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.
Puede restaurar un clúster de base de datos a un punto en el tiempo con la Consola de administración de
AWS, la AWS CLI o la API de RDS.
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 el panel de navegación, seleccione Databases (Bases de datos).
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).
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
Para Windows:
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
• DBClusterIdentifier
• RestoreToTime
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:
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/.
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.
Example
Para Windows:
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.
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
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:
• 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
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
Amazon RDS (p. 344).
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).
Consola
Para administrar la actualización de un clúster de base de datos
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 el panel de navegación, seleccione Databases (Bases 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:
Note
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
Para Windows:
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
Para Windows:
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:
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
Para Windows:
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.
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.
Consola
Para ajustar la ventana de mantenimiento preferida del clúster de base de datos
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 el panel de navegación, seleccione Databases (Bases 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.
O bien, elija Back para editar los cambios o Cancel para cancelarlos.
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:
• --db-cluster-identifier
• --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.
Para Windows:
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.
https://rds.us-west-2.amazonaws.com/
?Action=ModifyDBCluster
&DBClusterIdentifier=my-cluster
&PreferredMaintenanceWindow=Tue:04:00-Tue:04:30
&SignatureMethod=HmacSHA256
&SignatureVersion=4
&Version=2014-10-31
&X-Amz-Algorithm=AWS4-HMAC-SHA256
&X-Amz-Credential=AKIADQKE4SARGYLE/20140725/us-east-1/rds/aws4_request
&X-Amz-Date=20161017T161457Z
&X-Amz-SignedHeaders=content-type;host;user-agent;x-amz-content-sha256;x-amz-date
&X-Amz-Signature=d6d1c65c2e94f5800ab411a3f7336625820b103713b6c063430900514e21d784
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.
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 el panel de navegación, elija Databases (Bases de datos) y, a continuación, seleccione la instancia
de base de datos que desee reiniciar.
3. Para Actions (Acciones), elija Reboot (Reiniciar).
CLI
Para reiniciar una instancia de base de datos mediante la AWS CLI, llame al comando reboot-db-
instance.
Para Windows:
API
Para reiniciar una instancia de base de datos mediante la API de Amazon RDS, llame a la acción
RebootDBInstance.
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,
consulte Replicación de clústeres de base de datos Amazon Aurora MySQL entre distintas regiones de
AWS (p. 599).
Consola
Para eliminar una instancia de base de datos
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 el panel de navegación, elija Databases (Bases de datos) y, a continuación, seleccione la instancia
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
Para Windows:
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.
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.
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).
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,
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.
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 el panel de navegación, seleccione Databases (Bases 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).
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 el panel de navegación, seleccione Databases (Bases 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).
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.
Tag Las etiquetas son pares clave-valor que define el usuario. En un conjunto de
etiquetas puede haber entre 1 y 50 etiquetas.
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.
arn:aws:rds:<region>:<account number>:<resourcetype>:<name>
En la siguiente tabla se muestra el formato que debe utilizar al crear un ARN para un tipo de recurso
concreto de Amazon RDS.
Por ejemplo:
arn:aws:rds:us-east-2:123456789012:db:my-mysql-instance-1
Por ejemplo:
arn:aws:rds:us-east-2:123456789012:cluster:my-aurora-
cluster-1
Por ejemplo:
arn:aws:rds:us-east-2:123456789012:es:my-subscription
arn:aws:rds:us-east-2:123456789012:og:my-og
arn:aws:rds:us-east-2:123456789012:pg:my-param-enable-logs
arn:aws:rds:us-east-2:123456789012:cluster-pg:my-cluster-
param-timezone
arn:aws:rds:us-east-2:123456789012:ri:my-reserved-
postgresql
arn:aws:rds:us-east-2:123456789012:secgrp:my-public
Por ejemplo:
arn:aws:rds:us-east-2:123456789012:snapshot:my-mysql-
snap-20130507
arn:aws:rds:us-east-2:123456789012:cluster-snapshot:my-
aurora-snap-20160809
arn:aws:rds:us-east-2:123456789012:subgrp:my-subnet-10
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.
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
Para Linux, OS X o Unix:
Para Windows:
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.
DescribeEventSubscriptions EventSubscriptionArn
DescribeCertificates CertificateArn
DescribeDBParameterGroups DBParameterGroupArn
DescribeDBClusterParameterGroups DBClusterParameterGroupArn
DescribeDBInstances DBInstanceArn
DescribeDBSecurityGroups DBSecurityGroupArn
DescribeDBSnapshots DBSnapshotArn
DescribeEvents SourceArn
DescribeReservedDBInstances ReservedDBInstanceArn
DescribeDBSubnetGroups DBSubnetGroupArn
DescribeOptionGroups OptionGroupArn
DescribeDBClusters DBClusterArn
DescribeDBClusterSnapshots DBClusterSnapshotArn
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)
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.
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.
SHOW @@aurora_version;
Temas relacionados
• Administración de un clúster de base de datos de Amazon Aurora (p. 232)
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)
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.
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.
Herramientas de monitorización
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.
• 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
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
• 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
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.
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).
Métrica Descripción
Unidades: bytes
BurstBalance El porcentaje de créditos de E/S del bucket por ráfaga SSD de uso
general (gp2) disponibles.
Unidades: porcentaje
Unidades: porcentaje
Métrica Descripción
el CPUCreditBalance no persiste y se pierden todos los créditos
acumulados.
Unidades: recuento
Unidades: recuento
El número de trabajos del Agente SQL que han producido error durante
FailedSQLServerAgentJobsCount
el último minuto.
Unidad: recuento/minuto
Unidades: bytes
Unidades: bytes
Unidades: recuento
Unidades: bytes/segundo
Unidades: bytes/segundo
Unidades: megabytes
Unidades: recuento/segundo
Unidades: segundos
Métrica Descripción
Unidades: bytes/segundo
Unidades: segundos
Unidades: megabytes
Unidades: bytes
Unidades: megabytes
Unidades: bytes/segundo
Unidades: recuento/segundo
Unidades: segundos
Unidades: bytes/segundo
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.
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.
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.
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
• Llame a put-metric-alarm. Para obtener más información, consulte AWS CLI Command
Reference.
• Llame a PutMetricAlarm. Para obtener más información, consulte Amazon CloudWatch API
Reference
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).
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.
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).
Para ver métricas de base de datos y de sistema operativo para una instancia de base de datos
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 el panel de navegación, seleccione Databases (Bases 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:
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.
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.
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
Para ver las estadísticas de uso y desempeño de una instancia de base de datos
• Statistics.member.1 = Average
• Namespace = AWS/RDS
• StartTime = 2009-10-16T00:00:00
• EndTime = 2009-10-16T00:02:00
• Period = 60
• MeasureName = FreeStorageSpace
• 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.
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.
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.
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.
Si la AWS CLI está configurada para salida JSON, el comando devuelve lo siguiente.
{
"DBClusters": [
{
"Status": "available",
"Engine": "aurora",
"Endpoint": "sample-cluster1.cluster-123456789012.us-east-1.rds.amazonaws.com"
"AllocatedStorage": 1,
"DBClusterIdentifier": "sample-cluster1",
"MasterUsername": "mymasteruser",
"EarliestRestorableTime": "2016-03-30T03:35:42.563Z",
"DBClusterMembers": [
{
"IsClusterWriter": false,
"DBClusterParameterGroupStatus": "in-sync",
"DBInstanceIdentifier": "sample-replica"
},
{
"IsClusterWriter": true,
"DBClusterParameterGroupStatus": "in-sync",
"DBInstanceIdentifier": "sample-primary"
}
],
"Port": 3306,
"PreferredBackupWindow": "03:34-04:04",
"VpcSecurityGroups": [
{
"Status": "active",
"VpcSecurityGroupId": "sg-ddb65fec"
}
],
"DBSubnetGroup": "default",
"StorageEncrypted": false,
"DatabaseName": "sample",
"EngineVersion": "5.6.10a",
"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"
},
{
"Status": "available",
"Engine": "aurora",
"Endpoint": "aurora-sample.cluster-123456789012.us-east-1.rds.amazonaws.com",
"AllocatedStorage": 1,
"DBClusterIdentifier": "aurora-sample-cluster",
"MasterUsername": "mymasteruser",
"EarliestRestorableTime": "2016-03-30T10:21:34.826Z",
"DBClusterMembers": [
{
"IsClusterWriter": false,
"DBClusterParameterGroupStatus": "in-sync",
"DBInstanceIdentifier": "aurora-replica-sample"
},
{
"IsClusterWriter": true,
"DBClusterParameterGroupStatus": "in-sync",
"DBInstanceIdentifier": "aurora-sample"
}
],
"Port": 3306,
"PreferredBackupWindow": "10:20-10:50",
"VpcSecurityGroups": [
{
"Status": "active",
"VpcSecurityGroupId": "sg-55da224b"
}
],
"DBSubnetGroup": "default",
"StorageEncrypted": false,
"DatabaseName": "sample",
"EngineVersion": "5.6.10a",
"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"
}
]
}
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.
https://rds.us-east-1.amazonaws.com/
?Action=DescribeDBClusters
&MaxRecords=100
&SignatureMethod=HmacSHA256
&SignatureVersion=4
&Version=2014-10-31
&X-Amz-Algorithm=AWS4-HMAC-SHA256
&X-Amz-Credential=AKIADQKE4SARGYLE/20140722/us-east-1/rds/aws4_request
&X-Amz-Date=20140722T200807Z
&X-Amz-SignedHeaders=content-type;host;user-agent;x-amz-content-sha256;x-amz-date
&X-Amz-Signature=2d4f2b9e8abc31122b5546f94c0499bba47de813cb875f9b9c78e8e19c9afe1b
<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>
</DescribeDBClustersResult>
<ResponseMetadata>
<RequestId>d682b02c-1383-11b4-a6bb-172dfac7f170</RequestId>
</ResponseMetadata>
</DescribeDBClustersResponse>
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.
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.
Unidades: bytes
AuroraGlobalDBReplicatedWriteIO Aurora MySQL
Unidades: bytes
AuroraGlobalDBDataTransferBytes Aurora MySQL
Unidades: milisegundos
AuroraGlobalDBReplicationLag Aurora MySQL
ReadThroughputEl número medio de bytes leídos del disco por Aurora PostgreSQL
segundo.
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).
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 el panel de navegación, seleccione Instances (Instancias).
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.
• AuroraBinlogReplicaLag
• DeleteLatency
• DeleteThroughput
• 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:
DDLThroughput DDL
Network throughput
NetworkReceiveThroughput
• 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
Categoría Métricas
SQL ActiveTransactions
Categoría Métricas
BlockedTransactions
BufferCacheHitRatio
CommitLatency
CommitThroughput
DatabaseConnections
DDLLatency
DDLThroughput
Deadlocks
DMLLatency
DMLThroughput
LoginFailures
ResultSetCacheHitRatio
SelectLatency
SelectThroughput
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.
Temas relacionados
• Administración de un clúster de base de datos de Amazon Aurora (p. 232)
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.
• 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.
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.
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:
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.
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).
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.
• 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 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 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.
Métricas de SO disponibles
Las tablas siguientes incluyen las métricas de SO disponibles al usar Amazon CloudWatch Logs.
Métricas de Aurora
version La versión del formato JSON del flujo de la métrica del SO.
loadAverageMinute
fifteen El número de procesos que solicitan tiempo de la CPU en los
últimos 15 minutos.
• Compatibilidad de Amazon Aurora con MySQL versión 2.04.2 y versiones posteriores a 2.x (compatible
con MySQL 5.7)
• 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 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.
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.
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)
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).
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
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. 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
Cifrado de recursos de Amazon Aurora (p. 158).
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.
• 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
Para Windows:
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).
El ejemplo siguiente habilita Performance Insights para sample-db-instance y especifica que los datos
de Performance Insights se conserven durante dos años.
Para Windows:
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.
• ModifyDBInstance
• CreateDBInstanceReadReplica
• RestoreDBInstanceFromS3
• 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
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.
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).
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.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "pi:*",
"Resource": "arn:aws:pi:*:*:metrics/rds/*"
}
]
}
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).
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.
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)
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.
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.
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.
Para obtener más información, consulte Contadores de Performance Insights (p. 433).
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.
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
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.
Puede controlar las ID que muestra la tabla Top Load Items (Principales elementos de carga)
seleccionando el icono Preferences (Preferencias).
Habilite las ID que quiera tener visibles en la tabla Top Load Items (Principales elementos de carga) y
seleccione Save (Guardar).
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.
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.
El límite del texto de SQL depende del motor de la base de datos. Se aplican los siguientes límites:
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.
Las instrucciones SQL con texto superior a 500 bytes son similares a las que se indican en la siguiente
imagen.
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
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.
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.
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).
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.
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.
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 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.
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"
...}
}
Temas
• Recuperación de métricas de contador (p. 422)
• 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)
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.
[
{
"Metric": "sys.cpu.user.avg"
},
{
"Metric": "sys.cpu.system.avg"
}
]
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 file://query.json
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 file://query.json
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.
{
"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
},
{
"Timestamp": 1540857720.0, //Minute2
"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": [
{
"Timestamp": 1540857660.0, //Minute1
"Value": 12.0
},
{
"Timestamp": 1540857720.0, //Minute2
"Value": 13.5
},
//... 60 datapoints for the sys.cpu.system.avg metric
]
}
] //end of MetricList
} //end of response
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.
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 }
}
]
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 file://query.json
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 file://query.json
{
"Identifier": "db-XXX",
"AlignedStartTime": 1540857600.0,
"AlignedEndTime": 1540861200.0,
"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
{
"Timestamp": 1540857660.0, //Minute1
"Value": 0.5166666666666667
},
{
"Timestamp": 1540857720.0, //Minute2
"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
"Metric": "db.load.avg",
"Dimensions": {
"db.wait_event.name": "CPU",
"db.wait_event.type": "CPU"
}
},
"DataPoints": [
{
"Timestamp": 1540857660.0, //Minute1
"Value": 0.35
},
{
"Timestamp": 1540857720.0, //Minute2
"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.
• 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
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.
[
{
"Metric": "db.load.avg",
"GroupBy": { "Group": "db.sql_tokenized", "Limit": 10 }
}
]
aws pi get-resource-metrics \
--service-type RDS \
--identifier db-ID \
--start-time 2018-10-29T00:00:00Z \
--end-time 2018-10-30T00:00:00Z \
--period-in-seconds 3600 \
--metric-queries file://query.json
Para Windows:
aws pi get-resource-metrics ^
--service-type RDS ^
--identifier db-ID ^
--start-time 2018-10-29T00:00:00Z ^
--end-time 2018-10-30T00:00:00Z ^
--period-in-seconds 3600 ^
--metric-queries file://query.json
Este ejemplo consulta durante 24 horas, con un periodo de una hora en segundos.
{
"AlignedStartTime": 1540771200.0,
"AlignedEndTime": 1540857600.0,
"Identifier": "db-XXX",
}
"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"
},
"Metric": "db.load.avg"
},
"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:
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.
[
{
"Metric": "db.load.avg",
"GroupBy": {
"Group": "db.sql_tokenized",
"Dimensions":["db.sql_tokenized.statement"],
"Limit": 10
}
}
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.
[
{
"Metric": "db.load.avg",
"GroupBy": { "Group": "db.wait_event", "Limit": 5 },
"Filter": { "db.sql_tokenized.id": "AKIAIOSFODNN7EXAMPLE" }
}
]
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 file://query.json
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 file://query.json
{
"Identifier": "db-XXX",
"AlignedStartTime": 1556215200.0,
"MetricList": [
{
"Key": {
"Metric": "db.load.avg"
},
"DataPoints": [
{
"Timestamp": 1556218800.0,
"Value": 1.4878117913832196
},
{
"Timestamp": 1556222400.0,
"Value": 1.192823803967328
}
]
},
{
"Key": {
"Metric": "db.load.avg",
"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": {
"Metric": "db.load.avg",
"Dimensions": {
"db.wait_event.type": "io",
"db.wait_event.name": "wait/io/table/sql/handler"
}
},
"DataPoints": [
{
"Timestamp": 1556218800.0,
"Value": 0.16241496598639457
},
{
"Timestamp": 1556222400.0,
"Value": 0.05163360560093349
}
]
},
{
"Key": {
"Metric": "db.load.avg",
"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": {
"Metric": "db.load.avg",
"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": {
"Metric": "db.load.avg",
"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
} //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étrica Descripción
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.
{
"Datapoints": [
{
"Timestamp": "2018-07-19T21:30:00Z",
"Unit": "None",
"Average": 2.1
},
{
"Timestamp": "2018-07-19T21:34:00Z",
"Unit": "None",
"Average": 1.7
},
{
"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.
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)
Contador Tipo
buffers memory
cached memory
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
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
Temas
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.
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_lock_timeouts
Bloqueos El número total de interbloqueos SELECT COUNT AS
que agotaron el tiempo de innodb_lock_timeouts
espera. FROM
INFORMATION_SCHEMA.INNODB_METRICS
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
INFORMATION_SCHEMA.INNODB_METRICS
WHERE
NAME='lock_row_lock_waits'
Temas
• Contadores nativos para Aurora PostgreSQL (p. 438)
• Contadores no nativos para Aurora PostgreSQL (p. 440)
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.
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
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.
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.
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 el panel de navegación, elija Recommendations (Recomendaciones).
• 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.
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).
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).
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.
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.
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
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)
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.
Consola
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.
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.
Para Windows:
Consola
Para obtener el estado de una secuencia de actividades de la base de datos de un clúster 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:
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"
. . .
}
]
}
Consola
Para desactivar una secuencia de actividades de la base de datos
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.
Para Windows:
• 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).
• 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)
Para obtener acceso a una secuencia de actividades de la base de datos desde Kinesis
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?.
Temas
• Ejemplos de registro de auditoría (p. 452)
• Registro de evento de actividad (p. 454)
• Matriz de JSON databaseActivityEventList (p. 454)
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"
}
]
}
{
"type":"DatabaseActivityMonitoringRecord",
"clusterId":"cluster-4HNY5V4RRNPKKYB7ICFKE5JBQQ",
"instanceId":"db-FZJTMYKCXQBUUZ6VLU7NW3ITCM",
"databaseActivityEventList":[
{
"logTime": "2019-05-24 00:36:54.494235+00",
"statementId": 2,
"substatementId": 1,
"objectType": null,
"command": "CREATE TABLE",
"objectName": null,
"databaseName": "postgres",
"dbUserName": "rdsadmin",
"remoteHost": "172.31.3.195",
"remotePort": "34534",
"sessionId": "5ce73c6f.7e64",
"rowCount": null,
"commandText": "create table my_table (id serial primary key, name varchar(32));",
"paramList": [],
"pid": 32356,
"clientApplication": "psql",
"exitCode": null,
"class": "DDL",
"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"
}
]
}
{
"type":"DatabaseActivityMonitoringRecord",
"clusterId":"cluster-4HNY5V4RRNPKKYB7ICFKE5JBQQ",
"instanceId":"db-FZJTMYKCXQBUUZ6VLU7NW3ITCM",
"databaseActivityEventList":[
{
"logTime": "2019-05-24 00:39:49.940668+00",
"statementId": 6,
"substatementId": 1,
"objectType": "TABLE",
"command": "SELECT",
"objectName": "public.my_table",
"databaseName": "postgres",
"dbUserName": "rdsadmin",
"remoteHost": "172.31.3.195",
"remotePort": "34534",
"sessionId": "5ce73c6f.7e64",
"rowCount": 10,
"commandText": "select * from my_table;",
"paramList": [],
"pid": 32356,
"clientApplication": "psql",
"exitCode": null,
"class": "READ",
"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"
}
]
}
cadena
databaseActivityEventList Objeto JSON cifrado como matriz de bytes base64. Siga los pasos
que indicamos a continuación para descifrar este contenido:
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.
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
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.
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
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.
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.
type cadena Tipo de evento. Los valores válidos son record o heartbeat.
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.List;
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;
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;
}
@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());
}
@Override
public void shutdown(IRecordProcessorCheckpointer checkpointer, ShutdownReason
reason) {
if (reason == ShutdownReason.TERMINATE) {
checkpoint(checkpointer);
}
}
// Base64.Decode
final byte[] decoded = Base64.decode(activity.databaseActivityEvents);
final byte[] decodedDataKey = Base64.decode(activity.key);
// 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()));
// GZip Decompress
final byte[] decompressed = decompress(decrypted);
// JSON $ActivityRecords
final ActivityRecords activityRecords = GSON.fromJson(new
String(decompressed, StandardCharsets.UTF_8), ActivityRecords.class);
kinesisClientLibConfiguration.withInitialPositionInStream(InitialPositionInStream.LATEST);
kinesisClientLibConfiguration.withRegionName(REGION_NAME);
final Worker worker = new Builder()
.recordProcessorFactory(new RecordProcessorFactory())
.config(kinesisClientLibConfiguration)
.build();
try {
worker.run();
} catch (Throwable t) {
System.err.println("Caught throwable while processing data.");
t.printStackTrace();
System.exit(1);
}
System.exit(0);
}
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'
cluster_id = "YOUR_CLUSTER_ID"
class MyRawMasterKeyProvider(RawMasterKeyProvider):
provider_id = "BC"
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
)
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'])
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"]
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).
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":"*",
}
]
}
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",
"Effect":"Allow",
"Action":"rds:StartActivityStream",
"Resource":"*"
}
]
}
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":"*"
}
]
}
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":"*"
}
]
}
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":"*"
}
]
}
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.
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.
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.
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.
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.
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 un grupo de seguridad 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 un clúster de base de datos de Aurora.
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.
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.
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 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:
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
Para Linux, OS X o Unix:
Para Windows:
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
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 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.
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.
Example
En el siguiente ejemplo de código se muestra una lista de hasta 100 suscripciones a eventos.
https://rds.us-east-1.amazonaws.com/
?Action=DescribeEventSubscriptions
&MaxRecords=100
&SignatureMethod=HmacSHA256
&SignatureVersion=4
&Version=2014-09-01
&X-Amz-Algorithm=AWS4-HMAC-SHA256
&X-Amz-Credential=AKIADQKE4SARGYLE/20140428/us-east-1/rds/aws4_request
&X-Amz-Date=20140428T161907Z
&X-Amz-SignedHeaders=content-type;host;user-agent;x-amz-content-sha256;x-amz-date
&X-Amz-Signature=4208679fe967783a1a149c826199080a066085d5a88227a80c6c0cadb3e8c0d4
https://rds.us-east-1.amazonaws.com/
?Action=DescribeEventSubscriptions
&SignatureMethod=HmacSHA256
&SignatureVersion=4
&SubscriptionName=myfirsteventsubscription
&Version=2014-09-01
&X-Amz-Algorithm=AWS4-HMAC-SHA256
&X-Amz-Credential=AKIADQKE4SARGYLE/20140428/us-east-1/rds/aws4_request
&X-Amz-Date=20140428T161907Z
&X-Amz-SignedHeaders=content-type;host;user-agent;x-amz-content-sha256;x-amz-date
&X-Amz-Signature=4208679fe967783a1a149c826199080a066085d5a88227a80c6c0cadb3e8c0d4
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 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.
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:
• --subscription-name
Example
El siguiente código activa myeventsubscription.
Para Windows:
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:
• SubscriptionName
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:
• --subscription-name
• --source-identifier
Example
En el siguiente ejemplo se añade el identificador de origen mysqldb a la suscripción
myrdseventsubscription
Para Windows:
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:
• SubscriptionName
• SourceIdentifier
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:
• --subscription-name
• --source-identifier
Example
Para Windows:
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:
• SubscriptionName
• SourceIdentifier
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.
Example
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.
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 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:
• --subscription-name
Example
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:
• SubscriptionName
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.
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 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.
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.
https://rds.us-west-2.amazonaws.com/
?Action=DescribeEvents
&Duration=20160
&MaxRecords=100
&SignatureMethod=HmacSHA256
&SignatureVersion=4
&Version=2014-09-01
&X-Amz-Algorithm=AWS4-HMAC-SHA256
&X-Amz-Credential=AKIADQKE4SARGYLE/20140421/us-west-2/rds/aws4_request
&X-Amz-Date=20140421T194733Z
&X-Amz-SignedHeaders=content-type;host;user-agent;x-amz-content-sha256;x-amz-date
&X-Amz-Signature=8e313cabcdbd9766c56a2886b5b298fd944e0b7cfa248953c82705fdd0374f27
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.
El siguiente ejemplo devuelve una lista de los archivos de registro de una instancia de base de datos
denominada my-db-instance.
Example
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.
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.
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
Para Windows:
API de RDS
Para descargar un archivo de registro de base de datos, use la acción DownloadDBLogFilePortion de
la API de Amazon RDS.
• the section called “Publicación de registros de Aurora MySQL en CloudWatch Logs” (p. 662)
La sintaxis es la siguiente:
La respuesta incluye el contenido del archivo de registro solicitado como una secuencia.
Si especifica una instancia de base de datos no existente, la respuesta consta del error siguiente:
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.
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).
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.
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.
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.
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:
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).
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.
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>:
Para eliminar por completo los datos antiguos y recuperar el espacio del disco, llame al procedimiento
correspondiente dos veces consecutivas.
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 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).
4. En Parameter group actions (Acciones de grupos de parámetros), seleccione Edit (Editar).
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
parámetros de base de datos.
Important
Para ejecutar la utilidad mysqlbinlog en una instancia de Amazon RDS, use las siguientes opciones:
Para obtener más información acerca de las opciones de mysqlbinlog, consulte mysqlbinlog - Utility for
Processing Binary Log Files.
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
call mysql.rds_show_configuration;
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.).
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)
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:
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:
Para obtener más información sobre CloudTrail, consulte la AWS CloudTrail User Guide.
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:
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:
En el ejemplo siguiente, se muestra una entrada de registro de CloudTrail que ilustra la acción
CreateDBInstance.
{
"eventVersion": "1.04",
"userIdentity": {
"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",
"subnetStatus": "Active"
},
{
"subnetAvailabilityZone": {"name": "us-east-1f"},
"subnetIdentifier": "subnet-6746046b",
"subnetStatus": "Active"
},
{
"subnetAvailabilityZone": {"name": "us-east-1c"},
"subnetIdentifier": "subnet-bac383e0",
"subnetStatus": "Active"
},
{
"subnetAvailabilityZone": {"name": "us-east-1d"},
"subnetIdentifier": "subnet-42599426",
"subnetStatus": "Active"
},
{
"subnetAvailabilityZone": {"name": "us-east-1a"},
"subnetIdentifier": "subnet-da327bf6",
"subnetStatus": "Active"
}
],
"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"
}
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)
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)
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:
Puede recuperar el valor actual de las métricas de inserción rápida con el siguiente comando:
+---------------------------------+-----------+
| Variable_name | Value |
+---------------------------------+-----------+
| Aurora_fast_insert_cache_hits | 3598300 |
| Aurora_fast_insert_cache_misses | 436401336 |
+---------------------------------+-----------+
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.
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.
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.
• 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
Aurora MySQL (p. 675).
• 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.
• 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.
• 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 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).
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. 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
Versión de API 2014-10-31
499
Amazon Aurora Guía del usuario de Aurora
Privilegios de la cuenta de usuario
maestro con Aurora MySQL
• 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
rds_kill_query para terminar las consultas o las sesiones de usuario en las instancias de base de
datos Aurora MySQL.
Note
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.
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:
mysql -h myinstance.c9akciq32.rds-us-east-1.amazonaws.com
--ssl-ca=[full path]rds-combined-ca-bundle.pem --ssl-mode=VERIFY_IDENTITY
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.
Note
Para obtener más información acerca de las conexiones SSL con MySQL, consulte la
documentación de MySQL.
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 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.
• 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.
En la siguiente tabla se describen sus opciones y el tipo de migración para cada opció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 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.
Para obtener más información, consulte
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.
Para obtener más información, consulte
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
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.
• 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).
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
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:
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.
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.
"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).
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).
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.
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)
El siguiente comando crea una copia de seguridad de la base de datos MySQL dividido en varios archivos
Gzip.
El siguiente comando crea una copia de seguridad de la base de datos MySQL dividido en varios archivos
tar.
El siguiente comando crea una copia de seguridad de la base de datos MySQL dividido en varios archivos
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.
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.
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.
• 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.
Para restaurar un clúster de base de datos de Amazon Aurora MySQL a partir de los archivos de
un bucket de Amazon S3
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 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).
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 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
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í).
Rol de IAM Esta opción solo está disponible si Create a new role
(Crear nuevo rol) se ha definido en No.
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í).
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.
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.
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).
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
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).
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. 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.
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).
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
bloquea el puerto predeterminado, elija otro puerto para el
nuevo clúster de base de datos.
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.
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)
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).
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).
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.
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).
• 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
• 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.
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).
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.
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-----
AAAAB3NzaC1yc2EAAAADAQABAAABAQClKsfkNkuSevGj3eYhCe53pcjqP3maAhDFcvBS7O6V
hz2ItxCih+PnDSUaw+WNQn/mZphTk/a/gU8jEzoOWbkM4yxyb/wB96xbiFveSFJuOp/d6RJhJOI0iBXr
lsLnBItntckiJ7FbtxJMXLvvwJryDUilBMTjYtwB+QhYXUMOzce5Pjz5/i8SeJtjnV3iAoG/cQk+0FzZ
qaeJAAHco+CY/5WrUBkrHmFJr6HcXkvJdWPkYQS3xqC0+FmUZofz221CBt5IMucxXPkX4rWi+z7wB3Rb
BQoQzd8v7yeb7OzlPnWOyN0qFU0XA246RA8QFYiCNYwI3f05p6KLxEXAMPLE
-----END CERTIFICATE-----\n","ssl_key":"-----BEGIN RSA PRIVATE KEY-----
AAAAB3NzaC1yc2EAAAADAQABAAABAQClKsfkNkuSevGj3eYhCe53pcjqP3maAhDFcvBS7O6V
hz2ItxCih+PnDSUaw+WNQn/mZphTk/a/gU8jEzoOWbkM4yxyb/wB96xbiFveSFJuOp/d6RJhJOI0iBXr
lsLnBItntckiJ7FbtxJMXLvvwJryDUilBMTjYtwB+QhYXUMOzce5Pjz5/i8SeJtjnV3iAoG/cQk+0FzZ
qaeJAAHco+CY/5WrUBkrHmFJr6HcXkvJdWPkYQS3xqC0+FmUZofz221CBt5IMucxXPkX4rWi+z7wB3Rb
BQoQzd8v7yeb7OzlPnWOyN0qFU0XA246RA8QFYiCNYwI3f05p6KLxEXAMPLE
-----END RSA PRIVATE KEY-----\n"}');
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
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
innodb_flush_log_at_trx_commit=1
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
+~-~-~-~-~-~-~-~-~-~-~-~-~-~--+~-~-~-~-~-~--+
| Variable_name | Value |
+~-~-~-~-~-~-~-~-~-~-~-~-~-~--+~-~-~-~-~-~--+
| have_ssl | YES |
+~-~-~-~-~-~-~-~-~-~-~-~-~-~--+~-~-~-~-~-~--+
1 row in set (0.00 sec)
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.
El usuario requiere los privilegios REPLICATION CLIENT y REPLICATION SLAVE. Conceda estos
privilegios al usuario.
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>.
Note
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
);
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.
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;
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.
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).
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:
• 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.
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.
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.
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.
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.
Tablas comprimidas Aurora MySQL no admite tablas comprimidas (es decir, tablas creadas
con ROW_FORMAT=COMPRESSED).
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.
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)
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
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. Inicie la migración de datos desde la instancia de base de datos MySQL a desde la instantánea:
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
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.
Versión de API 2014-10-31
531
Amazon Aurora Guía del usuario de Aurora
Migración desde una instancia de base
de datos MySQL a Aurora MySQL
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:
• --db-cluster-identifier
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).
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.
Para Windows:
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.
Para Windows:
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
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
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.
Para crear una réplica de lectura de Aurora a partir de una instancia de base de datos MySQL
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 el panel de navegación, seleccione Instances (Instancias).
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
clase de instancia de base de datos (p. 61).
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
de varias zonas de disponibilidad, consulte Elección de
Regiones y zonas de disponibilidad (p. 64).
Opción Descripción
identificador se utiliza en la dirección del punto de enlace
de la instancia principal del nuevo clúster de base de
datos.
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).
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. 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
información, consulte Requisitos previos de clúster de base
de datos (p. 86).
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).
Opción Descripción
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. 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
de base de datos. Para obtener más información, consulte
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.
Opción Descripción
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.
Opción Descripción
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)
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).
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).
Para Windows:
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.
• --db-cluster-identifier
El nombre de la clase de instancia de base de datos que se va a utilizar para la instancia principal.
• --db-instance-identifier
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
Para Windows:
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:
• DBClusterIdentifier
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
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
obtener más información sobre los ARN de Amazon RDS, consulte Amazon Relational Database Service
(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
https://rds.us-east-1.amazonaws.com/
?Action=CreateDBCluster
&DBClusterIdentifier=myreadreplicacluster
&DBSubnetGroupName=mysubnetgroup
&Engine=aurora
&ReplicationSourceIdentifier=mysqlmasterARN
&SignatureMethod=HmacSHA256
&SignatureVersion=4
&Version=2014-10-31
&VpcSecurityGroupIds=mysecuritygroup
&X-Amz-Algorithm=AWS4-HMAC-SHA256
&X-Amz-Credential=AKIADQKE4SARGYLE/20150927/us-east-1/rds/aws4_request
&X-Amz-Date=20150927T164851Z
&X-Amz-SignedHeaders=content-type;host;user-agent;x-amz-content-sha256;x-amz-date
&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:
• DBClusterIdentifier
El nombre de la clase de instancia de base de datos que se va a utilizar para la instancia principal.
• DBInstanceIdentifier
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
https://rds.us-east-1.amazonaws.com/
?Action=CreateDBInstance
&DBClusterIdentifier=myreadreplicacluster
&DBInstanceClass=myinstanceclass
&DBInstanceIdentifier=myreadreplicainstance
&Engine=aurora
&SignatureMethod=HmacSHA256
&SignatureVersion=4
&Version=2014-09-01
&X-Amz-Algorithm=AWS4-HMAC-SHA256
&X-Amz-Credential=AKIADQKE4SARGYLE/20140424/us-east-1/rds/aws4_request
&X-Amz-Date=20140424T194844Z
&X-Amz-SignedHeaders=content-type;host;user-agent;x-amz-content-sha256;x-amz-date
&X-Amz-Signature=bee4aabc750bf7dad0cd9e22b952bd6089d91e2a16592c2293e532eeaab8bc77
Para ver la instancia de base de datos MySQL maestra para una réplica de lectura de Aurora
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 el panel de navegación, seleccione Databases (Bases de datos).
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).
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.
Example
Para Windows:
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.
Para promover una réplica de lectura de Aurora a un clúster de base de datos Aurora
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 el panel de navegación, seleccione Instances (Instancias).
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
Para Windows:
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)
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.
db.t2.small 1 1 2
db.t2.medium 2 2 4
db.r3.xlarge 4 13 30.5
db.r3.2xlarge 8 26 61
db.r3.4xlarge 16 52 122
db.r4.large 2 7 15.25
db.r4.2xlarge 8 27 61
db.r4.4xlarge 16 53 122
db.r4.8xlarge 32 99 244
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.
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
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.
• 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
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
• 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.
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).
• 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).
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.
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)
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.
Puede modificar la búsqueda de datos anteriores de un clúster de base de datos utilizando la consola.
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. Seleccione Databases (Bases de datos).
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:
• 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.
8. Elija Modify Cluster (Modificar clúster).
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
• restore-db-cluster-to-point-in-time
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
Para Windows:
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
• RestoreDBClusterFromSnapshot
• RestoreDBClusterToPointInTime
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.
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.
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 el panel de navegación, seleccione Instances (Instancias).
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
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.
--db-cluster-identifier sample-cluster \
--backtrack-to 2018-03-19T10:00:00+00:00
Para Windows:
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.
Consola
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. Seleccione Databases (Bases de datos).
3. Elija el nombre del clúster de búsqueda de datos anteriores para abrir información sobre el mismo.
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.
• 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:
• 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
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
Para Windows:
--db-cluster-identifier sample-cluster
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.
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. 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).
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 Windows:
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.
Consola
Puede deshabilitar la búsqueda de datos anteriores de un clúster de base de datos utilizando la consola.
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. Seleccione Databases (Bases de datos).
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.
6. Para Scheduling of Modifications (Programación de modificaciones), elija una de las siguientes:
• 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.
7. Elija Modify Cluster (Modificar clúster).
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
Para Windows:
API de RDS
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).
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
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é.
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
Opciones
Esta consulta de inserción de errores toma los siguientes parámetros:
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.
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
Opciones
Esta consulta de inserción de errores toma los siguientes parámetros:
• 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.
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
Opciones
Esta consulta de inserción de errores toma los siguientes parámetros:
• 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.
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:
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
Sintaxis
ALTER TABLE tbl_name ADD COLUMN col_name column_definition
Opciones
Esta declaración puede usar las siguientes opciones:
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.
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.
+---------------+-------+
| Disks | 96 |
| Nodes | 74 |
+---------------+-------+
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)
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
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.
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
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
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
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.
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.
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).
• 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.
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.
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:
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.
Para restaurar una instantánea a un clúster de consultas en paralelo con la AWS CLI
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.
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.
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:
Para habilitar o deshabilitar las consultas en paralelo para un clúster de Aurora MySQL con la
Consola de administración de AWS
1. Cree un grupo de parámetros personalizados según se indica 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).
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.
Para habilitar o deshabilitar las consultas en paralelo para una instancia de base de datos con la
CLI
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'}.
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.
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,
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).
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
|
+----+...
+------------------------------------------------------------------------------------------------------
+
| 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.
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 | |
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.
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.
Nombre Descripción
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)
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.
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.
+----+-------------+-------+...+----------
+----------------------------------------------------------------------------+
| 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.
• 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.
• 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.
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;
+----+...+----------
+----------------------------------------------------------------------------+
| id |...| rows | Extra
|
+----+...+----------
+----------------------------------------------------------------------------+
| 1 |...| 20427936 | Using where; Using parallel query (1 columns, 1 filters, 0 exprs; 0
extra) |
+----+...+----------
+----------------------------------------------------------------------------+
mysql> explain select count(*) from part where p_partkey < 10;
+----+...+------+--------------------------+
| id |...| rows | Extra |
+----+...+------+--------------------------+
| 1 |...| 9 | Using where; Using index |
+----+...+------+--------------------------+
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.
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.
| id |...| Extra
|
+----+...
+------------------------------------------------------------------------------------------------------
+
| 1 |...| Using where; Using temporary; Using filesort; Using parallel query (4 columns, 0
filters, 2 exprs; 0 extra) |
+----+...
+------------------------------------------------------------------------------------------------------
+
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
filters, 1 exprs; 0 extra) |
+----+...
+------------------------------------------------------------------------------------------------------
+
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
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_type = 'LARGE BRUSHED BRASS';
+----+...+----------
+----------------------------------------------------------------------------+
| id |...| rows | Extra
|
+----+...+----------
+----------------------------------------------------------------------------+
| 1 |...| 20427936 | Using where; Using parallel query (9 columns, 1 filters, 0 exprs; 0
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
+----+...+----------+-------+---------------+-------------+...+-----------
+------------------------------------------------------------------------------------------------------
+
| 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;
+----+-------------+----------+...+----------
+----------------------------------------------------------------------------+
| id | select_type | table |...| rows | Extra
|
+----+-------------+----------+...+----------
+----------------------------------------------------------------------------+
| 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.
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
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
filters, 1 exprs; 0 extra) |
| 2 | UNION |...| 20427936 | Using where; Using parallel query (2 columns, 0
filters, 1 exprs; 0 extra) |
| NULL | UNION RESULT | <union1,2> |...| NULL | Using temporary
|
+----+--------------+...+----------
+----------------------------------------------------------------------------+
Note
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> explain select count(*) from part_view where p_partkey is not null;
+----+...+----------
+----------------------------------------------------------------------------+
| id |...| rows | Extra
|
+----+...+----------
+----------------------------------------------------------------------------+
| 1 |...| 20427936 | Using where; Using parallel query (1 columns, 0 filters, 0 exprs; 1
extra) |
+----+...+----------
+----------------------------------------------------------------------------+
mysql> explain insert into part_subset select * from part where p_mfgr = 'Manufacturer#1';
+----+...+----------
+----------------------------------------------------------------------------+
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.
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.
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> explain select sql_no_cache count(*) from part_txn where p_retailprice > 10.0;
+----+...+---------
+----------------------------------------------------------------------------+
| id |...| rows | Extra
|
+----+...+---------
+----------------------------------------------------------------------------+
| 1 |...| 2976129 | Using where; Using parallel query (1 columns, 1 filters, 0 exprs; 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)
+----+...+---------+-------------+
| id |...| rows | Extra |
+----+...+---------+-------------+
| 1 |...| 2976129 | Using where |
+----+...+---------+-------------+
mysql> commit;
mysql> explain select sql_no_cache count(*) from part_txn where p_retailprice > 10.0;
+----+...+---------
+----------------------------------------------------------------------------+
| id |...| rows | Extra
|
+----+...+---------
+----------------------------------------------------------------------------+
| 1 |...| 2976129 | Using where; Using parallel query (1 columns, 1 filters, 0 exprs; 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.
+-------------------------------+-------+
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.
Í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.
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
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
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).
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.
• 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
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.
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).
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.
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.
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.
objeto En los eventos QUERY, este valor indica la consulta ejecutada. En los eventos TABLE,
indica el nombre de la tabla.
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)
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 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
• 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).
• 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.
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.
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
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.
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.
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.
• 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
parámetros de clúster de base de datos (p. 259).
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,
a continuación, crea automáticamente una instancia de base de datos que es la instancia principal de ese
clúster de base de datos.
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
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, seleccione la región de AWS
que aloja el clúster de base de datos de origen.
3. En el panel de navegación, seleccione Instances (Instancias).
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.
Opción Descripción
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.
DB instance class Elija una clase de instancia de base de datos que defina
los requisitos de procesamiento y memoria para la
Opción Descripción
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
clase de instancia de base de datos (p. 61).
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
de varias zonas de disponibilidad, consulte Elección de
Regiones y zonas de disponibilidad (p. 64).
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.
Opción Descripción
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 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.
Opción Descripción
Auto minor version upgrade Esta configuración no se aplica a los clústeres de base de
(Actualización automática de versiones datos Aurora MySQL.
secundarias)
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).
6. Elija Create (Crear) para crear una réplica de lectura entre regiones de Aurora.
AWS CLI
Para crear un clúster de base de datos Aurora MySQL que sea una réplica de lectura entre
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.
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.
Para Windows:
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 cifrado de la región us-west-2. Se llama al comando en la región
us-east-1.
Para Windows:
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.
Para Windows:
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
Para crear un clúster de base de datos Aurora MySQL que sea una réplica de lectura entre
regiones con la API
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.
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 a la acción en la
región us-east-1.
https://rds.us-east-1.amazonaws.com/
?Action=CreateDBCluster
&ReplicationSourceIdentifier=arn:aws:rds:us-west-2:123456789012:cluster:sample-
master-cluster
&DBClusterIdentifier=sample-replica-cluster
&Engine=aurora
&SignatureMethod=HmacSHA256
&SignatureVersion=4
&Version=2014-10-31
&X-Amz-Algorithm=AWS4-HMAC-SHA256
&X-Amz-Credential=AKIADQKE4SARGYLE/20161117/us-east-1/rds/aws4_request
&X-Amz-Date=20160201T001547Z
&X-Amz-SignedHeaders=content-type;host;user-agent;x-amz-content-sha256;x-amz-date
&X-Amz-Signature=a04c831a0b54b5e4cd236a90dcb9f5fab7185eb3b72b5ebe9a70a4e95790c8b7
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 cifrado de la región us-west-2. Se llama a la acción en la región
us-east-1.
https://rds.us-east-1.amazonaws.com/
?Action=CreateDBCluster
&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
&DBClusterIdentifier=sample-replica-cluster
&Engine=aurora
&SignatureMethod=HmacSHA256
&SignatureVersion=4
&Version=2014-10-31
&X-Amz-Algorithm=AWS4-HMAC-SHA256
&X-Amz-Credential=AKIADQKE4SARGYLE/20161117/us-east-1/rds/aws4_request
&X-Amz-Date=20160201T001547Z
&X-Amz-SignedHeaders=content-type;host;user-agent;x-amz-content-sha256;x-amz-date
&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.
https://rds.us-east-1.amazonaws.com/
?Action=DescribeDBClusters
&DBClusterIdentifier=sample-replica-cluster
&SignatureMethod=HmacSHA256
&SignatureVersion=4
&Version=2014-10-31
&X-Amz-Algorithm=AWS4-HMAC-SHA256
&X-Amz-Credential=AKIADQKE4SARGYLE/20161117/us-east-1/rds/aws4_request
&X-Amz-Date=20160201T002223Z
&X-Amz-SignedHeaders=content-type;host;user-agent;x-amz-content-sha256;x-amz-date
&X-Amz-Signature=84c2e4f8fba7c577ac5d820711e34c6e45ffcd35be8a6b7c50f329a74f35f426
https://rds.us-east-1.amazonaws.com/
?Action=CreateDBInstance
&DBClusterIdentifier=sample-replica-cluster
&DBInstanceClass=db.r3.large
&DBInstanceIdentifier=sample-replica-instance
&Engine=aurora
&SignatureMethod=HmacSHA256
&SignatureVersion=4
&Version=2014-10-31
&X-Amz-Algorithm=AWS4-HMAC-SHA256
&X-Amz-Credential=AKIADQKE4SARGYLE/20161117/us-east-1/rds/aws4_request
&X-Amz-Date=20160201T003808Z
&X-Amz-SignedHeaders=content-type;host;user-agent;x-amz-content-sha256;x-amz-date
&X-Amz-Signature=125fe575959f5bbcebd53f2365f907179757a08b5d7a16a378dfa59387f58cdb
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:
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:
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
Consola
Para promover una réplica de lectura de Aurora MySQL a un clúster de base de datos
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 consola de Amazon RDS, elija Instances (Instancias).
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.
Versión de API 2014-10-31
609
Amazon Aurora Guía del usuario de Aurora
Replicación entre Aurora y MySQL o entre
Aurora y otro clúster de base de datos Aurora
Example
Para Windows:
API de RDS
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.
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.
La configuración de la replicación de MySQL con Aurora MySQL incluye los siguientes pasos, que se
describen en detalle en este tema:
2. Conserve los registros binarios en el maestro de replicación hasta que dejen de ser
necesarios (p. 615)
Motor de Instrucciones
base de
datos
Aurora Para habilitar el registro binario en un clúster de base de datos Aurora MySQL
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 parámetros de clúster de base de datos (p. 259).
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.
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
• 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.
Motor de Instrucciones
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.
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-----
AAAAB3NzaC1yc2EAAAADAQABAAABAQClKsfkNkuSevGj3eYhCe53pcjqP3maAhDFcvBS7O6V
hz2ItxCih+PnDSUaw+WNQn/mZphTk/a/gU8jEzoOWbkM4yxyb/wB96xbiFveSFJuOp/
d6RJhJOI0iBXr
lsLnBItntckiJ7FbtxJMXLvvwJryDUilBMTjYtwB+QhYXUMOzce5Pjz5/i8SeJtjnV3iAoG/
cQk+0FzZ
qaeJAAHco+CY/5WrUBkrHmFJr6HcXkvJdWPkYQS3xqC0+FmUZofz221CBt5IMucxXPkX4rWi
+z7wB3Rb
BQoQzd8v7yeb7OzlPnWOyN0qFU0XA246RA8QFYiCNYwI3f05p6KLxEXAMPLE
-----END CERTIFICATE-----\n","ssl_key":"-----BEGIN RSA PRIVATE KEY-----
AAAAB3NzaC1yc2EAAAADAQABAAABAQClKsfkNkuSevGj3eYhCe53pcjqP3maAhDFcvBS7O6V
Motor de Instrucciones
base de
datos
hz2ItxCih+PnDSUaw+WNQn/mZphTk/a/gU8jEzoOWbkM4yxyb/wB96xbiFveSFJuOp/
d6RJhJOI0iBXr
lsLnBItntckiJ7FbtxJMXLvvwJryDUilBMTjYtwB+QhYXUMOzce5Pjz5/i8SeJtjnV3iAoG/
cQk+0FzZ
qaeJAAHco+CY/5WrUBkrHmFJr6HcXkvJdWPkYQS3xqC0+FmUZofz221CBt5IMucxXPkX4rWi
+z7wB3Rb
BQoQzd8v7yeb7OzlPnWOyN0qFU0XA246RA8QFYiCNYwI3f05p6KLxEXAMPLE
-----END RSA PRIVATE KEY-----\n"}');
sudo vi /etc/my.cnf
log-bin=mysql-bin
server-id=2133421
innodb_flush_log_at_trx_commit=1
sync_binlog=1
Las entradas del archivo /etc/my.cnf incluyen las ubicaciones del archivo .pem para el
servidor de base de datos MySQL.
Motor de Instrucciones
base de
datos
log-bin=mysql-bin
server-id=2133421
innodb_flush_log_at_trx_commit=1
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
Mientras está conectado a la base de datos MySQL externa, registre la posición del log
binario de la base de datos MySQL externa.
+------------------+----------+--------------+------------------
+-------------------+
| 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.
Puede encontrar instrucciones acerca del procedimiento para conservar logs binario para el motor de base
de datos a continuación.
Motor de Instrucciones
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.
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.
Motor de Instrucciones
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.
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.
Motor de Instrucciones
base de
datos
Aurora Para crear una instantánea de un clúster de base de datos Aurora MySQL
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.
Motor de Instrucciones
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"
}
]
}
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
base de datos (p. 317).
5. Elimine la réplica de lectura.
Motor de Instrucciones
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:
3. Una vez que haya creado el snapshot, desbloquee las tablas de su base de datos de
MySQL con el siguiente comando:
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.
Motor de Instrucciones
base de
datos
Aurora Para cargar una instantánea en un clúster de base de datos Aurora MySQL
Motor de Instrucciones
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.
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:
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
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 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.
Además, cree un ID de usuario que solo se utilice para la replicación. A continuación se muestra un
ejemplo.
El usuario requiere los privilegios REPLICATION CLIENT y REPLICATION SLAVE. Conceda estos
privilegios al usuario.
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.
Note
Puede encontrar instrucciones acerca del procedimiento para habilitar la replicación para su motor de base
de datos a continuación.
Motor de Instrucciones
base de
datos
Aurora Para habilitar la replicación desde un clúster de base de datos Aurora MySQL
Motor de Instrucciones
base de
datos
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.
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_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;
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.
Motor de Instrucciones
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
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.
Motor de Instrucciones
base de
datos
Aurora Para deshabilitar el registro binario en un clúster de base de datos Amazon Aurora
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:
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.
sudo vi /etc/my.cnf
Motor de Instrucciones
base de
datos
Para obtener más información, consulte Setting the Replication Master Configuration en
la documentación de MySQL.
3. Inicie el servicio mysql.
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)
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
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:
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.
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.
enforce_gtid_consistency
OFF, ON, WARN OFF permite que las transacciones infrinjan la
uniformidad de GTID.
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:
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.
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).
Note
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
parámetros de clúster de base de datos (p. 259).
Note
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:
CALL mysql.rds_set_master_auto_position(0);
File Position
------------------------------------
mysql-bin-changelog.000031 107
------------------------------------
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
b. Reinicie el clúster de base de datos de Aurora MySQL.
• Invoque de forma síncrona o asíncrona una función de AWS Lambda mediante las funciones nativas
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
un bucket de Amazon S3 (p. 649).
• 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).
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).
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).
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:
• 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. 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
un bucket de Amazon S3 (p. 649).
• 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).
• 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).
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).
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.
Versión de API 2014-10-31
630
Amazon Aurora Guía del usuario de Aurora
Autorización a Aurora MySQL a obtener
acceso a otros servicios de AWS
GetObjectVersion
GetObjectVersion
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
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.
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.
13. Elija Create Policy.
14. 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).
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>"
}
]
}
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 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
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.
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.
11. Elija Create Policy.
12. 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).
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",
"logs:DescribeLogStreams",
"logs:GetLogEvents"
],
"Resource": [
"arn:aws:logs:*:*:log-group:/aws/rds/*:log-stream:*"
]
}
]
}
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 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
• 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:
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>"
}
]
}
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 las claves de KMS en su nombre.
Para crear una política de IAM para conceder acceso a sus claves de KMS
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.
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
• 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
Amazon Aurora MySQL (p. 636).
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.
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.
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.
Para asociar un rol de IAM a un clúster de base de datos Aurora con la consola
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.
11. Elija Save changes.
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:
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).
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.
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.
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.
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.
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
Aurora MySQL (p. 678).
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 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
• Integración de Aurora con otros servicios de AWS (p. 297)
• Administración de un clúster de base de datos de Amazon Aurora (p. 232)
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.
Para obtener instrucciones, consulte Creación de una política de IAM para acceder a los recursos de
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.
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.
s3-region://bucket-name/file-name-or-prefix
• 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).
Sintaxis
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.
• 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.
• 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.
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.
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.
{
"$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
},
{
"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.
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.
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.
Campo Descripción
Campo Descripción
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.
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.
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.
• Con los nombres de las columnas como atributos de un elemento <row>. El valor del atributo identifica
el contenido del campo de la tabla.
• 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,...)]
[CHARACTER SET charset_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
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.
• 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.
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)
• Administración de un clúster de base de datos de Amazon Aurora (p. 232)
• Migración de datos a un clúster de base de datos Amazon Aurora (p. 154)
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.
Para obtener instrucciones, consulte Creación de una política de IAM para acceder a los recursos de
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_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.
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.
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
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.
s3-region://bucket-name/file-prefix
• 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
• s3-us-west-2://bucket/prefix.part_00001
• s3-us-west-2://bucket/prefix.part_00002
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": [
{
"url":"s3-us-west-2://bucket/prefix.part_00000"
},
{
"url":"s3-us-west-2://bucket/prefix.part_00001"
},
{
"url":"s3-us-west-2://bucket/prefix.part_00002"
}
]
}
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'
[CHARACTER SET charset_name]
[export_options]
[MANIFEST {ON | OFF}]
[OVERWRITE {ON | OFF}]
export_options:
[{FIELDS | COLUMNS}
[TERMINATED BY 'string']
[[OPTIONALLY] ENCLOSED BY 'char']
[ESCAPED BY 'char']
]
[LINES
[STARTING BY 'string']
[TERMINATED 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).
• 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).
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
la documentación de MySQL.
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.
• 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.
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.
La instrucción siguiente selecciona todos los datos de la tabla employees y los guarda en un bucket de
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.
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. 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.
La instrucción siguiente selecciona todos los datos de la tabla employees y los guarda en un bucket de
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.
Temas relacionados
• Integración de Aurora con otros servicios de AWS (p. 297)
• 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)
• Administración de un clúster de base de datos de Amazon Aurora (p. 232)
• Migración de datos a un clúster de base de datos Amazon Aurora (p. 154)
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)
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
obtener instrucciones, consulte Creación de una política de IAM para acceder a los recursos de AWS
Lambda (p. 632).
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 AWS Lambda (p. 632) 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 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.
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 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
Aurora MySQL con otros servicios de AWS (p. 640).
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.
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.
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.
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
lambda_function_ARN
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.
SELECT lambda_sync(
'arn:aws:lambda:us-east-1:868710585169:function:BasicTestLambda',
'{"operation": "ping"}');
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 (
lambda_function_ARN,
JSON_payload
)
lambda_function_ARN
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.
SELECT lambda_async(
'arn:aws:lambda:us-east-1:868710585169:function:BasicTestLambda',
'{"operation": "ping"}');
Temas relacionados
• Integración de Aurora con otros servicios de AWS (p. 297)
• Administración de un clúster de base de datos de Amazon Aurora (p. 232)
• Guía para desarrolladores de AWS Lambda
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.
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.
Sintaxis
CALL mysql.lambda_async (
lambda_function_ARN,
lambda_function_input
)
Parámetros
lambda_function_ARN
Ejemplos
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
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.
import boto3
ses = boto3.client('ses')
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
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.
import boto3
sns = boto3.client('sns')
return sns.publish(
TopicArn='arn:aws:sns:us-west-2:123456789012:Sample_Topic',
Message=event['message'],
Subject=event['subject'],
MessageStructure='string'
)
Procedimiento almacenado
Tabla
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 ;
Temas relacionados
• Integración de Aurora con otros servicios de AWS (p. 297)
• Administración de un clúster de base de datos de Amazon Aurora (p. 232)
• Guía para desarrolladores de AWS Lambda
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
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
Amazon Aurora (p. 207).
• 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
Consola
Puede publicar registros de Aurora MySQL para clústeres aprovisionados en CloudWatch Logs con la
consola.
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:
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
• restore-db-cluster-to-point-in-time
Ejecute uno de estos comandos de la AWS CLI con las siguientes opciones:
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.
Para Windows:
Example
El siguiente comando crea un clúster de base de datos Aurora MySQL para publicar archivos de registro
en CloudWatch Logs.
Para Windows:
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:
También puede publicar logs de Aurora MySQL con la API de RDS ejecutando una de las siguientes
acciones de API de RDS:
• CreateDBCluster
• RestoreDBClusterFromS3
• RestoreDBClusterFromSnapshot
• RestoreDBClusterToPointInTime
Podrían ser necesarios otros parámetros en función del comando de la AWS CLI que ejecute.
/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.
Característica Descripción
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)
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.
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.
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.
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).
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
Aurora MySQL (p. 695).
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.
• 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.
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.
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.
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.
-> 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.
Para obtener más información acerca del uso de la replicación en Amazon Aurora, consulte Replicación
con Amazon Aurora (p. 48).
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
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.
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 \
--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:
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.
Versión de API 2014-10-31
673
Amazon Aurora Guía del usuario de Aurora
Uso de Amazon Aurora para la recuperación de
desastres con sus bases de datos de MySQL
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
continuación se muestra un ejemplo.
CALL mysql.rds_start_replication;
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).
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).
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.
Para obtener más información acerca del uso de transacciones de XA con MySQL, consulte XA
Transactions en la documentación de 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.
• 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
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.
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).
• 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).
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.
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:
Temas relacionados
• Administración de un clúster de base de datos de Amazon Aurora (p. 232)
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)
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)
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.
auto_increment_increment Sí
auto_increment_offset Sí
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í
innodb_autoinc_lock_mode Sí
innodb_checksums No
innodb_cmp_per_index_enabled Sí
innodb_commit_concurrency Sí
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_logs Sí
innodb_undo_tablespaces No
lc_time_names Sí
lower_case_table_names Sí
master-info-repository Sí
master_verify_checksum Sí
server_audit_events Sí
server_audit_excl_users Sí
server_audit_incl_users Sí
server_id No
skip-character-set-client- Sí
handshake
skip_name_resolve No
sync_frm Sí
time_zone Sí
allow-suspicious-udfs No
autocommit Sí
automatic_sp_privileges Sí
back_log Sí
binlog_cache_size Sí
binlog_max_flush_queue_time Sí
binlog_order_commits Sí
binlog_stmt_cache_size Sí
bulk_insert_buffer_size Sí
concurrent_insert Sí
connect_timeout Sí
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í
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í
group_concat_max_len Sí
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í
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í
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_replication_delay Sí
innodb_sort_buffer_size Sí
innodb_stats_auto_recalc Sí
innodb_stats_method Sí
innodb_stats_on_metadata Sí
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í
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í
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
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_rnd_buffer_size Sí
relay-log No
relay_log_info_repository Sí
relay_log_recovery No
safe-user-create Sí
secure_auth Sí
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í
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í
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í
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í
• innodb_adaptive_flushing
• 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
• innodb_buffer_pool_bytes_dirty
• innodb_buffer_pool_pages_dirty
• innodb_buffer_pool_pages_flushed
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, 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
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
documentación de MySQL.
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
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, 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
documentación de MySQL.
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
documentación de MySQL.
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.
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
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.
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.
replication_user_name
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.
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.
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.
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
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
Parámetros
gtid_to_skip
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.
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.
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.
select AURORA_VERSION();
select @@aurora_version;
<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.
• 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)
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.
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.
• 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.
Note
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)
• 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 (29/05/2019) (versión 2.04.4) (p. 701)
• Actualizaciones del motor de base de datos de Aurora MySQL (09/05/2019) (versión 2.04.3) (p. 703)
• Actualizaciones del motor de base de datos de Aurora MySQL (02/05/2019) (versión 2.04.2) (p. 704)
• Actualizaciones del motor de base de datos de Aurora MySQL (25/03/2019) (versión 2.04.1) (p. 706)
• 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 (18/01/2019) (p. 708) (versión 2.03.3)
• Actualizaciones del motor de base de datos de Aurora MySQL (09/01/2019) (p. 709) (versión 2.03.2)
• Actualizaciones del motor de base de datos de Aurora MySQL (24/10/2018) (p. 710) (versión 2.03.1)
• 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/10/2018) (p. 711) (versión 2.02.5)
• Actualizaciones del motor de base de datos de Aurora MySQL (21/09/2018) (p. 712) (versión 2.02.4)
• Actualizaciones del motor de base de datos de Aurora MySQL (23/08/2018) (p. 712) (versión 2.02.3)
• Actualizaciones del motor de base de datos de Aurora MySQL (04/06/2018) (p. 714) (versión 2.02.2)
• Actualizaciones del motor de base de datos de Aurora MySQL (03/05/2018) (p. 716) (versión 2.02)
• Actualizaciones del motor de base de datos de Aurora MySQL (13/03/2018) (p. 718) (versión 2.01.1)
• Actualizaciones del motor de base de datos de Aurora MySQL (06/02/2018) (p. 720) (versión 2.01)
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.
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
datos de Amazon Aurora (p. 340).
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
provocaba que la base de datos se reiniciara.
• 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
provocaba que la base de datos se reiniciara.
• Se ha solucionado un problema que provocaba anulaciones de conexiones cuando se gestionaba un
error en la administración de protocolos de red.
• 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
Aurora MySQL (p. 675).
• 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).
• 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).
Aurora MySQL 2.04.5 no admite actualmente las siguientes características de MySQL 5.7:
Aurora MySQL 2.04.4 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.
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.
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
datos de Amazon Aurora (p. 340).
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
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 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 provocaba anulaciones de conexiones cuando se gestionaba un
error en la administración de protocolos de red.
• 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.
• 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
Aurora MySQL (p. 675).
• 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).
• 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).
Aurora MySQL 2.04.4 no admite actualmente las siguientes características de MySQL 5.7:
• Filtrado de replicación
• La instrucción SQL CREATE TABLESPACE
Aurora MySQL 2.04.3 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.
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.3. 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.3.
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
datos de Amazon Aurora (p. 340).
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
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
• 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.
• 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
Aurora MySQL (p. 675).
• 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).
• 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).
Aurora MySQL 2.04.3 no admite actualmente las siguientes características de MySQL 5.7:
Aurora MySQL 2.04.2 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.
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.2. 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.*, 2.04.0 y 2.04.1 en Aurora MySQL 2.04.2.
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
datos de Amazon Aurora (p. 340).
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
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
• 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.
• 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
Aurora MySQL (p. 675).
• 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).
• 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).
Aurora MySQL 2.04.2 no admite actualmente las siguientes características de MySQL 5.7:
Aurora MySQL 2.04.1 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.
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.1. 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.0 en Aurora MySQL 2.04.1.
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
datos de Amazon Aurora (p. 340).
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.
Aurora MySQL 2.04 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.
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
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.
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
datos de Amazon Aurora (p. 340).
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
• 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.
Aurora MySQL 2.03.4 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.
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.*.
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
datos de Amazon Aurora (p. 340).
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.
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
• 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.
Aurora MySQL 2.03.3 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.
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.3 ni la
restauración a Aurora MySQL 2.03.3 desde una copia de seguridad de Amazon S3. Tenemos previsto
quitar estas restricciones en una versión posterior de Aurora MySQL 2.*.
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
datos de Amazon Aurora (p. 340).
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.
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 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.
• 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.
Aurora MySQL 2.03.2 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.
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.2 ni la
restauración a Aurora MySQL 2.03.2 desde una copia de seguridad de Amazon S3. Tenemos previsto
quitar estas restricciones en una versión posterior de Aurora MySQL 2.*.
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
datos de Amazon Aurora (p. 340).
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.
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
• 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).
Aurora MySQL 2.03.1 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.
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.
No permitimos la actualización in situ de los clústeres de Aurora MySQL 1.* a Aurora MySQL 2.03.1 ni la
restauración a Aurora MySQL 2.03.1 desde una copia de seguridad de Amazon S3. Tenemos previsto
quitar estas restricciones en una versión posterior de Aurora MySQL 2.*.
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
datos de Amazon Aurora (p. 340).
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.
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.
Aurora MySQL 2.03 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.
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.* 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.*.
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.
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
datos de Amazon Aurora (p. 340).
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.
Aurora MySQL 2.02.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.
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.* y 2.02.* en
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.
No permitimos la actualización in situ de los clústeres de Aurora MySQL 1.* a Aurora MySQL 2.02.5 ni la
restauración a Aurora MySQL 2.02.5 desde una copia de seguridad de Amazon S3. Tenemos previsto
quitar estas restricciones en una versión posterior de Aurora MySQL 2.*.
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.
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.
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
datos de Amazon Aurora (p. 340).
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.
Aurora MySQL 2.02.4 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.
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.* y 2.02.* en
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.
No permitimos la actualización in situ de los clústeres de Aurora MySQL 1.* a Aurora MySQL 2.02.4 ni la
restauración a Aurora MySQL 2.02.4 desde una copia de seguridad de Amazon S3. Tenemos previsto
quitar estas restricciones en una versión posterior de Aurora MySQL 2.*.
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.
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
datos de Amazon Aurora (p. 340).
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.
Aurora MySQL 2.02.3 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.
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.*, 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.
No permitimos la actualización in situ de los clústeres de Aurora MySQL 1.* a Aurora MySQL 2.02.3 ni la
restauración a Aurora MySQL 2.02.3 desde una copia de seguridad de Amazon S3. Tenemos previsto
quitar estas restricciones en una versión posterior de Aurora MySQL 2.*.
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.
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.
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
datos de Amazon Aurora (p. 340).
• 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
Aurora MySQL (p. 675).
• 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).
• 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 2.01 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).
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.
• 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
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.
Aurora MySQL 2.02.2 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.
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*, 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.
No permitimos la actualización in situ de los clústeres de Aurora MySQL 1.* a Aurora MySQL 2.02.2 ni la
restauración a Aurora MySQL 2.02.2 desde una copia de seguridad de Amazon S3. Tenemos previsto
quitar estas restricciones en una versión posterior de Aurora MySQL 2.*.
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.
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.
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
datos de Amazon Aurora (p. 340).
• 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
Aurora MySQL (p. 675).
• 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).
• 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 2.01 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).
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.
• 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
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.
Aurora MySQL 2.02 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.
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* 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
restauración a Aurora MySQL 2.02 desde una copia de seguridad de Amazon S3. Tenemos previsto quitar
estas restricciones en una versión posterior de Aurora MySQL 2.x.
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.
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
datos de Amazon Aurora (p. 340).
• 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
Aurora MySQL (p. 675).
• 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).
• 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 2.01 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).
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.
• 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
• Filtrado de replicación
• La instrucción SQL CREATE TABLESPACE
• Protocolo X
• 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.
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.
Aurora MySQL 2.01.1 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.
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* 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.
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.
• 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
Aurora MySQL (p. 675).
• 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).
• 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 2.01.1 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).
Aurora MySQL 2.01.1 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.
• 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
• Filtrado de replicación
• La instrucción SQL CREATE TABLESPACE
• Protocolo X
• 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.
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.
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
restauración a Aurora MySQL 2.01 desde una copia de seguridad de Amazon S3. Tenemos previsto quitar
estas restricciones en una versión posterior de Aurora MySQL 2.x.
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.
• 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
Aurora MySQL (p. 675).
• 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).
• 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 2.01 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).
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.
• 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
• Filtrado de replicación
• La instrucción SQL CREATE TABLESPACE
• Protocolo X
• Actualizaciones del motor de base de datos de Aurora MySQL (05/06/2019) (p. 722) (versión 1.19.2)
• Actualizaciones del motor de base de datos de Aurora MySQL (09/05/2019) (p. 723) (versión 1.19.1)
• Actualizaciones del motor de base de datos de Aurora MySQL (07/02/2019) (p. 724) (versión 1.19.0)
• Actualizaciones del motor de base de datos de Aurora MySQL (20/09/2018) (p. 725) (versión 1.18.0)
• Actualizaciones del motor de base de datos de Aurora MySQL (17/01/2019) (p. 726) (versión 1.17.8)
• Actualizaciones del motor de base de datos de Aurora MySQL (08/10/2018) (p. 727) (versión 1.17.7)
• Actualizaciones del motor de base de datos de Aurora MySQL (06/09/2018) (p. 728) (versión 1.17.6)
• Actualizaciones del motor de base de datos de Aurora MySQL (14/08/2018) (p. 729) (versión 1.17.5)
• Actualizaciones del motor de base de datos de Aurora MySQL (07/08/2018) (p. 729) (versión 1.17.4)
• Actualizaciones del motor de base de datos de Aurora MySQL (05/06/2018) (p. 730) (versión 1.17.3)
• Actualizaciones del motor de base de datos de Aurora MySQL (27/04/2018) (p. 731) (versión 1.17.2)
• Actualizaciones del motor de base de datos de Aurora MySQL (23/03/2018) (p. 731) (versión 1.17.1)
• Actualizaciones del motor de base de datos de Aurora MySQL (13/03/2018) (p. 732) (versión 1.17)
• Actualizaciones del motor de base de datos de Aurora MySQL (11/12/2017) (p. 733) (versión 1.16)
• Actualizaciones del motor de base de datos de Aurora MySQL (20/11/2017) (p. 734) (versión 1.15.1)
• Actualizaciones del motor de base de datos de Aurora MySQL (24/10/2017) (p. 735) (versión 1.15)
• 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: 22/09/2017 (p. 738) (versión 1.14.1)
• 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: 15/05/2017 (p. 740) (versión 1.13)
• Actualizaciones del motor de base de datos de Aurora MySQL: 05/04/2017 (p. 742) (versión 1.12)
• Actualizaciones del motor de base de datos de Aurora MySQL: 23/02/2017 (p. 743) (versión 1.11)
• Actualizaciones del motor de base de datos de Aurora MySQL: 12/01/2017 (p. 745) (versión 1.10.1)
• Actualizaciones del motor de base de datos de Aurora MySQL: 14/12/2016 (p. 746) (versión 1.10)
• 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: 26/10/2016 (p. 749) (versión 1.8.1)
• Actualizaciones del motor de base de datos de Aurora MySQL: 18/10/2016 (p. 749) (versión 1.8)
• Actualizaciones del motor de base de datos de Aurora MySQL: 20/09/2016 (p. 750) (versión 1.7.1)
• Actualizaciones del motor de base de datos de Aurora MySQL: 30/08/2016 (p. 751) (versión 1.7)
• Actualizaciones del motor de base de datos de Aurora MySQL: 01/06/2016 (p. 752) (versión 1.6.5)
• Actualizaciones del motor de base de datos de Aurora MySQL: 06/04/2016 (p. 752) (versión 1.6)
• Actualizaciones del motor de base de datos de Aurora MySQL: 11/01/2016 (p. 754) (versión 1.5)
• Actualizaciones del motor de base de datos de Aurora MySQL: 03/12/2015 (p. 755) (versión 1.4)
• Actualizaciones del motor de base de datos de Aurora MySQL: 16/10/2015 (p. 756) (versiones 1.2, 1.3)
• Actualizaciones del motor de base de datos de Aurora MySQL: 24/08/2015 (p. 759) (versión 1.1)
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.
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
datos de Amazon Aurora (p. 340).
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
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
• 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 provocaba anulaciones de conexiones cuando se gestionaba un
error en la administración de protocolos de red.
• 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.
Aurora MySQL 1.19.1 ya está disponible con carácter general. Todos los clústeres de base de datos
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.
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
datos de Amazon Aurora (p. 340).
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.
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
• 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.
Aurora MySQL 1.19.0 ya está disponible con carácter general. Todos los clústeres de base de datos
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.
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
datos de Amazon Aurora (p. 340).
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.
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).
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.
• 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.
Aurora MySQL 1.18.0 ya está disponible con carácter general. Todos los clústeres de base de datos
Aurora MySQL nuevos compatibles con MySQL 5.6, incluidos los que se hayan restablecido a partir de
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.
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
datos de Amazon Aurora (p. 340).
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).
Aurora MySQL 1.17.8 ya está disponible con carácter general. Todos los clústeres de base de datos
Aurora MySQL nuevos compatibles con MySQL 5.6, incluidos los que se hayan restablecido a partir de
instantáneas, se crearán en Aurora MySQL 1.17.8. Tiene la opción, aunque no es obligatorio, de actualizar
clústeres de base de datos existentes a Aurora MySQL 1.17.8. Para usar una versión anterior, puede crear
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.
Con la versión 1.17.8 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.
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.
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
datos de Amazon Aurora (p. 340).
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.
Aurora MySQL 1.17.7 ya está disponible con carácter general. Todos los clústeres de base de datos
Aurora MySQL nuevos compatibles con MySQL 5.6, incluidos los que se hayan restablecido a partir de
instantáneas, se crearán en Aurora MySQL 1.17.7. Tiene la opción, aunque no es obligatorio, de actualizar
clústeres de base de datos existentes a Aurora MySQL 1.17.7. Para usar una versión anterior, puede crear
nuevos clústeres de base de datos en Aurora MySQL 1.14.4, 1.15.1, 1.16 o 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.17.7 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.
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.
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
datos de Amazon Aurora (p. 340).
Mejoras
• La variable de estado InnoDB innodb_buffer_pool_size ya es visible públicamente para que los
clientes puedan modificarla.
• 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.
Aurora MySQL 1.17.6 ya está disponible con carácter general. Todos los clústeres de base de datos
Aurora MySQL nuevos compatibles con MySQL 5.6, incluidos los que se hayan restablecido a partir de
instantáneas, se crearán en Aurora MySQL 1.17.6. Tiene la opción, aunque no es obligatorio, de actualizar
clústeres de base de datos existentes a Aurora MySQL 1.17.6. Para usar una versión anterior, puede crear
nuevos clústeres de base de datos en Aurora MySQL 1.14.4, 1.15.1, 1.16 o 1.17.5. 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.17.6 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.
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.
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
datos de Amazon Aurora (p. 340).
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.
Aurora MySQL 1.17.5 ya está disponible con carácter general. Todos los clústeres de base de datos
Aurora MySQL nuevos compatibles con MySQL 5.6, incluidos los que se hayan restablecido a partir de
instantáneas, se crearán en Aurora MySQL 1.17.5. Tiene la opción, aunque no es obligatorio, de actualizar
clústeres de base de datos existentes a Aurora MySQL 1.17.5. Para usar una versión anterior, puede crear
nuevos clústeres de base de datos en Aurora MySQL 1.14.4, 1.15.1, 1.16 o 1.17.4. 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.17.5 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.
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.
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
datos de Amazon Aurora (p. 340).
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.
Aurora MySQL 1.17.4 ya está disponible con carácter general. Todos los clústeres de base de datos
Aurora MySQL nuevos compatibles con MySQL 5.6, incluidos los que se hayan restablecido a partir de
instantáneas, se crearán en Aurora MySQL 1.17.4. Tiene la opción, aunque no es obligatorio, de actualizar
clústeres de base de datos existentes a Aurora MySQL 1.17.4. Para usar una versión anterior, puede crear
nuevos clústeres de base de datos en Aurora MySQL 1.14.4, 1.15.1, 1.16 o 1.17.3. 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.17.4 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.
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.
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
datos de Amazon Aurora (p. 340).
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.
Aurora MySQL 1.17.3 ya está disponible con carácter general. Todos los clústeres de base de datos
Aurora MySQL nuevos compatibles con MySQL 5.6, incluidos los que se hayan restablecido a partir de
instantáneas, se crearán en Aurora MySQL 1.17.3. Tiene la opción, aunque no es obligatorio, de actualizar
clústeres de base de datos existentes a Aurora MySQL 1.17.3. Puede crear nuevos clústeres de base de
datos en Aurora MySQL 1.14.4, Aurora MySQL 1.15.1 o Aurora MySQL 1.16. 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.17.3 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.
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.
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
datos de Amazon Aurora (p. 340).
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.
Aurora MySQL 1.17.2 ya está disponible con carácter general. Todos los clústeres de base de datos
Aurora MySQL nuevos compatibles con MySQL 5.6, incluidos los que se hayan restablecido a partir de
instantáneas, se crearán en Aurora MySQL 1.17.2. Tiene la opción, aunque no es obligatorio, de actualizar
clústeres de base de datos existentes a Aurora MySQL 1.17.2. Puede crear nuevos clústeres de base de
datos en Aurora MySQL 1.14.4, Aurora MySQL 1.15.1 o Aurora MySQL 1.16. 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.17.2 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.
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
datos de Amazon Aurora (p. 340).
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.
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
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.
Con la versión 1.17.1 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. En
esta versión se corrigen algunos problemas de motor conocidos, además de aplicar regresiones.
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
datos de Amazon Aurora (p. 340).
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.
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
base de datos de Amazon Aurora (p. 340).
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.
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.
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
de la AWS CLI o la API de Amazon RDS y especificando la versión del motor.
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
las conexiones de cliente durante este proceso. Para obtener más información, consulte Mantenimiento de
un clúster de base de datos de Amazon Aurora (p. 340).
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.
Nuevas características
• 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.
Aurora MySQL 1.15.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 1.15.1.
Tiene la opción, aunque no es obligatorio, de actualizar clústeres de base de datos existentes a Aurora
1.15.1. 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.
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
un clúster de base de datos de Amazon Aurora (p. 340).
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)
Aurora MySQL 1.15 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.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.
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.
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).
Nuevas características
• 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.
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
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
base de datos de Amazon Aurora (p. 340).
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).
Nuevas características
• 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.
Aurora MySQL 1.14.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
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.
Con la versión 1.14.1 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 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.
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.
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.
Aurora MySQL 1.14 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
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.
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.
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.
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.
Aurora MySQL 1.13 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
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
Mantenimiento de un clúster de base de datos de Amazon Aurora (p. 340).
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
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.
• 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)
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).
Nuevas características
• 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.
• 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.
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).
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.
Nuevas características
• 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).
• 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.
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).
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.
Nuevas características
• 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
clúster de base de datos.
Nuevas características
• 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.
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.
Nuevas características
• 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.
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.
Nuevas características
• 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
Mantenimiento de un clúster de base de datos de Amazon Aurora (p. 340).
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.
• 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.
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.
• 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.
Nuevas características
• 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.
• 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)
Nuevas características
• 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.
Nuevas características
• 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.
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.
select AURORA_VERSION();
select @@aurora_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:
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.
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).
• 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.
Nuevas características
• 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.
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.
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.
• Ordenar por un resultado de GROUP_CONCAT() podría provocar una suspensión del servidor. (Error n.º
19880368)
• 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.
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)
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)
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)
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)
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)
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)
• 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. 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).
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
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.
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.
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.
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.
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).
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.
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:
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. 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
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).
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
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).
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)
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.
Métrica Descripción
Unidades: bytes
Unidades: megabytes
Métrica Descripción
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.
Consola
Para crear una réplica de lectura de Aurora a partir de una instancia de base de datos PostgreSQL
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 el panel de navegación, seleccione Databases (Bases de datos).
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.
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
Opción Descripción
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).
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).
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
información, consulte Requisitos previos de clúster de base
de datos (p. 86).
Opción Descripción
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
de ocultar instancias al acceso público, consulte Cómo
ocultar una instancia de base de datos en una VPC desde
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
información, consulte 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 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
bloquea el puerto predeterminado, elija otro puerto para el
nuevo clúster de base de datos.
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).
Opción Descripción
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
precisión de segundos.
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
clúster de base de datos.
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.
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.
Para Windows:
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-cluster-identifier
El nombre de la clase de instancia de base de datos que se va a utilizar para la instancia principal.
• --db-instance-identifier
Example
Para Linux, OS X o Unix:
Para Windows:
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:
• DBClusterIdentifier
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 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 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.
Example
https://rds.us-east-1.amazonaws.com/
?Action=CreateDBCluster
&DBClusterIdentifier=myreadreplicacluster
&DBSubnetGroupName=mysubnetgroup
&Engine=aurora-postgresql
&ReplicationSourceIdentifier=mysqlmasterARN
&SignatureMethod=HmacSHA256
&SignatureVersion=4
&Version=2014-10-31
&VpcSecurityGroupIds=mysecuritygroup
&X-Amz-Algorithm=AWS4-HMAC-SHA256
&X-Amz-Credential=AKIADQKE4SARGYLE/20150927/us-east-1/rds/aws4_request
&X-Amz-Date=20150927T164851Z
&X-Amz-SignedHeaders=content-type;host;user-agent;x-amz-content-sha256;x-amz-date
&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:
• DBClusterIdentifier
El nombre de la clase de instancia de base de datos que se va a utilizar para la instancia principal.
• DBInstanceIdentifier
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
https://rds.us-east-1.amazonaws.com/
?Action=CreateDBInstance
&DBClusterIdentifier=myreadreplicacluster
&DBInstanceClass=myinstanceclass
&DBInstanceIdentifier=myreadreplicainstance
&Engine=aurora-postgresql
&SignatureMethod=HmacSHA256
&SignatureVersion=4
&Version=2014-09-01
&X-Amz-Algorithm=AWS4-HMAC-SHA256
&X-Amz-Credential=AKIADQKE4SARGYLE/20140424/us-east-1/rds/aws4_request
&X-Amz-Date=20140424T194844Z
&X-Amz-SignedHeaders=content-type;host;user-agent;x-amz-content-sha256;x-amz-date
&X-Amz-Signature=bee4aabc750bf7dad0cd9e22b952bd6089d91e2a16592c2293e532eeaab8bc77
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.
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
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 el panel de navegación, seleccione Instances (Instancias).
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:
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.
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)
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.
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:
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.
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.
• 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).
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).
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
Example
Para Windows:
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.
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
Para Windows:
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
Para Windows:
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
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. 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
Para Windows:
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.
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
2|foo2|bar2|elephant2
3|foo3|bar3|elephant3
4|foo4|bar4|elephant4
...
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.
• 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.
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.
• 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.
aws_s3.table_import_from_s3 (
table_name text,
column_list text,
options text,
s3_info aws_commons._s3_uri_1,
credentials aws_commons._aws_credentials_1
)
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
Parámetro Descripción
PostgreSQL. Para obtener más detalles, consulte la documentación de COPY de
PostgreSQL.
• Clave de acceso
• Clave secreta
• Token de sesión
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.
aws_s3.table_import_from_s3 (
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.
aws_s3.table_import_from_s3 (
table_name text,
column_list text,
options text,
bucket text,
file_path text,
region text,
access_key text,
secret_key text,
session_token text
Parámetro Descripción
bucket Cadena de texto que incluye el nombre del bucket de Amazon S3 que contiene el 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
)
Parámetro Descripción
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,
session_token text
)
Parámetro Descripción
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.
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)
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).
LEAST({DBInstanceClassMemory/9531392},5000).
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:
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.
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
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)
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 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. 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
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).
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)
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.
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:
• 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.
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.
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.
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.
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.
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.
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.
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.
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:
Para usar AWS DMS para la replicación lógica con Aurora PostgreSQL
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.
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):
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.
Versión de API 2014-10-31
801
Amazon Aurora Guía del usuario de Aurora
Integración de Aurora PostgreSQL con los servicios de AWS
• 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
Amazon RDS (p. 402).
• 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 un clúster de base de datos de Amazon Aurora (p. 232)
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.
• 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)
psql my-database
my-database=> CREATE EXTENSION apg_plan_mgmt;
Para actualizar, ejecute los siguientes comandos en el nivel de instancia de la base de datos o el clúster.
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)
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).
Cada fila mostrada representa un plan administrado. En el ejemplo anterior se muestra la siguiente
información.
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).
• 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.
Cuando el optimizador procesa cualquier instrucción SQL, utiliza las siguientes reglas para crear la
instrucción SQL normalizada:
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 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');
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'
)
FROM apg_plan_mgmt.dba_plans
WHERE status = 'Unapproved' AND enabled = true;
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).
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
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.
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).
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
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
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
apg_plan_mgmt.evolve_plan_baselines (p. 826).
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.
sql_hash Un valor hash del texto de la instrucción SQL, normalizado con los literales
eliminados.
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.
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).
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)
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).
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
más volátil. Sin embargo, este modo ampliado de la captura de planes automática tiene una
sobrecarga de rendimiento notable.
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).
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.
Parámetro Descripción
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.
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.
Note
A medida que se ejecuta la aplicación, el optimizador captura los planes para cada instrucción coincidente.
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.
En el siguiente gráfico de flujo se muestra cómo el optimizador del administrador de planes de consulta
elige qué plan ejecutar.
El flujo es el siguiente:
1. Cuando el optimizador procesa cada una de las instrucciones SQL, genera un plan de costo mínimo.
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.
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.
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).
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)
Temas
• Aprobar planes mejores (p. 817)
• Rechazar o deshabilitar planes más lentos (p. 818)
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';
0
(1 row)
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'.
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.
)
FROM apg_plan_mgmt.dba_plans
WHERE status = 'Unapproved' AND -- plan is Unapproved
origin = 'Automatic'; -- plan was auto-captured
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.
FROM apg_plan_mgmt.dba_plans
WHERE last_used < (current_date - interval '7 days');
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).
Para modificar el plan generado por el optimizador y capturar el plan con pg_hint_plan
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.
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.
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
para que surtan efecto los cambios. Para obtener más información, consulte el parámetro
apg_plan_mgmt.max_plans (p. 823).
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.
4. Vuelva a cargar los planes administrados en la memoria compartida y elimine la tabla de planes
temporal.
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)
• 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
de clúster de base de datos (p. 269).
• 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.
apg_plan_mgmt.capture_plan_baselines
Habilita la captura de planes de ejecución para instrucciones SQL.
Valor Descripción
automatic Habilita la captura de planes para instrucciones SQL subsiguientes que satisfagan los
criterios de elegibilidad.
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.
Important
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
apg_plan_mgmt.pgss_min_calls
Establece el número máximo de llamadas a pg_stat_statements elegibles para la captura de planes.
Notas de uso
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.
Notas de uso
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.
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.
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.
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
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.
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.
apg_plan_mgmt.use_plan_baselines
Forzar al optimizador a utilizar planes administrados para instrucciones administradas.
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.
Notas de uso
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
Parámetros
Parámetro Descripción
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
)
Valor de retorno
El número de planes que no han sido más rápidos que el mejor plan aprobado.
Parámetros
Parámetro Descripción
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.
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.
Notas de uso
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
Parámetros
Parámetro Descripción
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
• 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.
Sintaxis
apg_plan_mgmt.set_plan_enabled(
sql_hash,
plan_hash,
[true | false]
)
Valor de retorno
Parámetros
Parámetro Descripción
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
Parámetros
Parámetro Descripción
status Una cadena con uno de los siguientes valores, no distingue entre mayúsculas y
minúsculas:
• approved
• unapproved
• rejected
Parámetro Descripción
• 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
Parámetros
Parámetro Descripción
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.
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.
Utilice el formulario validate_plans(sql_hash, NULL, action) para validar todos los planes
administrados para una instrucción administrada especificada con sql_hash.
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)
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)
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.
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 el panel de navegación, seleccione Parameter groups (Grupos de parámetros).
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.
4. En Parameter group actions (Acciones de grupos de parámetros), seleccione Edit (Editar).
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:
• --db-cluster-parameter-group-name
• --parameters
Example
Para Windows:
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
clúster de base de datos de Aurora (p. 314).
Para establecer la prioridad de la promoción para la instancia de base de datos del escritor en
tier-0, realice el siguiente procedimiento
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 el panel de navegación, seleccione Databases (Bases de datos).
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).
6. Elija Continue y consulte el resumen de las modificaciones.
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:
• --db-instance-identifier
• --promotion-tier
• --apply-immediately
Example
Para Windows:
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:
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 el panel de navegación, seleccione Databases (Bases de datos).
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).
6. Elija Continue y consulte el resumen de las modificaciones.
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:
• --db-instance-identifier
• --promotion-tier
• --apply-immediately
Example
Para Windows:
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.
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.
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).
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)
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 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.
5. Elija Continue y consulte el resumen de las modificaciones.
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
un clúster de base de datos Amazon Aurora (p. 235).
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.
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:
Example
Para Windows:
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:
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:
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)
Note
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
Amazon Aurora (p. 340).
• 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.
• 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.
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.
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.
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
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.
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,
myauroracluster.cluster-ro-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:
my-node1.cksc6xlmwcyw.us-east-1-beta.rds.amazonaws.com:5432,
my-node2.cksc6xlmwcyw.us-east-1-beta.rds.amazonaws.com:5432,
my-node3.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.
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.
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.
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,
myauroracluster.cluster-ro-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.
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:
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-node1.cksc6xlmwcyw.us-east-1-beta.rds.amazonaws.com:5432,
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.
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
rdsClient.failoverDBCluster(request);
}
• 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.
import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.SQLException;
import java.sql.Statement;
import java.util.ArrayList;
import java.util.List;
import java.util.stream.Collectors;
import java.util.stream.IntStream;
import org.joda.time.Duration;
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
/*
* 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;
}
return newEndpointList;
}
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
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.
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).
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í
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í
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í
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í
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í
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í
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
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í
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
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.
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)
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;
La siguiente tabla muestra la versión de PostgreSQL con la que es compatible cada versión de 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.
Mejoras
Versión 2.3.1
Puede encontrar las siguientes mejoras en esta actualización del motor.
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
Puede encontrar las siguientes mejoras en esta actualización del motor.
Nuevas características
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
Esta versión de Aurora PostgreSQL es compatible con PostgreSQL 10.6. Para obtener más información
acerca de las mejoras en la versión 10.6, consulte Versión 10.6 de PostgreSQL.
Versiones de parche
• Versión 2.2.1 (p. 859)
• Versión 2.2.0 (p. 860)
Versión 2.2.1
Puede encontrar las siguientes mejoras en esta actualización del motor.
Mejoras
Versión 2.2.0
Puede encontrar las siguientes mejoras en esta actualización del motor.
Nuevas características
Versión 2.1
Esta versión de Aurora PostgreSQL es compatible con PostgreSQL 10.5. Para obtener más información
acerca de las mejoras en la versión 10.5, consulte Versión 10.5 de PostgreSQL.
Versiones de parche
• Versión 2.1.1 (p. 860)
• Versión 2.1.0 (p. 860)
Versión 2.1.1
Puede encontrar las siguientes mejoras en esta actualización del motor.
Mejoras
1. 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".
2. Aumento del tamaño compatible de contraseñas IAM a 8 KB.
3. Mejora de la coherencia del rendimiento en cargas de trabajo de escritura de alto rendimiento.
4. Corrección de un error que podía provocar que se bloqueara una réplica de lectura durante un reinicio.
5. Corrección de un error que podría provocar un error al ejecutar consultas. El mensaje informativo podría
ser: "ERROR DE SQL: Intentando leer el EOF pasado de relación".
6. Corrección de un error que podía provocar un aumento del uso de la memoria después de un reinicio.
7. 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.
8. 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.
9. Corrección de un error que podía provocar que se produjera un error al importar una instantánea de
RDS para PostgreSQL .
Versión 2.1.0
Puede encontrar las siguientes mejoras en esta actualización del motor.
Nuevas características
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
obtener más información, consulte Administración de planes de ejecución de consultas para Aurora
PostgreSQL (p. 802).
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
Versión 2.0
Esta versión de Aurora PostgreSQL es compatible con PostgreSQL 10.4. Para obtener más información
acerca de las mejoras en la versión 10.4, consulte Versión 10.4 de PostgreSQL.
Versiones de parche
• Versión: 2.0.1 (p. 862)
• Versión 2.0.0 (p. 862)
Versión: 2.0.1
Puede encontrar las siguientes mejoras en esta actualización del motor.
Mejoras
1. 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".
2. Aumento del tamaño compatible de contraseñas IAM a 8 KB.
3. Mejora de la coherencia del rendimiento en cargas de trabajo de escritura de alto rendimiento.
4. Corrección de un error que podía provocar que se bloqueara una réplica de lectura durante un reinicio.
5. Corrección de un error que podría provocar un error al ejecutar consultas. El mensaje informativo podría
ser: "ERROR DE SQL: Intentando leer el EOF pasado de relación".
6. Corrección de un error que podía provocar un aumento del uso de la memoria después de un reinicio.
7. 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.
8. 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.
9. Corrección de un error que podía provocar que se produjera un error al importar una instantánea de
RDS para PostgreSQL .
Versión 2.0.0
Puede encontrar las siguientes mejoras en esta actualización del motor.
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.
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
Puede encontrar las siguientes mejoras en esta actualización del motor.
Mejoras
Versión 1.5.1
Puede encontrar las siguientes mejoras en esta actualización del motor.
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
Puede encontrar las siguientes mejoras en esta actualización del motor.
Nuevas características
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 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
Esta versión de Aurora PostgreSQL es compatible con PostgreSQL 9.6.11. Para obtener más información
acerca de las mejoras en la versión 9.6.11, consulte Versión 9.6.11 de PostgreSQL.
Nuevas características
Mejoras
1. Esta versión contiene todas las correcciones, características y mejoras presentes en Versión
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).
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.
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
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.
Versión 1.3
Esta versión de Aurora PostgreSQL es compatible con PostgreSQL 9.6.9. Para obtener más información
acerca de las mejoras en la versión 9.6.9, consulte Versión 9.6.9 de PostgreSQL.
Versión de API 2014-10-31
865
Amazon Aurora Guía del usuario de Aurora
Versiones del motor de Aurora PostgreSQL
Versiones de parche
• Versión 1.3.2 (p. 866)
• Versión 1.3.0 (p. 866)
Versión 1.3.2
Puede encontrar las siguientes mejoras en esta actualización del motor.
Nuevas características
Mejoras
1. 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".
2. Aumento del tamaño compatible de contraseñas IAM a 8 KB.
3. Mejora de la coherencia del rendimiento en cargas de trabajo de escritura de alto rendimiento.
4. Corrección de un error que podía provocar que se bloqueara una réplica de lectura durante un reinicio.
5. Corrección de un error que podría provocar un error al ejecutar consultas. El mensaje informativo podría
ser: "ERROR DE SQL: Intentando leer el EOF pasado de relación".
6. Corrección de un error que podía provocar un aumento del uso de la memoria después de un reinicio.
7. 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.
8. 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.
9. Corrección de un error que podía provocar que se produjera un error al importar una instantánea de
RDS para PostgreSQL .
Versión 1.3.0
Puede encontrar las siguientes mejoras en esta actualización del motor.
Mejoras
1. Esta versión contiene todas las correcciones, características y mejoras presentes en Versión
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)
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:
Versión 1.2
Esta versión de Aurora PostgreSQL es compatible con PostgreSQL 9.6.8. Para obtener más información
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
Puede encontrar las siguientes mejoras en esta actualización del motor.
Nuevas características
Mejoras
1. 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".
Versión 1.2.0
Puede encontrar las siguientes mejoras en esta actualización del motor.
Nuevas características
Mejoras
1. Esta versión contiene todas las correcciones, características y mejoras presentes en Versión
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.
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:
Versión 1.1
Esta versión de Aurora PostgreSQL es compatible con PostgreSQL 9.6.6. Para obtener más información
sobre las mejoras de la versión 9.6.6, consulte Versión 9.6.6 de PostgreSQL.
Nuevas características
Mejoras
1. Esta versión contiene todas las correcciones, características y mejoras presentes en Versión
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.
Versión 1.0
Esta versión de Aurora PostgreSQL es compatible con PostgreSQL 9.6.3. Para obtener más información
sobre las mejoras de la versión 9.6.3, consulte Versión 9.6.3 de PostgreSQL.
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
Puede encontrar las siguientes mejoras en esta actualización del motor:
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.
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
Puede encontrar las siguientes mejoras en esta actualización del motor:
Versión 1.0.7
Es la primera versión de Amazon Compatibilidad de Aurora con PostgreSQL disponible con carácter
general.
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:
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)
• 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.
• 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).
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).
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.
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.
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
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.
• ¿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.
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
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.
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
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.
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.
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.
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.
• 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
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.
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.
• 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.
• 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.
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.
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
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.
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).
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.
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
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.
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
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
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.
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
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.
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
• 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.
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)
Clústeres 40
Suscripciones de eventos 20
Grupos de parámetros 50
Instancias reservadas 40
Grupos de subredes 50
Note
Nombre de base de datos Las restricciones de los nombres de base de datos difieren
para cada motor de base de datos.
Nombre de usuario maestro Las restricciones de los nombres de usuario maestros difieren
para cada motor de base de datos.
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).
• 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.
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):
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:
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.
Para obtener más información sobre la creación de usuarios de IAM, consulte Creación de un usuario de
IAM (p. 50).
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 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:
• 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.
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).
• 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.
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).
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.
• 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
Estas son algunas de las situaciones comunes que pueden causar errores 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.
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.
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.
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.
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)
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.
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"; }
• 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
https://forums.aws.amazon.com/
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.
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
instancia de base de datos.
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.
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.
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
instancia de base de datos.
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
de datos de Aurora PostgreSQL.
Para obtener más información,
consulte Uso de la replicación
lógica de PostgreSQL.
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.
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.
Para obtener más información,
consulte Clase de instancia de
base de datos.
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.
Para obtener más información,
consulte Clase de instancia de
base de datos.
Bases de datos globales de Ahora puede crear bases de November 28, 2018
Aurora (p. 903) datos globales de Aurora. Una
base de datos global de Aurora
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á
disponible y es compatible con
PostgreSQL 10.5. Para obtener
más información, consulte
Versión 2.1.
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
de datos. Para obtener más
información, consulte la sección
Uso de la API de datos para
Aurora Serverless.
Aurora PostgreSQL, versión 2.0 La versión 2.0 de Compatibilidad September 25, 2018
(p. 903) de Aurora con PostgreSQL está
disponible y es compatible con
PostgreSQL 10.4. Para obtener
más información, consulte
Versión 2.0.
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.