Backup dividido

Uma estratégia de backup dividido é quando você migra um grande servidor de banco de dados dividindo o backup em várias partes. Você pode usar abordagens diferentes para migrar cada parte do backup. Essa pode ser a melhor opção para os seguintes casos de uso:

• Servidor de banco de dados grande, mas bancos de dados individuais pequenos — Essa é 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 separadamente e paralelamente.

  Vamos usar um exemplo de um servidor de banco de dados local 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 melhores práticas neste guia.

• Servidor de banco de dados grande, mas pequenas tabelas de banco de dados individuais — Essa é uma boa abordagem quando o tamanho total do servidor de banco de dados é de vários TBs, mas o tamanho de cada tabela de banco de dados 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 é o único banco de dados em um servidor de banco de dados local. Há 10 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 carga de trabalho transacionais e não transacionais — Semelhante ao caso de uso anterior, você pode usar uma abordagem de backup dividido quando você tem tabelas de carga de trabalho 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 carga de trabalho 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 carga de trabalho transacional e o backup da tabela de arquivamento em paralelo.

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

  Por exemplo, um servidor de produção local pode estar sobrecarregado com cargas de trabalho 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 2 a 3 tabelas cada.