Esse é um assunto pouco abordado, muito negligenciado e EXTREMAMENTE importante.
Nesse artigo vamos ver 3 formas de realizar o backup, restore, otimizações e o tão polêmico backup incremental no MySQL.

Vamos ver o MYSQLDUMP, INTO OUTFILE/LOAD DATA INFILE e LOG BINÁRIO. São 3 formas distintas de realizar uma tarefa tão importante.

MYSQLDUMP

Método tradicional e bem difundido, ele realiza a extração das estruturas de databasestables e dados para um arquivo texto, onde o conteúdo são comandos DDL e DML. Apesar de ser o método usado por quase todo mundo, as suas opções são bem pouco exploradas. Existem muitas reclamações sobre desempenho, gerar lock tables, não poder realizar backp incremental, etc… Tudo isso pode ser verdade, desde que não utilizadas as opções corretas.

Artigo sobre mysqldump

INTO OUTFILE/LOAD DATA INFILE

Ao contrário do MYSQLDUMP, usar o INTO OUTFILE/LOAD DATA INFILE não é nem um pouco convencional, e isso se deve ao fato de ele ser extremamente trabalhoso. Para realizar o backup dessa maneira é necessário escrever as sentenças SQL para cada uma das tabelas que deseja realizar o backup. Outro fator importante é que as estruturas das tabelas não irão estar no backup, essas estruturas necessitam de um backup através do MYSQLDUMP.

Mas se é tão trabalhoso assim, qual o motivo de eu pensar em usar ele? A resposta é: velocidade no momento do restore. Segundo a documentação do MySQL, esse processo é cerca de 20x mais rápido que quando comparado com um restore de um backup gerado pelo MYSQLDUMP. Mas isso pode melhorar ainda mais se alguns procedimentos forem adotados.

LOG BINÁRIO

O LOG BINÁRIO é um arquivo de log, onde é armazenado todos os comandos DDL e DML que alteram dados que são executados no MySQL, e se ele armazena tudo que altera dados e estruturas, ele pode ser utilizado como um método de backup.
Esse método requer um planejamento bem grande, tem muitos pontos que se não for tomados os devidos cuidados, algo pode sair errado, porem ele pode se tornar a maneira mais fácil de realizar backups.
ATENÇÃO, o backup através do LOG BINÁRIO sempre será incremental e nunca FULL, por isso sempre guarde com segurança todos os arquivos do log binário. Através do log binário é possível voltar para qualquer ponto na linha do tempo.

 

E você, como você garante que seus backups estão íntegros e atualizados? 

 

Aulas ao vivo sem que você precise sair de casa.

Nesse post vamos ver como utilizar o log binário para realizar backups e restore.

Esse é o método de backup mais complicado para ser gerenciado, porém se bem arquitetado é uma poderosa ferramenta de backup.
O logbin é um log de eventos que guarda todas as alterações que são feitas no servidor MySQL, seja de comandos DDL ou DML. Ele é usado em sua grande maioria dos casos apenas para a replicação, mas ele pode(e deve) ser utilizado como backup(incremental), uma vez que tudo que que altera o seu servidor é registrado.

O primeiro passo é habilitar o log binário, para isso edite o my.cnf

[mysqld]
log_bin = /var/log/mysql/mysql-bin.log

Como todas as alterações são escritas no logbin, ele tende a crescer bastante e é interessante adicionar opções, como por exemplo, mas cuidado, entende bem para que serve cada uma das opções.

Remover os arquivos com mais de X dias
expire_logs_days = 10

Quando o arquivo chegar em um determinado tamanho, outro será gerado.
max_binlog_size = 100M

Veja mais sobre logbin nesse link: http://dev.mysql.com/doc/refman/5.6/en/binary-log.html

Após fazer as alterações no my.cnf, reinicie o MySQL: /etc/init.d/mysql restart

Para verificar se ele realmente está ativado, pode ser consultada as variáveis do MySQL.

mysql> show variables like ‘log_bin';
+——————+——-+
| Variable_name | Value |
+——————+——-+
| log_bin               | ON     |
+——————+——-+
1 row in set (0.00 sec)

Você precisa do MySQL e nós temos a melhor solução.

