Início / dba / Perguntas / 6271
Accepted
geoaxis
Asked: 2011-09-29 08:33:02 +0800 CST

Envenenamento do banco de dados MySQL: como recuperar rapidamente para um estado conhecido

  • 772

Se você deseja evitar o envenenamento do banco de dados (ou seja, deseja recuperar rapidamente um ponto no tempo), qual metodologia você prefere?

Deixe-me definir envenenamento de dados. Você insere algumas coisas em seu banco de dados que bagunçam totalmente a estrutura interna e as interdependências. Eu sei que isso significa que o design do banco de dados provavelmente também precisa ser revisto, mas o estrago está feito.

Os métodos que tenho em mente são

  1. De alguma forma, configure a replicação na qual o escravo é passivo e está X horas atrasado. Se eu tiver uma falha, tudo o que preciso fazer é redefinir o aplicativo e apontá-lo para o escravo como meu novo mestre. Eu suspeito que seja possível.
  2. Faça um hot backup do MySQL a cada poucas horas e quando a falha for detectada, restaure para um backup de X horas antes. Isso significaria um tempo de inatividade para o aplicativo, pois não posso permitir que o aplicativo atual continue em execução. Pode-se usar innobackup ou percona para etapas rápidas de backup e recuperação.
  3. Projete o aplicativo e o banco de dados especificamente para que os dados recém-adicionados sejam destruídos (ou arquivados). Isso significa que armazeno todos os eventos/estados (acho que essa é a solução mais difícil e teórica)

Se a primeira opção for possível e também armazenar todos os logs de retransmissão (ou seja, o que já aconteceu no mestre é transferido para o escravo no mesmo instante, mas é aplicado automaticamente em algumas horas), então seria uma solução perfeita. Talvez alguém possa configurar vários escravos em uma configuração para se recuperar de uma interrupção e envenenamento de dados

mysql replication

4 respostas

  1. Best Answer

    Você pode usar a ferramenta pt-slave-delay do Percona Toolkit para manter uma réplica atrasada pelo tempo que você escolher.

    • 5

  2. Eu normalmente configuro um slave especificamente para backups. Dessa forma eu posso STOP SLAVE, fazer backup e START SLAVE. Fazer esse método permitiria que você fizesse quantos backups desejasse durante o dia sem tempo de inatividade em seu mestre.

    Se você quiser, pode desligar o escravo manualmente depois que ele recuperar os logs. Você teria algum tempo de inatividade copiando-o de volta para o mestre, mas então você pode reproduzir os logs binários até o ponto em que seus dados foram 'envenenados'.

    • 2

  3. Você definitivamente precisará de Master/Master e o uso de um DBVIP

    Primeiro, vamos configurar a replicação circular

    Deixe db1: Mestre, db2: Escravo

    1. Use o db1 existente como mestre
    2. instale o mysql no db2 (mesma versão aon db1 e db2)
    3. verifique se o mysql não está sendo executado no db2
      • Adicionar server-id=1a db1:/etc/my.cnf
      • Adicionar log-bin=mysql-bina db1:/etc/my.cnf
      • Adicionar log-slave-updatesa db1:/etc/my.cnf
      • Adicionar skip-slave-starta db1:/etc/my.cnf
      • service mysql restartem db1
    4. copiar db1:/etc/my.cnf para db2:/etc/my.cnf
    5. mude server-id=1para server-id=2db2:/etc/my.cnf
    6. RESET MASTER;em db1
    7. service mysql stopem db1
    8. rm -f /var/lib/mysql/mysql-bin.* no db1
    9. rsync db1:/var/lib/mysql para db2:/var/lib/mysql
    10. service mysql startno db2
    11. CHANGE MASTER TO MASTER_HOST='HostIP of db1',MASTER_PORT=3306, MASTER_USER='replusername',MASTER_PASSWORD='replpassword', MASTER_LOG_FILE='mysql-bin.000001',MASTER_LOG_POS=<number>;no db2 (Nota: MASTER_LOG_POS é 98 antes do MySQL 5.1, 106 para MySQL 5.1 e 107 para MySQL 5.5)
    12. service mysql startno db2
    13. START SLAVE;no db2 e deixe a recuperação da replicação (Seconds_Behind_Master=0)
    14. CHANGE MASTER TO MASTER_HOST='HostIP of db2',MASTER_PORT=3306, MASTER_USER='replusername',MASTER_PASSWORD='replpassword', MASTER_LOG_FILE='mysql-bin.000001',MASTER_LOG_POS=<number>;em db1
    15. START SLAVE;no db1 e deixe a replicação recuperar (Seconds_Behind_Master=0)

    Depois de ter a replicação circular instalada, agora você pode congelar o db2 em um determinado ponto no tempo executando STOP SLAVE;no db2

    Em seguida, crie um DBVIP no db1 (Exemplo: 192.168.10.1)

    ip addr add 192.168.10.1/24 dev eth1

    Execute todas as leituras e gravações de banco de dados usando DBVIP

    Se você deseja que o db2 seja atualizado, simplesmente execute START SLAVE;no db2 e deixe a replicação recuperar.

    Se você quiser voltar no tempo para o ponto em que o DB2 estava, você pode executar as etapas

    • service mysql stopem db1
    • rm -f mysql-bin.*em db1
    • rm -f master.infoem db1
    • ip addr del 192.168.10.1/24 dev eth1em db1
    • ip addr add 192.168.10.1/24 dev eth1no db2
    • CHANGE MASTER TO MASTER_HOST='';no db2
    • RESET MASTERno db2 (logs binários de mangueiras)
    • service mysql stopno db2
    • rsync db2:/var/lib/mysql para db1:/var/lib/mysql
    • service mysql startno db2
    • service mysql startem db1

    O If poderia acelerar essas etapas ignorando o desligamento do mysql do servidor de banco de dados do qual você está sincronizando. Isso requer apenas uma pequena limpeza extra no servidor de destino do banco de dados.

    Essas etapas são simplesmente guias. Você pode achar alguns dos meus passos um pouco paranóicos. Fique à vontade para usar o que quiser.

    • 1

  4. Outra opção, além de usar a ferramenta pt-slave-delay da Percona, é configurar a tabela de histórico/auditoria para cada tabela base, que rastrearia todas as alterações no conteúdo dos dados e conteria registros de inserção, atualização e exclusão e registros de data e hora e conteúdo real. Você precisaria criar gatilhos que disparassem em cada instrução de inserção, atualização e exclusão e, em seguida, insere na(s) tabela(s) de histórico/auditoria. Para reverter o dano, você leria as tabelas de histórico/auditoria e aplicaria as alterações nas tabelas básicas.

    Por exemplo, DBIx::Class::Journal é um módulo perl que implementa esse tipo de esquema automaticamente do lado do código. Se você visitar a URL, verá que este módulo se aprofunda bastante na captura de alterações de conteúdo de dados. O esquema do diário contém tabelas como:

    ChangeSet
ChangeLog
AuditLog
AuditHistory

    Para sua configuração, você pode querer começar com apenas uma tabela de histórico para cada tabela base.

    • 0

relate perguntas