开发环境： macOS 12.4 + docker
一、环境搭建
docker-compose.yml
services: postgis: image: postgis/postgis:13-3.1 restart: always expose: - "5432" ports: - "5432:5432" environment: POSTGRES_USER: {POSTGRES_USER} POSTGRES_PASSWORD: {POSTGRES_PASSWORD} POSTGRES_DB: mydb POSTGRES_HOST: localhost POSTGRES_HOST_AUTH_METHOD: trust clickhouse: image: clickhouse/clickhouse-server:22.6.4 restart: always expose: - 9009 - 8123 ports: - "9009:9009" - "8123:8123" environment: platform: linux/amd64 ulimit nofile: 262144:262144 二、PgSQL 环境设置
要求
- wal_level 设置必须有一个值
logical和max_replication_slots参数必须有一个值至少2在 PostgreSQL 配置文件。 - 每个复制的表必须具有以下 副本标识之一：
- primary key (by default)
- index
wal_level
wal_level决定多少信息写入到 WAL 中。默认值是replica，它会写入足够的数据以支持WAL归档和复制，包括在后备服务器上运行只读查询。minimal会去掉除从崩溃或者立即关机中进行恢复所需的信息之外的所有记录。最后，logical会增加支持逻辑解码所需的信息。每个层次包括所有更低层次记录的信息。这个参数只能在服务器启动时设置。
在minimal级别中，某些批量操作的 WAL 日志可以被安全地跳过，这可以使那些操作更快（见populate-pitr）。这种优化可以应用的操作包括：
- CREATE TABLE AS
- CREATE INDEX
- CLUSTER
- COPY到在同一个事务中被创建或截断的表中
但最少的 WAL 不会包括足够的信息来从基础备份和 WAL 日志中重建数据，因此，要启用 WAL 归档（archive_mode）和流复制，必须使用replica或更高级别。
在logical层，与replica相同的信息会被记录，外加上 允许从 WAL 抽取逻辑修改集所需的信息。使用级别 logical将增加 WAL 容量，特别是如果为了REPLICA IDENTITY FULL配置了很多表并且执行了很多UPDATE和DELETE 语句时。
在 9.6 之前的版本中，这个参数也允许值archive和hot_standby。现在仍然接受这些值，但是它们会被映射到replica。
ALTER SYSTEM SET wal_level = logical; max_replication_slots
指定服务器可以支持的复制槽最大数量。默认值为10。这个参数只能在服务器启动时设置。将它设置为一个比当前已有复制槽要少的值会阻碍服务器启动。此外，要允许使用复制槽， wal_level必须被设置为replica或 更高。
ALTER SYSTEM SET max_replication_slots = 2; 笔记
改变设置后，需要重启 PgSQL 实例。
三、Clickhouse 迁移
数据库引擎#
使用 PostgreSQL 数据库中的表创建 ClickHouse 数据库。首先，带有引擎 MaterializedPostgreSQL 的数据库创建 PostgreSQL 数据库的快照并加载所需的表。所需表可以包括来自指定数据库的任何模式子集的任何表子集。随着快照数据库引擎获取 LSN，一旦执行了表的初始转储 - 它就开始从 WAL 中提取更新。创建数据库后，PostgreSQL 数据库中新添加的表不会自动添加到复制中。它们必须通过 ATTACH TABLE db.table 查询手动添加。
复制是使用 PostgreSQL 逻辑复制协议实现的，该协议不允许复制 DDL，但允许知道是否发生了复制中断更改（列类型更改、添加/删除列）。检测到此类更改并根据表格停止接收更新。如果打开所需的设置，此类表可以在后台自动重新加载（可以从 22.1 开始使用）。目前最安全的方法是使用 ATTACH/DETACH 查询来完全重新加载表。如果 DDL 不中断复制（例如，重命名列），表仍将接收更新（插入按位置完成）。
开启迁移引擎
SET allow_experimental_database_materialized_postgresql=1 创建数据库
CREATE DATABASE [IF NOT EXISTS] db_name [ON CLUSTER cluster] ENGINE = MaterializedPostgreSQL('host:port', 'database', 'user', 'password') [SETTINGS ...] Engine 参数
host:port— PostgreSQL 服务器地址database— PostgreSQL 数据库名称user— PostgreSQL 用户名password— PostgreSQL 用户密码
使用示例
CREATE DATABASE postgres_db ENGINE = MaterializedPostgreSQL('localhost:5432', 'postgres_database', 'postgres_user', 'postgres_password') SETTINGS materialized_postgresql_tables_list='table1,table2,table3',materialized_postgresql_allow_automatic_update = 1; SHOW TABLES FROM postgres_db; ┌─name───┐ │ table1 │ └────────┘ SELECT * FROM postgres_db.table1; 设置
materialized_postgresql_tables_list#
设置 PostgreSQL 数据库表的逗号分隔列表，将通过 MaterializedPostgreSQL 数据库引擎进行复制。
默认值：空列表 — 表示将复制整个 PostgreSQL 数据库。
materialized_postgresql_schema#
默认值：空字符串。 （使用默认模式） materialized_postgresql_schema_list#
默认值：空列表。 （使用默认模式） materialized_postgresql_allow_automatic_update#
不要在 22.1 版本之前使用此设置。
当检测到架构更改时，允许在后台重新加载表。 PostgreSQL 端的 DDL 查询不会通过 ClickHouse MaterializedPostgreSQL 引擎进行复制，因为 PostgreSQL 逻辑复制协议不允许这样做，但 DDL 更改的事实是 交易检测。 在这种情况下，默认行为是在检测到 DDL 后停止复制这些表。 但是，如果启用此设置，则不会停止这些表的复制，而是通过数据库快照在后台重新加载它们，而不会丢失数据，并且将为它们继续复制。
可能的值：
- 0 — 当检测到架构更改时，表不会在后台自动更新。
- 1 — 当检测到架构更改时，表会在后台自动更新。
默认值：“0”。
materialized_postgresql_max_block_size#
设置在将数据刷新到 PostgreSQL 数据库表之前在内存中收集的行数。
可能的值：
- 正整数。
默认值：65536。
materialized_postgresql_replication_slot#
用户创建的复制槽。 必须与 materialized_postgresql_snapshot 一起使用。
materialized_postgresql_snapshot#
标识快照的文本字符串，将从中执行 PostgreSQL 表的初始转储。 必须与 materialized_postgresql_replication_slot 一起使用。
CREATE DATABASE database1 ENGINE = MaterializedPostgreSQL('postgres1:5432', 'postgres_database', 'postgres_user', 'postgres_password') SETTINGS materialized_postgresql_tables_list = 'table1,table2,table3'; SELECT * FROM database1.table1; 如有必要，可以使用 DDL 查询更改设置。 但是不可能更改设置 materialized_postgresql_tables_list。 要更新此设置中的表列表，请使用 ATTACH TABLE 查询。
ALTER DATABASE postgres_database MODIFY SETTING materialized_postgresql_max_block_size = <new_size>; 动态添加新表到复制
MaterializedPostgreSQL 数据库创建后，它不会自动检测相应 PostgreSQL 数据库中的新表。 可以手动添加此类表：
ATTACH TABLE postgres_db.new_table; 警告
在 22.1 版本之前，将表添加到复制会留下一个未删除的临时复制槽（名为 {db_name}_ch_replication_slot_tmp）。 如果在 22.1 之前的 ClickHouse 版本中附加表，请确保手动删除它（SELECT pg_drop_replication_slot('{db_name}_ch_replication_slot_tmp')）。 否则磁盘使用量会增加。 此问题已在 22.1 中修复。
从复制中动态删除表
可以从复制中删除特定表：
DETACH TABLE postgres_db.table_to_remove; 表引擎#
使用 PostgreSQL 表的初始数据转储创建 ClickHouse 表并启动复制过程，即执行后台作业以应用在远程 PostgreSQL 数据库中的 PostgreSQL 表上发生的新更改。
如果需要多张表，强烈建议使用 MaterializedPostgreSQL 数据库引擎代替表引擎并使用materialized_postgresql_tables_list 设置，它指定要复制的表（也可以添加数据库 schema）。在远程 PostgreSQL 数据库中的 CPU、更少的连接和更少的复制槽方面会好得多。
创建表
CREATE TABLE postgresql_db.postgresql_replica (key UInt64, value UInt64) ENGINE = MaterializedPostgreSQL('localhost:5432', 'postgres_database', 'postgresql_replica', 'postgres_user', 'postgres_password') PRIMARY KEY key; Engine 参数
host:port— PostgreSQL 服务器地址database— PostgreSQL 数据库名称table- PostgreSQL 表名user— PostgreSQL 用户名password— PostgreSQL 用户密码
要求
- wal_level 设置必须有一个值
logical和max_replication_slots参数必须至少有一个值2在 PostgreSQL 配置文件中。 - 使用
MaterializedPostgreSQL引擎的表必须有一个主键——与 PostgreSQL 表的副本标识索引（默认：主键）相同（参见 副本标识索引的详细信息）。 - 只允许使用数据库 Atomic。
虚拟列
创建表时不需要添加这些列。它们始终可以在 SELECT 查询中访问。 _version 列等于 WAL 中的 LSN 位置，因此它可能用于检查复制的最新程度。
CREATE TABLE postgresql_db.postgresql_replica (key UInt64, value UInt64) ENGINE = MaterializedPostgreSQL('postgres1:5432', 'postgres_database', 'postgresql_replica', 'postgres_user', 'postgres_password') PRIMARY KEY key; SELECT key, value, _version FROM postgresql_db.postgresql_replica; 
