6 de janeiro de 2026 Matheus Cruz 50 Views

Backups no MySQL com MyDumper

No MySQL, existem algumas ferramentas de backup lógico (dump) que podem ser utilizadas para realizar backups diários, seja como uma cópia secundária, em conjunto com um backup físico, ou ainda para cenários de migração e atualização de versão. No entanto, a ferramenta oficial mysqldump possui algumas limitações. Em bancos de dados muito grandes, por exemplo, o processo de backup tende a ser lento, pois é executado de forma serial, banco por banco e tabela por tabela, sem suporte a paralelismo.

Como alternativa, existe a ferramenta mysqlpump, que já oferece suporte a paralelismo. Contudo, conforme a documentação oficial do MySQL, o mysqlpump foi descontinuado na versão 8.0.34 e será removido em versões futuras. Porém, o mysqlpump, faz o backup de forma paralela, porém, não realiza o restore com paralelismo, continua sendo de forma sequencial.

Dessa forma, ficamos restritos apenas ao uso do mysqldump como ferramenta oficial de backup lógico? Não! Existe uma ferramenta open source chamada MyDumper.

O MyDumper é uma solução de backup lógico de código aberto composta por dois utilitários:

mydumper: exporta um backup consistente de bancos de dados MySQL, suportando múltiplas threads em paralelo (até uma por núcleo de CPU disponível).
myloader: lê os arquivos de backup criados pelo mydumper, conecta-se à instância de destino e restaura o banco de dados.

O MyDumper é mantido pela comunidade e não é um produto da Percona, MariaDB ou MySQL. Seu repositório oficial está disponível no GitHub: https://github.com/mydumper/mydumper, assim como a documentação oficial, ainda em desenvolvimento: https://mydumper.github.io/mydumper/docs/html/index.html.

Além disso, o MyLoader permite paralelismo inclusive no restore, o que pode, em alguns casos, ser até mais rápido que o restore sequencial comum.

Instalação do MyDumper

A instalação do MyDumper é simples. É possível instalar o binário em Linux (YUM, APT), FreeBSD e macOS.
No nosso caso, faremos a instalação para Linux.

Para ambientes Red Hat / CentOS / Rocky Linux, a instalação é feita da seguinte maneira:

Instale a chave do repositório:

wget -O GPG-KEY-MyDumper "https://keyserver.ubuntu.com/pks/lookup?op=get&search=0x79EA15C0E82E34BA"
rpm --import GPG-KEY-MyDumper

Sim, a chave está hospedada em um servidor do Ubuntu.

Após importar a chave, crie o arquivo do repositório /etc/yum.repos.d/mydumper.repo para que o sistema reconheça o repositório como fonte de pacotes:

echo -e "[mydumper]\nname=MyDumper\nbaseurl=https://mydumper.github.io/mydumper/repo/yum/\$releasever\nenabled=1\ngpgcheck=1" | sudo tee /etc/yum.repos.d/mydumper.repo

O parâmetro $releasever é expandido pelo yum/dnf para a versão do sistema operacional.

Em seguida, instale o MyDumper com o comando:

yum install mydumper

Saída esperada:

[root@rhel-demo ~]# yum install mydumper
MyDumper                                                                                2.4 kB/s | 1.5 kB     00:00
Dependencies resolved.
========================================================================================================================
 Package                     Architecture              Version                        Repository                   Size
========================================================================================================================
Installing:
 mydumper                    x86_64                    0.19.3-3                       mydumper                    3.2 M

Transaction Summary
========================================================================================================================
Install  1 Package

Total download size: 3.2 M
Installed size: 19 M
Is this ok [y/N]: y

Com isso, o MyDumper estará instalado em ambientes RHEL, CentOS, Rocky Linux e equivalentes.

Para a instalação em ambientes Debian / Ubuntu, siga os passos abaixo:

Importar a chave do repositório:

wget -qO- 'https://keyserver.ubuntu.com/pks/lookup?op=get&search=0x1D357EA7D10C9320371BDD0279EA15C0E82E34BA&exact=on' | sudo tee /etc/apt/keyrings/mydumper.asc

