# Supervisión de archivos de registro de Amazon Aurora
Cada motor de base de datos de RDS genera registros a los que puede acceder para realizar auditorías y solucionar problemas. El tipo de registros depende del motor de base de datos.
Puede acceder a los registros de base de datos de instancias de base de datos mediante la Consola de administración de AWS, la AWS Command Line Interface (AWS CLI) o la API de Amazon RDS. No puede visualizar, ver ni descargar registros de transacciones.
**nota**
En algunos casos, los registros contienen datos ocultos. Por tanto, la Consola de administración de AWS podría mostrar contenido en un archivo de registro, pero el archivo de registro podría estar vacío cuando lo descarga.
**Topics**
+ [Visualización y descripción de archivos de registro de base de datos](USER_LogAccess.Procedural.Viewing.md)
+ [Descarga de un archivo de registro de base de datos](USER_LogAccess.Procedural.Downloading.md)
+ [Ver un archivo de registro de base de datos](USER_LogAccess.Procedural.Watching.md)
+ [Publicación de registros de base de datos en registros de Amazon Cloudwatch](USER_LogAccess.Procedural.UploadtoCloudWatch.md)
+ [Lectura del contenido del archivo de registro mediante REST](DownloadCompleteDBLogFile.md)
+ [Archivos de registro de base de datos de Aurora MySQL](USER_LogAccess.Concepts.MySQL.md)
+ [Archivos de registro de base de datos de Aurora PostgreSQL](USER_LogAccess.Concepts.PostgreSQL.md)
# Visualización y descripción de archivos de registro de base de datos
Puede ver los archivos de registro de base de datos de su motor de base de datos de Amazon Aurora con la Consola de administración de AWS. Puede ver los archivos de registro que están disponibles para descargar o monitorear mediante la AWS CLI o la API de Amazon RDS.
**nota**
No puede ver los archivos de registro de los clústeres de base de datos de Aurora Serverless v1 en la consola de RDS. Sin embargo, puede verlos en la consola de Amazon CloudWatch en [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
## Consola
**Para ver un archivo de registro de base de datos**
1. Abra la consola de Amazon RDS en [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. En el panel de navegación, seleccione **Databases (Bases de datos)**.
1. Seleccione el nombre de la instancia de base de datos que tiene el archivo de registro que desea visualizar.
1. Seleccione la pestaña **Logs & events (Registros y eventos)**.
1. Desplácese hacia abajo hasta la sección **Logs (Registros)**.
1. (Opcional) Ingrese un término de búsqueda para filtrar los resultados.
En el siguiente ejemplo, se enumeran los registros filtrados por el texto **error**.
![\[Lista de los registros de base de datos\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/AuroraUserGuide/images/ListEventsAMS.png)
1. Elija el registro que quiera visualizar y, a continuación, elija **View (Ver)**.
## AWS CLI
Para ver los archivos de registro de base de datos disponibles para una instancia de base de datos, use el comando [AWS CLI](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-log-files.html) de la `describe-db-log-files`.
El siguiente ejemplo devuelve una lista de los archivos de registro de una instancia de base de datos denominada `my-db-instance`.
**Example**
```
1. aws rds describe-db-log-files --db-instance-identifier my-db-instance
```
## API de RDS
Para ver los archivos de registro de base de datos de una instancia de base de datos, use la acción [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBLogFiles.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBLogFiles.html) de la API de Amazon RDS.
# Descarga de un archivo de registro de base de datos
Puede usar la Consola de administración de AWS, la AWS CLI o la API para descargar un archivo de registro de base de datos.
## Consola
**Para descargar un archivo de registro de base de datos**
1. Abra la consola de Amazon RDS en [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. En el panel de navegación, seleccione **Databases (Bases de datos)**.
1. Seleccione el nombre de la instancia de base de datos que tiene el archivo de registro que desea visualizar.
1. Seleccione la pestaña **Logs & events (Registros y eventos)**.
1. Desplácese hacia abajo hasta la sección **Logs (Registros)**.
1. En la sección **Logs (Registros)**, elija el botón junto al registro que desee descargar y, a continuación, elija **Download (Descargar)**.
1. Abra el menú contextual (haga clic con el botón derecho) del enlace que se proporciona y elija **Save Link As (Guardar enlace como)**. Escriba la ubicación en la que desee guardar el archivo de registro y elija **Save (Guardar)**.
![\[visualización de archivo de registro\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/AuroraUserGuide/images/log_download2.png)
## AWS CLI
Para descargar un archivo de registro de base de datos, use el comando [AWS CLI](https://docs.aws.amazon.com/cli/latest/reference/rds/download-db-log-file-portion.html) de la `download-db-log-file-portion`. 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 Linux, macOS o:Unix
```
1. aws rds download-db-log-file-portion \
2. --db-instance-identifier myexampledb \
3. --starting-token 0 --output text \
4. --log-file-name log/ERROR.4 > errorlog.txt
```
En:Windows
```
1. aws rds download-db-log-file-portion ^
2. --db-instance-identifier myexampledb ^
3. --starting-token 0 --output text ^
4. --log-file-name log/ERROR.4 > errorlog.txt
```
## API de RDS
Para descargar un archivo de registro de base de datos, use la acción [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DownloadDBLogFilePortion.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DownloadDBLogFilePortion.html) de la API de Amazon RDS.
# Ver un archivo de registro de base de datos
Ver un archivo de registro de base de datos equivale a detallar el archivo en un sistema UNIX o Linux. Puede ver un archivo de registro usando la Consola de administración de AWS. RDS actualiza el detalle del registro cada 5 segundos.
**Para monitorizar un archivo de registro de base de datos**
1. Abra la consola de Amazon RDS en [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. En el panel de navegación, seleccione **Databases (Bases de datos)**.
1. Seleccione el nombre de la instancia de base de datos que tiene el archivo de registro que desea visualizar.
1. Seleccione la pestaña **Logs & events (Registros y eventos)**.
![\[Seleccione la pestaña Logs & events (Registros y eventos).\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/AuroraUserGuide/images/Monitoring_logsEvents.png)
1. En la sección **Logs (Registros)**, elija un archivo de registro y, a continuación, elija **Watch (Ver)**.
![\[Elija un registro.\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/AuroraUserGuide/images/Monitoring_LogsEvents_watch.png)
RDS muestra el detalle del registro, como en el siguiente ejemplo de MySQL.
![\[Detalle de un archivo de registro\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/AuroraUserGuide/images/Monitoring_LogsEvents_watch_content.png)
# Publicación de registros de base de datos en registros de Amazon Cloudwatch
En una base de datos en las instalaciones, los registros de la base de datos residen en el sistema de archivos. Amazon RDS no proporciona acceso de host a los registros de base de datos del sistema de archivos de el clúster de base de datos. Por este motivo, Amazon RDS le permite exportar registros de base de datos a [registros de Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html). Con CloudWatch Logs, puede realizar análisis en tiempo real de los datos de registro. También puede guardarlos en un almacenamiento de larga duración y gestionarlos con el agente de CloudWatch Logs.
**Topics**
+ [Descripción general de la integración de RDS con CloudWatch Logs](#rds-integration-cw-logs)
+ [Decisión sobre los registros que desea publicar en CloudWatch Logs](#engine-specific-logs)
+ [Especificación de registros que desea publicar en CloudWatch Logs](#integrating_cloudwatchlogs.configure)
+ [Búsqueda y filtrado de los registros en CloudWatch Logs](#accessing-logs-in-cloudwatch)
## Descripción general de la integración de RDS con CloudWatch Logs
En CloudWatch Logs, un *flujo de registro* es una secuencia de eventos de registro que comparten el mismo origen. Cada fuente independiente de registros en Registros de CloudWatch constituye un flujo de registros independiente. Un *grupo de registro* es un grupo de flujos de registro que comparten la misma configuración de retención, monitorización y control de acceso.
Amazon Aurora transmite continuamente sus registros de clúster de base de datos en un grupo de registro. Por ejemplo, hay un grupo de registros `/aws/rds/cluster/cluster_name/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.
AWS conserva los datos de registro publicados en CloudWatch Logs durante un periodo de tiempo indefinido a menos que se especifique un periodo de retención. Para obtener más información, consulte [Cambiar la retención de datos de registro en CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Working-with-log-groups-and-streams.html#SettingLogRetention).
## Decisión sobre los registros que desea publicar en CloudWatch Logs
Cada motor de base de datos RDS admite su propio conjunto de registros. Para obtener más información sobre las opciones del motor de base de datos, revise los siguientes temas:
+ [Publicación de registros de Amazon Aurora MySQL en Amazon CloudWatch Logs](AuroraMySQL.Integrating.CloudWatch.md)
+ [Publicación de registros de Aurora PostgreSQL en Amazon CloudWatch Logs](AuroraPostgreSQL.CloudWatch.md)
## Especificación de registros que desea publicar en CloudWatch Logs
Puede especificar qué registros se van a publicar en la consola. Asegúrese de que tiene un rol vinculado a un servicio en AWS Identity and Access Management (IAM). Para obtener más información acerca de los roles vinculados a servicios, consulte [Uso de roles vinculados a servicios de Amazon Aurora](UsingWithRDS.IAM.ServiceLinkedRoles.md).
**Para especificar los registros que se van a publicar**
1. Abra la consola de Amazon RDS en [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. En el panel de navegación, elija **Databases** (Bases de datos).
1. Haga una de estas dos operaciones:
+ Elija **Creación de base de datos**.
+ Elija una base de datos de la lista y luego seleccione **Modify (Modificar)**.
1. En **Logs exports (Exportaciones de registros)**, elija los registros que desea publicar.
En el siguiente ejemplo se especifican el registro de auditoría, los registros de errores, el registro general, el registro de instancias, el registro de errores de autenticación de bases de datos de IAM y el registro de consultas lentas para un clúster de bases de datos de Aurora MySQL.
## Búsqueda y filtrado de los registros en CloudWatch Logs
Puede buscar las entradas de registro que cumplan los criterios especificados mediante la consola de CloudWatch Logs. Puede acceder a los registros a través de la consola de RDS, que lo lleva a la consola de CloudWatch Logs, o directamente desde la consola de CloudWatch Logs.
**Para buscar los registros de RDS mediante la consola de RDS**
1. Abra la consola de Amazon RDS en [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. En el panel de navegación, elija **Databases** (Bases de datos).
1. Elija un clúster de base de datos o una instancia de base de datos.
1. Elija **Configuración**.
1. En **Published logs (Registros publicados)**, elija el registro de base de datos que desea ver.
**Para buscar registros de RDS mediante la consola de CloudWatch Logs**
1. Abra la consola de CloudWatch en [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. En el panel de navegación, seleccione **Grupos de registro**.
1. En el cuadro de filtro, escriba **/aws/rds**.
1. En **Log Groups (Grupos de registro)**, elija el nombre del grupo de registro que contiene el flujo de registros que desea buscar.
1. En **Log Streams (Flujos de registros)**, elija el nombre del flujo de registros que desea buscar.
1. En **Log events (Eventos de registros)**, escriba la sintaxis del filtro que se va a utilizar.
Para obtener más información, consulte el temas sobre cómo [buscar y filtrar datos de registros](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/MonitoringLogData.html) en la *guía del usuario de Amazon CloudWatch*. Para ver un tutorial en el blog que explique cómo monitorear los registros de RDS, consulte la publicación del blog sobre cómo [crear un monitoreo proactivo de bases de datos para Amazon RDS con registros de Amazon Cloudwatch, AWS Lambda y Amazon SNS](https://aws.amazon.com/blogs/database/build-proactive-database-monitoring-for-amazon-rds-with-amazon-cloudwatch-logs-aws-lambda-and-amazon-sns/).
# Lectura del contenido del archivo de registro mediante REST
Amazon RDS proporciona un punto de enlace REST que permite el acceso a los archivos de registro de instancia de base de datos. Esto resulta útil si necesita escribir una aplicación para transmitir el contenido del archivo de registro de Amazon RDS.
La sintaxis es la siguiente:
```
GET /v13/downloadCompleteLogFile/DBInstanceIdentifier/LogFileName HTTP/1.1
Content-type: application/json
host: rds.region.amazonaws.com
```
Se requieren los siguientes parámetros:
+ `DBInstanceIdentifier`: el nombre asignado de la instancia de base de datos que contiene el archivo de registro que se desea descargar.
+ `LogFileName`: el nombre del archivo de registro que se va a descargar.
La respuesta incluye el contenido del archivo de registro solicitado como una secuencia.
En el siguiente ejemplo se descarga el archivo de registro denominado *log/ERROR.6* para la instancia de base de datos denominada *sample-sql* en la región *us-west-2*.
```
GET /v13/downloadCompleteLogFile/sample-sql/log/ERROR.6 HTTP/1.1
host: rds.us-west-2.amazonaws.com
X-Amz-Security-Token: AQoDYXdzEIH//////////wEa0AIXLhngC5zp9CyB1R6abwKrXHVR5efnAVN3XvR7IwqKYalFSn6UyJuEFTft9nObglx4QJ+GXV9cpACkETq=
X-Amz-Date: 20140903T233749Z
X-Amz-Algorithm: AWS4-HMAC-SHA256
X-Amz-Credential: AKIADQKE4SARGYLE/20140903/us-west-2/rds/aws4_request
X-Amz-SignedHeaders: host
X-Amz-Content-SHA256: e3b0c44298fc1c229afbf4c8996fb92427ae41e4649b934de495991b7852b855
X-Amz-Expires: 86400
X-Amz-Signature: 353a4f14b3f250142d9afc34f9f9948154d46ce7d4ec091d0cdabbcf8b40c558
```
Si especifica una instancia de base de datos no existente, la respuesta consta del error siguiente:
+ `DBInstanceNotFound`: `DBInstanceIdentifier` no hace referencia a una instancia de base de datos existente. (Código de estado HTTP: 404)
# Archivos de registro de base de datos de Aurora MySQL
Puede supervisar los registros de Aurora MySQL directamente desde la consola de Amazon RDS, la API de Amazon RDS, 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 [Supervisión de archivos de registro de Amazon Aurora](USER_LogAccess.md).
**Topics**
+ [Información general de los registros de bases de datos de Aurora MySQL](USER_LogAccess.MySQL.LogFileSize.md)
+ [Envío de la salida del registro de Aurora MySQL a las tablas](Appendix.MySQL.CommonDBATasks.Logs.md)
+ [Configuración del registro binario de Aurora MySQL para bases de datos Single-AZ](USER_LogAccess.MySQL.BinaryFormat.md)
+ [Acceso a los registros binarios de MySQL](USER_LogAccess.MySQL.Binarylog.md)
# Información general de los registros de bases de datos de Aurora MySQL
Puede supervisar los siguientes tipos de archivos de registro de Aurora MySQL:
+ Registro de errores
+ Registro de consultas lentas
+ Registro general
+ Registro de auditoría
+ Registro de instancias
+ Registro de errores de autenticación de base de datos de IAM
El registro de errores de Aurora MySQL se genera de forma predeterminada. Puede generar la consulta lenta y los registros generales estableciendo parámetros en su grupo de parámetros de base de datos.
**Topics**
+ [Registros de errores de Aurora MySQL](#USER_LogAccess.MySQL.Errorlog)
+ [Registros generales y de consultas lentas de Aurora MySQL](#USER_LogAccess.MySQL.Generallog)
+ [Registro de auditoría de Aurora MySQL](#ams-audit-log)
+ [Registro de instancias de Aurora MySQL](#ams-instance-log)
+ [Rotación y retención de registros en Aurora MySQL](#USER_LogAccess.AMS.LogFileSize.retention)
+ [Publicación de registros de Aurora MySQL en Amazon CloudWatch Logs](#USER_LogAccess.MySQLDB.PublishAuroraMySQLtoCloudWatchLogs)
## Registros de errores de Aurora MySQL
Aurora MySQL escribe los errores en el archivo `mysql-error.log`. 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.
Aurora 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.
Por diseño, los registros de errores se filtran para que solo se muestren los eventos inesperados, por ejemplo, los errores. No obstante, los registros de errores también contienen información adicional sobre la base de datos, por ejemplo, el progreso de la consulta, que no se muestra. Por lo tanto, incluso sin ningún error real, el tamaño de los registros de errores podría aumentar debido a las actividades continuas de la base de datos. Y, aunque puede que vea un tamaño determinado en bytes o kilobytes en los registros de error de la Consola de administración de AWS, es posible que tengan 0 bytes al descargarlos.
Aurora MySQL escribe `mysql-error.log` en disco cada 5 minutos. Adjunta el contenido del registro a `mysql-error-running.log`.
Aurora MySQL rota el archivo `mysql-error-running.log` cada hora.
**nota**
Tenga en cuenta que el periodo de retención es diferente entre Amazon RDS y Aurora.
## Registros generales y de consultas lentas de Aurora MySQL
Puede escribir el registro de consultas lentas de Aurora MySQLRDS para MySQL y el registro general en un archivo o en una tabla de la base de datos. Para hacerlo, establezca los parámetros en el grupo de parámetros de la base de datos. Para obtener información acerca de cómo crear y modificar un grupo de parámetros de base de datos, consulte [Grupos de parámetros para Amazon Aurora](USER_WorkingWithParamGroups.md). Debe definir estos parámetros para poder ver el registro de consultas lentas o el registro general en la consola de Amazon RDS o a través de la API de Amazon RDS, la CLI de Amazon RDS o los SDK de AWS.
Puede controlar lo que registra Aurora 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\$1output = FILE, puede especificar un valor de punto flotante que llega a una resolución de microsegundos. Si log\$1output = TABLE, debe especificar un valor entero con resolución de segundos. Solo se registran 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. Las consultas que no usen un índice se registran incluso si su tiempo de ejecución es inferior al valor del parámetro `long_query_time`. El valor predeterminado es 0.
+ `log_output option`: puede especificar una de las opciones siguientes para el parámetro `log_output`.
+ **TABLE** : 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.
+ **NONE**: deshabilitar registro.
Para las versiones 2 y 3 de Aurora MySQL, el valor predeterminado de `log_output` es `FILE`.
Para que los datos de consultas lentas aparezcan en Registros de Amazon CloudWatch, se deben cumplir las siguientes condiciones:
+ Registros de CloudWatch debe configurarse para incluir registros de consultas lentas.
+ `slow_query_log` debe estar habilitado.
+ `log_output` debe establecerse en `FILE`.
+ La consulta debe tardar más tiempo que el tiempo configurado para `long_query_time`.
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:
+ [El registro de consultas lentas](https://dev.mysql.com/doc/refman/8.0/en/slow-query-log.html)
+ [El registro de consultas generales](https://dev.mysql.com/doc/refman/8.0/en/query-log.html)
## Registro de auditoría de Aurora MySQL
El registro de auditoría para Aurora MySQL se llama auditoría avanzada. Para activar la auditoría avanzada, hay que establecer ciertos parámetros del clúster de base de datos. Para obtener más información, consulte [Uso de auditorías avanzadas con un clúster de base de datos de Amazon Aurora MySQL](AuroraMySQL.Auditing.md).
## Registro de instancias de Aurora MySQL
Aurora crea un archivo de registro independiente para las instancias de base de datos que tienen la pausa automática habilitada. Este archivo instance.log registra cualquier motivo por el que estas instancias de base de datos no han podido pausarse cuando se esperaba. Para obtener más información sobre el comportamiento del archivo de registro de instancias y la capacidad de pausa automática de Aurora, consulte [Supervisión de la actividad de pausa y reanudación de Aurora sin servidor v2](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-serverless-v2-administration.html#autopause-logging-instance-log).
## Rotación y retención de registros en Aurora MySQL
Cuando el registro está habilitado, Amazon Aurora rota 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 desempeño. Aurora MySQL gestiona la rotación y la eliminación de la siguiente manera:
+ El tamaño de los archivos de registro de errores de Aurora MySQL está limitado al 15 % del almacenamiento local de una instancia de base de datos. Para mantener este umbral, los registros se rotan automáticamente cada hora. Aurora MySQL elimina los registros después de 30 días o cuando se alcanza el 15 % del espacio en disco. Si el tamaño combinado de los archivos de registro sobrepasa el umbral después de eliminar los archivos de registro antiguos, los archivos de registro más grandes se eliminan hasta que el tamaño del archivo de registro deje de sobrepasar el umbral.
+ Aurora MySQL elimina los registros de auditoría, generales y de consultas lentas después de 24 horas o cuando se ha consumido el 15 % del almacenamiento.
+ Cuando el registro `FILE` está activado, los archivos de registro general y de consulta lenta se examinan cada hora y se eliminan los archivos de registro con más de 24 horas de antigüedad. En algunos casos, el tamaño restante del archivo de registro combinado después de la eliminación puede superar el umbral del 15 % del espacio local de una instancia de base de datos. En estos casos, los archivos de registro más antiguos se eliminan hasta que el tamaño del archivo de registro no sobrepase el umbral.
+ Cuando el registro `TABLE` está activado, las tablas de registro no se rotan ni se eliminan. Las tablas de registro se truncan cuando el tamaño de todos los registros combinados es demasiado grande. Puede suscribirse a la categoría de evento `low storage` para recibir una notificación cuando las tablas de registro se deban rotar o eliminar manualmente para liberar espacio. Para obtener más información, consulte [Uso de notificaciones de eventos de Amazon RDS](USER_Events.md).
Puede rotar la tabla `mysql.general_log` manualmente si llama al procedimiento `mysql.rds_rotate_general_log`. Para rotar la tabla `mysql.slow_log` puede ejecutar el procedimiento `mysql.rds_rotate_slow_log`.
Cuando rota las tablas de registro manualmente, la tabla de registro actual se copia en una tabla de registro de copia de seguridad y se eliminan las entradas de la tabla de registro actual. 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 de la tabla `mysql.slow_log` se llama `mysql.slow_log_backup`.
+ Los registros de auditoría de Aurora MySQL se rotan cuando el tamaño de archivo alcanza los 100 MB y se eliminan después de 24 horas.
+ Amazon RDS rota los archivos de registro de errores de autenticación de la base de datos de IAM de más de 10 MB. Amazon RDS elimina los archivos de registro de errores de autenticación de la base de datos de IAM que tengan más de cinco días o más de 100 MB.
Para trabajar con los registros desde la consola de Amazon RDS, la API de Amazon RDS, la 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 Aurora MySQL, estos archivos de registro rotan cada hora. Se conservan los archivos de registro que se generaron durante las 24 horas anteriores. Tenga en cuenta que el período de retención es diferente entre Amazon RDS y Aurora.
## Publicación de registros de Aurora MySQL en Amazon CloudWatch Logs
Puede configurar un clúster de bases de datos de Aurora MySQL para publicar datos de registro en un grupo de registros en Amazon CloudWatch Logs. Con CloudWatch Logs, puede realizar análisis en 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](AuroraMySQL.Integrating.CloudWatch.md).
# Envío de la salida del registro de Aurora MySQL a las tablas
Para dirigir los registros general y de consultas lentas a tablas de la instancia de base de datos, cree un grupo de parámetros de base de datos y asigne al parámetro `log_output` del servidor el valor `TABLE`. Las consultas generales se registrarán entonces en la tabla `mysql.general_log` y las consultas lentas en la tabla `mysql.slow_log`. Puede consultar las tablas para obtener acceso a la información del registro. Al habilitar este registro, se incrementa la cantidad de datos que se escribe en la base de datos, lo que puede degradar el desempeño.
Tanto el registro general como los registros de consultas lentas están deshabilitados de manera predeterminada. Para habilitar el registro en tablas, también debe asignar a los parámetros `general_log` y `slow_query_log` del servidor el valor `1`.
Las tablas de registro seguirán creciendo hasta que las actividades de registro respectivas se desactiven cambiando el valor del parámetro a `0`. A menudo, se acumula una gran cantidad de datos, lo que puede consumir un porcentaje elevado del espacio de almacenamiento asignado. Amazon Aurora no permite truncar las tablas de registro, pero sí mover su contenido. Al rotar una tabla, su contenido se guarda en una tabla de copia de seguridad y se crea una nueva tabla de registro vacía. Puede aplicar manualmente la rotación de las tablas de registro con los procedimientos de línea de comandos siguientes, en los que el símbolo del sistema se representa por:`PROMPT>`
```
PROMPT> CALL mysql.rds_rotate_slow_log;
PROMPT> CALL mysql.rds_rotate_general_log;
```
Para eliminar por completo los datos antiguos y recuperar el espacio del disco, llame al procedimiento correspondiente dos veces consecutivas.
# Configuración del registro binario de Aurora MySQL para bases de datos Single-AZ
El *registro binario* es un conjunto de archivos de registro que contienen información acerca de las modificaciones de datos hechas en una instancia de servidor de Aurora MySQL. El registro binario contiene información como la siguiente:
+ Eventos que describen cambios en la base de datos, como la creación de tablas o las modificaciones de filas.
+ Información sobre la duración de cada instrucción que actualizó los datos.
+ Eventos para instrucciones que podrían haber actualizado datos, pero que no lo hicieron.
El registro binario registra las instrucciones que se envían durante la replicación. También es necesario para algunas operaciones de recuperación. Para obtener más información, consulte [The Binary Log](https://dev.mysql.com/doc/refman/8.0/en/binary-log.html) en la documentación de MySQL.
Los registros binarios solo son accesibles desde la instancia principal de base de datos, no desde las réplicas.
MySQL en Amazon Aurora admite los formatos de registro binario *basado en filas*, *basado en instrucciones* y *mixto*. Recomendamos mezclarlos, a menos que necesite un formato binlog concreto. Para obtener información detallada acerca de los formatos de registro binarios de MySQL de Aurora, consulte [Binary logging formats](https://dev.mysql.com/doc/refman/8.0/en/binary-log-formats.html) en la documentación de MySQL.
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](https://dev.mysql.com/doc/refman/8.0/en/replication-sbr-rbr.html) en la documentación de MySQL.
**importante**
Con MySQL 8.0.34, MySQL ha dejado de utilizar el parámetro `binlog_format`. En versiones posteriores de MySQL, MySQL planea eliminar el parámetro y admitir únicamente la replicación basada en filas. Por ello, recomendamos utilizar el registro basado en filas para las nuevas configuraciones de replicación de MySQL. Para obtener más información, consulte [binlog\$1format](https://dev.mysql.com/doc/refman/8.0/en/replication-options-binary-log.html#sysvar_binlog_format) en la documentación de MySQL.
Las versiones 8.0 y 8.4 de MySQL aceptan el parámetro `binlog_format`. Al usar este parámetro, MySQL emite una advertencia de obsolescencia. En una futura versión principal, MySQL eliminará el parámetro `binlog_format`.
La replicación basada en instrucciones puede causar incoherencias entre el clúster de la 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](https://dev.mysql.com/doc/refman/8.0/en/replication-rbr-safe-unsafe.html) en la documentación de MySQL.
Habilitar el registro binario aumenta el número de operaciones de E/S de escritura en el disco en el clúster de base de datos. Puede supervisar el uso de IOPS con la métrica de CloudWatch ```VolumeWriteIOPs`.
**Para configurar el formato de registro binario de MySQL**
1. Abra la consola de Amazon RDS en [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. En el panel de navegación, seleccione **Grupos de parámetros**.
1. Seleccione el grupo de parámetros del clúster de base de datos asociado con el clúster de base de datos que quiera modificar.
No puede modificar un grupo de parámetros predeterminado. Si el clúster de la de base de datos emplea un grupo de parámetros predeterminado, cree un nuevo grupo de parámetros y asócielo con el clúster de la de base de datos.
Para obtener más información acerca de los grupos de parámetros, consulte [Grupos de parámetros para Amazon Aurora](USER_WorkingWithParamGroups.md).
1. En **Acciones**, elija **Editar**.
1. Establezca el parámetro `binlog_format` en el formato de registro binario de su elección (`ROW`, `STATEMENT` o `MIXED`). También puede utilizar el valor `OFF` para desactivar el registro binario.
**nota**
Si `binlog_format` se establece en `OFF` en el grupo de parámetros del clúster de base de datos, se deshabilita la variable de sesión `log_bin`. Esto deshabilita el registro binario en el clúster de base de datos de Aurora MySQL, lo que a su vez restablece la variable de sesión `binlog_format` al valor predeterminado de `ROW` en la base de datos.
1. Elija **Guardar cambios** para guardar los cambios realizados en el grupo de parámetros del clúster de la base de datos.
Tras realizar estos pasos, debe reiniciar la instancia de escritor en el clúster de base de datos para que se apliquen los cambios. En la versión 2.09 de Aurora MySQL y las versiones anteriores, al reiniciar la instancia del escritor, también se reinician todas las instancias del lector en el clúster de base de datos. En la versión 2.10 de Aurora MySQL y versiones posteriores, debe reiniciar todas las instancias del lector manualmente. Para obtener más información, consulte [Reinicio de un clúster de base de datos de Amazon Aurora o de una instancia de base de datos de Amazon Aurora](USER_RebootCluster.md).
**importante**
El cambio de un grupo de parámetros de clúster de bases de datos afecta a todos los clústeres de base de datos que utilizan ese grupo de parámetros. Si desea especificar diferentes formatos de registro binario para diferentes clústeres de base de datos de Aurora MySQL en una región de AWS, los clústeres de base de datos deben utilizar diferentes grupos de parámetros de clúster de bases de datos. Estos grupos de parámetros identifican diferentes formatos de registro. Asigne el grupo de parámetros de clúster de bases de datos apropiado a cada clúster de bases de datos. Para obtener más información acerca de los parámetros Aurora MySQL, consulte [Parámetros de configuración de Aurora MySQL](AuroraMySQL.Reference.ParameterGroups.md).
# Acceso a los registros binarios de MySQL
Puede usar la herramienta mysqlbinlog para descargar o transmitir los registros binarios desde las instancias de Amazon RDS para MySQL. El registro binario se descarga en el equipo local, donde puede ejecutar acciones tales como reproducirlo con la utilidad mysql. Para obtener más información acerca del uso de la herramienta mysqlbinlog, consulte [Using mysqlbinlog to Back Up Binary Log Files](https://dev.mysql.com/doc/refman/8.0/en/mysqlbinlog-backup.html) (Uso de mysqlbinlog para realizar copias de seguridad de archivos de registro binarios) en la documentación de MySQL.
Para ejecutar la utilidad mysqlbinlog en una instancia de Amazon RDS, use las siguientes opciones:
+ `--read-from-remote-server`: obligatorio.
+ `--host`: el nombre de DNS del punto de conexión de la instancia.
+ `--port`: el puerto que utiliza la instancia.
+ `--user`: un usuario de MySQL al que se le concede el permiso `REPLICATION SLAVE`.
+ `--password`: la contraseña del usuario de MySQL, o bien no indique ninguna para que la herramienta le pida una.
+ `--raw`: descargue el archivo en formato binario.
+ `--result-file`: el archivo local en que se guardará la salida sin procesar.
+ `--stop-never`: transmita los archivos de registro binarios.
+ `--verbose`: cuando utilice el formato binlog de `ROW`, incluya esta opción para ver los eventos de fila como instrucciones pseudo-SQL. Para obtener más información acerca de la opción `--verbose`, consulte [mysqlbinlog row event display](https://dev.mysql.com/doc/refman/8.0/en/mysqlbinlog-row-events.html) (Visualización de eventos de fila mysqlbinlog) en la documentación de MySQL.
+ Especifique los nombres de uno o varios de los archivos de registro binarios. Para obtener una lista de los registros disponibles, use el comando de SQL `SHOW BINARY LOGS`.
Para obtener más información acerca de las opciones de mysqlbinlog, consulte [mysqlbinlog - Utility for Processing Binary Log Files](https://dev.mysql.com/doc/refman/8.0/en/mysqlbinlog.html) (mysqlbinlog - Utilidad para procesar archivos de registro binarios) en la documentación de MySQL.
En los siguientes ejemplos, se muestra cómo utilizar la herramienta mysqlbinlog.
Para Linux, macOS o Unix:
```
mysqlbinlog \
--read-from-remote-server \
--host=MySQLInstance1.cg034hpkmmjt.region.rds.amazonaws.com \
--port=3306 \
--user ReplUser \
--password \
--raw \
--verbose \
--result-file=/tmp/ \
binlog.00098
```
Para Windows:
```
mysqlbinlog ^
--read-from-remote-server ^
--host=MySQLInstance1.cg034hpkmmjt.region.rds.amazonaws.com ^
--port=3306 ^
--user ReplUser ^
--password ^
--raw ^
--verbose ^
--result-file=/tmp/ ^
binlog.00098
```
Los registros binarios deben permanecer disponibles en la instancia de base de datos para que la utilidad mysqlbinlog pueda acceder a ellos. Para garantizar su disponibilidad, utilice el procedimiento [mysql.rds\$1set\$1configuration](mysql-stored-proc-configuring.md#mysql_rds_set_configuration) almacenado y especifique un periodo con tiempo suficiente para descargar los registros. Si esta configuración no está establecida, Amazon RDS purga los registros binarios lo antes posible, lo que genera huecos en los registros binarios que recupera la utilidad mysqlbinlog.
En el siguiente ejemplo se define el periodo de retención en 1 día.
```
call mysql.rds_set_configuration('binlog retention hours', 24);
```
Para mostrar el valor actual, utilice el procedimiento almacenado [mysql.rds\$1show\$1configuration](mysql-stored-proc-configuring.md#mysql_rds_show_configuration).
```
call mysql.rds_show_configuration;
```
# Archivos de registro de base de datos de Aurora PostgreSQL
Puede supervisar los siguientes tipos de archivos de registro de Aurora PostgreSQL:
+ Registro de PostgreSQL
+ Registro de instancias
+ Registro de errores de autenticación de base de datos de IAM
**nota**
Para habilitar los registros de errores de autenticación de base de datos de IAM, primero debe habilitar la autenticación de base de datos de IAM para el clúster de base de datos de Aurora PostgreSQL. Para obtener más información sobre la habilitación de la autenticación de bases de datos de IAM, consulte [Activación y desactivación de la autenticación de bases de datos de IAM](UsingWithRDS.IAMDBAuth.Enabling.md).
Aurora PostgreSQL registra las actividades de la base de datos en el archivo de registro de PostgreSQL predeterminado. En el caso de una instancia de base de datos de PostgreSQL en las instalaciones, estos mensajes se almacenan localmente en `log/postgresql.log`. Para un clúster de base de datos de Aurora PostgreSQL, el archivo de registro está disponible en el clúster de Aurora, . También puede acceder a estos registros a través de la Consola de administración de AWS, donde podrá verlos o descargarlos. El nivel de registro predeterminado captura los errores de inicio de sesión, los errores graves del servidor, los bloqueos y los errores de consulta.
Para obtener más información sobre cómo puede ver, descargar y observar los registros de la base de datos basados en archivos, consulte [Supervisión de archivos de registro de Amazon Aurora](USER_LogAccess.md). Para saber más sobre los registros de PostgreSQL, consulte [Trabajo con registros de Amazon RDS y Aurora PostgreSQL: parte 1](https://aws.amazon.com/blogs/database/working-with-rds-and-aurora-postgresql-logs-part-1/) y [ Trabajo con registros de Amazon RDS y Aurora PostgreSQL: parte 2](https://aws.amazon.com/blogs/database/working-with-rds-and-aurora-postgresql-logs-part-2/).
Además de los registros estándar de PostgreSQL que se describen en este tema, Aurora PostgreSQL también admite la extensión de auditoría de PostgreSQL (`pgAudit`). La mayoría de los sectores regulados y las agencias gubernamentales necesitan mantener un registro de auditoría o registro de auditoría de los cambios realizados en los datos para cumplir con los requisitos legales. Para obtener información acerca del modo de instalar y usar pgAudit, consulte [Uso de pgAudit para registrar la actividad de la base de datos](Appendix.PostgreSQL.CommonDBATasks.pgaudit.md).
Aurora crea un archivo de registro independiente para las instancias de base de datos que tienen la pausa automática habilitada. Este archivo instance.log registra cualquier motivo por el que estas instancias de base de datos no han podido pausarse cuando se esperaba. Para obtener más información sobre el comportamiento del archivo de registro de instancias y la capacidad de pausa automática de Aurora, consulte [Supervisión de la actividad de pausa y reanudación de Aurora sin servidor v2](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-serverless-v2-administration.html#autopause-logging-instance-log).
**Topics**
+ [Parámetros de registro en Aurora PostgreSQL](USER_LogAccess.Concepts.PostgreSQL.overview.parameter-groups.md)
+ [Activación de registro de consultas para su clúster de base de datos de Aurora PostgreSQL](USER_LogAccess.Concepts.PostgreSQL.Query_Logging.md)
# Parámetros de registro en Aurora PostgreSQL
Puede personalizar el comportamiento de registro de su clúster de base de datos de Aurora PostgreSQL modificando varios parámetros. En la siguiente tabla, puede encontrar los parámetros que afectan al tiempo que se almacenan los registros, cuándo se debe rotar el registro y si se debe generar el registro en formato CSV (valor separado por comas). También puede encontrar la salida de texto enviada a STDERR, entre otras configuraciones. Para cambiar la configuración de los parámetros que se pueden modificar, use un grupo de parámetros de clúster de base de datos personalizado para su clúster de base de datos de Aurora PostgreSQL. Para obtener más información, consulte [Grupos de parámetros para Amazon Aurora](USER_WorkingWithParamGroups.md).
| Parámetro | Predeterminado | Descripción |
| --- | --- | --- |
| log\$1destination | stderr | Establece el formato de salida para el registro. El valor predeterminado es `stderr`, pero también puede especificar un valor separado por comas (CSV) agregándolo `csvlog` al ajuste. Para obtener más información, consulte [Configuración del destino del registro (`stderr`, `csvlog`)](#USER_LogAccess.Concepts.PostgreSQL.Log_Format). |
| log\$1filename | postgresql.log.%Y-%m-%d-%H%M | Especifica el patrón del nombre del archivo de registro. Además del valor predeterminado, este parámetro admite `postgresql.log.%Y-%m-%d` y `postgresql.log.%Y-%m-%d-%H` para el patrón del nombre de archivo. Para Aurora PostgreSQL versión 17.4 y posteriores, no puede modificar este parámetro. |
| log\$1line\$1prefix | %t:%r:%u@%d:[%p]: | Define el prefijo de cada línea de registro que se escribe en `stderr`, para anotar la hora (%t), el host remoto (%r), el usuario (%u), la base de datos (%d) y el ID del proceso (%p). |
| log\$1rotation\$1age | 60 | Minutos después de los cuales el archivo de registro rota automáticamente. Puede cambiar este valor dentro del intervalo de 1 a 1440 minutos. Para obtener más información, consulte [Configuración de la rotación del archivo de registro](#USER_LogAccess.Concepts.PostgreSQL.log_rotation). |
| log\$1rotation\$1size | – | El tamaño (kB) con el que se rota automáticamente el registro. Puede cambiar este valor dentro del intervalo de 50 000 a 1 000 000 kilobytes. Para obtener más información, consulte [Configuración de la rotación del archivo de registro](#USER_LogAccess.Concepts.PostgreSQL.log_rotation). |
| rds.log\$1retention\$1period | 4320 | Los registros de PostgreSQL que superan el número de minutos especificado se eliminarán. El valor predeterminado de 4320 minutos elimina los archivos de registro transcurridos 3 días. Para obtener más información, consulte [Configuración de periodo de retención de registros](#USER_LogAccess.Concepts.PostgreSQL.log_retention_period). |
Para identificar problemas de aplicaciones, puede buscar errores de consulta, errores de inicio de sesión, interbloqueos y errores de servidor graves en el registro. Por ejemplo, suponga que ha convertido una aplicación heredada de Oracle a Aurora PostgreSQL, pero no todas las consultas se han convertido correctamente. Estas consultas con formato incorrecto generan mensajes de error que se pueden encontrar en los registros para ayudar a identificar los problemas. Para más información sobre el registro de consultas, consulte [Activación de registro de consultas para su clúster de base de datos de Aurora PostgreSQL ](USER_LogAccess.Concepts.PostgreSQL.Query_Logging.md).
En los temas siguientes, encontrará información sobre cómo configurar varios parámetros que controlan los detalles básicos de sus registros de PostgreSQL.
**Topics**
+ [Configuración de periodo de retención de registros](#USER_LogAccess.Concepts.PostgreSQL.log_retention_period)
+ [Configuración de la rotación del archivo de registro](#USER_LogAccess.Concepts.PostgreSQL.log_rotation)
+ [Configuración del destino del registro (`stderr`, `csvlog`)](#USER_LogAccess.Concepts.PostgreSQL.Log_Format)
+ [Descripción del parámetro log\$1line\$1prefix](#USER_LogAccess.Concepts.PostgreSQL.Log_Format.log-line-prefix)
## Configuración de periodo de retención de registros
El parámetro `rds.log_retention_period` especifica cuánto tiempo su clúster de base de datos de Aurora PostgreSQL mantiene sus archivos de registro. La configuración predeterminada es de 3 días (4320 minutos), pero puede configurarla entre 1 día (1440 minutos) y 7 días (10 080 minutos). Asegúrese de que su clúster de base de datos de Aurora PostgreSQL tenga suficiente almacenamiento para almacenar los archivos de registro durante ese período de tiempo.
Le recomendamos que publique sus registros de forma rutinaria en Registros de Amazon CloudWatch, de modo que pueda ver y analizar los datos del sistema mucho tiempo después de que los registros se hayan eliminado de su clúster de base de datos de Aurora PostgreSQL. Para obtener más información, consulte [Publicación de registros de Aurora PostgreSQL en Amazon CloudWatch Logs](AuroraPostgreSQL.CloudWatch.md). Después de configurar la publicación en CloudWatch, Aurora no elimina un registro hasta que se publique en CloudWatch Logs.
Amazon Aurora comprime los registros de PostgreSQL más antiguos cuando el almacenamiento de la instancia de base de datos alcanza un umbral. Aurora comprime los archivos mediante la utilidad de compresión gzip. Para obtener más información, consulte el sitio web de [gzip](https://www.gzip.org).
Cuando el almacenamiento para la instancia de base de datos es bajo y se comprimen todos los registros disponibles, se obtiene una advertencia como la siguiente:
```
Warning: local storage for PostgreSQL log files is critically low for
this Aurora PostgreSQL instance, and could lead to a database outage.
```
Si no hay suficiente almacenamiento, Aurora podría eliminar los registros comprimidos de PostgreSQL antes de que finalice el período de retención especificado. Si eso sucede, verá un mensaje parecido al siguiente:
```
The oldest PostgreSQL log files were deleted due to local storage constraints.
```
## Configuración de la rotación del archivo de registro
Aurora crea los nuevos archivos de registro cada hora de forma predeterminada. El tiempo lo controla el parámetro `log_rotation_age`. Este parámetro tiene un valor predeterminado de 60 (minutos), pero puede configurarlo entre 1 minuto y 24 horas (1440 minutos). Cuando llega el momento de la rotación, se crea un nuevo archivo de registro distinto. Al archivo se le asigna un nombre de conformidad con el patrón especificado por el parámetro `log_filename`.
Los archivos de registro también se pueden rotar según su tamaño, tal y como se especifica en el parámetro `log_rotation_size`. Este parámetro especifica que el registro debe rotarse cuando alcance el tamaño especificado (en kilobytes). El `log_rotation_size` predeterminado es de 100 000 kB (kilobytes) para un clúster de base de datos de Aurora PostgreSQL, pero puede establecer en cualquier valor desde 50 000 hasta 1 000 000 de kilobytes.
Los nombres de archivo de registro se basan en el patrón de nombre de archivo especificado en el parámetro `log_filename`. La configuración disponible para este parámetro es la siguiente:
+ `postgresql.log.%Y-%m-%d`: formato predeterminado para el nombre del archivo de registro. Incluye el año, el mes y la fecha en el nombre del archivo de registro.
+ `postgresql.log.%Y-%m-%d-%H`: incluye la hora en el formato del nombre del archivo de registro.
+ `postgresql.log.%Y-%m-%d-%H%M`: incluye la hora:minuto en el formato del nombre del archivo de registro.
Si establece el parámetro `log_rotation_age` en menos de 60 minutos, establezca el parámetro `log_filename` en el formato de minutos.
Para obtener más información, consulte [https://www.postgresql.org/docs/current/runtime-config-logging.html#GUC-LOG-ROTATION-AGE](https://www.postgresql.org/docs/current/runtime-config-logging.html#GUC-LOG-ROTATION-AGE) y [https://www.postgresql.org/docs/current/runtime-config-logging.html#GUC-LOG-ROTATION-SIZE](https://www.postgresql.org/docs/current/runtime-config-logging.html#GUC-LOG-ROTATION-SIZE) en la documentación de PostgreSQL.
## Configuración del destino del registro (`stderr`, `csvlog`)
De forma predeterminada, Aurora PostgreSQL genera registros en formato de error estándar (stderr). Esta es la configuración predeterminada del parámetro `log_destination`. Cada mensaje lleva el prefijo según el patrón especificado en el parámetro `log_line_prefix`. Para obtener más información, consulte [Descripción del parámetro log\$1line\$1prefix](#USER_LogAccess.Concepts.PostgreSQL.Log_Format.log-line-prefix).
Aurora PostgreSQL también puede generar los registros con el formato `csvlog`. `csvlog` resulta útil para analizar los datos de registro como valores separados con coma (CSV). Por ejemplo, supongamos que utiliza la extensión `log_fdw` para trabajar con los registros como tablas extranjeras. La tabla extranjera creada en los archivos de registro `stderr` contienen una sola columna con datos de eventos de registro. Al añadir `csvlog` al parámetro `log_destination`, se obtiene el archivo de registro en formato CSV con demarcaciones para las múltiples columnas de la tabla externa. Esto le permite ordenar y analizar los registros con mayor facilidad.
Si especifica `csvlog` para este parámetro, tenga en cuenta que se generan los archivos `stderr` y `csvlog`. Asegúrese de supervisar el almacenamiento consumido por los registros, teniendo en cuenta `rds.log_retention_period` y otras configuraciones que afectan al almacenamiento de registros y a los análisis. Usar `stderr` y `csvlog` duplica de sobra el almacenamiento consumido por los registros.
Si añade `csvlog` a `log_destination` y quiere volver solo a `stderr` solo, debe restablecer el parámetro. Para ello, utilice la consola de Amazon RDS y abra el grupo de parámetros del clúster de base de datos personalizado para su instancia. Elija el parámetro `log_destination`, elija **Edit parameter** (Editar parámetro) y, a continuación, seleccione **Reset** (Restablecer).
Para obtener más información acerca de la configuración de los registros, consulte la entrada del blog sobre [trabajar con registros de Amazon RDS y Aurora PostgreSQL: parte 1](https://aws.amazon.com/blogs/database/working-with-rds-and-aurora-postgresql-logs-part-1/).
## Descripción del parámetro log\$1line\$1prefix
El formato de registro de `stderr` prefija cada mensaje de registro con los detalles especificados por el parámetro `log_line_prefix`. El valor predeterminado es:
```
%t:%r:%u@%d:[%p]:t
```
A partir de la versión 16 de Aurora PostgreSQL, también puede elegir:
```
%m:%r:%u@%d:[%p]:%l:%e:%s:%v:%x:%c:%q%a
```
Cada entrada de registro enviada a stderr incluye la siguiente información en función del valor seleccionado:
+ `%t`: hora de entrada del registro sin milisegundos
+ `%m`: hora de entrada del registro con milisegundos
+ `%r`: dirección del host remoto.
+ `%u@%d`: nombre de usuario @ nombre de base de datos.
+ `[%p]`: ID del proceso si está disponible.
+ `%l`: Número de línea de registro por sesión
+ `%e`: Código de error SQL
+ `%s`: Marca temporal de inicio de proceso
+ `%v`: ID de transacción virtual
+ `%x`: ID de transacción
+ `%c`: ID de sesión
+ `%q`: Terminador que no sea de sesión
+ `%a`: Nombre de la aplicación
# Activación de registro de consultas para su clúster de base de datos de Aurora PostgreSQL
Puede recopilar información más detallada sobre las actividades de la base de datos, incluidas las consultas, las consultas en espera de bloqueos, los puntos de control y muchos otros detalles configurando algunos de los parámetros que se enumeran en la tabla siguiente. Este tema se centra en el registro de consultas.
| Parámetro | Predeterminado | Descripción |
| --- | --- | --- |
| log\$1connections | – | Registra cada conexión realizada correctamente. Para obtener información sobre cómo utilizar este parámetro con `log_disconnections` para detectar la pérdida de conexiones, consulte [Administración de la pérdida de conexión de Aurora PostgreSQL con agrupación](AuroraPostgreSQL.BestPractices.connection_pooling.md). |
| log\$1disconnections | – | Registra el final de cada sesión y su duración. Para obtener información sobre cómo utilizar este parámetro con `log_connections` para detectar la pérdida de conexiones, consulte [Administración de la pérdida de conexión de Aurora PostgreSQL con agrupación](AuroraPostgreSQL.BestPractices.connection_pooling.md). |
| log\$1checkpoints | : | No se aplica a Aurora PostgreSQL |
| log\$1lock\$1waits | – | Registra las esperas de bloqueo largas. Por defecto, este parámetro no está configurado. |
| log\$1min\$1duration\$1sample | – | (ms) Establece el tiempo mínimo de ejecución a partir del cual se registra una muestra de instrucciones. El tamaño de la muestra se establece mediante el parámetro log\$1statement\$1sample\$1rate. |
| log\$1min\$1duration\$1statement | – | Se registra cualquier instrucción SQL que se ejecute al menos durante el período de tiempo especificado o durante más tiempo. Por defecto, este parámetro no está configurado. Si se activa este parámetro, puede resultar más sencillo encontrar consultas no optimizadas. |
| log\$1statement | – | Define el tipo de declaraciones que se deben registrar. De forma predeterminada, este parámetro no está configurado, pero puede cambiarlo a `all`, `ddl` o `mod` para especificar los tipos de instrucciones SQL que desea que se registren. Si especifica algo que no sea `none` para este parámetro, también debe adoptar medidas adicionales para evitar que las contraseñas aparezcan en los archivos de registro. Para obtener más información, consulte [Mitigar el riesgo de exposición de contraseñas al utilizar el registro de consultasMitigar el riesgo de exposición de contraseñas](#USER_LogAccess.Concepts.PostgreSQL.Query_Logging.mitigate-risk). |
| log\$1statement\$1sample\$1rate | – | El porcentaje de sentencias que superan el tiempo especificado en `log_min_duration_sample` se registrarán, expresado como un valor de coma flotante entre 0.0 y 1.0. |
| log\$1statement\$1stats | – | Escribe las estadísticas de rendimiento acumulativas en el registro del servidor. |
## Uso del registro para encontrar consultas con un rendimiento lento
Puede registrar instrucciones y consultas SQL para ayudar a encontrar consultas que se den con resultados lentos. Para activar esta función, modifique la configuración de los parámetros `log_statement` y `log_min_duration`, tal como se describe en esta sección. Antes de activar el registro de consultas para su clúster de base de datos de Aurora PostgreSQL, debe conocer la posible exposición de contraseñas en los registros y cómo mitigar los riesgos. Para obtener más información, consulte [Mitigar el riesgo de exposición de contraseñas al utilizar el registro de consultasMitigar el riesgo de exposición de contraseñas](#USER_LogAccess.Concepts.PostgreSQL.Query_Logging.mitigate-risk).
A continuación, encontrará información de referencia sobre los parámetros `log_statement` y `log_min_duration`.log\$1statement
Este parámetro especifica el tipo de instrucciones SQL que deben enviarse al registro. El valor predeterminado es `none`. Si cambia este parámetro a `all`, `ddl` o `mod`, asegúrese de aplicar algunas de las medidas recomendadas para reducir el riesgo de exponer las contraseñas en los registros. Para obtener más información, consulte [Mitigar el riesgo de exposición de contraseñas al utilizar el registro de consultasMitigar el riesgo de exposición de contraseñas](#USER_LogAccess.Concepts.PostgreSQL.Query_Logging.mitigate-risk).
**all**
Registra todas las instrucciones. Para depuración, se recomienda esta configuración.
**ddl**
Registra todas las instrucciones del lenguaje de definición de datos (DDL), como CREATE, ALTER, DROP, etc.
**MOD**
Registra todas las instrucciones DDL y las instrucciones de lenguaje de manipulación de datos (DML), como INSERT, UPDATE y DELETE, que modifican los datos.
**none**
No se registra ninguna instrucción SQL. Recomendamos esta configuración para evitar el riesgo de exponer las contraseñas en los registros.log\$1min\$1duration\$1statement
Se registra cualquier instrucción SQL que se ejecute al menos durante el período de tiempo especificado o durante más tiempo. Por defecto, este parámetro no está configurado. Si se activa este parámetro, puede resultar más sencillo encontrar consultas no optimizadas.
**–1–2147483647**
El número de milisegundos (ms) de tiempo de ejecución durante los cuales se registra una instrucción.
**Para configurar el registro de consultas**
Estos pasos suponen que su clúster de base de datos de Aurora PostgreSQL utiliza un grupo de parámetros del clúster de base de datos personalizado.
1. Establezca el parámetro `log_statement` como `all`. En el siguiente ejemplo se muestra la información que se escribe en el archivo con esta configuración de parámetros.
```
2022-10-05 22:05:52 UTC:52.95.4.1(11335):postgres@labdb:[3639]:LOG: statement: SELECT feedback, s.sentiment,s.confidence
FROM support,aws_comprehend.detect_sentiment(feedback, 'en') s
ORDER BY s.confidence DESC;
2022-10-05 22:05:52 UTC:52.95.4.1(11335):postgres@labdb:[3639]:LOG: QUERY STATISTICS
2022-10-05 22:05:52 UTC:52.95.4.1(11335):postgres@labdb:[3639]:DETAIL: ! system usage stats:
! 0.017355 s user, 0.000000 s system, 0.168593 s elapsed
! [0.025146 s user, 0.000000 s system total]
! 36644 kB max resident size
! 0/8 [0/8] filesystem blocks in/out
! 0/733 [0/1364] page faults/reclaims, 0 [0] swaps
! 0 [0] signals rcvd, 0/0 [0/0] messages rcvd/sent
! 19/0 [27/0] voluntary/involuntary context switches
2022-10-05 22:05:52 UTC:52.95.4.1(11335):postgres@labdb:[3639]:STATEMENT: SELECT feedback, s.sentiment,s.confidence
FROM support,aws_comprehend.detect_sentiment(feedback, 'en') s
ORDER BY s.confidence DESC;
2022-10-05 22:05:56 UTC:52.95.4.1(11335):postgres@labdb:[3639]:ERROR: syntax error at or near "ORDER" at character 1
2022-10-05 22:05:56 UTC:52.95.4.1(11335):postgres@labdb:[3639]:STATEMENT: ORDER BY s.confidence DESC;
----------------------- END OF LOG ----------------------
```
1. Establezca el parámetro `log_min_duration_statement`. En el siguiente ejemplo se muestra la información que se escribe en el archivo `postgresql.log`cuando se establece el parámetro en:`1`
Se registran las consultas que superan la duración especificada en el parámetro `log_min_duration_statement`. A continuación se muestra un ejemplo. Puede ver el archivo de registro de su clúster de base de datos de Aurora PostgreSQL en la consola de Amazon RDS.
```
2022-10-05 19:05:19 UTC:52.95.4.1(6461):postgres@labdb:[6144]:LOG: statement: DROP table comments;
2022-10-05 19:05:19 UTC:52.95.4.1(6461):postgres@labdb:[6144]:LOG: duration: 167.754 ms
2022-10-05 19:08:07 UTC::@:[355]:LOG: checkpoint starting: time
2022-10-05 19:08:08 UTC::@:[355]:LOG: checkpoint complete: wrote 11 buffers (0.0%); 0 WAL file(s) added, 0 removed, 0 recycled; write=1.013 s, sync=0.006 s, total=1.033 s; sync files=8, longest=0.004 s, average=0.001 s; distance=131028 kB, estimate=131028 kB
----------------------- END OF LOG ----------------------
```
### Mitigar el riesgo de exposición de contraseñas al utilizar el registro de consultas
Le recomendamos que mantenga `log_statement` establecido en `none` para evitar exponer las contraseñas. Si establece `log_statement` en `all`, `ddl` o `mod`, le recomendamos que siga uno o más de los siguientes pasos.
+ Para el cliente, cifre la información confidencial. Para obtener más información, consulte [Encryption Options](https://www.postgresql.org/docs/current/encryption-options.html) en la documentación de PostgreSQL. Utilice las opciones `ENCRYPTED` (y `UNENCRYPTED`) de las instrucciones `CREATE` y `ALTER`. Para obtener más información, consulte [CREATE USER](https://www.postgresql.org/docs/current/sql-createuser.html) en la documentación de PostgreSQL.
+ Para su clúster de base de datos de Aurora PostgreSQL, configure y utilice la extensión de auditoría de PostgreSQL (pgAudit). Esta extensión redacta la información confidencial de las instrucciones CREATE y ALTER enviadas al registro. Para obtener más información, consulte [Uso de pgAudit para registrar la actividad de la base de datos](Appendix.PostgreSQL.CommonDBATasks.pgaudit.md).
+ Restrinja el acceso a los Registros de CloudWatch.
+ Utilice mecanismos de autenticación más sólidos como IAM.