Copia de seguridad dividida

Una estrategia de copia de seguridad dividida consiste en migrar un servidor de bases de datos grande dividiendo la copia de seguridad en varias partes. Puede utilizar diferentes enfoques para migrar cada parte de la copia de seguridad. Esta puede ser la mejor opción para los siguientes casos de uso:

• Servidor de bases de datos grande pero bases de datos individuales pequeñas: este es un buen enfoque cuando el tamaño total del servidor de bases de datos es de varios TB, pero el tamaño de cada base de datos de usuario individual e independiente es inferior a 1 TB. Para reducir el período de migración general, puede migrar bases de datos individuales por separado y en paralelo.

  Usemos un ejemplo de un servidor de base de datos local de 2 TB. Este servidor consta de cuatro bases de datos de 0,5 TB cada una. Puede realizar copias de seguridad de cada base de datos individual por separado. Al restaurar la copia de seguridad, puede restaurar todas las bases de datos de una instancia en paralelo o, si las bases de datos son independientes, puede restaurar cada copia de seguridad en una instancia independiente. Se recomienda restaurar bases de datos independientes en instancias distintas, en lugar de restaurarlas en la misma instancia. Para obtener más información, consulta las prácticas recomendadas en esta guía.

• Servidor de base de datos grande pero tablas de bases de datos individuales pequeñas: este es un buen enfoque cuando el tamaño total del servidor de base de datos es de varios TB, pero el tamaño de cada tabla de base de datos independiente es inferior a 1 TB. Para reducir el período de migración general, puede migrar tablas independientes de forma individual.

  Usemos un ejemplo de una base de datos de un solo usuario de 1 TB y que es la única base de datos de un servidor de bases de datos local. Hay 10 tablas en la base de datos y cada una tiene 100 GB. Puede realizar copias de seguridad de cada tabla individual por separado. Al restaurar la copia de seguridad, puedes restaurar todas las tablas de una instancia en paralelo.

• Una base de datos contiene tablas de cargas de trabajo transaccionales y no transaccionales. Al igual que en el caso de uso anterior, puede utilizar un enfoque de copia de seguridad dividida cuando tiene tablas de cargas de trabajo transaccionales y no transaccionales en la misma base de datos.

  Usemos un ejemplo de una base de datos de 2 TB que consta de 0,5 TB de tablas de cargas de trabajo críticas que se utilizan para el procesamiento de transacciones en línea (OLTP) y una sola tabla de 1,5 TB que se utiliza para archivar datos antiguos. Puede realizar la copia de seguridad de todos los objetos de la base de datos, excepto la tabla de archivado, como una copia de seguridad coherente y de una sola transacción. A continuación, realiza otra copia de seguridad independiente únicamente de la tabla de archivado. Para la copia de seguridad de la tabla de archivado, también puede considerar la posibilidad de realizar varias copias de seguridad paralelas utilizando condiciones para dividir el número de filas del archivo de copia de seguridad. A continuación, se muestra un ejemplo:

  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

  Al restaurar los archivos de copia de seguridad, puede restaurar la copia de seguridad de la carga de trabajo transaccional y la copia de seguridad de la tabla de archivado en paralelo.

• Limitaciones de recursos informáticos: si tiene recursos informáticos limitados en el servidor local, como la CPU, la memoria o las E/S del disco, esto puede afectar a la estabilidad y al rendimiento al realizar la copia de seguridad. En lugar de realizar una copia de seguridad completa, puede dividirla en partes.

  Por ejemplo, un servidor de producción local puede estar muy cargado de cargas de trabajo y tener recursos de CPU limitados. Si realiza una copia de seguridad de una sola ejecución de una base de datos de varios terabytes en este servidor, puede consumir recursos de CPU adicionales y afectar negativamente al servidor de producción. En lugar de realizar la copia de seguridad completa de la base de datos, divida la copia de seguridad en varias partes, por ejemplo, de 2 a 3 tablas cada una.