MariaDB
 sql >> Base de Dados >  >> RDS >> MariaDB

Como executar e gerenciar backups MySQL para DBAs Oracle


A migração do banco de dados Oracle para o código aberto pode trazer vários benefícios. O custo de propriedade mais baixo é tentador e leva muitas empresas a migrar. Ao mesmo tempo, DevOps, SysOps ou DBA precisam manter SLAs rígidos para atender às necessidades de negócios.

Uma das principais preocupações ao planejar a migração de dados para outro banco de dados, especialmente de código aberto, é como evitar a perda de dados. Não é muito improvável que alguém tenha apagado acidentalmente parte do banco de dados, alguém esqueceu de incluir uma cláusula WHERE em uma consulta DELETE ou executou DROP TABLE acidentalmente. A questão é como se recuperar de tais situações.

Coisas assim podem e vão acontecer, é inevitável, mas o impacto pode ser desastroso. Como alguém disse:“É tudo diversão e jogos até que o backup falhe”. O ativo mais valioso não pode ser comprometido. Período.

O medo do desconhecido é natural se você não estiver familiarizado com as novas tecnologias. De fato, o conhecimento das soluções de banco de dados Oracle, a confiabilidade e os ótimos recursos que o Oracle Recovery Manager (RMAN) oferece podem desencorajar você ou sua equipe a migrar para um novo sistema de banco de dados. Gostamos de usar coisas que conhecemos, então por que migrar quando nossa solução atual funciona? Quem sabe quantos projetos foram suspensos porque a equipe ou o indivíduo não estavam convencidos sobre a nova tecnologia?

Backups lógicos (exp/imp, expdp/impdb)


De acordo com a documentação do MySQL, backup lógico é “um backup que reproduz a estrutura e os dados da tabela, sem copiar os arquivos de dados reais”. Essa definição pode ser aplicada aos mundos MySQL e Oracle. O mesmo é “por que” e “quando” você usará o backup lógico.

Os backups lógicos são uma boa opção quando sabemos quais dados serão modificados para que você possa fazer backup apenas da parte necessária. Ele simplifica a restauração potencial em termos de tempo e complexidade. Também é muito útil se precisarmos mover uma parte do conjunto de dados de tamanho pequeno/médio e copiá-lo de volta para outro sistema (geralmente em uma versão de banco de dados diferente). O Oracle usa utilitários de exportação como exp e expdp para ler os dados do banco de dados e exportá-los para um arquivo no nível do sistema operacional. Você pode então importar os dados de volta para um banco de dados usando os utilitários de importação imp ou impdp.

O Oracle Export Utilities nos oferece muitas opções para escolher quais dados precisam ser exportados. Você definitivamente não encontrará o mesmo número de recursos com o mysql, mas a maioria das necessidades é coberta e o resto pode ser feito com scripts adicionais ou ferramentas externas (verifique mydumper).

O MySQL vem com um pacote de ferramentas que oferece funcionalidades muito básicas. Eles são mysqldump, mysqlpump (a versão moderna do mysqldump que tem suporte nativo para paralelização) e cliente MySQL que pode ser usado para extrair dados para um arquivo simples.

Abaixo você pode encontrar vários exemplos de como usá-los:

Estrutura de banco de dados de backup apenas 
mysqldump --no-data -h localhost -u root -ppassword mydatabase > mydatabase_backup.sql

Estrutura da tabela de backup 
mysqldump --no-data --single- transaction -h localhost -u root -ppassword mydatabase table1 table2 > mydatabase_backup.sql

Fazer backup de linhas específicas 
mysqldump -h localhost --single- transaction -u root -ppassword mydatabase table_name --where="date_created='2019-05-07'" > table_with_specific_rows_dump.sql

Importando a Tabela 
mysql -u username -p -D dbname < tableName.sql

O comando acima interromperá o carregamento se ocorrer um erro.

Se você carregar dados diretamente do cliente mysql, os erros serão ignorados e o cliente prosseguirá 
mysql> source tableName.sql

