Backup e restauração no ClickHouse

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.

Embora a replicação ofereça proteção contra falhas de hardware, ela não protege contra erros humanos: exclusão acidental de dados, exclusão da tabela errada ou de uma tabela no cluster errado, e bugs de software que resultam em processamento incorreto de dados ou corrupção de dados.

Em muitos casos, erros como esses afetam todas as réplicas. O ClickHouse tem salvaguardas integradas para evitar alguns tipos de erro; por exemplo, por padrão você não pode simplesmente excluir tabelas com um motor da família 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.

As páginas a seguir detalham os vários métodos de backup e restauração disponíveis no ClickHouse:

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

Os backups podem ser completos ou incrementais. Os backups completos são uma cópia completa dos dados, enquanto os backups incrementais contêm apenas as alterações nos dados desde o último backup completo.

Os backups completos têm a vantagem de serem um método de recuperação simples, independente (de outros backups) e confiável. No entanto, podem levar muito tempo para serem concluídos e podem consumir muito espaço. Os backups incrementais, por outro lado, são mais eficientes tanto em termos de tempo quanto de espaço, mas a restauração dos dados exige que todos os backups estejam disponíveis.

Dependendo das suas necessidades, você pode optar por usar:

• 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.

Os comandos 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.

Por padrão, o ClickHouse permite backups e restaurações concorrentes. Isso significa que você pode iniciar várias operações de backup ou restauração simultaneamente. No entanto, há configurações no nível do servidor que permitem desativar esse comportamento. Se você definir essas configurações como false, apenas uma operação de backup ou restauração poderá ser executada em um cluster por vez. Isso pode ajudar a evitar contenção de recursos ou possíveis conflitos entre operações.

Para desativar backups/restaurações concorrentes, você pode usar estas configurações, respectivamente:

<clickhouse>
    <backups>
        <allow_concurrent_backups>false</allow_concurrent_backups>
        <allow_concurrent_restores>false</allow_concurrent_restores>
    </backups>
</clickhouse>

O valor padrão de ambos é true, então, por padrão, backups/restaurações concorrentes são permitidos. Quando essas configurações são false em um cluster, apenas um único backup/restauração pode ser executado no cluster por vez.

Os backups do ClickHouse suportam compactação por meio das configurações compression_method e compression_level.

Ao criar um backup, você pode especificar:

BACKUP TABLE test.table
  TO Disk('backups', 'filename.zip')
  SETTINGS compression_method='lzma', compression_level=3

Coleções nomeadas permitem armazenar pares chave-valor (como credenciais do S3, endpoints e configurações) que podem ser reutilizados em operações de backup e restauração. Elas ajudam a:

• 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

Consulte "coleções nomeadas" para mais detalhes.

As tabelas de sistema também podem ser incluídas nos seus fluxos de trabalho de backup e restauração, mas isso depende do seu caso de uso específico.

Tabelas de sistema que armazenam dados históricos, como aquelas com o sufixo _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.

-- comandos principais
BACKUP | RESTORE 
--- o que incluir no backup/restaurar (ou excluir)
TABLE [db.]table_name           [AS [db.]table_name_in_backup] |
DICTIONARY [db.]dictionary_name [AS [db.]name_in_backup] |
DATABASE database_name          [AS database_name_in_backup] |
TEMPORARY TABLE table_name      [AS table_name_in_backup] |
VIEW view_name                  [AS view_name_in_backup] |
[EXCEPT TABLES ...] |
ALL [EXCEPT {TABLES|DATABASES}...] } [,...]
--- 
[ON CLUSTER 'cluster_name']
--- destino ou origem do backup ou restauração
TO|FROM 
File('<path>/<filename>') | 
Disk('<disk_name>', '<path>/') | 
S3('<S3 endpoint>/<path>', '<Access key ID>', '<Secret access key>', '<extra_credentials>') |
AzureBlobStorage('<connection string>/<url>', '<container>', '<path>', '<account name>', '<account key>')
--- configurações adicionais
[SETTINGS ...]
[ASYNC]

Consulte "resumo dos comandos" para obter mais detalhes sobre cada comando.

Cada um dos comandos acima é detalhado a seguir:

Configurações genéricas de backup e restauração

Configurações específicas do S3

Configurações específicas do Azure

O comando de backup retorna um 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:

BACKUP TABLE helloworld.my_first_table TO Disk('backups', '1.zip') ASYNC

┌─id───────────────────────────────────┬─status──────────┐
│ 7678b0b3-f519-4e6e-811f-5a0781a4eb52 │ CREATING_BACKUP │
└──────────────────────────────────────┴─────────────────┘

1 row in set. Elapsed: 0.001 sec.

SELECT
*
FROM system.backups
WHERE id='7678b0b3-f519-4e6e-811f-5a0781a4eb52'
FORMAT Vertical

Row 1:
──────
id:                7678b0b3-f519-4e6e-811f-5a0781a4eb52
name:              Disk('backups', '1.zip')
status:            BACKUP_FAILED
num_files:         0
uncompressed_size: 0
compressed_size:   0
error:             Code: 598. DB::Exception: Backup Disk('backups', '1.zip') already exists. (BACKUP_ALREADY_EXISTS) (version 22.8.2.11 (official build))
start_time:        2022-08-30 09:21:46
end_time:          2022-08-30 09:21:46

1 row in set. Elapsed: 0.002 sec.

Além da tabela 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:

SELECT *
FROM system.backup_log
WHERE id = '7678b0b3-f519-4e6e-811f-5a0781a4eb52'
ORDER BY event_time_microseconds ASC
FORMAT Vertical

Row 1:
──────
event_date:              2023-08-18
event_time_microseconds: 2023-08-18 11:13:43.097414
id:                      7678b0b3-f519-4e6e-811f-5a0781a4eb52
name:                    Disk('backups', '1.zip')
status:                  CREATING_BACKUP
error:
start_time:              2023-08-18 11:13:43
end_time:                1970-01-01 03:00:00
num_files:               0
total_size:              0
num_entries:             0
uncompressed_size:       0
compressed_size:         0
files_read:              0
bytes_read:              0

Row 2:
──────
event_date:              2023-08-18
event_time_microseconds: 2023-08-18 11:13:43.174782
id:                      7678b0b3-f519-4e6e-811f-5a0781a4eb52
name:                    Disk('backups', '1.zip')
status:                  BACKUP_FAILED
error:                   Code: 598. DB::Exception: Backup Disk('backups', '1.zip') already exists. (BACKUP_ALREADY_EXISTS) (version 23.8.1.1)
start_time:              2023-08-18 11:13:43
end_time:                2023-08-18 11:13:43
num_files:               0
total_size:              0
num_entries:             0
uncompressed_size:       0
compressed_size:         0
files_read:              0
bytes_read:              0

2 rows in set. Elapsed: 0.075 sec.