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

Migrando o banco de dados do Azure para MySQL/MariaDB para um servidor local

As migrações de banco de dados podem impor grandes desafios quando você considera como iniciar, quais ferramentas usar e como obter uma migração completa de banco de dados com sucesso. Anteriormente, listamos o principal código aberto que você pode usar na migração para MySQL ou MariaDB. Neste blog, mostraremos como migrar dados do Banco de Dados do Microsoft Azure para MySQL ou MariaDB.

O Microsoft Azure agora é conhecido por ser um concorrente contra os outros dois gigantes da tecnologia de nuvem:AWS e Google Cloud. Ele especializa mais de seus produtos da Microsoft, especialmente seu banco de dados proprietário MSSQL criado em casa. Mas não só isso, ele também tem código aberto como um de seus bancos de dados de serviços totalmente gerenciados para oferecer publicamente. Entre seus bancos de dados suportados estão MySQL e MariaDB.

A mudança do Banco de Dados do Azure para MySQL/MariaDB pode ser entediante, mas depende do tipo de arquitetura e do tipo de conjunto de dados que você hospedou no Azure como seu provedor de nuvem atual. Com as ferramentas certas, isso pode ser alcançado e uma migração completa pode ser feita.

Vamos nos concentrar nas ferramentas que podemos usar para migrações de dados no MySQL ou MariaDB. Para este blog, estou usando o RHEL/CentOS para instalar os pacotes necessários. Vamos passar por cima e definir as etapas e procedimentos sobre como fazer isso.

Migrando do Banco de Dados do Azure para MySQL ou MariaDB

Uma abordagem típica de migração de seus dados do Banco de Dados do Azure para um servidor local é fazer um backup usando uma cópia lógica. Isso pode ser feito usando soluções de utilitário de backup compatíveis para operar com o Banco de Dados do Azure para MySQL ou MariaDB, que é um serviço totalmente gerenciado. Os serviços de banco de dados totalmente gerenciados não oferecem logins SSH, portanto, a cópia física dos backups não é uma opção.

Antes de migrar ou despejar seu banco de dados existente do Azure, você deve observar as seguintes considerações.

Casos de uso comuns para despejo e restauração no local

Os casos de uso mais comuns são:

  • Usar backup lógico (como mysqldump, mysqlpump ou mydumper/myloader) e restaurar é a única opção. O Banco de Dados do Azure para MySQL ou MariaDB não oferece suporte ao acesso físico ao armazenamento físico, pois este é um serviço de banco de dados totalmente gerenciado.
  • Suporta apenas mecanismos de armazenamento InnoDB e Memory. Migrando de mecanismos de armazenamento alternativos para InnoDB. O Banco de Dados do Azure para MySQL ou MariaDB dá suporte apenas ao mecanismo de armazenamento InnoDB e, portanto, não dá suporte a mecanismos de armazenamento alternativos. Se suas tabelas estiverem configuradas com outros mecanismos de armazenamento, converta-as no formato do mecanismo InnoDB antes da migração para o Banco de Dados do Azure para MySQL.
  • Por exemplo, se você tiver um WordPress ou WebApp usando as tabelas MyISAM, primeiro converta essas tabelas migrando para o formato InnoDB antes de restaurar para o Banco de Dados do Azure para MySQL. Use a cláusula ENGINE=InnoDB para definir o mecanismo usado ao criar uma nova tabela e transfira os dados para a tabela compatível antes da restauração.
  • Se seu banco de dados do Azure de origem estiver em uma versão específica, seu servidor local de destino também terá a mesma versão do banco de dados do Azure de origem.

Assim, com essas limitações, você espera apenas que seus dados do Azure tenham que ser o mecanismo de armazenamento InnoDB ou a Memória, se houver em seu conjunto de dados.

Considerações de desempenho para fazer backup lógico do banco de dados do Azure