Uma coisa BEM IMPORTANTE é ter em mente que apenas após o ser ativado é que os comandos DDL e DML começam a ser gravados no logbin, os dados que já estavam antes no servidor não vão para dentro do logbin. E outra coisa, é que o quando usamos o logbin para backup, ele é um backup incremental, ou seja, para que seja possíevl restaurar é necessário ter feito cópias de todos os logbins e restaurar todos na sequencia correta, e estar ciente que isso pode demorar muito, pois é um histórico todo de alterações, por isso é mais comum usar o logbin apenas em situações de emergência, para restaurar a partir de um certo ponto o backup.

Uma vez, eu desenvolvi uma rotina de backup em que era feito um backup full com o mysqldump durante a madrugada, e durante o dia, a cada 30 minutos era realizada a copia dos logs binários, com isso, caso tivesse algum problema, o período máximo de dados perdidos que teria, seria de 30 minutos.

Para restaurar o backup é bem simples, o MySQL tem o aplicativo mysqlbinlog, com ele podemos extrair os dados do logbin e depois importar para o MySQL. Para mais informações sobre mysqlbinlog, veja esse link: http://dev.mysql.com/doc/refman/5.6/en/mysqlbinlog.html

Exportando os dados do logbin para um arquivo de texto:

mysqlbinlog [opções] <caminho completo para o logbin>

Ex: mysqlbinlog /var/log/mysql/mysql-bin.007

Isso irá mostrar ne tela, o conteúdo inteiro do logbin, o que não nos interessa. Então temos que redirecionar a saída para um arquivo texto, igual fazemos com o mysqldumo.

Ex: mysqlbinlog /var/log/mysql/mysql-bin.007 > /backup/xpto/restore_logbin_xpto.sql

Algumas opções interessantes de parâmetros que temos para usar o mysqlbinlog. Elas pode ser utilizadas sozinhas ou

–start-datetime
Define a partir de que data os dados devem ser lidos do logbin.

Ex: mysqlbinlog –start-datetime=”2014-09-01 00:00:00″ /var/log/mysql/mysql-bin.007 > /backup/xpto/restore_logbin_xpto.sqltper

–stop-datetime
Define até qual data os dados devem ser lidos o logbin.

Ex: mysqlbinlog –stop-datetime=”2014-09-02 23:59:59″ /var/log/mysql/mysql-bin.007 > /backup/xpto/restore_logbin_xpto.sql

Usando as duas opções em conjunto

Ex: mysqlbinlog –start-datetime=”2014-09-01 00:00:00″ –stop-datetime=”2014-09-02 23:59:59″ /var/log/mysql/mysql-bin.007 > /backup/xpto/restore_logbin_xpto.sql
Após isso, temos um arquivo texto com comandos DDL e DML que podem ser importados pelo MySQL.

Ex: mysql -uroot -p db_name2 < /backup/xpto/restore_logbin_xpto.sql

Na teoria, gerenciamento de backup com o logbin é a mais simples, mas na pratica é a mais complicada, então antes faça vários testes para ter certeza que ele irá atender a sua necessidade e que todas as suas dúvidas foram sanadas.

Aulas ao vivo sem que você precise sair de casa.

Nesse post vamos ver como criar backups utilizando o comando INTO OUTFILE e como restaurá-los com o comando LOAD DATA INFILE.

Basicamente é a exportação do conteúdo das tabelas para um arquivo texto(csv por exemplo) e a restauração dos arquivos texto para as tabelas.
Esse método é mais trabalhoso, pois é necessário realizar o procedimento para cada uma das tabelas e é feito o backup apenas dos dados, sendo necessário realizar o backup da estrutura separadamente.
Segundo a documentação o comando LOAD DATA INFILE é até 20x mais rápido do que o INSERT gerado pelo mysqldump. Mas esse tempo pode ser melhorado ainda mais caso alguns procedimentos sejam realizados, vamos discuir sobre eles.

Fazendo o Backup
Vamos usar o “SELECT … INTO OUTFILE”, veja mais em: http://dev.mysql.com/doc/refman/5.6/en/select-into.html

ex:
SELECT *
INTO OUTFILE ‘/tmp/backuP_tbl_name1.csv’
FIELDS TERMINATED BY ‘;’ OPTIONALLY ENCLOSED BY ‘”‘
LINES TERMINATED BY ‘n’
FROM tbl_nam1;

Observações:

– O arquivo ‘/tmp/backuP_tbl_name1.csv’ não pode existir.
– O arquivo setá salvo no servidor que está rodando o serviço MySQL e não no client que está realizando o backup.

Vamos ver formas de otimizar ainda mais o restore dos dados.

Otimizar tabelas InnoDB

