Comencemos con un poco de historia. En nuestra empresa, un proyecto está en mantenimiento, que hasta hace poco estaba en la etapa de prueba / desarrollo. En ese momento, utilizaba ClickHouse con 3 fragmentos, 2 réplicas cada uno. Teniendo en cuenta que la infraestructura de este proyecto era de prueba y no requería ninguna autorización adicional (ClickHouse estaba en un segmento cerrado), nadie hizo esta pregunta.
Con el tiempo, el proyecto creció, ClickHouse se convirtió en una base de producción y migramos los datos de la infraestructura anterior a la nueva con 1 fragmento, 3 réplicas en 3 servidores diferentes (ClickHouse se encuentra en Kubernetes basado en StatefulSets) y, por supuesto, con autorización.
Esto es lo que sucedió después.
Casi inmediatamente después de comenzar el proyecto en producción, descubrimos que en el DataDir ClickHouse de la base de datos del usuario, en tablas no fragmentarias (en nuestro caso, las que se encuentran localmente en cada nodo, sin el postfix fragmentado, del tipo Distribuido), había una gran cantidad de no perdido bin-logs. La fecha de los registros precedió a la fecha de instalación en la autorización de ClickHouse.
La siguiente es la salida de la consola para una de las réplicas de ClickHouse de la tabla tabla_1 de la base de datos de prueba:
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
Es decir los datos en sí se colocaron en la tabla Distribuida local de una réplica específica, pero por una razón desconocida en ese momento, no se movió a una tabla con un código postal fragmentado (como ReplicatedMergeTree), al que se puede acceder desde todas las réplicas del clúster accediendo a través de una tabla local (sin código postal) fragmentado).
Como resultó después del análisis, los datos que se registraron en la base de datos ClickHouse en la infraestructura anterior, es decir antes de habilitar la autorización, ya no podían distribuirse entre réplicas en la nueva infraestructura, porque En los nuevos servidores ClickHouse, la autorización ya se ha habilitado.
Por qué Cuando los datos se escriben en ClickHouse sin autorización, se genera un enlace del siguiente formulario en el directorio de datos de clickHouse en los directorios de la base de datos correspondiente y la tabla (el enlace se genera en función de una solicitud realizada a la base de datos):
test_usr@clickhouse%2D0%2Eclickhouse%2Eclickhouse%2Dprod%2Esvc%2Ecluster%2Elocal\:9000
Miremos con más detalle. El usuario prueba_usr accede al enlace anterior, pero no se especifica la contraseña para la autorización. Y lo que sucede, si antes de habilitar la autorización en la base de datos, se registraba una gran cantidad de datos en ClickHouse, que formaba registros de bin, y ClickHouse en los servidores antiguos no tenía tiempo de perderlos, luego, después de habilitar la autorización en los nuevos servidores ClickHouse y migrar los viejos no perdidos bin-logs a nuevos servidores, estos bin-logs ya no se pueden reproducir, porque el enlace ya se ha generado sin autorización para el usuario test_usr.
Todos los nuevos datos entrantes en ClickHouse también generarán bin-logs en los directorios y tablas de bases de datos correspondientes, que luego se reproducirán, pero con un enlace diferente, donde se indica la autorización (ya que la aplicación ya está accediendo a ClickHouse en la nueva infraestructura se realiza con la contraseña para el usuario test_usr, de lo contrario la solicitud simplemente no llegará a la base de datos):
test_usr:password@clickhouse%2D0%2Eclickhouse%2Eclickhouse%2Dprod%2Esvc%2Ecluster%2Elocal\:9000
Porque los datos se escriben en la base de datos de forma asincrónica, es decir, primero se colocan en una réplica local de ClickHouse a la que se accedió, y solo luego se envían a otras réplicas del clúster.
En consecuencia, los datos antiguos que se registraron en una de las réplicas locales de ClickHouse, pero no se distribuyeron entre el resto de las réplicas del clúster (dado que el enlace generado no contenía la contraseña para el usuario, pero ya estaba configurado), ni siquiera se podía acceder a ellos. para leer en la réplica en la que se ubicaron directamente los bin-logs no aplicados.
¿Cómo resolvimos el problema y no perdimos datos no asignados?
Todo resultó ser bastante simple. Es suficiente realizar las siguientes manipulaciones con datos no asignados en la base de datos:
- Los enlaces generados para cada una de las tablas de la base de datos del problema deben ser renombrados (renombrados) a la forma requerida:
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 las réplicas de ClickHouse, que inicia el proceso de reproducción de registros de bin y su colocación en nuestras tablas fragmentadas (ReplicatedMergeTree).
PD : Recomiendo a todos que verifiquen el funcionamiento de sus servidores ClickHouse para ver los problemas descritos. Si se encuentran, entonces esta nota lo ayudará a ahorrar tiempo buscando una solución y será más cuidadoso al configurar / cambiar una contraseña en ClickHouse en el futuro.
Lea también otros artículos en nuestro blog: