Backups dos Bancos de Dados


Como as tabelas do MariaDB são armazenadas como arquivos, é mais fácil realizar um backup. Para obter um backup consistente, faça um LOCK TABLES nas tabelas relevantes seguido por FLUSH TABLES para as tabelas. Leia "Sintaxe LOCK TABLES e UNLOCK TABLES". Leia "Sintaxe de FLUSH". Você só precisa de um bloqueio de leitura; isto possibilita outras threads a continuarem a pesquisar nas tabelas enquanto você copia os arquivos no diretório do banco de dados. O FLUSH TABLE é necessário para garantir que todas as páginas ativas de índices serão escritas em disco antes de iniciar o backup.

A partir das versões 3.23.56 e 4.0.12 BACKUP TABLE não permitirá que você sobrescreva arquivos exixtentes já que isso colocaria em risco a segurança.

Se você desejar realizar um backup ao nível da linguagem SQL de um tabela, você pode utilizar SELECT INTO OUTFILE ou BACKUP TABLE. Leia "Sintaxe SELECT".See "Sintaxe de BACKUP TABLE".

Outra maneira de efetuar um backup de um banco de dados é utilizar o programa mysqldump ou o script mysqlhotcopy. Leia "mysqldump, Descarregando a Estrutura de Tabelas e Dados". Leia "mysqlhotcopy, Copiando Bancos de Dados e Tabelas do MariaDB".

  1. Fazer um backup completo do seu banco de dados: 
    shell> mysqldump --tab=/path/to/some/dir --opt db_name
ou shell> mysqlhotcopy db_name /path/to/some/dir

    Você também pode simplesmente copiar os arquivos das tabelas (*.frm, *.MYD) e os arquivos *.MYI) quando o servidor não estiver atualizando nada. O script mysqlhotcopy utiliza este método. (Mas nopte que estes métodos não funcionarão se seu banco de dados contém tabelas InnoDB. InnoDB não armazena o conteúdo das tabelas em diretórios de banco de dados, e o mysqlhotcopy funciona apenas para tabelas MyISAM e ISAM.)

  2. Interrompa o mysqld caso ele esteja em execução, depois inicie-o com a opção --log-bin[=nome_arquivo]. Leia "O Log Binário". Os arquivos de log binário fornecem a informação necessária para replicar alterações ao banco de dados que forem feitas depois do ponto em que você executou mysqldump.

Se o seu servidor MariaDB é um slave, seja qual for o método de backup que você escolha, quando você faz backup dos dados do slave, você deve também fazer backup dos arquivos master.info e relay-log.info que são necessários para continuar a replicação depois que você restaurar os dados do slave. Se seu slave está sujeito a replicação de comandos LOAD DATA INFILE, você também deve fazer backup dos arquivos SQL_LOAD-* que podem existir no diretório especificado pela opção slave-load-tmpdir. (A localização padrão desta opção é o valor da variável tmpdirse não especificado.) O slave precisará destes arquivos para continuar a replicação de qualquer LOAD DATA INFILE interrompido.

Se você necessita restaurar alguma coisa, tente primeiro recuperar suas tabelas utilizando REPAIR TABLE ou myisamchk -r. Isto deve funcionar em 99.9% de todos os caso, Se o myisamchk falhar, tente o seguinte procedimento: (Isto só irá funcionar se você iniciou o MariaDB com --log-update, veja "O Log Binário",):

  1. Restaure o backup original feito com o mysqldump ou backup binário.
  2. Execute o seguinte comando para re-executar as atualizações armazenadas no log binário: 
    shell> mysqlbinlog hostname-bin.[0-9]* | mysql

    Em seu caso você pode querer re-executar apenas alguns log binários, a partir de certas posiçõs (normalmente você quer re-executar todos os log binários a partir da data de restauração do backup, co exceção de algumas consultas erradas). Veja "mysqlbinlog, Executando as Consultas a Partir de um Log Binário" fpara mais informações sobre o utilitário mysqlbinlog e como usá-lo.

    Se você estiver utilizando o log atualizado, você pode executar o conteúdo do log de atualização desta forma: 

    shell> ls -1 -t -r hostname.[0-9]* | xargs cat | mysql

O comando ls é usado para obter todos os arquivos de log na ordem correta.

Você pode também fazer backups seletivos com SELECT * INTO OUTFILE 'nome_arquivo' FROM nome_tabela e restaurar com LOAD DATA INFILE 'nome_arquivo' REPLACE.... Para evitar registros duplicados, você precisará de um chave PRIMARY KEY ou uma UNIQUE na tabela. A palavra chave REPLACE substitui os antigos registros com os novos quando um novo registro duplica um antigo registro em uma chave de valores únicos.

Se você tiver problemas de performance realizando backups no seu sistema, você pode resolver isto configurando uma replicação e fazendo os backups na máquina slave no lugar da master. Leia "Introdução".

Se você estiver utilizando um sistema de arquivos Veritas, você pode fazer:

  1. Executar em um cliente (perl ?) FLUSH TABLES WITH READ LOCK
  2. Bifurcar uma shell ou executar em outro cliente mount vfxs snapshot.
  3. Executar no primeiro cliente UNLOCK TABLES
  4. Copiar arquivos do snapshot
  5. Desmontar snapshot

Retornar