- Autocommit
As tabelas InnoDB são transacionais, com isso todo comando DML(INSERT, UPDATE e DELETE) são gerenciados por transações e o comando COMMIT precisa ser executado para que as alterações sejam aplicadas no escopo global do InnoDB. Mas o MySQL tem uma varivável chamada autocommit, o seu valor padrão é 1(ON), então não é necessário a execução do comando COMMIT, o MySQL se encarrega que ao final de cada comando executado seja realizado um COMMIT implícito. Até aqui tudo bem, nada fora do normal, mas quando queremos otimizar uma carga de dados, podemos desativar o autocommit e ao final do processo todo execucar o comando COMMIT explícito.
A variável autocommit existe no escopo local e global, e os seus valores podem ser diferentes em cada um dos escopos.
Faça um teste:
Acesso o mysql e execute esses comandos;
mysql> SHOW LOCAL VARIABLES LIKE ‘%autocommit%';
+——————-+——-+
| Variable_name | Value |
+——————-+——-+
| autocommit        | ON    |
+——————-+——-+
1 row in set (0,00 sec)

mysql> SHOW GLOBAL VARIABLES LIKE ‘%autocommit%';
+——————-+——-+
| Variable_name | Value |
+——————-+——-+
| autocommit        | ON    |
+——————-+——-+
1 row in set (0,00 sec)

mysql> SET autocommit=0;
Query OK, 0 rows affected (0,00 sec)

mysql> SHOW LOCAL VARIABLES LIKE ‘%autocommit%';
+——————-+——-+
| Variable_name | Value |
+——————-+——-+
| autocommit       | OFF   |
+——————-+——-+
1 row in set (0,00 sec)

mysql> SHOW GLOBAL VARIABLES LIKE ‘%autocommit%';
+——————-+——-+
| Variable_name | Value |
+——————-+——-+
| autocommit        | ON    |
+——————-+——-+
1 row in set (0,00 sec)
Então vimos que cada escopo pode ter o seu valor diferente, mas qual deles é utilizado quando os comandos são executados? Apenas o escopo local. O valor da variável no escopo global é o valor padão que cada conexão irá utilziar no escopo local. Se a conexão for encerrada e reaberta, o valor da varável local voltar a ser o mesmo da global.
Para alterar o valor do escopo global, altere no my.cnf:

[mysqld]
autocommit=0

E reinicie o MySQl. Mas cuidado ao fazer isso será necessário que sempre seja executado o comando COMMIT explícito nas tabelas InnoDB.

Você precisa do MySQL e nós temos a melhor solução.

- unique_checks
Se você na sua tabela tiver chave única, essa variável irá desativer o controle de valor único e para tabelas grandes, pode otimizar o tempo de restore, por que irá diminuir consideravelmente o I/O de disco. Só tenha certeza que não existem valores duplicados nas colunas que serão chave única.
O valor padrão da variável unique_checks é 1(ON) e assim como a variável autocommit, ela existe no escopo global e local e o seu valor pode ser controlado separadamente.

mysql> SET unique_checks=0;
Query OK, 0 rows affected (0,00 sec)

– foreign_key_checks
Caso você tenha chaves estrangeiras nas suas tabelas InnoDB, pode ser desligado o controle de verificação das chaves estrangeiras, isso também irá otimizar o tempo de restore consideravelmente, pois o I/O de disco também será bem menor.
O valor padrão da variável foreign_key_checks é 1(ON) e assim como a variável autocommit, ela existe no escopo global e local e o seu valor pode ser controlado separadamente.

mysql> SET foreign_key_checks=0;
Query OK, 0 rows affected (0,00 sec)

Otimizar tabelas MyISAM

- Desabilitar os índices
No mysqldump temos o parâmetro –disable-keys que desabilita a atualização dos índices no momento do INSERT e habilita ao final de todo o processo, para restaurar uma tabela também recomendo desabilitar antes do restores e habilitar ao final, , pois o I/O de disco também será bem menor.
Mas atenção, essa operação não é apenas para o escopo local, isso será aplicado para o escopo global, então ao final não pode esquecer de habilitar os íncides novamente.
Funciona apenas para tabelas MyISAM.

Para ver os índices de uma tabela:
mysql> SHOW INDEX FROM tbl_name1G
*************************** 1. row ***************************
Table: tbl_name1
Non_unique: 1
Key_name: idx_uf
Seq_in_index: 1
Column_name: uf
Collation: A
Cardinality: NULL
Sub_part: NULL
Packed: NULL
Null: YES
Index_type: BTREE
Comment:<——
Index_comment:
2 rows in set (0,01 sec)