Em versões anteriores ao Debian 12 e Ubuntu 22.04, o diretório /etc/apt/keyrings pode não existir e deve ser criado com permissões 0755.

Criar o arquivo do repositório em /etc/apt/sources.list.d/mydumper.list:

Ubuntu:

echo "deb [signed-by=/etc/apt/keyrings/mydumper.asc] https://mydumper.github.io/mydumper/repo/apt/ubuntu $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/mydumper.list

Debian:

echo "deb [signed-by=/etc/apt/keyrings/mydumper.asc] https://mydumper.github.io/mydumper/repo/apt/debian $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/mydumper.list

Atualizar os pacotes e instalar o MyDumper:

apt-get update && apt-get install mydumper

Saída esperada:

root@db1:~# apt-get update && apt-get install mydumper
Hit:1 https://security.debian.org/debian-security bookworm-security InRelease
Hit:2 https://deb.debian.org/debian bookworm InRelease
Hit:3 https://deb.debian.org/debian bookworm-updates InRelease
Hit:4 https://deb.debian.org/debian bookworm-backports InRelease
Get:5 https://mydumper.github.io/mydumper/repo/apt/debian bookworm InRelease [4009 B]
Get:6 https://mydumper.github.io/mydumper/repo/apt/debian bookworm/main amd64 Packages [633 B]
Fetched 4642 B in 12s (396 B/s)
Reading package lists... Done
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following additional packages will be installed:
  gcc-12-base libatomic1 libgcc-s1 libpcre3 libstdc++6
The following NEW packages will be installed:
  libatomic1 libpcre3 mydumper
The following packages will be upgraded:
  gcc-12-base libgcc-s1 libstdc++6
3 upgraded, 3 newly installed, 0 to remove and 83 not upgraded.
Need to get 9955 kB of archives.
After this operation, 742 kB of additional disk space will be used.
Do you want to continue? [Y/n] y

Após a conclusão, o MyDumper estará instalado em ambientes Debian, Ubuntu e equivalentes.

Com a instalação do MyDumper, o MyLoader já é instalado junto. Para verificar se ambos foram instalados corretamente, utilize os seguintes comandos:

root@db1:~# mydumper --version
mydumper v0.19.3-3, built against MySQL 8.4.5 with SSL support

root@db1:~# myloader --version
myloader v0.19.3-3, built against MySQL 8.4.5 with SSL support

Ambos devem retornar a versão instalada, indicando que a instalação foi concluída com sucesso.

Exemplo de backup com MyDumper

Uma vez instalado o MyDumper, para realizar backups precisamos de um usuário que tenha permissões tanto para mapear a estrutura dos bancos e tabelas quanto para executar SELECT e assim permitir o dump dos dados.

Exemplo de criação do usuário do MyDumper:

CREATE USER 'mydumper'@'%' IDENTIFIED BY 'senha';
GRANT SELECT, LOCK TABLES, SHOW VIEW, EVENT, TRIGGER, REPLICATION CLIENT, BACKUP_ADMIN, RELOAD ON *.* TO 'mydumper'@'%';

Explicação detalhada das permissões:

SELECT → permite ler os dados das tabelas. Essencial para que o mydumper consiga extrair registros de cada banco e tabela.
LOCK TABLES → possibilita travar tabelas durante a execução do backup. Esse bloqueio garante consistência dos dados.
SHOW VIEW → autoriza a leitura das definições de views. Sem esse privilégio, o backup não incluiria o código SQL necessário para recriar as views no myloader.
EVENT → permite exportar eventos agendados do MySQL (rotinas que rodam automaticamente em horários configurados).
TRIGGER → garante que as triggers sejam exportadas junto ao backup.
REPLICATION CLIENT → dá permissão para consultar informações de status da replicação, como posição binlog e GTID. Isso é importante para backups consistentes em ambientes replicados, pois o mydumper pode registrar a posição exata para posterior restauração e sincronização com o master.
BACKUP_ADMIN → introduzido em versões recentes do MySQL, concede acesso específico a operações de backup. Ele facilita a exportação de metadados e tabelas sem exigir privilégios mais amplos como SUPER.
RELOAD → possibilita executar comandos como FLUSH TABLES ou FLUSH LOGS, que são úteis para garantir consistência no momento do backup, especialmente quando o mydumper precisa descarregar dados ou reinicializar logs.

