# Referência do Amazon Aurora MySQL
Esta referência inclui informações sobre parâmetros do Aurora MySQL, variáveis de status e extensões SQL gerais ou diferenças do mecanismo de banco de dados MySQL da comunidade.
**Topics**
+ [Parâmetros de configuração do Aurora MySQL](AuroraMySQL.Reference.ParameterGroups.md)
+ [Variáveis de status globais do Aurora MySQL](AuroraMySQL.Reference.GlobalStatusVars.md)
+ [Eventos de espera do Aurora MySQL](AuroraMySQL.Reference.Waitevents.md)
+ [Estados de threads do Aurora MySQL](AuroraMySQL.Reference.thread-states.md)
+ [Níveis de isolamento do Aurora MySQL](AuroraMySQL.Reference.IsolationLevels.md)
+ [Dicas do Aurora MySQL](AuroraMySQL.Reference.Hints.md)
+ [Referência de procedimentos armazenados do Aurora MySQL](AuroraMySQL.Reference.StoredProcs.md)
+ [Tabelas information\$1schema específicas do Aurora MySQL](AuroraMySQL.Reference.ISTables.md)
# Parâmetros de configuração do Aurora MySQL
Você gerencia o cluster de bancos de dados Amazon Aurora MySQL da mesma maneira que gerencia outras instâncias de banco de dados do Amazon RDS, usando parâmetros em um grupo de parâmetros de banco de dados. O Amazon Aurora é diferente de outros mecanismos de banco de dados porque você tem um cluster de banco de dados contendo várias instâncias de banco de dados. Como resultado, alguns dos parâmetros que você usa para gerenciar seu cluster de bancos de dados Aurora MySQL aplicam-se a todo o cluster. Outros parâmetros aplicam-se apenas a uma instância de banco de dados particular no cluster de banco de dados.
Para gerenciar parâmetros no nível do cluster, use grupos de parâmetros de cluster de banco de dados. Para gerenciar parâmetros no nível da instância, use grupos de parâmetros de banco de dados. Cada instância de banco de dados em um cluster de bancos de dados Aurora MySQL é compatível com o mecanismo de banco de dados MySQL. No entanto, aplique alguns parâmetros do mecanismo de banco de dados do MySQL no nível do cluster e gerencie esses parâmetros usando grupos de parâmetros do cluster de banco de dados. Você não consegue encontrar parâmetros em nível de cluster no grupo de parâmetros de banco de dados para uma instância em um cluster de bancos de dados Aurora. Uma lista de parâmetros em nível de cluster é exibida mais adiante neste tópico.
Você pode gerenciar parâmetros no nível do cluster e no nível da instância usando o Console de gerenciamento da AWS, a AWS CLI, ou a API do Amazon RDS. Use comandos separados para gerenciar parâmetros no nível do cluster e parâmetros no nível da instância. Por exemplo, você pode usar o comando da CLI [modify-db-cluster-parameter-group](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster-parameter-group.html) para gerenciar parâmetros em nível do cluster em um grupo de parâmetros de cluster de banco de dados. É possível usar o comando da CLI [modify-db-parameter-group](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-parameter-group.html) para gerenciar parâmetros em nível de instância em um grupo de parâmetros de banco de dados para uma instância de banco de dados em um cluster de banco de dados.
Você pode visualizar parâmetros em nível de cluster e em nível de instância no console ou usando a CLI ou a API do RDS. Por exemplo, você pode usar o comando [describe-db-cluster-parameters](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-cluster-parameters.html) da AWS CLI para visualizar parâmetros em nível de cluster em um grupo de parâmetros de cluster de banco de dados. É possível usar o comando da CLI [describe-db-parameters](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-parameters.html) para gerenciar parâmetros em nível de instância em um grupo de parâmetros de banco de dados para uma instância de banco de dados em um cluster de banco de dados.
**nota**
Cada [grupo de parâmetros padrão](USER_WorkingWithParamGroups.md) contém os valores padrão para todos os parâmetros no grupo. Se o parâmetro tiver “engine default” (padrão do mecanismo) para esse valor, consulte a documentação específica da versão do MySQL ou PostgreSQL quanto o valor padrão real.
Salvo indicação em contrário, os parâmetros listados nas tabelas a seguir são válidos para as versões 2 e 3 do Aurora MySQL.
Para ter mais informações sobre os grupos de parâmetros de banco de dados, consulte [Grupos de parâmetros para Amazon Aurora](USER_WorkingWithParamGroups.md). Para conhecer as regras e restrições para clusters Aurora Serverless v1, consulte [Grupos de parâmetros para Aurora Serverless v1](aurora-serverless-v1.how-it-works.md#aurora-serverless.parameter-groups).
**Topics**
+ [Parâmetros no nível do cluster](#AuroraMySQL.Reference.Parameters.Cluster)
+ [Parâmetros no nível da instância](#AuroraMySQL.Reference.Parameters.Instance)
+ [Parâmetros do MySQL não se aplicam ao Aurora MySQL](#AuroraMySQL.Reference.Parameters.Inapplicable)
## Parâmetros no nível do cluster
A tabela a seguir mostra todos os parâmetros que se aplicam a todo o cluster de bancos de dados Aurora MySQL.
| Nome do parâmetro | Permite modificação | Observações |
| --- | --- | --- |
| `aurora_binlog_read_buffer_size` | Sim | Só afeta clusters que usam replicação de log binário (binlog). Para obter informações sobre replicação de log binário, consulte [Replicação entre Aurora e o MySQL ou entre Aurora e outro cluster de banco de dados do Aurora (replicação de log binário)](AuroraMySQL.Replication.MySQL.md). Retirado do Aurora MySQL versão 3. |
| `aurora_binlog_replication_max_yield_seconds` | Sim | Só afeta clusters que usam replicação de log binário (binlog). Para obter informações sobre replicação de log binário, consulte [Replicação entre Aurora e o MySQL ou entre Aurora e outro cluster de banco de dados do Aurora (replicação de log binário)](AuroraMySQL.Replication.MySQL.md). |
| `aurora_binlog_replication_sec_index_parallel_workers` | Sim | Define o número total de threads paralelos disponíveis para aplicar alterações de índice secundário ao replicar transações para tabelas grandes com mais de um índice secundário. O parâmetro é definido como `0` (desabilitado) por padrão. Esse parâmetro está disponível no Aurora MySQL versão 306 e posteriores. Para ter mais informações, consulte [Otimizar a replicação de logs binários para Aurora MySQL](binlog-optimization.md). |
| `aurora_binlog_use_large_read_buffer` | Sim | Só afeta clusters que usam replicação de log binário (binlog). Para obter informações sobre replicação de log binário, consulte [Replicação entre Aurora e o MySQL ou entre Aurora e outro cluster de banco de dados do Aurora (replicação de log binário)](AuroraMySQL.Replication.MySQL.md). Retirado do Aurora MySQL versão 3. |
| `aurora_disable_hash_join` | Sim | Defina esse parâmetro como `ON` para desativar a otimização de junções de hash no Aurora MySQL versão 2.09 ou posterior. Não há suporte para a versão 3. Para ter mais informações, consulte [Consulta paralela do Amazon Aurora MySQL](aurora-mysql-parallel-query.md). |
| `aurora_enable_replica_log_compression` | Sim | Para ter mais informações, consulte [Considerações sobre performance da replicação do Amazon Aurora MySQL](AuroraMySQL.Replication.md#AuroraMySQL.Replication.Performance). Não se aplica a clusters que fazem parte de um banco de dados global Aurora. Retirado do Aurora MySQL versão 3. |
| `aurora_enable_repl_bin_log_filtering` | Sim | Para ter mais informações, consulte [Considerações sobre performance da replicação do Amazon Aurora MySQL](AuroraMySQL.Replication.md#AuroraMySQL.Replication.Performance). Não se aplica a clusters que fazem parte de um banco de dados global Aurora. Retirado do Aurora MySQL versão 3. |
| `aurora_enable_staggered_replica_restart` | Sim | Essa configuração está disponível no Aurora MySQL versão 3, mas não é usada. |
| `aurora_enable_zdr` | Sim | Essa configuração é ativada por padrão no Aurora MySQL 2.10 e posterior. Para ter mais informações, consulte [Zero-downtime restart (ZDR – Reinício com tempo de inatividade zero) para Amazon Aurora MySQL](AuroraMySQL.Replication.Availability.md). |
| `aurora_enhanced_binlog` | Sim | Defina o valor desse parâmetro como 1 para ativar o log binário avançado no Aurora MySQL versão 3.03.1 e posterior. Para ter mais informações, consulte [Configurar o log binário avançado para Aurora MySQL](AuroraMySQL.Enhanced.binlog.md). |
| `aurora_jemalloc_background_thread` | Sim | Use esse parâmetro para permitir que um thread em segundo plano execute operações de manutenção de memória. Os valores permitidos são `0` (desabilitado) e `1` (habilitado). O valor padrão é `0`. Esse parâmetro é aplicável ao Aurora MySQL versão 3.05 e posterior. |
| `aurora_jemalloc_dirty_decay_ms` | Sim | Use esse parâmetro para reter a memória liberada por um período especificado (em milissegundos). A retenção da memória permite uma reutilização mais rápida. Os valores permitidos são `0`–`18446744073709551615`. O valor padrão (`0`) retorna toda a memória para o sistema operacional como memória liberável. Esse parâmetro é aplicável ao Aurora MySQL versão 3.05 e posterior. |
| `aurora_jemalloc_tcache_enabled` | Sim | Use esse parâmetro para atender a pequenas solicitações de memória (até 32 KiB) em um cache local de thread, ignorando as arenas de memória. Os valores permitidos são `0` (desabilitado) e `1` (habilitado). O valor padrão é `1`. Esse parâmetro é aplicável ao Aurora MySQL versão 3.05 e posterior. |
| `aurora_load_from_s3_role` | Sim | Para ter mais informações, consulte [Carregar dados em um cluster de banco de dados do Amazon Aurora MySQL a partir de arquivos de texto em um bucket do Amazon S3](AuroraMySQL.Integrating.LoadFromS3.md). No momento indisponível no Aurora MySQL versão 3. Usar `aws_default_s3_role`. |
| `aurora_mask_password_hashes_type` | Sim | Essa configuração é ativada por padrão no Aurora MySQL 2.11 e posterior. Use essa configuração para mascarar os hashes de senha do Aurora MySQL nos logs de consultas lentas e de auditoria. Os valores permitidos são `0` e `1` (padrão). Quando definido como `1`, as senhas são registradas como ``. Quando definido como `0`, as senhas são registradas como valores de hash (`#`). |
| `aurora_select_into_s3_role` | Sim | Para ter mais informações, consulte [Salvar dados a partir de um cluster de banco de dados do Amazon Aurora MySQL em arquivos de texto de um bucket do Amazon S3](AuroraMySQL.Integrating.SaveIntoS3.md). No momento indisponível no Aurora MySQL versão 3. Usar `aws_default_s3_role`. |
| `authentication_kerberos_caseins_cmp` | Sim | Controla a comparação de nomes de usuário sem distinção entre maiúsculas e minúsculas para o plug-in `authentication_kerberos`. Defina-o como `true` para comparação sem distinção entre maiúsculas e minúsculas. Por padrão, é usada a comparação com distinção entre maiúsculas e minúsculas (`false`). Para ter mais informações, consulte [Usar a autenticação Kerberos para Aurora MySQL](aurora-mysql-kerberos.md). Esse parâmetro está disponível no Aurora MySQL versão 3.03 e posteriores. |
| `auto_increment_increment` | Sim | |
| `auto_increment_offset` | Sim | |
| `aws_default_lambda_role` | Sim | Para ter mais informações, consulte [Invocar uma função do Lambda a partir de um cluster de banco de dados do Amazon Aurora MySQL](AuroraMySQL.Integrating.Lambda.md). |
| `aws_default_s3_role` | Sim | Usado ao invocar a instrução `LOAD DATA FROM S3`, `LOAD XML FROM S3` ou `SELECT INTO OUTFILE S3` do seu cluster de banco de dados. No Aurora MySQL versão 2, o perfil do IAM especificado nesse parâmetro será usado se não for especificado um perfil do IAM para `aurora_load_from_s3_role` ou `aurora_select_into_s3_role` para a instrução apropriada. No Aurora MySQL versão 3, o perfil do IAM especificado para esse parâmetro sempre é usado. Para ter mais informações, consulte [Associar uma função do IAM a um cluster de banco de dados do Amazon Aurora MySQL](AuroraMySQL.Integrating.Authorizing.IAM.AddRoleToDBCluster.md). |
| `binlog_backup` | Sim | Defina o valor desse parâmetro como 0 para ativar o log binário avançado no Aurora MySQL versão 3.03.1 e posterior. É possível desativar esse parâmetro somente ao usar o log binário avançado. Para ter mais informações, consulte [Configurar o log binário avançado para Aurora MySQL](AuroraMySQL.Enhanced.binlog.md). |
| `binlog_checksum` | Sim | A API do RDS e AWS CLI reportam um valor de `None` se esse parâmetro não estiver definido. Nesse caso, Aurora MySQL usa o valor padrão do mecanismo, que é `CRC32`. Isso é diferente da configuração explícita de `NONE`, que desativa a soma de verificação. |
| `binlog-do-db` | Sim | Este parâmetro é aplicável ao Aurora MySQL versão 3. |
| `binlog_format` | Sim | Para ter mais informações, consulte [Replicação entre Aurora e o MySQL ou entre Aurora e outro cluster de banco de dados do Aurora (replicação de log binário)](AuroraMySQL.Replication.MySQL.md). |
| `binlog_group_commit_sync_delay` | Sim | Este parâmetro é aplicável ao Aurora MySQL versão 3. |
| `binlog_group_commit_sync_no_delay_count` | Sim | Este parâmetro é aplicável ao Aurora MySQL versão 3. |
| `binlog-ignore-db` | Sim | Este parâmetro é aplicável ao Aurora MySQL versão 3. |
| `binlog_replication_globaldb` | Sim | Defina o valor desse parâmetro como 0 para ativar o log binário avançado no Aurora MySQL versão 3.03.1 e posterior. É possível desativar esse parâmetro somente ao usar o log binário avançado. Para ter mais informações, consulte [Configurar o log binário avançado para Aurora MySQL](AuroraMySQL.Enhanced.binlog.md). |
| `binlog_row_image` | Não | |
| `binlog_row_metadata` | Sim | Este parâmetro é aplicável ao Aurora MySQL versão 3. |
| `binlog_row_value_options` | Sim | Este parâmetro é aplicável ao Aurora MySQL versão 3. |
| `binlog_rows_query_log_events` | Sim | |
| `binlog_transaction_compression` | Sim | Este parâmetro é aplicável ao Aurora MySQL versão 3. |
| `binlog_transaction_compression_level_zstd` | Sim | Este parâmetro é aplicável ao Aurora MySQL versão 3. |
| `binlog_transaction_dependency_history_size` | Sim | Esse parâmetro define um limite superior para o número de hashes de linha que são mantidos na memória e usados para pesquisar a transação que modificou pela última vez uma linha específica. Depois que esse número de hashes for atingido, o histórico será eliminado. Esse parâmetro se aplica ao Aurora MySQL versão 2.12 e posterior e versão 3. |
| `binlog_transaction_dependency_tracking` | Sim | Este parâmetro é aplicável ao Aurora MySQL versão 3. |
| `character-set-client-handshake` | Sim | |
| `character_set_client` | Sim | |
| `character_set_connection` | Sim | |
| `character_set_database` | Sim | |
| `character_set_filesystem` | Sim | |
| `character_set_results` | Sim | |
| `character_set_server` | Sim | |
| `collation_connection` | Sim | |
| `collation_server` | Sim | |
| `completion_type` | Sim | |
| `default_storage_engine` | Não | Os clusters do Aurora MySQL usam o mecanismo de armazenamento InnoDB para todos os dados. |
| `enforce_gtid_consistency` | Às vezes | Modificável no Aurora MySQL versão 2 e posterior. |
| `event_scheduler` | Sim | Indica o status do programador de eventos. Modificável somente no nível do cluster no Aurora MySQL versão 3. |
| `gtid-mode` | Às vezes | Modificável no Aurora MySQL versão 2 e posterior. |
| `information_schema_stats_expiry` | Sim | O número de segundos após os quais o servidor de banco de dados MySQL busca dados do mecanismo de armazenamento e os substitui no cache. Os valores permitidos são `0`–`31536000`. Este parâmetro é aplicável ao Aurora MySQL versão 3. |
| `init_connect` | Sim | O comando a ser executado pelo servidor para cada cliente conectado. Use aspas duplas (“) nas configurações para evitar falhas de conexão, por exemplo: SET optimizer_switch="hash_join=off"
No Aurora MySQL versão 3, esse parâmetro não se aplica aos usuários que têm o privilégio `CONNECTION_ADMIN`. Isso inclui o usuário principal do Aurora. Para ter mais informações, consulte [Modelo de privilégios baseados em funções](AuroraMySQL.Compare-80-v3.md#AuroraMySQL.privilege-model). |
| `innodb_adaptive_hash_index` | Sim | É possível modificar esse parâmetro no nível do cluster de banco de dados no Aurora MySQL versões 2 e 3. O Adaptive Hash Index não é compatível com instâncias de banco de dados de leitor. |
| `innodb_aurora_instant_alter_column_allowed` | Sim | Controla se o algoritmo `INSTANT` pode ser usado para operações `ALTER COLUMN` em nível global. Os valores permitidos são os seguintes: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Reference.ParameterGroups.html) Para obter mais informações, consulte [Operações de coluna](https://dev.mysql.com/doc/refman/8.0/en/innodb-online-ddl-operations.html#online-ddl-column-operations) na documentação do MySQL. Esse parâmetro é aplicável ao Aurora MySQL versão 3.05 e posterior. |
| `innodb_autoinc_lock_mode` | Sim | |
| `innodb_checksums` | Não | Retirado do Aurora MySQL versão 3. |
| `innodb_cmp_per_index_enabled` | Sim | |
| `innodb_commit_concurrency` | Sim | |
| `innodb_data_home_dir` | Não | O Aurora MySQL utiliza instâncias gerenciadas em que não é possível acessar o sistema de arquivos diretamente. |
| `innodb_deadlock_detect` | Sim | Esta opção é usada para desabilitar a detecção de deadlock no Aurora MySQL versão 2.11 e posterior e versão 3. Em sistemas de alta simultaneidade, a detecção de deadlock pode causar uma desaceleração quando vários segmentos aguardam o mesmo bloqueio. Consulte a documentação do MySQL para obter mais informações sobre esse parâmetro. |
| `innodb_default_row_format` | Sim | Esse parâmetro define o formato de linha padrão para tabelas do InnoDB (incluindo tabelas temporárias do InnoDB criadas pelo usuário). Aplica-se ao Aurora MySQL versões 2 e 3. Os valores podem ser `DYNAMIC`, `COMPACT` ou `REDUNDANT.` |
| `innodb_file_per_table` | Sim | Esse parâmetro afeta como o armazenamento de tabela é organizado. Para ter mais informações, consulte [Escalabilidade de armazenamento](Aurora.Managing.Performance.md#Aurora.Managing.Performance.StorageScaling). |
| `innodb_flush_log_at_trx_commit` | Sim | É altamente recomendável usar o valor padrão de `1`. No Aurora MySQL versão 3, antes de definir esse parâmetro como um valor diferente de `1`, é necessário definir o valor de `innodb_trx_commit_allow_data_loss` como `1`. Para ter mais informações, consulte [Configurar a frequência com que o buffer de log é liberado](AuroraMySQL.BestPractices.FeatureRecommendations.md#AuroraMySQL.BestPractices.Flush). |
| `innodb_ft_max_token_size` | Sim | |
| `innodb_ft_min_token_size` | Sim | |
| `innodb_ft_num_word_optimize` | Sim | |
| `innodb_ft_sort_pll_degree` | Sim | |
| `innodb_online_alter_log_max_size` | Sim | |
| `innodb_optimize_fulltext_only` | Sim | |
| `innodb_page_size` | Não | |
| `innodb_print_all_deadlocks` | Sim | Quando ativado, registra informações sobre todos os deadlocks do InnoDB no log de erros do Aurora MySQL. Para ter mais informações, consulte [Minimizar e solucionar problemas de deadlocks do Aurora MySQL](AuroraMySQL.BestPractices.FeatureRecommendations.md#AuroraMySQL.BestPractices.deadlocks). |
| `innodb_purge_batch_size` | Sim | |
| `innodb_purge_threads` | Sim | |
| `innodb_rollback_on_timeout` | Sim | |
| `innodb_rollback_segments` | Sim | |
| `innodb_spin_wait_delay` | Sim | |
| `innodb_strict_mode` | Sim | |
| `innodb_support_xa` | Sim | Retirado do Aurora MySQL versão 3. |
| `innodb_sync_array_size` | Sim | |
| `innodb_sync_spin_loops` | Sim | |
| `innodb_stats_include_delete_marked` | Sim | Quando esse parâmetro está habilitado, o InnoDB inclui registros marcados com exclusão ao calcular estatísticas persistentes do otimizador. Esse parâmetro se aplica ao Aurora MySQL versão 2.12 e posterior e versão 3. |
| `innodb_table_locks` | Sim | |
| `innodb_trx_commit_allow_data_loss` | Sim | No Aurora MySQL versão 3, defina o valor desse parâmetro como `1` para que você possa alterar o valor de `innodb_flush_log_at_trx_commit`. O valor padrão de `innodb_trx_commit_allow_data_loss` é `0`. Para ter mais informações, consulte [Configurar a frequência com que o buffer de log é liberado](AuroraMySQL.BestPractices.FeatureRecommendations.md#AuroraMySQL.BestPractices.Flush). |
| `innodb_undo_directory` | Não | O Aurora MySQL utiliza instâncias gerenciadas em que não é possível acessar o sistema de arquivos diretamente. |
| `internal_tmp_disk_storage_engine` | Sim | Controla qual mecanismo de armazenamento na memória é usado para tabelas temporárias internas. Os valores permitidos são `INNODB` e `MYISAM`. Este parâmetro é aplicável ao Aurora MySQL versão 2. |
| `internal_tmp_mem_storage_engine` | Sim | Controla qual mecanismo de armazenamento na memória é usado para tabelas temporárias internas. Os valores permitidos são `MEMORY` e `TempTable`. Este parâmetro é aplicável ao Aurora MySQL versão 3. |
| `key_buffer_size` | Sim | Cache de chaves para tabelas MyISAM. Para ter mais informações, consulte [keycache->cache\$1lock mutex](AuroraMySQL.Reference.Waitevents.md#key-cache.cache-lock). |
| `lc_time_names` | Sim | |
| `log_error_suppression_list` | Sim | Especifica uma lista de códigos de erros que não estão registrados no log de erros do MySQL. Isso permite que você ignore certas condições de erro não críticas para ajudar a manter seus logs de erros limpos. Para ter mais informações, consulte [log\$1error\$1suppression\$1list](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_log_error_suppression_list) na documentação do MySQL. Esse parâmetro é aplicável ao Aurora MySQL versão 3.03 e posterior. |
| `low_priority_updates` | Sim | As operações `INSERT`, `UPDATE`, `DELETE` e `LOCK TABLE WRITE` aguardam até que não haja nenhuma operação `SELECT` pendente. Esse parâmetro só afeta mecanismos de armazenamento que usam apenas bloqueio em nível de tabela (MyISAM, MEMORY, MERGE). Este parâmetro é aplicável ao Aurora MySQL versão 3. |
| `lower_case_table_names` | Sim (Aurora MySQL versão 2) Somente no momento da criação do cluster (Aurora MySQL versão 3) | No Aurora MySQL versão 2.10 e versões 2.x posteriores, certifique-se de reinicializar todas as instâncias de leitor depois de alterar essa configuração e de reinicializar a instância de gravador. Para obter detalhes, consulte [Reinicializar um cluster do Aurora com disponibilidade de leitura](aurora-mysql-survivable-replicas.md). No Aurora MySQL versão 3, o valor desse parâmetro é definido permanentemente no momento da criação do cluster. Se você utilizar um valor não padrão para essa opção, configure o grupo de parâmetros personalizado do Aurora MySQL versão 3 antes do upgrade e especifique o grupo de parâmetros durante a operação de restauração do snapshot que cria o cluster da versão 3. Com um banco de dados Aurora global baseado no Aurora MySQL, você não poderá executar uma atualização no local do Aurora MySQL versão 2 para a versão 3 se o parâmetro `lower_case_table_names` estiver ativado. Para ter mais informações sobre os métodos que você pode usar, consulte [Atualizações de versão principal](aurora-global-database-upgrade.md#aurora-global-database-upgrade.major). |
| `master-info-repository` | Sim | Retirado do Aurora MySQL versão 3. |
| `master_verify_checksum` | Sim | Aurora MySQL versão 2. Use `source_verify_checksum` no Aurora MySQL versão 3. |
| `max_delayed_threads` | Sim | Define o número máximo de threads para lidar com instruções `INSERT DELAYED`. Este parâmetro é aplicável ao Aurora MySQL versão 3. |
| `max_error_count` | Sim | O número máximo de mensagens de erro, advertência e observação que devem ser armazenadas para exibição. Este parâmetro é aplicável ao Aurora MySQL versão 3. |
| `max_execution_time` | Sim | O tempo limite para executar declarações `SELECT`, em milissegundos. O valor pode ser de `0` a `18446744073709551615`. Quando definido como `0`, não há tempo limite. Para ter mais informações, consulte [max\$1execution\$1time](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_max_execution_time) na documentação do MySQL. |
| `min_examined_row_limit` | Sim | Use esse parâmetro para evitar que consultas que examinam menos do que o número especificado de linhas sejam registradas em log. Este parâmetro é aplicável ao Aurora MySQL versão 3. |
| `partial_revokes` | Não | Este parâmetro é aplicável ao Aurora MySQL versão 3. |
| `preload_buffer_size` | Sim | O tamanho do buffer que é alocado ao pré-carregar índices. Este parâmetro é aplicável ao Aurora MySQL versão 3. |
| `query_cache_type` | Sim | Retirado do Aurora MySQL versão 3. |
| `read_only` | Sim | Quando esse parâmetro é ativado, o servidor não permite atualizações, exceto aquelas executadas por threads de réplica. Para o Aurora MySQL versão 2, os valores válidos são os seguintes: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Reference.ParameterGroups.html) Para o Aurora MySQL versão 3, os valores válidos são os seguintes: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Reference.ParameterGroups.html) No Aurora MySQL versão 3, esse parâmetro não se aplica aos usuários que têm o privilégio `CONNECTION_ADMIN`. Isso inclui o usuário principal do Aurora. Para ter mais informações, consulte [Modelo de privilégios baseados em funções](AuroraMySQL.Compare-80-v3.md#AuroraMySQL.privilege-model). |
| `relay-log-space-limit` | Sim | Este parâmetro é aplicável ao Aurora MySQL versão 3. |
| `replica_parallel_type` | Sim | Esse parâmetro permite a execução paralela na réplica de todos os threads não confirmados que já estão na fase de preparação, sem violar a consistência. Aplica-se ao Aurora MySQL versão 3. No Aurora MySQL versão 3.03\$1 e anteriores, o valor padrão é DATABASE. No Aurora MySQL versão 3.04 e posteriores, o valor padrão é LOGICAL\$1CLOCK. |
| `replica_preserve_commit_order` | Sim | Este parâmetro é aplicável ao Aurora MySQL versão 3. |
| `replica_transaction_retries` | Sim | Este parâmetro é aplicável ao Aurora MySQL versão 3. |
| `replica_type_conversions` | Sim | Esse parâmetro determina as conversões de tipo usadas nas réplicas. Os valores permitidos são: `ALL_LOSSY`, `ALL_NON_LOSSY`, `ALL_SIGNED` e `ALL_UNSIGNED`. Para obter mais informações, consulte [Replication with differing table definitions on source and replica](https://dev.mysql.com/doc/refman/8.0/en/replication-features-differing-tables.html) na documentação do MySQL. Este parâmetro é aplicável ao Aurora MySQL versão 3. |
| `replicate-do-db` | Sim | Este parâmetro é aplicável ao Aurora MySQL versão 3. |
| `replicate-do-table` | Sim | Este parâmetro é aplicável ao Aurora MySQL versão 3. |
| `replicate-ignore-db` | Sim | Este parâmetro é aplicável ao Aurora MySQL versão 3. |
| `replicate-ignore-table` | Sim | Este parâmetro é aplicável ao Aurora MySQL versão 3. |
| `replicate-wild-do-table` | Sim | Este parâmetro é aplicável ao Aurora MySQL versão 3. |
| `replicate-wild-ignore-table` | Sim | Este parâmetro é aplicável ao Aurora MySQL versão 3. |
| `require_secure_transport` | Sim | Este parâmetro é aplicável ao Aurora MySQL versões 2 e 3. Para ter mais informações, consulte [Conexões do TLS com clusters de banco de dados do Aurora MySQL](AuroraMySQL.Security.md#AuroraMySQL.Security.SSL). |
| `rpl_read_size` | Sim | Este parâmetro é aplicável ao Aurora MySQL versão 3. |
| `server_audit_cw_upload` | Não | Esse parâmetro foi descontinuado no Aurora MySQL. Usar `server_audit_logs_upload`. Para ter mais informações, consulte [Publicar logs do Amazon Aurora MySQL no Amazon CloudWatch Logs](AuroraMySQL.Integrating.CloudWatch.md). |
| `server_audit_events` | Sim | Para ter mais informações, consulte [Como utilizar a auditoria avançada em um cluster de banco de dados do Amazon Aurora MySQL](AuroraMySQL.Auditing.md). |
| `server_audit_excl_users` | Sim | Para ter mais informações, consulte [Como utilizar a auditoria avançada em um cluster de banco de dados do Amazon Aurora MySQL](AuroraMySQL.Auditing.md). |
| `server_audit_incl_users` | Sim | Para ter mais informações, consulte [Como utilizar a auditoria avançada em um cluster de banco de dados do Amazon Aurora MySQL](AuroraMySQL.Auditing.md). |
| `server_audit_logging` | Sim | Para obter instruções sobre como fazer upload dos logs no Amazon CloudWatch Logs, consulte [Publicar logs do Amazon Aurora MySQL no Amazon CloudWatch Logs](AuroraMySQL.Integrating.CloudWatch.md). |
| `server_audit_logs_upload` | Sim | É possível publicar logs de auditoria no CloudWatch Logs habilitando a Auditoria avançada e definindo esse parâmetro como `1`. O padrão do parâmetro `server_audit_logs_upload` é `0`. Para ter mais informações, consulte [Publicar logs do Amazon Aurora MySQL no Amazon CloudWatch Logs](AuroraMySQL.Integrating.CloudWatch.md). |
| `server_id` | Não | |
| `skip-character-set-client-handshake` | Sim | |
| `skip_name_resolve` | Não | |
| `slave-skip-errors` | Sim | Só se aplica a clusters do Aurora MySQL versão 2, com compatibilidade com o MySQL 5.7. |
| `source_verify_checksum` | Sim | Este parâmetro é aplicável ao Aurora MySQL versão 3. |
| `sync_frm` | Sim | Retirado do Aurora MySQL versão 3. |
| `thread_cache_size` | Sim | O número de threads para armazenar em cache. Esse parâmetro se aplica ao Aurora MySQL versões 2 e 3. |
| `time_zone` | Sim | Por padrão, o fuso horário de um cluster de bancos de dados do Aurora é o Tempo Universal Coordenado (UTC). Você pode definir o fuso horário de instâncias em seu cluster de banco de dados como o fuso horário local de seu aplicativo. Para ter mais informações, consulte [Fuso horário local para os clusters de bancos de dados Amazon Aurora](Concepts.RegionsAndAvailabilityZones.md#Aurora.Overview.LocalTimeZone). |
| `tls_version` | Sim | Para ter mais informações, consulte [Versões do TLS para o Aurora MySQL](AuroraMySQL.Security.md#AuroraMySQL.Security.SSL.TLS_Version). |
## Parâmetros no nível da instância
A tabela a seguir mostra todos os parâmetros que se aplicam uma instância de banco de dados específica no cluster de bancos de dados Aurora MySQL.
| Nome do parâmetro | Permite modificação | Observações |
| --- | --- | --- |
| `activate_all_roles_on_login` | Sim | Este parâmetro é aplicável ao Aurora MySQL versão 3. |
| `allow-suspicious-udfs` | Não | |
| `aurora_disable_hash_join` | Sim | Defina esse parâmetro como `ON` para desativar a otimização de junções de hash no Aurora MySQL versão 2.09 ou posterior. Não há suporte para a versão 3. Para ter mais informações, consulte [Consulta paralela do Amazon Aurora MySQL](aurora-mysql-parallel-query.md). |
| `aurora_lab_mode` | Sim | Para ter mais informações, consulte [Modo de laboratório do Amazon Aurora MySQL](AuroraMySQL.Updates.LabMode.md). Retirado do Aurora MySQL versão 3. |
| `aurora_oom_response` | Sim | Este parâmetro é compatível com o Aurora MySQL versões 2 e 3. Para ter mais informações, consulte [Solucionar problemas de falta de memória em bancos de dados do Aurora MySQL](AuroraMySQLOOM.md). |
| `aurora_parallel_query` | Sim | Defina como `ON` para ativar a consulta paralela no Aurora MySQL versão 2.09 ou posterior. O parâmetro `aurora_pq` antigo não é usado nessas versões. Para ter mais informações, consulte [Consulta paralela do Amazon Aurora MySQL](aurora-mysql-parallel-query.md). |
| `aurora_pq` | Sim | Defina como `OFF` para desativar a consulta paralela para instâncias de banco de dados específicas nas versões anteriores à 2.09 do Aurora MySQL. Na versão 2.09 ou posterior, ative e desative a consulta paralela com `aurora_parallel_query`. Para ter mais informações, consulte [Consulta paralela do Amazon Aurora MySQL](aurora-mysql-parallel-query.md). |
| `aurora_read_replica_read_committed` | Sim | Habilita o nível de isolamento `READ COMMITTED` para réplicas do Aurora e altera o comportamento de isolamento com o intuito de reduzir o atraso de eliminação durante consultas de longa execução. Habilite essa configuração somente se você entende as alterações de comportamento e como elas afetam os resultados da consulta. Por exemplo, essa configuração usa um isolamento menos rigoroso que o padrão do MySQL. Quando habilitada, as consultas de longa execução podem ver mais de uma cópia da mesma linha, pois o Aurora reorganiza os dados da tabela enquanto a consulta está em execução. Para ter mais informações, consulte [Níveis de isolamento do Aurora MySQL](AuroraMySQL.Reference.IsolationLevels.md). |
| `aurora_tmptable_enable_per_table_limit` | Sim | Determina se o parâmetro `tmp_table_size` controla o tamanho máximo das tabelas temporárias na memória criadas pelo mecanismo de armazenamento `TempTable` no Aurora MySQL versão 3.04 e posterior. Para ter mais informações, consulte [Limitar o tamanho de tabelas temporárias internas na memória](ams3-temptable-behavior.md#ams3-temptable-behavior-limit). |
| `aurora_use_vector_instructions` | Sim | Quando esse parâmetro é ativado, o Aurora MySQL usa instruções otimizadas de processamento vetorial fornecidas por CPUs modernas para melhorar a performance em workloads que fazem uso intenso de E/S. Essa configuração é ativada por padrão no Aurora MySQL versão 3.05 e posterior. |
| `autocommit` | Sim | |
| `automatic_sp_privileges` | Sim | |
| `back_log` | Sim | |
| `basedir` | Não | O Aurora MySQL utiliza instâncias gerenciadas em que não é possível acessar o sistema de arquivos diretamente. |
| `binlog_cache_size` | Sim | |
| `binlog_max_flush_queue_time` | Sim | |
| `binlog_order_commits` | Sim | |
| `binlog_stmt_cache_size` | Sim | |
| `binlog_transaction_compression` | Sim | Este parâmetro é aplicável ao Aurora MySQL versão 3. |
| `binlog_transaction_compression_level_zstd` | Sim | Este parâmetro é aplicável ao Aurora MySQL versão 3. |
| `bulk_insert_buffer_size` | Sim | |
| `concurrent_insert` | Sim | |
| `connect_timeout` | Sim | |
| `core-file` | Não | O Aurora MySQL utiliza instâncias gerenciadas em que não é possível acessar o sistema de arquivos diretamente. |
| `datadir` | Não | O Aurora MySQL utiliza instâncias gerenciadas em que não é possível acessar o sistema de arquivos diretamente. |
| `default_authentication_plugin` | Não | Este parâmetro é aplicável ao Aurora MySQL versão 3. |
| `default_time_zone` | Não | |
| `default_tmp_storage_engine` | Sim | O mecanismo de armazenamento padrão para tabelas temporárias. |
| `default_week_format` | Sim | |
| `delay_key_write` | Sim | |
| `delayed_insert_limit` | Sim | |
| `delayed_insert_timeout` | Sim | |
| `delayed_queue_size` | Sim | |
| `div_precision_increment` | Sim | |
| `end_markers_in_json` | Sim | |
| `eq_range_index_dive_limit` | Sim | |
| `event_scheduler` | Às vezes | Indica o status do programador de eventos. Modificável somente no nível do cluster no Aurora MySQL versão 3. |
| `explicit_defaults_for_timestamp` | Sim | |
| `flush` | Não | |
| `flush_time` | Sim | |
| `ft_boolean_syntax` | Não | |
| `ft_max_word_len` | Sim | |
| `ft_min_word_len` | Sim | |
| `ft_query_expansion_limit` | Sim | |
| `ft_stopword_file` | Sim | |
| `general_log` | Sim | Para obter instruções sobre como fazer upload dos logs no CloudWatch Logs, consulte [Publicar logs do Amazon Aurora MySQL no Amazon CloudWatch Logs](AuroraMySQL.Integrating.CloudWatch.md). |
| `general_log_file` | Não | O Aurora MySQL utiliza instâncias gerenciadas em que não é possível acessar o sistema de arquivos diretamente. |
| `group_concat_max_len` | Sim | |
| `host_cache_size` | Sim | |
| `init_connect` | Sim | O comando a ser executado pelo servidor para cada cliente conectado. Use aspas duplas (“) nas configurações para evitar falhas de conexão, por exemplo: SET optimizer_switch="hash_join=off"
No Aurora MySQL versão 3, esse parâmetro não se aplica aos usuários que têm o privilégio `CONNECTION_ADMIN`, incluindo o usuário principal do Aurora. Para ter mais informações, consulte [Modelo de privilégios baseados em funções](AuroraMySQL.Compare-80-v3.md#AuroraMySQL.privilege-model). |
| `innodb_adaptive_hash_index` | Sim | É possível modificar esse parâmetro no nível da instância de banco de dados no Aurora MySQL versão 2. É modificável somente no nível do cluster de banco de dados no Aurora MySQL versão 3. O Adaptive Hash Index não é compatível com instâncias de banco de dados de leitor. |
| `innodb_adaptive_max_sleep_delay` | Sim | Modificar este parâmetro não tem efeito, porque `innodb_thread_concurrency` é sempre 0 para o Aurora. |
| `innodb_aurora_max_partitions_for_range` | Sim | Em alguns casos em que estatísticas persistentes não estão disponíveis, você pode usar esse parâmetro para melhorar a performance das estimativas de contagem de linhas em tabelas particionadas. Você pode configurá-lo com um valor de 0 a 8.192, em que o valor determina o número de partições a serem verificadas durante a estimativa de contagem de linhas. O valor padrão é 0, que estima o uso de todas as partições, em consistência com o comportamento padrão do MySQL. Esse parâmetro está disponível para o Aurora MySQL versão 3.03.1 e posteriores. |
| `innodb_autoextend_increment` | Sim | |
| `innodb_buffer_pool_dump_at_shutdown` | Não | |
| `innodb_buffer_pool_dump_now` | Não | |
| `innodb_buffer_pool_filename` | Não | |
| `innodb_buffer_pool_load_abort` | Não | |
| `innodb_buffer_pool_load_at_startup` | Não | |
| `innodb_buffer_pool_load_now` | Não | |
| `innodb_buffer_pool_size` | Sim | O valor padrão é representado por uma fórmula. Para obter detalhes sobre como o valor `DBInstanceClassMemory` na fórmula é calculado, consulte [Variáveis de fórmulas de parâmetros de banco de dados](USER_ParamValuesRef.md#USER_FormulaVariables). |
| `innodb_change_buffer_max_size` | Não | O Aurora MySQL não usa o buffer de mudança do InnoDB. |
| `innodb_compression_failure_threshold_pct` | Sim | |
| `innodb_compression_level` | Sim | |
| `innodb_compression_pad_pct_max` | Sim | |
| `innodb_concurrency_tickets` | Sim | Modificar este parâmetro não tem efeito, porque `innodb_thread_concurrency` é sempre 0 para Aurora. |
| `innodb_deadlock_detect` | Sim | Esta opção é usada para desabilitar a detecção de deadlock no Aurora MySQL versão 2.11 e posterior e versão 3. Em sistemas de alta simultaneidade, a detecção de deadlock pode causar uma desaceleração quando vários segmentos aguardam o mesmo bloqueio. Consulte a documentação do MySQL para obter mais informações sobre esse parâmetro. |
| `innodb_file_format` | Sim | Retirado do Aurora MySQL versão 3. |
| `innodb_flushing_avg_loops` | Não | |
| `innodb_force_load_corrupted` | Não | |
| `innodb_ft_aux_table` | Sim | |
| `innodb_ft_cache_size` | Sim | |
| `innodb_ft_enable_stopword` | Sim | |
| `innodb_ft_server_stopword_table` | Sim | |
| `innodb_ft_user_stopword_table` | Sim | |
| `innodb_large_prefix` | Sim | Retirado do Aurora MySQL versão 3. |
| `innodb_lock_wait_timeout` | Sim | |
| `innodb_log_compressed_pages` | Não | |
| `innodb_lru_scan_depth` | Sim | |
| `innodb_max_purge_lag` | Sim | |
| `innodb_max_purge_lag_delay` | Sim | |
| `innodb_monitor_disable` | Sim | |
| `innodb_monitor_enable` | Sim | |
| `innodb_monitor_reset` | Sim | |
| `innodb_monitor_reset_all` | Sim | |
| `innodb_old_blocks_pct` | Sim | |
| `innodb_old_blocks_time` | Sim | |
| `innodb_open_files` | Sim | |
| `innodb_print_all_deadlocks` | Sim | Quando ativado, registra informações sobre todos os deadlocks do InnoDB no log de erros do Aurora MySQL. Para ter mais informações, consulte [Minimizar e solucionar problemas de deadlocks do Aurora MySQL](AuroraMySQL.BestPractices.FeatureRecommendations.md#AuroraMySQL.BestPractices.deadlocks). |
| `innodb_random_read_ahead` | Sim | |
| `innodb_read_ahead_threshold` | Sim | |
| `innodb_read_io_threads` | Não | |
| `innodb_read_only` | Não | O Aurora MySQL gerencia os estados somente leitura e de leitura/gravação de instâncias de banco de dados com base no tipo de cluster. Por exemplo, um cluster provisionado tem uma instância de banco de dados de leitura/gravação (a *instância primária*) e qualquer outra instância no cluster é somente leitura (as réplicas do Aurora). |
| `innodb_replication_delay` | Sim | |
| `innodb_sort_buffer_size` | Sim | |
| `innodb_stats_auto_recalc` | Sim | |
| `innodb_stats_method` | Sim | |
| `innodb_stats_on_metadata` | Sim | |
| `innodb_stats_persistent` | Sim | |
| `innodb_stats_persistent_sample_pages` | Sim | |
| `innodb_stats_transient_sample_pages` | Sim | |
| `innodb_thread_concurrency` | Não | |
| `innodb_thread_sleep_delay` | Sim | Modificar este parâmetro não tem efeito, porque `innodb_thread_concurrency` é sempre 0 para o Aurora. |
| `interactive_timeout` | Sim | O Aurora avalia o valor mínimo de `interactive_timeout` e `wait_timeout`. Em seguida, ele utiliza esse mínimo como o tempo limite para encerrar todas as sessões inativas, interativas e não interativas. |
| `internal_tmp_disk_storage_engine` | Sim | Controla qual mecanismo de armazenamento na memória é usado para tabelas temporárias internas. Os valores permitidos são `INNODB` e `MYISAM`. Este parâmetro é aplicável ao Aurora MySQL versão 2. |
| `internal_tmp_mem_storage_engine` | Sim | Controla qual mecanismo de armazenamento na memória é usado para tabelas temporárias internas. Os valores permitidos são `MEMORY` e `TempTable`. Este parâmetro é aplicável ao Aurora MySQL versão 3. |
| `join_buffer_size` | Sim | |
| `keep_files_on_create` | Sim | |
| `key_buffer_size` | Sim | Cache de chaves para tabelas MyISAM. Para ter mais informações, consulte [keycache->cache\$1lock mutex](AuroraMySQL.Reference.Waitevents.md#key-cache.cache-lock). |
| `key_cache_age_threshold` | Sim | |
| `key_cache_block_size` | Sim | |
| `key_cache_division_limit` | Sim | |
| `local_infile` | Sim | |
| `lock_wait_timeout` | Sim | |
| `log-bin` | Não | Definir `binlog_format` como `STATEMENT`, `MIXED` ou `ROW` define automaticamente `log-bin` como `ON`. Definir `binlog_format` como `OFF` define automaticamente `log-bin` como `OFF`. Para ter mais informações, consulte [Replicação entre Aurora e o MySQL ou entre Aurora e outro cluster de banco de dados do Aurora (replicação de log binário)](AuroraMySQL.Replication.MySQL.md). |
| `log_bin_trust_function_creators` | Sim | |
| `log_bin_use_v1_row_events` | Sim | Retirado do Aurora MySQL versão 3. |
| `log_error` | Não | |
| `log_error_suppression_list` | Sim | Especifica uma lista de códigos de erros que não estão registrados no log de erros do MySQL. Isso permite que você ignore certas condições de erro não críticas para ajudar a manter seus logs de erros limpos. Para ter mais informações, consulte [log\$1error\$1suppression\$1list](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_log_error_suppression_list) na documentação do MySQL. Esse parâmetro é aplicável ao Aurora MySQL versão 3.03 e posterior. |
| `log_output` | Sim | |
| `log_queries_not_using_indexes` | Sim | |
| `log_slave_updates` | Não | Aurora MySQL versão 2. Use `log_replica_updates` no Aurora MySQL versão 3. |
| `log_replica_updates` | Não | Aurora MySQL versão 3 |
| `log_throttle_queries_not_using_indexes` | Sim | |
| `log_warnings` | Sim | Retirado do Aurora MySQL versão 3. |
| `long_query_time` | Sim | |
| `low_priority_updates` | Sim | As operações `INSERT`, `UPDATE`, `DELETE` e `LOCK TABLE WRITE` aguardam até que não haja nenhuma operação `SELECT` pendente. Esse parâmetro só afeta mecanismos de armazenamento que usam apenas bloqueio em nível de tabela (MyISAM, MEMORY, MERGE). Este parâmetro é aplicável ao Aurora MySQL versão 3. |
| `max_allowed_packet` | Sim | |
| `max_binlog_cache_size` | Sim | |
| `max_binlog_size` | Não | |
| `max_binlog_stmt_cache_size` | Sim | |
| `max_connect_errors` | Sim | |
| `max_connections` | Sim | O valor padrão é representado por uma fórmula. Para obter detalhes sobre como o valor `DBInstanceClassMemory` na fórmula é calculado, consulte [Variáveis de fórmulas de parâmetros de banco de dados](USER_ParamValuesRef.md#USER_FormulaVariables). Para obter os valores padrão, dependendo da classe da instância, consulte [Número máximo de conexões com uma instância de bancos de dados Aurora MySQL](AuroraMySQL.Managing.Performance.md#AuroraMySQL.Managing.MaxConnections). |
| `max_delayed_threads` | Sim | Define o número máximo de threads para lidar com instruções `INSERT DELAYED`. Este parâmetro é aplicável ao Aurora MySQL versão 3. |
| `max_error_count` | Sim | O número máximo de mensagens de erro, advertência e observação que devem ser armazenadas para exibição. Este parâmetro é aplicável ao Aurora MySQL versão 3. |
| `max_execution_time` | Sim | O tempo limite para executar declarações `SELECT`, em milissegundos. O valor pode ser de `0` a `18446744073709551615`. Quando definido como `0`, não há tempo limite. Para ter mais informações, consulte [max\$1execution\$1time](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_max_execution_time) na documentação do MySQL. |
| `max_heap_table_size` | Sim | |
| `max_insert_delayed_threads` | Sim | |
| `max_join_size` | Sim | |
| `max_length_for_sort_data` | Sim | Retirado do Aurora MySQL versão 3. |
| `max_prepared_stmt_count` | Sim | |
| `max_seeks_for_key` | Sim | |
| `max_sort_length` | Sim | |
| `max_sp_recursion_depth` | Sim | |
| `max_tmp_tables` | Sim | Retirado do Aurora MySQL versão 3. |
| `max_user_connections` | Sim | |
| `max_write_lock_count` | Sim | |
| `metadata_locks_cache_size` | Sim | Retirado do Aurora MySQL versão 3. |
| `min_examined_row_limit` | Sim | Use esse parâmetro para evitar que consultas que examinam menos do que o número especificado de linhas sejam registradas em log. Este parâmetro é aplicável ao Aurora MySQL versão 3. |
| `myisam_data_pointer_size` | Sim | |
| `myisam_max_sort_file_size` | Sim | |
| `myisam_mmap_size` | Sim | |
| `myisam_sort_buffer_size` | Sim | |
| `myisam_stats_method` | Sim | |
| `myisam_use_mmap` | Sim | |
| `net_buffer_length` | Sim | |
| `net_read_timeout` | Sim | |
| `net_retry_count` | Sim | |
| `net_write_timeout` | Sim | |
| `old-style-user-limits` | Sim | |
| `old_passwords` | Sim | Retirado do Aurora MySQL versão 3. |
| `optimizer_prune_level` | Sim | |
| `optimizer_search_depth` | Sim | |
| `optimizer_switch` | Sim | Para obter informações sobre os recursos do Aurora MySQL que usam essa alternância, consulte [Melhores práticas do Amazon Aurora MySQL](AuroraMySQL.BestPractices.md). |
| `optimizer_trace` | Sim | |
| `optimizer_trace_features` | Sim | |
| `optimizer_trace_limit` | Sim | |
| `optimizer_trace_max_mem_size` | Sim | |
| `optimizer_trace_offset` | Sim | |
| `performance-schema-consumer-events-waits-current` | Sim | |
| `performance-schema-instrument` | Sim | |
| `performance_schema` | Sim | |
| `performance_schema_accounts_size` | Sim | |
| `performance_schema_consumer_global_instrumentation` | Sim | |
| `performance_schema_consumer_thread_instrumentation` | Sim | |
| `performance_schema_consumer_events_stages_current` | Sim | |
| `performance_schema_consumer_events_stages_history` | Sim | |
| `performance_schema_consumer_events_stages_history_long` | Sim | |
| `performance_schema_consumer_events_statements_current` | Sim | |
| `performance_schema_consumer_events_statements_history` | Sim | |
| `performance_schema_consumer_events_statements_history_long` | Sim | |
| `performance_schema_consumer_events_waits_history` | Sim | |
| `performance_schema_consumer_events_waits_history_long` | Sim | |
| `performance_schema_consumer_statements_digest` | Sim | |
| `performance_schema_digests_size` | Sim | |
| `performance_schema_events_stages_history_long_size` | Sim | |
| `performance_schema_events_stages_history_size` | Sim | |
| `performance_schema_events_statements_history_long_size` | Sim | |
| `performance_schema_events_statements_history_size` | Sim | |
| `performance_schema_events_transactions_history_long_size` | Sim | |
| `performance_schema_events_transactions_history_size` | Sim | |
| `performance_schema_events_waits_history_long_size` | Sim | |
| `performance_schema_events_waits_history_size` | Sim | |
| `performance_schema_hosts_size` | Sim | |
| `performance_schema_max_cond_classes` | Sim | |
| `performance_schema_max_cond_instances` | Sim | |
| `performance_schema_max_digest_length` | Sim | |
| `performance_schema_max_file_classes` | Sim | |
| `performance_schema_max_file_handles` | Sim | |
| `performance_schema_max_file_instances` | Sim | |
| `performance_schema_max_index_stat` | Sim | |
| `performance_schema_max_memory_classes` | Sim | |
| `performance_schema_max_metadata_locks` | Sim | |
| `performance_schema_max_mutex_classes` | Sim | |
| `performance_schema_max_mutex_instances` | Sim | |
| `performance_schema_max_prepared_statements_instances` | Sim | |
| `performance_schema_max_program_instances` | Sim | |
| `performance_schema_max_rwlock_classes` | Sim | |
| `performance_schema_max_rwlock_instances` | Sim | |
| `performance_schema_max_socket_classes` | Sim | |
| `performance_schema_max_socket_instances` | Sim | |
| `performance_schema_max_sql_text_length` | Sim | |
| `performance_schema_max_stage_classes` | Sim | |
| `performance_schema_max_statement_classes` | Sim | |
| `performance_schema_max_statement_stack` | Sim | |
| `performance_schema_max_table_handles` | Sim | |
| `performance_schema_max_table_instances` | Sim | |
| `performance_schema_max_table_lock_stat` | Sim | |
| `performance_schema_max_thread_classes` | Sim | |
| `performance_schema_max_thread_instances` | Sim | |
| `performance_schema_session_connect_attrs_size` | Sim | |
| `performance_schema_setup_actors_size` | Sim | |
| `performance_schema_setup_objects_size` | Sim | |
| `performance_schema_show_processlist` | Sim | Esse parâmetro determina qual implementação SHOW PROCESSLIST usar: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Reference.ParameterGroups.html)Esse parâmetro se aplica ao Aurora MySQL versão 2.12 e posterior e versão 3. |
| `performance_schema_users_size` | Sim | |
| `pid_file` | Não | |
| `plugin_dir` | Não | O Aurora MySQL utiliza instâncias gerenciadas em que não é possível acessar o sistema de arquivos diretamente. |
| `port` | Não | O Aurora MySQL gerencia as propriedades de conexão e impõe configurações consistentes para todas as instâncias de banco de dados em um cluster. |
| `preload_buffer_size` | Sim | O tamanho do buffer que é alocado ao pré-carregar índices. Este parâmetro é aplicável ao Aurora MySQL versão 3. |
| `profiling_history_size` | Sim | |
| `query_alloc_block_size` | Sim | |
| `query_cache_limit` | Sim | Retirado do Aurora MySQL versão 3. |
| `query_cache_min_res_unit` | Sim | Retirado do Aurora MySQL versão 3. |
| `query_cache_size` | Sim | O valor padrão é representado por uma fórmula. Para obter detalhes sobre como o valor `DBInstanceClassMemory` na fórmula é calculado, consulte [Variáveis de fórmulas de parâmetros de banco de dados](USER_ParamValuesRef.md#USER_FormulaVariables). Retirado do Aurora MySQL versão 3. |
| `query_cache_type` | Sim | Retirado do Aurora MySQL versão 3. |
| `query_cache_wlock_invalidate` | Sim | Retirado do Aurora MySQL versão 3. |
| `query_prealloc_size` | Sim | |
| `range_alloc_block_size` | Sim | |
| `read_buffer_size` | Sim | |
| `read_only` | Sim | Quando esse parâmetro é ativado, o servidor não permite atualizações, exceto aquelas executadas por threads de réplica. Para o Aurora MySQL versão 2, os valores válidos são os seguintes: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Reference.ParameterGroups.html) Recomendamos que você use o grupo de parâmetros do cluster de banco de dados na versão 2 do Aurora MySQL para garantir que o parâmetro `read_only` seja aplicado a novas instâncias do gravador em caso de failover. As instâncias do leitor são sempre somente leitura, porque o Aurora MySQL define `innodb_read_only` como `1` em todos os leitores. Portanto, `read_only` é redundante em instâncias do leitor. Retirado no nível da instância do Aurora MySQL versão 3. |
| `read_rnd_buffer_size` | Sim | |
| `relay-log` | Não | |
| `relay_log_info_repository` | Sim | Retirado do Aurora MySQL versão 3. |
| `relay_log_recovery` | Não | |
| `replica_checkpoint_group` | Sim | Aurora MySQL versão 3 |
| `replica_checkpoint_period` | Sim | Aurora MySQL versão 3 |
| `replica_parallel_workers` | Sim | Aurora MySQL versão 3 |
| `replica_pending_jobs_size_max` | Sim | Aurora MySQL versão 3 |
| `replica_skip_errors` | Sim | Aurora MySQL versão 3 |
| `replica_sql_verify_checksum` | Sim | Aurora MySQL versão 3 |
| `safe-user-create` | Sim | |
| `secure_auth` | Sim | Este parâmetro está sempre ativado no Aurora MySQL versão 2. Se tentar desativá-lo, um erro será gerado. Retirado do Aurora MySQL versão 3. |
| `secure_file_priv` | Não | O Aurora MySQL utiliza instâncias gerenciadas em que não é possível acessar o sistema de arquivos diretamente. |
| `show_create_table_verbosity` | Sim | Habilitar essa variável faz com que [SHOW\$1CREATE\$1TABLE](https://dev.mysql.com/doc/refman/5.7/en/show-create-table.html) exiba o`ROW_FORMAT` independentemente de ser o formato padrão. Esse parâmetro se aplica ao Aurora MySQL versão 2.12 e posterior e versão 3. |
| `skip-slave-start` | Não | |
| `skip_external_locking` | Não | |
| `skip_show_database` | Sim | |
| `slave_checkpoint_group` | Sim | Aurora MySQL versão 2. Use `replica_checkpoint_group` no Aurora MySQL versão 3. |
| `slave_checkpoint_period` | Sim | Aurora MySQL versão 2. Use `replica_checkpoint_period` no Aurora MySQL versão 3. |
| `slave_parallel_workers` | Sim | Aurora MySQL versão 2. Use `replica_parallel_workers` no Aurora MySQL versão 3. |
| `slave_pending_jobs_size_max` | Sim | Aurora MySQL versão 2. Use `replica_pending_jobs_size_max` no Aurora MySQL versão 3. |
| `slave_sql_verify_checksum` | Sim | Aurora MySQL versão 2. Use `replica_sql_verify_checksum` no Aurora MySQL versão 3. |
| `slow_launch_time` | Sim | |
| `slow_query_log` | Sim | Para obter instruções sobre como fazer upload dos logs no CloudWatch Logs, consulte [Publicar logs do Amazon Aurora MySQL no Amazon CloudWatch Logs](AuroraMySQL.Integrating.CloudWatch.md). |
| `slow_query_log_file` | Não | O Aurora MySQL utiliza instâncias gerenciadas em que não é possível acessar o sistema de arquivos diretamente. |
| `socket` | Não | |
| `sort_buffer_size` | Sim | |
| `sql_mode` | Sim | |
| `sql_select_limit` | Sim | |
| `stored_program_cache` | Sim | |
| `sync_binlog` | Não | |
| `sync_master_info` | Sim | |
| `sync_source_info` | Sim | Este parâmetro é aplicável ao Aurora MySQL versão 3. |
| `sync_relay_log` | Sim | Retirado do Aurora MySQL versão 3. |
| `sync_relay_log_info` | Sim | |
| `sysdate-is-now` | Sim | |
| `table_cache_element_entry_ttl` | Não | |
| `table_definition_cache` | Sim | O valor padrão é representado por uma fórmula. Para obter detalhes sobre como o valor `DBInstanceClassMemory` na fórmula é calculado, consulte [Variáveis de fórmulas de parâmetros de banco de dados](USER_ParamValuesRef.md#USER_FormulaVariables). |
| `table_open_cache` | Sim | O valor padrão é representado por uma fórmula. Para obter detalhes sobre como o valor `DBInstanceClassMemory` na fórmula é calculado, consulte [Variáveis de fórmulas de parâmetros de banco de dados](USER_ParamValuesRef.md#USER_FormulaVariables). |
| `table_open_cache_instances` | Sim | |
| `temp-pool` | Sim | Retirado do Aurora MySQL versão 3. |
| `temptable_max_mmap` | Sim | Este parâmetro é aplicável ao Aurora MySQL versão 3. Para obter detalhes, consulte [Novo comportamento de tabela temporária no Aurora MySQL versão 3](ams3-temptable-behavior.md). |
| `temptable_max_ram` | Sim | Este parâmetro é aplicável ao Aurora MySQL versão 3. Para obter detalhes, consulte [Novo comportamento de tabela temporária no Aurora MySQL versão 3](ams3-temptable-behavior.md). |
| `temptable_use_mmap` | Sim | Este parâmetro é aplicável ao Aurora MySQL versão 3. Para obter detalhes, consulte [Novo comportamento de tabela temporária no Aurora MySQL versão 3](ams3-temptable-behavior.md). |
| `thread_cache_size` | Sim | O número de threads para armazenar em cache. Esse parâmetro se aplica ao Aurora MySQL versões 2 e 3. |
| `thread_handling` | Não | |
| `thread_stack` | Sim | |
| `timed_mutexes` | Sim | |
| `tmp_table_size` | Sim | Define o tamanho máximo das tabelas temporárias na memória criadas pelo mecanismo de armazenamento `MEMORY` no Aurora MySQL versão 3. No Aurora MySQL versão 3.04 e posterior, define o tamanho máximo das tabelas temporárias na memória criadas pelo mecanismo de armazenamento `TempTable` quando `aurora_tmptable_enable_per_table_limit` está `ON`. Para ter mais informações, consulte [Limitar o tamanho de tabelas temporárias internas na memória](ams3-temptable-behavior.md#ams3-temptable-behavior-limit). |
| `tmpdir` | Não | O Aurora MySQL utiliza instâncias gerenciadas em que não é possível acessar o sistema de arquivos diretamente. |
| `transaction_alloc_block_size` | Sim | |
| `transaction_isolation` | Sim | Este parâmetro é aplicável ao Aurora MySQL versão 3. Ele substitui `tx_isolation`. |
| `transaction_prealloc_size` | Sim | |
| `tx_isolation` | Sim | Retirado do Aurora MySQL versão 3. Ele é substituído por `transaction_isolation`. |
| `updatable_views_with_limit` | Sim | |
| `validate-password` | Não | |
| `validate_password_dictionary_file` | Não | |
| `validate_password_length` | Não | |
| `validate_password_mixed_case_count` | Não | |
| `validate_password_number_count` | Não | |
| `validate_password_policy` | Não | |
| `validate_password_special_char_count` | Não | |
| `wait_timeout` | Sim | O Aurora avalia o valor mínimo de `interactive_timeout` e `wait_timeout`. Em seguida, ele utiliza esse mínimo como o tempo limite para encerrar todas as sessões inativas, interativas e não interativas. |
## Parâmetros do MySQL não se aplicam ao Aurora MySQL
Por causa das diferenças de arquitetura entre o Aurora MySQL e o MySQL, alguns parâmetros do MySQL não se aplicam ao Aurora MySQL.
Os seguintes parâmetros do MySQL não se aplicam ao Aurora MySQL. Essa lista não é exaustiva.
+ `activate_all_roles_on_login`: este parâmetro não se aplica ao Aurora MySQL versão 2. Ele está disponível no Aurora MySQL versão 3.
+ `big_tables`
+ `bind_address`
+ `character_sets_dir`
+ `innodb_adaptive_flushing`
+ `innodb_adaptive_flushing_lwm`
+ `innodb_buffer_pool_chunk_size`
+ `innodb_buffer_pool_instances`
+ `innodb_change_buffering`
+ `innodb_checksum_algorithm`
+ `innodb_data_file_path`
+ `innodb_dedicated_server`
+ `innodb_doublewrite`
+ `innodb_flush_log_at_timeout`: esse parâmetro não se aplica ao Aurora MySQL. Para ter mais informações, consulte [Configurar a frequência com que o buffer de log é liberado](AuroraMySQL.BestPractices.FeatureRecommendations.md#AuroraMySQL.BestPractices.Flush).
+ `innodb_flush_method`
+ `innodb_flush_neighbors`
+ `innodb_io_capacity`
+ `innodb_io_capacity_max`
+ `innodb_log_buffer_size`
+ `innodb_log_file_size`
+ `innodb_log_files_in_group`
+ `innodb_log_spin_cpu_abs_lwm`
+ `innodb_log_spin_cpu_pct_hwm`
+ `innodb_log_writer_threads`
+ `innodb_max_dirty_pages_pct`
+ `innodb_numa_interleave`
+ `innodb_page_size`
+ `innodb_redo_log_capacity`
+ `innodb_redo_log_encrypt`
+ `innodb_undo_log_encrypt`
+ `innodb_undo_log_truncate`
+ `innodb_undo_logs`
+ `innodb_undo_tablespaces`
+ `innodb_use_native_aio`
+ `innodb_write_io_threads`
# Variáveis de status globais do Aurora MySQL
O Aurora MySQL inclui variáveis de status do MySQL da comunidade e variáveis exclusivas do Aurora. É possível examinar essas variáveis para saber o que está acontecendo no mecanismo de banco de dados. Para ter mais informações sobre as variáveis de status no MySQL da comunidade, consulte [Server Status Variables](https://dev.mysql.com/doc/refman/8.0/en/server-status-variables.html) na documentação do MySQL 8.0 da comunidade.
Você pode encontrar os valores atuais das variáveis de status globais do Aurora MySQL usando uma declaração como a seguinte:
```
show global status like '%aurora%';
```
**nota**
As variáveis de status global são limpas quando o mecanismo de banco de dados é reiniciado.
A tabela a seguir descreve as variáveis de status globais que o Aurora MySQL usa.
| Name (Nome) | Descrição |
| --- | --- |
| `AuroraDb_commits` | O número total de confirmações desde a última reinicialização. |
| `AuroraDb_commit_latency` | A latência agregada de confirmação desde a última reinicialização. |
| `AuroraDb_ddl_stmt_duration` | A latência agregada de DDL desde a última reinicialização. |
| `AuroraDb_select_stmt_duration` | A latência agregada de declaração `SELECT` desde a última reinicialização. |
| `AuroraDb_insert_stmt_duration` | A latência agregada de declaração `INSERT` desde a última reinicialização. |
| `AuroraDb_update_stmt_duration` | A latência agregada de declaração `UPDATE` desde a última reinicialização. |
| `AuroraDb_delete_stmt_duration` | A latência agregada de declaração `DELETE` desde a última reinicialização. |
| `Aurora_binlog_io_cache_allocated` | O número de bytes alocados para o cache de E/S do binlog. |
| `Aurora_binlog_io_cache_read_requests` | O número de solicitações de leitura feitas no cache de E/S do binlog. |
| `Aurora_binlog_io_cache_reads` | O número de solicitações de leitura que foram atendidas do cache de E/S do binlog. |
| `Aurora_enhanced_binlog` | Indica se o binlog aprimorado está habilitado ou desabilitado para essa instância de banco de dados. Para obter mais informações, consulte [Configurar o log binário avançado para Aurora MySQL](AuroraMySQL.Enhanced.binlog.md). |
| `Aurora_external_connection_count` | O número de conexões de banco de dados com a instância de banco de dados, excluindo as conexões de serviço do RDS usadas para verificações de integridade do banco de dados. |
| `Aurora_fast_insert_cache_hits` | Um contador que é incrementado quando o cursor em cache é recuperado e verificado com êxito. Para receber mais informações sobre o cache de inserção rápida, consulte [Melhorias de performance do Amazon Aurora MySQL](Aurora.AuroraMySQL.Overview.md#Aurora.AuroraMySQL.Performance). |
| `Aurora_fast_insert_cache_misses` | Um contador que é incrementado quando o cursor em cache não é mais válido e o Aurora realiza um percurso de índice normal. Para receber mais informações sobre o cache de inserção rápida, consulte [Melhorias de performance do Amazon Aurora MySQL](Aurora.AuroraMySQL.Overview.md#Aurora.AuroraMySQL.Performance). |
| `Aurora_fts_cache_memory_used` | A quantidade de memória em bytes que o sistema de pesquisa de texto completo do InnoDB está usando. Essa variável aplica-se ao Aurora MySQL versão 3.07 e posterior. |
| `Aurora_fwd_master_dml_stmt_count` | Número total de declarações DML encaminhadas para essa instância de banco de dados do gravador. Esta variável é aplicável ao Aurora MySQL versão 2. |
| `Aurora_fwd_master_dml_stmt_duration` | A duração total das declarações DML encaminhadas para essa instância de banco de dados do gravador. Esta variável é aplicável ao Aurora MySQL versão 2. |
| `Aurora_fwd_master_errors_rpc_timeout` | O número de vezes que uma conexão encaminhada não foi estabelecida no gravador. |
| `Aurora_fwd_master_errors_session_limit` | O número de consultas encaminhadas que são rejeitadas devido a `session full` no gravador. |
| `Aurora_fwd_master_errors_session_timeout` | O número de vezes que uma sessão de encaminhamento é encerrada devido ao tempo limite do gravador. |
| `Aurora_fwd_master_open_sessions` | O número de sessões encaminhadas na instância de banco de dados do gravador. Esta variável é aplicável ao Aurora MySQL versão 2. |
| `Aurora_fwd_master_select_stmt_count` | O número total de declarações `SELECT` encaminhadas para essa instância de banco de dados do gravador. Esta variável é aplicável ao Aurora MySQL versão 2. |
| `Aurora_fwd_master_select_stmt_duration` | A duração total das declarações `SELECT` encaminhadas para essa instância de banco de dados do gravador. Esta variável é aplicável ao Aurora MySQL versão 2. |
| `Aurora_fwd_writer_dml_stmt_count` | Número total de declarações DML encaminhadas para essa instância de banco de dados do gravador. Esta variável é aplicável ao Aurora MySQL versão 3. |
| `Aurora_fwd_writer_dml_stmt_duration` | A duração total das declarações DML encaminhadas para essa instância de banco de dados do gravador. Esta variável é aplicável ao Aurora MySQL versão 3. |
| `Aurora_fwd_writer_errors_rpc_timeout` | O número de vezes que uma conexão encaminhada não foi estabelecida no gravador. |
| `Aurora_fwd_writer_errors_session_limit` | O número de consultas encaminhadas que são rejeitadas devido a `session full` no gravador. |
| `Aurora_fwd_writer_errors_session_timeout` | O número de vezes que uma sessão de encaminhamento é encerrada devido ao tempo limite do gravador. |
| `Aurora_fwd_writer_open_sessions` | O número de sessões encaminhadas na instância de banco de dados do gravador. Esta variável é aplicável ao Aurora MySQL versão 3. |
| `Aurora_fwd_writer_select_stmt_count` | O número total de declarações `SELECT` encaminhadas para essa instância de banco de dados do gravador. Esta variável é aplicável ao Aurora MySQL versão 3. |
| `Aurora_fwd_writer_select_stmt_duration` | A duração total das declarações `SELECT` encaminhadas para essa instância de banco de dados do gravador. Esta variável é aplicável ao Aurora MySQL versão 3. |
| `Aurora_lockmgr_buffer_pool_memory_used` | A quantidade de memória de grupo de buffer em bytes que o gerenciador de bloqueio do Aurora MySQL está usando. |
| `Aurora_lockmgr_memory_used` | A quantidade de memória em bytes que o gerenciador de bloqueio do Aurora MySQL está usando. |
| `Aurora_ml_actual_request_cnt` | A contagem agregada de solicitações que o Aurora MySQL faz nos serviços de machine learning do Aurora entre todas as consultas executadas por usuários da instância de banco de dados. Para obter mais informações, consulte [Usar o machine learning do Amazon Aurora com o Aurora MySQL](mysql-ml.md). |
| `Aurora_ml_actual_response_cnt` | A contagem agregada de respostas que o Aurora MySQL recebe dos serviços de machine learning do Aurora entre todas as consultas executadas por usuários da instância de banco de dados. Para obter mais informações, consulte [Usar o machine learning do Amazon Aurora com o Aurora MySQL](mysql-ml.md). |
| `Aurora_ml_cache_hit_cnt` | A contagem agregada de acertos do cache interno que o Aurora MySQL recebe dos serviços de machine learning do Aurora entre todas as consultas executadas por usuários da instância de banco de dados. Para obter mais informações, consulte [Usar o machine learning do Amazon Aurora com o Aurora MySQL](mysql-ml.md). |
| `Aurora_ml_logical_request_cnt` | O número de solicitações lógicas que a instância de banco de dados avaliou para serem enviadas aos serviços de machine learning do Aurora desde a última redefinição de status. Dependendo se o lote foi ou não usado, esse valor pode ser maior que `Aurora_ml_actual_request_cnt`. Para obter mais informações, consulte [Usar o machine learning do Amazon Aurora com o Aurora MySQL](mysql-ml.md). |
| `Aurora_ml_logical_response_cnt` | A contagem agregada de respostas que o Aurora MySQL recebe dos serviços de machine learning do Aurora entre todas as consultas executadas por usuários da instância de banco de dados. Para obter mais informações, consulte [Usar o machine learning do Amazon Aurora com o Aurora MySQL](mysql-ml.md). |
| `Aurora_ml_retry_request_cnt` | O número de novas solicitações que a instância de banco de dados enviou aos serviços de machine learning do Aurora desde a última redefinição de status. Para obter mais informações, consulte [Usar o machine learning do Amazon Aurora com o Aurora MySQL](mysql-ml.md). |
| `Aurora_ml_single_request_cnt` | A contagem agregada de funções do machine learning do Aurora que são avaliadas pelo modo que não seja em lote entre todas as consultas executadas por usuários da instância de banco de dados. Para obter mais informações, consulte [Usar o machine learning do Amazon Aurora com o Aurora MySQL](mysql-ml.md). |
| `aurora_oom_avoidance_recovery_state` | Indica se a recuperação para evitar falta de memória (OOM) do Aurora está no estado `ACTIVE` ou `INACTIVE` para essa instância de banco de dados. Essa variável aplica-se ao Aurora MySQL versão 3.06.0 e posterior. |
| `aurora_oom_reserved_mem_enter_kb` | Representa o limite para entrar no estado `RESERVED` no mecanismo de tratamento de OOM do Aurora. Quando a memória disponível no servidor fica abaixo desse limite, `aurora_oom_status` muda para `RESERVED`, indicando que o servidor está se aproximando de um nível crítico de uso da memória. Essa variável aplica-se ao Aurora MySQL versão 3.06.0 e posterior. |
| `aurora_oom_reserved_mem_exit_kb` | Representa o limite para sair do estado `RESERVED` no mecanismo de tratamento de OOM do Aurora. Quando a memória disponível no servidor ultrapassa esse limite, o `aurora_oom_status` reverte para `NORMAL`, indicando que o servidor retornou a um estado mais estável com recursos de memória suficientes. Essa variável aplica-se ao Aurora MySQL versão 3.06.0 e posterior. |
| `aurora_oom_status` | Representa o status atual de OOM dessa instância de banco de dados. Quando o valor é `NORMAL`, indica que há recursos de memória suficientes. Se o valor mudar para `RESERVED`, isso indica que o servidor tem pouca memória disponível. As ações são realizadas com base na configuração dos parâmetros `aurora_oom_response`. Para obter mais informações, consulte [Solucionar problemas de falta de memória em bancos de dados do Aurora MySQL](AuroraMySQLOOM.md). Essa variável aplica-se ao Aurora MySQL versão 3.06.0 e posterior. |
| `Aurora_pq_bytes_returned` | O número de bytes de estruturas de dados de tupla transmitidos para o nó de cabeçalho durante as consultas paralelas. Divida por 16.384 para comparar com `Aurora_pq_pages_pushed_down`. |
| `Aurora_pq_max_concurrent_requests` | O número máximo de sessões de consulta paralela que podem ser executadas simultaneamente nesta instância de bancos de dados Aurora. Esse é um número fixo, que depende da classe da instância de banco de dados da AWS. |
| `Aurora_pq_pages_pushed_down` | O número de páginas de dados (cada uma com um tamanho fixo de 16 KiB) em que a consulta paralela evitou uma transmissão de rede para o nó de cabeçalho. |
| `Aurora_pq_request_attempted` | O número de sessões de consultas paralelas solicitadas. Esse valor pode representar mais de uma sessão por consulta, dependendo dos elementos SQL, como subconsultas e junções. |
| `Aurora_pq_request_executed` | O número de sessões de consultas paralelas executadas com êxito. |
| `Aurora_pq_request_failed` | O número de sessões de consultas paralelas que retornaram um erro para o cliente. Em alguns casos, uma solicitação por uma consulta paralela pode falhar, por exemplo, devido a um problema na camada de armazenamento. Nesses casos, a parte da consulta que falhou é reprocessada usando um mecanismo de consulta não paralelo. Se a consulta reprocessada também falhar, será retornado um erro para o cliente e o contador será incrementado. |
| `Aurora_pq_request_in_progress` | O número de sessões de consultas paralelas em andamento no momento. Esse número se aplica à instância de bancos de dados Aurora em particular à qual você está conectado, e não a todo o cluster de bancos de dados Aurora. Para saber se uma instância de banco de dados está próxima do limite de simultaneidade, compare este valor a `Aurora_pq_max_concurrent_requests`. |
| `Aurora_pq_request_not_chosen` | O número de vezes em que a consulta paralela não foi escolhida para atender uma consulta. Este valor é a soma de vários outros contadores mais granulares. Uma instrução `EXPLAIN` pode incrementar esse contador mesmo que a consulta não seja realmente executada. |
| `Aurora_pq_request_not_chosen_below_min_rows` | O número de vezes em que a consulta paralela não foi escolhida devido ao número de linhas na tabela. Uma declaração `EXPLAIN` pode incrementar esse contador mesmo que a consulta não seja realmente executada. |
| `Aurora_pq_request_not_chosen_column_bit` | O número de solicitações de consulta paralela que usam o caminho de processamento de consulta não paralela devido a um tipo de dados sem suporte na lista de colunas projetadas. |
| `Aurora_pq_request_not_chosen_column_geometry` | O número de solicitações de consulta paralela que usam o caminho de processamento de consulta não paralela porque a tabela tem colunas com o tipo de dados `GEOMETRY`. Para saber mais sobre as versões do Aurora MySQL que removem essa limitação, consulte [Fazer upgrade de clusters de consulta paralela para o Aurora MySQL versão 3](aurora-mysql-parallel-query-optimizing.md#aurora-mysql-parallel-query-upgrade-pqv2). |
| `Aurora_pq_request_not_chosen_column_lob` | O número de solicitações de consulta paralela que usam o caminho de processamento de consulta não paralela porque a tabela inclui colunas com um tipo de dados `LOB` ou colunas `VARCHAR` que são armazenadas externamente devido ao comprimento declarado. Para saber mais sobre as versões do Aurora MySQL que removem essa limitação, consulte [Fazer upgrade de clusters de consulta paralela para o Aurora MySQL versão 3](aurora-mysql-parallel-query-optimizing.md#aurora-mysql-parallel-query-upgrade-pqv2). |
| `Aurora_pq_request_not_chosen_column_virtual` | O número de solicitações de consulta paralela que usam o caminho de processamento de consulta não paralela porque a tabela contém uma coluna virtual. |
| `Aurora_pq_request_not_chosen_custom_charset` | O número de solicitações de consulta paralela que usam o caminho de processamento de consulta não paralela porque a tabela tem colunas com um conjunto de caracteres personalizado. |
| `Aurora_pq_request_not_chosen_fast_ddl` | O número de solicitações de consulta paralela que usam o caminho de processamento de consulta não paralela porque a tabela está sendo alterada atualmente por uma instrução `ALTER` DDL rápida. |
| `Aurora_pq_request_not_chosen_few_pages_outside_buffer_pool` | O número de vezes em que a consulta paralela não foi escolhida, ainda que menos de 95 por cento dos dados da tabela já estivessem no grupo de buffers, porque não havia uma quantidade suficiente de dados da tabela fora do buffer que fizesse a consulta paralela valer a pena. |
| `Aurora_pq_request_not_chosen_full_text_index` | O número de solicitações de consulta paralela que usam o caminho de processamento de consulta não paralela porque a tabela tem índices de texto completo. |
| `Aurora_pq_request_not_chosen_high_buffer_pool_pct` | O número de vezes em que a consulta paralela não foi escolhida porque uma alta porcentagem de dados da tabela (no momento, maior do que 95 por cento) já se encontrava no grupo de buffers. Nesses casos, o otimizador determina que a leitura dos dados a partir do grupo de buffers é mais eficiente. Uma instrução `EXPLAIN` pode incrementar esse contador mesmo que a consulta não seja realmente executada. |
| `Aurora_pq_request_not_chosen_index_hint` | O número de solicitações de consulta paralela que usam o caminho de processamento de consulta não paralela porque a consulta inclui uma dica de índice. |
| `Aurora_pq_request_not_chosen_innodb_table_format` | O número de solicitações de consulta paralela que usam o caminho de processamento de consulta não paralela porque a tabela usa um formato de linha InnoDB que não é compatível. A consulta paralela do Aurora só se aplica aos formatos de linha `COMPACT`, `REDUNDANT` e `DYNAMIC`. |
| `Aurora_pq_request_not_chosen_long_trx` | O número de solicitações de consultas paralelas que usaram o caminho de processamento de consultas não paralelas, devido à execução da consulta ter sido iniciada dentro de uma transação de execução demorada. Uma instrução `EXPLAIN` pode incrementar esse contador mesmo que a consulta não seja realmente executada. |
| `Aurora_pq_request_not_chosen_no_where_clause` | O número de solicitações de consulta paralela que usam o caminho de processamento de consulta não paralela porque a consulta não inclui nenhuma cláusula `WHERE`. |
| `Aurora_pq_request_not_chosen_range_scan` | O número de solicitações de consulta paralela que usam o caminho de processamento de consulta não paralela porque a consulta usa uma verificação de intervalo em um índice. |
| `Aurora_pq_request_not_chosen_row_length_too_long` | O número de solicitações de consulta paralela que usam o caminho de processamento de consulta não paralela porque o comprimento total combinado de todas as colunas é muito longo. |
| `Aurora_pq_request_not_chosen_small_table` | O número de vezes em que a consulta paralela não foi escolhida devido ao tamanho total da tabela, o que é determinado pelo número de linhas e pelo comprimento médio da linha. Uma instrução `EXPLAIN` pode incrementar esse contador mesmo que a consulta não seja realmente executada. |
| `Aurora_pq_request_not_chosen_temporary_table` | O número de solicitações de consulta paralela que usam o caminho de processamento de consulta não paralela porque a consulta se refere a tabelas temporárias que usam os tipos de tabela `MyISAM` ou `memory` que não têm suporte. |
| `Aurora_pq_request_not_chosen_tx_isolation` | O número de solicitações de consulta paralela que usam o caminho de processamento de consulta não paralela porque a consulta usa um nível de isolamento de transação sem suporte. Em instâncias de banco de dados do leitor, a consulta paralela se aplica somente aos níveis de isolamento `REPEATABLE READ` e `READ COMMITTED`. |
| `Aurora_pq_request_not_chosen_update_delete_stmts` | O número de solicitações de consulta paralela que usam o caminho de processamento de consulta não paralela porque a consulta faz parte de uma instrução `UPDATE` ou `DELETE`. |
| `Aurora_pq_request_not_chosen_unsupported_access` | O número de solicitações de consultas paralelas que usam o caminho de processamento de consultas não paralelas porque a cláusula `WHERE` não atende aos critérios de consulta paralela. Esse resultado pode ocorrer se a consulta não exigir uma varredura de dados intensiva ou se a consulta for uma instrução `DELETE` ou `UPDATE`. |
| `Aurora_pq_request_not_chosen_unsupported_storage_type` | O número de solicitações de consulta paralelas que usam o caminho de processamento de consulta não paralelo porque o cluster de banco de dados do Aurora MySQL não está usando uma configuração de armazenamento de cluster compatível do Aurora. Para obter mais informações, consulte [Limitações](aurora-mysql-parallel-query.md#aurora-mysql-parallel-query-limitations). Esse parâmetro é aplicável ao Aurora MySQL versão 3.04 e posterior. |
| `Aurora_pq_request_throttled` | O número de vezes em que a consulta paralela não foi escolhida devido ao número máximo de consultas paralelas simultâneas em execução em uma determinada instância de bancos de dados Aurora. |
| `Aurora_repl_bytes_received` | Número de bytes replicados em uma instância de banco de dados do leitor do Aurora MySQL desde a última reinicialização. Para obter mais informações, consulte [Replicação com o Amazon Aurora MySQL](AuroraMySQL.Replication.md). |
| `Aurora_reserved_mem_exceeded_incidents` | O número de vezes, desde a última reinicialização, que o engenheiro excedeu os limites de memória reservada. Se `aurora_oom_response` estiver configurado, esse limite definirá quando as atividades para evitar falta de memória (OOM) serão acionadas. Para receber mais informações sobre a resposta OOM do Aurora MySQL, consulte [Solucionar problemas de falta de memória em bancos de dados do Aurora MySQL](AuroraMySQLOOM.md). |
| `aurora_temptable_max_ram_allocation` | A quantidade máxima de memória, em bytes, usada em qualquer momento por tabelas temporárias internas desde a última reinicialização. |
| `aurora_temptable_ram_allocation` | A quantidade atual de memória, em bytes, usada pelas tabelas temporárias internas. |
| `Aurora_in_memory_relaylog_status` | O status atual do recurso de log de retransmissão na memória. O valor pode ser ENABLED ou DISABLED. |
| `Aurora_in_memory_relaylog_disabled_reason` | Mostra o motivo do status atual do recurso de log de retransmissão na memória; se o recurso estiver desabilitado, será exibida uma mensagem explicando por que o recurso está desabilitado. |
| `Aurora_in_memory_relaylog_fallback_count` | Mostra o número total de fallbacks do recurso de log de retransmissão na memória para o modo de log de retransmissão persistente (legado). O fallback pode ser causado por um único evento maior que o tamanho do cache (no momento, 128 MB) ou por uma nova tentativa de transação que excede o limite de repetição de transação de réplica replica\$1transaction\$1retries. |
| `Aurora_in_memory_relaylog_recovery_count` | Mostra o número total de recuperações de log de retransmissão na memória executadas automaticamente. Essa contagem inclui o número total de fallbacks e o número de retornos do modo automático para o modo de log de retransmissão na memória após os fallbacks temporários. |
| `Aurora_thread_pool_thread_count` | O número atual de segmentos no grupo de segmentos do Aurora. Para receber mais informações sobre o grupo de segmentos no Aurora MySQL, consulte [Pool de threads](AuroraMySQL.Managing.Tuning.concepts.md#AuroraMySQL.Managing.Tuning.concepts.processes.pool). |
| `Aurora_tmz_version` | Indica a versão atual das informações de fuso horário usadas pelo cluster de banco de dados. Os valores seguem o formato Internet Assigned Numbers Authority (IANA): `YYYYsuffix`; por exemplo, `2022a` e `2023c`. Esse parâmetro se aplica ao Aurora MySQL versão 2.12 e posterior e versão 3.04 e posterior. |
| `Aurora_zdr_oom_threshold` | Representa o limite de memória, em quilobytes (KB), para que uma instância de banco de dados do Aurora inicie uma reinicialização com tempo de inatividade zero (ZDR) para se recuperar de possíveis problemas relacionados à memória. |
| `server_aurora_das_running` | Indica se Database Activity Streams (DAS) está habilitado ou desabilitado nessa instância de banco de dados. Para obter mais informações, consulte [Monitorar o Amazon Aurora com o recurso Database Activity Streams](DBActivityStreams.md). |
## Variáveis de status do MySQL não se aplicam ao Aurora MySQL
Por causa das diferenças de arquitetura entre o Aurora MySQL e o MySQL, algumas variáveis de status do MySQL não se aplicam ao Aurora MySQL.
As variáveis de status do MySQL a seguir não são aplicáveis ao Aurora MySQL. Essa lista não é exaustiva.
+ `innodb_buffer_pool_bytes_dirty`
+ `innodb_buffer_pool_pages_dirty`
+ `innodb_buffer_pool_pages_flushed`
O Aurora MySQL versão 3 remove as seguintes variáveis de status presentes no Aurora MySQL versão 2:
+ `AuroraDb_lockmgr_bitmaps0_in_use`
+ `AuroraDb_lockmgr_bitmaps1_in_use`
+ `AuroraDb_lockmgr_bitmaps_mem_used`
+ `AuroraDb_thread_deadlocks`
+ `available_alter_table_log_entries`
+ `Aurora_lockmgr_memory_used`
+ `Aurora_missing_history_on_replica_incidents`
+ `Aurora_new_lock_manager_lock_release_cnt`
+ `Aurora_new_lock_manager_lock_release_total_duration_micro`
+ `Aurora_new_lock_manager_lock_timeout_cnt`
+ `Aurora_total_op_memory`
+ `Aurora_total_op_temp_space`
+ `Aurora_used_alter_table_log_entries`
+ `Aurora_using_new_lock_manager`
+ `Aurora_volume_bytes_allocated`
+ `Aurora_volume_bytes_left_extent`
+ `Aurora_volume_bytes_left_total`
+ `Com_alter_db_upgrade`
+ `Compression`
+ `External_threads_connected`
+ `Innodb_available_undo_logs`
+ `Last_query_cost`
+ `Last_query_partial_plans`
+ `Slave_heartbeat_period`
+ `Slave_last_heartbeat`
+ `Slave_received_heartbeats`
+ `Slave_retried_transactions`
+ `Slave_running`
+ `Time_since_zero_connections`
Estas variáveis de status do MySQL estão disponíveis no Aurora MySQL versão 2, mas não no Aurora MySQL versão 3:
+ `Innodb_redo_log_enabled`
+ `Innodb_undo_tablespaces_total`
+ `Innodb_undo_tablespaces_implicit`
+ `Innodb_undo_tablespaces_explicit`
+ `Innodb_undo_tablespaces_active`
# Eventos de espera do Aurora MySQL
Os seguintes são alguns eventos de espera comuns para o Aurora MySQL.
**nota**
Para ter informações sobre como ajustar a performance do Aurora MySQL usando eventos de espera, consulte [Ajustar o Aurora MySQL com eventos de espera](AuroraMySQL.Managing.Tuning.wait-events.md).
Para obter informações sobre as convenções de nomenclatura usadas em eventos de espera do MySQL, consulte [ Performance Schema instrument naming conventions](https://dev.mysql.com/doc/refman/8.0/en/performance-schema-instrument-naming.html) na documentação do MySQL.
**cpu**
O número de conexões ativas que estão prontas para execução é consistentemente maior que o número de vCPUs. Para obter mais informações, consulte [cpu](ams-waits.cpu.md).
**io/aurora\$1redo\$1log\$1flush**
Uma sessão está mantendo dados no armazenamento do Aurora. Normalmente, esse evento de espera é para uma operação de E/S de gravação no Aurora MySQL. Para obter mais informações, consulte [io/aurora\$1redo\$1log\$1flush](ams-waits.io-auredologflush.md).
**io/aurora\$1respond\$1to\$1client**
O processamento da consulta foi concluído e os resultados estão sendo retornados ao cliente da aplicação para as seguintes versões do Aurora MySQL: 2.10.2 e versões 2.10 posteriores, 2.09.3 e versões 2.09 posteriores, e 2.07.7 e versões 2.07 posteriores. Compare a largura de banda da rede da classe de instância de banco de dados com o tamanho do conjunto de resultados que está sendo retornado. Além disso, confira os tempos de resposta no lado do cliente. Se o cliente não responder e não conseguir processar os pacotes TCP, poderão ocorrer descartes de pacotes e retransmissões TCP. Essa situação afeta negativamente a largura de banda da rede. Nas versões inferiores às versões 2.10.2, 2.09.3 e 2.07.7, o evento de espera inclui incorretamente o tempo ocioso. Para aprender a ajustar seu banco de dados quando essa espera for proeminente, consulte [io/aurora\$1respond\$1to\$1client](ams-waits.respond-to-client.md).
**io/file/csv/data**
Threads estão gravando em tabelas no formato de valores separados por vírgula (CSV). Verifique o uso de sua tabela CSV. Uma causa típica desse evento é a definição de `log_output` em uma tabela.
**io/file/sql/binlog**
Um thread está aguardando um arquivo de log binário (binlog) que está sendo gravado em disco.
**io/redo\$1log\$1flush**
Uma sessão está mantendo dados no armazenamento do Aurora. Normalmente, esse evento de espera é para uma operação de E/S de gravação no Aurora MySQL. Para obter mais informações, consulte [io/redo\$1log\$1flush](ams-waits.io-redologflush.md).
**io/socket/sql/client\$1connection**
O programa `mysqld` está ocupado com a criação de threads para lidar com novas conexões de clientes de entrada. Para obter mais informações, consulte [io/socket/sql/client\$1connection](ams-waits.client-connection.md).
**io/table/sql/handler**
O mecanismo está aguardando acesso a uma tabela. Esse evento ocorre não importa se os dados estão armazenados em cache no grupo de buffer ou acessados no disco. Para obter mais informações, consulte [io/table/sql/handler](ams-waits.waitio.md).
**lock/table/sql/handler**
Este evento de espera é um manipulador de eventos de espera de bloqueio de tabela. Para ter mais informações sobre eventos "átomo" e "molécula" no Performance Schema, consulte o tópico sobre [Eventos "átomo" e "molécula" no Performance Schema](https://dev.mysql.com/doc/refman/8.0/en/performance-schema-atom-molecule-events.html), na documentação do MySQL.
**synch/cond/innodb/row\$1lock\$1wait**
Várias instruções de linguagem de manipulação de dados (DML) estão acessando as mesmas linhas de banco de dados simultaneamente. Para obter mais informações, consulte [synch/cond/innodb/row\$1lock\$1wait](ams-waits.row-lock-wait.md).
**synch/cond/innodb/row\$1lock\$1wait\$1cond**
Várias instruções DML estão acessando as mesmas linhas de banco de dados simultaneamente. Para obter mais informações, consulte [synch/cond/innodb/row\$1lock\$1wait\$1cond](ams-waits.row-lock-wait-cond.md).
**synch/cond/sql/MDL\$1context::COND\$1wait\$1status**
Threads estão aguardando em um bloqueio de metadados de tabela. O mecanismo utiliza esse tipo de bloqueio para gerenciar o acesso simultâneo a um esquema de banco de dados e garantir a consistência dos dados. Para ter mais informações, consulte [Optimizing locking operations](https://dev.mysql.com/doc/refman/8.0/en/locking-issues.html) na documentação do MySQL. Para aprender a ajustar seu banco de dados quando esse evento for proeminente, consulte [synch/cond/sql/MDL\$1context::COND\$1wait\$1status](ams-waits.cond-wait-status.md).
**synch/cond/sql/MYSQL\$1BIN\$1LOG::COND\$1done**
Você habilitou o registro em log binário. Pode haver uma alta taxa de transferência de confirmações, alto número de transações fazendo confirmações ou réplicas lendo binlogs. Considere utilizar instruções em várias linhas ou instruções de empacotamento em uma única transação. No Aurora, use bancos de dados globais em vez da replicação de logs binários ou use os parâmetros `aurora_binlog_*`.
**synch/mutex/innodb/aurora\$1lock\$1thread\$1slot\$1futex**
Várias instruções DML estão acessando as mesmas linhas de banco de dados simultaneamente. Para obter mais informações, consulte [synch/mutex/innodb/aurora\$1lock\$1thread\$1slot\$1futex](ams-waits.waitsynch.md).
**synch/mutex/innodb/buf\$1pool\$1mutex**
O grupo de buffer não é suficientemente grande para armazenar o conjunto de dados de trabalho. Ou a workload acessa páginas de uma tabela específica, resultando na contenção no grupo de buffer. Para obter mais informações, consulte [synch/mutex/innodb/buf\$1pool\$1mutex](ams-waits.bufpoolmutex.md).
**synch/mutex/innodb/fil\$1system\$1mutex**
O processo está esperando ter acesso ao cache de memória do espaço de tabelas. Para obter mais informações, consulte [synch/mutex/innodb/fil\$1system\$1mutex](ams-waits.innodb-fil-system-mutex.md).
**synch/mutex/innodb/trx\$1sys\$1mutex**
Operações estão verificando, atualizando, excluindo ou adicionando IDs de transações no InnoDB de maneira consistente ou controlada. Essas operações exigem uma chamada mutex `trx_sys` que é rastreada pela instrumentação do Performance Schema. Elas incluem o gerenciamento do sistema de transações quando o banco de dados é iniciado ou encerrado, reversões, limpezas de ações desfazer, acesso para leitura de linhas e cargas de grupos de buffer. A alta carga do banco de dados com um alto número de transações resulta no surgimento frequente desse evento de espera. Para obter mais informações, consulte [synch/mutex/innodb/trx\$1sys\$1mutex](ams-waits.trxsysmutex.md).
**synch/mutex/mysys/KEY\$1CACHE::cache\$1lock**
O mutex `keycache->cache_lock` controla o acesso ao cache de chaves para tabelas MyISAM. Embora o Aurora MySQL não permita o uso de tabelas MyISAM para armazenar dados persistentes, elas são usadas para armazenar tabelas temporárias internas. Considere conferir os contadores de status `created_tmp_disk_tables` ou `created_tmp_tables`, porque em determinadas situações, as tabelas temporárias são gravadas no disco quando não cabem mais na memória.
**synch/mutex/sql/FILE\$1AS\$1TABLE::LOCK\$1offsets**
O mecanismo obtém esse mutex quando abre ou cria um arquivo de metadados de tabela. Quando esse evento de espera ocorre excessivamente, significa que o número de tabelas criadas ou abertas aumentou.
**synch/mutex/sql/FILE\$1AS\$1TABLE::LOCK\$1shim\$1lists**
O mecanismo obtém esse mutex ao executar operações como `reset_size`,`detach_contents` ou `add_contents` na estrutura interna que controla tabelas abertas. O mutex sincroniza o acesso ao conteúdo das listas. Quando esse evento de espera ocorre com alta frequência, indica uma súbita mudança no conjunto de tabelas anteriormente acessadas. O mecanismo precisa acessar novas tabelas ou descartar o contexto relacionado a essas tabelas.
**synch/mutex/sql/LOCK\$1open**
O número de tabelas que estão sendo abertas pelas suas sessões excede o tamanho do cache de definição de tabelas ou do cache de abertura de tabelas. Aumente o tamanho desses caches. Para ter mais informações, consulte [Como o MySQL abre e fecha tabelas](https://dev.mysql.com/doc/refman/8.0/en/table-cache.html).
**synch/mutex/sql/LOCK\$1table\$1cache**
O número de tabelas que estão sendo abertas pelas suas sessões excede o tamanho do cache de definição de tabelas ou do cache de abertura de tabelas. Aumente o tamanho desses caches. Para ter mais informações, consulte [Como o MySQL abre e fecha tabelas](https://dev.mysql.com/doc/refman/8.0/en/table-cache.html).
**synch/mutex/sql/LOG**
Neste evento de espera, há threads aguardando um bloqueio de log. Por exemplo, um thread pode aguardar um bloqueio para gravar no arquivo de log de consultas lentas.
**synch/mutex/sql/MYSQL\$1BIN\$1LOG::LOCK\$1commit**
Neste evento de espera, há um thread aguardando para adquirir um bloqueio com a intenção de confirmar no log binário. A contenção do log binário pode ocorrer em bancos de dados com uma taxa de alteração muito alta. Dependendo da versão do MySQL, há alguns bloqueios usados para proteger a consistência e durabilidade do log binário. No RDS para MySQL, os logs binários são usados para a replicação e para o processo de backup automatizado. No Aurora MySQL, os logs binários não são necessários para a replicação ou backups nativos. Por padrão, eles estão desabilitados, mas podem ser habilitados e usados para replicação externa e captura de dados de alterações. Para ter mais informações, consulte [The binary log](https://dev.mysql.com/doc/refman/8.0/en/binary-log.html) na documentação do MySQL.
**sync/mutex/sql/MYSQL\$1BIN\$1LOG::LOCK\$1dump\$1thread\$1metrics\$1collection**
Se o registro em log binário estiver habilitado, o mecanismo obterá esse mutex ao imprimir métricas de threads de despejo ativo no log de erros do mecanismo e no mapa de operações interno.
**sync/mutex/sql/MYSQL\$1BIN\$1LOG::LOCK\$1inactive\$1binlogs\$1map**
Se o registro em log binário estiver habilitado, o mecanismo obterá esse mutex ao adicionar, excluir ou pesquisar na lista de arquivos binlog atrás do mais recente.
**sync/mutex/sql/MYSQL\$1BIN\$1LOG::LOCK\$1io\$1cache**
Se o registro em log binário estiver habilitado, o mecanismo obterá esse mutex durante operações de cache de E/S para binlog do Aurora: alocar, redimensionar, liberar, gravar, ler, limpar e acessar informações do cache. Se esse evento ocorrer com frequência, significa que o mecanismo está acessando o cache em que os eventos de log binário são armazenados. Para reduzir tempos de espera, reduza confirmações. Tente agrupar várias instruções em uma só transação.
**synch/mutex/sql/MYSQL\$1BIN\$1LOG::LOCK\$1log**
Você habilitou o registro em log binário. Pode haver uma alta taxa de transferência de confirmações, muitas transações fazendo confirmações ou réplicas lendo binlogs. Considere utilizar instruções em várias linhas ou instruções de empacotamento em uma única transação. No Aurora, use bancos de dados globais em vez da replicação de logs binários ou use os parâmetros `aurora_binlog_*`.
**synch/mutex/sql/SERVER\$1THREAD::LOCK\$1sync**
O mutex `SERVER_THREAD::LOCK_sync` é obtido durante o agendamento, o processamento ou a inicialização de threads para gravações em arquivos. A ocorrência excessiva desse evento de espera indica aumento na atividade de gravação no banco de dados.
**synch/mutex/sql/TABLESPACES:lock**
O mecanismo obtém o mutex `TABLESPACES:lock` durante as operações de espaço de tabela a seguir: criar, excluir, truncar e estender. A ocorrência excessiva desse evento de espera indica alta frequência de operações de espaço de tabela. Um exemplo é carregar muitos dados no banco de dados.
**synch/rwlock/innodb/dict**
Neste evento de espera, há threads aguardando um rwlock mantido no dicionário de dados InnoDB.
**synch/rwlock/innodb/dict\$1operation\$1lock**
Neste evento de espera, há threads aguardando bloqueios nas operações do dicionário de dados InnoDB.
**synch/rwlock/innodb/dict sys RW lock**
É acionado ao mesmo tempo um alto número de instruções de linguagem de controle de dados (DCLs) simultâneas no código de linguagem de definição de dados (DDLs). Reduza a dependência da aplicação por DDLs durante suas atividades regulares.
**synch/rwlock/innodb/index\$1tree\$1rw\$1lock**
Muitas instruções de linguagem de manipulação de dados (DML) estão acessando as mesmas linhas de objetos de banco de dados simultaneamente. Tente utilizar instruções com várias linhas. Além disso, disperse a workload por objetos de banco de dados diferentes. Por exemplo, implemente o particionamento.
**synch/sxlock/innodb/dict\$1operation\$1lock**
É acionado ao mesmo tempo um alto número de instruções de linguagem de controle de dados (DCLs) simultâneas no código de linguagem de definição de dados (DDLs). Reduza a dependência da aplicação por DDLs durante suas atividades regulares.
**synch/sxlock/innodb/dict\$1sys\$1lock**
É acionado ao mesmo tempo um alto número de instruções de linguagem de controle de dados (DCLs) simultâneas no código de linguagem de definição de dados (DDLs). Reduza a dependência da aplicação por DDLs durante suas atividades regulares.
**synch/sxlock/innodb/hash\$1table\$1locks**
A sessão não foi capaz de encontrar páginas no grupo de buffer. O mecanismo precisa ler um arquivo ou modificar a lista com utilização menos recente (LRU) para o grupo de buffer. Considere aumentar o tamanho do cache do buffer e melhorar caminhos de acesso para consultas relevantes.
**synch/sxlock/innodb/index\$1tree\$1rw\$1lock**
Muitas instruções de linguagem de manipulação de dados (DML) estão acessando as mesmas linhas de objetos de banco de dados simultaneamente. Tente utilizar instruções com várias linhas. Além disso, disperse a workload por objetos de banco de dados diferentes. Por exemplo, implemente o particionamento.
**synch/mutex/innodb/temp\$1pool\$1manager\$1mutex**
Esse evento de espera ocorre quando uma sessão está aguardando para adquirir um mutex para o grupo de tablespaces temporários de sessão.
Para ter mais informações sobre como solucionar problemas de eventos de espera de sincronização, consulte [Why is my MySQL DB instance showing a high number of active sessions waiting on SYNCH wait events in Performance Insights?](https://aws.amazon.com/premiumsupport/knowledge-center/aurora-mysql-synch-wait-events/) (Por que minha instância de banco de dados do MySQL está mostrando um grande número de sessões ativas aguardando eventos de espera SYNCH no Performance Insights?).
# Estados de threads do Aurora MySQL
Os seguintes são alguns estados de thread comuns do Aurora MySQL.
**checking permissions**
O thread está verificando se o servidor tem os privilégios necessários para executar a instrução.
**checking query cache for query**
O servidor está verificando se a consulta atual está presente no cache de consulta.
**cleaned up**
Este é o estado final de uma conexão cujo trabalho está concluído, mas que não foi encerrada pelo cliente. A melhor solução é encerrar a conexão explicitamente no código. Outra alternativa é definir um valor mais baixo para `wait_timeout` no grupo de parâmetros.
**closing tables**
O thread está liberando os dados de tabelas alterados no disco e encerrando as tabelas utilizadas. Se esta não for uma operação rápida, verifique as métricas de consumo de largura de banda de rede em relação à largura de banda de rede da classe de instância. Verifique também se os valores dos parâmetros para `table_open_cache` e `table_definition_cache` permitem que tabelas suficientes sejam abertas ao mesmo tempo, para que o mecanismo não precise abrir e fechar tabelas com frequência. Esses parâmetros influenciam o consumo de memória na instância.
**converting HEAP to MyISAM**
A consulta está convertendo uma tabela temporária de "na memória" para "no disco". A conversão é necessária porque as tabelas temporárias criadas pelo MySQL nas etapas intermediárias do processamento de consultas se tornaram grandes demais para a memória. Verifique os valores de `tmp_table_size` e `max_heap_table_size`. Em versões posteriores, o nome desse estado de thread é `converting HEAP to ondisk`.
**converting HEAP to ondisk**
O thread está convertendo uma tabela temporária interna de uma tabela "na memória" para uma tabela "no disco".
**copy to tmp table**
O thread está processando uma instrução `ALTER TABLE`. Esse estado ocorre após a criação da tabela com a nova estrutura, mas antes que as linhas sejam copiadas para ela. Para um thread nesse estado, é possível utilizar o Performance Schema para obter informações sobre o progresso da operação de cópia.
**creating sort index**
O Aurora MySQL está fazendo uma classificação porque não consegue utilizar um índice existente para satisfazer a cláusula `ORDER BY` ou `GROUP BY` de uma consulta. Para obter mais informações, consulte [criar índice de classificação](ams-states.sort-index.md).
**creating table**
O thread está criando uma tabela permanente ou temporária.
**delayed commit ok done**
Uma confirmação assíncrona no Aurora MySQL recebeu um reconhecimento e está concluída.
**delayed commit ok initiated**
O thread do Aurora MySQL iniciou o processo de confirmação assíncrona, mas está aguardando reconhecimento. Em geral, esse é o tempo de confirmação autêntico de uma transação.
**delayed send ok done**
Um thread de operador do Aurora MySQL que está vinculado a uma conexão pode ser liberado enquanto uma resposta é enviada ao cliente. O thread pode iniciar outro trabalho. O estado `delayed send ok` indica que o reconhecimento assíncrono para o cliente foi concluído.
**delayed send ok initiated**
Um thread de operador do Aurora MySQL enviou uma resposta assíncrona a um cliente e está livre para trabalhar com outras conexões. A transação iniciou um processo de confirmação assíncrona que ainda não foi reconhecido.
**executing**
O thread iniciou a execução de uma instrução.
**freeing items**
O thread executou um comando. Algumas liberações de itens realizadas nesse estado envolvem o cache de consulta. Em geral, esse estado é seguido por uma limpeza.
**init**
Esse estado ocorre antes da inicialização de instruções `ALTER TABLE`,`DELETE`,`INSERT`,`SELECT` ou `UPDATE`. As ações nesse estado incluem liberar o log binário ou o log do InnoDB e a limpeza do cache de consulta.
**A origem enviou todos os logs binários à réplica; aguardando mais atualizações.**
O nó primário terminou sua parte da replicação. O thread está aguardando mais consultas serem executadas para poder gravar no log binário (binlog).
**opening tables**
O thread está tentando abrir uma tabela. Essa operação é rápida, a menos que uma instrução `ALTER TABLE` ou `LOCK TABLE` precise ser encerrada ou exceda o valor de `table_open_cache`.
**optimizing**
O servidor está fazendo otimizações iniciais para uma consulta.
**preparing**
Esse estado ocorre durante a otimização de consultas.
**query end**
Esse estado ocorre após o processamento de uma consulta, mas antes do estado de liberação de itens.
**removing duplicates**
O Aurora MySQL não conseguiu otimizar uma operação `DISTINCT` no estágio inicial de uma consulta. O Aurora MySQL precisa remover todas as linhas duplicadas antes de enviar o resultado ao cliente.
**searching rows for update**
O thread está localizando todas as linhas correspondentes antes de as atualizar. Este estágio será necessário se o `UPDATE` estiver alterando o índice usado pelo mecanismo para localizar as linhas.
**sending binlog event to slave**
O thread fez a leitura de um evento do log binário e o está enviando para a réplica.
**sending cached result to client**
O servidor está obtendo o resultado de uma consulta do cache de consultas e o enviando ao cliente.
**sending data**
O thread está fazendo a leitura e o processamento de linhas para uma instrução `SELECT`, mas ainda não começou a enviar dados ao cliente. O processo está identificando quais páginas contêm os resultados necessários para atender à consulta. Para obter mais informações, consulte [enviar dados](ams-states.sending-data.md).
**sending to client**
O servidor está gravando um pacote para o cliente. Em versões anteriores do MySQL, esse evento de espera se chamava `writing to net`.
**starting**
Este é o primeiro estágio no início da execução da instrução.
**estatísticas**
O servidor está calculando estatísticas para desenvolver um plano de execução de consultas. Se um thread estiver nesse estado por um longo tempo, o servidor provavelmente está associado ao disco durante a realização de outros trabalhos.
**storing result in query cache**
O servidor está armazenando o resultado de uma consulta no cache de consultas.
**system lock**
O thread chamou `mysql_lock_tables`, mas o estado desse thread não foi atualizado desde a chamada. Esse estado geral ocorre por diversos motivos.
**atualizar**
O thread está se preparando para iniciar a atualização da tabela.
**atualizar**
O thread está procurando linhas e as está atualizando.
**user lock**
O thread emitiu uma chamada `GET_LOCK`. O thread solicitou um bloqueio consultivo e está aguardando por ele ou está planejando solicitá-lo.
**waiting for more updates**
O nó primário terminou sua parte da replicação. O thread está aguardando mais consultas serem executadas para poder gravar no log binário (binlog).
**waiting for schema metadata lock**
Uma espera por um bloqueio de metadados.
**waiting for stored function metadata lock**
Uma espera por um bloqueio de metadados.
**waiting for stored procedure metadata lock**
Uma espera por um bloqueio de metadados.
**waiting for table flush**
O thread está executando `FLUSH TABLES` e aguardando todos os threads fecharem suas tabelas. Ou, o thread recebeu uma notificação de que a estrutura subjacente de uma tabela foi modificada e, portanto, precisa reabrir essa tabela para obter a nova estrutura. Para reabrir a tabela, o thread deve aguardar até que todos os outros threads s tenham fechado. Essa notificação ocorre quando outro thread utilizou uma das seguintes instruções na tabela: `FLUSH TABLES`, `ALTER TABLE`, `RENAME TABLE`, `REPAIR TABLE`, `ANALYZE TABLE` ou `OPTIMIZE TABLE`.
**waiting for table level lock**
Uma sessão está mantendo um bloqueio em uma tabela enquanto outra sessão tenta obter esse mesmo bloqueio na mesma tabela.
**waiting for table metadata lock**
O Aurora MySQL utiliza o bloqueio de metadados para gerenciar o acesso simultâneo a objetos de banco de dados e garantir a consistência dos dados. Nesse evento de espera, uma sessão está mantendo um bloqueio de metadados em uma tabela enquanto outra sessão tenta obter esse mesmo bloqueio na mesma tabela. Quando o Performance Schema está habilitado, esse estado de thread é indicado como o evento de espera `synch/cond/sql/MDL_context::COND_wait_status`.
**writing to net**
O servidor está gravando um pacote na rede. Em versões posteriores do MySQL, esse evento de espera se chama `Sending to client`.
# Níveis de isolamento do Aurora MySQL
Descubra como as instâncias de banco de dados de um cluster do Aurora MySQL implementam a propriedade de isolamento do banco de dados. Este tópico explica como o comportamento padrão do Aurora MySQL se equilibra entre consistência rigorosa e alta performance. Você pode usar essas informações para decidir quando alterar as configurações padrão com base nas características da sua workload.
## Níveis de isolamento disponíveis para instâncias do gravador
Você pode usar os níveis de isolamento `REPEATABLE READ`, `READ COMMITTED`, `READ UNCOMMITTED` e `SERIALIZABLE` na instância primária de um cluster de banco de dados do Aurora MySQL. Esses níveis de isolamento funcionam no Aurora MySQL da mesma maneira que no RDS para MySQL.
## Nível de isolamento REPEATABLE READ (leitura repetível) para instâncias leitoras
Por padrão, as instâncias de banco de dados do Aurora MySQL configuradas como réplicas somente leitura do Aurora sempre usam o nível de isolamento `REPEATABLE READ`. Essas instâncias de banco de dados ignoram quaisquer instruções `SET TRANSACTION ISOLATION LEVEL` e continuam usando o nível de isolamento `REPEATABLE READ`.
## Nível de isolamento READ COMMITTED (leitura confirmada) para instâncias leitoras
Se sua aplicação incluir uma workload com alta demanda de gravação na instância primária e consultas demoradas nas réplicas do Aurora, você poderá enfrentar um atraso significativo na limpeza. *Atraso na limpeza* acontece quando a coleta de lixo interna é bloqueada por consultas demoradas. O sintoma visto é um valor alto para `history list length` na saída do comando `SHOW ENGINE INNODB STATUS`. Você pode monitorar esse valor usando a métrica `RollbackSegmentHistoryListLength` no CloudWatch. O atraso substancial na limpeza pode reduzir a eficácia dos índices secundários, reduzir a performance geral da consulta e gerar desperdício de espaço de armazenamento.
Se enfrentar esses problemas, você poderá definir uma configuração no nível da sessão do Aurora MySQL, `aurora_read_replica_read_committed`, para usar o nível de isolamento `READ COMMITTED` nas réplicas do Aurora. Ao aplicar essa configuração, você pode ajudar a reduzir a desaceleração e o desperdício de espaço resultantes da execução de consultas demoradas ao mesmo tempo em que as transações que modificam suas tabelas.
Recomendamos que você entenda o comportamento específico do Aurora MySQL de isolamento de `READ COMMITTED` antes de usar essa configuração. O comportamento de `READ COMMITTED` da réplica do Aurora está em conformidade com o padrão ANSI SQL. No entanto, o isolamento é menos rigoroso do que o comportamento típico de `READ COMMITTED` do MySQL com o qual você pode estar familiarizado. Portanto, os resultados da consulta com `READ COMMITTED` em uma réplica de leitura do Aurora MySQL poderão ser diferentes dos resultados da mesma consulta com `READ COMMITTED` na instância primária do Aurora MySQL ou no RDS para MySQL. Você pode usar a configuração `aurora_read_replica_read_committed` para esses casos como um relatório abrangente que verifica um banco de dados muito grande. Por outro lado, você pode evitá-la para consultas breves com pequenos conjuntos de resultados, em que a precisão e a repetibilidade são importantes.
O nível de isolamento `READ COMMITTED` não está disponível para sessões em um cluster secundário em um banco de dados global Aurora que usam o recurso de encaminhamento de gravação. Para obter informações sobre o encaminhamento de gravação, consulte [Como usar o encaminhamento de gravação em um banco de dados global Amazon Aurora](aurora-global-database-write-forwarding.md).
### Usar READ COMMITTED para leitores
Para usar o nível de isolamento `READ COMMITTED` para réplicas do Aurora, defina a configuração `aurora_read_replica_read_committed` como `ON`. Use essa configuração no nível da sessão enquanto estiver conectada a uma réplica específica do Aurora. Para fazer isso, execute os comandos SQL a seguir:
```
set session aurora_read_replica_read_committed = ON;
set session transaction isolation level read committed;
```
Você pode usar essa configuração temporariamente para executar consultas únicas interativas. Você também pode executar uma aplicação de relatórios ou análise de dados que se beneficie do nível de isolamento `READ COMMITTED`, mantendo a configuração padrão inalterada para outras aplicações.
Quando a configuração `aurora_read_replica_read_committed` estiver ativada, use o comando `SET TRANSACTION ISOLATION LEVEL` para especificar o nível de isolamento das transações apropriadas.
```
set transaction isolation level read committed;
```
### Diferenças no comportamento READ COMMITTED (LEITURA CONFIRMADA) das réplicas do Aurora
A configuração `aurora_read_replica_read_committed` disponibiliza o nível de isolamento `READ COMMITTED` para uma Réplica do Aurora, com comportamento de consistência otimizado para transações de longa execução. O nível de isolamento `READ COMMITTED` nas réplicas do Aurora é menos rigoroso do que nas instâncias primárias do Aurora. Por esse motivo, habilite essa configuração apenas nas Réplicas do Aurora, onde você sabe que suas consultas podem aceitar a possibilidade de certos tipos de resultados inconsistentes.
Suas consultas podem enfrentar certos tipos de anomalias de leitura quando a configuração `aurora_read_replica_read_committed` está habilitada. Dois tipos de anomalias são especialmente importantes para entender e lidar com o código da aplicação. Uma *non-repeatable read (leitura não repetível)* ocorre quando outra transação é confirmada enquanto sua consulta está em execução. Uma consulta demorada pode ter dados diferentes no início e no final da consulta. Uma *phantom read (leitura fantasma)* ocorre quando outras transações fazem com que as linhas existentes sejam reorganizadas enquanto a consulta está em execução, e uma ou mais linhas são lidas duas vezes pela consulta.
Suas consultas podem ter contagens de linhas inconsistentes como resultado de leituras fantasmas. Suas consultas também podem retornar resultados incompletos ou inconsistentes devido a leituras não repetíveis. Por exemplo, vamos supor que uma operação de junção se refira a tabelas modificadas simultaneamente por instruções SQL como `INSERT` ou `DELETE`. Nesse caso, a consulta de junção poderá ler uma linha de uma tabela, mas não a linha correspondente de outra tabela.
O padrão SQL ANSI permite esses comportamentos para o nível de isolamento `READ COMMITTED`. No entanto, esses comportamentos são diferentes da implementação típica do MySQL no `READ COMMITTED`. Portanto, antes de habilitar a configuração `aurora_read_replica_read_committed`, verifique qualquer código SQL existente para saber se ele opera conforme o esperado no modelo de consistência mais flexível.
A contagem de linhas e outros resultados podem não ser altamente consistentes no nível de isolamento `READ COMMITTED` enquanto essa configuração estiver habilitada. Dessa forma, geralmente habilita-se a configuração apenas ao executar consultas analíticas que agregam grandes quantidades de dados e não exigem precisão absoluta. Se você não tiver esse tipo de consultas demoradas com uma workload de gravação intensa, provavelmente não precisará da configuração `aurora_read_replica_read_committed`. Sem a combinação de consultas demoradas e uma workload de gravação intensa, é improvável que você enfrente problemas com o comprimento da lista de histórico.
**Example Consultas que mostram comportamento de isolamento para READ COMMITTED em réplicas do Aurora**
O exemplo a seguir mostra como as consultas `READ COMMITTED` em uma Réplica do Aurora podem retornar resultados não repetíveis se as transações modificarem as tabelas associadas simultaneamente. A tabela `BIG_TABLE` contém 1 milhão de linhas antes do início de qualquer consulta. Outras instruções de linguagem de manipulação de dados (DML) adicionam, removem ou alteram linhas enquanto estão em execução.
As consultas na instância primária do Aurora no nível de isolamento `READ COMMITTED` produzem resultados previsíveis. No entanto, os custos indiretos de manter a visualização de leitura consistente durante toda a vida útil de todas as consultas demoradas podem levar a uma coleta de lixo cara posteriormente.
As consultas na Réplica do Aurora no nível de isolamento `READ COMMITTED` são otimizadas para minimizar esses custos indiretos da coleta de lixo. A desvantagem é que os resultados podem variar dependendo do fato de as consultas recuperarem linhas adicionadas, removidas ou reorganizadas por transações confirmadas enquanto a consulta está em execução. As consultas não precisam, mas têm permissão para considerar essas linhas. Para fins de demonstração, as consultas verificam apenas o número de linhas na tabela usando a função `COUNT(*)`.
| Tempo | Instrução DML na instância primária do Aurora | Consulta na instância primária do Aurora com READ COMMITTED (LEITURA CONFIRMADA) | Consulta na réplica do Aurora com READ COMMITTED |
| --- | --- | --- | --- |
| T1 | INSERT INTO big\$1table SELECT \$1 FROM other\$1table LIMIT 1000000; COMMIT; | | |
| T2 | | Q1: SELECT COUNT(\$1) FROM big\$1table; | Q2: SELECT COUNT(\$1) FROM big\$1table; |
| T3 | INSERT INTO big\$1table (c1, c2) VALUES (1, 'one more row'); COMMIT; | | |
| T4 | | Se Q1 terminar agora, o resultado será 1.000.000. | Se Q2 terminar agora, o resultado será 1.000.000 ou 1.000.001. |
| T5 | DELETE FROM big\$1table LIMIT 2; COMMIT; | | |
| T6 | | Se Q1 terminar agora, o resultado será 1.000.000. | Se Q2 terminar agora, o resultado será 1.000.000 ou 1.000.001 ou 999.999 ou 999.998. |
| T7 | UPDATE big\$1table SET c2 = CONCAT(c2,c2,c2); COMMIT; | | |
| T8 | | Se Q1 terminar agora, o resultado será 1.000.000. | Se Q2 terminar agora, o resultado será 1.000.000 ou 1.000.001 ou 999.999 ou, possivelmente, um número superior. |
| T9 | | Q3: SELECT COUNT(\$1) FROM big\$1table; | Q4: SELECT COUNT(\$1) FROM big\$1table; |
| T10 | | Se Q3 terminar agora, o resultado será 999.999. | Se Q4 terminar agora, o resultado será 999.999. |
| T11 | | Q5: SELECT COUNT(\$1) FROM parent\$1table p JOIN child\$1table c ON (p.id = c.id) WHERE p.id = 1000; | Q6: SELECT COUNT(\$1) FROM parent\$1table p JOIN child\$1table c ON (p.id = c.id) WHERE p.id = 1000; |
| T12 | INSERT INTO parent\$1table (id, s) VALUES (1000, 'hello'); INSERT INTO child\$1table (id, s) VALUES (1000, 'world'); COMMIT; | | |
| T13 | | Se Q5 terminar agora, o resultado será 0. | Se Q6 terminar agora, o resultado será 0 ou 1. |
Se as consultas forem concluídas rapidamente, antes de qualquer outra transação executar instruções DML e ser confirmada, os resultados serão previsíveis e iguais entre a instância principal e a Réplica do Aurora. Vamos examinar as diferenças de comportamento em detalhes, começando pela primeira consulta.
Os resultados para Q1 são altamente previsíveis, porque `READ COMMITTED` na instância primária usa um modelo de consistência sólido semelhante ao nível de isolamento `REPEATABLE READ`.
Os resultados para Q2 podem variar dependendo de quais transações são confirmadas enquanto a consulta está em execução. Por exemplo, vamos supor que outras transações executem instruções DML e sejam confirmadas enquanto as consultas estiverem em execução. Nesse caso, a consulta na Réplica do Aurora com o nível de isolamento `READ COMMITTED` poderá ou não levar em consideração as alterações. As contagens de linhas não são previsíveis da mesma maneira que no nível de isolamento `REPEATABLE READ`. Elas também não são tão previsíveis quanto as consultas executadas no nível de isolamento `READ COMMITTED` na instância primária ou em uma instância do RDS para MySQL.
A instrução `UPDATE` em T7 não altera realmente o número de linhas na tabela. No entanto, ao alterar o comprimento de uma coluna de tamanho variável, essa instrução pode fazer com que as linhas sejam reorganizadas internamente. Uma transação `READ COMMITTED` demorada pode visualizar a versão antiga de uma linha e, posteriormente, na mesma consulta, visualizar a nova versão da mesma linha. A consulta também pode ignorar as versões antiga e nova da linha, por isso a contagem de linhas pode ser diferente da esperada.
Os resultados de Q5 e Q6 podem ser idênticos ou ligeiramente diferentes. A consulta Q6 na Réplica do Aurora em `READ COMMITTED` pode, mas não precisa, visualizar as novas linhas confirmadas enquanto a consulta estiver em execução. Ela também pode visualizar a linha de uma tabela, mas não de outra. Se a consulta de junção não encontrar uma linha correspondente nas duas tabelas, ela retornará uma contagem igual a zero. Se a consulta localizar as duas novas linhas em `PARENT_TABLE` e `CHILD_TABLE`, ela retornará uma contagem igual a um. Em uma consulta demorada, as pesquisas nas tabelas unidas podem ocorrer em momentos amplamente distintos.
Essas diferenças de comportamento dependem do momento em que as transações são confirmadas e quando as consultas processam as linhas da tabela subjacente. Dessa forma, é mais provável que você visualize essas diferenças nas consultas de relatório que demoram minutos ou horas e são executadas em clusters do Aurora que processam transações OLTP ao mesmo tempo. Esses são os tipos de cargas de trabalho mistas que mais se beneficiam do nível de isolamento `READ COMMITTED` nas Réplicas do Aurora.
# Dicas do Aurora MySQL
É possível usar dicas SQL com consultas do Aurora MySQL para ajustar a performance. Também é possível usar dicas para impedir que planos de execução para consultas importantes sejam alterados devido a condições imprevisíveis.
**dica**
Para verificar o efeito que uma dica tem em uma consulta, examine o plano de consulta produzido pela instrução `EXPLAIN`. Compare os planos de consulta com e sem a dica.
No Aurora MySQL versão 3, é possível usar todas as dicas disponíveis no MySQL Community Edition 8.0. Para ter mais informações sobre essas dicas, consulte [Dicas do Optimizer](https://dev.mysql.com/doc/refman/8.0/en/optimizer-hints.html) no *Guia de referência do MySQL*.
As dicas a seguir estão disponíveis no Aurora MySQL versão 2. Elas se aplicam a consultas que usam o recurso de junção de hash no Aurora MySQL versão 2, especialmente a consultas que usam a otimização de consultas paralelas.
**PQ, NO\$1PQ**
Especifica se deve forçar o Optimizer a usar a consulta paralela por tabela ou por consulta.
`PQ` força o Optimizer a usar a consulta paralela para tabelas especificadas ou para toda a consulta (bloco). `NO_PQ` impede que o Optimizer use a consulta paralela para tabelas especificadas ou para toda a consulta (bloco).
Esta dica está disponível no Aurora MySQL versão 2.11 e posterior. Os exemplos a seguir mostram como usar essa dica.
A especificação de um nome de tabela força o Optimizer a aplicar a dica `PQ/NO_PQ` somente às tabelas selecionadas. Não especificar um nome de tabela força a dica `PQ/NO_PQ` em todas as tabelas afetadas pelo bloco de consulta.
```
EXPLAIN SELECT /*+ PQ() */ f1, f2
FROM num1 t1 WHERE f1 > 10 and f2 < 100;
EXPLAIN SELECT /*+ PQ(t1) */ f1, f2
FROM num1 t1 WHERE f1 > 10 and f2 < 100;
EXPLAIN SELECT /*+ PQ(t1,t2) */ f1, f2
FROM num1 t1, num1 t2 WHERE t1.f1 = t2.f21;
EXPLAIN SELECT /*+ NO_PQ() */ f1, f2
FROM num1 t1 WHERE f1 > 10 and f2 < 100;
EXPLAIN SELECT /*+ NO_PQ(t1) */ f1, f2
FROM num1 t1 WHERE f1 > 10 and f2 < 100;
EXPLAIN SELECT /*+ NO_PQ(t1,t2) */ f1, f2
FROM num1 t1, num1 t2 WHERE t1.f1 = t2.f21;
```
**HASH\$1JOIN, NO\$1HASH\$1JOIN**
Ativa ou desativa a capacidade do Optimizer de consulta paralela de escolher se deseja usar o método de otimização de junção de hash para uma consulta. `HASH_JOIN` permite que o Optimizer use junção de hash se esse mecanismo for mais eficiente. `NO_HASH_JOIN` impede que o Optimizer use junção de hash para a consulta. Esta dica está disponível no Aurora MySQL versão 2.08 e posterior. Ela não tem efeito no Aurora MySQL versão 3.
Os exemplos a seguir mostram como usar essa dica.
```
EXPLAIN SELECT/*+ HASH_JOIN(t2) */ f1, f2
FROM t1, t2 WHERE t1.f1 = t2.f1;
EXPLAIN SELECT /*+ NO_HASH_JOIN(t2) */ f1, f2
FROM t1, t2 WHERE t1.f1 = t2.f1;
```
**HASH\$1JOIN\$1PROBING, NO\$1HASH\$1JOIN\$1PROBING**
Em uma consulta de junção de hash, especifica se deve ou não usar a tabela especificada para o lado de teste da junção. A consulta testa se os valores de coluna da tabela de compilação existem na tabela de teste, em vez de ler todo o conteúdo da tabela de teste. É possível usar `HASH_JOIN_PROBING` e `HASH_JOIN_BUILDING` para especificar como as consultas de junção hash são processadas sem reordenar as tabelas dentro do texto da consulta. Esta dica está disponível no Aurora MySQL versão 2.08 e posterior. Ela não tem efeito no Aurora MySQL versão 3.
Os exemplos a seguir mostram como usar essa dica. Especificar a dica `HASH_JOIN_PROBING` para a tabela `T2` tem o mesmo efeito que especificar `NO_HASH_JOIN_PROBING` para a tabela `T1`.
```
EXPLAIN SELECT /*+ HASH_JOIN(t2) HASH_JOIN_PROBING(t2) */ f1, f2
FROM t1, t2 WHERE t1.f1 = t2.f1;
EXPLAIN SELECT /*+ HASH_JOIN(t2) NO_HASH_JOIN_PROBING(t1) */ f1, f2
FROM t1, t2 WHERE t1.f1 = t2.f1;
```
**HASH\$1JOIN\$1BUILDING, NO\$1HASH\$1JOIN\$1BUILDING**
Em uma consulta de junção de hash, especifica se deve ou não usar a tabela especificada para o lado de compilação da junção. A consulta processa todas as linhas desta tabela para criar a lista de valores de coluna para referência cruzada com a outra tabela. É possível usar `HASH_JOIN_PROBING` e `HASH_JOIN_BUILDING` para especificar como as consultas de junção hash são processadas sem reordenar as tabelas dentro do texto da consulta. Esta dica está disponível no Aurora MySQL versão 2.08 e posterior. Ela não tem efeito no Aurora MySQL versão 3.
Os exemplos a seguir mostram como usar essa dica. Especificar a dica `HASH_JOIN_BUILDING` para a tabela `T2` tem o mesmo efeito que especificar `NO_HASH_JOIN_BUILDING` para a tabela `T1`.
```
EXPLAIN SELECT /*+ HASH_JOIN(t2) HASH_JOIN_BUILDING(t2) */ f1, f2
FROM t1, t2 WHERE t1.f1 = t2.f1;
EXPLAIN SELECT /*+ HASH_JOIN(t2) NO_HASH_JOIN_BUILDING(t1) */ f1, f2
FROM t1, t2 WHERE t1.f1 = t2.f1;
```
**JOIN\$1FIXED\$1ORDER**
Especifica que as tabelas na consulta são unidas com base na ordem em que são listadas na consulta. É útil com consultas que envolvem três ou mais tabelas. Deve ser um substituto da dica `STRAIGHT_JOIN` do MySQL e é equivalente à dica [JOIN\$1FIXED\$1ORDER](https://dev.mysql.com/doc/refman/8.0/en/optimizer-hints.html) do MySQL. Esta dica está disponível no Aurora MySQL versão 2.08 e posterior.
Os exemplos a seguir mostram como usar essa dica.
```
EXPLAIN SELECT /*+ JOIN_FIXED_ORDER() */ f1, f2
FROM t1 JOIN t2 USING (id) JOIN t3 USING (id) JOIN t4 USING (id);
```
**JOIN\$1ORDER**
Especifica a ordem de junção para as tabelas na consulta. É útil com consultas que envolvem três ou mais tabelas. É equivalente à dica [JOIN\$1ORDER](https://dev.mysql.com/doc/refman/8.0/en/optimizer-hints.html) do MySQL. Esta dica está disponível no Aurora MySQL versão 2.08 e posterior.
Os exemplos a seguir mostram como usar essa dica.
```
EXPLAIN SELECT /*+ JOIN_ORDER (t4, t2, t1, t3) */ f1, f2
FROM t1 JOIN t2 USING (id) JOIN t3 USING (id) JOIN t4 USING (id);
```
**JOIN\$1PREFIX**
Especifica as tabelas a serem colocadas em primeiro lugar na ordem de junção. É útil com consultas que envolvem três ou mais tabelas. É equivalente à dica [JOIN\$1PREFIX](https://dev.mysql.com/doc/refman/8.0/en/optimizer-hints.html) do MySQL. Esta dica está disponível no Aurora MySQL versão 2.08 e posterior.
Os exemplos a seguir mostram como usar essa dica.
```
EXPLAIN SELECT /*+ JOIN_PREFIX (t4, t2) */ f1, f2
FROM t1 JOIN t2 USING (id) JOIN t3 USING (id) JOIN t4 USING (id);
```
**JOIN\$1SUFFIX**
Especifica as tabelas a serem colocadas por último na ordem de junção. É útil com consultas que envolvem três ou mais tabelas. É equivalente à dica [JOIN\$1SUFFIX](https://dev.mysql.com/doc/refman/8.0/en/optimizer-hints.html) do MySQL. Esta dica está disponível no Aurora MySQL versão 2.08 e posterior.
Os exemplos a seguir mostram como usar essa dica.
```
EXPLAIN SELECT /*+ JOIN_SUFFIX (t1) */ f1, f2
FROM t1 JOIN t2 USING (id) JOIN t3 USING (id) JOIN t4 USING (id);
```
Para obter informações sobre como usar consultas de junção de hash, consulte [Otimizando grandes consultas de junção do Aurora MySQL com junções hash](AuroraMySQL.BestPractices.Performance.md#Aurora.BestPractices.HashJoin).
# Referência de procedimentos armazenados do Aurora MySQL
Você pode gerenciar seu cluster de bancos de dados do Aurora MySQL chamando procedimentos armazenados integrados.
**Topics**
+ [Coletar e manter o histórico de status global](mysql-stored-proc-gsh.md)
+ [Configurar, iniciar e interromper a replicação de logs binários (binlogs)](mysql-stored-proc-replicating.md)
+ [Encerrar uma sessão ou consulta](mysql-stored-proc-ending.md)
+ [Replicar transações com GTIDs](mysql-stored-proc-gtid.md)
+ [Alternar os logs de consulta](mysql-stored-proc-logging.md)
+ [Definir e mostrar a configuração de logs binários](mysql-stored-proc-configuring.md)
# Coletar e manter o histórico de status global
O Amazon RDS fornece um conjunto de procedimentos que gera snapshots dos valores dessas variáveis de status ao longo do tempo e as grava em uma tabela, juntamente com quaisquer alterações feitas desde o último snapshot. Essa infraestrutura é chamada de histórico de status global. Para obter mais informações, consulte [Gerenciar o histórico de status global](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.MySQL.CommonDBATasks.html#Appendix.MySQL.CommonDBATasks.GoSH).
Os procedimentos armazenados a seguir gerenciam a forma como o histórico de status global é coletado e mantido.
**Topics**
+ [mysql.rds\$1collect\$1global\$1status\$1history](#mysql_rds_collect_global_status_history)
+ [mysql.rds\$1disable\$1gsh\$1collector](#mysql_rds_disable_gsh_collector)
+ [mysql.rds\$1disable\$1gsh\$1rotation](#mysql_rds_disable_gsh_rotation)
+ [mysql.rds\$1enable\$1gsh\$1collector](#mysql_rds_enable_gsh_collector)
+ [mysql.rds\$1enable\$1gsh\$1rotation](#mysql_rds_enable_gsh_rotation)
+ [mysql.rds\$1rotate\$1global\$1status\$1history](#mysql_rds_rotate_global_status_history)
+ [mysql.rds\$1set\$1gsh\$1collector](#mysql_rds_set_gsh_collector)
+ [mysql.rds\$1set\$1gsh\$1rotation](#mysql_rds_set_gsh_rotation)
## mysql.rds\$1collect\$1global\$1status\$1history
Gera um snapshot sob demanda para o histórico de status global.
### Sintaxe
```
CALL mysql.rds_collect_global_status_history;
```
## mysql.rds\$1disable\$1gsh\$1collector
Desativa os snapshots gerados pelo histórico de status global.
### Sintaxe
```
CALL mysql.rds_disable_gsh_collector;
```
## mysql.rds\$1disable\$1gsh\$1rotation
Desativa a rotação da tabela `mysql.global_status_history`.
### Sintaxe
```
CALL mysql.rds_disable_gsh_rotation;
```
## mysql.rds\$1enable\$1gsh\$1collector
Ativa o histórico de status global para gerar snapshots padrão em intervalos especificados por `rds_set_gsh_collector`.
### Sintaxe
```
CALL mysql.rds_enable_gsh_collector;
```
## mysql.rds\$1enable\$1gsh\$1rotation
Ativa a rotação do conteúdo da tabela `mysql.global_status_history` com o da `mysql.global_status_history_old` em intervalos especificados por `rds_set_gsh_rotation`.
### Sintaxe
```
CALL mysql.rds_enable_gsh_rotation;
```
## mysql.rds\$1rotate\$1global\$1status\$1history
Reveza o conteúdo da tabela `mysql.global_status_history` para o da `mysql.global_status_history_old` sob demanda.
### Sintaxe
```
CALL mysql.rds_rotate_global_status_history;
```
## mysql.rds\$1set\$1gsh\$1collector
Especifica o intervalo em minutos entre os snapshots gerados pelo histórico de status global.
### Sintaxe
```
CALL mysql.rds_set_gsh_collector(intervalPeriod);
```
### Parâmetros
*intervalPeriod*
O intervalo em minutos entre snapshots. O valor padrão é `5`.
## mysql.rds\$1set\$1gsh\$1rotation
Especifica o intervalo em dias entre os revezamentos da tabela `mysql.global_status_history`.
### Sintaxe
```
CALL mysql.rds_set_gsh_rotation(intervalPeriod);
```
### Parâmetros
*intervalPeriod*
O intervalo em dias entre os revezamentos da tabela. O valor padrão é `7`.
# Configurar, iniciar e interromper a replicação de logs binários (binlogs)
É possível os seguintes procedimentos armazenados enquanto estiver conectado à instância primária em um cluster do Aurora MySQL. Esses procedimentos controlam como as transações são replicadas de um banco de dados externo para o Aurora MySQL ou do Aurora MySQL para um banco de dados externo.
**Topics**
+ [mysql.rds\$1disable\$1session\$1binlog (Aurora MySQL versão 2)](#mysql_rds_disable_session_binlog)
+ [mysql.rds\$1enable\$1session\$1binlog (Aurora MySQL versão 2)](#mysql_rds_enable_session_binlog)
+ [mysql.rds\$1import\$1binlog\$1ssl\$1material](#mysql_rds_import_binlog_ssl_material)
+ [mysql.rds\$1next\$1master\$1log (Aurora MySQL versão 2)](#mysql_rds_next_master_log)
+ [mysql.rds\$1next\$1source\$1log (Aurora MySQL versão 3)](#mysql_rds_next_source_log)
+ [mysql.rds\$1remove\$1binlog\$1ssl\$1material](#mysql_rds_remove_binlog_ssl_material)
+ [mysql.rds\$1reset\$1external\$1master (Aurora MySQL versão 2)](#mysql_rds_reset_external_master)
+ [mysql.rds\$1reset\$1external\$1source (Aurora MySQL versão 3)](#mysql_rds_reset_external_source)
+ [mysql.rds\$1set\$1binlog\$1source\$1ssl (Aurora MySQL versão 3)](#mysql_rds_set_binlog_source_ssl)
+ [mysql.rds\$1set\$1external\$1master (Aurora MySQL versão 2)](#mysql_rds_set_external_master)
+ [mysql.rds\$1set\$1external\$1source (Aurora MySQL versão 3)](#mysql_rds_set_external_source)
+ [mysql.rds\$1set\$1external\$1master\$1with\$1auto\$1position (Aurora MySQL versão 2)](#mysql_rds_set_external_master_with_auto_position)
+ [mysql.rds\$1set\$1external\$1source\$1with\$1auto\$1position (Aurora MySQL versão 3)](#mysql_rds_set_external_source_with_auto_position)
+ [mysql.rds\$1set\$1master\$1auto\$1position (Aurora MySQL versão 2)](#mysql_rds_set_master_auto_position)
+ [mysql.rds\$1set\$1read\$1only (Aurora MySQL versão 3)](#mysql_rds_set_read_only)
+ [mysql.rds\$1set\$1session\$1binlog\$1format (Aurora MySQL versão 2)](#mysql_rds_set_session_binlog_format)
+ [mysql.rds\$1set\$1source\$1auto\$1position (Aurora MySQL versão 3)](#mysql_rds_set_source_auto_position)
+ [mysql.rds\$1skip\$1repl\$1error](#mysql_rds_skip_repl_error)
+ [mysql.rds\$1start\$1replication](#mysql_rds_start_replication)
+ [mysql.rds\$1start\$1replication\$1until(Aurora MySQL versão 3)](#mysql_rds_start_replication_until)
+ [mysql.rds\$1stop\$1replication](#mysql_rds_stop_replication)
## mysql.rds\$1disable\$1session\$1binlog (Aurora MySQL versão 2)
Desativa o registro em log binário para a sessão atual definindo a variável `sql_log_bin` como `OFF`.
### Sintaxe
```
CALL mysql.rds_disable_session_binlog;
```
### Parâmetros
Nenhum
### Observações de uso
Para um cluster de bancos de dados Aurora MySQL, você chama esse procedimento armazenado enquanto está conectado à instância primária.
Quanto ao Aurora, esse procedimento é compatível com o Aurora MySQL versão 2.12 e em versões posteriores compatíveis com o MySQL 5.7.
**nota**
No Aurora MySQL versão 3, é possível usar o comando a seguir para desabilitar o registro em log binário para a sessão atual, se tiver o privilégio `SESSION_VARIABLES_ADMIN`:
```
SET SESSION sql_log_bin = OFF;
```
## mysql.rds\$1enable\$1session\$1binlog (Aurora MySQL versão 2)
Ativa o registro em log binário para a sessão atual definindo a variável `sql_log_bin` como `ON`.
### Sintaxe
```
CALL mysql.rds_enable_session_binlog;
```
### Parâmetros
Nenhum
### Observações de uso
Para um cluster de bancos de dados Aurora MySQL, você chama esse procedimento armazenado enquanto está conectado à instância primária.
Quanto ao Aurora, esse procedimento é compatível com o Aurora MySQL versão 2.12 e em versões posteriores compatíveis com o MySQL 5.7.
**nota**
No Aurora MySQL versão 3, é possível usar o comando a seguir para habilitar o registro em log binário para a sessão atual, se tiver o privilégio `SESSION_VARIABLES_ADMIN`:
```
SET SESSION sql_log_bin = ON;
```
## mysql.rds\$1import\$1binlog\$1ssl\$1material
Importa o certificado da autoridade de certificação, o certificado de cliente e a chave de cliente em um cluster de bancos de dados do Aurora MySQL. As informações são necessárias para a comunicação de SSL e a replicação criptografada.
**nota**
Atualmente, esse procedimento é compatível com o Aurora MySQL versão 2: 2.09.2, 2.10.0, 2.10.1, e 2.11.0; e versão 3: 3.01.1 e posteriores.
### Sintaxe
```
CALL mysql.rds_import_binlog_ssl_material (
ssl_material
);
```
### Parâmetros
*ssl\$1material*
A carga de JSON que contém o conteúdo dos arquivos de formato .pem a seguir de um cliente MySQL:
+ "ssl\$1ca":"*Certificado de autoridade de certificação*"
+ "ssl\$1cert":"*Certificado de cliente*"
+ "ssl\$1key":"*Chave de cliente*"
### Observações de uso
Prepare para a replicação criptografada antes de executar este procedimento:
+ Se você não tem o SSL habilitado na instância de banco de dados de origem externa do MySQL e não tem uma chave de cliente e um certificado de cliente preparados, habilite o SSL no servidor de banco de dados MySQL e gere a chave de cliente e o certificado de cliente necessários.
+ Se o SSL estiver habilitado na instância de banco de dados de origem externa, forneça uma chave e um certificado de cliente para o cluster de bancos de dados Aurora MySQL. Se você não os tiver, gere uma nova chave e certificado para o cluster de bancos de dados Aurora MySQL. Para assinar o certificado de cliente, é necessário ter a chave da autoridade de certificação usada para configurar o SSL na instância de banco de dados de origem externa do MySQL.
Para obter mais informações, consulte [Creating SSL certificates and keys using openssl](https://dev.mysql.com/doc/refman/8.0/en/creating-ssl-files-using-openssl.html) na documentação do MySQL.
**Importante**
Após preparar para a replicação criptografada, use uma conexão SSL para executar este procedimento. A chave de cliente não deve ser transferida por meio de uma conexão incerta.
Este procedimento importa informações SSL de um banco de dados MySQL externo em um cluster de banco de dados Aurora MySQL. As informações de SSL estão em arquivos de formato .pem que contêm as informações SSL do cluster de banco de dados Aurora MySQL. Durante a replicação criptografada, o cluster do banco de dados de Aurora MySQL age como um cliente para o servidor de banco de dados do MySQL. Os certificados e chaves do cliente Aurora MySQL estão nos arquivos em formato .pem.
Você pode copiar informações desses arquivos no parâmetro `ssl_material` na carga de JSON correta. Para suportar a replicação criptografada, importe essas informações SSL no cluster do banco de dados Aurora MySQL.
A carga de JSON deve estar no seguinte formato.
```
'{"ssl_ca":"-----BEGIN CERTIFICATE-----
ssl_ca_pem_body_code
-----END CERTIFICATE-----\n","ssl_cert":"-----BEGIN CERTIFICATE-----
ssl_cert_pem_body_code
-----END CERTIFICATE-----\n","ssl_key":"-----BEGIN RSA PRIVATE KEY-----
ssl_key_pem_body_code
-----END RSA PRIVATE KEY-----\n"}'
```
### Exemplos
O exemplo a seguir importa informações de SSL no Aurora MySQL. Em arquivos de formato .pem, o código do corpo geralmente é maior que o código de corpo exibido no exemplo.
```
call mysql.rds_import_binlog_ssl_material(
'{"ssl_ca":"-----BEGIN CERTIFICATE-----
AAAAB3NzaC1yc2EAAAADAQABAAABAQClKsfkNkuSevGj3eYhCe53pcjqP3maAhDFcvBS7O6V
hz2ItxCih+PnDSUaw+WNQn/mZphTk/a/gU8jEzoOWbkM4yxyb/wB96xbiFveSFJuOp/d6RJhJOI0iBXr
lsLnBItntckiJ7FbtxJMXLvvwJryDUilBMTjYtwB+QhYXUMOzce5Pjz5/i8SeJtjnV3iAoG/cQk+0FzZ
qaeJAAHco+CY/5WrUBkrHmFJr6HcXkvJdWPkYQS3xqC0+FmUZofz221CBt5IMucxXPkX4rWi+z7wB3Rb
BQoQzd8v7yeb7OzlPnWOyN0qFU0XA246RA8QFYiCNYwI3f05p6KLxEXAMPLE
-----END CERTIFICATE-----\n","ssl_cert":"-----BEGIN CERTIFICATE-----
AAAAB3NzaC1yc2EAAAADAQABAAABAQClKsfkNkuSevGj3eYhCe53pcjqP3maAhDFcvBS7O6V
hz2ItxCih+PnDSUaw+WNQn/mZphTk/a/gU8jEzoOWbkM4yxyb/wB96xbiFveSFJuOp/d6RJhJOI0iBXr
lsLnBItntckiJ7FbtxJMXLvvwJryDUilBMTjYtwB+QhYXUMOzce5Pjz5/i8SeJtjnV3iAoG/cQk+0FzZ
qaeJAAHco+CY/5WrUBkrHmFJr6HcXkvJdWPkYQS3xqC0+FmUZofz221CBt5IMucxXPkX4rWi+z7wB3Rb
BQoQzd8v7yeb7OzlPnWOyN0qFU0XA246RA8QFYiCNYwI3f05p6KLxEXAMPLE
-----END CERTIFICATE-----\n","ssl_key":"-----BEGIN RSA PRIVATE KEY-----
AAAAB3NzaC1yc2EAAAADAQABAAABAQClKsfkNkuSevGj3eYhCe53pcjqP3maAhDFcvBS7O6V
hz2ItxCih+PnDSUaw+WNQn/mZphTk/a/gU8jEzoOWbkM4yxyb/wB96xbiFveSFJuOp/d6RJhJOI0iBXr
lsLnBItntckiJ7FbtxJMXLvvwJryDUilBMTjYtwB+QhYXUMOzce5Pjz5/i8SeJtjnV3iAoG/cQk+0FzZ
qaeJAAHco+CY/5WrUBkrHmFJr6HcXkvJdWPkYQS3xqC0+FmUZofz221CBt5IMucxXPkX4rWi+z7wB3Rb
BQoQzd8v7yeb7OzlPnWOyN0qFU0XA246RA8QFYiCNYwI3f05p6KLxEXAMPLE
-----END RSA PRIVATE KEY-----\n"}');
```
## mysql.rds\$1next\$1master\$1log (Aurora MySQL versão 2)
Altera a posição do log da instância de banco de dados de origem para o início do próximo log binário na instância de banco de dados de origem. Use este procedimento somente se estiver recebendo o erro 1236 de E/S de replicação em uma réplica de leitura.
### Sintaxe
```
CALL mysql.rds_next_master_log(
curr_master_log
);
```
### Parâmetros
*curr\$1master\$1log*
O índice do arquivo de log mestre atual. Por exemplo, se o arquivo atual dor denominado `mysql-bin-changelog.012345`, o índice será 12345. Para determinar o nome do arquivo de log do mestre, execute o comando `SHOW REPLICA STATUS` e veja o campo `Master_Log_File`.
### Observações de uso
O usuário mestre deve executar o procedimento `mysql.rds_next_master_log`.
**Atenção**
Chame `mysql.rds_next_master_log` somente se a replicação falhar após um failover de uma instância de banco de dados multi-AZ que for a origem da replicação, e o campo `Last_IO_Errno` do `SHOW REPLICA STATUS` reportar o erro 1236 de E/S.
Chamar `mysql.rds_next_master_log` pode resultar em perda de dados na réplica de leitura caso as transações na instância de origem não tenham sido gravadas no log binário no disco antes do evento de failover.
### Exemplos
Suponha que a replicação falhe em uma réplica de leitura do Aurora MySQL. A execução de `SHOW REPLICA STATUS\G` na réplica de leitura retorna o seguinte resultado:
```
*************************** 1. row ***************************
Replica_IO_State:
Source_Host: myhost.XXXXXXXXXXXXXXX.rr-rrrr-1.rds.amazonaws.com
Source_User: MasterUser
Source_Port: 3306
Connect_Retry: 10
Source_Log_File: mysql-bin-changelog.012345
Read_Source_Log_Pos: 1219393
Relay_Log_File: relaylog.012340
Relay_Log_Pos: 30223388
Relay_Source_Log_File: mysql-bin-changelog.012345
Replica_IO_Running: No
Replica_SQL_Running: Yes
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Source_Log_Pos: 30223232
Relay_Log_Space: 5248928866
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Source_SSL_Allowed: No
Source_SSL_CA_File:
Source_SSL_CA_Path:
Source_SSL_Cert:
Source_SSL_Cipher:
Source_SSL_Key:
Seconds_Behind_Master: NULL
Source_SSL_Verify_Server_Cert: No
Last_IO_Errno: 1236
Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: 'Client requested master to start replication from impossible position; the first event 'mysql-bin-changelog.013406' at 1219393, the last event read from '/rdsdbdata/log/binlog/mysql-bin-changelog.012345' at 4, the last byte read from '/rdsdbdata/log/binlog/mysql-bin-changelog.012345' at 4.'
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Source_Server_Id: 67285976
```
O campo `Last_IO_Errno` mostra que a instância está recebendo o erro 1236 de E/S. O campo `Master_Log_File` mostra que o nome do arquivo é `mysql-bin-changelog.012345`, o que significa que o índice de arquivos de log é `12345`. Para resolver o erro, chame `mysql.rds_next_master_log` com o seguinte parâmetro:
```
CALL mysql.rds_next_master_log(12345);
```
## mysql.rds\$1next\$1source\$1log (Aurora MySQL versão 3)
Altera a posição do log da instância de banco de dados de origem para o início do próximo log binário na instância de banco de dados de origem. Use este procedimento somente se estiver recebendo o erro 1236 de E/S de replicação em uma réplica de leitura.
### Sintaxe
```
CALL mysql.rds_next_source_log(
curr_source_log
);
```
### Parâmetros
*curr\$1source\$1log*
O índice do arquivo de log de origem atual. Por exemplo, se o arquivo atual dor denominado `mysql-bin-changelog.012345`, o índice será 12345. Para determinar o nome do arquivo de log de origem atual, execute o comando `SHOW REPLICA STATUS` e veja o campo `Source_Log_File`.
### Observações de uso
O usuário administrativo precisa executar o procedimento `mysql.rds_next_source_log`.
**Atenção**
Chame `mysql.rds_next_source_log` somente se a replicação falhar após um failover de uma instância de banco de dados multi-AZ que for a origem da replicação, e o campo `Last_IO_Errno` do `SHOW REPLICA STATUS` reportar o erro 1236 de E/S.
Chamar `mysql.rds_next_source_log` pode resultar em perda de dados na réplica de leitura caso as transações na instância de origem não tenham sido gravadas no log binário no disco antes do evento de failover. Você pode reduzir a chance de que isso aconteça configurando os parâmetros `sync_binlog` e `innodb_support_xa` da instância de origem como `1`, embora isso possa reduzir o desempenho.
### Exemplos
Suponha que a replicação falhe em uma réplica de leitura do Aurora MySQL. A execução de `SHOW REPLICA STATUS\G` na réplica de leitura retorna o seguinte resultado:
```
*************************** 1. row ***************************
Replica_IO_State:
Source_Host: myhost.XXXXXXXXXXXXXXX.rr-rrrr-1.rds.amazonaws.com
Source_User: MasterUser
Source_Port: 3306
Connect_Retry: 10
Source_Log_File: mysql-bin-changelog.012345
Read_Source_Log_Pos: 1219393
Relay_Log_File: relaylog.012340
Relay_Log_Pos: 30223388
Relay_Source_Log_File: mysql-bin-changelog.012345
Replica_IO_Running: No
Replica_SQL_Running: Yes
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Source_Log_Pos: 30223232
Relay_Log_Space: 5248928866
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Source_SSL_Allowed: No
Source_SSL_CA_File:
Source_SSL_CA_Path:
Source_SSL_Cert:
Source_SSL_Cipher:
Source_SSL_Key:
Seconds_Behind_Source: NULL
Source_SSL_Verify_Server_Cert: No
Last_IO_Errno: 1236
Last_IO_Error: Got fatal error 1236 from source when reading data from binary log: 'Client requested source to start replication from impossible position; the first event 'mysql-bin-changelog.013406' at 1219393, the last event read from '/rdsdbdata/log/binlog/mysql-bin-changelog.012345' at 4, the last byte read from '/rdsdbdata/log/binlog/mysql-bin-changelog.012345' at 4.'
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Source_Server_Id: 67285976
```
O campo `Last_IO_Errno` mostra que a instância está recebendo o erro 1236 de E/S. O campo `Source_Log_File` mostra que o nome do arquivo é `mysql-bin-changelog.012345`, o que significa que o índice de arquivos de log é `12345`. Para resolver o erro, chame `mysql.rds_next_source_log` com o seguinte parâmetro:
```
CALL mysql.rds_next_source_log(12345);
```
## mysql.rds\$1remove\$1binlog\$1ssl\$1material
Remove o certificado de autoridade de certificado, o certificado de cliente e a chave de cliente para comunicação SSL e replicação criptografada. Essas informações são importada usando [mysql.rds\$1import\$1binlog\$1ssl\$1material](#mysql_rds_import_binlog_ssl_material).
### Sintaxe
```
CALL mysql.rds_remove_binlog_ssl_material;
```
## mysql.rds\$1reset\$1external\$1master (Aurora MySQL versão 2)
Reconfigura uma instância de banco de dados do Aurora MySQL para que não seja mais uma réplica de leitura de uma instância do MySQL executada fora do Amazon RDS.
**Importante**
Para executar esse procedimento, `autocommit` deve estar habilitado. Para habilitá-lo, defina o parâmetro `autocommit` como `1`. Para obter informações sobre como modificar parâmetros, consulte [Modificar parâmetros em um grupo de parâmetros de banco de dados no Amazon Aurora](USER_WorkingWithParamGroups.Modifying.md).
### Sintaxe
```
CALL mysql.rds_reset_external_master;
```
### Observações de uso
O usuário mestre deve executar o procedimento `mysql.rds_reset_external_master`. Esse procedimento deve ser executado na instância de banco de dados MySQL a ser removida como a réplica de leitura de uma instância do MySQL sendo executada externamente ao Amazon RDS.
**nota**
Oferecemos esses procedimentos armazenados principalmente para permitir a replicação com instâncias do MySQL externas ao Amazon RDS. Recomendamos que você use réplicas do Aurora para gerenciar a replicação em um cluster de banco de dados do Aurora MySQL sempre que possível. Para obter informações sobre como gerenciar a replicação em clusters de banco de dados do Aurora MySQL, consulte [Usar réplicas do Aurora](AuroraMySQL.Replication.md#AuroraMySQL.Replication.Replicas).
Para obter mais informações sobre como usar a replicação para importar dados de uma instância do MySQL executada fora do Aurora MySQL, consulte [Replicação entre Aurora e o MySQL ou entre Aurora e outro cluster de banco de dados do Aurora (replicação de log binário)](AuroraMySQL.Replication.MySQL.md).
## mysql.rds\$1reset\$1external\$1source (Aurora MySQL versão 3)
Reconfigura uma instância de banco de dados do Aurora MySQL para que não seja mais uma réplica de leitura de uma instância do MySQL executada fora do Amazon RDS.
**Importante**
Para executar esse procedimento, `autocommit` deve estar habilitado. Para habilitá-lo, defina o parâmetro `autocommit` como `1`. Para obter informações sobre como modificar parâmetros, consulte [Modificar parâmetros em um grupo de parâmetros de banco de dados no Amazon Aurora](USER_WorkingWithParamGroups.Modifying.md).
### Sintaxe
```
CALL mysql.rds_reset_external_source;
```
### Observações de uso
O usuário administrativo precisa executar o procedimento `mysql.rds_reset_external_source`. Esse procedimento deve ser executado na instância de banco de dados MySQL a ser removida como a réplica de leitura de uma instância do MySQL sendo executada externamente ao Amazon RDS.
**nota**
Oferecemos esses procedimentos armazenados principalmente para permitir a replicação com instâncias do MySQL externas ao Amazon RDS. Recomendamos que você use réplicas do Aurora para gerenciar a replicação em um cluster de banco de dados do Aurora MySQL sempre que possível. Para obter informações sobre como gerenciar a replicação em clusters de banco de dados do Aurora MySQL, consulte [Usar réplicas do Aurora](AuroraMySQL.Replication.md#AuroraMySQL.Replication.Replicas).
## mysql.rds\$1set\$1binlog\$1source\$1ssl (Aurora MySQL versão 3)
Habilita a criptografia de `SOURCE_SSL` para replicação de logs binários. Consulte mais informações em [CHANGE REPLICATION SOURCE TO statement](https://dev.mysql.com/doc/refman/8.0/en/change-replication-source-to.html) na documentação do MySQL.
### Sintaxe
```
CALL mysql.rds_set_binlog_source_ssl(mode);
```
### Parâmetros
*modo*
Um valor que indica se a criptografia de `SOURCE_SSL` está habilitada:
+ `0`: a criptografia `SOURCE_SSL` está desabilitada. O padrão é `0`.
+ `1`: a criptografia `SOURCE_SSL` está habilitada. É possível configurar a criptografia usando SSL ou TLS.
### Observações de uso
Esse procedimento é compatível com o Aurora MySQL versão 3.06 e posterior.
## mysql.rds\$1set\$1external\$1master (Aurora MySQL versão 2)
Configura uma instância de banco de dados do Aurora MySQL para que seja uma réplica de leitura de uma instância do MySQL executada fora do Amazon RDS.
O procedimento `mysql.rds_set_external_master` está obsoleto e será removido em uma versão futura. Use `mysql.rds\$1set\$1external\$1source` em vez disso.
**Importante**
Para executar esse procedimento, `autocommit` deve estar habilitado. Para habilitá-lo, defina o parâmetro `autocommit` como `1`. Para obter informações sobre como modificar parâmetros, consulte [Modificar parâmetros em um grupo de parâmetros de banco de dados no Amazon Aurora](USER_WorkingWithParamGroups.Modifying.md).
### Sintaxe
```
CALL mysql.rds_set_external_master (
host_name
, host_port
, replication_user_name
, replication_user_password
, mysql_binary_log_file_name
, mysql_binary_log_file_location
, ssl_encryption
);
```
### Parâmetros
*host\$1name*
O nome de host ou o endereço IP da instância do MySQL executada externamente ao Amazon RDS que se tornará a instância de banco de dados de origem.
*host\$1port*
A porta usada para executar a instância do MySQL executada externamente ao Amazon RDS a ser configurada como a instância de banco de dados de origem. Se sua configuração de rede inclui replicação de porta Secure Shell (SSH) que converte o número da porta, especifique o número da porta exposto pelo SSH.
*replication\$1user\$1name*
O ID de um usuário com as permissões `REPLICATION CLIENT` e `REPLICATION SLAVE` na instância do MySQL executada externamente ao Amazon RDS. Recomendamos que você forneça uma conta que seja usada unicamente para a replicação com a instância externa.
*replication\$1user\$1password*
A senha do ID de usuário especificada em `replication_user_name`.
*mysql\$1binary\$1log\$1file\$1name*
O nome do log binário na instância de banco de dados de origem que contém as informações de replicação.
*mysql\$1binary\$1log\$1file\$1location*
O local no log binário `mysql_binary_log_file_name` no qual a replicação começa a ler as informações de replicação.
É possível determinar o nome e a localização do arquivo de binlog executando `SHOW MASTER STATUS` na instância do banco de dados de origem.
*ssl\$1encryption*
Um valor que especifica se a criptografia do Secure Sockets Layer (SSL) será usada na conexão de replicação. 1 especifica para usar criptografia de SSL, 0 especifica para não usar criptografia. O padrão é 0.
A opção `MASTER_SSL_VERIFY_SERVER_CERT` não tem suporte. Essa opção é definida como 0, o que significa que a conexão é criptografada, mas os certificados não são verificados.
### Observações de uso
O usuário mestre deve executar o procedimento `mysql.rds_set_external_master`. Esse procedimento deve ser executado na instância de banco de dados MySQL que será configurada como a réplica de leitura de uma instância do MySQL externa ao Amazon RDS.
Antes de executar `mysql.rds_set_external_master`, é necessário configurar a instância do MySQL executada externamente ao Amazon RDS para ser uma instância de banco de dados de origem. Para conectar-se à instância do MySQL sendo executada externamente ao Amazon RDS, você deve especificar valores de `replication_user_name` e `replication_user_password` que indicam um usuário de replicação com permissões de `REPLICATION CLIENT` e `REPLICATION SLAVE` na instância externa do MySQL.
**Como configurar uma instância externa do MySQL como uma instância de banco de dados de origem**
1. Usando o cliente do MySQL de sua escolha, conecte-se à instância externa do MySQL e crie uma conta de usuário a ser usada para a replicação. Veja um exemplo a seguir.
**MySQL 5.7**
```
CREATE USER 'repl_user'@'mydomain.com' IDENTIFIED BY 'password';
```
**MySQL 8.0**
```
CREATE USER 'repl_user'@'mydomain.com' IDENTIFIED WITH mysql_native_password BY 'password';
```
**nota**
Especifique uma senha diferente do prompt mostrado aqui como prática recomendada de segurança.
1. Na instância externa do MySQL, conceda privilégios de `REPLICATION CLIENT` e `REPLICATION SLAVE` para seu usuário de replicação. O exemplo a seguir concede privilégios de `REPLICATION CLIENT` e `REPLICATION SLAVE` ao usuário 'repl\$1user' em todos os bancos de dados de seu domínio.
**MySQL 5.7**
```
GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'mydomain.com' IDENTIFIED BY 'password';
```
**MySQL 8.0**
```
GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'mydomain.com';
```
Para usar a replicação criptografada, configure a instância de banco de dados de origem para usar conexões SSL. Além disso, importe o certificado da autoridade de certificação, o certificado e a chave de clientes na instância de banco de dados ou no cluster do banco de dados usando o procedimento [mysql.rds\$1import\$1binlog\$1ssl\$1material](#mysql_rds_import_binlog_ssl_material).
**nota**
Oferecemos esses procedimentos armazenados principalmente para permitir a replicação com instâncias do MySQL externas ao Amazon RDS. Recomendamos que você use réplicas do Aurora para gerenciar a replicação em um cluster de banco de dados do Aurora MySQL sempre que possível. Para obter informações sobre como gerenciar a replicação em clusters de banco de dados do Aurora MySQL, consulte [Usar réplicas do Aurora](AuroraMySQL.Replication.md#AuroraMySQL.Replication.Replicas).
Depois de chamar `mysql.rds_set_external_master` para configurar uma instância de banco de dados do Amazon RDS, é possível chamar [mysql.rds\$1start\$1replication](#mysql_rds_start_replication) na réplica de leitura para iniciar o processo de replicação. É possível chamar [mysql.rds\$1reset\$1external\$1master (Aurora MySQL versão 2)](#mysql_rds_reset_external_master) para remover a configuração da réplica de leitura.
Quando `mysql.rds_set_external_master` é chamado, o Amazon RDS grava a hora, o usuário e uma ação do `set master` nas tabelas `mysql.rds_history` e `mysql.rds_replication_status`.
### Exemplos
Ao executar em uma instância de banco de dados MySQL, o exemplo a seguir configura a instância do banco de dados para ser uma réplica de leitura de uma instância do MySQL que é executada externamente ao Amazon RDS.
```
call mysql.rds_set_external_master(
'Externaldb.some.com',
3306,
'repl_user',
'password',
'mysql-bin-changelog.0777',
120,
1);
```
## mysql.rds\$1set\$1external\$1source (Aurora MySQL versão 3)
Configura uma instância de banco de dados do Aurora MySQL para que seja uma réplica de leitura de uma instância do MySQL executada fora do Amazon RDS.
**Importante**
Para executar esse procedimento, `autocommit` deve estar habilitado. Para habilitá-lo, defina o parâmetro `autocommit` como `1`. Para obter informações sobre como modificar parâmetros, consulte [Modificar parâmetros em um grupo de parâmetros de banco de dados no Amazon Aurora](USER_WorkingWithParamGroups.Modifying.md).
### Sintaxe
```
CALL mysql.rds_set_external_source (
host_name
, host_port
, replication_user_name
, replication_user_password
, mysql_binary_log_file_name
, mysql_binary_log_file_location
, ssl_encryption
);
```
### Parâmetros
*host\$1name*
O nome de host ou o endereço IP da instância do MySQL executada externamente ao Amazon RDS que se tornará a instância de banco de dados de origem.
*host\$1port*
A porta usada para executar a instância do MySQL executada externamente ao Amazon RDS a ser configurada como a instância de banco de dados de origem. Se sua configuração de rede inclui replicação de porta Secure Shell (SSH) que converte o número da porta, especifique o número da porta exposto pelo SSH.
*replication\$1user\$1name*
O ID de um usuário com as permissões `REPLICATION CLIENT` e `REPLICATION SLAVE` na instância do MySQL executada externamente ao Amazon RDS. Recomendamos que você forneça uma conta que seja usada unicamente para a replicação com a instância externa.
*replication\$1user\$1password*
A senha do ID de usuário especificada em `replication_user_name`.
*mysql\$1binary\$1log\$1file\$1name*
O nome do log binário na instância de banco de dados de origem que contém as informações de replicação.
*mysql\$1binary\$1log\$1file\$1location*
O local no log binário `mysql_binary_log_file_name` no qual a replicação começa a ler as informações de replicação.
É possível determinar o nome e a localização do arquivo de binlog executando `SHOW MASTER STATUS` na instância do banco de dados de origem.
*ssl\$1encryption*
Um valor que especifica se a criptografia do Secure Sockets Layer (SSL) será usada na conexão de replicação. 1 especifica para usar criptografia de SSL, 0 especifica para não usar criptografia. O padrão é 0.
Você deve ter importado um certificado SSL personalizado usando [mysql.rds\$1import\$1binlog\$1ssl\$1material](#mysql_rds_import_binlog_ssl_material) para habilitar essa opção. Se você não importou um certificado SSL personalizado, defina esse parâmetro como 0 e use [mysql.rds\$1set\$1binlog\$1source\$1ssl (Aurora MySQL versão 3)](#mysql_rds_set_binlog_source_ssl) para habilitar o SSL para replicação de log binário.
A opção `SOURCE_SSL_VERIFY_SERVER_CERT` não tem suporte. Essa opção é definida como 0, o que significa que a conexão é criptografada, mas os certificados não são verificados.
### Observações de uso
O usuário administrativo precisa executar o procedimento `mysql.rds_set_external_source`. Esse procedimento deve ser executado na instância de banco de dados do Aurora MySQL que será configurada como a réplica de leitura de uma instância do MySQL externa ao Amazon RDS.
Antes de executar `mysql.rds_set_external_source`, é necessário configurar a instância do MySQL executada externamente ao Amazon RDS para ser uma instância de banco de dados de origem. Para conectar-se à instância do MySQL sendo executada externamente ao Amazon RDS, você deve especificar valores de `replication_user_name` e `replication_user_password` que indicam um usuário de replicação com permissões de `REPLICATION CLIENT` e `REPLICATION SLAVE` na instância externa do MySQL.
**Como configurar uma instância externa do MySQL como uma instância de banco de dados de origem**
1. Usando o cliente do MySQL de sua escolha, conecte-se à instância externa do MySQL e crie uma conta de usuário a ser usada para a replicação. Veja um exemplo a seguir.
```
CREATE USER 'repl_user'@'mydomain.com' IDENTIFIED BY 'password';
```
**nota**
Especifique uma senha diferente do prompt mostrado aqui como prática recomendada de segurança.
1. Na instância externa do MySQL, conceda privilégios de `REPLICATION CLIENT` e `REPLICATION SLAVE` para seu usuário de replicação. O exemplo a seguir concede privilégios de `REPLICATION CLIENT` e `REPLICATION SLAVE` ao usuário 'repl\$1user' em todos os bancos de dados de seu domínio.
```
GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'mydomain.com';
```
Para usar a replicação criptografada, configure a instância de banco de dados de origem para usar conexões SSL. Além disso, importe o certificado de autoridade de certificação, o certificado e a chave de clientes na instância de banco de dados ou no cluster de banco de dados usando o procedimento [mysql.rds\$1import\$1binlog\$1ssl\$1material](url-rds-user;mysql_rds_import_binlog_ssl_material.html).
**nota**
Oferecemos esses procedimentos armazenados principalmente para permitir a replicação com instâncias do MySQL externas ao Amazon RDS. Recomendamos que você use réplicas do Aurora para gerenciar a replicação em um cluster de banco de dados do Aurora MySQL sempre que possível. Para obter informações sobre como gerenciar a replicação em clusters de banco de dados do Aurora MySQL, consulte [Usar réplicas do Aurora](AuroraMySQL.Replication.md#AuroraMySQL.Replication.Replicas).
Depois de chamar `mysql.rds_set_external_source` para configurar uma instância de banco de dados do Aurora MySQL, é possível chamar [mysql.rds\$1start\$1replication](#mysql_rds_start_replication) na réplica de leitura para iniciar o processo de replicação. É possível chamar [mysql.rds\$1reset\$1external\$1source (Aurora MySQL versão 3)](#mysql_rds_reset_external_source) para remover a configuração da réplica de leitura.
Quando `mysql.rds_set_external_source` é chamado, o Amazon RDS grava a hora, o usuário e uma ação do `set master` nas tabelas `mysql.rds_history` e `mysql.rds_replication_status`.
### Exemplos
Quando executado em uma instância de banco de dados do Aurora MySQL, o exemplo a seguir configura a instância de banco de dados para ser uma réplica de leitura de uma instância do MySQL que é executada externamente ao Amazon RDS.
```
call mysql.rds_set_external_source(
'Externaldb.some.com',
3306,
'repl_user',
'password',
'mysql-bin-changelog.0777',
120,
1);
```
## mysql.rds\$1set\$1external\$1master\$1with\$1auto\$1position (Aurora MySQL versão 2)
Configura uma instância primária do Aurora MySQL para aceitar a replicação de entrada de uma instância externa do MySQL. Esse procedimento também configura a replicação com base em identificadores de transação global (GTIDs).
Esse procedimento não configura a replicação atrasada, pois o Aurora MySQL não oferece suporte à replicação atrasada.
### Sintaxe
```
CALL mysql.rds_set_external_master_with_auto_position (
host_name
, host_port
, replication_user_name
, replication_user_password
, ssl_encryption
);
```
### Parâmetros
*host\$1name*
O nome de host ou o endereço IP da instância do MySQL sendo executada externamente ao Aurora que se torna a origem de replicação.
*host\$1port*
A porta utilizada para executar a instância do MySQL sendo executada externamente ao Aurora a ser configurada como a origem de replicação. Se sua configuração de rede inclui replicação de porta Secure Shell (SSH) que converte o número da porta, especifique o número da porta exposto pelo SSH.
*replication\$1user\$1name*
O ID de um usuário com as permissões `REPLICATION CLIENT` e `REPLICATION SLAVE` na instância do MySQL executada externamente ao Aurora. Recomendamos que você forneça uma conta que seja usada unicamente para a replicação com a instância externa.
*replication\$1user\$1password*
A senha do ID de usuário especificada em `replication_user_name`.
*ssl\$1encryption*
Essa opção não está implementada atualmente. O padrão é 0.
### Observações de uso
Para um cluster de bancos de dados Aurora MySQL, você chama esse procedimento armazenado enquanto está conectado à instância primária.
O usuário mestre deve executar o procedimento `mysql.rds_set_external_master_with_auto_position`. O usuário principal executa esse procedimento na instância primária de um cluster de bancos de dados Aurora MySQL que atua como um destino de replicação. Este pode ser o destino de replicação de uma instância de banco de dados externa do MySQL ou um cluster de bancos de dados Aurora MySQL.
Esse procedimento é compatível com o Aurora MySQL versão 2. Para o Aurora MySQL versão 3, prefira usar o procedimento [mysql.rds\$1set\$1external\$1source\$1with\$1auto\$1position (Aurora MySQL versão 3)](#mysql_rds_set_external_source_with_auto_position).
Antes de executar o `mysql.rds_set_external_master_with_auto_position`, configure a instância de banco de dados externa do MySQL para ser uma origem de replicação. Para conectar-se à instância externa do MySQL, especifique valores para `replication_user_name` e `replication_user_password`. Esses valores devem indicar um usuário de replicação que tenha as permissões `REPLICATION CLIENT` e `REPLICATION SLAVE` na instância externa do MySQL.
**Para configurar uma instância externa do MySQL como uma origem de replicação**
1. Usando o cliente do MySQL de sua escolha, conecte-se à instância externa do MySQL e crie uma conta de usuário a ser usada para replicação. Veja um exemplo a seguir.
```
CREATE USER 'repl_user'@'mydomain.com' IDENTIFIED BY 'SomePassW0rd'
```
1. Para a instância externa do MySQL, conceda os privilégios `REPLICATION CLIENT` e `REPLICATION SLAVE` ao seu usuário de replicação. O exemplo a seguir concede privilégios de `REPLICATION CLIENT` e `REPLICATION SLAVE` ao usuário `'repl_user'` em todos os bancos de dados de seu domínio.
```
GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'mydomain.com'
IDENTIFIED BY 'SomePassW0rd'
```
Quando você chama `mysql.rds_set_external_master_with_auto_position`, o Amazon RDS registra algumas informações. Essas informações incluem o horário, o usuário e uma ação de `"set master"` nas tabelas `mysql.rds_history` e `mysql.rds_replication_status`.
Para ignorar uma transação específica baseada em GTID que seja conhecida por causar problemas, use o procedimento armazenado [mysql.rds\$1skip\$1transaction\$1with\$1gtid(Aurora MySQL versões 2 e 3)](mysql-stored-proc-gtid.md#mysql_rds_skip_transaction_with_gtid). Para obter mais informações sobre como trabalhar com a replicação baseada em GTID, consulte [Usar a replicação baseada em GTID](mysql-replication-gtid.md).
### Exemplos
Quando executado em uma instância primária do Aurora, o exemplo a seguir configura o cluster do Aurora para atuar como uma réplica de leitura de uma instância do MySQL executada fora do Aurora.
```
call mysql.rds_set_external_master_with_auto_position(
'Externaldb.some.com',
3306,
'repl_user'@'mydomain.com',
'SomePassW0rd');
```
## mysql.rds\$1set\$1external\$1source\$1with\$1auto\$1position (Aurora MySQL versão 3)
Configura uma instância primária do Aurora MySQL para aceitar a replicação de entrada de uma instância externa do MySQL. Esse procedimento também configura a replicação com base em identificadores de transação global (GTIDs).
### Sintaxe
```
CALL mysql.rds_set_external_source_with_auto_position (
host_name
, host_port
, replication_user_name
, replication_user_password
, ssl_encryption
);
```
### Parâmetros
*host\$1name*
O nome de host ou o endereço IP da instância do MySQL sendo executada externamente ao Aurora que se torna a origem de replicação.
*host\$1port*
A porta utilizada para executar a instância do MySQL sendo executada externamente ao Aurora a ser configurada como a origem de replicação. Se sua configuração de rede inclui replicação de porta Secure Shell (SSH) que converte o número da porta, especifique o número da porta exposto pelo SSH.
*replication\$1user\$1name*
O ID de um usuário com as permissões `REPLICATION CLIENT` e `REPLICATION SLAVE` na instância do MySQL executada externamente ao Aurora. Recomendamos que você forneça uma conta que seja usada unicamente para a replicação com a instância externa.
*replication\$1user\$1password*
A senha do ID de usuário especificada em `replication_user_name`.
*ssl\$1encryption*
Essa opção não está implementada atualmente. O padrão é 0.
Use [mysql.rds\$1set\$1binlog\$1source\$1ssl (Aurora MySQL versão 3)](#mysql_rds_set_binlog_source_ssl) para habilitar o SSL para replicação de logs binários.
### Observações de uso
Para um cluster de bancos de dados Aurora MySQL, você chama esse procedimento armazenado enquanto está conectado à instância primária.
O usuário administrativo precisa executar o procedimento `mysql.rds_set_external_source_with_auto_position`. O usuário administrativo executa esse procedimento na instância primária de um cluster de bancos de dados Aurora MySQL que atua como um destino de replicação. Este pode ser o destino de replicação de uma instância de banco de dados externa do MySQL ou um cluster de bancos de dados Aurora MySQL.
Esse procedimento é compatível com o Aurora MySQL versão 3. Esse procedimento não configura a replicação atrasada, pois o Aurora MySQL não oferece suporte à replicação atrasada.
Antes de executar o `mysql.rds_set_external_source_with_auto_position`, configure a instância de banco de dados externa do MySQL para ser uma origem de replicação. Para conectar-se à instância externa do MySQL, especifique valores para `replication_user_name` e `replication_user_password`. Esses valores devem indicar um usuário de replicação que tenha as permissões `REPLICATION CLIENT` e `REPLICATION SLAVE` na instância externa do MySQL.
**Para configurar uma instância externa do MySQL como uma origem de replicação**
1. Usando o cliente do MySQL de sua escolha, conecte-se à instância externa do MySQL e crie uma conta de usuário a ser usada para replicação. Veja um exemplo a seguir.
```
CREATE USER 'repl_user'@'mydomain.com' IDENTIFIED BY 'SomePassW0rd'
```
1. Para a instância externa do MySQL, conceda os privilégios `REPLICATION CLIENT` e `REPLICATION SLAVE` ao seu usuário de replicação. O exemplo a seguir concede privilégios de `REPLICATION CLIENT` e `REPLICATION SLAVE` ao usuário `'repl_user'` em todos os bancos de dados de seu domínio.
```
GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'mydomain.com'
IDENTIFIED BY 'SomePassW0rd'
```
Quando você chama `mysql.rds_set_external_source_with_auto_position`, o Amazon RDS registra algumas informações. Essas informações incluem o horário, o usuário e uma ação de `"set master"` nas tabelas `mysql.rds_history` e `mysql.rds_replication_status`.
Para ignorar uma transação específica baseada em GTID que seja conhecida por causar problemas, use o procedimento armazenado [mysql.rds\$1skip\$1transaction\$1with\$1gtid(Aurora MySQL versões 2 e 3)](mysql-stored-proc-gtid.md#mysql_rds_skip_transaction_with_gtid). Para obter mais informações sobre como trabalhar com a replicação baseada em GTID, consulte [Usar a replicação baseada em GTID](mysql-replication-gtid.md).
### Exemplos
Quando executado em uma instância primária do Aurora, o exemplo a seguir configura o cluster do Aurora para atuar como uma réplica de leitura de uma instância do MySQL executada fora do Aurora.
```
call mysql.rds_set_external_source_with_auto_position(
'Externaldb.some.com',
3306,
'repl_user'@'mydomain.com',
'SomePassW0rd');
```
## mysql.rds\$1set\$1master\$1auto\$1position (Aurora MySQL versão 2)
Define o modo de replicação de base nas posições do arquivo de log binário ou nos identificadores de transações globais (GTIDs).
### Sintaxe
```
CALL mysql.rds_set_master_auto_position (
auto_position_mode
);
```
### Parâmetros
*auto\$1position\$1mode*
Um valor que indica se será usada a replicação de posição do arquivo de log ou a replicação com base no GTID:
+ `0`: usar o método de replicação com base na posição do arquivo de log binário. O padrão é `0`.
+ `1`: usar o método de replicação com base no GTID.
### Observações de uso
O usuário principal deve executar o procedimento `mysql.rds_set_master_auto_position`.
Esse procedimento é compatível com o Aurora MySQL versão 2.
## mysql.rds\$1set\$1read\$1only (Aurora MySQL versão 3)
Ativa ou desativa globalmente o modo `read_only` da instância de banco de dados.
### Sintaxe
```
CALL mysql.rds_set_read_only(mode);
```
### Parâmetros
*modo*
Um valor que indica se o modo `read_only` está ativado ou desativado globalmente para a instância de banco de dados:
+ `0`: `OFF`. O padrão é `0`.
+ `1` – `ON`
### Observações de uso
O procedimento `mysql.rds_set_read_only` armazenado modifica somente o parâmetro `read_only`. O parâmetro `innodb_read_only` não pode ser alterado nas instâncias de banco de dados do leitor.
A alteração do parâmetro `read_only` não persiste na reinicialização. Para fazer alterações permanentes em `read_only`, é necessário usar o parâmetro `read_only` do cluster de banco de dados.
Esse procedimento é compatível com o Aurora MySQL versão 3.06 e posterior.
## mysql.rds\$1set\$1session\$1binlog\$1format (Aurora MySQL versão 2)
Define o formato de log binário para a sessão atual.
### Sintaxe
```
CALL mysql.rds_set_session_binlog_format(format);
```
### Parâmetros
*formato*
Um valor que indica o formato do log binário da sessão atual:
+ `STATEMENT`: a origem de replicação grava eventos no log binário com base em declarações SQL.
+ `ROW`: a origem de replicação grava eventos no log binário que indicam alterações em linhas individuais da tabela.
+ `MIXED`: o registro em log geralmente é baseado em declarações SQL, mas muda para linhas em determinadas condições. Para receber mais informações, consulte [Mixed Binary Logging Format](https://dev.mysql.com/doc/refman/8.0/en/binary-log-mixed.html) na documentação do MySQL.
### Observações de uso
Para um cluster de bancos de dados Aurora MySQL, você chama esse procedimento armazenado enquanto está conectado à instância primária.
Para usar esse procedimento armazenado, você deve ter o registro em log binário configurado para a sessão atual.
Quanto ao Aurora, esse procedimento é compatível com o Aurora MySQL versão 2.12 e em versões posteriores compatíveis com o MySQL 5.7.
## mysql.rds\$1set\$1source\$1auto\$1position (Aurora MySQL versão 3)
Define o modo de replicação de base nas posições do arquivo de log binário ou nos identificadores de transações globais (GTIDs).
### Sintaxe
```
CALL mysql.rds_set_source_auto_position (auto_position_mode);
```
### Parâmetros
*auto\$1position\$1mode*
Um valor que indica se será usada a replicação de posição do arquivo de log ou a replicação com base no GTID:
+ `0`: usar o método de replicação com base na posição do arquivo de log binário. O padrão é `0`.
+ `1`: usar o método de replicação com base no GTID.
### Observações de uso
Para um cluster de bancos de dados Aurora MySQL, você chama esse procedimento armazenado enquanto está conectado à instância primária.
O usuário administrativo precisa executar o procedimento `mysql.rds_set_source_auto_position`.
## mysql.rds\$1skip\$1repl\$1error
Ignora e exclui um erro de replicação em uma réplica de leitura de banco de dados MySQL.
### Sintaxe
```
CALL mysql.rds_skip_repl_error;
```
### Observações de uso
O usuário principal deve executar o procedimento `mysql.rds_skip_repl_error` em uma réplica de leitura. Para obter mais informações sobre esse procedimento, consulte [Ignorar o erro de replicação atual](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.MySQL.CommonDBATasks.html#Appendix.MySQL.CommonDBATasks.SkipError).
Para determinar se há erros, execute o comando `SHOW REPLICA STATUS\G` do MySQL. Se um erro de replicação não for crítico, execute `mysql.rds_skip_repl_error` para ignorá-lo. Se houver vários, `mysql.rds_skip_repl_error` exclui o primeiro erro, depois avisa que há outros ainda. Assim, você pode usar `SHOW REPLICA STATUS\G` para determinar o plano de ação correto para o próximo erro. Para obter informações sobre os valores retornados, consulte [Instrução SHOW REPLICA STATUS](https://dev.mysql.com/doc/refman/8.0/en/show-replica-status.html) na documentação do MySQL.
Para obter mais informações sobre como lidar com erros de replicação no Aurora MySQL, consulte [Diagnosticar e resolver uma falha de replicação de leitura do MySQL ](CHAP_Troubleshooting.md#CHAP_Troubleshooting.MySQL.RR).
#### Erro de replicação interrompida
Ao chamar o procedimento `mysql.rds_skip_repl_error`, você pode receber uma mensagem de erro informando que a réplica está inativa ou desativada.
Essa mensagem de erro aparece quando você executa o procedimento na instância primária em vez da réplica de leitura. Você deve executar esse procedimento na réplica de leitura para que o procedimento funcione.
Essa mensagem de erro também poderá aparecer se você executar o procedimento na réplica de leitura, mas a replicação não poderá ser reiniciada com êxito.
Se você precisar ignorar um grande número de erros, o atraso de replicação poderá aumentar além do período de retenção padrão para arquivos de log binário (binlog). Nesse caso, você poderá encontrar um erro fatal, com os arquivos binlog sendo limpos antes de sua reprodução na réplica de leitura. Essa remoção faz com que a replicação pare, e você não consegue chamar o comando `mysql.rds_skip_repl_error` para ignorar erros de replicação.
É possível mitigar esse problema aumentando o número de horas em que os arquivos binlog são retidos na instância de banco de dados de origem. Após aumentar o período de retenção de log binário, você pode reiniciar a replicação e chamar o comando `mysql.rds_skip_repl_error` conforme necessário.
Para definir o período de retenção do binlog, use o procedimento [mysql.rds\$1set\$1configuration](mysql-stored-proc-configuring.md#mysql_rds_set_configuration) e especifique um parâmetro de configuração `'binlog retention hours'`, juntamente com o número de horas de retenção dos arquivos binlog no cluster do banco de dados. O exemplo a seguir define o período de retenção para arquivos de log binário em 48 horas.
```
CALL mysql.rds_set_configuration('binlog retention hours', 48);
```
## mysql.rds\$1start\$1replication
Inicia a replicação de um cluster de banco de dados do Aurora MySQL.
**nota**
Você pode usar o procedimento armazenado [mysql.rds\$1start\$1replication\$1until(Aurora MySQL versão 3)](#mysql_rds_start_replication_until) ou [mysql.rds\$1start\$1replication\$1until\$1gtid(Aurora MySQL versão 3)](mysql-stored-proc-gtid.md#mysql_rds_start_replication_until_gtid) para iniciar a replicação de uma instância de banco de dados do Aurora MySQL e interromper a replicação no local do arquivo de log binário especificado.
### Sintaxe
```
CALL mysql.rds_start_replication;
```
### Observações de uso
O usuário principal deve executar o procedimento `mysql.rds_start_replication`.
Para importar dados de uma instância do MySQL fora do Amazon RDS, chame `mysql.rds_start_replication` na réplica de leitura para iniciar o processo de replicação depois de ter chamado [mysql.rds\$1set\$1external\$1master (Aurora MySQL versão 2)](#mysql_rds_set_external_master) ou [mysql.rds\$1set\$1external\$1source (Aurora MySQL versão 3)](#mysql_rds_set_external_source) para criar a configuração de replicação. Para obter mais informações, consulte [Replicação entre Aurora e o MySQL ou entre Aurora e outro cluster de banco de dados do Aurora (replicação de log binário)](AuroraMySQL.Replication.MySQL.md).
Para exportar dados para uma instância do MySQL fora do Amazon RDS, chame `mysql.rds_start_replication` e `mysql.rds_stop_replication` na réplica de leitura para controlar algumas ações de replicação, como a remoção de logs binários. Para obter mais informações, consulte [Replicação entre Aurora e o MySQL ou entre Aurora e outro cluster de banco de dados do Aurora (replicação de log binário)](AuroraMySQL.Replication.MySQL.md).
Também é possível chamar `mysql.rds_start_replication` na réplica de leitura para reiniciar qualquer processo de replicação que tenha sido interrompido anteriormente chamando `mysql.rds_stop_replication`. Para obter mais informações, consulte [Erro de replicação interrompida](CHAP_Troubleshooting.md#CHAP_Troubleshooting.MySQL.ReplicationStopped).
## mysql.rds\$1start\$1replication\$1until(Aurora MySQL versão 3)
Inicia a replicação de um cluster de banco de dados do Aurora MySQL e interrompe a replicação no local do arquivo de log binário especificado.
### Sintaxe
```
CALL mysql.rds_start_replication_until (
replication_log_file
, replication_stop_point
);
```
### Parâmetros
*replication\$1log\$1file*
O nome do log binário na instância de banco de dados de origem que contém as informações de replicação.
*replication\$1stop\$1point *
O local no log binário `replication_log_file` no qual a replicação será interrompida.
### Observações de uso
O usuário mestre deve executar o procedimento `mysql.rds_start_replication_until`.
Esse procedimento é compatível com o Aurora MySQL versão 3.04 e posterior.
O procedimento armazenado `mysql.rds_start_replication_until` não é compatível com a replicação gerenciada, o que inclui o seguinte:
+ [Replicar clusters de banco de dados do Amazon Aurora MySQL entre Regiões da AWS](AuroraMySQL.Replication.CrossRegion.md)
+ [Migrar de uma instância de banco de dados do RDS para MySQL para um cluster de banco de dados do Amazon Aurora MySQL usando uma réplica de leitura do Aurora](AuroraMySQL.Migrating.RDSMySQL.Replica.md)
O nome do arquivo especificado para o parâmetro `replication_log_file` deve corresponder ao nome do arquivo do log binário da instância de banco de dados de origem.
Quando o parâmetro `replication_stop_point` especifica um local de parada no passado, a replicação é interrompida imediatamente.
### Exemplos
O exemplo a seguir inicia a replicação e replica as alterações até que ela atinja o local `120` no arquivo de log binário `mysql-bin-changelog.000777`.
```
call mysql.rds_start_replication_until(
'mysql-bin-changelog.000777',
120);
```
## mysql.rds\$1stop\$1replication
Interrompe a replicação de uma instância de banco de dados MySQL.
### Sintaxe
```
CALL mysql.rds_stop_replication;
```
### Observações de uso
O usuário mestre deve executar o procedimento `mysql.rds_stop_replication`.
Se você estiver configurando a replicação para importar dados de uma instância do MySQL em execução externamente ao Amazon RDS, chame `mysql.rds_stop_replication` na réplica de leitura para encerrar o processo de replicação após a importação ter sido concluída. Para obter mais informações, consulte [Replicação entre Aurora e o MySQL ou entre Aurora e outro cluster de banco de dados do Aurora (replicação de log binário)](AuroraMySQL.Replication.MySQL.md).
Se estiver configurando a replicação para exportar dados para uma instância do MySQL externa ao Amazon RDS, chame `mysql.rds_start_replication` e `mysql.rds_stop_replication` na réplica de leitura para controlar algumas ações de replicação, como a remoção de logs binários. Para obter mais informações, consulte [Replicação entre Aurora e o MySQL ou entre Aurora e outro cluster de banco de dados do Aurora (replicação de log binário)](AuroraMySQL.Replication.MySQL.md).
O procedimento armazenado `mysql.rds_stop_replication` não é compatível com a replicação gerenciada, o que inclui o seguinte:
+ [Replicar clusters de banco de dados do Amazon Aurora MySQL entre Regiões da AWS](AuroraMySQL.Replication.CrossRegion.md)
+ [Migrar de uma instância de banco de dados do RDS para MySQL para um cluster de banco de dados do Amazon Aurora MySQL usando uma réplica de leitura do Aurora](AuroraMySQL.Migrating.RDSMySQL.Replica.md)
# Encerrar uma sessão ou consulta
Os procedimentos armazenados a seguir encerram uma sessão ou consulta.
**Topics**
+ [mysql.rds\$1kill](#mysql_rds_kill)
+ [mysql.rds\$1kill\$1query](#mysql_rds_kill_query)
## mysql.rds\$1kill
Encerra uma conexão ao servidor MySQL.
### Sintaxe
```
CALL mysql.rds_kill(processID);
```
### Parâmetros
*processID*
A identidade do thread de conexão a ser encerrada.
### Observações de uso
Cada conexão ao servidor do MySQL é executada em um thread separado. Para encerrar uma conexão, use o procedimento `mysql.rds_kill` e passe o ID de thread dessa conexão. Para obter o ID de thread, use o comando [SHOW PROCESSLIST](https://dev.mysql.com/doc/refman/8.0/en/show-processlist.html) do MySQL.
### Exemplos
O exemplo a seguir encerra uma conexão com um ID de thread de 4243:
```
CALL mysql.rds_kill(4243);
```
## mysql.rds\$1kill\$1query
Encerra uma consulta em execução no servidor MySQL.
### Sintaxe
```
CALL mysql.rds_kill_query(processID);
```
### Parâmetros
*processID*
A identidade do processo ou thread que está executando a consulta a ser encerrada.
### Observações de uso
Para encerrar uma consulta em execução no servidor MySQL, use o procedimento `mysql_rds_kill_query` e passe o ID do thread que está executando a consulta. O procedimento então encerra a conexão.
Para obter o ID, consulte a [tabela INFORMATION\$1SCHEMA PROCESSLIST](https://dev.mysql.com/doc/refman/8.0/en/information-schema-processlist-table.html) do MySQL ou use o comando [SHOW PROCESSLIST](https://dev.mysql.com/doc/refman/8.0/en/show-processlist.html) do MySQL. O valor na coluna ID de `SHOW PROCESSLIST` ou `SELECT * FROM INFORMATION_SCHEMA.PROCESSLIST` é *processID*.
### Exemplos
O seguinte exemplo encerra uma consulta com um ID de thread de consulta 230040:
```
CALL mysql.rds_kill_query(230040);
```
# Replicar transações com GTIDs
Os procedimentos armazenados a seguir controlam como as transações são replicadas usando identificadores de transações globais (GTIDs) com o Aurora MySQL. Para saber como usar a replicação com base em GTIDs com o Aurora MySQL, consulte [Usar a replicação baseada em GTID](mysql-replication-gtid.md).
**Topics**
+ [mysql.rds\$1assign\$1gtids\$1to\$1anonymous\$1transactions (Aurora MySQL versão 3)](#mysql_assign_gtids_to_anonymous_transactions)
+ [mysql.rds\$1gtid\$1purged (Aurora MySQL versão 3)](#mysql_rds_gtid_purged)
+ [mysql.rds\$1skip\$1transaction\$1with\$1gtid(Aurora MySQL versões 2 e 3)](#mysql_rds_skip_transaction_with_gtid)
+ [mysql.rds\$1start\$1replication\$1until\$1gtid(Aurora MySQL versão 3)](#mysql_rds_start_replication_until_gtid)
## mysql.rds\$1assign\$1gtids\$1to\$1anonymous\$1transactions (Aurora MySQL versão 3)
Configura a opção `ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS` da instrução `CHANGE REPLICATION SOURCE TO`. Faz com que o canal de replicação atribua um GTID a transações replicadas que não têm um. Assim, é possível realizar a replicação de logs binários de uma origem que não utiliza replicação baseada em GTID para uma réplica que a utiliza. Para obter mais informações, consulte a [Instrução CHANGE REPLICATION SOURCE TO](https://dev.mysql.com/doc/refman/8.0/en/change-replication-source-to.html) e o tópico sobre [Replicação de uma origem sem GTIDs para uma réplica com GTIDs](https://dev.mysql.com/doc/refman/8.0/en/replication-gtids-assign-anon.html), no *Guia de referência do MySQL*.
### Sintaxe
```
CALL mysql.rds_assign_gtids_to_anonymous_transactions(gtid_option);
```
### Parâmetros
*gtid\$1option*
Valor da string. Os valores permitidos são `OFF`, `LOCAL` ou um UUID especificado.
### Observações de uso
Esse procedimento tem o mesmo efeito que a emissão da instrução `CHANGE REPLICATION SOURCE TO ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS = gtid_option` na comunidade do MySQL.
O GTID deve se transformar `ON` para que *gtid\$1option* seja definido como `LOCAL` ou um UUID específico.
O padrão é `OFF`, o que significa que o recurso não é utilizado.
`LOCAL` atribui um GTID que inclui o próprio UUID da réplica (a configuração `server_uuid`).
Transmitir um parâmetro que é um UUID atribui um GTID que inclui o UUID especificado, como a configuração `server_uuid` do servidor de origem de replicação.
### Exemplos
Para desabilitar esse recurso:
```
mysql> call mysql.rds_assign_gtids_to_anonymous_transactions('OFF');
+-------------------------------------------------------------+
| Message |
+-------------------------------------------------------------+
| ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS has been set to: OFF |
+-------------------------------------------------------------+
1 row in set (0.07 sec)
```
Para utilizar o próprio UUID da réplica:
```
mysql> call mysql.rds_assign_gtids_to_anonymous_transactions('LOCAL');
+---------------------------------------------------------------+
| Message |
+---------------------------------------------------------------+
| ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS has been set to: LOCAL |
+---------------------------------------------------------------+
1 row in set (0.07 sec)
```
Para utilizar um UUID especificado:
```
mysql> call mysql.rds_assign_gtids_to_anonymous_transactions('317a4760-f3dd-3b74-8e45-0615ed29de0e');
+----------------------------------------------------------------------------------------------+
| Message |
+----------------------------------------------------------------------------------------------+
| ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS has been set to: 317a4760-f3dd-3b74-8e45-0615ed29de0e |
+----------------------------------------------------------------------------------------------+
1 row in set (0.07 sec)
```
## mysql.rds\$1gtid\$1purged (Aurora MySQL versão 3)
Define o valor global da variável de sistema `gtid_purged` como determinado conjunto de identificadores de transação global (GTID). A variável de sistema `gtid_purged` é um conjunto de GTID que consiste nos GTIDs de todas as transações que foram confirmadas no servidor mas não existem em nenhum arquivo de log binário no servidor.
Para permitir a compatibilidade com o MySQL 8.0, há duas maneiras de definir o valor de `gtid_purged`:
+ Substituir o valor de `gtid_purged` por seu conjunto de GTIDs especificado.
+ Anexar seu conjunto de GTIDs especificado ao conjunto de GTIDs que `gtid_purged` já contém.
### Sintaxe
Como substituir o valor de `gtid_purged` por seu conjunto de GTIDs especificado:
```
CALL mysql.rds_gtid_purged (gtid_set);
```
Como anexar o valor de `gtid_purged` ao seu conjunto de GTIDs especificado:
```
CALL mysql.rds_gtid_purged (+gtid_set);
```
### Parâmetros
*gtid\$1set*
O valor de *gtid\$1set* deve ser um superconjunto do valor atual de `gtid_purged` e não pode fazer uma intersecção com `gtid_subtract(gtid_executed,gtid_purged)`. Ou seja, o novo conjunto de GTIDs deve incluir todos os GTIDs que já estavam em `gtid_purged` e não pode incluir nenhum GTID em `gtid_executed` que ainda não tenha sido eliminado. O parâmetro *gtid\$1set* também não pode incluir nenhum GTID que esteja no conjunto `gtid_owned` global, os GTIDs para transações que estão sendo processadas no momento no servidor.
### Observações de uso
O usuário principal deve executar o procedimento `mysql.rds_gtid_purged`.
Esse procedimento é compatível com o Aurora MySQL versão 3.04 e posterior.
### Exemplos
O exemplo a seguir atribui o GTID `3E11FA47-71CA-11E1-9E33-C80AA9429562:23` à variável `gtid_purged` global.
```
CALL mysql.rds_gtid_purged('3E11FA47-71CA-11E1-9E33-C80AA9429562:23');
```
## mysql.rds\$1skip\$1transaction\$1with\$1gtid(Aurora MySQL versões 2 e 3)
Ignora a replicação de uma transação com o identificador de transação global (GTID) especificado em uma instância primária do Aurora.
Você pode usar esse procedimento para a recuperação de desastres, quando uma transação baseada em GTID específica for conhecida por causar desastres. Use esse procedimento armazenado para ignorar a transação problemática. Exemplos de transações problemáticas incluem transações que desabilitam a replicação, excluem dados importantes ou fazem com que a instância de banco de dados se torne indisponível.
### Sintaxe
```
CALL mysql.rds_skip_transaction_with_gtid (
gtid_to_skip
);
```
### Parâmetros
*gtid\$1to\$1skip*
O GTID da transação de replicação a ser ignorada.
### Observações de uso
O usuário principal deve executar o procedimento `mysql.rds_skip_transaction_with_gtid`.
Esse procedimento é compatível com o Aurora MySQL versões 2 e 3.
### Exemplos
O exemplo a seguir ignora a replicação da transação com o GTID `3E11FA47-71CA-11E1-9E33-C80AA9429562:23`.
```
CALL mysql.rds_skip_transaction_with_gtid('3E11FA47-71CA-11E1-9E33-C80AA9429562:23');
```
## mysql.rds\$1start\$1replication\$1until\$1gtid(Aurora MySQL versão 3)
Inicia a replicação de um cluster de banco de dados do Aurora MySQL e interrompe a replicação logo depois do identificador de transação global (GTID) especificado.
### Sintaxe
```
CALL mysql.rds_start_replication_until_gtid(gtid);
```
### Parâmetros
*gtid*
O GTID após o qual a replicação será interrompida.
### Observações de uso
O usuário principal deve executar o procedimento `mysql.rds_start_replication_until_gtid`.
Esse procedimento é compatível com o Aurora MySQL versão 3.04 e posterior.
O procedimento armazenado `mysql.rds_start_replication_until_gtid` não é compatível com a replicação gerenciada, o que inclui o seguinte:
+ [Replicar clusters de banco de dados do Amazon Aurora MySQL entre Regiões da AWS](AuroraMySQL.Replication.CrossRegion.md)
+ [Migrar de uma instância de banco de dados do RDS para MySQL para um cluster de banco de dados do Amazon Aurora MySQL usando uma réplica de leitura do Aurora](AuroraMySQL.Migrating.RDSMySQL.Replica.md)
Quando o parâmetro `gtid` especifica uma transação que já tenha sido executada pela réplica, a replicação é interrompida imediatamente.
### Exemplos
O exemplo a seguir inicia a replicação e replica as alterações até atingir o GTID `3E11FA47-71CA-11E1-9E33-C80AA9429562:23`.
```
call mysql.rds_start_replication_until_gtid('3E11FA47-71CA-11E1-9E33-C80AA9429562:23');
```
# Alternar os logs de consulta
Os procedimentos armazenados a seguir fazem a rotação dos logs do MySQL para tabelas de backup. Para ter mais informações, consulte [Arquivos de log do banco de dados AuroraMySQL](USER_LogAccess.Concepts.MySQL.md).
**Topics**
+ [mysql.rds\$1rotate\$1general\$1log](#mysql_rds_rotate_general_log)
+ [mysql.rds\$1rotate\$1slow\$1log](#mysql_rds_rotate_slow_log)
## mysql.rds\$1rotate\$1general\$1log
Reveza a tabela `mysql.general_log` com uma tabela de backup.
### Sintaxe
```
CALL mysql.rds_rotate_general_log;
```
### Observações de uso
Você pode revezar a tabela `mysql.general_log` com uma tabela de backup, chamando o procedimento `mysql.rds_rotate_general_log`. Quando as tabelas de log são revezadas, a tabela de log atual é copiada para uma tabela de log de backup e as entradas na tabela de log atual são removidas. Se uma 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`.
É possível executar esse procedimento somente quando o parâmetro `log_output` está definido como `TABLE`.
## mysql.rds\$1rotate\$1slow\$1log
Reveza a tabela `mysql.slow_log` com uma tabela de backup.
### Sintaxe
```
CALL mysql.rds_rotate_slow_log;
```
### Observações de uso
Você pode revezar a tabela `mysql.slow_log` com uma tabela de backup, chamando o procedimento `mysql.rds_rotate_slow_log`. Quando as tabelas de log são revezadas, a tabela de log atual é copiada para uma tabela de log de backup e as entradas na tabela de log atual são removidas. Se uma 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.slow_log` é denominada `mysql.slow_log_backup`.
# Definir e mostrar a configuração de logs binários
Os procedimentos armazenados a seguir definem e mostram parâmetros de configuração, como para retenção de arquivos de log binários.
**Topics**
+ [mysql.rds\$1set\$1configuration](#mysql_rds_set_configuration)
+ [mysql.rds\$1show\$1configuration](#mysql_rds_show_configuration)
## mysql.rds\$1set\$1configuration
Especifica o número de horas para retenção de logs binários ou o número de segundos para atrasar a replicação.
### Sintaxe
```
CALL mysql.rds_set_configuration(name,value);
```
### Parâmetros
*name*
(Opcional) O nome do parâmetro de configuração a definir.
*value*
O valor do parâmetro de configuração.
### Observações de uso
O procedimento `mysql.rds_set_configuration` oferece suporte aos seguintes parâmetros de configuração:
+ [horas de retenção do log binário](#mysql_rds_set_configuration-usage-notes.binlog-retention-hours)
Os parâmetros de configuração são armazenados permanentemente e sobrevivem a qualquer reinicialização ou failover da instância de banco de dados.
#### horas de retenção do log binário
O parâmetro `binlog retention hours` é usado para especificar o número de horas para reter arquivos de log binários. O Amazon Aurora normalmente elimina um log binário o mais rápido possível, mas o log binário ainda pode ser necessário para a replicação com um banco de dados MySQL externo ao Aurora.
O valor padrão de `binlog retention hours` é `NULL`. No Aurora MySQL, `NULL` significa que os logs binários são limpos lentamente. Os registros binários do Aurora MySQL podem permanecer no sistema por determinado período, que geralmente não passa de um dia.
Para especificar o número de horas para reter os logs binários em um cluster de banco de dados, use o procedimento armazenado `mysql.rds_set_configuration` e especifique um período com tempo suficiente para que a replicação ocorra, conforme exibido no exemplo a seguir.
`call mysql.rds_set_configuration('binlog retention hours', 24);`
**nota**
Não é possível usar o valor `0` para `binlog retention hours`.
Para clusters de banco de dados do Aurora MySQL versão 2.11.0 e posterior e clusters de banco de dados versão 3, o valor máximo de `binlog retention hours` é 2.160 (90 dias).
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.
## mysql.rds\$1show\$1configuration
A quantidade de horas em que os logs binários são mantidos.
### Sintaxe
```
CALL mysql.rds_show_configuration;
```
### Observações de uso
Para verificar o número de horas durante as quais o Amazon RDS vai reter os logs binários, use o procedimento armazenado `mysql.rds_show_configuration`.
### Exemplos
O exemplo a seguir mostra exibe o período de retenção:
```
call mysql.rds_show_configuration;
name value description
binlog retention hours 24 binlog retention hours specifies the duration in hours before binary logs are automatically deleted.
```
# Tabelas information\$1schema específicas do Aurora MySQL
O Aurora MySQL tem determinadas tabelas `information_schema` que são específicas do Aurora.
## information\$1schema.aurora\$1global\$1db\$1instance\$1status
A tabela `information_schema.aurora_global_db_instance_status` contém informações sobre o status de todas as instâncias de banco de dados nos clusters de banco de dados primários e secundários de um banco de dados global. A tabela a seguir mostra as colunas que você pode usar. As colunas restantes são somente para uso interno do Aurora.
**nota**
As tabelas de esquema de informações só está disponível com bancos de dados globais do Aurora MySQL versão 3.04.0 e posterior.
| Coluna | Tipo de dados | Descrição |
| --- | --- | --- |
| SERVER\$1ID | varchar(100) | O identificador da instância de banco de dados. |
| SESSION\$1ID | varchar(100) | Um identificador exclusivo da sessão atual. O valor de MASTER\$1SESSION\$1ID identifica a instância de banco de dados do leitor (primário). |
| AWS\$1REGION | varchar(100) | A Região da AWS onde essa instância de banco de dados global é executada. Para obter uma lista de regiões, consulte [Disponibilidade de regiões](Concepts.RegionsAndAvailabilityZones.md#Aurora.Overview.Availability). |
| DURABLE\$1LSN | bigint não assinado | O número de sequência de logs (LSN) que se tornou durável no armazenamento. Um número de sequência de log (LSN) é um número sequencial exclusivo que identifica um registo no log de transações do banco de dados. LSNs são ordenados de forma que um LSN maior represente uma transação posterior. |
| HIGHEST\$1LSN\$1RCVD | bigint não assinado | O LSN mais alto recebido pela instância de banco de dados da instância de banco de dados do gravador. |
| OLDEST\$1READ\$1VIEW\$1TRX\$1ID | bigint não assinado | O ID da transação mais antiga que a instância de banco de dados do gravador pode limpar. |
| OLDEST\$1READ\$1VIEW\$1LSN | bigint não assinado | O LSN mais antigo usado pela instância de banco de dados para fazer a leitura no armazenamento. |
| VISIBILITY\$1LAG\$1IN\$1MSEC | float(10,0) não assinado | Para leitores no cluster de banco de dados primário, até que ponto essa instância de banco de dados está atrasada em relação à instância de banco de dados de gravador em milissegundos. Para leitores em um cluster de banco de dados secundário, até que ponto essa instância de banco de dados está atrasada em relação ao volume secundário em milissegundos. |
## information\$1schema.aurora\$1global\$1db\$1status
A tabela `information_schema.aurora_global_db_status` contém informações sobre diversos aspectos do atraso do banco de dados global do Aurora, especificamente o atraso do armazenamento do Aurora subjacente (o chamado atraso de durabilidade) e o atraso entre o objetivo de ponto de recuperação (RPO). A tabela a seguir mostra as colunas que você pode usar. As colunas restantes são somente para uso interno do Aurora.
**nota**
As tabelas de esquema de informações só está disponível com bancos de dados globais do Aurora MySQL versão 3.04.0 e posterior.
| Coluna | Tipo de dados | Descrição |
| --- | --- | --- |
| AWS\$1REGION | varchar(100) | A Região da AWS onde essa instância de banco de dados global é executada. Para obter uma lista de regiões, consulte [Disponibilidade de regiões](Concepts.RegionsAndAvailabilityZones.md#Aurora.Overview.Availability). |
| HIGHEST\$1LSN\$1WRITTEN | bigint não assinado | O número de sequência de logs (LSN) mais alto nesse cluster de banco de dados no momento. Um número de sequência de log (LSN) é um número sequencial exclusivo que identifica um registo no log de transações do banco de dados. LSNs são ordenados de forma que um LSN maior represente uma transação posterior. |
| DURABILITY\$1LAG\$1IN\$1MILLISECONDS | float(10,0) não assinado | A diferença nos valores de carimbo de data/hora entre o HIGHEST\$1LSN\$1WRITTEN em um cluster de banco de dados secundário e o HIGHEST\$1LSN\$1WRITTEN no cluster de banco de dados primário. Esse valor é sempre 0 no cluster de banco de dados primário do banco de dados global do Aurora. |
| RPO\$1LAG\$1IN\$1MILLISECONDS | float(10,0) não assinado | O atraso do objetivo de ponto de recuperação (RPO). O atraso do RPO é o tempo necessário para que a transação COMMIT mais recente do usuário seja armazenada em um cluster de banco de dados secundário após ser armazenada no cluster de banco de dados primário de um banco de dados Aurora global. Esse valor é sempre 0 no cluster de banco de dados primário do banco de dados global do Aurora. Em termos simples, essa métrica calcula o objetivo do ponto de recuperação de cada cluster de banco de dados do Aurora MySQL no banco de dados global do Aurora, ou seja, quantos dados poderão ser perdidos se houver uma interrupção. Tal como o atraso, o RPO é medido em tempo. |
| LAST\$1LAG\$1CALCULATION\$1TIMESTAMP | datetime | O carimbo de data/hora que especifica quando os valores foram calculados pela última vez para DURABILITY\$1LAG\$1IN\$1MILLISECONDS e RPO\$1LAG\$1IN\$1MILLISECONDS. Um valor de tempo como 1970-01-01 00:00:00\$100 indica que este é o cluster de banco de dados primário. |
| OLDEST\$1READ\$1VIEW\$1TRX\$1ID | bigint não assinado | O ID da transação mais antiga que a instância de banco de dados do gravador pode limpar. |
## information\$1schema.replica\$1host\$1status
A tabela `information_schema.replica_host_status` contém informações de replicação. As colunas que você pode usar são mostradas na tabela a seguir. As colunas restantes são somente para uso interno do Aurora.
| Coluna | Tipo de dados | Descrição |
| --- | --- | --- |
| CPU | double | A porcentagem de uso da CPU do host de réplica. |
| IS\$1CURRENT | tinyint | Se a réplica é atual. |
| LAST\$1UPDATE\$1TIMESTAMP | datetime(6) | Hora em que a última atualização ocorreu. Utilizado para determinar se um registro está obsoleto. |
| REPLICA\$1LAG\$1IN\$1MILLISECONDS | double | O atraso da réplica em milissegundos. |
| SERVER\$1ID | varchar(100) | O ID do servidor de banco de dados. |
| SESSION\$1ID | varchar(100) | O ID da sessão do banco de dados. Utilizado para determinar se uma instância de banco de dados é uma instância do gravador ou do leitor. |
**nota**
Quando uma instância de réplica fica para trás, as informações consultadas em sua tabela `information_schema.replica_host_status` podem estar desatualizadas. Nessa situação, recomendamos que você consulte a instância do gravador em vez disso.
Embora a tabela `mysql.ro_replica_status` tenha informações semelhantes, não recomendamos que você a use.
## information\$1schema.aurora\$1forwarding\$1processlist
A tabela `information_schema.aurora_forwarding_processlist` contém informações sobre os processos envolvidos no encaminhamento de gravação.
O conteúdo dessa tabela é visível somente na instância de banco de dados do gravador de um cluster de banco de dados com o encaminhamento de gravação global ou no cluster ativado. Um conjunto de resultados vazio é retornado nas instâncias de banco de dados do leitor.
| Campo | Tipo de dados | Descrição |
| --- | --- | --- |
| ID | bigint | O identificador da conexão na instância de banco de dados do gravador. Esse identificador é o mesmo valor exibido na coluna Id da declaração SHOW PROCESSLIST e devolvida pela função CONNECTION\$1ID() dentro do segmento. |
| USER | varchar(32) | O usuário do MySQL que emitiu a declaração. |
| HOST | varchar(255) | O cliente do MySQL que emitiu a declaração. Para declarações encaminhadas, esse campo mostra o endereço do host do cliente da aplicação que estabeleceu a conexão na instância de banco de dados do leitor de encaminhamento. |
| Banco de dados | varchar(64) | O banco de dados padrão para o segmento. |
| COMMAND | varchar(16) | O tipo de comando que o segmento está executando em nome do cliente ou Sleep se a sessão estiver inativa. Para conhecer as descrições dos comandos de segmento, consulte [Thread Command Values](https://dev.mysql.com/doc/refman/8.0/en/thread-commands.html) na documentação do MySQL. |
| TIME | int | O tempo em segundos que o segmento esteve no estado atual. |
| STATE | varchar(64) | Uma ação, um evento ou um estado que indica o que o segmento está fazendo. Para conhecer as descrições dos valores de estado, consulte [General Thread States](https://dev.mysql.com/doc/refman/8.0/en/general-thread-states.html) na documentação do MySQL. |
| INFO | longtext | A declaração que o segmento está executando ou NULL se não estiver executando uma declaração. A declaração pode ser a enviada ao servidor ou uma declaração mais interna se a declaração executar outras declarações. |
| IS\$1FORWARDED | bigint | Indica se o segmento foi encaminhado de uma instância de banco de dados do leitor. |
| REPLICA\$1SESSION\$1ID | bigint | O identificador de conexão na réplica do Aurora. Esse identificador é o mesmo valor exibido na coluna Id da declaração SHOW PROCESSLIST na instância de banco de dados do leitor de encaminhamento do Aurora. |
| REPLICA\$1INSTANCE\$1IDENTIFIER | varchar(64) | O identificador da instância de banco de dados do segmento de encaminhamento. |
| REPLICA\$1CLUSTER\$1NAME | varchar(64) | O identificador do cluster de banco de dados do segmento de encaminhamento. Para encaminhamento de gravação no cluster, esse identificador é o mesmo cluster de banco de dados da instância de banco de dados do gravador. |
| REPLICA\$1REGION | varchar(64) | A Região da AWS da qual o segmento de encaminhamento se origina. Para encaminhamento de gravação no cluster, essa região é a mesma Região da AWS da instância de banco de dados do gravador. |