Vamos começar com um pouco de fundo. Em nossa empresa, um projeto está em manutenção, que até recentemente estava em fase de teste / desenvolvimento. Naquela época, ele usava o ClickHouse com 3 shards, 2 réplicas cada. Considerando que a infraestrutura deste projeto foi testada e não exigiu nenhuma autorização adicional (o ClickHouse estava em um segmento fechado), ninguém fez essa pergunta.
Com o tempo, o projeto cresceu, o ClickHouse se tornou uma base de produção e migramos os dados da infraestrutura antiga para a nova com 1 shard, 3 réplicas em 3 servidores diferentes (o ClickHouse é hospedado no Kubernetes com base no StatefulSets) e, é claro, com autorização.
Aqui está o que aconteceu a seguir.
Quase imediatamente após o início do projeto em produção, descobrimos que no datadir ClickHouse do banco de dados do usuário, em tabelas não shard (no nosso caso, localizadas localmente em cada nó, sem o postfix sharded, do tipo Distributed), houve um grande número de perdas bin-logs. A data dos logs precedeu a data da instalação na autorização do ClickHouse.
A seguir, é apresentada a saída do console para uma das réplicas ClickHouse da tabela table_1 do banco de dados de teste:
ls -l /var/lib/clickhouse/data/test/table_1/test_usr@clickhouse%2D0%2Eclickhouse%2Eclickhouse%2Dprod%2Esvc%2Ecluster%2Elocal\:9000 | tail -n 10 -rw-r----- 1 clickhouse clickhouse 1472 Jul 8 08:26 9983.bin -rw-r----- 1 clickhouse clickhouse 1453 Jul 8 08:26 9985.bin -rw-r----- 1 clickhouse clickhouse 1383 Jul 8 08:26 9987.bin -rw-r----- 1 clickhouse clickhouse 1461 Jul 8 08:27 9989.bin -rw-r----- 1 clickhouse clickhouse 1458 Jul 8 08:28 9991.bin -rw-r----- 1 clickhouse clickhouse 1468 Jul 8 08:29 9993.bin -rw-r----- 1 clickhouse clickhouse 1413 Jul 8 08:29 9995.bin -rw-r----- 1 clickhouse clickhouse 1509 Jul 8 08:32 9997.bin -rw-r----- 1 clickhouse clickhouse 1504 Jul 8 08:32 9999.bin drwxr-x--- 2 clickhouse clickhouse 4096 Sep 16 12:59 tmp
I.e. os dados em si foram colocados na tabela local Distributed de uma réplica específica, mas por um motivo desconhecido naquele momento, não foram movidos para uma tabela com o postfix fragmentado (como ReplicatedMergeTree), acessível a partir de todas as réplicas de cluster, acessando-o através da tabela local (sem o postfix sharded).
Como ocorreu após a análise, os dados que foram registrados no banco de dados ClickHouse na infraestrutura antiga, ou seja, antes de habilitar a autorização, eles não podiam mais ser distribuídos entre réplicas na nova infraestrutura, porque Nos novos servidores ClickHouse, a autorização já foi ativada.
Por que sim? Quando os dados são gravados no ClickHouse sem autorização, um link do seguinte formulário é gerado no diretório de dados clickHouse nos diretórios correspondentes do banco de dados e na tabela (o link é gerado com base em uma solicitação feita ao banco de dados):
test_usr@clickhouse%2D0%2Eclickhouse%2Eclickhouse%2Dprod%2Esvc%2Ecluster%2Elocal\:9000
Vamos dar uma olhada em mais detalhes. O link acima é acessado pelo usuário test_usr, mas a senha para autorização não está especificada. E o que acontece, se antes de habilitar a autorização no banco de dados, uma quantidade muito grande de dados foi registrada no ClickHouse, que formava logs de lixeira, e o ClickHouse nos servidores antigos não tinha tempo para perdê-los, depois de habilitar a autorização em novos servidores ClickHouse e migrar os antigos não perdidos bin-logs para novos servidores, esses bin-logs não podem mais ser reproduzidos, porque o link já foi gerado sem autorização para o usuário test_usr.
Todos os novos dados recebidos no ClickHouse também geram logs de binários nos diretórios e tabelas correspondentes do banco de dados, que serão reproduzidos, mas com um link diferente, onde a autorização é indicada (porque o aplicativo já está acessando o ClickHouse na nova infraestrutura é feita com a senha do usuário test_usr, caso contrário, a solicitação simplesmente não chegará ao banco de dados):
test_usr:password@clickhouse%2D0%2Eclickhouse%2Eclickhouse%2Dprod%2Esvc%2Ecluster%2Elocal\:9000
Porque os dados são gravados no banco de dados de forma assíncrona, ou seja, eles são colocados primeiro em uma réplica ClickHouse local que foi acessada e somente depois são enviados para outras réplicas do cluster.
Conseqüentemente, os dados antigos que foram registrados em uma das réplicas locais da ClickHouse, mas não foram distribuídos pelo restante das réplicas de cluster (como o link gerado não continha a senha do usuário, mas já estava definida), eles não podiam ser acessados para ler a réplica na qual os logs de caixa não aplicados foram localizados diretamente.
Como resolvemos o problema e não perdemos dados não alocados?
Tudo acabou sendo bastante simples. É o suficiente para executar as seguintes manipulações com dados não alocados no banco de dados:
- Os links gerados para cada uma das tabelas do banco de dados do problema devem ser renomeados (renomeados) para o formulário necessário:
mv /var/lib/clickhouse/data/test/table_1/test_usr@clickhouse%2D0%2Eclickhouse%2Eclickhouse%2Dprod%2Esvc%2Ecluster%2Elocal\:9000 /var/lib/clickhouse/data/test/table_1/test_usr:password@clickhouse%2D0%2Eclickhouse%2Eclickhouse%2Dprod%2Esvc%2Ecluster%2Elocal\:9000
- Reinicie as réplicas do ClickHouse, que inicia o processo de reproduzir logs de lixeira e colocá-los em nossas tabelas fragmentadas (ReplicatedMergeTree).
PS : Recomendo a todos que verifiquem a operação de seus servidores ClickHouse quanto aos problemas descritos. Se for encontrado, esta nota ajudará você a economizar tempo na busca de uma solução e a ter mais cuidado ao definir / alterar uma senha no ClickHouse no futuro.
Leia também outros artigos em nosso blog: