Alterar configuração para versão compatível com a comunidade do ClickHouse - ApsaraDB for ClickHouse: Central de Documentação do Alibaba Cloud

Para adaptar-se às mudanças nos requisitos de negócios, ajuste a configuração ou o tamanho do cluster do Alibaba Cloud ClickHouse Community-Compatible Edition. Realize dimensionamentos verticais e horizontais no cluster do Alibaba Cloud ClickHouse para alcançar o equilíbrio ideal entre custo e desempenho.

Visão geral do dimensionamento vertical e horizontal

O dimensionamento vertical é mais rápido e causa menos interrupções nos negócios do que o dimensionamento horizontal. Se o desempenho do cluster for insuficiente, considere primeiro o dimensionamento vertical.

Método de dimensionamento	Casos de uso	Como funciona	Impacto	Ações
Dimensionamento vertical	Ajusta os recursos do nó quando a capacidade de CPU, memória ou disco é insuficiente ou superdimensionada.	Aumenta ou diminui as especificações do nó, a capacidade de armazenamento e as especificações do ZooKeeper de um cluster do Alibaba Cloud ClickHouse Community-Compatible Edition, ajustando o poder de computação, a capacidade de armazenamento e as capacidades de coordenação distribuída. Nota Não é possível usar o dimensionamento vertical para reduzir a capacidade de armazenamento. As seguintes soluções estão disponíveis para essa finalidade: Em instâncias com vários nós, remova um nó para reduzir a capacidade de armazenamento conforme os requisitos de negócios. Em instâncias de nó único, crie uma nova instância e migre os dados para reduzir a capacidade de armazenamento.	Atualizar o tipo de armazenamento ou aumentar a capacidade de armazenamento de um cluster do Alibaba Cloud ClickHouse Community-Compatible Edition não afeta a instância (aplica-se apenas a instâncias criadas após 1º de dezembro de 2021). No entanto, alterar as especificações do cluster ou do ZooKeeper reinicia o cluster. Importante O dimensionamento vertical leva de 5 a 10 minutos. O tempo necessário para reiniciar um cluster depende do volume de dados. Quanto mais bancos de dados, tabelas e dados frios o cluster tiver, mais demorada será a reinicialização. Em clusters de réplica dupla, o dimensionamento pode causar interrupções transitórias de conexão durante a alternância de solicitações entre réplicas. Realize o dimensionamento fora dos horários de pico e garanta que a aplicação possua mecanismo de nova tentativa. Clusters de réplica única ficam indisponíveis durante todo o processo de dimensionamento. Execute esta operação fora dos horários de pico ou quando as operações de gravação estiverem suspensas, e garanta que a aplicação possua mecanismo de nova tentativa. Alterar as especificações do ZooKeeper durante horários de pico pode causar inconsistências entre metadados da tabela e dados reais. Execute esta operação fora dos horários de pico ou quando as operações de gravação estiverem suspensas.	Escalar verticalmente para cima ou para baixo
Scale-out	Scale-out com migração de dados: utilize este método quando for necessário redistribuir os dados do cluster após o scale-out. Scale-out simples: Utilize este método quando o cluster atender às seguintes condições: Antes do scale-out, os dados são gravados diretamente em tabelas locais ou em tabelas distribuídas cuja chave de fragmentação esteja definida como `rand`. Não há necessidade de rebalancear dados entre os nós. Importante Não use scale-out simples em clusters com tabelas que utilizam engines como ReplacingMergeTree, CollapsingMergeTree ou VersionedCollapsingMergeTree. Os dados nesses tipos de tabela só podem ser mesclados no mesmo nó. O scale-out simples dispersa os dados que precisam ser mesclados em diferentes nós, impedindo a mesclagem.	Scale-out com migração de dados: aumenta o número de nós em um cluster do Alibaba Cloud ClickHouse Community-Compatible Edition para escalar horizontalmente o poder de computação. Os dados existentes são migrados e redistribuídos. Scale-out simples: aumenta o número de nós em um cluster do Alibaba Cloud ClickHouse Community-Compatible Edition para escalar horizontalmente o poder de computação. Este método aplica-se quando os dados são gravados diretamente em tabelas locais e não é necessário rebalanceamento entre nós.	Operações DDL são proibidas durante todo o processo de scale-out. O uso de CPU e memória do cluster aumenta durante o processo de scale-out. A sobrecarga estimada de recursos é inferior a 5 núcleos de CPU e 20 GB de memória por nó. Após a conclusão do scale-out, ocorre um período de operações de mesclagem de alta frequência. Isso aumenta o uso de I/O e pode elevar a latência nas solicitações de negócios.	Scale out e scale in
Scale-in	Scale-in padrão: Reduz o número de nós para economizar custos. Os nós são removidos aleatoriamente. Não é possível especificar quais nós remover. Scale-in especificando nós: remove nós específicos em clusters com grandes especificações de armazenamento.	Reduz o número de nós em um cluster do Alibaba Cloud ClickHouse Community-Compatible Edition para diminuir custos.	Operações DDL são proibidas durante todo o processo de scale-in. O uso de CPU e memória do cluster aumenta durante o processo de scale-in. A sobrecarga estimada de recursos é inferior a 5 núcleos de CPU e 20 GB de memória por nó. Após a conclusão do scale-in, ocorre um período de operações de mesclagem de alta frequência. Isso aumenta o uso de I/O e pode elevar a latência nas solicitações de negócios.	Scale out e scale in

