Início / dba / Perguntas / 52364
Accepted
ethrbunny
Asked: 2013-10-29 12:09:44 +0800 CST

MySQL: todos os procedimentos armazenados foram excluídos?

  • 772

Comecei a ver alguns erros estranhos de processos dependentes esta manhã. Após algumas pesquisas, parece que o arquivo /mysql/proc.MYD está configurado para comprimento zero. O arquivo /mysql/db.MYD parece estar truncado também.

O que é ainda mais interessante é que esse não é o caso do escravo replicado.

  1. O que causaria isso?
  2. Por que não apareceria no servidor escravo?
  3. Se eu copiar os arquivos /mysql/proc* do escravo de volta para o mestre - isso restaurará os procedimentos?

Quase todos os arquivos na pasta /mysql foram tocados ao mesmo tempo. Alguns foram alterados, enquanto muitos não foram. Meu primeiro pensamento é que é uma falha no sistema de arquivos, mas parece estar localizada nesta pasta.

EDIT: Detalhes pertinentes:

RHEL 5.x
MySQL 5.5

Desativei as duas instâncias do MySQL e estou tentando tirar a pasta MySQL da fita. Eu executaria fsck no volume, mas a página do manual tem alguns avisos bastante assustadores.

mysql stored-procedures

1 respostas

  1. Best Answer

    O curso de ação mais seguro é parar o MySQL em ambas as máquinas e copiar os arquivos de tabela que você precisa do mysqlesquema do escravo para o mestre, salvando cópias dos arquivos. Desde que sejam tabelas MyISAM (não InnoDB), esta é uma operação legítima.

    Se você não conseguir desligar as máquinas, conecte-se a ambas e execute, FLUSH TABLES WITH READ LOCK;aguarde o prompt retornar e, em seguida, deixe as conexões abertas (para manter os bloqueios) enquanto copia os arquivos. Em seguida, UNLOCK TABLES;para liberar o bloqueio global de leitura. As tabelas MyISAM são bastante flexíveis desta forma... você precisa copiar os arquivos MYD e MYI para as tabelas, juntos em pares, e você provavelmente deve copiar os arquivos .frm correspondentes na chance de que eles não sejam idênticos (embora eles deveria ser)... apenas salve cópias de qualquer coisa que você sobrescrever e não tente fazer isso com tabelas InnoDB.

    Isso deve restaurar os procedimentos; pode ser necessário reiniciar o servidor para que eles sejam reconhecidos por todos os threads (mas acho que não).

    Se as alterações nas tabelas mysqlnormalmente se replicam em sua configuração, isso tende a sugerir problemas subjacentes no sistema ... ou outra pessoa com acesso ao sistema sem saber o que está fazendo ... ou uma possível violação de segurança e, infelizmente, nenhuma Uma dessas coisas realmente salta para mim como mais provável do que qualquer outra, embora meu instinto seja "suspeitar de malícia".

    Já que você tem o registro binário habilitado, você deve revisar os binlogs do período de tempo que os timestamps sugerem usar mysqlbinlog --verbose --base64-output=decode-rows, pois mesmo que o escravo não tenha alterado suas tabelas, isso não significa que não possa haver algo interessante no binlog que alterou outra coisa que você ainda não descobriu ou que não teve o mesmo impacto no escravo por vários outros motivos, como replicate-ignore-db.

    Eu verificaria todo o conteúdo da tabela de concessões junto com todo o resto do mysqlesquema. Eu também reconfiguraria os servidores com log_warnings = 2, que registra erros de acesso negado, e posso até ficar tentado a ativar o log de consulta geral por um tempo se o seu sistema tiver a capacidade de E/S para suportar isso sem penalidade de desempenho. Eu configuraria ainda mais a máquina local para encaminhar uma cópia de suas mensagens syslog para outro sistema com acesso estritamente restrito e auditar completamente o firewall ... tudo isso soa um pouco alarmista, mas sem alguma outra evidência de problemas no sistema de arquivos , isso certamente não pode ser considerado a coisa mais provável de ter acontecido.

    • 1

relate perguntas