Para registrar a saída, você precisa usar 
mysql> tee import_tableName.log

Você pode encontrar todas as bandeiras explicadas nos links abaixo:
  • https://dev.mysql.com/doc/refman/8.0/en/mysqldump.html
  • https://dev.mysql.com/doc/refman/8.0/en/mysqlimport.html
  • https://dev.mysql.com/doc/refman/8.0/en/mysql.html

Se você planeja usar o backup lógico em diferentes versões do banco de dados, certifique-se de ter a configuração de agrupamento correta. A instrução a seguir pode ser usada para verificar o conjunto de caracteres padrão e o agrupamento para um determinado banco de dados:
USE mydatabase;
SELECT @@character_set_database, @@collation_database;

Outra maneira de recuperar a variável de sistema collation_database é usar SHOW VARIABLES. 
SHOW VARIABLES LIKE 'collation%';

Devido às limitações do dump mysql, muitas vezes temos que modificar a saída. Um exemplo de tal modificação pode ser a necessidade de remover algumas linhas. Felizmente, temos a flexibilidade de visualizar e modificar a saída usando ferramentas de texto padrão antes de restaurar. Ferramentas como awk, grep, sed podem se tornar suas amigas. Abaixo está um exemplo simples de como remover a terceira linha do arquivo de despejo. 
sed -i '1,3d' file.txt

As possibilidades são infinitas. Isso é algo que não encontraremos no Oracle, pois os dados são escritos em formato binário.

Existem algumas coisas que você precisa considerar ao executar o mysql lógico. Uma das principais limitações é o suporte puro ao paralelismo e o travamento de objetos.

Considerações de backup lógico


Quando esse backup for executado, as etapas a seguir serão executadas.
  • LOCK TABLE table.
  • MOSTRAR tabela CREATE TABLE.
  • SELECT * FROM table INTO OUTFILE arquivo temporário.
  • Grave o conteúdo do arquivo temporário no final do arquivo de despejo.
  • DESBLOQUEAR TABELAS

Por padrão, o mysqldump não inclui rotinas e eventos em sua saída - você precisa definir explicitamente os sinalizadores --routines e --events.

Outra consideração importante é um mecanismo que você usa para armazenar seus dados. Espero que hoje em dia a maioria dos sistemas de produção use o mecanismo compatível com ACID chamado InnoDB. O mecanismo mais antigo MyISAM tinha que bloquear todas as tabelas para garantir a consistência. Isto é quando FLUSH TABLES WITH READ LOCK foi executado. Infelizmente, é a única maneira de garantir um instantâneo consistente das tabelas MyISAM enquanto o servidor MySQL está em execução. Isso fará com que o servidor MySQL se torne somente leitura até que UNLOCK TABLES seja executado.

Para tabelas no mecanismo de armazenamento InnoDB, é recomendável usar a opção --single- transaction. O MySQL então produz um ponto de verificação que permite que o dump capture todos os dados anteriores ao ponto de verificação enquanto recebe as alterações recebidas.

A opção --single-transaction do mysqldump não faz FLUSH TABLES WITH READ LOCK. Isso faz com que o mysqldump configure uma transação REPEATABLE READ para todas as tabelas sendo despejadas.

Um backup mysqldump é muito mais lento que as ferramentas Oracle exp, expdp. O Mysqldump é uma ferramenta de thread único e esta é sua desvantagem mais significativa - o desempenho é bom para bancos de dados pequenos, mas rapidamente se torna inaceitável se o conjunto de dados crescer para dezenas de gigabytes.
  • INICIAR TRANSAÇÃO COM INSTANTÂNEO CONSISTENTE.
  • Para cada esquema e tabela de banco de dados, um dump executa estas etapas:
    • MOSTRAR tabela CREATE TABLE.
    • SELECT * FROM table INTO OUTFILE arquivo temporário.
    • Grave o conteúdo do arquivo temporário no final do arquivo de despejo.
  • COMPROMETA-SE.

Backups físicos (RMAN)


