^
--result-file=/tmp/binlog.txt
```
Normalmente, o Amazon RDS limpa um log binário o mais rápido possível. No entanto, o log binário ainda deve estar disponível na instância para ser acessado por mysqlbinlog. Para especificar o número de horas durante as quais o RDS vai reter os logs binários, use o procedimento armazenado `mysql.rds_set_configuration`. Especifique um período com tempo suficiente para baixar os logs. Após configurar o período de retenção, monitore o uso de armazenamento da instância de banco de dados para garantir que os logs binários retidos não consumam muito armazenamento.
O exemplo a seguir define o período de retenção como 1 dia.
```
call mysql.rds_set_configuration('binlog retention hours', 24);
```
Para exibir a configuração atual, use o procedimento armazenado `mysql.rds_show_configuration`.
```
call mysql.rds_show_configuration;
```
# Habilitar a anotação de log binário do MariaDB
Em uma instância de banco de dados MariaDB, você pode usar o evento `Annotate_rows` para anotar um evento de linha com uma cópia da consulta SQL que causou esse evento de linha. Essa abordagem fornece funcionalidade semelhante para habilitar o parâmetro `binlog_rows_query_log_events` em uma instância de banco de dados do RDS para MySQL.
Você pode habilitar anotações de logs binários globalmente criando um grupo de parâmetros personalizado e definindo o parâmetro `binlog_annotate_row_events` como **1**. Você também pode habilitar anotações em nível de sessão, chamando `SET SESSION binlog_annotate_row_events = 1`. Use a opção `replicate_annotate_row_events` para replicar anotações de logs binários para a instância de réplica se o registro em log binário estiver habilitado nela. Não são necessários privilégios especiais para usar essas configurações.
A seguir está um exemplo de uma transação com base em linha no MariaDB. O uso do registro em log baseado em fila é acionado definindo o nível de isolamento da transação como confirmado na leitura.
```
CREATE DATABASE IF NOT EXISTS test;
USE test;
CREATE TABLE square(x INT PRIMARY KEY, y INT NOT NULL) ENGINE = InnoDB;
SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;
BEGIN
INSERT INTO square(x, y) VALUES(5, 5 * 5);
COMMIT;
```
Sem anotações, as entradas de logs binários para a transação são as seguintes:
```
BEGIN
/*!*/;
# at 1163
# at 1209
#150922 7:55:57 server id 1855786460 end_log_pos 1209 Table_map: `test`.`square` mapped to number 76
#150922 7:55:57 server id 1855786460 end_log_pos 1247 Write_rows: table id 76 flags: STMT_END_F
### INSERT INTO `test`.`square`
### SET
### @1=5
### @2=25
# at 1247
#150922 7:56:01 server id 1855786460 end_log_pos 1274 Xid = 62
COMMIT/*!*/;
```
A seguinte instrução permite anotações em nível de sessão para essa mesma transação e as desabilita em seguida confirmando a transação:
```
CREATE DATABASE IF NOT EXISTS test;
USE test;
CREATE TABLE square(x INT PRIMARY KEY, y INT NOT NULL) ENGINE = InnoDB;
SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;
SET SESSION binlog_annotate_row_events = 1;
BEGIN;
INSERT INTO square(x, y) VALUES(5, 5 * 5);
COMMIT;
SET SESSION binlog_annotate_row_events = 0;
```
Com anotações, as entradas de logs binários para a transação são as seguintes:
```
BEGIN
/*!*/;
# at 423
# at 483
# at 529
#150922 8:04:24 server id 1855786460 end_log_pos 483 Annotate_rows:
#Q> INSERT INTO square(x, y) VALUES(5, 5 * 5)
#150922 8:04:24 server id 1855786460 end_log_pos 529 Table_map: `test`.`square` mapped to number 76
#150922 8:04:24 server id 1855786460 end_log_pos 567 Write_rows: table id 76 flags: STMT_END_F
### INSERT INTO `test`.`square`
### SET
### @1=5
### @2=25
# at 567
#150922 8:04:26 server id 1855786460 end_log_pos 594 Xid = 88
COMMIT/*!*/;
```
# Arquivos de log do banco de dados do Amazon RDS para Microsoft SQL Server
Você pode acessar os logs de erros, logs de agentes, arquivos de rastreamento e arquivos de despejo do Microsoft SQL Server usando o console do Amazon RDS, a AWS CLI ou a API do RDS. Para mais informações sobre a visualização, o download e os logs de bancos de dados baseados no monitoramento de arquivos, consulte [Monitorar arquivos de log do Amazon RDS](USER_LogAccess.md).
## Cronograma de retenção
Os arquivos de log são revezados a cada dia e sempre que sua instância de banco de dados for reiniciada. A seguir você encontra o cronograma de retenção para logs do Microsoft SQL Server no Amazon RDS.
****
| Tipo de log | Cronograma de retenção |
| --- | --- |
| Logs de erro | No máximo, 30 logs de erros são retidos. O Amazon RDS pode excluir logs de erros com mais de 7 dias. |
| Logs de agente | No máximo, 10 logs de agente são retidos. O Amazon RDS pode excluir logs de agente com mais de 7 dias. |
| Arquivos de rastreamento | Os arquivos de rastreamento são mantidos de acordo com o período de retenção de arquivos de rastreamento de sua instância de banco de dados. O período de retenção padrão de arquivos de rastreamento é de 7 dias. Para modificar o período de retenção de arquivos de rastreamento de sua instância de banco de dados, consulte [Como definir o período de retenção para arquivos de rastreamento e despejo](Appendix.SQLServer.CommonDBATasks.TraceFiles.md#Appendix.SQLServer.CommonDBATasks.TraceFiles.PurgeTraceFiles). |
| Arquivos de despejo | Os arquivos de despejo são mantidos de acordo com o período de retenção de arquivos de despejo de sua instância de banco de dados. O período de retenção padrão de arquivos de despejo é de 7 dias. Para modificar o período de retenção de arquivos de despejo de sua instância de banco de dados, consulte [Como definir o período de retenção para arquivos de rastreamento e despejo](Appendix.SQLServer.CommonDBATasks.TraceFiles.md#Appendix.SQLServer.CommonDBATasks.TraceFiles.PurgeTraceFiles). |
## Visualizar o log de erros do SQL Server usando o procedimento rds\$1read\$1error\$1log
Você pode usar o procedimento armazenado `rds_read_error_log` do Amazon RDS para visualizar logs de erros e logs de agente. Para obter mais informações, consulte [Visualizar logs do agente ou erros](Appendix.SQLServer.CommonDBATasks.Logs.md#Appendix.SQLServer.CommonDBATasks.Logs.SP).
## Publicar logs do SQL Server no Amazon CloudWatch Logs
Com o Amazon RDS para SQL Server, você pode publicar eventos de log de erros e de agentes diretamente no Amazon CloudWatch Logs. Analise os dados de logs com o CloudWatch Logs e depois use o CloudWatch para criar alarmes e visualizar métricas.
Com o CloudWatch Logs, você pode fazer o seguinte:
+ Armazene os logs em um espaço de armazenamento resiliente e com um período de retenção definido por você.
+ Pesquisar e filtrar dados de log.
+ Compartilhar dados de log entre contas.
+ Exportar logs para o Amazon S3.
+ Faça uma transmissão de dados para o Amazon OpenSearch Service.
+ Processar dados de log em tempo real com o Amazon Kinesis Data Streams. Para obter mais informações, consulte [Trabalhando com o Amazon CloudWatch Logs](https://docs.aws.amazon.com/kinesisanalytics/latest/dev/cloudwatch-logs.html), no *Guia do desenvolvedor do Amazon Kinesis Data Analytics para aplicativos SQL*.
O Amazon RDS publica cada log de banco de dados SQL Server como um fluxo separado de banco de dados no grupo de logs. Por exemplo, se você publicar os logs de erro e os logs do agente, os dados de erro serão armazenados em um fluxo de logs de erros no grupo de logs `/aws/rds/instance/my_instance.node1/error`, e os dados de log do agente serão armazenados no grupo de logs `/aws/rds/instance/my_instance.node1/agent`.
Para instâncias de banco de dados multi-AZ, o Amazon RDS publica o log do banco de dados como dois fluxos separados no grupo de logs. Por exemplo, se você publicar logs de erro, os dados de erro serão armazenados nos fluxos de log de erros `/aws/rds/instance/my_instance.node1/error` e `/aws/rds/instance/my_instance.node2/error` respectivamente. Os fluxos de log não mudam durante um failover e o fluxo de logs de erros de cada nó pode conter logs de erros da instância primária ou secundária. Com o multi-AZ, um fluxo de logs é criado automaticamente para `/aws/rds/instance/my_instance/rds-events` para armazenar dados de eventos, como failovers de instâncias de banco de dados.
**nota**
A publicação de logs do SQL Server no CloudWatch Logs não está habilitada por padrão. Não há suporte para a publicação de arquivos de rastreamento e despejo. A publicação de logs do SQL Server no CloudWatch Logs é aceita em todas as regiões.
### Console
**Para publicar logs de banco de dados do SQL Server no CloudWatch Logs a partir do Console de gerenciamento da AWS**
1. Abra o console do Amazon RDS em [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. No painel de navegação, escolha **Databases (Bancos de dados)** e a instância de banco de dados que você deseja modificar.
1. Selecione **Modify**.
1. Na seção **Log exports (Exportações de log)**, escolha os logs que deseja começar a publicar no CloudWatch Logs.
Você pode escolher **Agent log (Log do agente)**, **Error log (Log de erros)** ou ambos.
1. Escolha **Continue (Continuar)** e depois escolha **Modify DB Instance (Modificar instância de banco de dados)** na página de resumo.
### AWS CLI
Para publicar os logs do SQL Server, você pode usar o comando [https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html) com os seguintes parâmetros:
+ `--db-instance-identifier`
+ `--cloudwatch-logs-export-configuration`
**nota**
Uma alteração feita na opção `--cloudwatch-logs-export-configuration` sempre é aplicada imediatamente na instância de banco de dados. Por isso, as opções `--apply-immediately` e `--no-apply-immediately` não entram em vigor.
Você também pode publicar logs da SQL Server usando os seguintes comandos:
+ [https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html)
+ [https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-from-db-snapshot.html](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-from-db-snapshot.html)
+ [https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-to-point-in-time.html](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-to-point-in-time.html)
**Example**
O exemplo a seguir cria uma instância de banco de dados SQL Server com a publicação no CloudWatch Logs habilitada. O valor `--enable-cloudwatch-logs-exports` é uma matriz JSON de strings que podem incluir `error`, `agent` ou ambos.
Para Linux, macOS ou Unix:
```
aws rds create-db-instance \
--db-instance-identifier mydbinstance \
--enable-cloudwatch-logs-exports '["error","agent"]' \
--db-instance-class db.m4.large \
--engine sqlserver-se
```
Para Windows:
```
aws rds create-db-instance ^
--db-instance-identifier mydbinstance ^
--enable-cloudwatch-logs-exports "[\"error\",\"agent\"]" ^
--db-instance-class db.m4.large ^
--engine sqlserver-se
```
Ao usar o prompt de comando do Windows, você deve fazer o escape das aspas duplas (") no código JSON, prefixando-as com uma barra invertida (\$1).
**Example**
O exemplo a seguir altera uma instância de banco de dados SQL Server existente para publicar os arquivos de log no CloudWatch Logs. O valor `--cloudwatch-logs-export-configuration` é um objeto JSON. A chave desse objeto é `EnableLogTypes`, e seu valor é uma matriz de strings que pode incluir `error`, `agent` ou ambos.
Para Linux, macOS ou Unix:
```
aws rds modify-db-instance \
--db-instance-identifier mydbinstance \
--cloudwatch-logs-export-configuration '{"EnableLogTypes":["error","agent"]}'
```
Para Windows:
```
aws rds modify-db-instance ^
--db-instance-identifier mydbinstance ^
--cloudwatch-logs-export-configuration "{\"EnableLogTypes\":[\"error\",\"agent\"]}"
```
Ao usar o prompt de comando do Windows, você deve fazer o escape das aspas duplas (") no código JSON, prefixando-as com uma barra invertida (\$1).
**Example**
O exemplo a seguir altera uma instância de banco de dados SQL Server existente para desabilitar a publicação de arquivos de log do agente no CloudWatch Logs. O valor `--cloudwatch-logs-export-configuration` é um objeto JSON. A chave desse objeto é `DisableLogTypes`, e seu valor é uma matriz de strings que pode incluir `error`, `agent` ou ambos.
Para Linux, macOS ou Unix:
```
aws rds modify-db-instance \
--db-instance-identifier mydbinstance \
--cloudwatch-logs-export-configuration '{"DisableLogTypes":["agent"]}'
```
Para Windows:
```
aws rds modify-db-instance ^
--db-instance-identifier mydbinstance ^
--cloudwatch-logs-export-configuration "{\"DisableLogTypes\":[\"agent\"]}"
```
Ao usar o prompt de comando do Windows, você deve fazer o escape das aspas duplas (") no código JSON, prefixando-as com uma barra invertida (\$1).
# Arquivos de log do banco de dados MySQL
Você pode monitorar os logs do MySQL diretamente por meio do console do Amazon RDS, da API do Amazon RDS, da AWS CLI ou dos SDKs da AWS. Você também pode acessar os logs do MySQL direcionando os logs para uma tabela de banco de dados no banco de dados primário e consultando essa tabela. Você pode usar o utilitário mysqlbinlog para baixar um log de binários.
Para mais informações sobre a visualização, o download e os logs de bancos de dados baseados no monitoramento de arquivos, consulte [Monitorar arquivos de log do Amazon RDS](USER_LogAccess.md).
**Topics**
+ [Visão geral dos logs de banco de dados do RDS para MySQL](USER_LogAccess.MySQL.LogFileSize.md)
+ [Publicação de logs do MySQL no Amazon CloudWatch Logs](USER_LogAccess.MySQLDB.PublishtoCloudWatchLogs.md)
+ [Enviar a saída de log do MySQL para tabelas](Appendix.MySQL.CommonDBATasks.Logs.md)
+ [Configurar o registro em log binário do RDS para MySQL para bancos de dados single-AZ](USER_LogAccess.MySQL.BinaryFormat.md)
+ [Configuração do registro em log binário do MySQL para clusters de banco de dados multi-AZ](USER_Binlog.MultiAZ.md)
+ [Acessar logs binários do MySQL](USER_LogAccess.MySQL.Binarylog.md)
# Visão geral dos logs de banco de dados do RDS para MySQL
Você pode monitorar os seguintes tipos de arquivos de log do RDS para MySQL:
+ Log de erros
+ Log de consultas lentas
+ Log geral
+ Log de auditoria
+ Log de instância
+ Log de erros de autenticação de banco de dados do IAM
O log de erros do RDS para MySQL é gerado por padrão. Você pode gerar a consulta lenta e os logs gerais definindo parâmetros no seu grupo de parâmetros do banco de dados.
**Topics**
+ [Logs de erro do RDS para MySQL](#USER_LogAccess.MySQL.Errorlog)
+ [Logs gerais e de consultas lentas do RDS para MySQL](#USER_LogAccess.MySQL.Generallog)
+ [Log de auditoria do MySQL](#USER_LogAccess.MySQL.Auditlog)
+ [Alternância e retenção de logs do RDS para MySQL](#USER_LogAccess.MySQL.LogFileSize.retention)
+ [Limites de tamanho em redo logs](#USER_LogAccess.MySQL.LogFileSize.RedoLogs)
## Logs de erro do RDS para MySQL
O RDS para MySQL grava erros no arquivo `mysql-error.log`. Cada arquivo de log tem a hora em que foi gerado (em UTC) anexada ao seu nome. Os arquivos de log também possuem um carimbo de data/hora que ajuda você a determinar quando as entradas de log foram gravadas.
O RDS para MySQL grava no log de erros apenas na inicialização, no desligamento e quando encontra erros. Uma instância de banco de dados pode passar horas ou dias sem novas entradas gravadas no log de erros. Se você não vir nenhuma entrada recente, é porque o servidor não encontrou nenhum erro que tenha gerado uma entrada de log.
Por padrão, os logs de erros são filtrados para que apenas eventos inesperados, como erros, sejam exibidos. No entanto, os logs de erros também contêm algumas informações adicionais do banco de dados, por exemplo, o andamento da consulta, que não são mostradas. Portanto, mesmo sem erros reais, o tamanho dos logs de erros pode aumentar devido às atividades em andamento do banco de dados. Embora você possa ver determinado tamanho em bytes ou quilobytes para os logs de erros no Console de gerenciamento da AWS, eles poderão ter 0 byte quando você fizer download deles.
O RDS para MySQL grava o `mysql-error.log` no disco a cada cinco minutos. Ele acrescenta o conteúdo do log ao `mysql-error-running.log`.
O RDS para MySQL alterna o arquivo `mysql-error-running.log` de hora em hora. Ele retém os logs gerados durante as últimas duas semanas.
**nota**
Observe que o período de retenção é diferente entre o Amazon RDS e o Aurora.
## Logs gerais e de consultas lentas do RDS para MySQL
É possível gravar o log de consultas lentas e o log geral do RDS para MySQL em um arquivo ou em uma tabela de banco de dados. Para isso, defina parâmetros em seu grupo de parâmetros de banco de dados. Para obter informações sobre como criar e modificar um grupo de parâmetros de banco de dados, consulte [Grupos de parâmetros para Amazon RDS](USER_WorkingWithParamGroups.md). Você deve definir esses parâmetros antes de visualizar o log de consultas lentas ou o log geral no console do Amazon RDS ou usando a API do Amazon RDS, a CLI do Amazon RDS ou os SDKs da AWS.
Você pode controlar o registro em log do RDS para MySQL usando os parâmetros nesta lista:
+ `slow_query_log`: para criar o log de consultas lentas, defina como 1. O padrão é 0.
+ `general_log`: para criar o log geral, defina como 1. O padrão é 0.
+ `long_query_time`: para evitar que as consultas de execução rápida sejam registradas no log de consultas lentas, especifique um valor para o tempo de execução de consultas mais curto a ser registrado, em segundos. O padrão é 10 segundos; o mínimo é 0. Se log\$1output = FILE, você poderá especificar um valor de ponto flutuante com resolução por microssegundo. Se log\$1output = TABLE, você deverá especificar um valor inteiro com a segunda resolução. Apenas as consultas cujo tempo de execução excede o valor `long_query_time` são registradas em log. Por exemplo, definir `long_query_time` como 0.1 impede que qualquer consulta que seja executada por menos de 100 milissegundos seja registrada.
+ `log_queries_not_using_indexes`: para registrar todas as consultas que não usam um índice no log de consultas lentas, defina como 1. As consultas que não usam um índice são registradas, mesmo que seu tempo de execução seja inferior ao valor do parâmetro `long_query_time`. O padrão é 0.
+ `log_output option`: você pode especificar uma das seguintes opções para o parâmetro `log_output`.
+ **TABLE** (padrão): grava consultas gerais na tabela `mysql.general_log` e consultas lentas na tabela `mysql.slow_log`.
+ **FILE**: grave logs de consultas gerais e lentas no sistema de arquivos.
+ **NONE**: desabilite o registro em log.
Para que dados de consulta lenta apareçam no Amazon CloudWatch Logs, as seguintes condições devem ser atendidas:
+ O CloudWatch Logs deve ser configurado para incluir logs de consultas lentas.
+ `slow_query_log` deve estar habilitado.
+ `log_output` deve ser definido como `FILE`.
+ A consulta deve demorar mais do que o tempo configurado para `long_query_time`.
Para obter mais informações sobre os log de consultas gerais e de consultas lentas, acesse os seguintes tópicos na documentação do MySQL:
+ [O log de consultas lentas](https://dev.mysql.com/doc/refman/8.0/en/slow-query-log.html)
+ [O log de consultas gerais](https://dev.mysql.com/doc/refman/8.0/en/query-log.html)
## Log de auditoria do MySQL
Para acessar o log de auditoria, a instância de banco de dados deve usar um grupo de opções personalizado com a opção `MARIADB_AUDIT_PLUGIN`. Para obter mais informações, consulte [Suporte ao plug-in de auditoria do MariaDB para MySQL](Appendix.MySQL.Options.AuditPlugin.md).
## Alternância e retenção de logs do RDS para MySQL
Quando o registro em log está habilitado, o Amazon RDS faz o rodízio de logs de tabelas ou exclui arquivos de log em intervalos regulares. Essa medida é uma precaução para reduzir a possibilidade de um arquivo de log grande bloquear o uso do banco de dados ou afetar o desempenho. O RDS para MySQL lida com a alternância e a exclusão da seguinte forma:
+ Os tamanhos de arquivo do log de consultas lentas, do log de erros e do log geral do MySQL são restritos a não mais de 2% do espaço de armazenamento alocado para uma instância de banco de dados. Para manter esse limite, os logs são alternados automaticamente a cada hora. O MySQL remove arquivos de log criados há mais de duas semanas. Se o tamanho do arquivo de log combinado exceder o limite após a remoção dos arquivos de log antigos, os arquivos de log mais antigos serão excluídos até o tamanho do arquivo de log deixar de exceder esse limite.
+ Quando o registro em log `FILE` é ativado, os arquivos de log são examinados a cada hora e os arquivos de log com mais de duas semanas são excluídos. Em alguns casos, o tamanho do arquivo de log combinado restante após a exclusão pode exceder o limite de 2% do espaço alocado da instância de um banco de dados. Nesses casos, os arquivos de log mais antigos serão excluídos até que o tamanho do arquivo de log não exceda o limite.
+ Quando o registro de `TABLE` estiver ativado, em alguns casos as tabelas de log serão rotacionadas a cada 24 horas. Essa alternância ocorrerá se o espaço utilizado pelos logs de tabelas for superior a 20% do espaço de armazenamento alocado. Isso também ocorrerá se o tamanho de todos os logs combinados for superior a 10 GB. Se a quantidade de espaço usada por uma instância de banco de dados for maior que 90 por cento do espaço de armazenamento alocado da instância de banco de dados, os limites para o rodízio do log serão reduzidos. As tabelas de logs serão, então, alternadas se o espaço utilizado pelos logs de tabelas for superior a 10% do espaço de armazenamento alocado. Eles também serão alternados se o tamanho de todos os logs combinados for superior a 5 GB. Você pode assinar a categoria de evento `low storage` para ser notificado quando tabelas de log forem rotacionadas para liberar espaço. Para obter mais informações, consulte [Trabalhar com a notificação de eventos do Amazon RDS](USER_Events.md).
Quando as tabelas de log são alternadas, a tabela de logs atual é copiada primeiro em uma tabela de logs de backup. Depois, as entradas na tabela de logs atual são removidas. Se a tabela de log de backup já existir, então ela será excluída antes que a tabela de log atual seja copiada ao backup. Você pode consultar a tabela de log de backup, se necessário. A tabela de log de backup para a tabela `mysql.general_log` é denominada `mysql.general_log_backup`. A tabela de log de backup para a tabela `mysql.slow_log` é denominada `mysql.slow_log_backup`.
Você pode rotacionar a tabela `mysql.general_log` chamando o procedimento `mysql.rds_rotate_general_log`. Você pode rotacionar a tabela `mysql.slow_log` chamando o procedimento `mysql.rds_rotate_slow_log`.
Os logs de tabelas são rotacionados durante um upgrade de versão do banco de dados.
Para trabalhar com os logs no console do Amazon RDS, na API do Amazon RDS, na CLI do Amazon RDS ou nos SDKs da AWS, defina o parâmetro `log_output` como FILE. Como o log de erros do MySQL, esses arquivos de log são rotacionados por hora. Os arquivos de log que foram gerados durante as duas semanas anteriores são retidos. Observe que o período de retenção é diferente entre o Amazon RDS e o Aurora.
## Limites de tamanho em redo logs
Para o RDS para MySQL versão 8.0.32 e anterior, o valor padrão desse parâmetro é 256 MB. Esse valor é obtido multiplicando o valor padrão do parâmetro `innodb_log_file_size` (128 MB) pelo valor padrão do parâmetro `innodb_log_files_in_group` (2). Para ter mais informações, consulte [Best practices for configuring parameters for Amazon RDS for MySQL, part 1: Parameters related to performance](https://aws.amazon.com/blogs/database/best-practices-for-configuring-parameters-for-amazon-rds-for-mysql-part-1-parameters-related-to-performance/).
Para o RDS para MySQL versão 8.0.33 e posterior e versões secundárias posteriores, o Amazon RDS usa o parâmetro `innodb_redo_log_capacity` em vez do `innodb_log_file_size`. O valor padrão do parâmetro `innodb_redo_log_capacity` do Amazon RDS é 2 GB. Para obter mais informações, consulte [Changes in MySQL 8.0.30](https://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-30.html) (Alterações no MySQL 8.0.30) na documentação do MySQL.
A partir do MySQL 8.4, o Amazon RDS habilita o parâmetro `innodb_dedicated_server` por padrão. Com o parâmetro `innodb_dedicated_server`, o mecanismo do banco de dados calcula os parâmetros `innodb_buffer_pool_size` e `innodb_redo_log_capacity`. Para obter mais informações, consulte [Configuração do tamanho do pool de buffer e a capacidade de log redo no MySQL 8.4](Appendix.MySQL.CommonDBATasks.Config.Size.8.4.md).
# Publicação de logs do MySQL no Amazon CloudWatch Logs
Você pode configurar sua instância de banco de dados MySQL para publicar dados de log em um grupo de log no Amazon CloudWatch Logs. Com o CloudWatch Logs, você pode executar análise em tempo real de dados de log e usar o CloudWatch para criar alarmes e visualizar métricas. Você pode usar o CloudWatch Logs para armazenar seus registros de log em armazenamento resiliente.
O Amazon RDS publica cada log de banco de dados MySQL como um fluxo separado de banco de dados no grupo de logs. Por exemplo, se você configurar a função de exportação para incluir o log de consultas lentas, os dados de consultas lentas serão armazenados em um fluxo de log de consultas lentas no grupo de logs `/aws/rds/instance/my_instance/slowquery`.
O log de erros está habilitado por padrão. A tabela a seguir resume os requisitos de outros logs do MySQL.
| Log | Requisito |
| --- | --- |
| Log de auditoria | A instância de banco de dados deve usar um grupo de opções personalizado com a opção `MARIADB_AUDIT_PLUGIN`. |
| Log geral | A instância de banco de dados deve usar um grupo de parâmetros personalizado com a configuração de parâmetro `general_log = 1` para habilitar o log geral. |
| Log de consultas lentas | A instância de banco de dados deve usar um grupo de parâmetros personalizado com a configuração de parâmetro `slow_query_log = 1` para habilitar o log de consulta lenta. |
| Log de erros de autenticação de banco de dados do IAM | Você deve habilitar o tipo de log `iam-db-auth-error` para uma instância de banco de dados criando ou modificando uma instância de banco de dados. |
| Resultado de saída do log | A instância de banco de dados deve usar um grupo de parâmetros personalizado com a configuração de parâmetro `log_output = FILE` para gravar logs no sistema de arquivos e publicá-los no CloudWatch Logs. |
## Console
**Para publicar logs do MySQL no CloudWatch Logs usando o console**
1. Abra o console do Amazon RDS em [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. No painel de navegação, escolha **Databases (Bancos de dados)** e a instância de banco de dados que você deseja modificar.
1. Selecione **Modify**.
1. Na seção **Log exports (Exportações de log)**, escolha os logs que deseja começar a publicar no CloudWatch Logs.
1. Escolha **Continue (Continuar)** e depois escolha **Modify DB Instance (Modificar instância de banco de dados)** na página de resumo.
## AWS CLI
Você pode publicar logs do MySQL com o AWS CLI. Você pode chamar o comando [https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html) com os seguintes parâmetros:
+ `--db-instance-identifier`
+ `--cloudwatch-logs-export-configuration`
**nota**
Uma alteração feita na opção `--cloudwatch-logs-export-configuration` sempre é aplicada imediatamente na instância de banco de dados. Por isso, as opções `--apply-immediately` e `--no-apply-immediately` não entram em vigor.
Também é possível publicar logs do MySQL chamando os seguintes comandos AWS CLI:
+ [https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html)
+ [https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-from-db-snapshot.html](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-from-db-snapshot.html)
+ [https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-from-s3.html](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-from-s3.html)
+ [https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-to-point-in-time.html](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-to-point-in-time.html)
Execute um destes comandos da AWS CLI com as seguintes opções:
+ `--db-instance-identifier`
+ `--enable-cloudwatch-logs-exports`
+ `--db-instance-class`
+ `--engine`
Outras opções podem ser obrigatórias, dependendo do comando da AWS CLI executado.
**Example**
O exemplo a seguir altera uma instância de Banco de Dados MySQL existente para publicar os arquivos de log no CloudWatch Logs. O valor `--cloudwatch-logs-export-configuration` é um objeto JSON. A chave para esse objeto é `EnableLogTypes`, e seu valor é uma matriz de strings com qualquer combinação de `audit`, `error`, `general` e `slowquery`.
Para Linux, macOS ou Unix:
```
1. aws rds modify-db-instance \
2. --db-instance-identifier mydbinstance \
3. --cloudwatch-logs-export-configuration '{"EnableLogTypes":["audit","error","general","slowquery"]}'
```
Para Windows:
```
1. aws rds modify-db-instance ^
2. --db-instance-identifier mydbinstance ^
3. --cloudwatch-logs-export-configuration '{"EnableLogTypes":["audit","error","general","slowquery"]}'
```
**Example**
O exemplo a seguir cria uma instância de Banco de Dados MySQL e publica os arquivos de log no CloudWatch Logs. O valor `--enable-cloudwatch-logs-exports` é uma matriz de strings JSON. As strings podem ser qualquer combinação de `audit`, `error`, `general` e `slowquery`.
Para Linux, macOS ou Unix:
```
1. aws rds create-db-instance \
2. --db-instance-identifier mydbinstance \
3. --enable-cloudwatch-logs-exports '["audit","error","general","slowquery"]' \
4. --db-instance-class db.m4.large \
5. --engine MySQL
```
Para Windows:
```
1. aws rds create-db-instance ^
2. --db-instance-identifier mydbinstance ^
3. --enable-cloudwatch-logs-exports '["audit","error","general","slowquery"]' ^
4. --db-instance-class db.m4.large ^
5. --engine MySQL
```
## API do RDS
Você pode publicar logs do MySQL com a API da RDS. Você pode chamar a ação [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html) com os seguintes parâmetros:
+ `DBInstanceIdentifier`
+ `CloudwatchLogsExportConfiguration`
**nota**
Uma alteração feita no parâmetro `CloudwatchLogsExportConfiguration` sempre é aplicada imediatamente na instância de banco de dados. Por isso, o parâmetro `ApplyImmediately` não entra em vigor.
Também é possível publicar logs do MySQL chamando as seguintes operações da API do RDS:
+ [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBInstance.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBInstance.html)
+ [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBInstanceFromDBSnapshot.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBInstanceFromDBSnapshot.html)
+ [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBInstanceFromS3.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBInstanceFromS3.html)
+ [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBInstanceToPointInTime.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBInstanceToPointInTime.html)
Execute uma destas operações da API do RDS com os seguintes parâmetros:
+ `DBInstanceIdentifier`
+ `EnableCloudwatchLogsExports`
+ `Engine`
+ `DBInstanceClass`
Outros parâmetros podem ser exigidos dependendo do comando AWS CLI que você executa.
# Enviar a saída de log do MySQL para tabelas
Você pode direcionar os logs de consultas gerais e lentas para tabelas na instância de banco de dados, criando um grupo de parâmetros de banco de dados e definindo o parâmetro do servidor `log_output` como `TABLE`. As consultas gerais são registradas na tabela `mysql.general_log` e as consultas lentas são registradas na tabela `mysql.slow_log`. Você pode consultar as tabelas para acessar as informações do log. Habilitar esse registro aumenta a quantidade de dados gravados no banco de dados, o que pode degradar a performance.
O log geral e os logs de consultas lentas estão desabilitados por padrão. Para habilitar o registro em log de tabelas, você também deve definir os parâmetros de servidor `general_log` e `slow_query_log` como `1`.
As tabelas de log continuarão crescendo até que as respectivas atividades de log sejam desativadas com a redefinição do parâmetro apropriado como `0`. Uma grande quantidade de dados geralmente se acumula ao longo do tempo, o que pode consumir uma porcentagem considerável do espaço de armazenamento alocado. O Amazon RDS não permite truncar tabelas de log, mas é possível mover o conteúdo delas. Rotacionar uma tabela salva seu conteúdo em uma tabela de backup e, em seguida, cria uma nova tabela de log vazia. Você pode rotacionar manualmente as tabelas de log com os seguintes procedimentos de linha de comando, em que o prompt de comando é indicado por `PROMPT>`:
```
PROMPT> CALL mysql.rds_rotate_slow_log;
PROMPT> CALL mysql.rds_rotate_general_log;
```
Para remover completamente os dados antigos e recuperar o espaço em disco, chame o procedimento apropriado duas vezes sucessivamente.
# Configurar o registro em log binário do RDS para MySQL para bancos de dados single-AZ
O *log binário* é um conjunto de arquivos de log que contêm informações sobre modificações de dados feitas em uma instância do servidor MySQL. O log binário contém informações como as seguintes:
+ Eventos que descrevem alterações no banco de dados, como criação de tabela ou modificações de linha
+ Informações sobre a duração de cada instrução que atualizou dados
+ Eventos para declarações que poderiam ter dados atualizados, mas não foram
O log binário registra instruções que são enviadas durante a replicação. Também é necessário para algumas operações de recuperação. Para obter mais informações, consulte [The Binary Log](https://dev.mysql.com/doc/refman/8.0/en/binary-log.html) na documentação do MySQL.
O recurso de backups automatizados determina se o registro em log binário está ativado ou desativado para o MySQL. Você tem as seguintes opções:
Ativar o registro em log binário
Defina o período de retenção de backup para um valor positivo diferente de zero.
Desativar o registro em log binário
Defina o período de retenção de backup para 0.
Para ter mais informações, consulte [Ativar backups automáticos](USER_WorkingWithAutomatedBackups.Enabling.md).
O MySQL no Amazon RDS é compatível com os formatos de registro em log binário *baseados em linha*, *baseados em instrução* e *mistos*. Recomendamos misto, a menos que você precise de um formato específico de log binário. Para obter detalhes sobre os diferentes formatos de logs binários do MySQL, consulte [Formatos de registro em log binário](https://dev.mysql.com/doc/refman/8.0/en/binary-log-formats.html) na documentação do MySQL.
Se você pretende usar replicação, o formato do registro em log binário é importante porque determina o registro de alterações feitas nos dados salvas na origem e enviadas para os destinos de replicação. Para obter informações sobre as vantagens e as desvantagens de formatos de registro em logs binários para replicação, consulte [Vantagens e desvantagens da replicação baseada em instrução e baseada em linha](https://dev.mysql.com/doc/refman/8.0/en/replication-sbr-rbr.html) na documentação do MySQL.
**Importante**
Com o MySQL 8.0.34, o MySQL descontinuou o parâmetro `binlog_format`. Em versões posteriores do MySQL, o MySQL pretende remover o parâmetro e oferecer suporte somente à replicação baseada em linhas. Como resultado, recomendamos o uso de registro baseado em linhas para novas configurações de replicação do MySQL. Para obter mais informações, consulte [binlog\$1format](https://dev.mysql.com/doc/refman/8.0/en/replication-options-binary-log.html#sysvar_binlog_format) na documentação do MySQL.
As versões 8.0 e 8.4 do MySQL aceitam o parâmetro `binlog_format`. Ao usar esse parâmetro, o MySQL emite um aviso de descontinuação. Em uma futura versão principal, o MySQL removerá o parâmetro `binlog_format`.
A replicação baseada em instrução pode causar inconsistências entre a instância de banco de dados de origem e uma réplica de leitura. Para obter mais informações, consulte [Determinação de instruções seguras e inseguras no registro de logs binários](https://dev.mysql.com/doc/refman/8.0/en/replication-rbr-safe-unsafe.html). na documentação do MySQL.
Habilitar o registro em log binário aumenta o número de operações de E/S do disco de gravação na instância de banco de dados. Você pode monitorar o uso de IOPS com a métrica `WriteIOPS``` do CloudWatch.
**Para definir o formato de registro em log binário do MySQL**
1. Abra o console do Amazon RDS em [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. No painel de navegação, selecione **Parameter groups**.
1. Selecione o grupo de parâmetros do de banco de dados associado à instância de banco de dados que você deseja modificar.
Não é possível modificar um grupo de parâmetros padrão. Se a instância de banco de dados estiver usando um grupo de parâmetros padrão, crie outro grupo de parâmetros e o associe à instância de banco de dados.
Para ter mais informações sobre grupos de parâmetros, consulte [Grupos de parâmetros para Amazon RDS](USER_WorkingWithParamGroups.md).
1. Em **Ações**, selecione **Editar**.
1. Defina o parâmetro `binlog_format` como o formato de registro em log binário de sua escolha (`ROW`, `STATEMENT` ou `MIXED`).
Você pode desativar o registro em log binário definindo o período de retenção de backup de uma instância de banco de dados como zero, mas isso desativa os backups automatizados diários. Desabilitar os backups automatizados desativa ou desabilita a variável de sessão `log_bin`. Isso desabilita o registro em log binário na instância de banco de dados do RDS para MySQL que, por sua vez, redefine a variável de sessão `binlog_format` como o valor padrão de `ROW` no banco de dados. Recomendamos não desabilitar os backups. Para receber mais informações sobre a configuração **Período de retenção de backup**, consulte [Configurações para instâncias de banco de dados](USER_ModifyInstance.Settings.md).
1. Escolha **Salvar alterações** para salvar as atualizações no grupo de parâmetros de banco de dados.
Como o parâmetro `binlog_format` é dinâmico no RDS para MySQL, você não precisa reinicializar a instância de banco de dados para que as alterações sejam aplicadas. (Observe que, no Aurora MySQL, esse parâmetro é estático. Consulte mais informações em [Configurar o registro em log binário do Aurora MySQL](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_LogAccess.MySQL.BinaryFormat.html).)
**Importante**
Alterar um grupo de parâmetros de banco de dados afeta todas as instâncias de banco de dados que usam esse grupo de parâmetros. Se você quiser especificar diferentes formatos do registro em log binário para diferentes instâncias de banco de dados MySQL em uma região da AWS, as instâncias de banco de dados deverão usar diferentes grupos de parâmetros de banco de dados. Esses grupos de parâmetros identificam diferentes formatos de log. Atribua o grupo de parâmetros de banco de dados apropriado a cada instância de banco de dados.
# Configuração do registro em log binário do MySQL para clusters de banco de dados multi-AZ
O registro em log binário no Amazon RDS para MySQL para clusters de banco de dados multi-AZ registra todas as alterações do banco de dados para oferecer suporte a replicação, recuperação point-in-time e auditoria. Em clusters de banco de dados multi-AZ, os logs binários sincronizam os nós secundários com o nó primário, garantindo a consistência de dados em todas as zonas de disponibilidade e permitindo failovers contínuos.
Para otimizar o registro em log binário, o Amazon RDS oferece suporte à compactação de transações de log binário, o que reduz os requisitos de armazenamento para logs binários e melhora a eficiência da replicação.
**Topics**
+ [Compactação de transação de log binário para clusters de banco de dados multi-AZ](#USER_Binlog.MultiAZ.compression)
+ [Configuração da compactação de transação de log binário para clusters de banco de dados multi-AZ](#USER_Binlog.MultiAZ.configuring)
## Compactação de transação de log binário para clusters de banco de dados multi-AZ
A compactação de transações de log binário usa o algoritmo zstd para reduzir o tamanho dos dados de transação armazenados em logs binários. Quando habilitado, o mecanismo de banco de dados MySQL comprime as cargas úteis de transação em um único evento, minimizando a sobrecarga de E/S e armazenamento. Esse recurso melhora o desempenho do banco de dados, reduz o tamanho do log binário e otimiza o uso de recursos para gerenciar e replicar logs em clusters de banco de dados multi-AZ.
O Amazon RDS fornece compactação de transação de log binário para clusters de banco de dados multi-AZ do RDS para MySQL por meio dos seguintes parâmetros:
+ `binlog_transaction_compression`: quando habilitado (`1`), o mecanismo de banco de dados compacto as cargas úteis da transação e as grava no log binário como um único evento. Isso reduz o uso do armazenamento e a sobrecarga de E/S. Por padrão, o parâmetro é desabilitado.
+ `binlog_transaction_compression_level_zstd`: configura o nível de compressão zstd para transações de log binário. Valores mais altos aumentam a taxa de compactação, reduzindo ainda mais os requisitos de armazenamento, mas aumentando o uso da CPU e da memória para compactação. O valor padrão é 3, com um intervalo de 1 a 22.
Esses parâmetros permitem ajustar a compactação de logs binários com base nas características da workload e na disponibilidade de recursos. Para obter mais informações, consulte [Compactação de transações de log binário](https://dev.mysql.com/doc/refman/8.4/en/binary-log-transaction-compression.html) na documentação do MySQL.
A compactação de transações de log binário oferece os seguintes benefícios principais:
+ A compactação diminui o tamanho dos logs binários, especialmente para workloads com grandes transações ou altos volumes de gravação.
+ Logs binários menores reduzem a sobrecarga de rede e de E/S, aprimorando o desempenho da replicação.
+ O parâmetro `binlog_transaction_compression_level_zstd` fornece controle sobre o equilíbrio entre a taxa de compressão e o consumo de recursos.
## Configuração da compactação de transação de log binário para clusters de banco de dados multi-AZ
Para configurar a compactação de transações de log binário para um cluster de banco de dados multi-AZ do RDS para MySQL, modifique as configurações relevantes dos parâmetros do cluster de acordo com seus requisitos de workload.
### Console
**Como habilitar a compactação de transações de log binário**
1. Modifique o grupo de parâmetros de cluster de banco de dados para definir o parâmetro `binlog_transaction_compression` como `1`.
1. (Opcional) Ajuste o valor do parâmetro `binlog_transaction_compression_level_zstd` com base nos requisitos de workload e na disponibilidade de recursos.
Para obter mais informações, consulte [Modificar parâmetros em um grupo de parâmetros de cluster de banco de dados](USER_WorkingWithParamGroups.ModifyingCluster.md).
### AWS CLI
Para configurar a compactação de transações de log binário usando a AWS CLI, use o comando [modify-db-cluster-parameter-group](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster-parameter-group.html).
**Example**
Para Linux, macOS ou Unix:
```
aws rds modify-db-cluster-parameter-group \
--db-cluster-parameter-group-name your-cluster-parameter-group \
--parameters "ParameterName=binlog_transaction_compression,ParameterValue=1,ApplyMethod=pending-reboot"
```
Para Windows:
```
aws rds modify-db-cluster-parameter-group ^
--db-cluster-parameter-group-name your-cluster-parameter-group ^
--parameters "ParameterName=binlog_transaction_compression,ParameterValue=1,ApplyMethod=pending-reboot"
```
### API do RDS
Para configurar a compactação de transações de log binário usando a API do Amazon RDS, use a operação [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBClusterParameterGroup.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBClusterParameterGroup.html).
# Acessar logs binários do MySQL
É possível usar o utilitário mysqlbinlog para baixar ou transmitir os logs binários de instâncias do RDS para instâncias de banco de dados do MySQL. O log binário é baixado para o computador local, onde você pode realizar ações como reproduzir o log usando o utilitário mysql. Para ter mais informações sobre como usar o utilitário mysqlbinlog, acesse [Usar mysqlbinlog para fazer backup de arquivos de log binários](https://dev.mysql.com/doc/refman/8.0/en/mysqlbinlog-backup.html) na documentação do MySQL.
Para executar o utilitário mysqlbinlog em uma instância do Amazon RDS, use as seguintes opções:
+ `--read-from-remote-server` – obrigatório.
+ `--host`: o nome DNS do endpoint da instância.
+ `--port`: a porta usada pela instância.
+ `--user`: um usuário do MySQL ao qual foi concedida a permissão `REPLICATION SLAVE`.
+ `--password`: a senha do usuário do MySQL ou omita um valor de senha de forma que o utilitário solicite uma senha.
+ `--raw`: baixe o arquivo em formato binário.
+ `--result-file`: o arquivo local para receber a saída bruta.
+ `--stop-never`: transmita os arquivos de log binários.
+ `--verbose`: ao usar o formato de log binário `ROW`, inclua essa opção para ver os eventos de linha como instruções pseudo-SQL. Para ter mais informações sobre a opção `--verbose`, consulte [Exibição de evento da linha mysqlbinlog](https://dev.mysql.com/doc/refman/8.0/en/mysqlbinlog-row-events.html) na documentação do MySQL.
+ Especifique os nomes de um ou mais arquivos de log binários. Para obter uma lista dos logs disponíveis, use o comando SQL `SHOW BINARY LOGS`.
Para ter mais informações sobre as opções de mysqlbinlog, consulte [mysqlbinlog: utilitário para processar arquivos de log binários](https://dev.mysql.com/doc/refman/8.0/en/mysqlbinlog.html) na documentação do MySQL.
Os exemplos a seguir mostram como usar o utilitário mysqlbinlog.
Para Linux, macOS ou 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
```
Os logs binários devem permanecer disponíveis na instância de banco de dados para que o utilitário mysqlbinlog possa acessá-los. Para garantir a disponibilidade deles, use o procedimento armazenado [mysql.rds\$1set\$1configuration](mysql-stored-proc-configuring.md#mysql_rds_set_configuration) e especifique um período com tempo suficiente para você baixar os logs. Se essa configuração não for definida, o Amazon RDS purgará os logs binários o mais rápido possível, causando lacunas nos logs binários que o utilitário mysqlbinlog recupera.
O exemplo a seguir define o período de retenção como 1 dia.
```
call mysql.rds_set_configuration('binlog retention hours', 24);
```
Para exibir a configuração atual, use o procedimento armazenado [mysql.rds\$1show\$1configuration](mysql-stored-proc-configuring.md#mysql_rds_show_configuration).
```
call mysql.rds_show_configuration;
```
# Arquivos de log do banco de dados do Amazon RDS para Oracle
Você pode acessar os logs de alerta, os arquivos de auditoria e os arquivos de rastreamento da Oracle usando o console ou a API do Amazon RDS. Para mais informações sobre a visualização, o download e os logs de bancos de dados baseados no monitoramento de arquivos, consulte [Monitorar arquivos de log do Amazon RDS](USER_LogAccess.md).
Os arquivos de auditoria da Oracle fornecidos são os arquivos de auditoria padrão da Oracle. O Amazon RDS é compatível com o recurso de auditoria refinada (FGA) da Oracle. Contudo, o acesso ao log não fornece acesso a eventos do FGA que são armazenados na tabela `SYS.FGA_LOG$` e são acessados por meio da visualização `DBA_FGA_AUDIT_TRAIL`.
A operação da API [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBLogFiles.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBLogFiles.html) que lista os arquivos de log da Oracle disponíveis para uma instância de banco de dados ignora o parâmetro `MaxRecords`e retorna até 1.000 registros. A chamada retorna `LastWritten` como uma data POSIX em milissegundos.
**Topics**
+ [Cronograma de retenção](#USER_LogAccess.Concepts.Oracle.Retention)
+ [Trabalhar com arquivos de rastreamento da Oracle](#USER_LogAccess.Concepts.Oracle.WorkingWithTracefiles)
+ [Publicação de logs da Oracle no Amazon CloudWatch Logs](#USER_LogAccess.Oracle.PublishtoCloudWatchLogs)
+ [Acesso aos logs de alerta e logs de receptor](#USER_LogAccess.Concepts.Oracle.AlertLogAndListenerLog)
## Cronograma de retenção
O mecanismo de banco de dados Oracle pode fazer a rotação dos arquivos de log se eles ficarem muito grandes. Baixe esses arquivos de auditoria ou de rastreamento para retê-los. Se você armazenar os arquivos localmente, reduzirá os custos de armazenamento do Amazon RDS e disponibilizará mais espaço para seus dados.
A tabela a seguir mostra o cronograma de retenção para os logs de alerta, arquivos de auditoria e arquivos de rastreamento da Oracle no Amazon RDS.
****
| Tipo de log | Cronograma de retenção |
| --- | --- |
| Logs de alerta | O log de alertas de texto é alternado diariamente com uma retenção de 30 dias gerenciada pelo Amazon RDS. O log de alerta de XML é retido por pelo menos sete dias. Você pode acessar esse log usando a visualização `ALERTLOG`. |
| Arquivos de auditoria | O período de retenção padrão para arquivos de rastreamento é de sete dias. O Amazon RDS poderá excluir arquivos de auditoria com mais de sete dias. |
| Arquivos de rastreamento | O período de retenção padrão para arquivos de rastreamento é de sete dias. O Amazon RDS poderá excluir arquivos de rastreamento com mais de sete dias. |
| Logs de listener | O período de retenção padrão para os logs de listener é sete dias. O Amazon RDS poderá excluir logs de listener com mais de sete dias. |
**nota**
Arquivos de auditoria e de rastreamento compartilham a mesma configuração de retenção.
## Trabalhar com arquivos de rastreamento da Oracle
A seguir, você pode localizar descrições de procedimentos do Amazon RDS para criar, atualizar, acessar e excluir arquivos de rastreamento.
**Topics**
+ [Listar arquivos](#USER_LogAccess.Concepts.Oracle.WorkingWithTracefiles.ViewingBackgroundDumpDest)
+ [Gerar arquivos de rastreamento e rastrear uma sessão](#USER_LogAccess.Concepts.Oracle.WorkingWithTracefiles.Generating)
+ [Recuperar arquivos de rastreamento](#USER_LogAccess.Concepts.Oracle.WorkingWithTracefiles.Retrieving)
+ [Limpar arquivos de rastreamento](#USER_LogAccess.Concepts.Oracle.WorkingWithTracefiles.Purging)
### Listar arquivos
Você pode usar qualquer um dos dois procedimentos para permitir acesso a qualquer arquivo no caminho `background_dump_dest`. O primeiro procedimento atualiza uma visualização que contém uma lista de todos os arquivos que estão em no moment `background_dump_dest`.
```
1. EXEC rdsadmin.manage_tracefiles.refresh_tracefile_listing;
```
Depois que a visualização for atualizada, consulte a visualização a seguir para acessar os resultados.
```
1. SELECT * FROM rdsadmin.tracefile_listing;
```
Uma alternativa ao processo anterior é usar `FROM table` para transmitir dados não relacionais que não estejam em tabelas em um formato semelhante ao de uma tabela para listar o conteúdo do diretório de banco de dados.
```
1. SELECT * FROM TABLE(rdsadmin.rds_file_util.listdir('BDUMP'));
```
A consulta a seguir mostra o texto de um arquivo de log.
```
1. SELECT text FROM TABLE(rdsadmin.rds_file_util.read_text_file('BDUMP','alert_dbname.log.date'));
```
Em uma réplica de leitura, obtenha o nome do diretório BDUMP consultando `V$DATABASE.DB_UNIQUE_NAME`. Se o nome exclusivo for `DATABASE_B`, o diretório BDUMP será `BDUMP_B`. O exemplo a seguir consulta o nome BDUMP em uma réplica e usa esse nome para consultar o conteúdo de `alert_DATABASE.log.2020-06-23`.
```
1. SELECT 'BDUMP' || (SELECT regexp_replace(DB_UNIQUE_NAME,'.*(_[A-Z])', '\1') FROM V$DATABASE) AS BDUMP_VARIABLE FROM DUAL;
2.
3. BDUMP_VARIABLE
4. --------------
5. BDUMP_B
6.
7. SELECT TEXT FROM table(rdsadmin.rds_file_util.read_text_file('BDUMP_B','alert_DATABASE.log.2020-06-23'));
```
### Gerar arquivos de rastreamento e rastrear uma sessão
Como não há restrições em `ALTER SESSION`, muitos métodos padrão para gerar arquivos de rastreamento da Oracle permanecem disponíveis para uma instância de banco de dados do Amazon RDS. Os procedimentos a seguir são fornecidos para arquivos de rastreamento que exigem maior acesso.
****
| Método Oracle | Método do Amazon RDS |
| --- | --- |
| `oradebug hanganalyze 3 ` | `EXEC rdsadmin.manage_tracefiles.hanganalyze; ` |
| `oradebug dump systemstate 266 ` | `EXEC rdsadmin.manage_tracefiles.dump_systemstate;` |
Você pode usar muitos métodos padrão para rastrear sessões individuais conectadas a uma instância de banco de dados Oracle no Amazon RDS. Para habilitar o rastreamento de uma sessão, é possível executar subprogramas em pacotes PL/SQL fornecidos pela Oracle, como `DBMS_SESSION` e `DBMS_MONITOR`. Para obter mais informações, consulte [Habilitar o rastreamento de uma sessão](https://docs.oracle.com/database/121/TGSQL/tgsql_trace.htm#GUID-F872D6F9-E015-481F-80F6-8A7036A6AD29) na documentação da Oracle.
### Recuperar arquivos de rastreamento
Você pode recuperar qualquer arquivo de rastreamento em `background_dump_dest` usando uma consulta SQL padrão em uma tabela externa gerenciada pelo Amazon RDS. Para usar este método, execute o procedimento e defina o local desta tabela para o arquivo de rastreamento específico.
Por exemplo, você pode usar a visualização `rdsadmin.tracefile_listing` mencionada anteriormente para listar todos os arquivos de rastreamento no sistema. Em seguida, você pode definir a visualização `tracefile_table` para apontar para o arquivo de rastreamento pretendido usando o seguinte procedimento.
```
1. EXEC rdsadmin.manage_tracefiles.set_tracefile_table_location('CUST01_ora_3260_SYSTEMSTATE.trc');
```
O exemplo a seguir criar uma tabela externa no esquema atual com o local definido para o arquivo fornecido. É possível recuperar o conteúdo em um arquivo local usando uma consulta SQL.
```
1. SPOOL /tmp/tracefile.txt
2. SELECT * FROM tracefile_table;
3. SPOOL OFF;
```
### Limpar arquivos de rastreamento
Os arquivos de rastreamento podem acumular e consumir espaço em disco. Por padrão, o Amazon RDS limpa os arquivos de rastreamento e os arquivos de log com mais de sete dias. Você pode visualizar e definir o período de retenção do arquivo de rastreamento usando o procedimento `show_configuration`. Você deve executar o comando `SET SERVEROUTPUT ON` para que possa visualizar os resultados da configuração.
O exemplo a seguir mostra o período de retenção do arquivo de rastreamento atual e, em seguida, define um novo período de retenção para o arquivo de rastreamento.
```
1. # Show the current tracefile retention
2. SQL> EXEC rdsadmin.rdsadmin_util.show_configuration;
3. NAME:tracefile retention
4. VALUE:10080
5. DESCRIPTION:tracefile expiration specifies the duration in minutes before tracefiles in bdump are automatically deleted.
6.
7. # Set the tracefile retention to 24 hours:
8. SQL> EXEC rdsadmin.rdsadmin_util.set_configuration('tracefile retention',1440);
9. SQL> commit;
10.
11. #show the new tracefile retention
12. SQL> EXEC rdsadmin.rdsadmin_util.show_configuration;
13. NAME:tracefile retention
14. VALUE:1440
15. DESCRIPTION:tracefile expiration specifies the duration in minutes before tracefiles in bdump are automatically deleted.
```
Além do processo periódico de limpeza, você pode remover arquivos de manualment `background_dump_dest`. O exemplo a seguir mostra como limpar todos os arquivos que tenham mais de cinco minutos.
```
EXEC rdsadmin.manage_tracefiles.purge_tracefiles(5);
```
Também limpe todos os arquivos correspondentes a um padrão específico (do contrário, não inclua a extensão do arquivo, como .trc). O exemplo a seguir mostra como limpar todos os arquivos que começam com `SCHPOC1_ora_5935`.
```
1. EXEC rdsadmin.manage_tracefiles.purge_tracefiles('SCHPOC1_ora_5935');
```
## Publicação de logs da Oracle no Amazon CloudWatch Logs
É possível configurar a instância de banco de dados do RDS para Oracle para publicar dados de log em um grupo de logs no Amazon CloudWatch Logs. Com o CloudWatch Logs, você pode analisar os dados de log e usar o CloudWatch para criar alarmes e visualizar métricas. Você pode usar o CloudWatch Logs para armazenar seus registros de log em armazenamento resiliente.
O Amazon RDS publica cada log de banco de dados Oracle como um fluxo separado de banco de dados no grupo de logs. Por exemplo, se você configurar a função de exportação para incluir o log de auditoria, os dados de auditoria serão armazenados em um fluxo de log de auditoria no grupo de logs `/aws/rds/instance/my_instance/audit`. A tabela a seguir resume os requisitos do RDS para Oracle para publicar logs no Amazon CloudWatch Logs.
| Nome do log | Requisito | Padrão |
| --- | --- | --- |
| Log de alertas | Nenhum. Não é possível desabilitar esse log. | Habilitado |
| Log de rastreamento | Defina o parâmetro `trace_enabled` como `TRUE` ou deixe-o definido como padrão. | `TRUE` |
| Log de auditoria | Defina o parâmetro `audit_trail` como qualquer um dos seguintes valores permitidos: { none | os | db [, extended] | xml [, extended] } | `none` |
| Log de listener | Nenhum. Não é possível desabilitar esse log. | Habilitado |
| Log do Oracle Management Agent | Nenhum. Não é possível desabilitar esse log. | Habilitado |
Esse log do Oracle Management Agent consiste nos grupos de logs mostrados na tabela a seguir.
****
| Nome do log | Grupo de logs do CloudWatch |
| --- | --- |
| emctl.log | oemagent-emctl |
| emdctlj.log | oemagent-emdctlj |
| gcagent.log | oemagent-gcagent |
| gcagent\$1errors.log | oemagent-gcagent-errors |
| emagent.nohup | oemagent-emagent-nohup |
| secure.log | oemagent-secure |
Para obter mais informações, consulte [Locating Management Agent Log and Trace Files](https://docs.oracle.com/en/enterprise-manager/cloud-control/enterprise-manager-cloud-control/13.4/emadm/locating-management-agent-log-and-trace-files1.html#GUID-9C710D78-6AA4-42E4-83CD-47B5FF4892DF) (Localizar arquivos de log e rastreamento do agente de gerenciamento) na documentação do Oracle.
### Console
**Para publicar logs de banco de dados Oracle no CloudWatch Logs pelo Console de gerenciamento da AWS**
1. Abra o console do Amazon RDS em [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. No painel de navegação, escolha **Databases (Bancos de dados)** e a instância de banco de dados que você deseja modificar.
1. Selecione **Modify**.
1. Na seção **Log exports (Exportações de log)**, escolha os logs que deseja começar a publicar no CloudWatch Logs.
1. Escolha **Continue (Continuar)** e depois escolha **Modify DB Instance (Modificar instância de banco de dados)** na página de resumo.
### AWS CLI
Para publicar os logs da Oracle, você pode usar o comando [https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html) com os seguintes parâmetros:
+ `--db-instance-identifier`
+ `--cloudwatch-logs-export-configuration`
**nota**
Uma alteração feita na opção `--cloudwatch-logs-export-configuration` sempre é aplicada imediatamente na instância de banco de dados. Por isso, as opções `--apply-immediately` e `--no-apply-immediately` não entram em vigor.
Você também pode publicar os logs da Oracle usando os seguintes comandos:
+ [https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html)
+ [https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-from-db-snapshot.html](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-from-db-snapshot.html)
+ [https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-from-s3.html](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-from-s3.html)
+ [https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-to-point-in-time.html](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-to-point-in-time.html)
**Example**
O exemplo a seguir cria uma instância de Banco de Dados Oracle com a publicação no CloudWatch Logs habilitada. O valor `--cloudwatch-logs-export-configuration` é uma matriz de strings JSON. As strings podem ser qualquer combinação de `alert`, `audit`, `listener` e `trace`.
Para Linux, macOS ou Unix:
```
aws rds create-db-instance \
--db-instance-identifier mydbinstance \
--cloudwatch-logs-export-configuration '["trace","audit","alert","listener","oemagent"]' \
--db-instance-class db.m5.large \
--allocated-storage 20 \
--engine oracle-ee \
--engine-version 19.0.0.0.ru-2024-04.rur-2024-04.r1 \
--license-model bring-your-own-license \
--master-username myadmin \
--manage-master-user-password
```
Para Windows:
```
aws rds create-db-instance ^
--db-instance-identifier mydbinstance ^
--cloudwatch-logs-export-configuration trace alert audit listener oemagent ^
--db-instance-class db.m5.large ^
--allocated-storage 20 ^
--engine oracle-ee ^
--engine-version 19.0.0.0.ru-2024-04.rur-2024-04.r1 ^
--license-model bring-your-own-license ^
--master-username myadmin ^
--manage-master-user-password
```
**Example**
O exemplo a seguir altera uma instância de Banco de Dados Oracle existente para publicar os arquivos de log no CloudWatch Logs. O valor `--cloudwatch-logs-export-configuration` é um objeto JSON. A chave para esse objeto é `EnableLogTypes`, e seu valor é uma matriz de strings com qualquer combinação de `alert`, `audit`, `listener` e `trace`.
Para Linux, macOS ou Unix:
```
aws rds modify-db-instance \
--db-instance-identifier mydbinstance \
--cloudwatch-logs-export-configuration '{"EnableLogTypes":["trace","alert","audit","listener","oemagent"]}'
```
Para Windows:
```
aws rds modify-db-instance ^
--db-instance-identifier mydbinstance ^
--cloudwatch-logs-export-configuration EnableLogTypes=\"trace\",\"alert\",\"audit\",\"listener\",\"oemagent\"
```
**Example**
O exemplo a seguir modifica uma instância de Banco de Dados Oracle existente para desabilitar a publicação de arquivos de log de auditoria e de listener no CloudWatch Logs. O valor `--cloudwatch-logs-export-configuration` é um objeto JSON. A chave para esse objeto é `DisableLogTypes`, e seu valor é uma matriz de strings com qualquer combinação de `alert`, `audit`, `listener` e `trace`.
Para Linux, macOS ou Unix:
```
aws rds modify-db-instance \
--db-instance-identifier mydbinstance \
--cloudwatch-logs-export-configuration '{"DisableLogTypes":["audit","listener"]}'
```
Para Windows:
```
aws rds modify-db-instance ^
--db-instance-identifier mydbinstance ^
--cloudwatch-logs-export-configuration DisableLogTypes=\"audit\",\"listener\"
```
### API do RDS
Você pode publicar logs de banco de dados Oracle com a API do RDS. Você pode chamar a ação [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html) com os seguintes parâmetros:
+ `DBInstanceIdentifier`
+ `CloudwatchLogsExportConfiguration`
**nota**
Uma alteração feita no parâmetro `CloudwatchLogsExportConfiguration` sempre é aplicada imediatamente na instância de banco de dados. Por isso, o parâmetro `ApplyImmediately` não entra em vigor.
Também publique logs Oracle chamando as seguintes operações da API do RDS:
+ [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBInstance.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBInstance.html)
+ [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBInstanceFromDBSnapshot.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBInstanceFromDBSnapshot.html)
+ [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBInstanceFromS3.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBInstanceFromS3.html)
+ [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBInstanceToPointInTime.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBInstanceToPointInTime.html)
Execute uma destas operações da API do RDS com os seguintes parâmetros:
+ `DBInstanceIdentifier`
+ `EnableCloudwatchLogsExports`
+ `Engine`
+ `DBInstanceClass`
Outros parâmetros podem ser obrigatórios, dependendo da operação do RDS executada.
## Acesso aos logs de alerta e logs de receptor
Você pode visualizar o log de alertas usando o console do Amazon RDS. Também é possível usar a instrução SQL a seguir.
```
1. SELECT message_text FROM alertlog;
```
Acesse o log do receptor usando o Amazon CloudWatch Logs.
**nota**
A Oracle faz a rotação dos logs de alerta e de ouvinte quando ultrapassam 10 MB e, a partir deste ponto, eles ficam indisponíveis nas visualizações do Amazon RDS.
# Arquivos de log do banco de dados RDS para PostgreSQL
Você pode monitorar os seguintes tipos de arquivo de log do :
+ Log do PostgreSQL
+ Log de atualização
+ Log de erros de autenticação de banco de dados do IAM
**nota**
Para habilitar os logs de erro de autenticação de banco de dados do IAM, você deve primeiro habilitar a autenticação de banco de dados do IAM para a instância de banco de dados do RDS para PostgreSQL. Para ter mais informações sobre a autenticação de banco de dados do IAM, consulte [Habilitar e desabilitar a autenticação de banco de dados do IAM](UsingWithRDS.IAMDBAuth.Enabling.md).
O RDS para PostgreSQL registra as atividades do banco de dados no arquivo de log padrão do PostgreSQL. Para uma instância de banco de dados PostgreSQL on-premises, essas mensagens são armazenadas localmente em `log/postgresql.log`. Para uma instância de banco de dados do RDS para PostgreSQL, o arquivo de log está disponível na instância do Amazon RDS. Esses logs também podem ser acessados por meio do Console de gerenciamento da AWS, onde você pode visualizá-los ou baixá-los. O nível de registro em log padrão captura falhas de login, erros fatais do servidor, deadlocks e falhas de consulta.
Para ter mais informações sobre a visualização, o download e os logs de banco de dados baseados no monitoramento de arquivos, consulte [Monitorar arquivos de log do Amazon RDS](USER_LogAccess.md). Para saber mais sobre logs do PostgreSQL, consulte [Working with Amazon RDS and Aurora PostgreSQL logs: Part 1](https://aws.amazon.com/blogs/database/working-with-rds-and-aurora-postgresql-logs-part-1/) (Trabalhar com o Amazon RDS e logs do Aurora PostgreSQL: parte 1) e [Working with RDS and Aurora PostgreSQL logs: Part 2](https://aws.amazon.com/blogs/database/working-with-rds-and-aurora-postgresql-logs-part-2/) (Trabalhar com o Amazon RDS e logs do Aurora PostgreSQL: parte 2).
Além dos logs padrão do PostgreSQL abordados neste tópico, o RDS para PostgreSQL também é compatível com a extensão Audit do PostgreSQL (`pgAudit`). A maioria dos setores regulamentados e agências governamentais precisa manter um log de auditoria ou uma trilha de auditoria das alterações feitas nos dados para cumprir os requisitos legais. Para obter informações sobre a instalação e o uso de pgAudit, consulte [Usar pgAudit para registrar a atividade do banco de dados](Appendix.PostgreSQL.CommonDBATasks.pgaudit.md).
**Topics**
+ [Parâmetros para registro em log no RDS para PostgreSQL](USER_LogAccess.Concepts.PostgreSQL.overview.parameter-groups.md)
+ [Ativar o registro em log de consultas para a instância de banco de dados do RDS para PostgreSQL](USER_LogAccess.Concepts.PostgreSQL.Query_Logging.md)
+ [Publicação de logs do PostgreSQL no Amazon CloudWatch Logs](#USER_LogAccess.Concepts.PostgreSQL.PublishtoCloudWatchLogs)
# Parâmetros para registro em log no RDS para PostgreSQL
É possível personalizar o comportamento do registro em log da instância de banco de dados do RDS para PostgreSQL modificando vários parâmetros. Na tabela a seguir, você encontra os parâmetros que afetam por quanto tempo os logs são armazenados, quando alternar o log e se ele deve ser gerado no formato CSV (valor separado por vírgula). Você também pode encontrar a saída de texto enviada para STDERR, entre outras configurações. Para alterar as configurações dos parâmetros que podem ser modificados, use um grupo de parâmetros de banco de dados para o Instância do RDS para PostgreSQL. Para ter mais informações, consulte [Grupos de parâmetros de banco de dados para instâncias de banco de dados do Amazon RDS](USER_WorkingWithDBInstanceParamGroups.md).
| Parâmetro | Padrão | Descrição |
| --- | --- | --- |
| log\$1destination | stderr | Define o formato de saída para o log. O padrão é `stderr`, mas você também pode especificar valores separados por vírgula (CSV) adicionando `csvlog` à configuração. Para obter mais informações, consulte [Definir o destino dos logs (`stderr`, `csvlog`)](#USER_LogAccess.Concepts.PostgreSQL.Log_Format). |
| log\$1filename | postgresql.log.%Y-%m-%d-%H%M | Especifica o padrão para o nome do arquivo de log. Além do padrão, esse parâmetro é compatível com `postgresql.log.%Y-%m-%d` e `postgresql.log.%Y-%m-%d-%H%M` para o padrão de nome de arquivo. |
| log\$1line\$1prefix | %t:%r:%u@%d:[%p]: | Define o prefixo para cada linha de log que é gravada em `stderr`, para anotar a hora (%t), o host remoto (%r), o usuário (%u), o banco de dados (%d) e o ID do processo (%p). |
| log\$1rotation\$1age | 60 | Minutos após os quais o arquivo de log é alternado automaticamente. É possível alterar esse valor no intervalo de 1 a e 1.440 minutos. Para obter mais informações, consulte [Configurar a alternância do arquivo de log](#USER_LogAccess.Concepts.PostgreSQL.log_rotation). |
| log\$1rotation\$1size | – | O tamanho (kB) no qual o log é alternado automaticamente. Por padrão, esse parâmetro não é usado porque os logs são trocados com base no parâmetro `log_rotation_age`. Para saber mais, consulte [Configurar a alternância do arquivo de log](#USER_LogAccess.Concepts.PostgreSQL.log_rotation). |
| rds.log\$1retention\$1period | 4320 | Os logs do PostgreSQL mais antigos que o número especificado de minutos são excluídos. O valor padrão de 4.320 minutos exclui os arquivos de log após três dias. Para ter mais informações, consulte [Definir o período de retenção de log](#USER_LogAccess.Concepts.PostgreSQL.log_retention_period). |
Para identificar problemas de aplicações, você pode procurar falhas de consulta, falhas de login, deadlocks e erros fatais de servidor no log. Por exemplo, suponha que você converta uma aplicação herdada do Oracle no Amazon RDS PostgreSQL, mas nem todas as consultas foram convertidas corretamente. Essas consultas formatadas incorretamente geram mensagens de erro nos logs, que você pode usar para identificar problemas. Para ter mais informações sobre o registro em log de consultas, consulte [Ativar o registro em log de consultas para a instância de banco de dados do RDS para PostgreSQL](USER_LogAccess.Concepts.PostgreSQL.Query_Logging.md).
Nos tópicos a seguir, você encontrará informações sobre como definir vários parâmetros que controlam os detalhes básicos de seus logs do PostgreSQL.
**Topics**
+ [Definir o período de retenção de log](#USER_LogAccess.Concepts.PostgreSQL.log_retention_period)
+ [Configurar a alternância do arquivo de log](#USER_LogAccess.Concepts.PostgreSQL.log_rotation)
+ [Definir o destino dos logs (`stderr`, `csvlog`)](#USER_LogAccess.Concepts.PostgreSQL.Log_Format)
+ [Noções básicas sobre o parâmetro log\$1line\$1prefix](#USER_LogAccess.Concepts.PostgreSQL.Log_Format.log-line-prefix)
## Definir o período de retenção de log
O parâmetro `rds.log_retention_period` especifica por quanto tempo sua instância de banco de dados do Aurora PostgreSQL mantém seus arquivos de log. A configuração padrão é de três dias (4.320 minutos), mas você pode definir esse valor de um dia (1.440 minutos) a sete dias (10.080 minutos). O A instância de banco de dados do RDS para PostgreSQL deve ter armazenamento suficiente para armazenar os arquivos de log durante o período.
Recomendamos que você publique habitualmente seus logs no Amazon CloudWatch Logs para que possa visualizar e analisar os dados do sistema muito tempo depois que os logs tiverem sido removidos do Instância de banco de dados do RDS para PostgreSQL. Para ter mais informações, consulte [Publicação de logs do PostgreSQL no Amazon CloudWatch Logs](USER_LogAccess.Concepts.PostgreSQL.md#USER_LogAccess.Concepts.PostgreSQL.PublishtoCloudWatchLogs).
## Configurar a alternância do arquivo de log
Por padrão, o Amazon RDS cria arquivos de log a cada hora. O tempo é controlado pelo parâmetro `log_rotation_age`. Esse parâmetro tem um valor padrão de 60 (minutos), mas você pode definir qualquer valor entre 1 minuto e 24 horas (1.440 minutos). Quando chegar o momento da alternância, será criado um novo arquivo de log distinto. O arquivo é nomeado de acordo com o padrão especificado pelo parâmetro `log_filename`.
Também é possível alternar os arquivos de log de acordo com o tamanho, conforme especificado no parâmetro `log_rotation_size`. Esse parâmetro especifica que o log deva ser alternado quando atingir o tamanho determinado (em kilobytes). Para uma instância de banco de dados do RDS para PostgreSQL, `log_rotation_size` não é definido, ou seja, não há valor especificado. No entanto, é possível definir o parâmetro de 0 a 2.097.151 kB (kilobytes).
Os nomes dos arquivos de log são baseados no padrão de nome do arquivo do parâmetro `log_filename`. As configurações disponíveis para esse parâmetro são as seguintes:
+ `postgresql.log.%Y-%m-%d`: formato padrão do nome do arquivo de log. Inclui o ano, o mês e a data no nome do arquivo de log.
+ `postgresql.log.%Y-%m-%d-%H`: inclui a hora no formato do nome do arquivo de log.
Para ter mais informações, 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) e [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) na documentação do PostgreSQL.
## Definir o destino dos logs (`stderr`, `csvlog`)
Por padrão, o Amazon RDS PostgreSQL gera logs no formato de erro padrão (stderr). Esse formato é a configuração padrão do parâmetro `log_destination`. Cada mensagem é prefixada usando o padrão especificado no parâmetro `log_line_prefix`. Para ter mais informações, consulte [Noções básicas sobre o parâmetro log\$1line\$1prefix](#USER_LogAccess.Concepts.PostgreSQL.Log_Format.log-line-prefix).
O RDS para PostgreSQL também pode gerar os registros no formato `csvlog`. O `csvlog` é útil para analisar os dados de log como dados de valores separados por vírgula (CSV). Por exemplo, digamos que você use a extensão `log_fdw` para trabalhar com seus logs como tabelas externas. A tabela externa criada nos arquivos de log do `stderr` contém uma única coluna com dados de eventos de log. Ao adicionar `csvlog` ao parâmetro `log_destination`, você obtém o arquivo de log no formato CSV com demarcações para as várias colunas da tabela externa. Agora você pode classificar e analisar os logs com maior facilidade. Para saber como usar o `log_fdw` com o `csvlog`, consulte [Usar a extensão log\$1fdw para acessar o log de banco de dados usando SQL](CHAP_PostgreSQL.Extensions.log_fdw.md).
Se você especificar `csvlog` para esse parâmetro, lembre-se de que os arquivos `stderr` e `csvlog` são gerados. Monitore o armazenamento consumido pelos logs, levando em consideração o `rds.log_retention_period` e outras configurações que afetam o armazenamento e a rotatividade dos logs. O uso de `stderr` e `csvlog` mais do que dobra o armazenamento consumido pelos logs.
Se você adicionar `csvlog` a `log_destination` e quiser reverter para o `stderr`, precisará redefinir o parâmetro. Para fazer isso, use o console do Amazon RDS e, depois, abra o grupo de parâmetros do banco de dados para sua instância. Selecione o parâmetro `log_destination`, **Edit parameter** (Editar parâmetro) e depois **Reset** (Redefinir).
Para ter mais informações sobre como configurar o registro em log, consulte [Trabalhar com logs do Amazon RDS e do Aurora PostgreSQL: parte 1](https://aws.amazon.com/blogs/database/working-with-rds-and-aurora-postgresql-logs-part-1/).
## Noções básicas sobre o parâmetro log\$1line\$1prefix
O formato de log `stderr` prefixa cada mensagem de log com os detalhes especificados pelo parâmetro `log_line_prefix`. O valor padrão é:
```
%t:%r:%u@%d:[%p]:t
```
A partir do Aurora PostgreSQL versão 16, você também pode escolher:
```
%m:%r:%u@%d:[%p]:%l:%e:%s:%v:%x:%c:%q%a
```
Cada entrada de log enviada para stderr inclui as seguintes informações com base no valor selecionado:
+ `%t`: hora da entrada do log sem milissegundos.
+ `%m`: hora da entrada do log com milissegundos.
+ `%r`: endereço do host remoto.
+ `%u@%d`: nome de usuário no nome do banco de dados.
+ `[%p]`: ID do processo, se disponível.
+ `%l`: número da linha de log por sessão.
+ `%e`: código de erro SQL.
+ `%s`: data e hora de início do processo.
+ `%v`: ID da transação virtual.
+ `%x`: ID da transação.
+ `%c`: ID da sessão.
+ `%q`: terminador não relacionado à sessão.
+ `%a`: nome da aplicação.
# Ativar o registro em log de consultas para a instância de banco de dados do RDS para PostgreSQL
Você pode coletar informações mais detalhadas sobre suas atividades de banco de dados, inclusive consultas, consultas à espera de bloqueios, pontos de verificação e muitos outros detalhes definindo alguns dos parâmetros listados na tabela a seguir. Este tópico se concentra no registro em log de consultas.
| Parâmetro | Padrão | Descrição |
| --- | --- | --- |
| log\$1connections | – | Registra cada conexão bem-sucedida. |
| log\$1disconnections | – | Registra o final de cada sessão e sua duração. |
| log\$1checkpoints | 1 | Registra em log cada ponto de verificação. |
| log\$1lock\$1waits | – | Registra esperas de bloqueio longas. Por padrão, esse parâmetro não está definido. |
| log\$1min\$1duration\$1sample | – | (ms) Define o tempo de execução mínimo acima do qual uma amostra de declarações será registrada. O tamanho da amostra é definido usando o parâmetro log\$1statement\$1sample\$1rate. |
| log\$1min\$1duration\$1statement | – | Todas as instruções SQL executadas pelo menos por um período especificado ou mais é registrada. Por padrão, esse parâmetro não está definido. Ativar esse parâmetro pode ajudar a encontrar consultas não otimizadas. |
| log\$1statement | – | Define o tipo de instruções registradas. Por padrão, esse parâmetro não está definido, mas você pode alterá-lo para `all`, `ddl` ou `mod` para especificar os tipos de declaração SQL que você deseja registrar. Se você especificar algo diferente de `none` para esse parâmetro, você também deve tomar medidas adicionais para evitar a exposição de senhas nos arquivos de log. Para ter mais informações, consulte [Reduzir o risco de exposição de senhas ao usar o registro em log de consultasReduzir o risco de exposição de senhas](#USER_LogAccess.Concepts.PostgreSQL.Query_Logging.mitigate-risk). |
| log\$1statement\$1sample\$1rate | – | A porcentagem de declarações que excedem o tempo especificado em `log_min_duration_sample` para serem registradas, expressa como um valor de ponto flutuante entre 0,0 e 1,0. |
| log\$1statement\$1stats | – | Grava estatísticas de desempenho cumulativas no log do servidor. |
## Usar o registro em log para encontrar consultas de baixa performance
Você pode registrar consultas e declarações SQL para ajudar a encontrar consultas com a performance lenta. Você ativa esse recurso modificando as configurações dos parâmetros `log_statement` e `log_min_duration` conforme descrito nesta seção. Antes de ativar o registro em log de consultas para sua instância de banco de dados do RDS para PostgreSQL, você deve estar ciente da possível exposição de senhas nos logs e de como reduzir os riscos. Para ter mais informações, consulte [Reduzir o risco de exposição de senhas ao usar o registro em log de consultasReduzir o risco de exposição de senhas](#USER_LogAccess.Concepts.PostgreSQL.Query_Logging.mitigate-risk).
A seguir, você encontrará informações de referência sobre os parâmetros `log_statement` e `log_min_duration`.log\$1statement
Esse parâmetro especifica o tipo de declarações SQL que devem ser enviadas ao log. O valor padrão é `none`. Se você alterar esse parâmetro para `all`, `ddl` ou `mod`, realize algumas das ações recomendadas para reduzir o risco de expor senhas nos logs. Para ter mais informações, consulte [Reduzir o risco de exposição de senhas ao usar o registro em log de consultasReduzir o risco de exposição de senhas](#USER_LogAccess.Concepts.PostgreSQL.Query_Logging.mitigate-risk).
**todas**
Registra todas as declarações. Essa configuração é recomendada para fins de depuração.
**ddl**
Registra todas as declarações de linguagem de definição de dados (DDL), como CREATE, ALTER, DROP etc.
**mod**
Registra todas as declarações DDL e declarações de linguagem de manipulação de dados (INSERT, UPDATE e DELETE) que modificam os dados.
**nenhuma**
Nenhuma declaração SQL é registrada. Recomendamos essa configuração para evitar o risco de expor senhas nos logs.log\$1min\$1duration\$1statement
Todas as instruções SQL executadas pelo menos por um período especificado ou mais é registrada. Por padrão, esse parâmetro não está definido. Ativar esse parâmetro pode ajudar a encontrar consultas não otimizadas.
**–1–2147483647**
O número de milissegundos (ms) de tempo de execução durante o qual uma declaração é registrada.
**Como configurar o registro em log de consultas**
Essas etapas pressupõem que o A instância de banco de dados do RDS para PostgreSQL usa um grupo de parâmetros de banco de dados personalizado.
1. Defina o parâmetro `log_statement` como `all`. O exemplo a seguir mostra a informação gravada no arquivo `postgresql.log`com essa configuração de parâmetro.
```
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. Defina o parâmetro `log_min_duration_statement`. O exemplo a seguir mostra a informação gravada no arquivo `postgresql.log` quando o parâmetro estiver definido como `1`.
As consultas que excedem a duração especificada no parâmetro `log_min_duration_statement` são registradas. Por exemplo: Você pode visualizar o arquivo de log de sua instância de banco de dados do RDS para PostgreSQL no console do 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 ----------------------
```
### Reduzir o risco de exposição de senhas ao usar o registro em log de consultas
Recomendamos manter `log_statement` definido como `none` para evitar a exposição de senhas. Se você definir `log_statement` como `all`, `ddl` ou`mod`, recomendamos que você siga uma ou mais destas etapas.
+ Para o cliente, criptografe informações confidenciais. Para ter mais informações consulte [Encryption Options](https://www.postgresql.org/docs/current/encryption-options.html) (Opções de criptografia) na documentação do PostgreSQL. Use as opções `ENCRYPTED` (e `UNENCRYPTED`) das declarações `CREATE` e `ALTER`. Para ter mais informações, consulte [CREATE USER](https://www.postgresql.org/docs/current/sql-createuser.html) na documentação do PostgreSQL.
+ Para instância de banco de dados do RDS para PostgreSQL, configure e use a extensão de auditoria do PostgreSQL (pgAudit). Essa extensão remove informações confidenciais das declarações CREATE e ALTER enviadas ao log. Para ter mais informações, consulte [Usar pgAudit para registrar a atividade do banco de dados](Appendix.PostgreSQL.CommonDBATasks.pgaudit.md).
+ Restringir o acesso aos logs CloudWatch.
+ Use mecanismos de autenticação mais fortes, como IAM.
## Publicação de logs do PostgreSQL no Amazon CloudWatch Logs
Para armazenar os registros de log do PostgreSQL em armazenamento resiliente, você pode usar o Amazon CloudWatch Logs. Com o CloudWatch Logs, é possível realizar análise em tempo real de dados e usar o CloudWatch para visualizar métricas e criar alarmes. Por exemplo, se você definir `log_statement` como `ddl`, poderá configurar um alarme para alertar sempre que uma declaração DDL for executada. Você pode optar por fazer upload dos logs do PostgreSQL no CloudWatch Logs durante o processo de criação de sua instância de banco de dados do RDS para PostgreSQL. Se você optar por não fazer upload de logs no momento, poderá modificar sua instância posteriormente para começar a fazer upload dos logs a partir desse momento. Em outras palavras, não é feito upload dos logs existentes. Só é feito upload de novos logs, pois eles são criados em sua instância de banco de dados do RDS para PostgreSQL modificada.
Todas as versões do RDS para PostgreSQL atualmente disponíveis são compatíveis com a publicação de arquivos de log no CloudWatch Logs. Para obter informações, consulte [Amazon RDS for PostgreSQL updates](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html) (Atualizações do Amazon RDS para PostgreSQL) nas *Amazon RDS for PostgreSQL Release Notes* (Notas de versão do Amazon RDS para PostgreSQL).
Para trabalhar com o CloudWatch Logs, configure o RDS para a instância de banco de dados do PostgreSQL para publicar dados de log a um grupo de log.
Você pode publicar os seguintes tipos de log no CloudWatch Logs do RDS do PostgreSQL:
+ Log do PostgreSQL
+ Log de atualização
+ Log de erros de autenticação de banco de dados do IAM
Depois que você concluir a configuração, o Amazon RDS publicará os eventos de log em fluxos de logs dentro de um grupo de logs do CloudWatch. Por exemplo, os dados de log do PostgreSQL são armazenados no grupo de logs `/aws/rds/instance/my_instance/postgresql`. Para visualizar os logs, abra o console do CloudWatch em [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
### Console
**Para publicar logs do PostgreSQL no CloudWatch Logs usando o console**
1. Abra o console do Amazon RDS em [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. No painel de navegação, escolha **Databases (Bancos de dados)**.
1. Escolha a instância de banco de dados que você deseja modificar e escolha **Modify (Modificar)**.
1. Na seção **Log exports (Exportações de log)**, escolha os logs que deseja começar a publicar no CloudWatch Logs.
A seção **Log exports (Exportações de log)** só está disponível para versões do PostgreSQL compatível com a publicação no CloudWatch Logs.
1. Escolha **Continue (Continuar)** e depois escolha **Modify DB Instance (Modificar instância de banco de dados)** na página de resumo.
### AWS CLI
Publique logs do PostgreSQL com a AWS CLI. Você pode chamar o comando [https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html) com os parâmetros a seguir.
+ `--db-instance-identifier`
+ `--cloudwatch-logs-export-configuration`
**nota**
Uma alteração feita na opção `--cloudwatch-logs-export-configuration` sempre é aplicada imediatamente na instância de banco de dados. Por isso, as opções `--apply-immediately` e `--no-apply-immediately` não entram em vigor.
Também publique logs do PostgreSQL chamando os seguintes comandos de CLI:
+ [https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html)
+ [https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-from-db-snapshot.html](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-from-db-snapshot.html)
+ [https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-to-point-in-time.html](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-to-point-in-time.html)
Execute um destes comandos da CLI com as seguintes opções:
+ `--db-instance-identifier`
+ `--enable-cloudwatch-logs-exports`
+ `--db-instance-class`
+ `--engine`
Outras opções podem ser obrigatórias, dependendo do comando da CLI executado.
**Example Modificar uma instância para publicar logs no CloudWatch Logs**
O exemplo a seguir modifica uma instância de banco de dados PostgreSQL existente para publicar arquivos de log em CloudWatch Logs. O valor `--cloudwatch-logs-export-configuration` é um objeto JSON. A chave desse objeto é `EnableLogTypes`, e o valor é uma matriz de strings com uma combinação qualquer de `postgresql` e `upgrade`.
Para Linux, macOS ou Unix:
```
1. aws rds modify-db-instance \
2. --db-instance-identifier mydbinstance \
3. --cloudwatch-logs-export-configuration '{"EnableLogTypes":["postgresql", "upgrade"]}'
```
Para Windows:
```
1. aws rds modify-db-instance ^
2. --db-instance-identifier mydbinstance ^
3. --cloudwatch-logs-export-configuration '{"EnableLogTypes":["postgresql","upgrade"]}'
```
**Example Criar uma instância para publicar logs no CloudWatch Logs**
O exemplo a seguir cria uma instância de banco de dados PostgreSQL e publica arquivos de log em CloudWatch Logs. O valor `--enable-cloudwatch-logs-exports` é uma matriz de strings JSON. As strings podem ser uma combinação qualquer de `postgresql` e `upgrade`.
Para Linux, macOS ou Unix:
```
1. aws rds create-db-instance \
2. --db-instance-identifier mydbinstance \
3. --enable-cloudwatch-logs-exports '["postgresql","upgrade"]' \
4. --db-instance-class db.m4.large \
5. --engine postgres
```
Para Windows:
```
1. aws rds create-db-instance ^
2. --db-instance-identifier mydbinstance ^
3. --enable-cloudwatch-logs-exports '["postgresql","upgrade"]' ^
4. --db-instance-class db.m4.large ^
5. --engine postgres
```
### API do RDS
Publique logs do PostgreSQL com a API do RDS. Você pode chamar a ação [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html) com os seguintes parâmetros:
+ `DBInstanceIdentifier`
+ `CloudwatchLogsExportConfiguration`
**nota**
Uma alteração feita no parâmetro `CloudwatchLogsExportConfiguration` sempre é aplicada imediatamente na instância de banco de dados. Por isso, o parâmetro `ApplyImmediately` não entra em vigor.
Também é possível publicar logs do PostgreSQL chamando as seguintes operações da API do RDS:
+ [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBInstance.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBInstance.html)
+ [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBInstanceFromDBSnapshot.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBInstanceFromDBSnapshot.html)
+ [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBInstanceToPointInTime.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBInstanceToPointInTime.html)
Execute uma destas operações da API do RDS com os seguintes parâmetros:
+ `DBInstanceIdentifier`
+ `EnableCloudwatchLogsExports`
+ `Engine`
+ `DBInstanceClass`
Outros parâmetros podem ser obrigatórios, dependendo da operação executada.