开发者学堂课程【PostgreSQL 快速入门：PostqreSQL 表级复制-Londiste3多节点数据同步合并到单节点】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/16/detail/74
PostqreSQL 表级复制-Londiste3多节点数据同步合并到单节点
内容介绍
一、拆分
二、merge 数据
三、测试
一、拆分
1.merge 与拆分
接下来讲解的是 Londiste 的最后一个案例，howtoo 里最后一个案例 merge，merge 指的是把多个节点数据 merge到一个节点，
再讲 merge 之前，先进行拆分，与 merge 相反，将一个节点拆分成多个节点数据，merge 是将多个节点拆分成一个节点，是反面过程，在讲 merge 之前先讲一下 partition， 
Partition 是从 src 节点上 partition 的四个节点，之前讲解过节点f值，其中 branch 是分支节点，Leaf 是叶子节点，Branch 节点下面可以挂在 brunch 节点或者 leaf 节点，但是 leaf 节点下面不能再添加任何节点，因为在 leaf 节点中没有 pgq，Brunch 节点中要启动 pgq 进程，包括 root 节点也要启动 pg q，所以在 branch 节点中可以查看 pg q，先查看原节点的 pg q，原节点之前写过1万条记录
查看事件有一万条记录，select*from pgq._1 event where ev_extral =digoal_01.user_account
大写的 i 表示 insert,以 ID 为组件的插入，后面是 date，这条记录的总的数据，从 ID 看，从第一条开始插入，因为使用的是多值函数插入，所以会从一一直插到1万，Event extra 3是 hash 值，hash 值是根据 ID 得到的，date 中可以看到一万条记录，对于 branch 分支节点，里面包含 pgq 等的 schema，包括这些 select*from pgq._1 event where ev_extral =digoal_01.user_account 值都有，例如3639branch 节点，查此 branch 节点，这里其实也是一万条，01是叶子节点，叶子节点中没有 schema，pgq schema 根本就不存在，连接到 branch 节点可以看到，将10000条事件都过来了，虽然是分区的方法，但是因为它是 branch 节点，所以相当于 pgq 队列做了负载，全部负载到这里，再将需要的数据 prey 到数据表中，也就是 user_account 中，队列的数据是完整的，队列数据在第一个下划线02中是完整的在 branch 节点，通过 select event date 可以看到，所有的数据都在其中，对于另外两个 branch节点同样，所有的 event 都通过消息队列负载过来了，这里是需要注意的点，虽然用了分区，但是消息队列是一样的，每一个节点的子节点消息队列都是同样的。
接下来讲解 merge 数据的合并
二、merge 数据
1.节点
merge 数据与拆分是相反的过程，一般用在 PL/proxy 的分区，要将各个分区的数据合并到一个数据仓库里，合到数据仓库可以通过 merge 这种方法进行合并，这个 demonstrate 用了两个 part，现在执行的用了四个 demo，也就是提到的四个数据库，将四个数据库合成一个表
例如四个数据库提到的配置文件，配置文件其实是一样的，一模一样没有变化，所以不用更改配置文件，根节点相当于分布在各个节点中，要创建根节点必须要安装 sky too，在实际生产环境中去使用根节点都要安装 sky too，因为要用到 io 文件，动态编辑库，首先在各个节点先创建根节点，创建根节点的目的是生成消息队列，允许生成消息队列，现在讲解 full data base 前面讲解的是 Partition database，full database 是消费者，前面的 provide 是向消息队列中写入数据，full database 是消费者，去消息队列中取数据，Full database 的配置也一样，没有任何变化，在这里的 full database 相当于用到了两个q，也就是两个队列，因为这里的队列名不一样，相当于 full database 里面要写两个配置文件，每一个队列都需要对应一个配置文件去启它，启动的时候相当于创建了叶子节点，叶子节点名字是 merge part 1 full，叶子节点对应的数据库是 db name，Provide 的是 db name 等于 part 1，然后将队列起来，队列的配置文件中包含 database list，List 中包含所有的库，涉及到的库，例如 partition 节点和 full 节点，在启动 pg q 时，要先看是否要做限制，如果不做限制，所有的数据库都放在 Database list 里面，在启动 worker 进程，启动 worker 进程之后去分区节点里面创建测试表，再将表加入分区节点配置文件中，向里面插入数据，连接到full 节点查看数据是否已经过来，连接到负一里查询 londist table infe
特别是队列名称，表名，在 full database 中可以看到合并过来的节点的名字，相当于 database list 里面就限制了这些，所以要写 database list，现在插入设置数据，要等待十秒钟，在连接到 full database 里查找数据，在此之前使用 merge all 参数，Create 表示默认创建表在 full database 中，进行合并
这两个分区节点是添加表，full database 也是添加表，但是使用了 merge all，merge all会用到 Londist table info表里的一些东西，part1 full Init 是合并的意思，full database 有两个配置文件，一个是 part 1-full1，一个是 part 2-full2，其实只用了一个配置文件，用到了 merge all，merge all 相当于将所有队列对应的统一的表合并到节点中，所有的根节点，相当于在 q 里面有两个根节点，队列对应的数据库来自于两个根节点。
2.londiste
查看一下 merge 里面除了对应 merge all 还有什么
merge 里面其实还可以指定q的名字，也就是队列的名字，Q name 其实在 full 节点里其实是可以看到的有几个 q 的name，要合并几个队列，就制作几个队列的名字，让 merge=q 再多指定几个就可以了，稍后不使用 merge all，数据负载环境很复杂，某一些队列需要复制，某一些队列却不需要复制，可以进行指定，merge all 表示所有的原队列，no merge 表示不做 merge，此之外就没有与 merge 相关的东西了。
三、测试
1.队列
接下来做做测试，相当于一栏使用四个表，将他merge到另外一个地方去，使用 user account 表，是在环境里面所用到的，User account 相当于一开始从150 digoal01分发到四个节点当中，稍后要从四个节点在合并到主库中的另外一个库中，例如现在创建一个库叫做 full，Full 可能是保留着，所以叫 full 1，创建 schema，然后创建表l
现在这张表就创建成功了，要将数据合并到这里来，首先是要创造队列，是在分区上创造根节点，但是有一些分区已经是 branch 节点了，如果已经是 branch 节点了，要在四个表中重新生成一个配置文件，每一个都创建一个配置文件，然后使用四个队列名称，例如是四个 partition，dst1拷贝到 pdst1,2改为 pdst2就是 partition 的意思,3改为pdst3,注意是拷贝过去，并不是删掉4拷贝到4，这里的队列名使用不同的队列名，为了与前面的有区分，这里的队列名叫做p1，因为要重新启动一个，所以日志 pid 都要改，否则会有冲突，脚本 name 也要改掉，前面加一个p就可以，其他的不用改，2也要改脚本 name 改成p2，对应的 q 名改成 p2，再把三和四改掉，四个配置文件已经改好了，然后要创建根节点，相当于用这些改的去创造根节点，要注意这里用的队列名，p1，P2P 3p4总共四个队列名是job name，
现在 create node/home/pg93/londiste3/pdsti_digoal_01.ini create-root 创建根节点，根节点的名字是 p1，然后是一个连接，第一个节点来自于39，再创建第二个，第二个库名叫做 p2，第二个创建好，在创建第三个，第三个节点来自于3.33，名字 p3，然后再继续创建第四个，名字为p4
现在相当于有四个 root 节点，从 pg93edb-172-16-3-150-> londiste3 /home/pg93/londiste3/src_digoal_01.ini status Queue:replikaLocalnode: src_digoal_01查看状态，因为是从队列里面输出的状态，用 p 查看，londiste3 /home/pg93/londiste3/pdst1_digoal_01.ini status: ni查看状态，只能看到 p1，因为它对应的队列名称是 p1，相当于是完全隔离的，队列也是隔离的，二也只能看到二，现在四个 root 节点已经创建好了，接下来要配置full database 1，是要合并的节点，merge 节点的配置文件，每个对应一个要有四个配置文件提供 provide，将 p 改为m拷贝一下，Job name 也改为 m，数据库名是172.16.3.150，因为是merge到数据库里的，merge数据名为full1的数据库中，Q name 是队列名，因为有很多个队列，所以这里队列名为p1，然后再修改 mdst2，Host 改为17 2.1 6.3.150，Port 改为1921，库名为 full1，队列名是p2，在修改 mdst3，Host 改为17 2.1 6.3.150，Port改为1921，合并的库名改为 full 1，队列名为 p3，相当于每个队列对复制队列每一个都给了配置文件在合并时，，然后再修改md st4Host 改为17 2.1 6.3.150，Port 改为1921，合并的库名改为 full 1，队列名为 p4，然后再创建叶子节点，londiste3 -v/home/pg93/londiste3/ndsti_digoal_0i.ini create-leaf，将叶子节点取名字，称为m1，指定 provide，前面已经将 root 节点加好了，接下来加叶子节点，叶子节点每一个配置文件都要添加为叶子节点，
pg93@db-172-16-3-150-> londiste3 -v/hone/pg93/londiste3/ndst3_digoal_01.ini create -leaf m1 "host-172.16.3.150 port=1921 user-postgr
dbname-full1password-postgres" --provider-"host-172.16.3.33 port=5432 user post tgres dbnane-digoal_04 password-postgres"对应的是 master 1 mdst1创建叶子节点，Create leaf，01对应的Provide 的是01节点17 2.16点3.39，对应的是 full1，对应的订阅者是1921，对应的 full database 是订阅者，取名为m1，然后是第二个节点，前面都一样，只需要改名字为 m2，dst2，3的源库来自于一七二点一六点3.33服务器，对应的 database 也是 full database，改名为3，Mdst 也是3，再将四号节点也加上，加第四个节点的时候出现了一个问题，不能够连接到 server，查看一下配置是否出现了问题
是配置文件出现的问题，四号节点的酷的配置文件忘记改端口了，将端口改为1921，现在可以了，查看 worker 进程，接下来要启动 worker 进程，四个节点的 q 还没有启动，Q 也要连接过去进行启动，使用 cat pgqd.ini 查看 q，每一个都要创建 q 的配置文件，pg93edb-172-16-3-150-> cp pgqd.ini pgqd_pdsti.ini pg93edb-172-16-3-150-> vi pgqd，Q文件叫做 ini
[pgqd ]
base_connstr -host=172.16.3.33 port=5432 user=postgres
password-postgres initial_database =template1
logfile=/home/pg93/londiste3/log/pgqd.log
pidfile=/home/pg93/londiste3/pid/pgqd.pid
这里要做更改，Q 是运行在172.16.3.39上面的，日志文件也要进行更改，Pid 也要更改一下，因为是启动在一个地方不能有冲突，下面是更改之后的
[pbbđ]
base_connstr-host=172.16.3.39 port=5432 user-postgres
password-postgres initial_database = template1
logfile…/home/pg93/londiste3/1og/pgqd_pdst1.log pidfile=/home/pg93/londiste3/pid/pgqd_pdst1.pid
cp pgqd_pdst1.ini pgqd_pdst1.ini
cp pgqd_pdst1.ini pgqd_pdst2.ini
cp pgqd_pdst1.ini pgqd_pdst3.ini
cp pgqd_pdst1.ini pgqd_pdst4.ini
一改为二，相当于总共有四个分区需要四个 q，同时要在本地启动队列，先将队列启动起来
150上面有一个队列，相当于3.33上面已经有一个队列了，在3.39上面再起一个队列就可以，总共物理的集群最后只是涉及到了3.33和3.39以及150，在原来的设置中，3.150和3.33是 base_connstr -host=172.16.3.33 port=5432 user-postgres password=postgres initial_database -template1
logfile=/home/pg93/londiste3/1og/pgqd.log
pidfile…/home/pg93/londiste3/pid/pgqd.pid
pg93edb-172-16-3-150->这个
，这是需要再加一个3.39的队列cp pgqd150.ini pgqd39.ini vi pgqd39.ini
[pyqd]
base_connstr -host-172.16.3.150 port=1921 user postgres
password-postgres initial_database = template1
logfile=/home/pg93/londiste3/log/pgqd150.log
pidfile-/home/pg93/londiste3/pid/pgqd150.pid
这里改成39就可以了，Port改为5432
base connstr - host 172.16.3.39 port-5432 user postgrespassword-postgres
initial_database -template1
logfile-/home/pg93/londiste3/log/pgqd39.log
pidfile=/home/pg93/londiste3/pid/pgqd39.pid
这就是更改之后的，将 pg q 启动，使用 pgq-v-d 指令，现在39这个队列也有了，现在队列都有了。
2. worker 进程
使用
londiste3 -u-d /home/pg93/londiste3/mdst1_digoal_01.ini worker_指令，二的，三的以及四的 worker 都要启动，这样四个合并的 worker 就启动起来了，是 full database 的 worker，其实现在 petition 的 work 还没有启动，Partition 的我也有启动，现在启动一下 partition 的 worker，例子中少了启动 worker 的过程
londiste3 -y-d /home/pg93/londiste3/pdst1_digoal_0i.ini worker1 32497 DEBUG __init__
londiste3 -y-d /home/pg93/londiste3/pdst2_digoal_02.ini worker32500 DEBUG_init__
londiste3-v-d/home/pg93/londiste3/pdst3_digoa1_03.ini worker32503 DEBUG__init__
londiste3 -v-d /home/pg93/londiste3/pdst4 digoal_04.ini worker
相当于启动了八个 worker，三个 pg q demo，三个对应的是1503339，里面包含了所有数据库的 q，worker 加上原来的 worker 已经有了很多个，后面启动了八个，前面有五个，Pg q 启动了三个。
3.添加表
添加表示在 partition 中完成的，现在 partition 中做，在做 merge，添加的表是通过对应的配置文件通过
home/pg93/londiste3/pdst1_digoal_01.ini add-table 连接到 partition dst1，对应的表名是digoal1_01.user_account,最终要将 user account 合并到full1下面去，pdst1_digoal_0i 是将 partition 表添加进来，第二个库也要添加进来，home/pg93/londiste3/pdst2_digoal_02.ini add-table，总共四个的分区都要添加进来，
home/pg93/londiste3/pdst3_digoal_03.ini add-table
home/pg93/londiste3/pdst4_digoal_04.ini add-table
四个都添加过来了，不用插值，因为里面已经有值了。接下来连接到 full database，要连接到 full digoal 01，表里面有 londiste table info 这张表
这里面对应有四个队列，说明同一个表来自于四个队列，P1, P2P 3p4，四个队列有这张表，然后做 merge，因为表已经加好了，merge 可以进行指定，
复制到/home/pg93/londiste3/ndst1_digoal_01.ini add-table digoal_01.user_account，然后指定 merge，merge里面要指定队列的名字
P1, P2P 3p4，pg93Cdb-172-16-3-150-> londiste3 -u/home/pg93/londiste3/ndst1_digoal_01.ini add-t able digoal_01.user_account --nerge-p1 --merge=p2 nerge-p3 --merge-p4。
这里报了错，因为用法有一些问题，crashed db error，发现多个源 User account use all orno to continuesource for table，查看一下p1，P2P 3p4这种写法可不可以，这种写法同样不支持，再换一种写法 p1, P2,P 3,p4这种写法也不行，error cannot protect.，没有办法只能使用 merge all，pg93Cdb-172-16-3-150-> londiste3 -u/home/pg93/londiste3/ndst1_digoal_01.ini add-t able digoal_01.user_account --nerge-p1 --merge all，四个队列合并成了一个，查找 select * from longest table in order by q name 状态。
现在看到在 in copy 的状态，相当于从四个队列里面取数据合并到一个表，现在是正在拷贝的状态，是查找 Longest table info 得到的结论，现在查找 select count from user account，记录还是零条，因为正在拷贝，拷贝完成之后merge 状态变为 ok，在此之前查看日志
是一个 merge 日志，现在已经 catch up，1万条数据已经过来了，对于的日志也可以通过 merge 去看，报错都可以通过这个去看
现在相当于还有三个节点正在做 catch up，emerge 马上要同步完成，完成之后可以做 campaign，这个例子相当于把多个节点合并到一个节点，完成之后可以看到状态变为了 ok，在主节点，也就是原库这里面的一些变更相当于是q到了另外一些节点，3.33~3.39一些分区节点，这些分区节点在通过合并，合并到 full database 里，现在就可以在里面进行一些 update 等的操作，例如连接到 digoal 01里面有一个 user account 表,可以做映射 Update delete 这样一些操作，例如创建一个函数
create or replace function ftest(i id int) returns void as
$$ declare begin
perforn 1 fron user_account where id-i_id; if found then
update user_account set ert_time=now() where id-i_id; else
insert into user_account values
(i_id,mdS(randon():itext),now()) end if;
exception when others then
return: end;
$$ language plpgsql strict:
select ftest(1);这样1就被更新过来了
现在可以看到一的时间已经更新成了当前时间，如果是零，相当于插入一条记录，现在做一个压力测试，结果已经合并完了，Test.sql
'test.sql" 2L, 43C written
pg93edb-172-16-3-150-> pgbench -M prepared-n-r-f./test.sql -c 8 -j 2 -T 160 -U digoal_01
相当于1~500万一直在做,八个连接两个线程测试160秒,连接到 digoal 01库，最终数据会有大的流转，从01库里面的表 user account，从这个表流转到四个分区表，四个分区分别是在39上，这是消息队列数据也在慢慢的过来，流转到四个分区表，从状态可以看到
从这个根节点流转到了这四个的分区节点，再从四个分区节点流转到合并的节点里面，/home/pg93/londiste3/mdst2_digoal_02.ini status 合并节点，这个合并到 p1，p2合并到 p2，三合并到 p3，因为他们的队列名称不一样，四，合并到批次，最终是合并 full database 一个节点。full digoal 01这个节点里面
相当于合并到 user account 这张表，现在数据都还没有过来，可以看到这里面的一些变化，所有的 londiste 强光进程都放在3.150里面
可以看到右面在做一些消息队列的传输，中间是正在压的过程，idle 是与 Python 相关的，再生成一些消息队列的东西。再查看两个分区节点，
两个分区节点一直在做复制，数据从3.150过来，复制到1200.16.3.150里对应的分区表中，例如0304两个这里对应的其实是0102，0102一直在做 Pray
“test.sql" 2L, 43C written
pg93edb-172-16-3-150-> pgbench -M preparedtes160
digoal_0i digoa1_01
transaction type: Custom query scaling factor: i
query node: prepared nunber of clients: 8 nunber of threads!
2 duration: 160 s
nunber of transactions actually processed: 1153912
tps =7211.921919 (including connections establishing) tps
-7212.510051 (excluding connections establishing) statement
latencies in milliseconds:
0.003356 lsetrandom id 1 5000000
1.103679select ftest(:id):
pg93edb-172-16-3-150->
这样过程就结束，压了160秒，一直在做队列的传输，能够看到在 full1里面还没有数据传输过来，但是在各个子节点里面，消息一直都在传输，因为是一个 Event 表，相当于一直在传输，总共传了七万多条消息，总共执行了一百一十五万多个事务，消息有115万多个，现在只出传输了八十多万个，对于 user account 表也是一批一批的在进来，但是合并还没有开始，进程可以看 status 进程
merge 状态 OK，等它完成 merge，这里不管怎么等待数据都不会复制过来，再重新初始化数据 rethink
Rethink 之后发现数据到这里就结束了，消息队列里的数据不会在传输过来的，原因是在子节点中，例如3339上其实里面创建了多个队列，启用了多个队列，查看 demo
Pgq 进程已经启了，150还有 ini，3.33上面的队列，39上面队列的启动脚本
Database 上面都有一些队列的存在，但是在编辑 partition pdst01时的队列名称叫做 p1，但实际上在查询时发现，查找 pgq_node.local 状态时
总共有两个队列，Provide 的节点是他本身，Provide 的节点来自于 Src，相当于消费者是 pdst3，但是在消息队列里面根本没有任何数据再查的时候，在来自 prelika 消息队列里基本上数据都在这里，所有事件的消息队列其实都在。查看 ext 表
里面有节点的信息，对应于 p3是根节点，worker name 是 pdst3
然后看 subscribe 订阅者的信息，对于 p3的 queue 来讲，订阅节点是 m3，订阅 name 是 mdst3，node location里面看到一些位置信息，例如 p3这个 queue 有两个 location，一个来自于33一个来自于3.150，数据库是 full 1，这里面是它自己。
对于单个表来讲，发生了一些变更，下面有几个触发器，一个是p3，还有 replica 队列的触发器，上面有几个队列，就有几个队列的触发器，P3触发器会调用 procedure 函数调用参数p3，查看 event 写到哪个数据表中
对于第一个 q 的 event，可能现在 event1或者 event2中，可以去 pg q 点 queen 里面查看队列，P3对应的事件表示event 2，所以在 event2里面就可以看到一些数据，这个表可能是继承表，查看一下
是一个主表，下面三个继承表，相当于p3队列的数据写在这里面，里面存储的是 p3队列的数据，使用 account*查看，里面只有27条记录，在做完操作之后，在执行五秒钟，表一定会有数据新增，队列现在里面没有数据，因为这个表数据的变更来自于主表的变更，来自于 digoal 复制过来，消息队列这些变更的记录在 event1里，也就是 Replica对应的消息事件里
相当于在绿色里不是做的直接变更，而是从消息队列中触发的变更，如果要将这个数据合并在此场景中是看不到数据合并过程的，除非将这些表上面的触发器删除掉，直接去里面生成数据，就可以看到变更，执行五秒钟查看一下
发现绿色的数据会有增长，但是 event 二没有任何增长，因为数据变更是从主节点拷贝过来的事件，三万多条数据是从3.150 User Account 表拷贝到各个子节点上面的 event 1对应的 Replica 的Queen Name，现在来看 q Name
通过这个来看，全部拷贝到 Replika 的 queue 里面，并不是得到了 p3的 queen，在做数据合并时，应该指定的queue name 是 Replika
===Full database==:
On the full database, which will hold data from both partitions
you need to set up two londiste nodes, one for each of the
partition nodes. These will act as the receiving nodes to
replicate to.
These look very sinilar and differ only in queue nane
File conf/13_part1_q full1.ini:
[londiste3]
job_nane = 13_part1_q_fulll db=dbname=full1
queue_name=13_part1_g
logfile=1og/%(job_name)s.log pidfile=pid/%(iob name)s.pid
File conf/13_part2_g full1in:
[londiste3]
job nane=13_part2_g full1 db=dbname=full1
queue_nane=13_part2_q
logfile=1og/%(iob_name)s.log pidfile=pid/%(job name)spid
再次场景中应该指定 replica，如果使用在其他场景，例如表完全是本地的，不是从其他地方复制过来的表，在当地节点 insert into digoal 产生的事件会触发到p3的 queen 里面去，就是 event2里面的数据，但是对于这个场景，Insert语句都不是来自于本地节点，而是来自于远端复制过来的，远端复制过来的消息队列，在这里做 reply，P3对应的消息队列里面根本不会有数据，所以无论执行多少条，在 full database 里面也不会看到数据合并，这时需要修改配置文件，说明消息队列来源有问题，要将消息队列改掉，队列名改为 Replica，让他从这个消息队列里获取，队列二也要改，也将消息队列改为 Replica，队列三也改为 Replica，队列四也是同样将消息队列改为 Replica
[londiste3]
job nane =mdst4_digoal_04
db - host=172.16.3.150 port 1921 user postgres dbname-fulli
password postgres queue nane - replika
logfile =/home/pg93/londiste3/log/mdst4 digoal 04.log pidfile=/home/pg93/londiste3/pid/mdst4_digoa1_04.pid
parallel_copies -16
然后进行 reload
londiste3 -r./mdst1_digoal_01.ini
londiste3 -r./mdst2_digoal_02.ini
londiste3 -r ./mdst3_digoal_03.ini
londiste3 -r./mdst4_digoa1_04.ini
然后查信息
看到 Q name.没有变化，要将 q name 改掉，看一下日志，还是从队列中去取，所以要将进程删掉，重新启动，Stop，然后再启动，1234都有依次停掉，因为 q 已经变更了，之前使用的方法创建的节点已经将 q 注册进去了，现在使用./mdst1_digoal_01.ini进行启动，它是叶子节点，使用此进行删除，找到 drop Note 进行删除/mdst1_digoal_01.ini drop-node ndst1_digoal_01，因为在注册时已经注册为了指定的 p1，P2，P 3，p4的queue，所以在这里还需要重新做 job，重新进行注册，本地节点是 m1，要将名字修改为./mdst1_digoal_01.ini drop-node m1，这样就可以进行删除了，先将文件恢复，再将对应的删掉
删除m1./mdst1_digoal_01.ini drop-node m1
删除m2./mdst2_digoal_02.ini drop-node m2
删除m3./mdst3_digoal_03.ini drop-node m3
删除m4./mdst4_digoal_04.ini drop-node m4
现在将这些里面的队列都删掉了，现在重新修改文件，改回 replica，先将它改回为 replica，再重新创建节点
[londiste3]
job nane = ndst4_digoal_04
db - host-172.16.3.150 port-1921 user postgres dbname-fulll
password-postgres queue_nane = replika
logfile=/home/pg93/londiste3/log/mdst4_digoa1_04.log pidfile=/home/pg93/londiste3/pid/mdst4_digoa1_04.pid
parallel_copies -16
更改完以后创建节点，不用理会 root 节点，创建的是叶子节点，
pg93@db-172-16-3-150-> londiste3 -v./mdst1_digoal_01.ini create-leaf m1 "host ?2.16.3.150 port-1921 user postgres dbnane full1 pas sword-postgres"--provider-"host=172.16.3.39 port=5432 user-postgres dbnane-digoal01 password-postgres"
叶子节点的名称是 m1，数据库的名称是172.16.3.33，Provide 的是从各个子节点中获取的，第一个字节点来自于39，合并的数据库是 full 1，创建叶子节点时 Register 失败，不能够订阅到叶子节点，因为第一个节点是 list 节点dsti_digoal_01 (leaf)是叶子节点，上面是没有队列的，所以没有办法做订阅，在这个环境中要将其改为 branch 节点才能够订阅消息，直接将它删除，在进行创建就可以完成这项操作./dsti_digoal_01.ini drop-node dsti_digoa1_01，使用这个指令就可以将节点删掉了，再去看状态时，这个节点就不存在了，然后创建 brunch 节点，将 work 节点加进去，表也加进去，这个过程稍微有一点复杂，下面为大家演示如何从复杂的环境中将它提取出来 pg930db-172-16-3-150-> londiste3 -v./dst1_digoa1_01.ini create-branch dst1_digoal01 "host=172.16.3.39 port-5432 user postgres dbna
ne-digoa1_01
password-postgres”--provider-"host-172.16.3.39 port-5432 user postgredbnane-digoal_01 password-postgres"
此时再看状态已经加进来了，digoal01就加进来了，刚刚在添加节点时添加了一个 m1节点，这个节点已经添加好了，其实就是刚刚添加的节点挂载这上面，也可以将其删除，重新添加./mdst1_digoal_01.ini drop-node m1，显示已经存在，说明刚才进行添加时失败了，导致这里此时出现错误，在此要将其强制删除，只是添加表示使用了，先不管这个，先将 brunch 表加进来，Brunch 表现在一个都没有，将 worker 进程起来 londiste3 -d ./dst1_digoal_01.ini worker，worker 进程启动以后要向其中添加表
pg93edb-172-16-3-150-> londiste3 ./dst1_digoa1_01.ini add-table digoal_01.user_acco ount --handler part --handler-arg-hash_key-id --ha ndler-arg
对于 user account 表之前使用的是 partition 方式，在这里接入进来也要使用 partition 方式，启 worker 进程前面都一样，只是在添加表的时候，有一个步骤不一样，就是指定 handler 还有 key，加的是 handler part --和 handler-arg，这是 account 用的 ID，然后再指定行数，这个表就加进去了，worker 进程也有了，接着回到 merge，下来看一下他的状态，现在负载了一个表，查看 dst1的 tables，数据还没有合并过来，还有等待数据合并，已经在拷贝了，刚才加 m1没有成功，现在试着加一下 m2
pg93Cdb-172-16-3-150-> londiste3 -./mdst2_digoa1_02.ini create-leaf m2 "host-172.16.3.150 port-1921 user postgres dbnane-fulll pas sword-postgres" --provider-"host-172.16.3.39 port-5432 user postgres dbnane-digoal01 password-postgres"
创建 leaf 节点叫做 m2的，显示配置文件不存在，没有关系，m2现在就加载成功了，现在加 m3
pg93edb-172-16-3-150-> londiste3 -v./mdst3_digoal_03.ini create-leaf m3 "host-172.16.3.150 port-1921 user postgres
dbname-fulll pas
sword-postgres”--provider-"host-172.16.3.33 port=5432 user
postgres dbnane-digoal03 password-postgres"
M 三对应的节点是3.33上面的，显示 Note is already initialized as leaf，Date 03是 leaf 节点，但是这里其实是brunch 节点，这里是参数出现的错误，显示 Replica 节点已经是 leaf 节点了，Replica 在150库里面已经是叶子节点了，也就是 m2没有办法再继续加了，这种通过节点之后再合并到库这种方法是有问题的，相当于在队列中打环了，在 replica 对列里打环了形成了环状，Londiste 禁止这样操作，要想正规的完成一次合并，要重新开始完成，重新命名队列，首先进行创建的队列是39上面的队列，前面经过多次的尝试，这条路是走不通的，正常的实际应用场景要做合并各个节点的数据源都是自己在写的数据源，而不是从其他地方复制过来的。
