Medo de FederatedÉ muito frustrante quando precisamos retornar um backup, e, fatalmente, descobrimos que o arquivo está corrompido ou até incompleto. Às vezes, mais do que frustração, esta prosaica situação pode vir acompanhada de prejuízos, aborrecimentos, demissões, e, outras chatices.

Portanto, cuidar dos backups é como cuidar de um investimento de longo prazo. É preciso acompanhar de perto… e com os dois olhos muito abertos!

Nunca é demais repetir o meu mantra do backup perfeito:

– Raid não é backup! Não adianta ter uma mega-hiper-super avançada controladora de discos e seus espelhamentos. Em caso de ‘DELETE’ ou ‘UPDATE’ acidental, sua controladora irá atualizar todos os discos em Dobra Máxima, e nem o Senhor Sulu irá lhe ajudar a reverter o processo.

– Múltiplos Slaves é mais do mesmo em caso de escritas acidentais. Pergunte ao Senhor Spock.

– Back Up dever ser encarado como uma política de segurança e continuidade de negócio composta de: processos rígidos, técnicas, equipamentos e pessoas. Processos descrevem como (tipo de backup: lógico/textual, binário, incremental, diferencial, total), quando e qual granularidade deve ser feito o backup e seu controle de qualidade. Técnicas quais recursos e elementos técnicos devem ser adotados. Equipamentos nos direciona para qual tipo de dispositivo local ou remoto será utilizado, e, Pessoas significa quem faz, quem confere, quem atua em caso de desastre.

Isto posto, vamos a um mistério que intrigava um amigo: o mistério do backup malcriado. Um mistério deveras intrigante. Vamos criar o cenário que eu encontrei, quando fui chamado para atuar como medium e espantar este fantasma.

  • SGBDR: MySQL 5.6.10
  • Storage Engine: InnoDB, Memory e Federated
  • Tamanho do Banco (dados+índices): 350GB
  • Política de Continuidade/Backup: Não havia
  • Segurança e Disponibilidade: Discos em Raid 1, Master – Slave e RH Cluster
  • Tipo de Backup: Somente Textual/Lógico com MySQLDump
  • Tamanho do Backup: 370GB
  • Tempo de Backup: 2h37s
  • Tempo de Restore: desconhecido

Existem vários erros, neste cenário, que podem e devem ser explorados. E, o serão em artigos posteriores. Neste artigo, vamos nos concentrar na encomenda de meu amigo: espantar o fantasma que fazia o backup parar sem explicação.

E este era o caso. O Backup parava, invariavelmente, inexplicavelmente. Às vezes completava com sucesso, e, tantas outras vezes não.

Regra de qualquer troubleshooting que se preze: PROCURE POR PADRÕES. E, foi exatamente isso que eu fiz. Procurei padrões, e, descobri que os backups, paravam, sempre com quantidade de bytes (tamanho) muito parecidos. Ao analisar o conteúdo do arquivo gerado pelo MySQLDump, notei, que sempre paravam num determinado grupo de tabelas. E, somente, nelas.

Ao buscar vascular usa estrutura, através do comando SHOW TABLE STATUS, veio à luz, duas constatações importantes:

  1. O Storage Engine das tabelas que corrompiam o backup, sem exceção, eram sempre do tipo FEDERATED
  2. Quando causavam a falha, no campo COMMENT lia-se a mensagem: “Got an error reading communication packets”

Esclarecimentos adicionais aos navegantes de primeira, segunda, e muitas viagens:

FEDERATED é um storage engine atípico. Em bom português uma tabela federada é uma imagem de uma tabela que existe em outro domínio, outra instância do mysql, em outro servidor. Criar uma tabela federada é um recurso jóia quando se precisa fazer um JOIN, por exemplo, em tabelas que estão em servidores diferentes.

GOT AN ERROR READING COMMUNICATION PACKETS é um erro comum no MySQL, e, via de regra é originado de uma falha de comunicação entre cliente e servidor. Neste caso, o servidor que continha as tabelas federadas (FEDERATED) era CLIENTE de outro servidor MySQL que continha as tabelas RAÍZ, que atuava como SERVIDOR.

Acontece que o servidor MySQL com as tabelas imagem (FEDERATED) estava distante, e, ligado via MPLS, ao servidor MySQL com as tabelas RAÍZ (neste caso INNODB). E, por algum motivo que depois foi questionado a provedora do acesso, a conexão MPLS falhava no período da madrugada, pouco antes da rotina de backup ser disparada.

Com a falha de conexão (que era intermitente), o MySQL cliente perdia a conexão com o MySQL servidor. Gerava o tal erro, e, durante o processo de backup (dump) ele abortava pois não conseguia se conectar ao MySQL servidor (RAÍZ) para fazer a backup dos dados das tabelas FEDERATED.

Na verdade, se houvesse log de backup, e, se houve verificação destes logs, notar-se-ia a mensagem: “mysqldump: Couldn’t execute ‘show table status like ‘historico_financeiro’: Got an error writing communication”. Para apimentar o problema, quando o mysqldump era gerado, na mão, durante o dia, o problema nunca aparecia.

Lições Aprendidas

  • Nunca, em hipótese alguma, faça backup de tabelas FEDERATED. Isso só vai gerar um tráfego de rede brutal e desnecessário. Estas tabelas devem ser “backupeadas” em seus devidos servidores (RAÍZ).
  • Conheça, gerencie e proteja  seu banco de dados, tamanhos, tempos, e o que acontece nele. Não deixe que qualquer um crie tabelas (e demais objetos) sem seu conhecimento (estas tabelas tinham sido criadas pelos desenvolvedores, sem participação do DBA).
  • Monitore seus backups: tenha logs (relatórios), tempos, e faça restores ao menos a cada 30 dias.
  • Não confie em uma única forma de backup. Por exemplo, faça backups textuais, mas, também binários. E nunca abra mão da dupla sertaneja mais famosa do mundo: Fullzão e Incremental.
  • Lembre-se sempre: “Backup e uma dose de covardia, mantém a conta corrente em dia”

Solução

  1. Resolvido o problema de conexão junto ao provedor
  2. Retirado do backup lógico todas as tabelas FEDERATED, através da colocação de várias linhas de configuração no my.cnf, com o parâmetro: ignore-table=banco.nome_da_tabela_federada
  3. Criado uma política (decente) de segurança e continuidade