Skip to main content

Visão geral

Há dois métodos principais para migrar dados de um ClickHouse autogerenciado (OSS) para o ClickHouse Cloud:
  • Usar a função remoteSecure(), em que os dados são extraídos/enviados diretamente.
  • Usar os comandos BACKUP/RESTORE por meio de armazenamento de objetos na nuvem
Este guia de migração se concentra na abordagem BACKUP/RESTORE e oferece um exemplo prático de migração de um banco de dados ou de um serviço completo do ClickHouse open source para o ClickHouse Cloud por meio de um bucket do S3.
Pré-requisitos Para tornar as etapas deste guia fáceis de acompanhar e reproduzir, usaremos um dos exemplos de Docker Compose para um cluster do ClickHouse com dois shards e duas réplicas.
Cluster obrigatórioEste método de backup exige um cluster do ClickHouse porque as tabelas devem ser convertidas do engine MergeTree para ReplicatedMergeTree. Se você estiver executando uma instância única, siga as etapas em “Migrando entre ClickHouse autogerenciado e ClickHouse Cloud usando remoteSecure”.

Preparação do OSS

Primeiro, vamos subir um cluster ClickHouse usando uma configuração do Docker Compose do nosso repositório de exemplos. Você pode pular esta etapa se já tiver um cluster ClickHouse em execução.
  1. Clone o repositório de exemplos para sua máquina local
  2. No terminal, acesse examples/docker-compose-recipes/recipes/cluster_2S_2R com cd
  3. Certifique-se de que o Docker esteja em execução e, em seguida, inicie o cluster ClickHouse:
Você verá:
Em uma nova janela do terminal, na raiz da pasta, execute o seguinte comando para se conectar ao primeiro nó do cluster:

De tabela MergeTree para tabela ReplicatedMergeTree

O ClickHouse Cloud usa SharedMergeTree. Ao restaurar um backup, o ClickHouse converte automaticamente tabelas com ReplicatedMergeTree em tabelas SharedMergeTree. Se você estiver executando um cluster, é provável que suas tabelas já estejam usando o engine ReplicatedMergeTree. Caso contrário, será necessário converter todas as tabelas MergeTree para ReplicatedMergeTree antes de fazer o backup. Para demonstrar como converter tabelas MergeTree em ReplicatedMergeTree, vamos começar com uma tabela MergeTree e depois convertê-la para ReplicatedMergeTree. Vamos seguir as duas primeiras etapas do guia de dados de táxi de Nova York para criar uma tabela de exemplo e carregar dados nela. Essas etapas estão incluídas abaixo para facilitar. Execute os comandos a seguir para criar um novo banco de dados e inserir dados de um bucket do S3 em uma nova tabela:
Execute o comando a seguir para executar DETACH na tabela.
Em seguida, anexe-a como replicada:
Por fim, restaure os metadados da réplica:
Verifique se ela foi convertida para ReplicatedMergeTree:
Agora você já está pronto para prosseguir com a configuração do seu serviço no Cloud, preparando-se para mais tarde restaurar um backup do seu bucket do S3.

Tabelas distribuídas com ReplicatedMergeTree

Se a sua configuração utiliza tabelas distribuídas em vários shards, você precisará de uma tabela ReplicatedMergeTree local em cada nó e de uma tabela Distributed como ponto de entrada para consultas. Execute o comando a seguir para criar a tabela replicada local em todos os nós do cluster:
Em seguida, crie a tabela Distributed sobre essa tabela:
Insira dados na tabela distribuída:

Preparação no Cloud

Você restaurará seus dados em um novo serviço Cloud. Siga as etapas abaixo para criar um novo serviço Cloud.
1

Abra o Cloud Console

2

Crie um novo serviço

3

Configure e crie um serviço

Escolha a região e a configuração desejadas e clique em Create service
4

Crie uma role de acesso

Abra o SQL Console

Configure o acesso ao S3

Para restaurar seu backup do S3, você precisará configurar acesso seguro entre o ClickHouse Cloud e seu bucket do S3.
  1. Siga as etapas em “Acessar dados no S3 com segurança” para criar uma role de acesso e obter o ARN da role.
  2. Atualize a política do bucket do S3 que você criou em “Como criar um bucket do S3 e uma IAM role”, adicionando o ARN da role da etapa anterior.
Sua política atualizada para o bucket do S3 ficará mais ou menos assim:
A política inclui ambos os ARNs:
  • Usuário do IAM (docs-s3-user): Permite que seu cluster ClickHouse autogerenciado faça backup no S3
  • Role do ClickHouse Cloud (ClickHouseAccess-001): Permite que seu serviço Cloud restaure a partir do S3

Fazendo o backup (na implantação autogerenciada)

Cada shard deve ser submetido a backup de forma independente. Conecte-se a um nó em cada shard e execute o comando de backup com um caminho de destino exclusivo para cada shard. Substitua BUCKET_URL, KEY_ID e SECRET_KEY pelas suas próprias credenciais da AWS. O guia “Como criar um bucket do S3 e uma IAM role” mostra como obtê-las caso você ainda não as tenha. Shard 1:
Shard 2:
Se tudo estiver configurado corretamente, você verá uma resposta semelhante à mostrada abaixo, contendo um ID exclusivo atribuído ao backup e o status do backup.
Implantações de nó únicoSe você não estiver usando tabelas distribuídas, poderá fazer backup do banco de dados inteiro com um único comando:
Ao verificar o bucket do S3, que antes estava vazio, você verá que algumas pastas apareceram: Se estiver realizando uma migração completa, você pode executar o comando a seguir para fazer backup de todo o servidor:
O comando acima faz backup de:
  • Todos os bancos de dados e tabelas de usuários
  • Contas de usuário e senhas
  • Roles e permissões
  • Perfis de configuração
  • Políticas por linha
  • Cotas
  • Funções Definidas pelo Usuário
Se você estiver usando um provedor de serviços em Cloud (CSP) diferente, poderá usar a sintaxe TO S3() (tanto para AWS quanto para GCP) e TO AzureBlobStorage(). Para bancos de dados muito grandes, considere usar ASYNC para executar o backup em segundo plano:
O ID do backup pode então ser usado para acompanhar o progresso do backup:
Também é possível fazer backups incrementais. Para mais detalhes sobre backups em geral, consulte a documentação sobre backup e restauração.

Restaurar no ClickHouse Cloud

Restaure o backup de cada shard, um de cada vez, no seu serviço Cloud. Defina ROLE_ARN como o valor obtido em “Acessar dados no S3 com segurança”. Use SETTINGS allow_non_empty_tables=true na segunda restauração (e em cada restauração subsequente) para que os dados do shard sejam adicionados às tabelas já restauradas, em vez de a operação falhar por conflito: Shard 1:
Shard 2:
implantações não distribuídasSe você não estiver usando tabelas distribuídas, restaure o banco de dados com um único comando:
Você também pode fazer uma restauração completa do serviço de forma semelhante:
Depois que a restauração for concluída, você poderá verificar se os dados estão disponíveis na Cloud:
Como o ClickHouse Cloud usa SharedMergeTree internamente, a antiga tabela distribuída não é mais necessária. Você pode removê-la e substituí-la por uma view que preserva o nome original da tabela nas suas consultas:
Tabelas ReplicatedMergeTree não distribuídas serão restauradas como SharedMergeTree:
Última modificação em 23 de julho de 2026