A única maneira de fazer um backup lógico com o Azure é usar mysqldump ou mysqlpump. Para otimizar o desempenho ao fazer um dump usando essas ferramentas, observe estas considerações ao fazer dump de bancos de dados grandes:

  • Use a opção exclude-triggers no mysqldump ao despejar bancos de dados. Exclua os gatilhos dos arquivos de despejo para evitar que os comandos do gatilho sejam disparados durante a restauração de dados.
  • Use a opção de transação única para definir o modo de isolamento da transação como REPEATABLE READ e envie uma instrução SQL START TRANSACTION ao servidor antes de despejar os dados. Despejar muitas tabelas em uma única transação faz com que algum armazenamento extra seja consumido durante a restauração. A opção de transação única e a opção lock-tables são mutuamente exclusivas porque LOCK TABLES faz com que quaisquer transações pendentes sejam confirmadas implicitamente. Para despejar tabelas grandes, combine a opção de transação única com a opção rápida.
  • Use a sintaxe de várias linhas de inserção estendida que inclui várias listas VALUE. Isso resulta em um arquivo de despejo menor e acelera as inserções quando o arquivo é recarregado.
  • Use a opção order-by-primary no mysqldump ao despejar bancos de dados, para que os dados sejam roteirizados na ordem da chave primária.
  • Use a opção disable-keys no mysqldump ao despejar dados, para desabilitar as restrições de chave estrangeira antes do carregamento. A desativação das verificações de chave estrangeira fornece ganhos de desempenho. Ative as restrições e verifique os dados após o carregamento para garantir a integridade referencial.
  • Use tabelas particionadas quando apropriado.
  • Carregar dados em paralelo. Evite muito paralelismo que faria com que você atingisse um limite de recursos e monitore os recursos usando as métricas disponíveis no portal do Azure.
  • Use a opção defer-table-indexes no mysqlpump ao despejar bancos de dados, para que a criação do índice ocorra depois que os dados da tabela forem carregados.
  • Use a opção skip-definer no mysqlpump para omitir as cláusulas definer e SQL SECURITY das instruções create para views e stored procedures. Quando você recarrega o arquivo de despejo, ele cria objetos que usam os valores padrão DEFINER e SQL SECURITY.
  • Copie os arquivos de backup para um blob/store do Azure e execute a restauração a partir daí, o que deve ser muito mais rápido do que realizar a restauração pela Internet.

Não suportado

Os itens a seguir não são compatíveis:

  • Função de DBA:Restrita. Como alternativa, você pode usar o usuário administrador (criado durante a criação do novo servidor), que permite executar a maioria das instruções DDL e DML.
  • Privilégio SUPER:Da mesma forma, o privilégio SUPER é restrito.
  • DEFINER:Requer superprivilégios para criar e é restrito. Se estiver importando dados usando um backup, remova os comandos CREATE DEFINER manualmente ou usando o comando --skip-definer ao executar um mysqldump.
  • Bancos de dados do sistema:O banco de dados do sistema mysql é somente leitura e usado para dar suporte a várias funcionalidades de PaaS. Você não pode fazer alterações no banco de dados do sistema mysql.
  • SELECT ... INTO OUTFILE:não suportado no serviço.

Usando mysqldump

O uso do mysqldump deve ser instalado em seu nó de banco de dados de destino localizado no local. Ele deve ser preparado como uma réplica do nó do Banco de Dados do Azure para que todas as transações subsequentes sejam replicadas para o nó. Para fazer isso, siga as etapas abaixo.

Instalar mysqldump

  1. Prepare o repositório.

# Para MySQL 

$ yum install https://dev.mysql.com/get/mysql80-community-release-el7-3.noarch.rpm

# Para MariaDB 
$ curl -sS https://downloads.mariadb.com/MariaDB/mariadb_repo_setup | sudo bash


  1. Instalar o pacote mysql-client


# Para MySQL 
$ yum install -y mysql-community-client.x86_64

# Para MariaDB 

$ yum install -y MariaDB-client

  1. Crie um dump de dados usando mysqldump executando-o dentro do nó de destino. 

