Database
 sql >> Base de Dados >  >> RDS >> Database

Alterar na tabela grande na solução RDS para tabela cheia de erro

Alterar na mesa grande no RDS Solução para o erro da tabela cheia. Vamos dar um exemplo, Tabelas que são muito grandes (~> 100 GB a 600 GB). Fazer alterações em tabelas tão grandes é HIGH memória e tarefa intensiva da CPU. Quando você tenta alterar a consulta em uma das tabelas, deu "ERRO 1114 (HY000):tabela cheia ” erro…

Por que esse problema ocorreu, embora o volume de armazenamento do Amazon Aurora aumente automaticamente para 64 TB.?

Primeiro, entenderemos o armazenamento no RDS Aurora. Existem 2 tipos de armazenamento no Aurora. Armazenamento de instâncias é o armazenamento local onde os objetos temporários são armazenados e o armazenamento principal para dados. Portanto, quando você executa ALTER em uma tabela, ele gera uma tabela temporária e o RDS aurora usaria o armazenamento de instância para armazenar a tabela temporária. Para sua instância, que é a instância db.r3.large, ela tem 1 × 32 GB de armazenamento local. Portanto, se os objetos temporários na instância forem maiores que esse tamanho, você receberá o erro "tabela cheia". Além disso, o limite de armazenamento local é diferente do volume de armazenamento total disponível para sua instância do Aurora e com base no uso do banco de dados, o volume de armazenamento do Amazon Aurora aumentará automaticamente, até 64 TB, em incrementos de 10 GB.

Alterar na mesa grande no RDS  solução para tabela cheia de erro

  1. Para superar o problema, você pode dimensionar a instância para obter mais armazenamento local para executar seu ALTER, alterar a tabela e reduzir o tipo de instância. Isso resulta em algum tempo de inatividade durante o tipo de instância de upgrade/downgrade.
  2. Você também pode usar:comando “pt-online-schema-change”, se você usar este comando, ele torna a tabela original ainda disponível para uso sem tempo de inatividade ou nenhum bloqueio de mesa.
Se você não puder ter tempo de inatividade no sistema, use o comando pt-online-schema-change em vez de dimensionar a instância. No entanto, a documentação de pt-online-schema-change  diz, devemos fazer um backup antes de executar este comando. Portanto, para evitar bloqueios e falhas de tabela durante a alteração da tabela de produção, você pode testar esse comando em uma cópia exata do banco de dados do aplicativo, com o mesmo tipo de instância do RDS. Além disso, tente adicionar uma carga de gravação pesada na tabela para imitar o tráfego . Para conseguir isso, crie um script bash que insira continuamente uma nova linha na tabela. Para ter uma cópia exata rápida do seu banco de dados atual, tire um snapshot do RDS DB e restaure-o do snapshot para teste.  Antes de executar este comando, precisamos definir log_bin_trust_function_creators como 1 no grupo de parâmetros de banco de dados RDS. Depois de terminar o processo ALTER, você pode alterar a variável para “0” novamente.
Resultados:
Se você estiver alterando a tabela com pt -online-schema-change  comando ativado  uma tabela que tenha o tamanho de 35 a 40 GB, pode levar cerca de 30 horas.

Por que usar o comando pt-online-schema-change e por que ativar  “log_bin_trust_function_creators “  no grupo de parâmetros de banco de dados? ?

pt-online-schema-change  não trava a mesa. Este comando cria triggers na tabela original. Mas para isso, precisa de privilégios de superusuário. quando você está usando o procedimento de armazenamento, você receberá o erro:
#1419 – Você não tem o privilégio SUPER e o log binário está ativado (você *pode* querer usar a variável log_bin_trust_function_creators menos segura
Motivo:  Este erro ocorre em instâncias do RDS quando você tenta usar “procedimentos armazenados”. Você logo descobrirá que conceder o super privilégio para um usuário não funcionará. Portanto, a única maneira de fazer as coisas funcionarem é definir log_bin_trust_function_creators como 1.   De acordo com os documentos da Percona: A conclusão é que a criação de gatilhos em um servidor com logs binários ativados requer um usuário com privilégios SUPER (o que é impossível no Amazon RDS). A mensagem de erro especifica a solução alternativa. Precisamos habilitar a variável no grupo de parâmetros do banco de dados “ log_bin_trust_function_creators”. Habilitá-lo é como dizer ao servidor: "Confio nos gatilhos e funções dos usuários comuns e que eles não causarão problemas, então permita que meus usuários os criem." Como a funcionalidade do banco de dados não muda, torna-se uma questão de confiar em seus usuários. log_bin_trust_function_creators é uma variável global que pode ser alterada dinamicamente. Tentando encontrar mais detalhes sobre “Super_priv”, quando você verifica as permissões dos usuários na tabela de usuários do banco de dados MySQL. você pode ver que o Super_priv não está definido para ninguém, exceto o usuário rdsadmin. 
MySQL> select User,Super_priv from user;
+-----------+------------+
| User | Super_priv |
+-----------+------------+
| rdsadmin | Y |
| root | N |
| dbuser | N |
+-----------+------------+
3 rows in set (0.00 sec)

Aqui “root” é o usuário mestre e “dbuser” é o usuário do banco de dados, esses usuários são criados por nós e o usuário “rdsadmin” é criado automaticamente pela AWS ao qual não temos acesso a esse usuário. O usuário rdsadmin MySQL é usado pela Amazon para manutenção e trabalho de gerenciamento.

Este é o final do tutorial, como Alter on Big Table in RDS Solution to table full Error.