Pré-requisitos

O cluster deve ser Alibaba Cloud ClickHouse Community-Compatible Edition.
O status do cluster deve ser Running.
O cluster não deve ter pedidos de renovação pendentes de pagamento.

Nota
Faça login no console do Alibaba Cloud ClickHouse. No canto superior direito da página, escolha Fee > Expenses and Costs. No painel de navegação à esquerda, clique em Order Management e conclua o pagamento ou cancele o pedido.

Observações de uso

Dimensionamento vertical: é possível alterar as especificações do ZooKeeper apenas para clusters do Alibaba Cloud ClickHouse Community-Compatible Edition criados após 1º de dezembro de 2021. Para obter informações sobre preços das especificações do ZooKeeper, consulte Preços de especificações do ZooKeeper para Community-Compatible Edition.
Dimensionamento horizontal:
- Ao realizar o scale-out de um cluster com tabelas da família de engine MergeTree, o sistema migra os dados existentes para o novo cluster e os redistribui automaticamente.
  Conteúdo suportado para migração:
  - Bancos de dados, dicionários de dados e visualizações materializadas.
  - Esquema de tabela: todos os esquemas de tabela, exceto os de tabelas que usam a engine Kafka ou RabbitMQ.
  - Dados: os dados de tabelas que usam engines da família MergeTree são migrados incrementalmente.
  Conteúdo não suportado para migração:
  - Esquemas de tabela e dados de tabelas das engines Kafka e RabbitMQ.
    
    Importante
    Durante uma alteração de configuração, os dados são migrados para uma nova instância e o tráfego é eventualmente direcionado para ela. Para evitar que os dados sejam divididos entre Kafka e RabbitMQ, remova primeiro as tabelas dessas engines do cluster de origem. Recrie-as após a conclusão da alteração de configuração.
  - Dados em tabelas não-MergeTree, como tabelas externas e tabelas da família Log.
  Importante
  Durante o processo de dimensionamento, trate manualmente o conteúdo não suportado conforme descrito no procedimento.
- Operações DDL são proibidas durante todo o processo de dimensionamento horizontal. O descumprimento desta regra pode resultar em falhas na validação de dados e causar a falha do dimensionamento.
- Após um scale-out, os endereços IP internos dos nós mudam. Se a aplicação depender de endereços IP de nó para gravação e acesso a dados, obtenha o novo bloco CIDR da VPC do cluster. Para mais informações, consulte Obter o bloco CIDR da VPC de um cluster.
- Apenas clusters baseados em disco local suportam scale-in especificando nós. Neste modo, os dados nos nós removidos serão perdidos. No modo de scale-in padrão, o sistema não perde dados, mas os redistribui.
Após a alteração da configuração do cluster, ocorre um período de operações de mesclagem de alta frequência. Isso aumenta o uso de I/O e pode elevar a latência nas solicitações de negócios. Planeje com antecedência para mitigar o impacto potencial da latência. Para obter informações sobre como calcular a duração da mesclagem, consulte Calcular a duração da mesclagem após a migração.
Durante a alteração da configuração do cluster, o uso de CPU e memória aumenta. A sobrecarga estimada de recursos é inferior a 5 núcleos de CPU e 20 GB de memória por nó.

Faturamento

Após alterar a configuração do cluster, as taxas são ajustadas. O custo real exibido no console prevalece. Para mais informações, consulte Faturamento para alterações de configuração.

Escalar verticalmente para cima e para baixo