$ MYSQL_PWD=<YOUR_MYSQL_PASS> mysqldump -h<YOUR_AZURE_DB_HOSTNAME>  -u<YOUR_AZURE_USERNAME> --single-transaction --master-data=2 --extended-insert --order-by-primary --disable-keys --databases maximusdb db2 db3 > backups/dump.sql

  1. Instale o servidor MySQL/MariaDB no nó do banco de dados de destino

# Para MySQL 

$  yum install mysql-community-server.x86_64 mysql-community-client mysql-community-common

# Para MariaDB 
$ yum install MariaDB-server.x86_64

  1. Configure a instância do servidor MySQL/MariaDB (my.cnf, permissões de arquivo, diretórios) e inicie o servidor

# Configurando o my.cnf (usando a implantação my.cnf usada pelo ClusterControl) 

[MYSQLD]

user=mysql

basedir=/usr/

datadir=/var/lib/mysql

socket=/var/lib/mysql/mysql.sock

pid_file=/var/lib/mysql/mysql.pid

port=3306

log_error=/var/log/mysql/mysqld.log

log_warnings=2

slow_query_log_file=/var/log/mysql/mysql-slow.log

long_query_time=2

slow_query_log=OFF

log_queries_not_using_indexes=OFF

innodb_buffer_pool_size=2G

innodb_flush_log_at_trx_commit=2

innodb_file_per_table=1

innodb_data_file_path=ibdata1:100M:autoextend

innodb_read_io_threads=4

innodb_write_io_threads=4

innodb_doublewrite=1

innodb_log_file_size=256M

innodb_log_buffer_size=32M

innodb_buffer_pool_instances=1

innodb_log_files_in_group=2

innodb_thread_concurrency=0

innodb_flush_method=O_DIRECT

innodb_rollback_on_timeout=ON

innodb_autoinc_lock_mode=2

innodb_stats_on_metadata=0

default_storage_engine=innodb

server_id=1126

binlog_format=ROW

log_bin=binlog

log_slave_updates=1

relay_log=relay-bin

expire_logs_days=7

read_only=OFF

report_host=192.168.10.226

key_buffer_size=24M

tmp_table_size=64M

max_heap_table_size=64M

max_allowed_packet=512M

skip_name_resolve=true

memlock=0

sysdate_is_now=1

max_connections=500

thread_cache_size=512

query_cache_type=0

query_cache_size=0

table_open_cache=1024

lower_case_table_names=0

performance_schema=OFF

performance-schema-max-mutex-classes=0

performance-schema-max-mutex-instances=0



[MYSQL]

socket=/var/lib/mysql/mysql.sock



[client]

socket=/var/lib/mysql/mysql.sock



[mysqldump]

socket=/var/lib/mysql/mysql.sock

max_allowed_packet=512M

