Crear una base de datos
zoo_path— Ruta de ZooKeeper. La misma ruta de ZooKeeper corresponde a la misma base de datos.shard_name— Nombre del segmento. Las réplicas de la base de datos se agrupan en segmentos segúnshard_name.replica_name— Nombre de la réplica. Los nombres de las réplicas deben ser distintos para todas las réplicas del mismo segmento.
zoo_path contiene la macro {uuid}, es obligatorio especificar un UUID explícito o añadir ON CLUSTER a la sentencia CREATE para garantizar que todas las réplicas usen el mismo UUID para esta base de datos.
En las tablas ReplicatedMergeTree, si no se proporcionan argumentos, se usan los argumentos predeterminados: /clickhouse/tables/{uuid}/{shard} y {replica}. Estos se pueden cambiar en la configuración del servidor default_replica_path y default_replica_name. La macro {uuid} se expande al UUID de la tabla; {shard} y {replica} se expanden a los valores de la configuración del servidor, no a los argumentos del motor de base de datos. Sin embargo, en el futuro será posible usar shard_name y replica_name de la base de datos Replicated.
También se admite un clúster auxiliar de ZooKeeper para almacenar los metadatos de una base de datos replicada en lugar de usar el clúster de ZooKeeper predeterminado. Podemos usar SQL para crear la base de datos replicada con un clúster auxiliar de ZooKeeper de la siguiente manera:
Particularidades y recomendaciones
Replicated funcionan de forma similar a las consultas ON CLUSTER, aunque con pequeñas diferencias.
En primer lugar, la solicitud DDL intenta ejecutarse en el iniciador (el host que recibió originalmente la solicitud del usuario). Si la solicitud no se completa, el usuario recibe inmediatamente un error y los demás hosts no intentan completarla. Si la solicitud se completa correctamente en el iniciador, todos los demás hosts la reintentarán automáticamente hasta completarla. El iniciador intentará esperar a que la consulta se complete en los demás hosts (durante no más de distributed_ddl_task_timeout) y devolverá una tabla con los estados de ejecución de la consulta en cada host.
El comportamiento en caso de errores está regulado por la configuración distributed_ddl_output_mode; para una base de datos Replicated es mejor establecerla en null_status_on_timeout, es decir, si algunos hosts no tienen tiempo de ejecutar la solicitud dentro de distributed_ddl_task_timeout, no se debe lanzar una excepción, sino mostrar el estado NULL para ellos en la tabla.
La tabla del sistema system.clusters contiene un clúster con el mismo nombre que la base de datos replicada, compuesto por todas las réplicas de la base de datos. Este clúster se actualiza automáticamente al crear o eliminar réplicas, y puede usarse para tablas Distributed.
Al crear una nueva réplica de la base de datos, esta réplica crea las tablas por sí sola. Si la réplica ha estado no disponible durante mucho tiempo y se ha quedado rezagada con respecto al log de replicación, comprueba sus metadatos locales con los metadatos actuales en ZooKeeper, mueve las tablas adicionales con datos a una base de datos no replicada independiente (para no eliminar accidentalmente nada de más), crea las tablas que faltan y actualiza los nombres de las tablas si se han renombrado. Los datos se replican a nivel de ReplicatedMergeTree, es decir, si la tabla no está replicada, los datos no se replicarán (la base de datos solo es responsable de los metadatos).
Las consultas ALTER TABLE FREEZE|ATTACH|FETCH|DROP|DROP DETACHED|DETACH PARTITION|PART están permitidas, pero no se replican. El motor de base de datos solo añadirá/recuperará/eliminará la partición/parte en la réplica actual. Sin embargo, si la propia tabla usa un motor de tabla Replicated, los datos se replicarán después de usar ATTACH.
Si solo necesita configurar un clúster sin mantener la replicación de tablas, consulte la funcionalidad Cluster Discovery.
Ejemplo de uso
{uuid} en zoo_path:
Ajustes
Los valores predeterminados pueden sobrescribirse en el archivo de configuración