- StorageEngine - mailweb.opengauss.org

openGauss （storageengine）社区统计知会
by issuemanager＠public.opengauss.org 13 Jun '22

13 Jun '22

1 0

openGauss （storageengine）社区统计知会
by issuemanager＠public.opengauss.org 12 Jun '22

12 Jun '22

1 0

openGauss （storageengine）社区统计知会
by issuemanager＠public.opengauss.org 10 Jun '22

10 Jun '22

1 0

openGauss （storageengine）社区统计知会
by issuemanager＠public.opengauss.org 09 Jun '22

09 Jun '22

1 0

by luozihao 09 Jun '22

09 Jun '22

yes

1 0

openGauss （storageengine）社区统计知会
by issuemanager＠public.opengauss.org 08 Jun '22

08 Jun '22

1 0

openGauss （storageengine）社区统计知会
by issuemanager＠public.opengauss.org 07 Jun '22

07 Jun '22

1 0

【20220602】发布订阅支持基础数据复制特性checkin评审遗留问题及解决
by chenxiaobin (F) 07 Jun '22

07 Jun '22

发布订阅支持基础数据复制特性checkin评审遗留问题及解决会议时间：2022.6.2 14:30-16:30 与会人：熊小军彭炯吴岳川陈琛王磊王江陈晓滨特性详情：可见20220506邮件《openGauss发布订阅支持基础数据同步设计评审纪要》 PR链接：https://gitee.com/opengauss/openGauss-server/pulls/1770 遗留问题： 1. 需要添加测试用例。已添加，见代码文件pubsub_check.sh 2. 需测试旧版本的发布端和新版本的订阅端之间做基础数据复制的具体报错表现测试结果：会报ERROR: could not receive list of replicated tables from the publisher: FATAL: replication command parser returned 1 因为订阅端会向发布端发送查询发布的表的SQL命令，但旧版本的walsender无法处理SQL命令。 3. 全量复制过程中可能存在数据不一致，原因是存在这种场景：表1在做全量复制，而表2在做增量复制，此时多表查询结果不一致表在做增量追赶的过程中，全局增量的apply线程是在等待的，前者追赶上并退出后，后者才继续做增量。最终的一致性是确定的。 4. 性能分析当前性能测试结果为：5张表，每张表5000w行记录，共计17.83G的基础数据，225s完成同步。后续做具体性能瓶颈分析和优化，当前版本无明确性能指标。 5. 考虑同一张表或不同表的双向订阅当前版本不支持基础数据的双向复制，后续根据实际需求安排。

1 0

openGauss （storageengine）社区统计知会
by issuemanager＠public.opengauss.org 06 Jun '22

06 Jun '22

1 0

openGauss （storageengine）社区统计知会
by issuemanager＠public.opengauss.org 05 Jun '22

05 Jun '22

1 0

2024

2023

2022

2021

2020

StorageEngine