# Arquivos de log do banco de dados AuroraMySQL
Você pode monitorar os logs do Aurora 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 Aurora](USER_LogAccess.md).
**Topics**
+ [Visão geral dos logs de banco de dados do Aurora MySQL](USER_LogAccess.MySQL.LogFileSize.md)
+ [Enviar a saída de log do AuroraMySQL para tabelas](Appendix.MySQL.CommonDBATasks.Logs.md)
+ [Configurar o registro em log binário do Aurora MySQL para bancos de dados single-AZ](USER_LogAccess.MySQL.BinaryFormat.md)
+ [Acessar logs binários do MySQL](USER_LogAccess.MySQL.Binarylog.md)
# Visão geral dos logs de banco de dados do Aurora MySQL
Você pode monitorar os seguintes tipos de arquivos de log do Aurora 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 Aurora 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 Aurora MySQL](#USER_LogAccess.MySQL.Errorlog)
+ [Logs gerais e de consultas lentas do Aurora MySQL](#USER_LogAccess.MySQL.Generallog)
+ [Log de auditoria do Aurora MySQL](#ams-audit-log)
+ [Log de instâncias do Aurora MySQL](#ams-instance-log)
+ [Alternância e retenção de logs do Aurora MySQL](#USER_LogAccess.AMS.LogFileSize.retention)
+ [Publicar logs do Aurora MySQL no Amazon CloudWatch Logs](#USER_LogAccess.MySQLDB.PublishAuroraMySQLtoCloudWatchLogs)
## Logs de erro do Aurora MySQL
O Aurora 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 Aurora 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 Aurora 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 Aurora MySQL alterna o arquivo `mysql-error-running.log` de hora em hora.
**nota**
Observe que o período de retenção é diferente entre o Amazon RDS e o Aurora.
## Logs gerais e de consultas lentas do Aurora MySQL
É possível gravar o log de consultas lentas e o log geral do Aurora 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 Aurora](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 Aurora 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** : 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.
Em relação ao Aurora MySQL versões 2 e 3, o padrão de `log_output` é `FILE`.
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 Aurora MySQL
O registro em log de auditoria do Aurora MySQL é chamado de Auditoria avançada. Para ativar a Auditoria avançada, defina determinados parâmetros de cluster de banco de dados. Para obter mais informações, consulte [Como utilizar a auditoria avançada em um cluster de banco de dados do Amazon Aurora MySQL](AuroraMySQL.Auditing.md).
## Log de instâncias do Aurora MySQL
O Aurora cria um arquivo de log separado para instâncias de banco de dados que têm a pausa automática habilitada. Esse arquivo instance.log registra todos os motivos pelos quais essas não foi possível pausar as instâncias de banco de dados quando esperado. Para ter mais informações sobre o comportamento do arquivo de log da instância e o recurso de pausa automática do Aurora, consulte [Monitorar a atividade de pausa e retomada do Aurora Serverless v2](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-serverless-v2-administration.html#autopause-logging-instance-log).
## Alternância e retenção de logs do Aurora MySQL
Quando o registro em log está ativado, o Amazon Aurora alterna ou exclui os 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 Aurora MySQL lida com a alternância e a exclusão da seguinte forma:
+ Os tamanhos dos arquivos de log de erros do Aurora MySQL são limitados a 15% do armazenamento local para uma instância de banco de dados. Para manter esse limite, os logs são alternados automaticamente a cada hora. O Aurora MySQL remove logs após 30 dias ou quando 15% do espaço em disco são atingidos. 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.
+ O Aurora MySQL removerá os logs de auditoria, gerais e de consulta lenta após 24 horas ou quando 15% do armazenamento tiver sido usado.
+ Quando o registro em log `FILE` está ativado, os arquivos de log geral e de consulta lenta são examinados a cada hora, e os arquivos de log com mais de 24 horas 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 15% do espaço local 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 em log de `TABLE` está ativado, as tabelas de log não são alternadas nem excluídas. As tabelas de log são truncadas quando o tamanho de todos os logs combinados é grande demais. Você pode assinar a categoria de evento `low storage` para ser notificado quando for necessário alternar ou excluir manualmente tabelas de logs para liberar espaço. Para obter mais informações, consulte [Trabalhar com a notificação de eventos do Amazon RDS](USER_Events.md).
Você pode alternar 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`.
Quando você alterna as tabelas de logs manualmente, a tabela de logs atual é copiada em uma tabela de logs de backup, e 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`.
+ Os logs de auditoria do Aurora MySQL são alternados quando o tamanho do arquivo atinge 100 MB e são removidos após 24 horas.
+ O Amazon RDS alterna os arquivos de log de erros de autenticação de banco de dados do IAM maiores que 10 MB. O Amazon RDS remove os arquivos de log de erros de autenticação de banco de dados do IAM com mais de cinco dias ou maiores que 100 MB.
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 Aurora MySQL, esses arquivos de log são alternados por hora. Os arquivos de log que foram gerados durante as 24 horas anteriores são retidos. Observe que o período de retenção é diferente entre o Amazon RDS e o Aurora.
## Publicar logs do Aurora MySQL no Amazon CloudWatch Logs
É possível configurar seu cluster de bancos de dados Aurora MySQL para publicar dados de log em um grupo 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. Para obter mais informações, consulte [Publicar logs do Amazon Aurora MySQL no Amazon CloudWatch Logs](AuroraMySQL.Integrating.CloudWatch.md).
# Enviar a saída de log do AuroraMySQL 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 Aurora 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 Aurora 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 Aurora 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.
Os logs binários só podem ser acessados pela instância de banco de dados primária, não pelas réplicas.
O MySQL no Amazon Aurora é 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 Aurora 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 o cluster 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 no cluster de banco de dados. Você pode monitorar o uso de IOPS com a métrica ```VolumeWriteIOPs` 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 cluster de banco de dados associado ao cluster de banco de dados que você deseja modificar.
Não é possível modificar um grupo de parâmetros padrão. Se o cluster de banco de dados estiver usando um grupo de parâmetros padrão, crie outro grupo de parâmetros e o associe ao cluster de banco de dados.
Para ter mais informações sobre grupos de parâmetros, consulte [Grupos de parâmetros para Amazon Aurora](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ê também pode usar o valor `OFF` para desativar o registro em log binário.
**nota**
Definir `binlog_format` como `OFF` no grupo de parâmetros do cluster de banco de dados desativa a variável de sessão `log_bin`. Isso desabilita o registro em log binário no cluster de banco de dados do Aurora 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.
1. Escolha **Salvar alterações** para salvar as atualizações no grupo de parâmetros do cluster de banco de dados.
Depois de realizar essas etapas, você deve reinicializar a instância do gravador no cluster de banco de dados para que suas alterações sejam aplicadas. No Aurora MySQL versão 2.09 e anteriores, quando você reinicializa a instância do gravador, todas as instâncias do leitor no cluster de banco de dados também são reinicializadas. No Aurora MySQL versão 2.10 e posteriores, você deve reinicializar todas as instâncias do leitor manualmente. Para obter mais informações, consulte [Reinicializar um cluster de banco de dados do Amazon Aurora ou instância de banco de dados do Amazon Aurora](USER_RebootCluster.md).
**Importante**
Alterar um grupo de parâmetros de cluster de banco de dados afeta todos os clusters 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 clusters de bancos de dados Aurora MySQL em uma região da AWS, os clusters de banco de dados deverão usar diferentes grupos de parâmetros de cluster de banco de dados. Esses grupos de parâmetros identificam diferentes formatos de log. Atribua o grupo de parâmetros de cluster de banco de dados apropriado a cada cluster de banco de dados. Para ter mais informações sobre parâmetros do Aurora MySQL, consulte [Parâmetros de configuração do Aurora MySQL](AuroraMySQL.Reference.ParameterGroups.md).
# 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;
```