Sobre o *.*:
O *.* indica que essas permissões valem para todos os bancos de dados (*) e todas as tabelas dentro deles (*).
Se você quiser limitar o acesso a apenas um banco específico, basta substituir *.* por nome_do_banco.*.

Com o usuário já criado, podemos executar o backup utilizando o mydumper.
Assim como o binário do mysql, os parâmetros de conexão são semelhantes:

-u (--user): Usuário de conexão.
-p (--password): Senha do usuário.
-h (--host): IP ou hostname do servidor.
-P (--port): Porta de conexão.

Outras opções podem ser adicionadas conforme a necessidade. Para mais detalhes, consulte:

mydumper --help

Exemplo de comando simples

Um backup básico de um banco de dados específico pode ser feito assim:

mydumper -u mydumper -p senha -h localhost -P 3306 -B employees -o /tmp/employees

Explicação dos parâmetros principais:

-u ou --user → usuário do MySQL que possui permissões de backup (mydumper no exemplo).
-p ou --password → senha do usuário.
-h ou --host → host do servidor onde o MySQL está rodando (aqui localhost).
-P ou --port → porta de conexão com o MySQL (padrão 3306).
-B ou --database → nome do banco de dados que será exportado (nesse caso, employees).
-o ou --outputdir → diretório de saída onde o backup será gravado (/tmp/employees).

Esse comando conecta no banco employees no servidor localhost, porta 3306, e salva o backup no diretório /tmp/employees.

O database employees é um sample oficial do MySQL, disponível em: github.com/datacharmer/test_db.

Estrutura do backup gerado

Dentro do diretório de backup, o mydumper cria arquivos separados para cada tabela e suas estruturas. Por exemplo:

employees-schema-create.sql → script para criar o database employees.
employees.departments-schema.sql → estrutura da tabela departments.
employees.departments.00000.sql → dados da tabela departments (nesse caso, 9 linhas).
employees.employees.00000.sql, employees.employees.00001.sql, employees.employees.00002.sql… → os dados da tabela employees, divididos em múltiplos arquivos conforme o número de linhas.
employees.current_dept_emp-schema-view.sql → definição de uma view.
metadata → informações sobre o dump (importantíssimo para restauração e replicação).

Os arquivos de dados são numerados (00000, 00001, 00002…) de acordo com os chunks de registros exportados. Isso facilita a paralelização do dump e posterior importação.

Exemplo de conteúdo do arquivo metadata

root@db1:/tmp/employees# cat metadata
# Started dump at: 2025-09-05 21:20:19
[config]
quote-character = BACKTICK