Felizmente, a maioria das limitações do backup lógico pode ser resolvida com a ferramenta Percona Xtrabackup. O Percona XtraBackup é o software de backup a quente MySQL/MariaDB de código aberto mais popular que executa backups sem bloqueio para bancos de dados InnoDB e XtraDB. Ele se enquadra na categoria de backup físico, que consiste em cópias exatas do diretório de dados do MySQL e dos arquivos abaixo dele.

É a mesma categoria de ferramentas como Oracle RMAN. O RMAN vem como parte do software de banco de dados, o XtraBackup precisa ser baixado separadamente. O Xtrabackup está disponível como pacote rpm e deb e suporta apenas plataformas Linux. A instalação é muito simples:
$ wget https://www.percona.com/downloads/XtraBackup/Percona-XtraBackup-8.0.4/binary/redhat/7/x86_64/percona-XtraBackup-80-8.0.4-1.el7.x86_64.rpm
$ yum localinstall percona-XtraBackup-80-8.0.4-1.el7.x86_64.rpm

O XtraBackup não bloqueia seu banco de dados durante o processo de backup. Para bancos de dados grandes (100+ GB), ele oferece um tempo de restauração muito melhor em comparação com o mysqldump. O processo de restauração envolve a preparação de dados MySQL dos arquivos de backup, antes de substituí-los ou trocá-los pelo diretório de dados atual no nó de destino.

O Percona XtraBackup funciona lembrando o número de sequência de log (LSN) quando é iniciado e, em seguida, copiando os arquivos de dados para outro local. A cópia de dados leva algum tempo e, se os arquivos estiverem mudando, eles refletirão o estado do banco de dados em diferentes momentos. Ao mesmo tempo, o XtraBackup executa um processo em segundo plano que fica de olho nos arquivos de log de transações (também conhecido como redo log) e copia as alterações dele. Isso deve ser feito continuamente porque os logs de transação são gravados de forma round-robin e podem ser reutilizados após algum tempo. O XtraBackup precisa dos registros do log de transações para cada alteração nos arquivos de dados desde o início da execução.

Quando o XtraBackup estiver instalado, você poderá finalmente realizar seus primeiros backups físicos. 
xtrabackup --user=root --password=PASSWORD --backup --target-dir=/u01/backups/

Outra opção útil que os administradores do MySQL fazem é o streaming de backup para outro servidor. Tal stream pode ser realizado com o uso da ferramenta xbstream, como no exemplo abaixo:

Inicie um ouvinte no servidor externo na porta preferencial (neste exemplo 1984) 
nc -l 1984 | pigz -cd - | pv | xbstream -x -C /u01/backups

Execute o backup e transfira para um host externo 
innobackupex --user=root --password=PASSWORD --stream=xbstream /var/tmp | pigz  | pv | nc external_host.com 1984

Como você pode notar, o processo de restauração é dividido em duas etapas principais (semelhante ao Oracle). As etapas são restauradas (copiar de volta) e recuperação (aplicar log). 
XtraBackup --copy-back --target-dir=/var/lib/data
innobackupex --apply-log --use-memory=[values in MB or GB] /var/lib/data

A diferença é que só podemos realizar a recuperação até o ponto em que o backup foi feito. Para aplicar as alterações após o backup, precisamos fazê-lo manualmente.

Restauração pontual (recuperação RMAN)


No Oracle, o RMAN faz todos os passos quando realizamos a recuperação do banco de dados. Isso pode ser feito para SCN ou hora ou com base no conjunto de dados de backup. 
RMAN> run
{
allocate channel dev1 type disk;
set until time "to_date('2019-05-07:00:00:00', 'yyyy-mm-dd:hh24:mi:ss')";
restore database;
recover database; }

No mysql, precisamos de outra ferramenta para extrair dados de logs binários (semelhante aos archivelogs da Oracle) mysqlbinlog. mysqlbinlog pode ler os logs binários e convertê-los em arquivos. O que precisamos fazer é