Importante

Para obter informações sobre os impactos do dimensionamento vertical, consulte Visão geral do dimensionamento vertical e horizontal e Observações de uso.

Faça login no console do Alibaba Cloud ClickHouse. No canto superior esquerdo da página, selecione a região onde o cluster está localizado.
Na página Clusters, clique em Clusters of Community-compatible Edition.
Na coluna Actions do cluster de destino, clique em Change Configurations.
Na caixa de diálogo Change Configurations, selecione Scale Up ou Scale Down e clique em OK.
Na página Change Specification ou Scale Down, selecione as configurações desejadas conforme os requisitos de negócios.
Nota
- Não é possível modificar simultaneamente a Storage Capacity ou o Storage Type e a Specification ao executar a Change Specification.
- Por padrão, os clusters vêm com especificações do ZooKeeper de 4 núcleos de CPU e 8 GB de memória. Na página Monitoring and Alerting, visualize as métricas do ZooKeeper no painel Cluster Monitoring para verificar gargalos de recursos. Se as especificações padrão forem insuficientes, escale para cima prontamente.
Clique em Buy and Start e conclua o pagamento conforme solicitado.
Na página Paid, clique em Console.
Em Clusters of Community-compatible Edition, visualize o status do cluster de destino na coluna Status.
Nota
- Após alterar a Storage Capacity, a alteração entra em vigor imediatamente e o status do cluster permanece como Running.
- Após alterar a Specification e as ZooKeeper Specifications, aguarde cerca de 10 a 15 minutos. A operação de escala para cima ou para baixo é bem-sucedida quando o status do cluster muda de Changing Specification para Running.

Scale out e scale in

Importante

Para obter informações sobre os impactos do dimensionamento horizontal, consulte Visão geral do dimensionamento vertical e horizontal e Observações de uso.

Etapa 1: Registrar e remover tabelas Kafka/RabbitMQ

O recurso de dimensionamento no console não migra diretamente tabelas das engines Kafka e RabbitMQ. Antes de dimensionar o cluster, registre as instruções DDL dessas tabelas e remova-as do cluster para evitar interferências na tarefa de dimensionamento.

Faça login no cluster e execute a seguinte instrução para consultar todas as tabelas das engines Kafka e RabbitMQ e suas dependências downstream.

/*
create_table_query: The table definition statement.
dependencies_database: The database that depends on the table.
dependencies_table: The name of the table that depends on the table.
You can use dependencies_database and dependencies_table to identify materialized views that depend on Kafka/RabbitMQ tables.
*/
SELECT * FROM system.tables WHERE engine IN ('RabbitMQ', 'Kafka');

Visualize a definição da visualização materializada para verificar se a tabela de destino é implícita.

/*
View the materialized view definition.
If the target table of the materialized view is an implicit table, pay special attention to the following:
When you delete the materialized view, the implicit table is also deleted, resulting in data loss.
Example: If the TO clause is not specified in CREATE MATERIALIZED VIEW [db.]table_name [TO[db.]name],
the system automatically creates an implicit table in the format '.inner_id.<TABLE_UUID>' or '.inner.<TABLE>'.
*/
SELECT * FROM system.tables WHERE database='<DATABASE>' AND name = '<MATERIALIZED_VIEW_NAME>';

Se uma visualização materializada foi criada sem cláusula TO, o sistema gera automaticamente uma tabela de destino implícita com o prefixo .inner ou .inner_id. Essas tabelas implícitas são migradas para os novos nós durante o dimensionamento. Contudo, devido aos mecanismos internos de nomenclatura, recriar diretamente a visualização materializada original pode causar conflitos de nomes. Portanto, renomeie primeiro as tabelas de destino implícitas para nomes de tabelas regulares.
```
-- Rename the implicit target table to a regular table name (execute on all nodes).
RENAME TABLE <database>.`.inner_id.<uuid>` TO <database>.<new_target_table_name> ON CLUSTER default;
```
Remova as visualizações materializadas e as tabelas das engines Kafka/RabbitMQ.

Importante
Remova as visualizações materializadas que referenciam as tabelas Kafka/RabbitMQ antes de remover as próprias tabelas dessas engines. Caso contrário, a operação de dimensionamento falhará.
```
-- Remove the materialized views first.
DROP TABLE <database>.<materialized_view_name> ON CLUSTER default;

-- Then, remove the Kafka/RabbitMQ engine tables.
DROP TABLE <database>.<kafka_or_rabbitmq_table_name> ON CLUSTER default;
```

