Esta seção apresenta uma visão geral de backups e restaurações no ClickHouse. Para uma descrição mais detalhada de cada método de backup, consulte as páginas dos métodos específicos na barra lateral.
Introdução
MergeTree contendo mais de
50 Gb de dados. No entanto, essas salvaguardas não cobrem todos os casos possíveis, e
problemas ainda podem ocorrer.
Para mitigar com eficácia possíveis erros humanos, você deve preparar cuidadosamente uma
estratégia de backup e restauração dos seus dados com antecedência.
Cada empresa tem recursos disponíveis e requisitos de negócio diferentes, portanto
não há uma solução universal de backups e restaurações do ClickHouse que sirva para
todas as situações. O que funciona para um gigabyte de dados provavelmente não funcionará para dezenas
de petabytes de dados. Há várias abordagens possíveis, cada uma com seus próprios prós
e contras, que são apresentadas nesta seção da documentação. É uma boa ideia
usar várias abordagens em vez de apenas uma, para compensar suas diferentes
limitações.
Lembre-se de que, se você fez backup de algo e nunca tentou restaurá-lo,
há grandes chances de que a restauração não funcione corretamente quando você realmente precisar dela (ou, pelo menos,
leve mais tempo do que a empresa pode tolerar). Portanto, qualquer que seja a abordagem de backup escolhida, certifique-se de automatizar também o processo de restauração e pratique-o
regularmente em um cluster ClickHouse de contingência.
Os backups podem:
- ser completos ou incrementais
- ser síncronos ou assíncronos
- ser concorrentes ou não concorrentes
- ser compactados ou não compactados
- usar coleções nomeadas
- ser protegidos por senha
- incluir tabelas de sistema, tabelas de log ou tabelas de gerenciamento de acesso
Tipos de backup
- Backups completos para bancos de dados menores ou dados críticos.
- Backups incrementais para bancos de dados maiores ou quando os backups precisam ser feitos com frequência e com bom custo-benefício.
- Ambos, por exemplo, backups completos semanais e backups incrementais diários.
Backups síncronos vs. assíncronos
BACKUP e RESTORE também podem ser marcados como ASYNC. Nesse caso, o
comando de backup retorna imediatamente, e o processo de backup é executado em segundo plano.
Se os comandos não forem marcados como ASYNC, o processo de backup será síncrono, e
o comando ficará bloqueado até que o backup seja concluído.
Backups concorrentes vs. não concorrentes
Backups compactados vs. não compactados
compression_method e compression_level.
Ao criar um backup, você pode especificar:
Usando coleções nomeadas
- Ocultar credenciais de usuários sem acesso de Admin
- Simplificar comandos armazenando configurações complexas de forma centralizada
- Manter a consistência entre as operações
- Evitar a exposição de credenciais nos logs de consultas
Backup de tabelas de sistema, de log ou de gerenciamento de acesso
_log (por exemplo,
query_log, part_log), podem ser submetidas a backup e restauração como qualquer outra tabela.
Se o seu caso de uso depender da análise de dados históricos — por exemplo, usar query_log
para acompanhar o desempenho de consultas ou depurar problemas —, é recomendável incluir essas
tabelas na sua estratégia de backup. No entanto, se os dados históricos dessas tabelas
não forem necessários, elas podem ser excluídas para economizar espaço de armazenamento de backup.
Tabelas de sistema relacionadas ao gerenciamento de acesso, como usuários, roles, row_policies,
settings_profiles e quotas, recebem tratamento especial durante as operações de backup e restauração.
Quando essas tabelas são incluídas em um backup, seu conteúdo é exportado para um arquivo especial
accessXX.txt, que contém as instruções SQL equivalentes para criar
e configurar as entidades de acesso. Durante a restauração, o processo
interpreta esses arquivos e reaplica os comandos SQL para recriar os usuários,
roles e outras configurações. Esse recurso garante que a configuração de controle
de acesso de um cluster ClickHouse possa ser submetida a backup e restauração como parte
da configuração geral do cluster.
Essa funcionalidade só funciona para configurações gerenciadas por meio de comandos SQL
(chamadas de “Controle de acesso e gerenciamento de contas orientados por SQL”).
As configurações de acesso definidas em arquivos de configuração do servidor ClickHouse (por exemplo, users.xml)
não são incluídas em backups e não podem ser restauradas por esse método.
Sintaxe geral
Resumo dos comandos
Configurações
Configurações específicas do S3
Configurações específicas do Azure
Administração e solução de problemas
id e um status, e esse id pode ser usado para
consultar o status do backup. Isso é muito útil para verificar o andamento de backups
longos ASYNC. O exemplo abaixo mostra uma falha que ocorreu ao tentar
sobrescrever um arquivo de backup existente:
system.backups, todas as operações de backup e restauração também são registradas na tabela de log do sistema
system.backup_log: