Problemas conhecidos e limitações do Amazon RDS for MySQL
Veja a seguir os problemas e as limitações conhecidos no trabalho com o Amazon RDS for MySQL.
Tópicos
- Palavra reservada InnoDB
- Tamanho do grupo de buffers do InnoDB inconsistente
- A otimização de mesclagem índice retorna resultados errados
- Tamanho do arquivo de log
- Exceções de parâmetros do MySQL para instâncias de bancos de dados do Amazon RDS
- Limites de tamanho de arquivo do MySQL no Amazon RDS
- Não há suporte ao plugin Keyring do MySQL
Palavra reservada InnoDB
InnoDB
é uma palavra reservada para o RDS for MySQL. Você não pode usar esse nome para um banco de dados MySQL.
Tamanho do grupo de buffers do InnoDB inconsistente
Para o MySQL 5.7, existe atualmente um bug na forma como o tamanho do grupo de buffers do InnoDB é gerenciado. O MySQL 5.7 pode ajustar o parâmetro innodb_buffer_pool_size
para um valor muito grande, que pode fazer com que o grupo de buffers do InnoDB cresça demais e consuma muita memória. Esse efeito pode fazer com que o mecanismo de banco de dados MySQL pare de funcionar ou pode impedir que o mecanismo de banco de dados MySQL seja iniciado. Esse problema é mais comum para classes de instâncias de banco de dados que têm menos memória disponível.
Para resolver esse problema, defina o valor do parâmetro innodb_buffer_pool_size
como um múltiplo do produto do valor do parâmetro innodb_buffer_pool_instances
e do valor do parâmetro innodb_buffer_pool_chunk_size
. Por exemplo, você pode configurar o valor do parâmetro innodb_buffer_pool_size
como um múltiplo de oito vezes o produto dos valores dos parâmetros innodb_buffer_pool_instances
e innodb_buffer_pool_chunk_size
, conforme mostrado no exemplo a seguir.
innodb_buffer_pool_chunk_size = 536870912 innodb_buffer_pool_instances = 4 innodb_buffer_pool_size = (536870912 * 4) * 8 = 17179869184
Para obter detalhes sobre este bug do MySQL 5.7, acesse https://bugs.mysql.com/bug.php?id=79379
A otimização de mesclagem índice retorna resultados errados
As consultas que utilizam a otimização de mesclagem de índice podem retornar resultados incorretos devido a um bug no otimizador de consulta MySQL que foi introduzido no MySQL 5.5.37. Ao emitir uma consulta em uma tabela com vários índices, o otimizador verifica intervalos de linhas com base em vários índices, mas não mescla os resultados corretamente. Para obter mais informações sobre o bug do otimizador de consulta, acesse http://bugs.mysql.com/bug.php?id=72745
Por exemplo, considere uma consulta em uma tabela com dois índices em que os argumentos de pesquisa fazem referência às colunas indexadas.
SELECT * FROM table1 WHERE indexed_col1 = 'value1' AND indexed_col2 = 'value2';
Nesse caso, o mecanismo de pesquisa pesquisará ambos os índices. No entanto, devido ao erro, os resultados mesclados estão incorretos.
Para resolver esse problema, você pode realizar um dos seguintes procedimentos:
Defina o parâmetro
optimizer_switch
comoindex_merge=off
no grupo de parâmetros de banco de dados para a sua instância de banco de dados MySQL. Para obter informações sobre como definir os parâmetros do grupo de parâmetros de banco de dados, consulte Trabalhar com grupos de parâmetros.-
Atualize sua instância de banco de dados MySQL para o MySQL versões 5.6, 5.7 ou 8.0. Para obter mais informações, consulte Atualização para um snapshot de banco de dados MySQL.
-
Se você não puder atualizar sua instância ou alterar o parâmetro
optimizer_switch
, poderá contornar o bug identificando explicitamente um índice para a consulta, por exemplo:SELECT * FROM table1 USE INDEX covering_index WHERE indexed_col1 = 'value1' AND indexed_col2 = 'value2';
Para obter mais informações, acesse Index merge optimization
Tamanho do arquivo de log
Para o MySQL, há um limite de tamanho em BLOBs gravados no log redo. Para considerar este limite, certifique-se de que o parâmetro innodb_log_file_size
da sua instância de banco de dados MySQL seja 10 vezes maior que o maior tamanho de dados BLOB encontrado nas suas tabelas, mais o comprimento de outros campos de comprimento variável (VARCHAR
, VARBINARY
, TEXT
) nas mesmas tabelas. Para obter informações sobre definir valores de parâmetros, consulte Trabalhar com grupos de parâmetros. Para obter mais informações sobre o limite de tamanho do BLOB de logs redo, acesse o tópico sobre Alterações no MySQL 5.6.20
Exceções de parâmetros do MySQL para instâncias de bancos de dados do Amazon RDS
Alguns parâmetros do MySQL requerem considerações especiais quando usados com uma instância de banco de dados do Amazon RDS.
lower_case_table_names
Como o Amazon RDS usa um sistema de arquivos que diferencia maiúsculas de minúsculas, não há suporte para definir o valor do parâmetro de servidor lower_case_table_names
como 2 ("nomes armazenados conforme especificados, mas comparados em minúsculas"). Veja a seguir os valores compatíveis com as instâncias de banco de dados do Amazon RDS for MySQL:
-
0 ("nomes armazenados como dados e as comparações diferenciam maiúsculas de minúsculas") é compatível com todas as versões do Amazon RDS for MySQL.
-
1 (“nomes armazenados em letras minúsculas e comparações não diferenciam maiúsculas de minúsculas”) é compatível com o Amazon RDS for MySQL versões 5.6, 5.7 e versões 8.0.19 e posteriores.
Defina o parâmetro lower_case_table_names
em um grupo de parâmetros de banco de dados personalizado antes de criar uma instância de banco de dados. Em seguida, especifique o grupo de parâmetros de banco de dados personalizado ao criar a instância de banco de dados.
Quando um grupo de parâmetros é associado a uma instância de banco de dados MySQL com uma versão inferior a 8.0, recomendamos que você evite alterar o parâmetro lower_case_table_names
no grupo de parâmetros. Essa ação poderia causar inconsistências com backups de recuperação point-in-time e instâncias de bancos de dados de réplica de leitura.
Quando um grupo de parâmetros é associado a uma instância de banco de dados MySQL versão 8.0, não é possível modificar o parâmetro lower_case_table_names
no grupo de parâmetros.
Réplicas de leitura sempre devem usar o mesmo valor de parâmetro lower_case_table_names
que a instância de banco de dados de origem.
long_query_time
Você pode definir o parâmetro long_query_time
como um valor de ponto flutuante que permita registrar consultas lentas no log de consultas lentas do MySQL com resolução de microssegundos. Você pode definir um valor como 0,1 segundos, que seria de 100 milissegundos, para ajudar ao depurar transações lentas que demoram menos de um segundo.
Limites de tamanho de arquivo do MySQL no Amazon RDS
Para instâncias de bancos de dados MySQL, o limite de armazenamento máximo provisionado restringe o tamanho de uma tabela a um máximo de 16 TB ao usar espaços de tabela de arquivo por tabela do InnoDB. Esse limite também restringe o espaço de tabela do sistema a um tamanho máximo de 16 TB. Os espaços de tabelas de arquivo por tabela do InnoDB (com cada tabela em seu próprio espaço de tabela) são definidos por padrão para instâncias de bancos de dados MySQL.
Algumas instâncias de Banco de Dados existentes têm um limite menor. Por exemplo, as instâncias de banco de dados MySQL criadas antes de abril de 2014 têm um limite de tamanho de arquivo e de tabela de 2 TB. Esse limite de tamanho de arquivo de 2 TB também se aplica a instâncias de banco de dados ou a réplicas de leitura criadas de snapshots de banco de dados tirados antes de abril de 2014, independentemente de quando a instância de banco de dados foi criada.
Existem vantagens e desvantagens na utilização de espaços de tabela de arquivo por tabela do InnoDB, dependendo do seu aplicativo. Para determinar a melhor abordagem para a aplicação, acesse File-per-table tablespaces
Não recomendamos permitir que as tabelas cresçam até o tamanho máximo do arquivo. Em geral, uma prática recomendada é particionar dados em tabelas menores, o que pode melhorar a performance e os tempos de recuperação.
Uma opção que você pode usar para dividir uma tabela grande em tabelas menores é o particionamento. O particionamento distribui partes da sua tabela grande em arquivos separados com base em regras que você especifica. Por exemplo, se você armazenar transações por data, poderá criar regras de particionamento que distribuem transações antigas em arquivos separados usando o particionamento. Em seguida, periodicamente, você pode arquivar os dados históricos de transações que não precisam estar prontamente disponíveis para o seu aplicativo. Para obter mais informações, acesse Partitioning
Para determinar o tamanho do arquivo de uma tabela
-
Use o seguinte comando SQL para determinar se algumas das suas tabelas são muito grandes e são candidatas para particionamento.
SELECT TABLE_SCHEMA, TABLE_NAME, round(((DATA_LENGTH + INDEX_LENGTH) / 1024 / 1024), 2) As "Approximate size (MB)" FROM information_schema.TABLES WHERE TABLE_SCHEMA NOT IN ('mysql', 'information_schema', 'performance_schema');
Para habilitar espaços de tabela de arquivo por tabela do InnoDB
-
Para habilitar espaços de tabela de arquivo por tabela do InnoDB, defina o parâmetro innodb_file_per_table como
1
no grupo de parâmetros da instância de banco de dados.
Para desabilitar espaços de tabela de arquivo por tabela do InnoDB
-
Para desabilitar espaços de tabela de arquivo por tabela do InnoDB, defina o parâmetro innodb_file_per_table como
0
no grupo de parâmetros da instância de banco de dados.
Para obter informações sobre como atualizar um grupo de parâmetros, consulte Trabalhar com grupos de parâmetros.
Quando tiver habilitado ou desabilitado espaços de tabelas de arquivo por tabela do InnoDB, você poderá emitir um comando ALTER
TABLE
para mover uma tabela do espaço de tabela global para seu próprio espaço de tabela, ou do seu próprio espaço de tabela para o espaço de tabela global, conforme mostrado no exemplo a seguir:
ALTER TABLE table_name ENGINE=InnoDB;
Não há suporte ao plugin Keyring do MySQL
No momento, o Amazon RDS for MySQL não oferece suporte ao plugin Keyring keyring_aws
da Amazon Web Services do MySQL.