ClickHouse 副本同步备份

本文详细介绍了如何在ClickHouse中设置主副本和副本,通过Zookeeper实现数据的高可用性和容灾。配置包括在主库和副本库上创建metrika.xml配置文件,定义Zookeeper服务器,并在表结构中使用ReplicatedMergeTree引擎进行数据同步。在主库上创建表并插入数据后,副本会自动同步,确保数据一致性。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

副本的目的主要是保障数据的高可用性与容灾,即使一台ClickHouse节点宕机,那么也可以从其他服务器获得相同的数据。副本数据同步,意思就是在主表上做任何增删改的操作,副本会进行相应的同步操作。而副本的数据则是来源与主表。副本同步只能同步数据,不能同步表结构,所以每台机器上的表需要自己手动创建。

主副本配置

zookeeper可单节点也可以集群,这里采用单节点模式。在主库 /etc/clickhouse-server/config.d/ 的目录中创建metrika.xml配置文件,内容如下

<yandex>
    <zookeeper-servers>
        <node index="1">
            <host>这里可以是zookeepr所在的服务器IP也可以是在hosts中映射好的主机名字</host>
            <port>2181</port>
        </node>
    </zookeeper-servers>
</yandex>

然后在 /etc/clickhouse-server/config.xml 中找到所在行,在它的下方将上面创建的metrika.xml引入进去
在这里插入图片描述
然后重启,副本clickhouse-server也做如上同样的操作。完成配置后,就可以建表测试。

在主库上创建如下表:

create table t_order_rep (
    id UInt32,
    sku_id String,
    total_amount Decimal(16,2),
    create_time  Datetime
 ) engine =ReplicatedMergeTree('/clickhouse/tables/01/t_order_rep','rep_102')
   partition by toYYYYMMDD(create_time)
   primary key (id)
   order by (id,sku_id);

在副本上创建如下表:

create table t_order_rep (
    id UInt32,
    sku_id String,
    total_amount Decimal(16,2),
    create_time  Datetime
 ) engine =ReplicatedMergeTree('/clickhouse/tables/01/t_order_rep','rep_103')
   partition by toYYYYMMDD(create_time)
   primary key (id)
   order by (id,sku_id);

参数解释
ReplicatedMergeTree 中,
  第一个参数是分片的zk_path一般按照: /clickhouse/table/{shard}/{table_name} 的格式写,如果只有一个分片就写01即可。
  第二个参数是副本名称,相同的分片副本名称不能相同。

然后在主库中执行以下插入语句,这个时候副本也会出现一样的数据

insert into t_order_rep values
(101,'sku_001',1000.00,'2020-06-01 12:00:00'),
(102,'sku_002',2000.00,'2020-06-01 12:00:00'),
(103,'sku_004',2500.00,'2020-06-01 12:00:00'),
(104,'sku_002',2000.00,'2020-06-01 12:00:00'),
(105,'sku_003',600.00,'2020-06-02 12:00:00');

引用来源:https://www.cnblogs.com/shengyang17/p/14282944.html#_lab2_0_1

### ClickHouse全量备份文件体积过小的原因分析 当使用 `clickhouse-backurp` 工具执行全量备份时,如果发现生成的备份文件体积明显小于预期,可能存在以下几个原因: #### 1. 数据压缩设置不当 ClickHouse 支持多种数据压缩算法,默认情况下会启用 LZ4 或 ZSTD 进行表级压缩。如果配置了较高的压缩级别,则可能导致备份文件看起来较小。 ```sql SELECT name, compression_codec FROM system.tables WHERE database='your_database'; ``` 对于这种情况,建议检查当前数据库中的表所使用的具体压缩方式[^1]。 #### 2. 备份工具版本不匹配 不同版本之间存在兼容性差异,某些旧版 clickhouse-backup 可能无法正确处理新特性或优化后的存储格式,从而影响到最终导出的数据完整性。 可以尝试升级至最新稳定版本并重新测试效果如何变化[^2]。 #### 3. 表结构变更未同步更新 假如最近进行了 DDL (Data Definition Language) 操作比如新增列、删除索引等操作之后立即做了备份动作,在这种场景下有可能因为元数据尚未完全刷新而导致部分对象丢失。 应当确认是否存在近期修改过的模式定义语句,并适当等待一段时间再做一次新的快照副本创建过程[^3]。 #### 解决方案概述 针对上述提到的各种可能性,采取如下措施有助于解决问题: - **验证环境一致性**: 确认源端与目标端部署相同版本的服务程序以及配套组件; - **调整参数选项**: 修改 `.config.yaml` 中有关于 snapshot 的设定项来控制行为逻辑; - **定期维护作业计划**: 定期安排清理无用历史记录的任务以减少不必要的空间占用情况发生; 通过以上方法应该能够有效改善 clickhouse-backup 所产生的镜像包尺寸异常现象。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值