Tenho uma instância do MariaDB ( 10.6.8
) hospedada no Amazon RDS ( db.m6g.4xlarge
). Ele tinha atualizações secundárias automáticas habilitadas, o que infelizmente causou horas de inatividade na última vez em que foi acionado.
Ao revisar os logs, parece que o problema era que algumas de nossas maiores tabelas precisavam ser reconstruídas antes que a atualização pudesse ser feita.
error : Table rebuild required. Please do "ALTER TABLE 'my_table' FORCE" or dump/reload to fix it!
Cada um estava levando várias horas. O maior tem aproximadamente 170 milhões de linhas e 20 colunas.
Na pior das hipóteses, podemos agendar o tempo de inatividade, eu acho. Mas se houver alguma maneira de fazer as coisas de maneira diferente para que isso não seja um problema daqui para frente, seria preferível.
Até agora, investiguei:
- Adicione a remoção para evitar manter dados antigos e desnecessários em algumas dessas tabelas. Isso os torna pequenos o suficiente para que a reconstrução não cause horas de inatividade
- No futuro, fazer e agendar minhas próprias atualizações secundárias, executar
mysqlcheck
com antecedência e, pelo menos, saber de antemão quais tabelas podem precisar ser reconstruídas. Isso ainda não é o ideal porque oALTER TABLE 'my_table' FORCE
comando bloqueia a tabela, o que obviamente também causa tempo de inatividade para nosso aplicativo - Presuma que é improvável que a reconstrução da tabela necessária ocorra novamente. Implemente uma reconstrução automatizada que selecione partes da tabela antiga e as insira em uma nova tabela até que seu conteúdo corresponda. Em seguida, exclua a tabela antiga e renomeie a nova tabela com o nome da antiga. Isso funcionaria - mas leva tempo e precisaria ser feito toda vez que uma tabela precisasse ser reconstruída
- Divida a(s) tabela(s) grande(s) logicamente em tabelas diferentes com o mesmo esquema. Se os padrões de acesso a dados não exigirem consultas de mais de um por vez, eu poderia limitar o bloqueio feito para uma reconstrução a uma tabela (menor) por vez, em vez de bloquear para reconstruir a tabela grande de uma só vez
Idealmente, eu gostaria de poder ativar as atualizações automáticas de versões secundárias novamente e "simplesmente funcionar" com o mínimo de tempo de inatividade em uma janela pré-selecionada.
Você pode usar uma ferramenta de alteração de esquema online, como pt-online-schema-change ou gh-ost, para executar uma reconstrução de tabela sem incorrer em tempo de inatividade.
No meu último trabalho, executamos centenas de comandos ALTER TABLE todas as semanas em instâncias de produção do MySQL durante o tráfego de pico, sem tempo de inatividade.
Essas ferramentas funcionam de maneira muito semelhante ao terceiro marcador da pergunta acima. Eles criam uma tabela de cópia e copiam blocos de linhas da tabela original para a nova tabela, o que efetivamente atualiza os tipos de dados e reconstrói índices. Enquanto isso, ele também monitora quaisquer novas alterações na tabela e também executa essas alterações na tabela de cópia. Isso leva mais tempo do que o método ALTER TABLE, mas como não bloqueia o tráfego de consulta em andamento e não causa nenhum tempo de inatividade, não é um problema.
Observe que eu disse "sem tempo de inatividade", mas na verdade há um breve momento no início e no final em que a ferramenta de alteração de esquema online precisa de acesso exclusivo à tabela. Se você tiver um fluxo ininterrupto de transações a cada momento, a ferramenta não poderá realizar seu trabalho.
Outra alternativa é criar uma réplica, fazer o upgrade na réplica. Isso leva horas, mas não importa se nenhum aplicativo depende da réplica. Em seguida, transforme a réplica atualizada na nova instância de origem e descomissione a instância de origem anterior.