Importante

Certifique-se de salvar todas as instruções DDL registradas. Será necessário recriar essas tabelas no cluster dimensionado posteriormente. Se você executou uma operação RENAME, use a cláusula TO para apontar para a tabela de destino renomeada ao recriar a visualização materializada. Para mais informações, consulte CREATE MATERIALIZED VIEW.

Se o cluster não contiver tabelas das engines Kafka/RabbitMQ, pule as Etapas 1, 4, 5 e 6 e comece pela Etapa 2.

Etapa 2: Fazer backup dos dados de tabelas não-MergeTree

Faça login no cluster e execute a seguinte instrução para identificar as tabelas não-MergeTree que requerem migração de dados.

SELECT
    `database` AS database_name,
    `name` AS table_name,
    `engine`
FROM `system`.`tables`
WHERE (`engine` NOT LIKE '%MergeTree%') AND (`engine` != 'Distributed') AND (`engine` != 'MaterializedView') AND (`engine` NOT IN ('Kafka', 'RabbitMQ')) AND (`database` NOT IN ('system', 'INFORMATION_SCHEMA', 'information_schema')) AND (`database` NOT IN (
    SELECT `name`
    FROM `system`.`databases`
    WHERE `engine` IN ('MySQL', 'MaterializedMySQL', 'MaterializeMySQL', 'Lazy', 'PostgreSQL', 'MaterializedPostgreSQL', 'SQLite')
))

Faça o backup dos dados.

Faça backup dos dados de negócios nas tabelas não-MergeTree. Para mais informações, consulte Fazer backup de dados no OSS.

Etapa 3: Dimensionar no console

Faça login no console do Alibaba Cloud ClickHouse. No canto superior esquerdo da página, selecione a região onde o cluster está localizado.
Na página Clusters, clique em Clusters of Community-compatible Edition.
Na coluna Actions do cluster de destino, clique em Change Configurations.
Na caixa de diálogo Change Configurations, selecione Scale Out ou Scale In e clique em OK.
Na janela de verificação de scale-out ou scale-in, visualize o status da verificação.

Nota
Ao entrar na janela de verificação para Scale Out, a opção Migration Expansion vem selecionada por padrão. Para selecionar Simple Expansion, clique em Previous nesta página. Na caixa de diálogo Scale-out, selecione Simple Expansion e clique em Next para ir à página Change Specification.

Se o cluster contiver tabelas das engines Kafka/RabbitMQ, execute a Etapa 4 para recriá-las no cluster quando a tarefa de dimensionamento entrar no estágio de Data Migration (após a conclusão da migração do esquema da tabela). Isso permite que os dados incrementais voltem a fluir e sejam sincronizados com os novos nós.

Antes do início da janela de suspensão de gravação configurada, execute a Etapa 5 para remover as tabelas das engines Kafka/RabbitMQ e suas visualizações materializadas downstream do cluster. Isso evita que acúmulos de mensagens durante a janela de suspensão causem inconsistências de dados.
- Se a verificação for bem-sucedida, clique em Next.
- Se a verificação falhar, corrija o problema conforme indicado na página e clique em Retry Detection. Após o sucesso da verificação, clique em Next.
  Motivos comuns para falha na verificação de scale-out incluem:
  Tabela distribuída única ausente: uma tabela local não possui tabela distribuída correspondente. Crie uma.
  
  Tabela distribuída correspondente não é única: uma tabela local possui mais de uma tabela distribuída. Remova as extras e mantenha apenas uma.
  
  Tabelas das engines Kafka/RabbitMQ não suportadas: o cluster contém tabelas das engines Kafka ou RabbitMQ. Remova-as.
  
  Tabelas MergeTree não replicadas em instância de múltiplas réplicas: dados inconsistentes entre réplicas causam erros de migração durante o dimensionamento.
  
  Colunas inconsistentes entre tabela distribuída e local: torne as colunas consistentes. Caso contrário, ocorrerão erros de migração de dados durante o dimensionamento.
  
  Tabela ausente em alguns nós: crie tabelas com o mesmo nome em diferentes shards. Para a tabela interna de uma visualização materializada, recomendamos renomeá-la e recriar a visualização materializada apontando para a tabela interna renomeada. Para mais informações, consulte A tabela interna de uma visualização materializada é inconsistente entre shards.