Para desabilitar os índices:
mysql> ALTER TABLE tbl_name1 DISABLE KEYS;
Query OK, 0 rows affected (0,00 sec)

Conferindo se foram desabilitados:
mysql> SHOW INDEX FROM tbl_name1G
*************************** 1. row ***************************
Table: tbl_name1
Non_unique: 1
Key_name: idx_uf
Seq_in_index: 1
Column_name: uf
Collation: A
Cardinality: NULL
Sub_part: NULL
Packed: NULL
Null: YES
Index_type: BTREE
Comment: disabled <——
Index_comment:
2 rows in set (0,00 sec)

Para habilitar os índices
mysql> ALTER TABLE tbl_name1 ENABLE KEYS;
Query OK, 0 rows affected (0,00 sec)

Então sendo possível realizar essas 3 opções, temos como melhorar mais a velocidade no momento do restore.

Agora já temos o backup realizado e o servidor otimizado para o restore, basta apenas realziar o restore.
Para isso, vamos utilziar o comando LOAD DATA INFILE, veja mais em: http://dev.mysql.com/doc/refman/5.6/en/load-data.html

No momento de realizar o backup através do comando “SELECT … INTO OUTFILE”, ele sempre será salvo no servidor, e nunca no client que está executando o comando, como já vimos acima. Mas para restaurar o backup, ele pode estar tanto no servidor, quanto no client que está executando o restore.

Restaurar um backup que está no servidor:
Lembre-se que antes de restaurar, é necessário já ter a tabela criada, pois diferentemente do mysqldump, o “SELECT … INTO OUTFILE” não exporta essa extrutura. Isso pode ser feito através do mysqldump(mysqldump -uroot -p –all-databases –no-data > path_que_sera_salvo_o_dump.sql).
O restore deve ser feito para todas as tabelas.

Dica,

Vamos ao restore!

Ex:
LOAD DATA INFILE ‘/tmp/backuP_tbl_name1.csv’
INTO TABLE tbl_nam1
FIELDS TERMINATED BY ‘;’ OPTIONALLY ENCLOSED BY ‘”‘
LINES TERMINATED BY ‘n’

Restaurar um backup que está no client:
É o mesmo comando, porém devemos adicionar a opção “LOCAL”

Ex:
LOAD DATA LOCAL INFILE ‘/tmp/backuP_tbl_name1.csv’
INTO TABLE tbl_nam1
FIELDS TERMINATED BY ‘;’ OPTIONALLY ENCLOSED BY ‘”‘
LINES TERMINATED BY ‘n’

O comando LOAD DATA INFILE tem mais opções, verifique bem e use as opções conforme a sua necessidade.
Dessa forma também podemos facilmente realizar backup incremental.
Teste e comprove a velocidade do restore.

Aulas ao vivo sem que você precise sair de casa.

Nesse post vamos ver como usar o mysqldump para realizar backups e como restaurá-los.

O mysqldump é a ferramenta que já vem com o MySQL para realização de backups, ela realiza a exportação dos dados dos databases(tabelas, procedures, functions, triggers e views) para um arquivo texto, onde o seu conteúdo são comandos DML e DDL.

Muita gente reclama que o mysqldump é lento ou gera locks nas tabelas no momento do backup, gerando uma fila de requisições gigante, elevando o load, uso de memória, swap, etc, caos total… Isso até pode ser verdade, mas sempre temos formas de não passar por esses problemas.

Eu sempre recomendo e faço os meus backups em um servidor slave, ou seja, monto uma replicação e realizo o backup a partir o servidor slave, mas não vamos usar esse cenário como exemplo, vamos imaginar um ambiente de produção sem replicação, que é o que acontece na grande maioria dos casos.

Nesse link possui a lista completa de parâmetros que podem ser utilizadas com o mysqldump: http://dev.mysql.com/doc/refman/5.6/en/mysqldump.html

Um ponto bem importante a ser considerado antes de julgar lento o mysqldump, é a velocidade dos discos e se o backup está sendo feito local ou remoto, se o disco for lento e/ou o backup estiver sendo realizado remoto, com toda certeza que o mysqldump irá parecer lento.

O mysqldump possui vários parâmetros, vamos ver uma lista com alguns deles.

Os parâmetros podem ser utilizados sozinhos ou em conjunto, analise bem o seu ambiente e monte o comando com tudo que for necessário.