O procedimento básico seria
  • Restaurar backup completo
  • Restaurar backups incrementais
  • Para identificar os horários de início e término da recuperação (que pode ser o fim do backup e o número da posição antes da tabela de descarte).
  • Converta os binglogs necessários para SQL e aplique os arquivos SQL recém-criados na sequência adequada - certifique-se de executar um único comando mysqlbinlog. 
    > mysqlbinlog binlog.000001 binlog.000002 | mysql -u root -p

Criptografar backups (Oracle Wallet)


O Percona XtraBackup pode ser usado para criptografar ou descriptografar backups locais ou de streaming com a opção xbstream para adicionar outra camada de proteção aos backups. Tanto a opção --encrypt-key quanto a opção --encryptkey-file podem ser usadas para especificar a chave de criptografia. As chaves de criptografia podem ser geradas com comandos como 
$ openssl rand -base64 24
$ bWuYY6FxIPp3Vg5EDWAxoXlmEFqxUqz1

Esse valor pode ser usado como a chave de criptografia. Exemplo do comando innobackupex usando a --encrypt-key:
$ innobackupex --encrypt=AES256 --encrypt-key=”bWuYY6FxIPp3Vg5EDWAxoXlmEFqxUqz1” /storage/backups/encrypted

Para descriptografar, basta usar a opção --decrypt com a --encrypt-key apropriada:
$ innobackupex --decrypt=AES256 --encrypt-key=”bWuYY6FxIPp3Vg5EDWAxoXlmEFqxUqz1”
/storage/backups/encrypted/2019-05-08_11-10-09/

Políticas de backup


Não há construção na funcionalidade de política de backup no MySQL/MariaDB ou mesmo na ferramenta da Percona. Se você deseja gerenciar seus backups lógicos ou físicos do MySQL, você pode usar o ClusterControl para isso.

ClusterControl é o sistema de gerenciamento de banco de dados de código aberto com tudo incluído para usuários com ambientes mistos. Ele fornece funcionalidade avançada de gerenciamento de backup para MySQL ou MariaDB.

Com o ClusterControl você pode:
  • Criar políticas de backup
  • Monitore o status de backup, execuções e servidores sem backups
  • Executar backups e restaurações (incluindo uma recuperação pontual)
  • Controlar a retenção de backup
  • Salvar backups no armazenamento em nuvem
  • Validar backups (teste completo com a restauração no servidor autônomo)
  • Criptografar backups
  • Compactar backups
  • E muitos outros
ClusterControl:Gerenciamento de backup

Mantenha backups na nuvem


As organizações têm implantado historicamente soluções de backup em fita como meio de proteger
dados contra falhas. No entanto, o surgimento da computação em nuvem pública também possibilitou novos modelos com TCO mais baixo do que o tradicionalmente disponível. Não faz sentido para os negócios abstrair o custo de uma solução de DR do design dela, portanto, as organizações precisam implementar o nível certo de proteção com o menor custo possível.

A nuvem mudou a indústria de backup de dados. Devido ao seu preço acessível, as empresas menores têm uma solução externa que faz backup de todos os seus dados (e sim, certifique-se de que estejam criptografados). Tanto o Oracle quanto o MySQL não oferecem soluções de armazenamento em nuvem integradas. Em vez disso, você pode usar as ferramentas fornecidas pelos fornecedores de nuvem. Um exemplo aqui poderia ser s3. 
aws s3 cp severalnines.sql s3://severalnine-sbucket/mysql_backups

Conclusão


Há várias maneiras de fazer backup de seu banco de dados, mas é importante analisar as necessidades de negócios antes de decidir sobre uma estratégia de backup. Como você pode ver, existem muitas semelhanças entre os backups do MySQL e do Oracle, que esperamos que possam atender aos seus SLAs.

Certifique-se sempre de praticar esses comandos. Não apenas quando você é novo na tecnologia, mas sempre que o DBMS se torna inutilizável, então você sabe o que fazer.

Se você quiser saber mais sobre o MySQL, consulte nosso whitepaper The DevOps Guide to Database Backups for MySQL and MariaDB.