# Aurora MySQL versão 3 compatível com o MySQL 8.0 É possível utilizar o Aurora MySQL versão 3 para obter os recursos mais recentes compatíveis com MySQL, aprimoramentos de performance e correções de bugs. A seguir, você pode saber mais sobre o Aurora MySQL versão 3 com compatibilidade com o MySQL 8.0. Você pode aprender a atualizar clusters e aplicações para o Aurora MySQL versão 3. Alguns recursos do Aurora, como o Aurora Serverless v2, requer o Aurora MySQL versão 3. **Topics** + [Recursos do MySQL 8.0 Community Edition](#AuroraMySQL.8.0-features-community) + [Pré-requisito do Aurora MySQL versão 3 para o Aurora MySQL Serverless v2](#AuroraMySQL.serverless-v2-8.0-prereq) + [Notas de release do Aurora MySQL versão 3](#AuroraMySQL.mysql80-bugs-fixed) + [Novas otimizações de consultas paralelas](#AuroraMySQL.8.0-features-pq) + [Otimizações para reduzir o tempo de reinicialização do banco de dados](#ReducedRestartTime) + [Novo comportamento de tabela temporária no Aurora MySQL versão 3](ams3-temptable-behavior.md) + [Comparar o Aurora MySQL versão 2 e o Aurora MySQL versão 3](AuroraMySQL.Compare-v2-v3.md) + [Comparar o Aurora MySQL versão 3 e o MySQL 8.0 Community Edition](AuroraMySQL.Compare-80-v3.md) + [Fazer upgrade para o Aurora MySQL versão 3](AuroraMySQL.mysql80-upgrade-procedure.md) ## Recursos do MySQL 8.0 Community Edition A versão inicial do Aurora MySQL versão 3 é compatível com o MySQL 8.0.23 Community Edition. O MySQL 8.0 apresenta vários novos recursos, incluindo os seguintes: + Compatibilidade com a linguagem de definição de dados (DDL) atômica. Para ter mais informações, consulte [Compatibilidade com a Linguagem de definição de dados (DDL) atômica](AuroraMySQL.Compare-v2-v3.md#AuroraMySQL.Compare-v2-v3-atomic-ddl). + Funções JSON. Para obter mais informações, consulte o tópico sobre [Funções JSON](https://dev.mysql.com/doc/refman/8.0/en/json-functions.html), no *Guia de referência do MySQL*. + Funções de janela. Para obter mais informações, consulte o tópico sobre [Funções de janela](https://dev.mysql.com/doc/refman/8.0/en/window-functions.html), no *Guia de referência do MySQL*. + Expressões de tabela comuns (CTEs), utilizando a cláusula `WITH`. Para obter mais informações, consulte [WITH (Expressões de tabela comuns)](https://dev.mysql.com/doc/refman/8.0/en/with.html) no *Guia de referência do MySQL*. + Otimização de cláusulas `ADD COLUMN` e `RENAME COLUMN` para a instrução `ALTER TABLE`. Essas otimizações são chamadas de “DDL instantânea”. O Aurora MySQL versão 3 tem compatibilidade com o recurso de DDL instantânea do MySQL edição da comunidade. O antigo recurso de DDL rápida do Aurora não é utilizado. Para obter informações sobre uso da DDL instantânea, consulte [DDL instantânea (Aurora MySQL versão 3)](AuroraMySQL.Managing.FastDDL.md#AuroraMySQL.mysql80-instant-ddl). + Índices descendentes, funcionais e invisíveis. Para obter mais informações, consulte os tópicos sobre [Índices invisíveis](https://dev.mysql.com/doc/refman/8.0/en/invisible-indexes.html), [Índices decrescentes](https://dev.mysql.com/doc/refman/8.0/en/descending-indexes.html) e a [Instrução CREATE INDEX](https://dev.mysql.com/doc/refman/8.0/en/create-index.html#create-index-functional-key-parts), no *Guia de referência do MySQL*. + Privilégios baseados em função controlados por instruções SQL. Para obter mais informações sobre as alterações feitas no modelo de privilégios, consulte [Modelo de privilégios baseados em funções](AuroraMySQL.Compare-80-v3.md#AuroraMySQL.privilege-model). + Cláusulas `NOWAIT` e `SKIP LOCKED` com a instrução `SELECT ... FOR SHARE`. Essas cláusulas evitam esperar que outras transações liberem bloqueios de linhas. Para obter mais informações, consulte o tópico sobre [Leituras de bloqueio](https://dev.mysql.com/doc/refman/8.0/en/innodb-locking-reads.html), no *Guia de referência do MySQL*. + Melhorias na replicação de log binário (binlog). Para obter detalhes referentes ao Aurora MySQL, consulte [Replicação de log binário](AuroraMySQL.Compare-v2-v3.md#AuroraMySQL.mysql80-binlog). Em particular, é possível realizar uma replicação filtrada. Para obter informações de uso sobre a replicação filtrada, consulte o tópico sobre [Como servidores avaliam regras de filtragem de replicação](https://dev.mysql.com/doc/refman/8.0/en/replication-rules.html), no *Guia de referência do MySQL*. + Dicas. Algumas das dicas compatíveis com o MySQL 8.0 já foram transferidas ao Aurora MySQL versão 2. Para obter informações sobre como utilizar dicas com o Aurora MySQL, consulte [Dicas do Aurora MySQL](AuroraMySQL.Reference.Hints.md). Para acessar a lista completa de dicas no MySQL 8.0 edição da comunidade, consulte [Dicas do otimizador](https://dev.mysql.com/doc/refman/8.0/en/optimizer-hints.html), no *Guia de referência do MySQL*. Para acessar a lista completa de recursos adicionados ao MySQL 8.0 edição da comunidade, consulte a postagem do blog [Lista completa dos novos recursos no MySQL 8.0](https://dev.mysql.com/blog-archive/the-complete-list-of-new-features-in-mysql-8-0/). O Aurora MySQL versão 3 também inclui alterações em palavras-chave para linguagem inclusiva, transferidas do MySQL 8.0.26 edição da comunidade. Para conhecer os detalhes dessas alterações, consulte [Alterações de linguagem inclusiva do Aurora MySQL versão 3](AuroraMySQL.Compare-v2-v3.md#AuroraMySQL.8.0-inclusive-language). ## Pré-requisito do Aurora MySQL versão 3 para o Aurora MySQL Serverless v2 O Aurora MySQL versão 3 é um pré-requisito para todas as instâncias de banco de dados em um cluster do Aurora MySQL Serverless v2. O Aurora MySQL Serverless v2 inclui suporte para instâncias de leitor em um cluster de banco de dados e outros recursos do Aurora que não estão disponíveis para o Aurora MySQL Serverless v1. Ele também tem uma escalabilidade mais rápida e granular do que o Aurora MySQL Serverless v1. ## Notas de release do Aurora MySQL versão 3 Para acessar as notas de lançamento de todas as versões do Aurora MySQL versão 3, consulte [Atualizações no mecanismo de banco de dados do Amazon Aurora MySQL versão 3](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraMySQLReleaseNotes/AuroraMySQL.Updates.30Updates.html) em *Notas de lançamento do Aurora MySQL*. ## Novas otimizações de consultas paralelas A otimização de consultas paralelas do Aurora agora é aplicável a mais operações SQL: + A consulta paralela agora é aplicável a tabelas que contêm os tipos de dados `TEXT`,`BLOB`,`JSON`,`GEOMETRY`, `VARCHAR` e `CHAR` com mais de 768 bytes. + A consulta paralela é capaz de otimizar consultas envolvendo tabelas particionadas. + A consulta paralela é capaz de otimizar consultas envolvendo chamadas de função agregadas na lista de seleção e na cláusula `HAVING`. Para obter mais informações sobre esses aprimoramentos, 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). Para obter informações gerais sobre a consulta paralela do Aurora, consulte [Consulta paralela do Amazon Aurora MySQL](aurora-mysql-parallel-query.md). ## Otimizações para reduzir o tempo de reinicialização do banco de dados O cluster de banco de dados do Aurora MySQL deve estar altamente disponível durante interrupções planejadas e não planejadas. Os administradores de banco de dados precisam realizar manutenção ocasional do banco de dados. Essa manutenção inclui aplicação de patches no banco de dados, atualizações, modificações nos parâmetros do banco de dados que exigem uma reinicialização manual, execução de um failover para reduzir o tempo necessário para, por exemplo, mudanças de classe e assim por diante. Essas ações planejadas necessitam de tempo de inatividade. No entanto, o tempo de inatividade também pode ser causado por ações não planejadas, como um failover inesperado devido a uma falha de hardware subjacente ou à limitação de recursos do banco de dados. Todas essas ações planejadas e não planejadas resultam na reinicialização do banco de dados. No Aurora MySQL versão 3.05 e superior, introduzimos otimizações que reduzem o tempo de reinicialização do banco de dados. Essas otimizações fornecem até 65% menos tempo de inatividade do que sem otimizações e menos interrupções nas workloads do banco de dados após uma reinicialização. Durante a inicialização do banco de dados, muitos componentes da memória interna são inicializados. O maior deles é o [pool de buffer do InnoDB](https://aws.amazon.com/blogs/database/best-practices-for-amazon-aurora-mysql-database-configuration/), que no Aurora MySQL é 75% do tamanho da memória da instância por padrão. Nossos testes descobriram que o tempo de inicialização é proporcional ao tamanho do pool de buffer do InnoDB e, portanto, é escalável com o tamanho da classe da instância de banco de dados. Durante essa fase de inicialização, o banco de dados não pode aceitar conexões, o que causa maior tempo de inatividade durante as reinicializações. A primeira fase da reinicialização rápida do Aurora MySQL otimiza a inicialização do pool de buffer, o que reduz o tempo de inicialização do banco de dados e, consequentemente, o tempo geral de reinicialização. Para obter mais detalhes, consulte o blog [Reduzir o tempo de inatividade com as otimizações do tempo de reinicialização do banco de dados Amazon Aurora MySQL](https://aws.amazon.com/blogs/database/reduce-downtime-with-amazon-aurora-mysql-database-restart-time-optimizations/). # Novo comportamento de tabela temporária no Aurora MySQL versão 3 O Aurora MySQL versão 3 processa as tabelas temporárias internas de forma diferente das versões anteriores do Aurora MySQL. Esse novo comportamento é herdado do MySQL 8.0 Community Edition. Existem dois tipos de tabelas temporárias que podem ser criadas com o Aurora MySQL versão 3: + Tabelas temporárias internas (ou *implícitas*): criadas pelo mecanismo do Aurora MySQL para lidar com operações, como agregação de classificação, tabelas derivadas ou expressões de tabela comuns (CTEs). + Tabelas temporárias criadas pelo usuário (ou *explícitas*): criadas pelo mecanismo do Aurora MySQL quando você usa a instrução `CREATE TEMPORARY TABLE`. Há considerações adicionais sobre tabelas temporárias internas e criadas pelo usuário em instâncias de banco de dados do leitor do Aurora. Abordamos essas alterações nas seções a seguir. **Topics** + [Mecanismo de armazenamento para tabelas temporárias internas (implícitas)](#ams3-temptable-behavior-engine) + [Limitar o tamanho de tabelas temporárias internas na memória](#ams3-temptable-behavior-limit) + [Mitigar problemas de volume em tabelas temporárias internas em réplicas do Aurora](#ams3-temptable-behavior-mitigate) + [Otimizar o parâmetro temptable\$1max\$1mmap nas instâncias de banco de dados do Aurora MySQL](#ams-optimize-temptable_max_mmap) + [Tabelas temporárias criadas pelo usuário (explícitas) em instâncias de banco de dados de leitor](#ams3-temptable-behavior.user) + [Mitigação e erros de criação de tabelas temporárias](#ams3-temptable-behavior.errors) ## Mecanismo de armazenamento para tabelas temporárias internas (implícitas) Ao gerar conjuntos de resultados intermediários, o Aurora MySQL inicialmente tenta gravar em tabelas temporárias na memória. Esse procedimento pode não ser bem-sucedido devido a tipos de dados incompatíveis ou limites configurados. Se esse for o caso, a tabela temporária será convertida em uma tabela temporária no disco, em vez de mantida na memória. Mais informações sobre isso podem ser encontradas em [Uso de tabela temporária interna no MySQL](https://dev.mysql.com/doc/refman/8.0/en/internal-temporary-tables.html) na documentação do MySQL. No Aurora MySQL versão 3, a maneira como as tabelas temporárias internas funcionam é diferente das versões anteriores do Aurora MySQL. Em vez de escolher entre os mecanismos de armazenamento InnoDB e MyISAM para essas tabelas temporárias, agora você escolhe entre os mecanismos de armazenamento `TempTable` e `MEMORY`. Com o mecanismo de armazenamento `TempTable`, é possível fazer uma escolha adicional de como lidar com determinados dados. Os dados afetados transbordam o pool de memória que contém todas as tabelas temporárias internas da instância de banco de dados. Essas opções podem influenciar a performance de consultas que geram altos volumes de dados temporários, por exemplo, ao realizar agregações como `GROUP BY` em tabelas grandes. **dica** Se a sua workload incluir consultas que geram tabelas temporárias internas, confirme a performance da sua aplicação com essa alteração executando benchmarks e monitorando métricas de performance. Em alguns casos, a quantidade de dados temporários se encaixa no grupo de memória `TempTable` ou apenas transborda o grupo de memória em uma pequena quantidade. Nesses casos, convém utilizar a configuração `TempTable` para tabelas temporárias internas e arquivos mapeados para a memória a fim de conter quaisquer dados de estouro. Essa é a configuração padrão. O mecanismo de armazenamento `TempTable` é o padrão. `TempTable` usa um grupo de memória comum para todas as tabelas temporárias que usam esse mecanismo, em vez de um limite máximo de memória por tabela. O tamanho desse grupo de memória é especificado pelo parâmetro [temptable\$1max\$1ram](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_temptable_max_ram). O padrão é 1 GiB em instâncias de banco de dados com 16 GiB ou mais de memória e 16 MB em instâncias de banco de dados com menos de 16 GiB de memória. O tamanho do grupo de memória influencia o consumo de memória em nível de sessão. Em alguns casos, quando você usa o mecanismo de armazenamento `TempTable`, os dados temporários podem exceder o tamanho do grupo de memória. Nesse caso, o Aurora MySQL armazena os dados de transbordamento usando um mecanismo secundário. É possível definir o parâmetro [temptable\$1max\$1mmap](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_temptable_max_mmap) para escolher se os dados transbordam para arquivos temporários mapeados pela memória ou para tabelas temporárias internas do InnoDB no disco. Os diferentes formatos de dados e critérios de transbordamento desses mecanismos de transbordamento podem afetar a performance das consultas. Isso ocorre devido à sua influência sobre a quantidade de dados gravados no disco e a demanda na taxa de transferência de armazenamento em disco. O Aurora MySQL versão 3 armazena os dados de transbordamento da seguinte forma: + Na instância de banco de dados de gravação, os dados que transbordam para tabelas temporárias internas do InnoDB ou para arquivos temporários mapeados em memória residem no armazenamento local na instância. + Em instâncias de banco de dados de leitor, os dados de transbordamento sempre residem em arquivos temporários mapeados para a memória no armazenamento local. Instâncias somente leitura não podem armazenar dados no volume do cluster do Aurora. Os parâmetros de configuração relacionados a tabelas temporárias internas são aplicáveis de maneira diferente às instâncias de gravador e de leitor no seu cluster: + Em instâncias do leitor, o Aurora MySQL sempre utiliza o mecanismo de armazenamento `TempTable`. + O tamanho de `temptable_max_mmap` é de 1 GiB por padrão, tanto para instâncias do gravador quanto do leitor, independentemente do tamanho da memória da instância de banco de dados. Você pode ajustar esse valor em instâncias do gravador e do leitor. + A configuração de `temptable_max_mmap` para `0` desativa o uso de arquivos temporários mapeados na memória em instâncias do gravador. + Você não pode definir `temptable_max_mmap` como `0` em instâncias do leitor. **nota** Não recomendamos utilizar o parâmetro [temptable\$1use\$1mmap](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_temptable_use_mmap). Ele foi descontinuado, e há previsões de que o suporte será removido em uma versão futura do MySQL. ## Limitar o tamanho de tabelas temporárias internas na memória Conforme abordado em [Mecanismo de armazenamento para tabelas temporárias internas (implícitas)](#ams3-temptable-behavior-engine), é possível controlar recursos de tabelas temporárias globalmente usando as configurações [temptable\$1max\$1ram](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_temptable_max_ram) e [temptable\$1max\$1mmap](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_temptable_max_mmap). Você também pode limitar o tamanho de qualquer tabela temporária interna individual na memória usando o parâmetro de banco de dados [tmp\$1table\$1size](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_tmp_table_size). Esse limite tem como objetivo evitar que consultas individuais consumam uma quantidade excessiva de recursos globais de tabelas temporárias, o que pode afetar a performance de consultas simultâneas que exigem esses recursos. O parâmetro `tmp_table_size` define o tamanho máximo das tabelas temporárias criadas pelo mecanismo de armazenamento `MEMORY` no Aurora MySQL versão 3. No Aurora MySQL versão 3.04 e posterior, `tmp_table_size` também define o tamanho máximo das tabelas temporárias criadas pelo mecanismo de armazenamento `TempTable` quando o parâmetro de banco de dados `aurora_tmptable_enable_per_table_limit` é definido como `ON`. Esse comportamento, que está desabilitado (`OFF`) por padrão, é o mesmo que no Aurora MySQL versão 3.03 e versões anteriores. + Quando `aurora_tmptable_enable_per_table_limit` está `OFF`, `tmp_table_size` não é considerado para tabelas temporárias internas na memória criadas pelo mecanismo de armazenamento `TempTable`. No entanto, o limite dos recursos `TempTable` globais ainda se aplica. O Aurora MySQL tem o seguinte comportamento quando o limite de recursos `TempTable` globais é atingido: + Instâncias de banco de dados de gravador: o Aurora MySQL converte automaticamente a tabela temporária na memória em uma tabela temporária em disco do InnoDB. + Instâncias de banco de dados de leitor: a consulta termina com um erro. ``` ERROR 1114 (HY000): The table '/rdsdbdata/tmp/#sqlxx_xxx' is full ``` + Quando `aurora_tmptable_enable_per_table_limit` está `ON` e o limite de `tmp_table_size` é atingido, o Aurora MySQL tem o seguinte comportamento: + Instâncias de banco de dados de gravador: o Aurora MySQL converte automaticamente a tabela temporária na memória em uma tabela temporária em disco do InnoDB. + Instâncias de banco de dados de leitor: a consulta termina com um erro. ``` ERROR 1114 (HY000): The table '/rdsdbdata/tmp/#sqlxx_xxx' is full ``` Tanto o limite de recursos `TempTable` globais quanto o limite por tabela se aplicam nesse caso. **nota** O parâmetro `aurora_tmptable_enable_per_table_limit` não tem efeito quando [internal\$1tmp\$1mem\$1storage\$1engine](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_internal_tmp_mem_storage_engine) está definido como `MEMORY`. Nesse caso, o tamanho máximo de uma tabela temporária na memória é definido pelo valor [tmp\$1table\$1size](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_tmp_table_size) ou [max\$1heap\$1table\$1size](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_max_heap_table_size), o que for menor. Os exemplos a seguir mostram o comportamento do parâmetro `aurora_tmptable_enable_per_table_limit` para instâncias de banco de dados de gravador e leitor. **Example da instância de banco de dados de gravador com `aurora_tmptable_enable_per_table_limit` definido como `OFF`.** A tabela temporária na memória não é convertida em uma tabela temporária em disco do InnoDB. ``` mysql> set aurora_tmptable_enable_per_table_limit=0; Query OK, 0 rows affected (0.00 sec) mysql> select @@innodb_read_only,@@aurora_version,@@aurora_tmptable_enable_per_table_limit,@@temptable_max_ram,@@temptable_max_mmap; +--------------------+------------------+------------------------------------------+---------------------+----------------------+ | @@innodb_read_only | @@aurora_version | @@aurora_tmptable_enable_per_table_limit | @@temptable_max_ram | @@temptable_max_mmap | +--------------------+------------------+------------------------------------------+---------------------+----------------------+ | 0 | 3.04.0 | 0 | 1073741824 | 1073741824 | +--------------------+------------------+------------------------------------------+---------------------+----------------------+ 1 row in set (0.00 sec) mysql> show status like '%created_tmp_disk%'; +-------------------------+-------+ | Variable_name | Value | +-------------------------+-------+ | Created_tmp_disk_tables | 0 | +-------------------------+-------+ 1 row in set (0.00 sec) mysql> set cte_max_recursion_depth=4294967295; Query OK, 0 rows affected (0.00 sec) mysql> WITH RECURSIVE cte (n) AS (SELECT 1 UNION ALL SELECT n + 1 FROM cte WHERE n < 60000000) SELECT max(n) FROM cte; +----------+ | max(n) | +----------+ | 60000000 | +----------+ 1 row in set (13.99 sec) mysql> show status like '%created_tmp_disk%'; +-------------------------+-------+ | Variable_name | Value | +-------------------------+-------+ | Created_tmp_disk_tables | 0 | +-------------------------+-------+ 1 row in set (0.00 sec) ``` **Example da instância de banco de dados de gravador com `aurora_tmptable_enable_per_table_limit` definido como `ON`.** A tabela temporária na memória não é convertida em uma tabela temporária em disco do InnoDB. ``` mysql> set aurora_tmptable_enable_per_table_limit=1; Query OK, 0 rows affected (0.00 sec) mysql> select @@innodb_read_only,@@aurora_version,@@aurora_tmptable_enable_per_table_limit,@@tmp_table_size; +--------------------+------------------+------------------------------------------+------------------+ | @@innodb_read_only | @@aurora_version | @@aurora_tmptable_enable_per_table_limit | @@tmp_table_size | +--------------------+------------------+------------------------------------------+------------------+ | 0 | 3.04.0 | 1 | 16777216 | +--------------------+------------------+------------------------------------------+------------------+ 1 row in set (0.00 sec) mysql> set cte_max_recursion_depth=4294967295; Query OK, 0 rows affected (0.00 sec) mysql> show status like '%created_tmp_disk%'; +-------------------------+-------+ | Variable_name | Value | +-------------------------+-------+ | Created_tmp_disk_tables | 0 | +-------------------------+-------+ 1 row in set (0.00 sec) mysql> WITH RECURSIVE cte (n) AS (SELECT 1 UNION ALL SELECT n + 1 FROM cte WHERE n < 6000000) SELECT max(n) FROM cte; +---------+ | max(n) | +---------+ | 6000000 | +---------+ 1 row in set (4.10 sec) mysql> show status like '%created_tmp_disk%'; +-------------------------+-------+ | Variable_name | Value | +-------------------------+-------+ | Created_tmp_disk_tables | 1 | +-------------------------+-------+ 1 row in set (0.00 sec) ``` **Example da instância de banco de dados de leitor com `aurora_tmptable_enable_per_table_limit` definido como `OFF`.** A consulta termina sem um erro porque `tmp_table_size` não se aplica e o limite de recursos `TempTable` globais não foi atingido. ``` mysql> set aurora_tmptable_enable_per_table_limit=0; Query OK, 0 rows affected (0.00 sec) mysql> select @@innodb_read_only,@@aurora_version,@@aurora_tmptable_enable_per_table_limit,@@temptable_max_ram,@@temptable_max_mmap; +--------------------+------------------+------------------------------------------+---------------------+----------------------+ | @@innodb_read_only | @@aurora_version | @@aurora_tmptable_enable_per_table_limit | @@temptable_max_ram | @@temptable_max_mmap | +--------------------+------------------+------------------------------------------+---------------------+----------------------+ | 1 | 3.04.0 | 0 | 1073741824 | 1073741824 | +--------------------+------------------+------------------------------------------+---------------------+----------------------+ 1 row in set (0.00 sec) mysql> set cte_max_recursion_depth=4294967295; Query OK, 0 rows affected (0.00 sec) mysql> WITH RECURSIVE cte (n) AS (SELECT 1 UNION ALL SELECT n + 1 FROM cte WHERE n < 60000000) SELECT max(n) FROM cte; +----------+ | max(n) | +----------+ | 60000000 | +----------+ 1 row in set (14.05 sec) ``` **Example da instância de banco de dados de leitor com `aurora_tmptable_enable_per_table_limit` definido como `OFF`.** Essa consulta atinge o limite global de recursos TempTable com `aurora_tmptable_enable_per_table_limit` definido como DESATIVADO. A consulta termina com um erro nas instâncias de leitor. ``` mysql> set aurora_tmptable_enable_per_table_limit=0; Query OK, 0 rows affected (0.00 sec) mysql> select @@innodb_read_only,@@aurora_version,@@aurora_tmptable_enable_per_table_limit,@@temptable_max_ram,@@temptable_max_mmap; +--------------------+------------------+------------------------------------------+---------------------+----------------------+ | @@innodb_read_only | @@aurora_version | @@aurora_tmptable_enable_per_table_limit | @@temptable_max_ram | @@temptable_max_mmap | +--------------------+------------------+------------------------------------------+---------------------+----------------------+ | 1 | 3.04.0 | 0 | 1073741824 | 1073741824 | +--------------------+------------------+------------------------------------------+---------------------+----------------------+ 1 row in set (0.00 sec) mysql> set cte_max_recursion_depth=4294967295; Query OK, 0 rows affected (0.01 sec) mysql> WITH RECURSIVE cte (n) AS (SELECT 1 UNION ALL SELECT n + 1 FROM cte WHERE n < 120000000) SELECT max(n) FROM cte; ERROR 1114 (HY000): The table '/rdsdbdata/tmp/#sqlfd_1586_2' is full ``` **Example da instância de banco de dados de leitor com `aurora_tmptable_enable_per_table_limit` definido como `ON`.** A consulta termina com um erro quando o limite `tmp_table_size` é atingido. ``` mysql> set aurora_tmptable_enable_per_table_limit=1; Query OK, 0 rows affected (0.00 sec) mysql> select @@innodb_read_only,@@aurora_version,@@aurora_tmptable_enable_per_table_limit,@@tmp_table_size; +--------------------+------------------+------------------------------------------+------------------+ | @@innodb_read_only | @@aurora_version | @@aurora_tmptable_enable_per_table_limit | @@tmp_table_size | +--------------------+------------------+------------------------------------------+------------------+ | 1 | 3.04.0 | 1 | 16777216 | +--------------------+------------------+------------------------------------------+------------------+ 1 row in set (0.00 sec) mysql> set cte_max_recursion_depth=4294967295; Query OK, 0 rows affected (0.00 sec) mysql> WITH RECURSIVE cte (n) AS (SELECT 1 UNION ALL SELECT n + 1 FROM cte WHERE n < 6000000) SELECT max(n) FROM cte; ERROR 1114 (HY000): The table '/rdsdbdata/tmp/#sqlfd_8_2' is full ``` ## Mitigar problemas de volume em tabelas temporárias internas em réplicas do Aurora Para evitar problemas de limitação de tamanho de tabelas temporárias, defina os parâmetros `temptable_max_ram` e `temptable_max_mmap` para um valor combinado que pode atender aos requisitos de sua workload. Tenha cuidado ao definir o valor do parâmetro `temptable_max_ram`. Definir o valor muito alto reduz a memória disponível na instância do banco de dados, o que pode causar uma condição de falta de memória. Monitore a memória média livre na instância de banco de dados. Depois, determine um valor apropriado para `temptable_max_ram` para que você ainda tenha uma quantidade razoável de memória livre na instância. Para obter mais informações, consulte [Problemas de memória liberável no Amazon Aurora](CHAP_Troubleshooting.md#Troubleshooting.FreeableMemory). Também é importante monitorar o tamanho do armazenamento local e o consumo de espaço em tabelas temporárias. É possível monitorar o armazenamento temporário disponível para uma instância de banco de dados específica com a métrica `FreeLocalStorage` do Amazon CloudWatch, descrita em [Métricas do Amazon CloudWatch para o Amazon Aurora](Aurora.AuroraMonitoring.Metrics.md). **nota** Esse procedimento não funciona quando o parâmetro `aurora_tmptable_enable_per_table_limit` está definido como `ON`. Para obter mais informações, consulte [Limitar o tamanho de tabelas temporárias internas na memória](#ams3-temptable-behavior-limit). **Example 1** Você sabe que suas tabelas temporárias aumentam até um tamanho cumulativo de 20 GiB. Você deseja definir tabelas temporárias na memória como 2 GiB e aumentar para um máximo de 20 GiB em disco. Defina `temptable_max_ram` como **2,147,483,648** e `temptable_max_mmap` como **21,474,836,480**. Esses valores estão em bytes. Essas configurações de parâmetros garantem que suas tabelas temporárias possam aumentar até um total cumulativo de 22 GiB. **Example 2** O tamanho da instância atual é 16xlarge ou maior. Você não sabe o tamanho total das tabelas temporárias que pode precisar. Você deseja ter a capacidade de usar até 4 GiB na memória e até o tamanho máximo de armazenamento disponível no disco. Defina `temptable_max_ram` como **4,294,967,296** e `temptable_max_mmap` como **1,099,511,627,776**. Esses valores estão em bytes. Aqui você está definindo `temptable_max_mmap` como 1 TiB, que é inferior ao armazenamento local máximo de 1,2 TiB em uma instância de banco de dados 16xlarge do Aurora. Em um tamanho de instância menor, ajuste o valor de `temptable_max_mmap` para que ele não preencha o armazenamento local disponível. Por exemplo, uma instância 2xlarge tem apenas 160 GiB de armazenamento local disponível. Por isso, recomendamos definir o valor como menos de 160 GiB. Para obter mais informações sobre o armazenamento local disponível para tamanhos de instância de banco de dados, consulte [Limites de armazenamento temporário para o Aurora MySQLLimites de armazenamento temporário](AuroraMySQL.Managing.Performance.md#AuroraMySQL.Managing.TempStorage). ## Otimizar o parâmetro temptable\$1max\$1mmap nas instâncias de banco de dados do Aurora MySQL O parâmetro `temptable_max_mmap` no Aurora MySQL controla a quantidade máxima de espaço em disco local que pode ser usada por arquivos mapeados na memória antes de transbordar para as tabelas temporárias do InnoDB em disco (em instâncias de banco de dados de gravador) ou causar um erro (em instâncias de banco de dados de leitor). Definir esse parâmetro de instância de banco de dados corretamente pode ajudar a otimizar o desempenho das instâncias de banco de dados. **Pré-requisitos** 1. O Performance Schema deve estar habilitado. Você pode verificar isso executando o seguinte comando SQL: ``` SELECT @@performance_schema; ``` Um valor de saída de `1` indica que ele está habilitado. 1. Confirme se a instrumentação de memória de tabela temporária está habilitada. Você pode verificar isso executando o seguinte comando SQL: ``` SELECT name, enabled FROM performance_schema.setup_instruments WHERE name LIKE '%memory%temptable%'; ``` A coluna `enabled` mostra `YES` para as entradas relevantes de instrumentação de memória de tabela temporária. **Monitorar o uso de tabelas temporárias** Ao definir o valor inicial para `temptable_max_mmap`, recomendamos que você comece com 80% do tamanho do armazenamento local para a classe de instância de banco de dados que está usando. Isso garante que as tabelas temporárias tenham espaço em disco suficiente para operar com eficiência, ao mesmo tempo em que deixa espaço para outros usos do disco na instância. Para encontrar o tamanho do armazenamento local para sua classe de instância de banco de dados, consulte [Limites de armazenamento temporário para o Aurora MySQLLimites de armazenamento temporário](AuroraMySQL.Managing.Performance.md#AuroraMySQL.Managing.TempStorage). Por exemplo, se você estiver usando a classe de instância de banco de dados db.r5.large, o tamanho do armazenamento local é de 32 GiB. Nesse caso, você definiria inicialmente o parâmetro `temptable_max_mmap` para 80% de 32 GiB, que é 25,6 GiB. Depois de definir o valor inicial de `temptable_max_mmap`, execute a workload máxima nas instâncias do Aurora MySQL. Monitore o uso atual e máximo do disco de tabela temporária usando a seguinte consulta SQL: ``` SELECT event_name, current_count, current_alloc, current_avg_alloc, high_count, high_alloc, high_avg_alloc FROM sys.memory_global_by_current_bytes WHERE event_name LIKE 'memory/temptable/%'; ``` Essa consulta recupera as seguintes informações: + `event_name`: o nome do evento de uso de memória ou disco de tabelas temporárias. + `current_count`: o número atual de blocos de memória ou disco alocados de tabelas temporárias. + `current_alloc`: a quantidade atual de memória ou disco alocada para tabelas temporárias. + `current_avg_alloc`: o tamanho médio atual dos blocos de memória ou disco de tabelas temporárias. + `high_count`: o maior número de blocos de memória ou disco alocados de tabelas temporárias. + `high_alloc`: a maior quantidade de memória ou disco alocada para tabelas temporárias. + `high_avg_alloc`: o maior tamanho médio dos blocos de memória ou disco de tabelas temporárias. Se as consultas falharem com um erro Table is full usando essa configuração, isso indica que a workload requer mais espaço em disco para operações de tabelas temporárias. Nesse caso, considere aumentar o tamanho da instância de banco de dados para uma com mais espaço de armazenamento local. **Definir o valor ideal de `temptable_max_mmap`** Use o procedimento a seguir para monitorar e definir o tamanho correto para o parâmetro `temptable_max_mmap`. 1. Analise a saída da consulta anterior e identifique o pico de uso de disco para tabelas temporárias, conforme indicado pela coluna `high_alloc`. 1. Com base no pico de uso de disco de tabelas temporárias, ajuste o parâmetro `temptable_max_mmap` no grupo de parâmetros do banco de dados para as instâncias de banco de dados do Aurora MySQL. Defina o valor para ser um pouco maior do que o pico de uso de disco de tabelas temporárias para acomodar o crescimento futuro. 1. Aplique as alterações do grupo de parâmetros às instâncias de banco de dados. 1. Monitore o uso de disco de tabelas temporárias novamente durante o pico de workload para garantir que o novo valor de `temptable_max_mmap` seja apropriado. 1. Repita as etapas anteriores conforme necessário para ajustar o parâmetro `temptable_max_mmap`. ## Tabelas temporárias criadas pelo usuário (explícitas) em instâncias de banco de dados de leitor Você pode criar explicitamente tabelas temporárias usando uma palavra-chave `TEMPORARY` em sua instrução `CREATE TABLE`. As tabelas temporárias explícitas são compatíveis com a instância de banco de dados do gravador em um cluster de banco de dados do Aurora. Você também pode usar tabelas temporárias explícitas em instâncias de banco de dados do leitor, mas as tabelas não podem impor o uso do mecanismo de armazenamento InnoDB. Para evitar erros ao criar tabelas temporárias explícitas em instâncias de banco de dados do leitor do Aurora MySQL, execute todas as instruções `CREATE TEMPORARY TABLE` em instâncias de banco de dados do leitor de uma destas maneiras: + Não especifique a cláusula `ENGINE=InnoDB`. + Não defina o modo SQL como `NO_ENGINE_SUBSTITUTION`. ## Mitigação e erros de criação de tabelas temporárias O erro retornado é diferente dependendo de você utilizar uma instrução `CREATE TEMPORARY TABLE` simples ou a variação `CREATE TEMPORARY TABLE AS SELECT`. Os exemplos a seguir mostram os diferentes tipos de erros. Esse comportamento de tabela temporária apenas se aplica a instâncias somente leitura. Esse primeiro exemplo confirma que este é o tipo de instância à qual a sessão está conectada. ``` mysql> select @@innodb_read_only; +--------------------+ | @@innodb_read_only | +--------------------+ | 1 | +--------------------+ ``` Para instruções `CREATE TEMPORARY TABLE` simples, a instrução falha quando o modo SQL `NO_ENGINE_SUBSTITUTION` está habilitado. Quando `NO_ENGINE_SUBSTITUTION` está desativado (padrão), a substituição do mecanismo apropriado é feita e a criação temporária da tabela é bem-sucedida. ``` mysql> set sql_mode = 'NO_ENGINE_SUBSTITUTION'; mysql> CREATE TEMPORARY TABLE tt2 (id int) ENGINE=InnoDB; ERROR 3161 (HY000): Storage engine InnoDB is disabled (Table creation is disallowed). mysql> SET sql_mode = ''; mysql> CREATE TEMPORARY TABLE tt4 (id int) ENGINE=InnoDB; mysql> SHOW CREATE TABLE tt4\G *************************** 1. row *************************** Table: tt4 Create Table: CREATE TEMPORARY TABLE `tt4` ( `id` int DEFAULT NULL ) ENGINE=MyISAM DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci ``` Para instruções `CREATE TEMPORARY TABLE AS SELECT`, a instrução falha quando o modo SQL `NO_ENGINE_SUBSTITUTION` está ativado. Quando `NO_ENGINE_SUBSTITUTION` está desativado (padrão), a substituição do mecanismo apropriado é feita e a criação temporária da tabela é bem-sucedida. ``` mysql> set sql_mode = 'NO_ENGINE_SUBSTITUTION'; mysql> CREATE TEMPORARY TABLE tt1 ENGINE=InnoDB AS SELECT * FROM t1; ERROR 3161 (HY000): Storage engine InnoDB is disabled (Table creation is disallowed). mysql> SET sql_mode = ''; mysql> show create table tt3; +-------+----------------------------------------------------------+ | Table | Create Table | +-------+----------------------------------------------------------+ | tt3 | CREATE TEMPORARY TABLE `tt3` ( `id` int DEFAULT NULL ) ENGINE=MyISAM DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci | +-------+----------------------------------------------------------+ 1 row in set (0.00 sec) ``` Para obter mais informações sobre os aspectos de armazenamento e as implicações de performance de tabelas temporárias no Aurora MySQL versão 3, consulte a postagem do blog [Usar o mecanismo de armazenamento TempTable no Amazon RDS para MySQL e Amazon Aurora MySQL](https://aws.amazon.com/blogs/database/use-the-temptable-storage-engine-on-amazon-rds-for-mysql-and-amazon-aurora-mysql/). # Comparar o Aurora MySQL versão 2 e o Aurora MySQL versão 3 Use as seguintes informações para saber mais sobre as alterações a serem observadas ao fazer upgrade do cluster do Aurora MySQL versão 2 para a versão 3. **Topics** + [Compatibilidade com a Linguagem de definição de dados (DDL) atômica](#AuroraMySQL.Compare-v2-v3-atomic-ddl) + [Diferenças de recursos entre as versões 2 e 3 do Aurora MySQL](#AuroraMySQL.Compare-v2-v3-features) + [Suporte a classes de instâncias](#AuroraMySQL.mysql80-instance-classes) + [Alterações de parâmetros do Aurora MySQL versão 3](#AuroraMySQL.mysql80-parameter-changes) + [Variáveis de status](#AuroraMySQL.mysql80-status-vars) + [Alterações de linguagem inclusiva do Aurora MySQL versão 3](#AuroraMySQL.8.0-inclusive-language) + [Valores de AUTO\$1INCREMENT](#AuroraMySQL.mysql80-autoincrement) + [Replicação de log binário](#AuroraMySQL.mysql80-binlog) ## Compatibilidade com a Linguagem de definição de dados (DDL) atômica Uma das maiores mudanças do MySQL 5.7 para o 8.0 é a introdução do [Atomic Data Dictionary](https://dev.mysql.com/doc/refman/8.0/en/data-dictionary-file-removal.html). Antes do MySQL 8.0, o dicionário de dados do MySQL usava uma abordagem baseada em arquivos para armazenar determinados metadados, como definições de tabela (.frm), gatilhos (.trg) e funções, à parte dos metadados do mecanismo de armazenamento (como os do InnoDB). Isso causava alguns problemas, incluindo o risco de as tabelas ficarem “[órfãs](https://dev.mysql.com/doc/refman/5.7/en/innodb-troubleshooting-datadict.html)” se algo inesperado acontecesse durante uma operação de DDL, fazendo com que os metadados baseados em arquivos e do mecanismo de armazenamento ficassem fora de sincronia. Para corrigir isso, o MySQL 8.0 introduziu o Atomic Data Dictionary, que armazena todos os metadados em um conjunto de tabelas internas do InnoDB no esquema `mysql`. Essa nova arquitetura oferece uma forma transacional compatível com [ACID](https://en.wikipedia.org/wiki/ACID) de gerenciar metadados de banco de dados, resolvendo o problema de “DDL atômica” com a antiga abordagem baseada em arquivos. Consulte mais informações sobre o Atomic Data Dictionary em [Removal of file-based metadata storage](https://dev.mysql.com/doc/refman/8.0/en/data-dictionary-file-removal.html) e em [Atomic data definition statement support](https://dev.mysql.com/doc/refman/8.0/en/atomic-ddl.html) no *MySQL Reference Manual*. Devido a essa mudança de arquitetura, você deve considerar o seguinte ao atualizar da versão 2 do Aurora MySQL para a versão 3: + Os metadados baseados em arquivo da versão 2 devem ser migrados para as novas tabelas do dicionário de dados durante o processo de atualização para a versão 3. Dependendo do número de objetos de banco de dados que forem migrados, isso poderá levar algum tempo. + As mudanças também incluíram algumas novas incompatibilidades que podem precisar ser resolvidas antes da atualização do MySQL 5.7 para 8.0. Por exemplo, a versão 8.0 introduziu algumas palavras-chave reservadas que podem entrar em conflito com os nomes de objeto de banco de dados existentes. Para ajudar você a identificar essas incompatibilidades antes de atualizar o mecanismo, o Aurora MySQL executa uma série de verificações de compatibilidade de atualização (pré-verificações) antes de realizar a atualização do dicionário de dados para determinar se há algum objeto incompatível. Consulte mais informações sobre as pré-verificações em [Verificações prévias de atualização da versão principal do Aurora MySQL](AuroraMySQL.upgrade-prechecks.md). ## Diferenças de recursos entre as versões 2 e 3 do Aurora MySQL Os recursos a seguir no Amazon Aurora MySQL têm suporte no Aurora MySQL para o MySQL 5.7, mas não têm suporte atualmente no Aurora MySQL para o MySQL 8.0: + Não é possível utilizar o Aurora MySQL versão 3 para clusters do Aurora Serverless v1. O Aurora MySQL versão 3 funciona com o Aurora Serverless v2. + O modo de laboratório não é aplicável ao Aurora MySQL versão 3. Não há recursos de modo de laboratório no Aurora MySQL versão 3. A DDL instantâneo substitui o recurso de DDL on-line rápida que estava disponível no modo de laboratório. Para ver um exemplo, consulte [DDL instantânea (Aurora MySQL versão 3)](AuroraMySQL.Managing.FastDDL.md#AuroraMySQL.mysql80-instant-ddl). + O cache de consulta foi removido do MySQL 8.0 edição da comunidade e também do Aurora MySQL versão 3. + O Aurora MySQL versão 3 tem compatibilidade com o recurso de junção de hash do MySQL da comunidade. A implementação específica do Aurora de junções de hash no Aurora MySQL versão 2 não é utilizada. Para obter informações sobre como utilizar junções de hash com a consulta paralela do Aurora, consulte [Habilitar a junção de hash para clusters de consulta paralela](aurora-mysql-parallel-query-enabling.md#aurora-mysql-parallel-query-enabling-hash-join) e [Dicas do Aurora MySQL](AuroraMySQL.Reference.Hints.md). Para obter informações gerais de uso sobre junções de hash, consulte [Otimização de junções de hash](https://dev.mysql.com/doc/refman/8.0/en/hash-joins.html), no *Guia de referência do MySQL*. + O procedimento armazenado `mysql.lambda_async` que foi marcado como defasado no Aurora MySQL versão 2 foi removido na versão 3. Para a versão 3, use a função assíncrona `lambda_async` no lugar. + O conjunto de caracteres padrão no Aurora MySQL versão 3 é `utf8mb4`. No Aurora MySQL versão 2, o conjunto de caracteres padrão era `latin1`. Para obter informações sobre esse conjunto de caracteres, consulte [O conjunto de caracteres utf8mb4 (4-Byte UTF-8 Unicode Encoding)](https://dev.mysql.com/doc/refman/8.0/en/charset-unicode-utf8mb4.html), no *Guia de referência do MySQL*. Determinados recursos do Aurora MySQL estão disponíveis para determinadas combinações de região da AWS e versão do mecanismo de banco de dados. Para obter detalhes, consulte [Recursos compatíveis com o Amazon Aurora por Região da AWS e com o mecanismo de banco de dados do Aurora](Concepts.AuroraFeaturesRegionsDBEngines.grids.md). ## Suporte a classes de instâncias O Aurora MySQL versão 3 oferece suporte a um conjunto diferente de classes de instâncias em comparação com o Aurora MySQL versão 2: + Para instâncias maiores, é possível utilizar as classes de instâncias modernas, como `db.r5`, `db.r6g` e `db.x2g`. + Para instâncias menores, é possível utilizar as classes de instâncias modernas, como `db.t3` e `db.t4g`. **nota** Recomendamos usar as classes de instância de banco de dados T somente para servidores de desenvolvimento e teste, ou outros servidores que não sejam de produção. Para obter mais detalhes sobre as classes de instâncias T, consulte [Uso de classes de instância T para desenvolvimento e testes](AuroraMySQL.BestPractices.Performance.md#AuroraMySQL.BestPractices.T2Medium). As classes de instância a seguir do Aurora MySQL versão 2 não estão disponíveis para o Aurora MySQL versão 3: + `db.r4` + `db.r3` + `db.t3.small` + `db.t2` Confira se há declarações da CLI em seus scripts de administração que criem instâncias de banco de dados do Aurora MySQL. Nomes de classes de instâncias de código fixo que não estejam disponíveis para o Aurora MySQL versão 3. Se necessário, modifique os nomes das classes de instância para nomes que são compatíveis no Aurora MySQL versão 3. **dica** Para verificar as classes de instância que podem ser utilizadas para uma combinação específica de versão do Aurora MySQL e região da AWS, use o comando `describe-orderable-db-instance-options` AWS CLI. Para obter detalhes completos sobre classes de instâncias do Aurora, consulte [Classes de instâncias de banco de dados do Amazon Aurora](Concepts.DBInstanceClass.md). ## Alterações de parâmetros do Aurora MySQL versão 3 O Aurora MySQL versão 3 inclui novos parâmetros de configuração em nível de cluster e de instância. O Aurora MySQL versão 3 também remove alguns parâmetros anteriormente presentes no Aurora MySQL versão 2. Alguns nomes de parâmetros foram modificados como resultado da iniciativa de linguagem inclusiva. Para compatibilidade com versões anteriores, ainda é possível recuperar valores de parâmetros utilizando os nomes antigos ou os novos. Porém, você deve utilizar os novos nomes para especificar valores de parâmetros em um grupo de parâmetros personalizado. No Aurora MySQL versão 3, o valor do parâmetro `lower_case_table_names` é 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. Em seguida, especifique o grupo de parâmetros durante a operação de criação de cluster ou restauração do snapshot. **nota** 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. Use o método de restauração de snapshot. Na versão 3 do Aurora MySQL, os parâmetros `init_connect` e `read_only` não se aplicam 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). Para obter a lista completa dos parâmetros de cluster do Aurora MySQL, consulte [Parâmetros no nível do cluster](AuroraMySQL.Reference.ParameterGroups.md#AuroraMySQL.Reference.Parameters.Cluster). A tabela engloba todos os parâmetros do Aurora MySQL versões 2 e 3. A tabela inclui observações mostrando quais parâmetros são novos no Aurora MySQL versão 3 ou foram removidos do Aurora MySQL versão 3. Para obter a lista completa de parâmetros de instância do Aurora MySQL, consulte [Parâmetros no nível da instância](AuroraMySQL.Reference.ParameterGroups.md#AuroraMySQL.Reference.Parameters.Instance). A tabela engloba todos os parâmetros do Aurora MySQL versões 2 e 3. A tabela inclui observações mostrando quais parâmetros são novos no Aurora MySQL versão 3 e quais parâmetros foram removidos do Aurora MySQL versão 3. Ela também inclui observações indicando quais parâmetros eram modificáveis em versões anteriores, mas não no Aurora MySQL versão 3. Para obter informações sobre nomes de parâmetros modificados, consulte [Alterações de linguagem inclusiva do Aurora MySQL versão 3](#AuroraMySQL.8.0-inclusive-language). ## Variáveis de status Para obter informações sobre variáveis de status não aplicáveis ao Aurora MySQL, consulte [Variáveis de status do MySQL não se aplicam ao Aurora MySQL](AuroraMySQL.Reference.GlobalStatusVars.md#AuroraMySQL.Reference.StatusVars.Inapplicable). ## Alterações de linguagem inclusiva do Aurora MySQL versão 3 O Aurora MySQL versão 3 tem compatibilidade com a versão 8.0.23 do MySQL edição da comunidade. O Aurora MySQL versão 3 também inclui alterações do MySQL 8.0.26 referentes a palavras-chave e esquemas de sistema para linguagem inclusiva. Por exemplo, o uso do comando `SHOW REPLICA STATUS` agora é preferencial ao do comando `SHOW SLAVE STATUS`. As seguintes métricas do Amazon CloudWatch têm novos nomes no Aurora MySQL versão 3. No Aurora MySQL versão 3, somente os nomes de métricas novos estão disponíveis. Certifique-se de atualizar alarmes ou qualquer outra automação que dependa de nomes de métricas ao fazer upgrade para o Aurora MySQL versão 3. | Nome antigo | Novo nome | | --- | --- | | ForwardingMasterDMLLatency | ForwardingWriterDMLLatency | | ForwardingMasterOpenSessions | ForwardingWriterOpenSessions | | AuroraDMLRejectedMasterFull | AuroraDMLRejectedWriterFull | | ForwardingMasterDMLThroughput | ForwardingWriterDMLThroughput | As seguintes variáveis de status têm novos nomes no Aurora MySQL versão 3. Para compatibilidade, é possível utilizar qualquer um dos nomes na versão inicial do Aurora MySQL versão 3. Os nomes de variáveis de status antigos serão removidos em um release futuro. | Nome a ser removido | Nome novo ou preferencial | | --- | --- | | Aurora\$1fwd\$1master\$1dml\$1stmt\$1duration | Aurora\$1fwd\$1writer\$1dml\$1stmt\$1duration | | Aurora\$1fwd\$1master\$1dml\$1stmt\$1count | Aurora\$1fwd\$1writer\$1dml\$1stmt\$1count | | Aurora\$1fwd\$1master\$1select\$1stmt\$1duration | Aurora\$1fwd\$1writer\$1select\$1stmt\$1duration | | Aurora\$1fwd\$1master\$1select\$1stmt\$1count | Aurora\$1fwd\$1writer\$1select\$1stmt\$1count | | Aurora\$1fwd\$1master\$1errors\$1session\$1timeout | Aurora\$1fwd\$1writer\$1errors\$1session\$1timeout | | Aurora\$1fwd\$1master\$1open\$1sessions | Aurora\$1fwd\$1writer\$1open\$1sessions | | Aurora\$1fwd\$1master\$1errors\$1session\$1limit | Aurora\$1fwd\$1writer\$1errors\$1session\$1limit | | Aurora\$1fwd\$1master\$1errors\$1rpc\$1timeout | Aurora\$1fwd\$1writer\$1errors\$1rpc\$1timeout | Os seguintes parâmetros de configuração têm nomes novos no Aurora MySQL versão 3. Para fins de compatibilidade, é possível verificar os valores dos parâmetros no cliente `mysql` utilizando qualquer nome no release inicial do Aurora MySQL versão 3. Você só pode usar os novos nomes ao modificar os valores em um grupo de parâmetros personalizado. Os nomes de parâmetros antigos serão removidos em um release futuro. | Nome a ser removido | Nome novo ou preferencial | | --- | --- | | aurora\$1fwd\$1master\$1idle\$1timeout | aurora\$1fwd\$1writer\$1idle\$1timeout | | aurora\$1fwd\$1master\$1max\$1connections\$1pct | aurora\$1fwd\$1writer\$1max\$1connections\$1pct | | master\$1verify\$1checksum | source\$1verify\$1checksum | | sync\$1master\$1info | sync\$1source\$1info | | init\$1slave | init\$1replica | | rpl\$1stop\$1slave\$1timeout | rpl\$1stop\$1replica\$1timeout | | log\$1slow\$1slave\$1statements | log\$1slow\$1replica\$1statements | | slave\$1max\$1allowed\$1packet | replica\$1max\$1allowed\$1packet | | slave\$1compressed\$1protocol | replica\$1compressed\$1protocol | | slave\$1exec\$1mode | replica\$1exec\$1mode | | slave\$1type\$1conversions | replica\$1type\$1conversions | | slave\$1sql\$1verify\$1checksum | replica\$1sql\$1verify\$1checksum | | slave\$1parallel\$1type | replica\$1parallel\$1type | | slave\$1preserve\$1commit\$1order | replica\$1preserve\$1commit\$1order | | log\$1slave\$1updates | log\$1replica\$1updates | | slave\$1allow\$1batching | replica\$1allow\$1batching | | slave\$1load\$1tmpdir | replica\$1load\$1tmpdir | | slave\$1net\$1timeout | replica\$1net\$1timeout | | sql\$1slave\$1skip\$1counter | sql\$1replica\$1skip\$1counter | | slave\$1skip\$1errors | replica\$1skip\$1errors | | slave\$1checkpoint\$1period | replica\$1checkpoint\$1period | | slave\$1checkpoint\$1group | replica\$1checkpoint\$1group | | slave\$1transaction\$1retries | replica\$1transaction\$1retries | | slave\$1parallel\$1workers | replica\$1parallel\$1workers | | slave\$1pending\$1jobs\$1size\$1max | replica\$1pending\$1jobs\$1size\$1max | | pseudo\$1slave\$1mode | pseudo\$1replica\$1mode | Os seguintes procedimentos armazenados têm novos nomes no Aurora MySQL versão 3. Para compatibilidade, é possível utilizar qualquer um dos nomes na versão inicial do Aurora MySQL versão 3. Os nomes de procedimentos antigos serão removidos em um release futuro. | Nome a ser removido | Nome novo ou preferencial | | --- | --- | | mysql.rds\$1set\$1master\$1auto\$1position | mysql.rds\$1set\$1source\$1auto\$1position | | mysql.rds\$1set\$1external\$1master | mysql.rds\$1set\$1external\$1source | | mysql.rds\$1set\$1external\$1master\$1with\$1auto\$1position | mysql.rds\$1set\$1external\$1source\$1with\$1auto\$1position | | mysql.rds\$1reset\$1external\$1master | mysql.rds\$1reset\$1external\$1source | | mysql.rds\$1next\$1master\$1log | mysql.rds\$1next\$1source\$1log | ## Valores de AUTO\$1INCREMENT No Aurora MySQL versão 3, o Aurora preserva o valor `AUTO_INCREMENT` para cada tabela ao reiniciar cada instância de banco de dados. No Aurora MySQL versão 2, o valor `AUTO_INCREMENT` não era preservado após uma reinicialização. O valor `AUTO_INCREMENT` não é preservado quando você configura um novo cluster por meio da restauração com um snapshot, aplicação de uma recuperação em um ponto anterior no tempo e clonagem de um cluster. Nesses casos, o valor `AUTO_INCREMENT` é inicializado para o valor com base no maior valor de coluna na tabela na ocasião em que o snapshot foi criado. Esse comportamento é diferente daquele no RDS para MySQL 8.0, em que o valor `AUTO_INCREMENT` é preservado durante essas operações. ## Replicação de log binário No MySQL 8.0 edição da comunidade, a replicação de logs binários está habilitada por padrão. No Aurora MySQL versão 3, a replicação de logs binários está desabilitada por padrão. **dica** Se os seus requisitos de alta disponibilidade forem atendidos pelos recursos de replicação integrados do Aurora, será possível deixar a replicação de logs binários desabilitada. Dessa forma, é possível evitar a sobrecarga de performance da replicação de logs binários. Você também pode evitar os processos de monitoramento e solução de problemas associados que são necessários para gerenciar a replicação de logs binários. O Aurora oferece suporte à replicação de logs binários de uma fonte compatível com MySQL 5.7 para o Aurora MySQL versão 3. O sistema de origem pode ser um cluster de banco de dados do Aurora MySQL, uma instância de banco de dados do RDS para MySQL ou uma instância do MySQL on-premises. Assim como o MySQL edição da comunidade, o Aurora MySQL oferece suporte para replicação a partir de uma origem que executa uma versão específica para um destino que executa a mesma versão principal ou uma versão principal superior. Por exemplo, não há suporte para a replicação de um sistema compatível com MySQL 5.6 para o Aurora MySQL versão 3. Não há suporte para a replicação do Aurora MySQL versão 3 para um sistema compatível com o MySQL 5.7 ou MySQL 5.6. Para obter detalhes sobre como utilizar a replicação de logs binários, 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 Aurora MySQL versão 3 inclui melhorias na replicação de logs binários no MySQL 8.0 edição da comunidade, como a replicação filtrada. Para obter detalhes sobre as melhorias no MySQL 8.0 edição da comunidade, consulte [Como servidores avaliam regras de filtragem de replicação](https://dev.mysql.com/doc/refman/8.0/en/replication-rules.html), no *Guia de referência do MySQL*. ### Compactação de transações para replicação de logs binários Para obter informações de uso sobre a compactação de logs binários, consulte [Compactação de transações de logs binários](https://dev.mysql.com/doc/refman/8.0/en/binary-log-transaction-compression.html), no Guia de referência do MySQL. As seguintes limitações aplicam-se à compactação de logs binários no Aurora MySQL versão 3: + Transações cujos dados de logs binários sejam maiores que o tamanho máximo permitido do pacote não são compactadas. Isso se aplica independentemente de a configuração de compactação de logs binários do Aurora MySQL estar ativada ou não. Essas transações são replicadas sem serem compactadas. + Se você utilizar um conector para captura de dados de alterações (CDC) que ainda não ofereça suporte ao MySQL 8.0, não será possível utilizar esse recurso. Recomendamos testar completamente todos os conectores de terceiros com a compactação de logs binários. Além disso, recomendamos fazer isso antes de ativar a compactação de binlog em sistemas que utilizam a replicação de binlog para CDC. # Comparar o Aurora MySQL versão 3 e o MySQL 8.0 Community Edition Use as seguintes informações para saber mais sobre as alterações a serem observadas ao converter de um sistema compatível com MySQL 8.0 diferente para o Aurora MySQL versão 3. Em geral, o Aurora MySQL versão 3 é compatível com o conjunto de recursos do MySQL 8.0.23 edição da comunidade. Alguns novos recursos do MySQL 8.0 edição da comunidade não se aplicam ao Aurora MySQL. Alguns desses recursos não são compatíveis com alguns aspectos do Aurora, como a arquitetura de armazenamento. Outros recursos não são necessários, pois o serviço de gerenciamento do Amazon RDS fornece funcionalidade equivalente. Os seguintes recursos no MySQL 8.0 edição da comunidade não têm suporte ou funcionam de maneira diferente no Aurora MySQL versão 3. Para acessar as notas de lançamento de todas as versões do Aurora MySQL versão 3, consulte [Atualizações no mecanismo de banco de dados do Amazon Aurora MySQL versão 3](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraMySQLReleaseNotes/AuroraMySQL.Updates.30Updates.html) em *Notas de lançamento do Aurora MySQL*. **Topics** + [Recursos do MySQL 8.0 que não estão disponíveis no Aurora MySQL versão 3](#AuroraMySQL.Compare-80-v3-features) + [Modelo de privilégios baseados em funções](#AuroraMySQL.privilege-model) + [Localização do ID do servidor do banco de dados](#AuroraMySQL.server-id) + [Autenticação](#AuroraMySQL.mysql80-authentication) ## Recursos do MySQL 8.0 que não estão disponíveis no Aurora MySQL versão 3 Os seguintes recursos no MySQL 8.0 edição da comunidade não estão disponíveis ou funcionam de maneira diferente no Aurora MySQL versão 3. + Os grupos de recursos e as instruções SQL associadas não têm suporte no Aurora MySQL. + O Aurora MySQL não é compatível com espaços de tabela undo definidos pelo usuário e instruções SQL associadas, como `CREATE UNDO TABLESPACE`, `ALTER UNDO TABLESPACE ... SET INACTIVE` e `DROP UNDO TABLESPACE`. + O Aurora MySQL não é compatível com o truncamento de espaço de tabela undo para versões do Aurora MySQL anteriores a 3.06. No Aurora MySQL versão 3.06 e posterior, o [truncamento automático do espaço de tabela undo](https://dev.mysql.com/doc/refman/8.0/en/innodb-undo-tablespaces.html#truncate-undo-tablespace) é compatível. + O plug-in de validação de senha não é aceito. + Não é possível modificar as configurações de nenhum dos plug-ins do MySQL, incluindo o plug-in de validação de senha. + Não há suporte para o plugin X. + Não há suporte à replicação em várias origens. ## Modelo de privilégios baseados em funções Com o Aurora MySQL versão 3, não é possível modificar as tabelas no banco de dados `mysql` diretamente. Em particular, não é possível configurar usuários inserindo-os na tabela `mysql.user`. Em vez disso, use instruções SQL para conceder privilégios baseados em funções. Você também não pode criar outros tipos de objeto, como procedimentos armazenados no banco de dados do `mysql`. Você ainda pode consultar as tabelas `mysql`. Se você utilizar a replicação de logs binários, as alterações feitas diretamente nas tabelas `mysql` no cluster de origem não serão replicadas no cluster de destino. Em alguns casos, sua aplicação pode utilizar atalhos para criar usuários ou outros objetos inserindo-os nas tabelas `mysql`. Em caso afirmativo, altere o código da aplicação para utilizar as instruções correspondentes, como `CREATE USER`. Se a aplicação criar procedimentos armazenados ou outros objetos no banco de dados do `mysql`, use um banco de dados diferente. Para exportar metadados para usuários de banco de dados durante a migração de um banco de dados externo do MySQL, é possível usar um comando do MySQL Shell em vez de `mysqldump`. Consulte mais informações em [Instance Dump Utility, Schema Dump Utility, and Table Dump Utility](https://dev.mysql.com/doc/mysql-shell/8.0/en/mysql-shell-utilities-dump-instance-schema.html#mysql-shell-utilities-dump-about). Para simplificar o gerenciamento de permissões para vários usuários ou aplicações, é possível utilizar a instrução `CREATE ROLE` para criar uma função que tenha um conjunto de permissões. Em seguida, você pode utilizar as instruções `GRANT` e `SET ROLE` e a função `current_role` para atribuir funções a usuários ou aplicações, alternar a função atual e verificar quais funções estão em vigor. Para obter mais informações sobre o sistema de permissões baseadas em funções no MySQL 8.0, consulte o tópico sobre como [Usar funções](https://dev.mysql.com/doc/refman/8.0/en/roles.html), no Guia de referência do MySQL. **Importante** É altamente recomendável não usar o usuário mestre diretamente nas aplicações. Em vez disso, siga as práticas recomendadas de usar um usuário do banco de dados criado com os privilégios mínimos obrigatórios para a aplicação. **Topics** + [rds\$1superuser\$1role](#AuroraMySQL.privilege-model.rds_superuser_role) + [Usuário de verificação de privilégios para replicação de logs binários.](#AuroraMySQL.privilege-model.binlog) + [Perfis para acessar outros serviços da AWS](#AuroraMySQL.privilege-model.other) ### rds\$1superuser\$1role O Aurora MySQL versão 3 inclui uma função especial que tem todos os privilégios a seguir. Essa função se chama `rds_superuser_role`. O usuário administrativo principal de cada cluster já tem essa função concedida por padrão. A função `rds_superuser_role` inclui os seguintes privilégios para todos os objetos de banco de dados: + `ALTER` + `APPLICATION_PASSWORD_ADMIN` + `ALTER ROUTINE` + `CONNECTION_ADMIN` + `CREATE` + `CREATE ROLE` + `CREATE ROUTINE` + `CREATE TEMPORARY TABLES` + `CREATE USER` + `CREATE VIEW` + `DELETE` + `DROP` + `DROP ROLE` + `EVENT` + `EXECUTE` + `FLUSH_OPTIMIZER_COSTS` (Aurora MySQL versão 3.09 e posterior) + `FLUSH_STATUS` (Aurora MySQL versão 3.09 e posterior) + `FLUSH_TABLES` (Aurora MySQL versão 3.09 e posterior) + `FLUSH_USER_RESOURCES` (Aurora MySQL versão 3.09 e posterior) + `INDEX` + `INSERT` + `LOCK TABLES` + `PROCESS` + `REFERENCES` + `RELOAD` + `REPLICATION CLIENT` + `REPLICATION SLAVE` + `ROLE_ADMIN` + `SET_USER_ID` + `SELECT` + `SHOW DATABASES` + `SHOW_ROUTINE` (Aurora MySQL versão 3.04 e posterior) + `SHOW VIEW` + `TRIGGER` + `UPDATE` + `XA_RECOVER_ADMIN` A definição da função também inclui `WITH GRANT OPTION`, permitindo que um usuário administrativo a conceda para outros usuários. Em particular, o administrador deve conceder quaisquer privilégios necessários para executar a replicação de logs binários com o cluster do Aurora MySQL como destino. **dica** Para visualizar os detalhes completos das permissões, insira as seguintes instruções. ``` SHOW GRANTS FOR rds_superuser_role@'%'; SHOW GRANTS FOR name_of_administrative_user_for_your_cluster@'%'; ``` ### Usuário de verificação de privilégios para replicação de logs binários. O Aurora MySQL versão 3 inclui um usuário de verificação de privilégios para replicação de logs binários (binlog), `rdsrepladmin_priv_checks_user`. Além dos privilégios de `rds_superuser_role`, esse usuário tem o privilégio `replication_applier`. Quando você ativa a replicação do log binário chamando o procedimento armazenado `mysql.rds_start_replication`, `rdsrepladmin_priv_checks_user` é criado. O usuário `rdsrepladmin_priv_checks_user@localhost` é reservado. Não o modifique. ### Perfis para acessar outros serviços da AWS O Aurora MySQL versão 3 inclui perfis que podem ser usados para acessar outros serviços da AWS. É possível definir muitos desses perfis como uma alternativa à concessão de privilégios. Por exemplo, especifique `GRANT AWS_LAMBDA_ACCESS TO user` no lugar de `GRANT INVOKE LAMBDA ON *.* TO user`. Para conhecer os procedimentos para acessar outros serviços da AWS, consulte [Integração do Amazon Aurora MySQL com outros produtos da AWS](AuroraMySQL.Integrating.md). O Aurora MySQL versão 3 inclui as seguintes funções relacionadas ao acesso a outros serviços da AWS: + `AWS_LAMBDA_ACCESS`: alternativa ao privilégio `INVOKE LAMBDA`. 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_LOAD_S3_ACCESS`: alternativa ao privilégio `LOAD FROM S3`. 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). + `AWS_SELECT_S3_ACCESS`: alternativa ao privilégio `SELECT INTO S3`. 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). + `AWS_COMPREHEND_ACCESS`: alternativa ao privilégio `INVOKE COMPREHEND`. Para ter mais informações, consulte [Conceder aos usuários de banco de dados acesso ao machine learning do Aurora](mysql-ml.md#aurora-ml-sql-privileges). + `AWS_SAGEMAKER_ACCESS`: alternativa ao privilégio `INVOKE SAGEMAKER`. Para ter mais informações, consulte [Conceder aos usuários de banco de dados acesso ao machine learning do Aurora](mysql-ml.md#aurora-ml-sql-privileges). + `AWS_BEDROCK_ACCESS`: não há privilégio `INVOKE` análogo para o Amazon Bedrock. Para ter mais informações, consulte [Conceder aos usuários de banco de dados acesso ao machine learning do Aurora](mysql-ml.md#aurora-ml-sql-privileges). Quando você concede acesso utilizando funções no Aurora MySQL versão 3, também ativa a função utilizando a instrução `SET ROLE role_name` ou `SET ROLE ALL`. O exemplo a seguir mostra como. Substitua o nome da função apropriado para `AWS_SELECT_S3_ACCESS`. ``` # Grant role to user. mysql> GRANT AWS_SELECT_S3_ACCESS TO 'user'@'domain-or-ip-address' # Check the current roles for your user. In this case, the AWS_SELECT_S3_ACCESS role has not been activated. # Only the rds_superuser_role is currently in effect. mysql> SELECT CURRENT_ROLE(); +--------------------------+ | CURRENT_ROLE() | +--------------------------+ | `rds_superuser_role`@`%` | +--------------------------+ 1 row in set (0.00 sec) # Activate all roles associated with this user using SET ROLE. # You can activate specific roles or all roles. # In this case, the user only has 2 roles, so we specify ALL. mysql> SET ROLE ALL; Query OK, 0 rows affected (0.00 sec) # Verify role is now active mysql> SELECT CURRENT_ROLE(); +-----------------------------------------------------+ | CURRENT_ROLE() | +-----------------------------------------------------+ | `AWS_SELECT_S3_ACCESS`@`%`,`rds_superuser_role`@`%` | +-----------------------------------------------------+ ``` ## Localização do ID do servidor do banco de dados O ID do servidor do banco de dados (`server_id`) é necessário para a replicação de log binário (binlog). A forma de encontrar o ID do servidor é diferente no Aurora MySQL e no MySQL Community. No MySQL Community, o ID do servidor é um número, que você obtém usando a seguinte sintaxe enquanto está conectado ao servidor: ``` mysql> select @@server_id; +-------------+ | @@server_id | +-------------+ | 2 | +-------------+ 1 row in set (0.00 sec) ``` No Aurora MySQL, o ID do servidor é o ID da instância de banco de dados, que você obtém usando a seguinte sintaxe enquanto está conectado à instância de banco de dados: ``` mysql> select @@aurora_server_id; +------------------------+ | @@aurora_server_id | +------------------------+ | mydbcluster-instance-2 | +------------------------+ 1 row in set (0.00 sec) ``` Para obter mais 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). ## Autenticação No MySQL 8.0 edição da comunidade, o plugin de autenticação padrão é `caching_sha2_password`. O Aurora MySQL versão 3 ainda utiliza o plugin `mysql_native_password`. Você não pode alterar a configuração `default_authentication_plugin`. No entanto, você pode criar usuários e alterar os usuários atuais, e as senhas individuais deles usarão o novo plug-in de autenticação. Veja um exemplo a seguir. ``` mysql> CREATE USER 'testnewsha'@'%' IDENTIFIED WITH caching_sha2_password BY 'aNewShaPassword'; Query OK, 0 rows affected (0.74 sec) ``` # Fazer upgrade para o Aurora MySQL versão 3 Para ter informações sobre como atualizar o banco de dados do Aurora MySQL versão 2 para a versão 3, consulte [Realizar a atualização da versão principal de um cluster de bancos de dados do Amazon Aurora MySQL](AuroraMySQL.Updates.MajorVersionUpgrade.md).