-u
Nome do usuário do MySQL que irá realizar o mysqldump

-p
senha do usuário do MySQL que irá realziar o mysqldump

-h
Host do MySQL, pode ser o IP ou algum DNS e não é necessário quando é localhost

–result-file
Caminho completo para o arquivo que será gerado com o conteúdo do dump.
Normalmente o arquivo gerado tem a extensão .sql, mas isso não é uma regra, pode ser qualquer extensão, ou inclusive não ter extensão.

ex: mysqldump -uroot -p –all-databases –result-file=path_que_sera_salvo_o_dump.sql
ex: mysqldump -uroot -p –all-databases –result-file=path_que_sera_salvo_o_dump.dump
ex: mysqldump -uroot -p –all-databases –result-file=path_que_sera_salvo_o_dump.txt
ex: mysqldump -uroot -p –all-databases –result-file=path_que_sera_salvo_o_dump

O –result-file não é uma unanimidade na hora de gerar o backup, a forma mais utilizada é não informar o –result-file mas sim direcionar a saída do mysqldump diretamente para um arquivo, utilizando o sinal de maior(>).

ex: mysqldump -uroot -p –all-databases > path_que_sera_salvo_o_dump.sql

Dificilmente terá alguma diferença entre usar o –result-file ou o >, mas o que pode acontecer é com o encoding de caracteres, uma vez que quando não é usado o –result-file todo o conteúdo do backup passa pelo cliente(prompt) que está sendo usado para gerar o backup e após direcionado para o arquivo, e se as configuração do cliente não aceitar algum dos caracteres que tem salvo em alguma coluna do MySQL, ele será trocado por algum caracter, normalmente por interrogação.
No Windows é altamente aconselhavel usar sempre o –result-file, por que o Windows utilza o “rn” para quebras de linhas, e no linux é utiulziado apenas o “n”.
Nos exemplos serão utilizados sempre >

–all-databases
Irá realizar um backup completo de todos os databases do seu MySQL, inclusive o database mysql, que contém as tabeals de usuários e permissões de acesso. Se o backup for realizdo com ele, no momento do restore, tenha sempre o cuidado para a versão do MySQL que está recebendo os dados seja a mesma que o MySQL de origem dos dados. Além disso tenha em mente que não será possível realizar o restore de apenas um dos databases, sempre será um restore de todos.

Ex: mysqldump -uroot -p –all-databases > path_que_sera_salvo_o_dump.sql

–databases
Realiza o backup de apenas um ou mais databases.
O nome dos databases são separados por um espaço em branco.

ex: Ex: mysqldump -uroot -p –databases db_name1 > path_que_sera_salvo_o_dump.sql

ex: Ex: mysqldump -uroot -p –databases db_name1 db_name2 > path_que_sera_salvo_o_dump.sql

–disable-keys
Desabilita os índices no inicio do restore e habilita ao final, ou seja, se não é necessário atualizar os índices a cada insert, o processo de restore tende a ser consideravelmente mais rápido.
Funciona apenas para tabelas MyISAM.

–events
Inclui no backup os events scheaduler, veja mais aqui: http://dev.mysql.com/doc/refman/5.6/en/create-event.html

–ignore-table
Não realiza o dump de uma ou mais tabelas.
Essa opção é extremamente util quando temos tabelas de log(por exemplo) gigantes e que não são importante serem realizadas cópias todos os dias.
É necessário informar o nome do database e o nome da tabela.

Ex: mysqldump -uroot -p –all-databases –ignore-table=db_name.tbl_name > path_que_sera_salvo_o_dump.sql
Caso seja necessária mais de uma tabela, repetir todo o parâmetro.
Ex: mysqldump -uroot -p –all-databases –ignore-table=db_name.tbl_name1 –ignore-table=db_name.tbl_name2 > path_que_sera_salvo_o_dump.sql

–no-create-db
Não escreve no dump os comandos de CREATE DATABSE
Ex: mysqldump -uroot -p –all-databases –no-create-db > path_que_sera_salvo_o_dump.sql

–no-create-info
Não escreve no dump os comandos de CREATE TABLE
Ex: mysqldump -uroot -p –all-databases –no-create-info > path_que_sera_salvo_o_dump.sql

–no-data
Não escreve no dump nenhum dado.
Ex: mysqldump -uroot -p –all-databases –no-data > path_que_sera_salvo_o_dump.sql

Você precisa do MySQL e nós temos a melhor solução.

