> ## Documentation Index > Fetch the complete documentation index at: https://private-7c7dfe99-postgresql-tls-support.mintlify.site/llms.txt > Use this file to discover all available pages before exploring further. > Descripción general de la replicación de datos con la familia Replicated* de motores de tabla en ClickHouse # Motores de tabla Replicated* En ClickHouse Cloud, la replicación se gestiona automáticamente. Cree sus tablas sin añadir argumentos. Por ejemplo, en el texto siguiente sustituiría: ```sql theme={null} ENGINE = ReplicatedMergeTree( '/clickhouse/tables/{shard}/table_name', '{replica}' ) ``` por: ```sql theme={null} ENGINE = ReplicatedMergeTree ``` La replicación solo es compatible con las tablas de la familia MergeTree * ReplicatedSummingMergeTree * ReplicatedCoalescingMergeTree * ReplicatedVersionedCollapsingMergeTree * ReplicatedCollapsingMergeTree * ReplicatedGraphiteMergeTree * ReplicatedMergeTree * ReplicatedReplacingMergeTree * ReplicatedAggregatingMergeTree La replicación funciona a nivel de cada tabla, no de todo el servidor. Un servidor puede almacenar tablas replicadas y tablas no replicadas al mismo tiempo. La replicación no depende de la fragmentación (sharding). Cada segmento tiene su propia replicación independiente. Los datos comprimidos de las consultas `INSERT` y `ALTER` se replican (para más información, consulte la documentación de [ALTER](/es/reference/statements/alter/index). Las consultas `CREATE`, `DROP`, `ATTACH`, `DETACH` y `RENAME` se ejecutan en un solo servidor y no se replican: * La consulta `CREATE TABLE` crea una nueva tabla replicable en el servidor donde se ejecuta. Si esta tabla ya existe en otros servidores, añade una nueva réplica. * La consulta `DROP TABLE` elimina la réplica ubicada en el servidor donde se ejecuta la consulta. * La consulta `RENAME` cambia el nombre de la tabla en una de las réplicas. En otras palabras, las tablas replicadas pueden tener nombres distintos en diferentes réplicas. ClickHouse usa [ClickHouse Keeper](/es/guides/oss/deployment-and-scaling/keeper/index) para almacenar los metadatos de las réplicas. Es posible usar ZooKeeper versión 3.4.5 o posterior, pero se recomienda ClickHouse Keeper. Para usar la replicación, configure los parámetros en la sección [zookeeper](/es/reference/settings/server-settings/settings#zookeeper) de la configuración del servidor. No pase por alto la configuración de seguridad. ClickHouse admite el esquema [ACL](https://zookeeper.apache.org/doc/current/zookeeperProgrammers.html#sc_ZooKeeperAccessControl) `digest` del subsistema de seguridad de ZooKeeper. Ejemplo de configuración de las direcciones del clúster de ClickHouse Keeper: ```xml theme={null} example1 2181 example2 2181 example3 2181 ``` ClickHouse también admite almacenar los metadatos de las réplicas en un clúster auxiliar de ZooKeeper. Para ello, proporcione el nombre y la ruta del clúster de ZooKeeper como argumentos del motor. En otras palabras, permite almacenar los metadatos de distintas tablas en diferentes clústeres de ZooKeeper. Ejemplo de configuración de las direcciones del clúster auxiliar de ZooKeeper: ```xml theme={null} example_2_1 2181 example_2_2 2181 example_2_3 2181 example_3_1 2181 ``` Para almacenar los metadatos de la tabla en un clúster de ZooKeeper auxiliar en lugar del clúster de ZooKeeper predeterminado, podemos usar SQL para crear la tabla con el motor ReplicatedMergeTree de la siguiente manera: ```sql theme={null} CREATE TABLE table_name ( ... ) ENGINE = ReplicatedMergeTree('zookeeper_name_configured_in_auxiliary_zookeepers:path', 'replica_name') ... ``` Puede especificar cualquier clúster de ZooKeeper existente y el sistema usará un directorio en él para almacenar sus propios datos (el directorio se especifica al crear una tabla replicable). Si ZooKeeper no está definido en el archivo de configuración, no se pueden crear tablas replicadas y cualquier tabla replicada existente será de solo lectura. ZooKeeper no se utiliza en las consultas `SELECT` porque la replicación no afecta al rendimiento de `SELECT`, y las consultas se ejecutan igual de rápido que en las tablas no replicadas. Al consultar tablas replicadas distribuidas, el comportamiento de ClickHouse está controlado por la configuración [max\_replica\_delay\_for\_distributed\_queries](/es/reference/settings/session-settings#max_replica_delay_for_distributed_queries) y [fallback\_to\_stale\_replicas\_for\_distributed\_queries](/es/reference/settings/session-settings#fallback_to_stale_replicas_for_distributed_queries). Para cada consulta `INSERT`, se añaden aproximadamente diez entradas a ZooKeeper mediante varias transacciones. (Más exactamente, esto ocurre por cada bloque de datos insertado; una consulta `INSERT` contiene un bloque, o un bloque por cada `max_insert_block_size = 1048576` filas). Esto provoca latencias ligeramente mayores para `INSERT` en comparación con las tablas no replicadas. Pero si se siguen las recomendaciones de insertar datos en lotes de no más de un `INSERT` por segundo, esto no genera ningún problema. Todo el clúster de ClickHouse que utiliza un clúster de ZooKeeper para la coordinación admite en total varios cientos de `INSERTs` por segundo. El rendimiento de las inserciones de datos (el número de filas por segundo) es igual de alto que en los datos no replicados. Para clústeres muy grandes, puede usar distintos clústeres de ZooKeeper para diferentes segmentos. Sin embargo, según nuestra experiencia, esto no ha resultado necesario en clústeres de producción con aproximadamente 300 servidores. La replicación es asíncrona y multimáster. Las consultas `INSERT` (así como `ALTER`) pueden enviarse a cualquier servidor disponible. Los datos se insertan en el servidor donde se ejecuta la consulta y luego se copian a los demás servidores. Al ser asíncrona, los datos insertados recientemente aparecen en las demás réplicas con cierta latencia. Si parte de las réplicas no está disponible, los datos se escriben cuando vuelven a estarlo. Si una réplica está disponible, la latencia es el tiempo necesario para transferir el bloque de datos comprimidos por la red. El número de hilos que realizan tareas en segundo plano para las tablas replicadas puede configurarse mediante la opción [background\_schedule\_pool\_size](/es/reference/settings/server-settings/settings#background_schedule_pool_size). El motor `ReplicatedMergeTree` usa un grupo de hilos independiente para los fetches replicados. El tamaño del grupo está limitado por la configuración [background\_fetches\_pool\_size](/es/reference/settings/server-settings/settings#background_fetches_pool_size), que puede ajustarse reiniciando el servidor. De forma predeterminada, una consulta `INSERT` espera la confirmación de escritura de los datos de una sola réplica. Si los datos se escribieron correctamente solo en una réplica y el servidor con esa réplica deja de existir, los datos almacenados se perderán. Para habilitar la confirmación de escritura de datos desde varias réplicas, use la opción `insert_quorum`. Cada bloque de datos se escribe de forma atómica. La consulta `INSERT` se divide en bloques de hasta `max_insert_block_size = 1048576` filas. En otras palabras, si la consulta `INSERT` tiene menos de 1048576 filas, se realiza de forma atómica. Los bloques de datos se deduplican. Si se escribe varias veces el mismo bloque de datos (bloques de datos del mismo tamaño que contienen las mismas filas en el mismo orden), el bloque solo se escribe una vez. Esto es útil en caso de fallos de red, cuando la aplicación cliente no sabe si los datos se escribieron en la DB, por lo que la consulta `INSERT` puede repetirse sin más. No importa a qué réplica se enviaron los `INSERTs` con datos idénticos. Los `INSERTs` son idempotentes. Los parámetros de deduplicación se controlan mediante la configuración del servidor [merge\_tree](/es/reference/settings/server-settings/settings#merge_tree). Durante la replicación, solo se transfieren por la red los datos de origen que se van a insertar. La transformación posterior de los datos (merging) se coordina y se realiza en todas las réplicas de la misma manera. Esto minimiza el uso de la red, lo que significa que la replicación funciona bien cuando las réplicas residen en distintos datacenters. (Tenga en cuenta que duplicar datos en distintos datacenters es el objetivo principal de la replicación). Puede tener cualquier número de réplicas de los mismos datos. Según nuestra experiencia, una solución relativamente fiable y práctica podría usar replicación doble en producción, con cada servidor usando RAID-5 o RAID-6 (y RAID-10 en algunos casos). El sistema supervisa la sincronización de los datos entre las réplicas y puede recuperarse después de un fallo. La conmutación por error es automática (cuando las diferencias de datos son pequeñas) o semiautomática (cuando los datos difieren demasiado, lo que puede indicar un error de configuración).
## Creación de tablas replicadas
En ClickHouse Cloud, la replicación se gestiona automáticamente. Cree tablas con [`MergeTree`](/es/reference/engines/table-engines/mergetree-family/mergetree) sin argumentos de replicación. El sistema convierte internamente [`MergeTree`](/es/reference/engines/table-engines/mergetree-family/mergetree) en [`SharedMergeTree`](/es/products/cloud/features/infrastructure/shared-merge-tree) para la replicación y la distribución de datos. Evite usar `ReplicatedMergeTree` o especificar parámetros de replicación, ya que la plataforma se encarga de la replicación.
### Parámetros de Replicated\*MergeTree
| Parámetro | Descripción | | ------------------ | ---------------------------------------------------------------------------------------------------------------- | | `zoo_path` | La ruta de la tabla en ClickHouse Keeper. | | `replica_name` | El nombre de la réplica en ClickHouse Keeper. | | `other_parameters` | Parámetros del motor utilizado para crear la versión replicada; por ejemplo, la versión en `ReplacingMergeTree`. | Ejemplo: ```sql theme={null} CREATE TABLE table_name ( EventDate DateTime, CounterID UInt32, UserID UInt32, ver UInt16 ) ENGINE = ReplicatedReplacingMergeTree('/clickhouse/tables/{layer}-{shard}/table_name', '{replica}', ver) PARTITION BY toYYYYMM(EventDate) ORDER BY (CounterID, EventDate, intHash32(UserID)) SAMPLE BY intHash32(UserID); ```
Ejemplo con sintaxis obsoleta ```sql theme={null} CREATE TABLE table_name ( EventDate DateTime, CounterID UInt32, UserID UInt32 ) ENGINE = ReplicatedMergeTree('/clickhouse/tables/{shard}/table_name', '{replica}', EventDate, intHash32(UserID), (CounterID, EventDate, intHash32(UserID), EventTime), 8192); ```
Como muestra el ejemplo, estos parámetros pueden incluir sustituciones entre `{}`. Los valores sustituidos se toman de la sección [macros](/es/reference/settings/server-settings/settings#macros) del archivo de configuración. Ejemplo: ```xml theme={null} 02 example05-02-1 ``` La ruta de la tabla en ClickHouse Keeper debe ser única para cada tabla replicada. Las tablas en distintos segmentos deben tener rutas diferentes. En este caso, la ruta consta de las siguientes partes: `/clickhouse/tables/` es el prefijo común. Recomendamos usar exactamente este. `{shard}` se expandirá al identificador del segmento. `table_name` es el nombre del nodo de la tabla en ClickHouse Keeper. Conviene que sea el mismo que el nombre de la tabla. Se define explícitamente porque, a diferencia del nombre de la tabla, no cambia después de una consulta RENAME. *SUGERENCIA*: también puedes añadir un nombre de base de datos delante de `table_name`. Por ejemplo, `db_name.table_name` Se pueden usar las dos sustituciones integradas `{database}` y `{table}`; se expanden al nombre de la base de datos y al nombre de la tabla, respectivamente (a menos que estas macros estén definidas en la sección `macros`). Así, la ruta de ZooKeeper puede especificarse como `'/clickhouse/tables/{shard}/{database}/{table}'`. Ten cuidado al renombrar tablas cuando uses estas sustituciones integradas. La ruta en ClickHouse Keeper no se puede cambiar y, cuando se renombra la tabla, las macros se expandirán a una ruta distinta, la tabla hará referencia a una ruta que no existe en ClickHouse Keeper y pasará al modo de solo lectura. El nombre de la réplica identifica distintas réplicas de la misma tabla. Puedes usar para ello el nombre del servidor, como en el ejemplo. El nombre solo tiene que ser único dentro de cada segmento. Puedes definir los parámetros explícitamente en lugar de usar sustituciones. Esto puede resultar conveniente para hacer pruebas y para configurar clústeres pequeños. Sin embargo, en ese caso no puedes usar consultas DDL distribuidas (`ON CLUSTER`). Al trabajar con clústeres grandes, recomendamos usar sustituciones porque reducen la probabilidad de errores. Puedes especificar argumentos predeterminados para el motor de tabla `Replicated` en el archivo de configuración del servidor. Por ejemplo: ```xml theme={null} /clickhouse/tables/{shard}/{database}/{table} {replica} ``` En este caso, se pueden omitir argumentos al crear tablas: ```sql theme={null} CREATE TABLE table_name ( x UInt32 ) ENGINE = ReplicatedMergeTree ORDER BY x; ``` Equivale a: ```sql theme={null} CREATE TABLE table_name ( x UInt32 ) ENGINE = ReplicatedMergeTree('/clickhouse/tables/{shard}/{database}/table_name', '{replica}') ORDER BY x; ``` Ejecute la consulta `CREATE TABLE` en cada réplica. Esta consulta crea una nueva tabla replicada o añade una nueva réplica a una ya existente. Si añade una nueva réplica cuando la tabla ya contiene datos en otras réplicas, los datos se copiarán desde las otras réplicas a la nueva después de ejecutar la consulta. En otras palabras, la nueva réplica se sincroniza con las demás. Para eliminar una réplica, ejecute `DROP TABLE`. Sin embargo, solo se elimina una réplica: la que reside en el servidor donde ejecuta la consulta.
## Recuperación tras fallos
Si ClickHouse Keeper no está disponible cuando se inicia un servidor, las tablas replicadas pasan a modo de solo lectura. El sistema intenta conectarse periódicamente a ClickHouse Keeper. Si ClickHouse Keeper no está disponible durante un `INSERT`, o se produce un error al interactuar con ClickHouse Keeper, se lanza una excepción. Después de conectarse a ClickHouse Keeper, el sistema comprueba si el conjunto de datos del sistema de archivos local coincide con el conjunto de datos esperado (ClickHouse Keeper almacena esta información). Si hay inconsistencias menores, el sistema las resuelve sincronizando los datos con las réplicas. Si el sistema detecta partes de datos dañadas (con un tamaño de archivo incorrecto) o partes no reconocidas (partes escritas en el sistema de archivos pero no registradas en ClickHouse Keeper), las mueve al subdirectorio `detached` (no se eliminan). Las partes que faltan se copian desde las réplicas. Tenga en cuenta que ClickHouse no realiza ninguna acción destructiva, como eliminar automáticamente una gran cantidad de datos. Cuando el servidor se inicia (o establece una nueva sesión con ClickHouse Keeper), solo comprueba la cantidad y el tamaño de todos los archivos. Si los tamaños de los archivos coinciden, pero se han modificado bytes en algún punto intermedio, esto no se detecta de inmediato, sino solo al intentar leer los datos para una consulta `SELECT`. La consulta lanza una excepción por una suma de comprobación no coincidente o por el tamaño de un bloque comprimido. En este caso, las partes de datos se añaden a la cola de verificación y se copian desde las réplicas si es necesario. Si el conjunto local de datos difiere demasiado del esperado, se activa un mecanismo de seguridad. El servidor deja constancia de ello en el registro y se niega a iniciarse. Esto se debe a que este caso puede indicar un error de configuración, por ejemplo, si una réplica de un segmento se configuró accidentalmente como una réplica de otro segmento. Sin embargo, los umbrales de este mecanismo están configurados bastante bajos, y esta situación puede producirse durante una recuperación normal tras un fallo. En este caso, los datos se restauran de forma semiautomática, "pulsando un botón". Para iniciar la recuperación, cree el nodo `/path_to_table/replica_name/flags/force_restore_data` en ClickHouse Keeper con cualquier contenido, o ejecute el comando para restaurar todas las tablas replicadas: ```bash theme={null} sudo -u clickhouse touch /var/lib/clickhouse/flags/force_restore_data ``` A continuación, reinicie el servidor. Al arrancar, el servidor elimina estas marcas e inicia la recuperación.
## Recuperación tras la pérdida completa de datos
Si todos los datos y metadatos desaparecieron de uno de los servidores, siga estos pasos para recuperarlos: 1. Instale ClickHouse en el servidor. Defina correctamente las sustituciones en el archivo de configuración que contiene el identificador del segmento y las réplicas, si las usa. 2. Si tenía tablas no replicadas que deben duplicarse manualmente en los servidores, copie sus datos desde una réplica (en el directorio `/var/lib/clickhouse/data/db_name/table_name/`). 3. Copie las definiciones de las tablas ubicadas en `/var/lib/clickhouse/metadata/` desde una réplica. Si en las definiciones de las tablas se define explícitamente un identificador de segmento o de réplica, corríjalo para que corresponda a esta réplica. (Como alternativa, inicie el servidor y ejecute todas las consultas `ATTACH TABLE` que deberían haber estado en los archivos .sql de `/var/lib/clickhouse/metadata/`). 4. Para iniciar la recuperación, cree el nodo de ClickHouse Keeper `/path_to_table/replica_name/flags/force_restore_data` con cualquier contenido, o ejecute el comando para restaurar todas las tablas replicadas: `sudo -u clickhouse touch /var/lib/clickhouse/flags/force_restore_data` Luego inicie el servidor (reinícielo si ya se está ejecutando). Los datos se descargarán desde las réplicas. Una opción de recuperación alternativa es eliminar de ClickHouse Keeper la información sobre la réplica perdida (`/path_to_table/replica_name`) y, a continuación, volver a crear la réplica como se describe en "[Creación de tablas replicadas](#creating-replicated-tables)". No se aplica ninguna restricción al ancho de banda de red durante la recuperación. Téngalo en cuenta si está restaurando muchas réplicas a la vez.
## Conversión de MergeTree a ReplicatedMergeTree
Usamos el término `MergeTree` para referirnos a todos los motores de tabla de la `familia MergeTree`, al igual que en el caso de `ReplicatedMergeTree`. Si tiene una tabla `MergeTree` replicada manualmente, puede convertirla en una tabla replicada. Puede ser necesario hacerlo si ya ha recopilado una gran cantidad de datos en una tabla `MergeTree` y ahora desea habilitar la replicación. La sentencia [ATTACH TABLE ... AS REPLICATED](/es/reference/statements/attach#attach-mergetree-table-as-replicatedmergetree) permite adjuntar una tabla `MergeTree` detached como `ReplicatedMergeTree`. Una tabla `MergeTree` puede convertirse automáticamente al reiniciar el servidor si la marca `convert_to_replicated` está establecida en el directorio de datos de la tabla (`/store/xxx/xxxyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy/` para la base de datos `Atomic`). Cree un archivo vacío `convert_to_replicated` y la tabla se cargará como replicada en el siguiente reinicio del servidor. Esta consulta puede usarse para obtener la ruta de datos de la tabla. Si la tabla tiene varias rutas de datos, debe usar la primera. ```sql theme={null} SELECT data_paths FROM system.tables WHERE table = 'table_name' AND database = 'database_name'; ``` Tenga en cuenta que la tabla ReplicatedMergeTree se creará con los valores de los ajustes `default_replica_path` y `default_replica_name`. Para crear la tabla convertida en otras réplicas, deberá especificar explícitamente su ruta en el primer argumento del motor `ReplicatedMergeTree`. La siguiente consulta puede utilizarse para obtener esa ruta. ```sql theme={null} SELECT zookeeper_path FROM system.replicas WHERE table = 'table_name'; ``` También existe una forma manual de hacerlo. Si los datos difieren entre distintas réplicas, primero sincronícelos o elimine esos datos en todas las réplicas excepto en una. Cambie el nombre de la tabla MergeTree existente y, a continuación, cree una tabla `ReplicatedMergeTree` con el nombre antiguo. Mueva los datos de la tabla antigua al subdirectorio `detached` dentro del directorio que contiene los datos de la tabla nueva (`/var/lib/clickhouse/data/db_name/table_name/`). Luego ejecute `ALTER TABLE ATTACH PARTITION` en una de las réplicas para agregar estas partes de datos al conjunto activo.
## Conversión de ReplicatedMergeTree a MergeTree
Utilice la sentencia [ATTACH TABLE ... AS NOT REPLICATED](/es/reference/statements/attach#attach-mergetree-table-as-replicatedmergetree) para adjuntar una tabla `ReplicatedMergeTree` en estado detached como `MergeTree` en un único servidor. Otra forma de hacerlo requiere reiniciar el servidor. Cree una tabla `MergeTree` con un nombre diferente. Mueva todos los datos del directorio de la tabla `ReplicatedMergeTree` al directorio de datos de la nueva tabla. Luego elimine la tabla `ReplicatedMergeTree` y reinicie el servidor. Si quiere deshacerse de una tabla `ReplicatedMergeTree` sin iniciar el servidor: * Elimine el archivo `.sql` correspondiente en el directorio de metadatos (`/var/lib/clickhouse/metadata/`). * Elimine la ruta correspondiente en ClickHouse Keeper (`/path_to_table/replica_name`). Después de esto, puede iniciar el servidor, crear una tabla `MergeTree`, mover los datos a su directorio y luego reiniciar el servidor.
## Recuperación cuando se pierden o se dañan los metadatos en el clúster de ClickHouse Keeper
Si los datos de ClickHouse Keeper se perdieron o se dañaron, puede conservarlos moviéndolos a una tabla no replicada, como se describió anteriormente. **Véase también** * [background\_schedule\_pool\_size](/es/reference/settings/server-settings/settings#background_schedule_pool_size) * [background\_fetches\_pool\_size](/es/reference/settings/server-settings/settings#background_fetches_pool_size) * [execute\_merges\_on\_single\_replica\_time\_threshold](/es/reference/settings/merge-tree-settings#execute_merges_on_single_replica_time_threshold) * [max\_replicated\_fetches\_network\_bandwidth](/es/reference/settings/merge-tree-settings#max_replicated_fetches_network_bandwidth) * [max\_replicated\_sends\_network\_bandwidth](/es/reference/settings/merge-tree-settings#max_replicated_sends_network_bandwidth)