Dividir o backup

Servidor de banco de dados grande, mas bancos de dados individuais pequenos: é uma boa abordagem quando o tamanho total do servidor de banco de dados é de vários TBs, mas o tamanho de cada banco de dados de usuário individual e independente é menor que 1 TB. Para reduzir o período geral de migração, você pode migrar bancos de dados individuais separada e paralelamente.

Vamos usar um exemplo de um servidor de banco de dados on-premises de 2 TB. Esse servidor consiste em quatro bancos de dados, cada um com 0,5 TB. Você pode fazer backups de cada banco de dados individual separadamente. Ao restaurar o backup, você pode restaurar todos os bancos de dados em uma instância em paralelo ou, se os bancos de dados forem independentes, você poderá restaurar cada backup em uma instância separada. É uma prática recomendada restaurar bancos de dados independentes em instâncias separadas, em vez de restaurá-los na mesma instância. Para obter mais informações, consulte as práticas recomendadas neste guia.

Servidor de banco de dados grande, mas tabelas de bancos de dados individuais pequenas: é uma boa abordagem quando o tamanho total do servidor de banco de dados é de vários TBs, mas o tamanho de cada banco de dados de usuário individual e independente é menor que 1 TB. Para reduzir o período geral de migração, você pode migrar tabelas independentes individualmente.

Vamos usar um exemplo de um único banco de dados de usuário de 1 TB e ele é o único banco de dados em um servidor de banco de dados on-premises. Há dez tabelas no banco de dados, e cada uma tem 100 GB. Você pode fazer backups de cada tabela individual separadamente. Ao restaurar o backup, você pode restaurar todas as tabelas em uma instância em paralelo.

Um banco de dados contém tabelas de workloads transacionais e não transacionais: semelhante ao caso de uso anterior, você pode usar uma abordagem de backup dividido quando você tem tabelas de workloads transacionais e não transacionais no mesmo banco de dados.

Vamos usar um exemplo de um banco de dados de 2 TB que consiste em 0,5 TB de tabelas de workloads críticas usadas para processamento de transações on-line (OLTP) e uma única tabela de 1,5 TB usada para arquivar dados antigos. Você pode fazer o backup de todos os objetos do banco de dados, exceto da tabela de arquivamento, como um backup consistente e de transação única. Em seguida, você faz outro backup separado somente da tabela de arquivamento. Para o backup da tabela de arquivamento, você também pode considerar fazer vários backups paralelos usando condições para dividir o número de linhas no arquivo de backup. Veja um exemplo a seguir:

mysqldump -p your_db1 --tables your_table1 --where="column1 between 1 and 1000000 " > your_table1_part1.sql
mysqldump -p your_db1 --tables your_table1 --where="column1 between 1000001 and 2000000 " > your_table1_part2.sql
mysqldump -p your_db1 --tables your_table1 --where="column1 > 2000000 " > your_table1_part3.sql

Ao restaurar os arquivos de backup, você pode restaurar o backup da workload transacional e o backup da tabela de arquivamento em paralelo.

Limitações de recursos computacionais: se você tiver recursos computacionais limitados no servidor on-premises, como CPU, memória ou E/S de disco, isso pode afetar a estabilidade e a performance ao fazer o backup. Em vez de fazer um backup completo, você pode dividi-lo em partes.

Por exemplo, um servidor de produção on-premises pode estar sobrecarregado com workloads e ter recursos de CPU limitados. Se você fizer um backup de execução única de um banco de dados de vários terabytes nesse servidor, ele poderá consumir recursos adicionais da CPU e afetar adversamente o servidor de produção. Em vez de fazer o backup completo do banco de dados, divida o backup em várias partes, como duas a três tabelas cada.