–routines
Realiza o backup das functions e procedures.
Ex: mysqldump -uroot -p –all-databases –routines > path_que_sera_salvo_o_dump.sql

–tables
Realiza o backup de uma ou mais tabelas de um database.
A utilização desse parâmetro deve ser feita em conjunto com o –databases e só deve ser utilziado para um database de cada vez.
– Ah, mas eu preciso fazer o backup de 1 tabela de um database e 3 tabelas de outro, como eu faço?
– É simples nobre gafanhoto, realize um backup para um database e outro backup para outro.

ex: Ex: mysqldump -uroot -p –databases db_name1 –tables tbl_name1 > path_que_sera_salvo_o_dump.sql

ex: Ex: mysqldump -uroot -p –databases db_name1 –tables tbl_name1 tbl_name2 > path_que_sera_salvo_o_dump.sql

–triggers
Realiza o backup das triggers

–single-transaction
A utilização desse parâmetro garante que as tabelas não sofram LOCK no momento do backup, porém ele só tem efeito em tabelas InnoDB.
Um LOCK geralmente gera uma fila de execução grande, e isso sempre acaba com o dia do DBA, então eu recomendo sempre utilizar o –single-transaction se as tabelas foram InnoDB.
Parâmetro essencial para não gerar problemas durante o backup. 

Ex: mysqldump -uroot -p –all-databases –single-transaction > path_que_sera_salvo_o_dump.sql

–skip-add-drop-table
Não escreve no dump os comandos de DROP TABLE.

Ex: mysqldump -uroot -p –all-databases –skip-add-drop-table > path_que_sera_salvo_o_dump.sql

–compatible
Gera o backup compatível com outro banco de dados. Util no momento de realizar migrações de dados.
Valores suportados: ansi, mysql323, mysql40, postgresql, oracle, mssql, db2, maxdb, no_key_options, no_table_options, e no_field_options

Ex: mysqldump -uroot -p –all-databases –compatible=postgresql > path_que_sera_salvo_o_dump.sql

–where
Realiza o backup aplicando uma expressão SQL.

Ex: mysqldump -uroot -p –databases db_name1 –tables tbl_name1 –where=”dataCadastro >= ‘2014-10-01′” > path_que_sera_salvo_o_dump.sql

Dessa forma você pode facilmente bolar um backup incremental, o único problema é que precisa ser realizado um backup para cada tabela. #ficadica

Após o backup feito, temos basicamente duas formas de fazer a restauração.

1ª forma
Para gerar o backup, o caracter que usamos é o maior(>) ou –result-file, no caso vamos ficar com o >. Para restaurar uamos o inverso, ou seja, o caracter de menor(<).
Agora não usamos mais mysqldump, mas apenas o mysql, que é o cliente de acesso ao MySQL.

Se o backup foi criado usando o parâmetro –all-databases ou o parâmetro –databases informando mais de um database, não é necessário informar o nome do banco de dados que o backup será restaurado, isso por que como tem mais de um databse no backup e ele irá criar ou ativar os databases durante o restore.

ex: mysql -uroot -p < path_que_sera_salvo_o_dump.sql

Mas caso o backup seja de apenas um database, é ncessário informar para qual database será feito o restore.

ex: mysql -uroot -p db_name < path_que_sera_salvo_o_dump.sql

Dessa forma é possível fazer o backup de um database e restaurar o em um database com outro nome.

ex dump: mysqldump -uroot -p db_name > path_que_sera_salvo_o_dump.sql
ex restore: mysql -uroot -p db_name2 < path_que_sera_salvo_o_dump.sql

2ª forma
Precisamos acessar o MySQL e a partir dele comandar a restauração do backup usando o comando source.
Acessar o MySQL através do prompt: mysql -uroot -p

Se o backup foi criado usando o parâmetro –all-databases ou o parâmetro –databases informando mais de um database, não é necessário informar o nome do banco de dados que o backup será restaurado, isso por que como tem mais de um databse no backup e ele irá criar ou ativar os databases durante o restore.

mysql> source path_que_sera_salvo_o_dump.sql

Mas caso o backup seja de apenas um database, é ncessário ativar o database será feito o restore.

mysql> use db_name1;
Database changed

mysql> source path_que_sera_salvo_o_dump.sql

Obs: Nos dois casos, o backup precisa estar no computador/servidor que esta originando a conexão e não no servidor onde está rodnado o serviço do MySQL de destino.

Aulas ao vivo sem que você precise sair de casa.