Na página Change Specification ou Scale Down, configure o número de Server Nodes e a janela de suspensão de gravação.SYNC: 同步中文变更 - 补充停写窗口定义说明和判断逻辑
Nota
A janela de suspensão de gravação é um período configurado pelo cliente durante o qual o kernel tem permissão para interromper gravações. A lógica interna de migração decide suspender as gravações da seguinte forma: se a hora atual estiver dentro da janela de suspensão e os dados restantes puderem ser migrados em até 10 minutos, o sistema entra automaticamente no estado de suspensão. Durante esse período, o backend continua migrando dados até que tudo esteja sincronizado. Após a conclusão da migração, o sistema sai automaticamente do estado de suspensão.

A migração de dados ocorre durante o dimensionamento do cluster. Para garantir uma migração bem-sucedida, a janela de suspensão de gravação deve atender aos seguintes requisitos:
- Recomendamos definir a janela de suspensão de gravação com pelo menos 30 minutos.
- O dimensionamento deve ser concluído dentro de 5 dias após a criação da alteração de configuração. Portanto, a hora final da janela de suspensão de gravação para o cluster de origem não deve ultrapassar a data atual + 5 dias.
- Para minimizar o impacto nos negócios, recomendamos definir a janela de suspensão de gravação em horários fora de pico.
Clique em Buy and Start e conclua o pagamento conforme solicitado.
Na página Purchase successful, clique em Console.
Em Clusters of Community-compatible Edition, visualize o status do cluster de destino na coluna Status.

Nota

O dimensionamento horizontal deve levar 30 minutos ou mais. A duração depende do volume de dados. O status do cluster no console mostra o status real de execução da tarefa.

Etapa 4: Recriar tabelas Kafka/RabbitMQ

Quando a tarefa de dimensionamento entrar no estágio de Data Migration (após a conclusão da migração do esquema da tabela), use as instruções DDL salvas para recriar as tabelas das engines Kafka/RabbitMQ e suas visualizações materializadas downstream. Após a recriação, os dados incrementais voltam a fluir e são sincronizados automaticamente com os novos nós do cluster.

Importante

Se você executou uma operação RENAME em tabelas de destino implícitas na Etapa 1, use a cláusula TO para apontar para a tabela de destino renomeada ao recriar a visualização materializada. Para mais informações sobre a cláusula TO, consulte CREATE MATERIALIZED VIEW.

-- Re-create Kafka/RabbitMQ engine tables.
CREATE TABLE <database>.<kafka_or_rabbitmq_table_name> (...)
ENGINE = Kafka/RabbitMQ
SETTINGS ...;

-- Re-create the materialized view (use the TO clause to point to the renamed target table).
CREATE MATERIALIZED VIEW <database>.<materialized_view_name> TO <database>.<new_target_table_name>
AS SELECT ... FROM <database>.<kafka_or_rabbitmq_table_name>;

Etapa 5: Remover tabelas Kafka/RabbitMQ antes da suspensão de gravação

Antes do início da janela de suspensão de gravação configurada, remova as tabelas das engines Kafka/RabbitMQ e suas visualizações materializadas downstream para interromper as gravações de dados incrementais e garantir a consistência final da sincronização de dados.

-- Remove materialized views first.
DROP TABLE <database>.<materialized_view_name> ON CLUSTER default;

-- Then, remove Kafka/RabbitMQ engine tables.
DROP TABLE <database>.<kafka_or_rabbitmq_table_name> ON CLUSTER default;

Etapa 6: Recriar tabelas Kafka/RabbitMQ após o dimensionamento

Após a conclusão da tarefa de dimensionamento, use as instruções DDL salvas para recriar as tabelas das engines Kafka/RabbitMQ e suas visualizações materializadas downstream no cluster dimensionado, restaurando o pipeline de consumo de dados incrementais.

Importante

-- Re-create Kafka/RabbitMQ engine tables.
CREATE TABLE <database>.<kafka_or_rabbitmq_table_name> (...)
ENGINE = Kafka/RabbitMQ
SETTINGS ...;

-- Re-create the materialized view (use the TO clause to point to the renamed target table).
CREATE MATERIALIZED VIEW <database>.<materialized_view_name> TO <database>.<new_target_table_name>
AS SELECT ... FROM <database>.<kafka_or_rabbitmq_table_name>;

Etapa 7: Migrar dados de tabelas não-MergeTree

Faça login no cluster e use o OSS para migrar os dados dos quais você fez backup na Etapa 2. Para mais informações, consulte Importar dados do OSS.