ClickHouseCluster, cómo escalar de forma segura el quórum de un KeeperCluster y qué condiciones observar mientras una operación de escalado está en curso.
Un
ClickHouseCluster siempre necesita un Keeper, al que se hace referencia mediante el campo obligatorio spec.keeperClusterRef; el operador coordina el clúster a través de él independientemente de su tamaño. Para ejecutar más de una réplica por segmento, los datos también deben residir en tablas ReplicatedMergeTree, ya que la replicación es lo que permite que una segunda réplica pueda servir las mismas filas.Escalado de réplicas
spec.replicas establece el número de réplicas en cada segmento. Cada réplica se ejecuta en su propio StatefulSet llamado <cluster>-clickhouse-<shard>-<replica>, por lo que un clúster con shards: 2 y replicas: 3 ejecuta seis StatefulSets.
Aumente o reduzca la cantidad directamente:
Escalado de segmentos
spec.shards establece el número de segmentos. Cada segmento nuevo añade un conjunto completo de StatefulSets por réplica, y el operador crea un PodDisruptionBudget por segmento para que una interrupción en un segmento no se contabilice para otro.
Distributed o un esquema de enrutamiento explícito decide en qué segmento acaba una fila, por lo que agregar un segmento proporciona un destino para las nuevas escrituras sin afectar a las filas ya almacenadas en los segmentos existentes.
Sincronización automática del esquema
spec.settings.enableDatabaseSync es true (valor predeterminado), el operador mantiene el esquema sincronizado a medida que cambia la topología:
- Al ampliar la escala — una vez que al menos dos réplicas están listas, el operador replica las definiciones de las bases de datos en las réplicas recién creadas, de modo que una réplica nueva se una con las mismas bases de datos
Replicatedy de integración que el resto del clúster. - Al reducir la escala — antes de que desaparezca una réplica, el operador elimina el registro de esa réplica de cada base de datos
ReplicatedconSYSTEM DROP DATABASE REPLICA, para que el clúster reducido no espere a una réplica de base de datosReplicatedque ya no existe.
Replicated y los motores de base de datos de integración. No mueve datos de tablas: los datos a nivel de fila residen en tablas ReplicatedMergeTree y se replican mediante Keeper de forma independiente de esta sincronización del esquema. Con una sola réplica lista, no hay nada que replicar, por lo que el operador omite este paso y registra que no tiene ningún destino.
Establece enableDatabaseSync: false para desactivar este comportamiento, por ejemplo, cuando una herramienta externa se encarga de la propagación del esquema. En ese caso, el operador informa del motivo SchemaSyncDisabled en la condición SchemaInSync.
Condiciones que debe vigilar
Una operación de escalado se completa cuando
ClusterSizeAligned informa UpToDate, SchemaInSync informa ReplicasInSync y Ready informa AllShardsReady.
Escalado de Keeper
KeeperCluster ejecuta un quorum de RAFT, por lo que el operador modifica sus miembros una réplica cada vez y solo cuando el clúster se encuentra en un estado estable. Esto protege el quorum: un clúster 2F+1 tolera la caída de F miembros, de modo que un clúster de 3 nodos sigue funcionando si falta un miembro y uno de 5 nodos, si faltan dos.
maxUnavailable: replicas/2 para preservar el quórum durante interrupciones voluntarias.
La condición ScaleAllowed indica si el quórum puede cambiar de miembros en este momento:
Escala Keeper de uno en uno y deja que
ScaleAllowed vuelva a ReadyToScale entre cambios. Saltar varios miembros a la vez no evita la reconciliación paso a paso: el operador sigue recorriendo el quórum, un miembro por paso.