[myloader_session_variables]
SQL_MODE='NO_AUTO_VALUE_ON_ZERO,ONLY_FULL_GROUP_BY,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION' /*!40101

[source]
File = binlog.000003
Position = 66379458
Executed_Gtid_Set =

[`employees`.`departments`]
real_table_name=departments
rows = 9

[`employees`.`dept_emp`]
real_table_name=dept_emp
rows = 331603

Principais informações do metadata:

Configurações de sessão (ex.: sql_mode).
Informações de replicação → arquivo e posição do binlog, além do GTID (se habilitado). Isso permite restaurar o backup e aplicar os binlogs para sincronizar com o master.
Contagem de linhas por tabela → mostra quantos registros cada tabela tinha no momento do backup.

Exemplo de comando de backup estendido

Com mais parâmetros, para incluir triggers, eventos e procedures, além de paralelizar o dump:

mydumper -u mydumper -p senha -h localhost -P 3306 -B employees \
-o "/tmp/employees" --sync-thread-lock-mode LOCK_ALL --no-views -G -E -R \
--threads 2 --verbose 3

Neste exemplo:

-u ou --user: Usuário do MySQL.
-p ou --password: Senha do usuário.
-h ou --host: Host ou IP do servidor MySQL.
-P ou --port: Porta de conexão (padrão: 3306).
-B ou --database: Nome do banco de dados a ser exportado.
-o ou --outputdir: Diretório de saída do backup.
--sync-thread-lock-mode: Define o modo de sincronização entre os threads de backup.
- FTWRL → aplica um lock global (FLUSH TABLES WITH READ LOCK).
- LOCK_ALL → aplica locks por tabela (LOCK TABLES ... READ).
- GTID → usa coordenadas de GTID, sem precisar travar tabelas.
- NO_LOCK → não aplica nenhum bloqueio (backup pode ficar inconsistente).
- AUTO → escolhe automaticamente o melhor modo conforme o banco.
-W ou --no-views: Ignora views.
-G ou --triggers: Inclui triggers.
-E ou --events: Inclui eventos.
-R ou --routines: Inclui procedures e funções.
-t ou --threads: Número de threads usadas no dump (padrão: 4).
-v ou --verbose: Nível de detalhamento (0 = silencioso, 1 = erros, 2 = avisos, 3 = informações).

Como definimos a quantidade de threads igual a 2, ao consultar o process list durante o período do backup, podemos observar essas threads executando SELECTs nas tabelas:

mysql> show processlist;
+----+-----------------+-----------+--------------------+---------+-------+------------------------+------------------------------------------------------------------------------------------------------+
| Id | User            | Host      | db                 | Command | Time  | State                  | Info                                                                                                 |
+----+-----------------+-----------+--------------------+---------+-------+------------------------+------------------------------------------------------------------------------------------------------+
|  5 | event_scheduler | localhost | NULL               | Daemon  | 27354 | Waiting on empty queue | NULL                                                                                                 |
| 33 | root            | localhost | NULL               | Query   |     0 | init                   | show processlist                                                                                     |
| 34 | mydumper        | localhost | information_schema | Sleep   |    14 |                        | NULL                                                                                                 |
| 35 | mydumper        | localhost | information_schema | Query   |     1 | executing              | SELECT /*!40001 SQL_NO_CACHE */ * FROM `employees`.`dept_emp`  WHERE (`emp_no` IS NULL OR(10001 <= ` |
| 36 | mydumper        | localhost | employees          | Query   |     0 | executing              | SELECT /*!40001 SQL_NO_CACHE */ * FROM `employees`.`dept_emp`  WHERE (377499 <= `emp_no` AND `emp_no |
+----+-----------------+-----------+--------------------+---------+-------+------------------------+------------------------------------------------------------------------------------------------------+
5 rows in set, 1 warning (0.00 sec)

mysql>

Além disso, ao executar o backup no modo verbose, é possível acompanhar a criação das threads, a inicialização dos jobs e o processamento das tabelas:

** Message: 21:37:37.926: Creating workers
** Message: 21:37:37.926: Starting to enqueue non-transactional tables
** Message: 21:37:37.929: Thread 2: connected using MySQL connection ID 32
** Message: 21:37:37.929: Thread 1: connected using MySQL connection ID 31
** Message: 21:37:37.930: Thread 2: Creating Jobs
** Message: 21:37:37.930: Written master status
** Message: 21:37:37.930: Thread 2: dumping db information for `employees`
** Message: 21:37:37.935: Thread 1: Creating Jobs
** Message: 21:37:37.935: Transactions started, unlocking tables
** Message: 21:37:37.935: Waiting database finish
** Message: 21:37:37.965: Thread 1: Processing Schema jobs
** Message: 21:37:37.966: Thread 1: dumping schema create for `employees`
** Message: 21:37:37.966: Thread 1: dumping schema for `employees`.`departments`
** Message: 21:37:37.968: Thread 2: Processing Schema jobs
** Message: 21:37:37.968: Thread 2: dumping schema for `employees`.`dept_emp`
** Message: 21:37:37.968: Shutdown schema jobs
** Message: 21:37:37.968: Waiting threads to complete
** Message: 21:37:37.970: Thread 1: dumping schema for `employees`.`employees`
** Message: 21:37:37.970: Thread 2: dumping schema for `employees`.`dept_manager`
** Message: 21:37:37.971: Thread 2: dumping schema for `employees`.`titles`
** Message: 21:37:37.972: Thread 1: dumping schema for `employees`.`salaries`
** Message: 21:37:37.972: Thread 2: Schema jobs are done, Starting exporting data for Non-Transactional tables
** Message: 21:37:37.973: Enqueuing of non-transactional tables completed
** Message: 21:37:37.973: Starting to enqueue transactional tables
** Message: 21:37:37.973: Thread 2: Non-Transactional tables are done, Starting exporting data for Transactional tables
** Message: 21:37:37.973: Thread 1: Schema jobs are done, Starting exporting data for Non-Transactional tables
** Message: 21:37:37.973: Thread 1: Non-Transactional tables are done, Starting exporting data for Transactional tables
** Message: 21:37:37.974: employees.salaries has ~2838426 rows
** Message: 21:37:37.986: Thread 1: `employees`.`salaries` [ 0% ] | Tables: 6/6
** Message: 21:37:38.008: Thread 2: `employees`.`salaries` [ 0% ] | Tables: 6/6
** Message: 21:37:38.075: Thread 1: `employees`.`salaries` [ 3% ] | Tables: 6/6
** Message: 21:37:38.089: Thread 1: `employees`.`salaries` [ 3% ] | Tables: 6/6

Agora, caso seja necessário fazer backup de múltiplos bancos de dados, podemos utilizar o parâmetro -B passando os nomes separados por vírgula:

mydumper -u mydumper -p senha -h localhost -P 3306 -B employees,sakila \
-o "/tmp/databases" --sync-thread-lock-mode LOCK_ALL --no-views -G -E -R \
--threads 2 --verbose 3

No exemplo acima, foram informados os bancos employees e sakila.
Durante a execução, é possível observar pelo log do processo que o backup é realizado banco por banco de forma paralela:

** Message: 21:48:39.860: Thread 1: connected using MySQL connection ID 41
** Message: 21:48:39.861: Thread 2: connected using MySQL connection ID 42
** Message: 21:48:39.862: Thread 1: Creating Jobs
** Message: 21:48:39.863: Written master status
** Message: 21:48:39.863: Thread 1: dumping db information for `employees`
** Message: 21:48:39.867: Thread 2: Creating Jobs
** Message: 21:48:39.867: Thread 2: dumping db information for `sakila`
** Message: 21:48:39.867: Waiting database finish
** Message: 21:48:39.935: Thread 1: Processing Schema jobs
** Message: 21:48:39.935: Thread 1: dumping schema create for `employees`
** Message: 21:48:39.935: Shutdown schema jobs
** Message: 21:48:39.935: Thread 2: Processing Schema jobs
** Message: 21:48:39.936: Thread 2: dumping schema create for `sakila`
** Message: 21:48:39.937: Thread 1: dumping SP and VIEWs for `sakila`
** Message: 21:48:39.937: Thread 2: dumping schema for `employees`.`departments`
** Message: 21:48:39.938: Thread 2: dumping schema for `employees`.`dept_emp`
** Message: 21:48:39.939: Thread 2: dumping schema for `employees`.`dept_manager`
** Message: 21:48:39.940: Thread 2: dumping schema for `employees`.`employees`
** Message: 21:48:39.940: Thread 2: dumping schema for `employees`.`salaries`
** Message: 21:48:39.940: Thread 2: dumping schema for `employees`.`titles`
** Message: 21:48:39.941: Thread 2: dumping schema for `sakila`.`actor`
** Message: 21:48:39.941: Thread 2: dumping schema for `sakila`.`address`
** Message: 21:48:39.942: Thread 2: dumping schema for `sakila`.`category`

No diretório de saída (/tmp/databases), podemos ver que foram criados arquivos separados para cada banco e suas respectivas tabelas:

root@db1:/tmp/databases# ls
employees-schema-create.sql        employees.titles.00000.sql  sakila.film_actor-schema.sql
employees-schema-triggers.sql      employees.titles.00001.sql  sakila.film_actor.00000.sql
employees.departments-schema.sql   metadata                    sakila.film_category-schema.sql
employees.departments.00000.sql    sakila-schema-create.sql    sakila.film_category.00000.sql
employees.dept_emp-schema.sql      sakila-schema-post.sql      sakila.film_text-schema.sql
employees.dept_emp.00000.sql       sakila-schema-triggers.sql  sakila.film_text.00000.sql
employees.dept_emp.00001.sql       sakila.actor-schema.sql     sakila.inventory-schema.sql
employees.dept_manager-schema.sql  sakila.actor.00000.sql      sakila.inventory.00000.sql
employees.dept_manager.00000.sql   sakila.address-schema.sql   sakila.language-schema.sql
employees.employees-schema.sql     sakila.address.00000.sql    sakila.language.00000.sql
employees.employees.00000.sql      sakila.category-schema.sql  sakila.payment-schema.sql
employees.employees.00001.sql      sakila.category.00000.sql   sakila.payment.00000.sql
employees.salaries-schema.sql      sakila.city-schema.sql      sakila.payment.00001.sql
employees.salaries.00000.sql       sakila.city.00000.sql       sakila.rental-schema.sql
employees.salaries.00001.sql       sakila.country-schema.sql   sakila.rental.00000.sql
employees.salaries.00003.sql       sakila.country.00000.sql    sakila.rental.00001.sql
employees.salaries.00007.sql       sakila.customer-schema.sql  sakila.staff-schema.sql
employees.salaries.00011.sql       sakila.customer.00000.sql   sakila.staff.00000.sql
employees.salaries.00019.sql       sakila.film-schema.sql      sakila.store-schema.sql
employees.titles-schema.sql        sakila.film.00000.sql       sakila.store.00000.sql
root@db1:/tmp/databases#

Assim, cada banco exportado fica com sua estrutura (arquivos *-schema.sql) e seus dados (arquivos *.00000.sql, *.00001.sql etc.) bem organizados.

Pontos de atenção

Para o backup, é importante definir corretamente o nível de LOCK, garantindo a consistência dos dados.

Outro detalhe é que funções, triggers e eventos não são exportados automaticamente, diferentemente das views. Isso ocorre porque, no processo de restauração com o myloader, toda a estrutura do banco é recriada antes da carga dos dados. Nesse cenário, triggers, funções e procedures poderiam alterar registros durante o restore, causando inconsistências.

Além disso, a quantidade de threads deve ser planejada de acordo com a capacidade do servidor, levando em consideração principalmente o número de núcleos físicos de CPU disponíveis.

Exemplo de restauração com MyLoader

Para restaurar os backups feitos com o mydumper, utilizamos o myloader com o seguinte comando:

myloader -u root -p senha -h localhost -P 3306 \
-d "/tmp/databases" --threads 2 \
--verbose 3

Para a restauração, recomenda-se utilizar um usuário com privilégios elevados, como root ou outro usuário administrador, para evitar erros de permissão durante o restore.

Parâmetros principais (semelhantes aos do MyDumper):

-u → Usuário do MySQL.
-p → Senha do usuário.
-h → Host do servidor.
-P → Porta de conexão (padrão: 3306).
-d → Diretório onde estão os arquivos de backup.
--threads → Número de threads utilizadas na restauração.
-v ou --verbose → Nível de detalhamento (0 = silencioso, 1 = erros, 2 = avisos, 3 = informações).

Com esse comando, o log do terminal durante a restauração será semelhante a este:

** Message: 22:04:07.450: Initializing initialize_worker_schema
** Message: 22:04:07.452: Reading metadata: metadata
** Message: 22:04:07.452: Config file loaded
** Message: 22:04:07.452: myloader_session_variables found on metadata
** Message: 22:04:07.452: Change master will be executed for channel: default channel
** Message: 22:04:07.452: metadata pushed
** Message: 22:04:07.452: Intermediate queue: Sending END job
** Message: 22:04:07.455: Intermediate thread ended
** Message: 22:04:07.455: Intermediate thread: SHUTDOWN
** Message: 22:04:07.455: S-Thread 4: Starting import
** Message: 22:04:07.456: Thread 4: restoring create database on `employees` from employees-schema-create.sql. Tables 0 of 22 completed
** Message: 22:04:07.459: S-Thread 5: Starting import
** Message: 22:04:07.459: Thread 5: restoring create database on `sakila` from sakila-schema-create.sql. Tables 0 of 22 completed
** Message: 22:04:07.459: S-Thread 3: Starting import
** Message: 22:04:07.460: S-Thread 6: Starting import
** Message: 22:04:07.460: Executing set session
** Message: 22:04:07.461: Executing set session
** Message: 22:04:07.468: Thread 4: restoring table employees.departments from /tmp/databases/employees.departments-schema.sql
** Message: 22:04:07.468: Thread 6: restoring table employees.dept_manager from /tmp/databases/employees.dept_manager-schema.sql

Pontos de atenção

É necessário garantir que o backup tenha sido consistente antes do restore.
O usuário que executa a restauração deve ter privilégios elevados.
Recomenda-se fazer o backup de views, funções, procedures e triggers separadamente do backup de dados, para evitar alterações indesejadas durante a restauração.
Tanto o mydumper quanto o myloader permitem backups e restores remotos, paralelos, usando múltiplas threads.
MyDumper/MyLoader também podem ser utilizados com MariaDB usando os mesmos parâmetros.
- Diferente do MySQL, o MariaDB possui a ferramenta mariadb-dump, que a partir da versão 11.4 passou a oferecer suporte a paralelismo.

Anterior Proxmox Datacenter Manager: A Nova Era do Gerenciamento Multi-Cluster Chegou

Categoria Banco de Dados Infraestrutura TI

About author

Matheus Cruz 4 posts

Consultor e instrutor DBA na 4Linux, trabalhando com as tecnologias PostgreSQL, MySQL, MongoDB, SQL Server, Redis, entre outras.

View all posts by this author →

Backups no MySQL com MyDumper

Instalação do MyDumper

Exemplo de backup com MyDumper

Exemplo de comando simples

Estrutura do backup gerado

Exemplo de conteúdo do arquivo metadata

Exemplo de comando de backup estendido

Pontos de atenção

Exemplo de restauração com MyLoader

Pontos de atenção

About author

Você pode gostar também

Entenda a LGPD e como ela impacta a segurança dos seus dados

Como lidar com dados duplicados no PostgreSQL usando a coluna de sistema ctid

Descubra o TimescaleDB: O banco de dados SQL para séries temporais

Pesquisar

Jedai.ai

JedaiCast

Cursos Gratuitos

Ebook Gratuito

Treinamento

Especialistas em open source

Temos um presente para você!

Você ganhou totalmente gratuito um curso da categoria Starter da 4Linux! São 9 opções de cursos para você escolher!

Backups no MySQL com MyDumper

Instalação do MyDumper

Exemplo de backup com MyDumper

Exemplo de comando simples

Estrutura do backup gerado

Exemplo de conteúdo do arquivo metadata

Exemplo de comando de backup estendido

Pontos de atenção

Exemplo de restauração com MyLoader

Pontos de atenção

Compartilhe este post:

About author

Você pode gostar também

Entenda a LGPD e como ela impacta a segurança dos seus dados

Compartilhe este post:

Como lidar com dados duplicados no PostgreSQL usando a coluna de sistema ctid

Compartilhe este post:

Descubra o TimescaleDB: O banco de dados SQL para séries temporais

Compartilhe este post:

Pesquisar

Jedai.ai

JedaiCast

Cursos Gratuitos

Ebook Gratuito

Treinamento

Especialistas em open source