## Redefina o diretório de dados e reinstale os arquivos do sistema de banco de dados 
$ rm -rf /var/lib/mysql/*

## Crie os diretórios de log 
$ mkdir /var/log/mysql

$ chown -R mysql.mysql /var/log/mysql

## Para MySQL 
$ mysqld --initialize

## Para MariaDB 
$ mysql_install_db

  1. Iniciar o servidor MySQL/MariaDB

## Para MySQL 

$ systemctl start mysqld

## Para MariaDB 

$ systemctl start mariadb

  1. Carregar o despejo de dados que tiramos do Banco de Dados do Azure para o nó do banco de dados de destino no local 

$ mysql --show-warnings < backups/dump.sql

  1. Crie o usuário de replicação de seu nó de origem do Banco de Dados do Azure 

CREATE USER 'repl_user'@'<your-target-node-ip>' IDENTIFIED BY 'repl_passw0rd';

GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO [email protected]'<your-target-node-ip>' IDENTIFIED BY 'repl_passw0rd';

Certifique-se de alterar o endereço IP do endereço IP do nó de destino como o cliente do qual se conectar.

  1. Configurar o servidor MySQL/MariaDB como uma réplica/escravo do nó de origem do Banco de Dados do Azure

## Primeiro, vamos pesquisar ou localizar o comando CHANGE MASTER 

$ grep -rn -E -i 'change master to master' backups/dump.sql |head -1

22:-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000006', MASTER_LOG_POS=2938610;

## Execute a instrução CHANGE MASTER, mas adicione o usuário/senha de replicação e o nome do host da seguinte maneira, 

CHANGE MASTER TO MASTER_HOST='<YOUR_AZURE_DB_HOSTNAME>', MASTER_LOG_FILE='mysql-bin.000006', MASTER_LOG_POS=2938610, MASTER_USER='repl_user', MASTER_PASSWORD='repl_passw0rd';

## Em alguns casos, você pode ter que ignorar o esquema mysql. Execute a seguinte instrução:

SET GLOBAL replicate_wild_ignore_table='mysql.%';

## Em seguida, inicie os threads escravos 

START SLAVE;

## Verifique o status do escravo como está 

SHOW SLAVE STATUS \G

Agora que finalmente conseguimos replicar do Banco de Dados do Azure para MySQL/MariaDB como a origem de sua réplica localizada no local.

Usando meudumper

O Banco de Dados do Azure para MySQL ou MariaDB na verdade sugere que usar o mydumper especialmente para backups grandes, como 1 TB, pode ser sua opção alternativa. Ele oferece paralelismo e velocidade ao fazer um dump ou cópia de backup de seu conjunto de dados de um nó de banco de dados do Azure de origem.

 Siga as etapas abaixo, desde a instalação do mydumper até o carregamento no servidor local de destino.

  1. Instale o binário. Os binários podem ser localizados aqui https://github.com/maxbube/mydumper/releases. 

 $ yum install https://github.com/maxbube/mydumper/releases/download/v0.9.5/mydumper-0.9.5-2.el6.x86_64.rpm

  1. Faça o backup do nó de origem do Banco de Dados do Azure. Por exemplo, 

[[email protected] mydumper]# MYSQL_PWD=<YOUR_AZURE_DB_PASSWORD> /usr/bin/mydumper --outputdir=. --verbose=3 --host=<YOUR_AZURE_DB_HOSTNAME>  -u <YOUR_AZURE_USER>@<YOUR_AZURE_DB_HOSTNAME> --port=3306 --kill-long-queries --chunk-filesize=5120 --build-empty-files --events --routines --triggers --compress --less-locking --success-on-1146 --regex='(maximusdb\.|db1\.|db2\.)'

** Message: Connected to a MySQL server

** Message: Using Percona Backup Locks



** (mydumper:28829): CRITICAL **: Couldn't acquire LOCK BINLOG FOR BACKUP, snapshots will not be consistent: You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near 'BINLOG FOR BACKUP' at line 1

** Message: Started dump at: 2020-10-26 01:34:05



** Message: Written master status

** Message: Multisource slave detected.

** Message: Thread 5 connected using MySQL connection ID 64315

** Message: Thread 6 connected using MySQL connection ID 64345

** Message: Thread 7 connected using MySQL connection ID 64275

** Message: Thread 8 connected using MySQL connection ID 64283

** Message: Thread 1 connected using MySQL connection ID 64253

** Message: Thread 2 connected using MySQL connection ID 64211

** Message: Thread 3 connected using MySQL connection ID 64200

** Message: Thread 4 connected using MySQL connection ID 64211



** (mydumper:28829): CRITICAL **: Error: DB: mysql - Could not execute query: Access denied for user 'mysqldbadmin'@'%' to database 'mysql'

** Message: Thread 5 shutting down

** Message: Thread 6 shutting down

** Message: Thread 7 shutting down

** Message: Thread 8 shutting down

** Message: Thread 1 dumping data for `db1`.`TB1`

** Message: Thread 2 dumping data for `db1`.`tb2

….

Como você pode ver, há uma limitação de fazer backup de um banco de dados gerenciado, como o Azure. Você pode notar, 

** (mydumper:28829): CRITICAL **: Couldn't acquire LOCK BINLOG FOR BACKUP, snapshots will not be consistent: You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near 'BINLOG FOR BACKUP' at line 1

Isso ocorre porque SUPER PRIVILEGE não é suportado ou restrito. Idealmente, a melhor opção para fazer isso é fazer o backup de uma réplica do seu Banco de Dados do Azure. Falaremos sobre isso mais tarde.

Agora, neste ponto, mydumper fará um backup de arquivos na forma de arquivos *.gz

  1. Carregue-o no servidor local de destino 

$ myloader --host localhost --directory=$(pwd) --queries-per-transaction=10000 --threads=8 --compress-protocol --verbose=3

** Message: 8 threads created

** Message: Creating database `maximusdb`

** Message: Creating table `maximusdb`.`usertbl`

** Message: Creating table `maximusdb`.`familytbl`

** Message: Creating table `db2`.`t1`

** Message: Creating table `db3`.`test1`

…

….

  1. Configure o nó de destino como escravo/réplica. mydumper incluirá um arquivo chamado metadados que consiste em coordenadas de log binário, incluindo posições GTID, por exemplo:

$ cat metadata

Started dump at: 2020-10-26 01:35:12

SHOW MASTER STATUS:

        Log: mysql-bin.000007

        Pos: 801

        GTID:0-3649485694-1705



Finished dump at: 2020-10-26 01:37:12

## Em seguida, execute um mestre de alterações da réplica ou do nó de banco de dados MySQL/MariaDB de destino de destino 

CHANGE MASTER TO MASTER_HOST='<YOUR_AZURE_DB_HOSTNAME>', MASTER_LOG_FILE='mysql-bin.000007', MASTER_LOG_POS=801, MASTER_USER='repl_user', MASTER_PASSWORD='repl_passw0rd';

## Inicie o slave 

START SLAVE;

Neste ponto, você já replicou de uma instância do Banco de Dados do Azure executando MySQL/MariaDB. Quando seu aplicativo estiver pronto para sair de sua instância de banco de dados do Azure, configure o ponto de extremidade indo para seu servidor local e todas as transações restantes de sua instância do Azure serão replicadas para seu local, não deixando nenhum dado perdido no seu local. servidor prem.

Lidando com limitações com bancos de dados gerenciados para MySQL ou MariaDB no Azure

Lidar com limitações, especialmente ao fazer um dump de backup do seu conjunto de dados, deve ser 100% preciso a partir do momento em que você fez o dump de backup. Obviamente, essa é uma migração ideal para seu local. Para lidar com isso, a melhor configuração de arquitetura é ter uma presença de topologia de replicação em seu banco de dados do Azure.

Depois de tê-lo e pronto para migração, o mysqldump/mysqlpump ou mydumper precisa usar a réplica do Banco de Dados do Azure como sua origem. Dentro dessa réplica do Banco de Dados do Azure, certifique-se de que o SQL_THREAD seja interrompido para que você possa fazer um instantâneo ou registrar o MASTER_LOG_FILE e EXEC_MASTER_LOG_POS corretos do resultado de SHOW SLAVE STATUS.

Claro, uma vez feito o backup, não se esqueça de iniciar sua réplica do Banco de Dados do Azure para iniciar seus threads de replicação novamente.

Verificar discrepâncias de dados

Depois de ter seus dados carregados ou despejados em seu servidor local atuando como uma réplica da instância do Banco de Dados do Azure, você deve verificar isso executando cálculos de soma de verificação para determinar até que ponto seus dados estão em relação ao banco de dados do Azure de origem. Sugerimos que você use a ferramenta pt-table-checksum do Percona Toolkit, mas você pode criar a sua própria usando ferramentas de soma de verificação como md5 ou sha256, mas isso leva tempo. Além disso, o uso de pt-upgrade do Percona Toolkit também pode ajudar após a migração de dados usando essa abordagem de replicação.

Conclusão

As limitações de privilégios e tipos sem suporte do Banco de Dados do Azure podem ser desafiadoras, mas com o fluxo e a arquitetura apropriados, não é impossível migrar de um banco de dados totalmente gerenciado no local. Tudo o que você precisa fazer é preparar as etapas necessárias, configurar a topologia necessária de sua fonte de banco de dados do Azure e iniciar a migração de fazer backups para replicação e migração total para seu local.