Esta sección ofrece una visión general de las copias de seguridad y la restauración en ClickHouse. Para obtener una descripción más detallada de cada método de copia de seguridad, consulta las páginas de cada método específico en la barra lateral.
Introducción
MergeTree que contengan más de
50 Gb de datos. Sin embargo, estas protecciones no cubren todos los casos posibles y
los problemas pueden seguir ocurriendo.
Para mitigar eficazmente los posibles errores humanos, debe preparar cuidadosamente una
estrategia para realizar copias de seguridad y restaurar sus datos con antelación.
Cada empresa dispone de recursos diferentes y tiene requisitos de negocio distintos, por lo que
no existe una solución universal de copias de seguridad y restauración en ClickHouse que se adapte a
todas las situaciones. Lo que funciona para un gigabyte de datos probablemente no funcionará para decenas
de petabytes de datos. Existen varios enfoques posibles, cada uno con sus propias ventajas
y desventajas, que se presentan en esta sección de la documentación. Conviene
usar varios enfoques en lugar de uno solo, para compensar sus distintas
limitaciones.
Tenga en cuenta que, si hizo una copia de seguridad de algo y nunca intentó restaurarla,
lo más probable es que la restauración no funcione correctamente cuando realmente la necesite (o, al
menos, tardará más de lo que la empresa puede tolerar). Por eso, sea cual sea el enfoque de copia de seguridad
que elija, asegúrese de automatizar también el proceso de restauración y practíquelo
regularmente en un clúster de ClickHouse de reserva.
Las copias de seguridad pueden:
- ser completas o incrementales
- ser sincrónicas o asincrónicas
- ser concurrentes o no concurrentes
- estar comprimidas o sin comprimir
- usar colecciones con nombre
- estar protegidas con contraseña
- hacerse de system tables, log tables o tablas de gestión de acceso
Tipos de copias de seguridad
- Copias de seguridad completas para bases de datos más pequeñas o datos críticos.
- Copias de seguridad incrementales para bases de datos más grandes o cuando sea necesario realizar copias de seguridad con frecuencia y de forma rentable.
- Ambas; por ejemplo, copias de seguridad completas semanales y copias de seguridad incrementales diarias.
Copias de seguridad síncronas vs. asíncronas
BACKUP y RESTORE también se pueden marcar como ASYNC. En este caso, el
comando de copia de seguridad devuelve el control de inmediato y el proceso de copia de seguridad se ejecuta en segundo plano.
Si los comandos no se marcan como ASYNC, el proceso de copia de seguridad es síncrono y
el comando queda bloqueado hasta que se completa la copia de seguridad.
Copias de seguridad concurrentes y no concurrentes
Copias de seguridad comprimidas y sin comprimir
compression_method y compression_level.
Al crear una copia de seguridad, puedes especificar:
Uso de colecciones con nombre
- Ocultar las credenciales a los usuarios sin acceso de administrador
- Simplificar los comandos al almacenar configuraciones complejas de forma centralizada
- Mantener la coherencia entre operaciones
- Evitar la exposición de credenciales en los logs de consultas
Copia de seguridad de tablas del sistema, de registro o de gestión de acceso
_log (p. ej.,
query_log, part_log), pueden incluirse en copias de seguridad y restaurarse como cualquier otra tabla.
Si su caso de uso depende del análisis de datos históricos —por ejemplo, usar query_log
para hacer un seguimiento del rendimiento de las consultas o depurar problemas—, se recomienda incluir estas
tablas en su estrategia de copia de seguridad. Sin embargo, si los datos históricos de estas tablas
no son necesarios, pueden excluirse para ahorrar espacio de almacenamiento.
Las tablas del sistema relacionadas con la gestión de acceso, como users, roles, row_policies,
settings_profiles y quotas, reciben un tratamiento especial durante las operaciones de copia de seguridad y restauración.
Cuando estas tablas se incluyen en una copia de seguridad, su contenido se exporta a un archivo especial
accessXX.txt, que contiene las sentencias SQL equivalentes para crear
y configurar las entidades de acceso. Durante la restauración, el proceso de restauración
interpreta estos archivos y vuelve a aplicar los comandos SQL para recrear los users,
roles y otras configuraciones. Esta funcionalidad garantiza que la configuración de control de acceso
de un clúster de ClickHouse pueda incluirse en una copia de seguridad y restaurarse como parte de
la configuración general del clúster.
Esta funcionalidad solo funciona para configuraciones gestionadas mediante comandos SQL
(conocidas como “Control de acceso y gestión de cuentas controlados por SQL”).
Las configuraciones de acceso definidas en los archivos de configuración del ClickHouse server (p. ej. users.xml)
no se incluyen en las copias de seguridad y no pueden restaurarse mediante este método.
Sintaxis general
Resumen de comandos
Configuración
Configuración específica de S3
Configuración específica de Azure
Administración y resolución de problemas
id y un status, y ese id puede usarse para
obtener el estado de la copia de seguridad. Esto es muy útil para comprobar el progreso de copias de seguridad
ASYNC prolongadas. El ejemplo siguiente muestra un error que se produjo al intentar
sobrescribir un archivo de copia de seguridad existente:
system.backups, todas las operaciones de copia de seguridad y restauración también quedan registradas en la tabla de registro del sistema
system.backup_log: