中奖用户公示：本次活动在截止日期内共有效盖楼26层，属于【有效盖楼数量50层以内】，奖品为：openGauss书籍1本，并给获奖者加赠HDC纪念章1枚；恭喜用户【蜡笔不辣】获得以上奖品，如需更换请在问卷中进行备注或私信我进行沟通。问卷链接已发送，请在3个工作日内填写问卷，10月27日零点以后未填写的中奖用户视为放弃！【活动主题】《数据库原理*GaussDB云数据库》系列课程——数据库理论基础 第一期：有奖竞答【活动时间】2020年8月16日 - 10月10日【奖品展示】【参与方式】Step1.  MOOC报名&学习：https://www.icourse163.org/course/NENU-1464035185Step2.  完成下方6道“有奖竞答”题：【回复方式】1. 华为云账号+MOOC报名学习截图；2.有奖竞答题：序号+答案；【奖励规则】所有参与盖楼的用户，均可参与抽奖！1.有效盖楼数量50层以内，奖品为：openGauss书籍1本，并给获奖者加赠HDC纪念章1枚；2.有效盖楼数量50≤X≤100层，奖品为：openGauss书籍1本，高硼玻璃杯2个，雨伞3把，并给获奖者加赠HDC纪念章各一枚；3.有效盖楼数量X＞100层以上，奖品为：openGauss书籍1本，GaussDB字母笔2盒，高硼玻璃杯3个，雨伞（X-100）/20个，中奖名额根据有效盖楼层数而定，并给获奖者加赠HDC纪念章各一枚；注：每个用户盖楼总数不能超过5层，禁止连续盖楼；【推荐考证 ▪ 选做】《数据库原理▪GaussDB云数据库》MOOC中涉及到GaussDB(for MySQL)，巩固知识，顺便考个证！HCIA-GaussDB  华为认证数据库工程师   培养与认证具备华为GaussDB数据库应用开发及管理能力的工程师适合人群：希望从事数据库开发或管理岗位的人员；售前/售后工程师/技术支持人员HCIP-GaussDB-OLTP 华为认证数据库高级工程师   培养与认证具备华为GaussDB(for MySQL)数据库二次开发及管理能力的高级工程师适合人群：希望成为GaussDB(for MySQL)数据库管理员的人员；希望成为数据库二次开发高级工程师考证权益：【倾情推荐】云数据库2.4折起，助力千行百业加速上云【注意事项】1.获奖结果将在活动结束后7个工作日内进行公示，请报名和留言的伙伴关注社区内容，所有奖品将在活动结束后15个工作日内发放。2.活动奖品颜色随机，且部分奖品数量有限发完将用等值奖品代替；3.活动参与需遵守《华为社区常规活动规则》；4.为保证活动的公平公正，华为云有权对恶意刷活动资源（“恶意”是指为获取资源而异常注册账号等破坏活动公平性的行为），利用资源从事违法违规行为的用户收回抽奖及奖励资格。5.本次活动一个实名认证账号只能对应一个获奖人，如同一账号填写多个不同获奖人，不予发放奖励；6.本活动最终解释权归华为云所有。【往期活动】【第2期 开学见面礼】博导带你学MOOC，盖楼就享4000元代金券服务，还有8种好礼拿！【第3期 华为“云”赏月】分享数据库MOOC，价值199元华为云背包等你来拿！ 【第4期 国庆最嗨免费区】华为云数据库：MOOC免费学、沙箱免费玩，229元移动电源送不停！

6月20日，在ACM SIGMOD国际学术会议“中国数据库高峰论坛”，华为云数据库产品部总经理苏光牛发表了《云数据库的创新与发展》主题演讲，分享了华为云GaussDB数据库5大创新技术，坚持生态开放理念，加速千行百业数字化转型。数字化时代下，企业对云数据库提出了更高要求，既希望云数据库能满足海量业务场景下的复杂需求，又希望可以降低使用成本，提升业务效率，保障数据安全。云数据库也成为了产业升级转型和重塑产业格局的关键抓手。苏光牛提到，华为很早就开始重视数据库的投入和发展，从2007年开始研究数据库，到2020年统一数据库品牌GaussDB，华为持续战略投入数据库，并布局全球7大研究所，汇聚了一批海内外数据库领域专业人才，同时布局前沿技术，积极打造行业领先的技术竞争力。华为云数据库产品部总经理苏光牛发表演讲华为云GaussDB聚焦业务新场景，打造了以下5大核心技术竞争力：金融级高可用：华为云GaussDB提供了多种高可用方案，包括AZ内高可用、跨AZ多活、异地跨Region容灾的两地三中心容灾方案，满足金融级监管要求，并且历经银行核心关键业务严苛考验。软硬协同全栈能力：依托华为全产业链优势，垂直整合华为软硬件全栈资源，不断提升竞争力。企业级混合负载：分布式+全并行架构设计，提供事务处理与复杂查询高性能，支持1000+超大分布式集群能力，可以轻松应对海量高并发数据处理和复杂查询场景的考验。全密态数据库安全：华为云GaussDB实现从密钥处理、查询、内存、存储等全方位的安全合规和隐私保护，包括链路安全、存储安全、访问安全，同时对应用实现尽可能的透明，保证客户隐私安全。智能运维与调优：结合AI技术，实现数据库自动优化与调优等功能，让数据库管理变得更加智能高效。数据库呼唤开放的生态，华为也始终坚持开源开放理念，积极构建良好的数据库生态关系。华为云GaussDB目前已支持华为自有openGauss生态与主流开源数据库生态（如MySQL、MongoDB、Redis、InfluxDB、Cassandra等）。华为还将GaussDB部分核心能力开源到openGauss社区，鼓励合作伙伴基于开源openGauss发行属于自己的商业版本。此外，华为持续和高校联合开课，致力于培养数据库人才，繁荣数据库生态。目前，华为云GaussDB已在1000+大客户规模商用，遍布金融、政府、电信、能源、交通、电商等。另外还在SIGMOD、ICDE、VLDB等国际知名学术会议发表累计50+篇创新成果论文，内容涵盖系统架构、事务处理、AI自治、安全等。面向未来，华为云GaussDB将持续打造领先技术和服务，与更多合作伙伴一起共创时代新价值，共赢未来新机遇！

123123123123 508119

论坛发帖验证---060101

删除联盟帖子测试----060101

现网发帖验证----0524

312312312312312

4月24-26日，华为开发者大会2021（HDC·Cloud）在深圳隆重举办。在名师大讲堂分会场，华为云数据库多位技术专家分享了GaussDB系列数据库全新5大黑科技，包括支持亿级时间线、千万级tpmC突破、两地三中心、AI自治等，通过技术创新不断为企业数字化转型注入新动力。黑科技1：GaussDB(for Influx)支持亿级时间线随着云计算规模越来越大，物联网（IoT）和运维监控（AIOps）领域的时序数据呈爆炸式增长，海量时序数据的存储和管理也成为一大难题。为了应对数据膨胀带来的管理、监控等挑战，华为云时序数据库GaussDB(for Influx)对内存分配、回收、单查询等功能做了大量优化，同时通过对数据分区分级、专用存储引擎、自适应压缩算法、高性能多维聚合查询、存储分析告警统一架构等技术的提升，实现亿级时间线下系统写入性能的稳定，大幅超出开源InfluxDB写入能力。华为云创新lab数据库专家现场分享黑科技2：GaussDB性能突破1500万tpmC 华为云企业级分布式数据库GaussDB基于计算存储分离架构，着重构筑传统数据库的企业级能力和互联网分布式数据库的高扩展和高可用能力。作为主打政企核心业务负载的金融级分布式数据库旗舰产品，它通过GTM-Lite技术和分布式优化器提供极致的分布式扩展能力，保证事务全局强一致，性能突破传统数据库瓶颈，实现 32节点1500万tpmC，在银行业务实测中，性能大幅度领先其他云厂商。华为云数据库首席产品经理现场分享黑科技3：GaussDB(for MySQL) 极致备份恢复能力作为华为云新一代高性能企业级分布式数据库，GaussDB(for MySQL) 通过定制的分布式存储系统，支持数据库秒级快照备份；并行高速复制下，实现数据快速备份和恢复；通过冷热数据分离，实现TB级数据最快20分钟内恢复可用，而且支持任意时间点恢复，为数据的安全可靠提供了强有力的保障。黑科技4：GaussDB与AI结合，让数据库运维更加高效、极简华为云GaussDB通过将AI技术植入到数据库内核的架构和算法中，让数据库管理更加智能与高效。如GaussDB通过利用AI 技术实现数据库自调优、自诊断、自安全、自运维、自愈等能力。典型场景如慢SQL 发现、索引推荐、基于性能指标的时序预测与异常发现、参数智能调优等，借助 AI 技术能更好地优化数据库的性能，协助DBA 降低运维难度，提升运维效率，自动调度平衡资源池。黑科技5：GaussDB支持跨 AZ/Region 部署，让数据底座更加稳定可靠在政企客户最为关注的高可用方面，华为云GaussDB提供了多种高可用方案，包括同城AZ内高可用、跨AZ高可用、异地跨Region的两地三中心容灾方案，提供跨AZ的读一致性访问，多AZ节点必须读到一致的数据，满足金融级监管要求。比如GaussDB通过独有的Switch Turbo技术，保障了同城AZ内单点故障能够快速切换，实现RPO=0，RT0小于10秒。这5大黑科技是华为云GaussDB前进路上的重大新路标，也是华为云GaussDB匠心打造领先数据库服务的重要体现。华为云GaussDB深知，在数字化时代下，企业的业务场景会更加复杂，对云数据库的要求会水涨船高，谁能抓住新一轮发展机遇，更快更好提升技术和服务，就可以在未来发展中获得更大的主动权。华为云GaussDB会不断积蓄力量，持续打造更与时俱进、更贴合企业场景的数据库服务，进一步加速企业数字化转型。详情内容可戳：cid:link_0

### 引言 熟悉MySQL的朋友应该都知道，MySQL集群主从间数据同步机制十分完善。令人惊喜的是，ClickHouse作为近年来炙手可热的大数据分析引擎也可以挂载为MySQL的从库，作为MySQL的 "协处理器" 面向OLAP场景提供高效数据分析能力。早先的方案比较直截了当，通过第三方插件将所有MySQL上执行的操作进行转化，然后在ClickHouse端逐一回放达到数据同步。终于在2020年下半年，Yandex 公司在 ClickHouse 社区发布了MaterializeMySQL引擎，支持从MySQL全量及增量实时数据同步。MaterializeMySQL引擎目前支持 MySQL 5.6/5.7/8.0 版本，兼容 Delete/Update 语句，及大部分常用的 DDL 操作。 ### 基础概念 - **MySQL & ClickHouse** MySQL一般特指完整的MySQL RDBMS，是开源的关系型数据库管理系统，目前属于Oracle公司。MySQL凭借不断完善的功能以及活跃的开源社区，吸引了越来越多的企业和个人用户。 ClickHouse是由Yandex公司开源的面向OLAP场景的分布式列式数据库。ClickHouse具有实时查询，完整的DBMS及高效数据压缩，支持批量更新及高可用。此外，ClickHouse还较好地兼容SQL语法并拥有开箱即用等诸多优点。 - **Row Store & Column Store** MySQL存储采用的是Row Store，表中数据按照 Row 为逻辑存储单元在存储介质中连续存储。这种存储方式适合随机的增删改查操作，对于按行查询较为友好。但如果选择查询的目标只涉及一行中少数几个属性，Row 存储方式也不得不将所有行全部遍历再筛选出目标属性，当表属性较多时查询效率通常较低。尽管索引以及缓存等优化方案在 OLTP 场景中能够提升一定的效率，但在面对海量数据背景的 OLAP 场景就显得有些力不从心了。 ClickHouse 则采用的是 Column Store，表中数据按照Column为逻辑存储单元在存储介质中连续存储。这种存储方式适合采用 SIMD (Single Instruction Multiple Data) 并发处理数据，尤其在表属性较多时查询效率明显提升。由于列存方式中物理相邻的数据类型通常相同，因此天然适合数据压缩，从而达到极致的数据压缩比。  ### 使用方法 - 部署Master-MySQL 开启BinLog功能：ROW模式 开启GTID模式：解决位点同步时MySQL主从切换问题（BinLog reset导致位点失效） ```shell # my.cnf关键配置 gtid_mode=ON enforce_gtid_consistency=1 binlog_format=ROW ``` - 部署Slave-ClickHouse 获取 [ClickHouse/Master](https://github.com/ClickHouse/ClickHouse) 代码编译安装 推荐使用`GCC-10.2.0`，`CMake 3.15`，`ninja1.9.0`及以上 - 创建Master-MySQL中database及table ```mysql creat databases master_db; use master_db; CREATE TABLE IF NOT EXISTS `runoob_tbl`( `runoob_id` INT UNSIGNED AUTO_INCREMENT, `runoob_` VARCHAR(100) NOT NULL, `runoob_author` VARCHAR(40) NOT NULL, `submission_date` DATE, PRIMARY KEY ( `runoob_id` ) )ENGINE=InnoDB DEFAULT CHARSET=utf8; # 插入几条数据 INSERT INTO runoob_tbl (runoob_, runoob_author, submission_date) VALUES ("MySQL-learning", "Bob", NOW()); INSERT INTO runoob_tbl (runoob_, runoob_author, submission_date) VALUES ("MySQL-learning", "Tim", NOW()); ``` - 创建 Slave-ClickHouse 中 MaterializeMySQL database ```sql # 开启materialize同步功能 SET allow_experimental_database_materialize_mysql=1; # 创建slave库，参数分别是("mysqld服务地址", "待同步库名", "授权账户", "密码") CREATE DATABASE slave_db ENGINE = MaterializeMySQL('192.168.6.39:3306', 'master_db', 'root', '3306123456'); ``` 此时可以看到ClickHouse中已经有从MySQL中同步的数据了： ```mysql DESKTOP:) select * from runoob_tbl; SELECT * FROM runoob_tbl Query id: 6e2b5f3b-0910-4d29-9192-1b985484d7e3 ┌─runoob_id─┬─runoob_title───┬─runoob_author─┬─submission_date─┐ │ 1 │ MySQL-learning │ Bob │ 2021-01-06 │ └───────────┴────────────────┴───────────────┴─────────────────┘ ┌─runoob_id─┬─runoob_title───┬─runoob_author─┬─submission_date─┐ │ 2 │ MySQL-learning │ Tim │ 2021-01-06 │ └───────────┴────────────────┴───────────────┴─────────────────┘ 2 rows in set. Elapsed: 0.056 sec. ``` ### 工作原理 - BinLog Event MySQL中BinLog Event主要包含以下几类： ```mysql 1. MYSQL_QUERY_EVENT　　　　-- DDL 2. MYSQL_WRITE_ROWS_EVENT　-- insert 3. MYSQL_UPDATE_ROWS_EVENT -- update 4. MYSQL_DELETE_ROWS_EVENT -- delete ``` 事务提交后，MySQL 将执行过的 SQL 处理 BinLog Event，并持久化到 BinLog 文件 ClickHouse通过消费BinLog达到数据同步，过程中主要考虑３个方面问题： 1、DDL兼容：由于ClickHouse和MySQL的数据类型定义有区别，DDL语句需要做相应转换 2、Delete/Update 支持：引入`_version`字段，控制版本信息 3、Query 过滤：引入`_sign`字段，标记数据有效性 - DDL操作 对比一下MySQL的DDL语句以及在ClickHouse端执行的DDL语句： ```mysql mysql> show create table runoob_tbl\G; *************************** 1. row *************************** Table: runoob_tbl Create Table: CREATE TABLE `runoob_tbl` ( `runoob_id` int unsigned NOT NULL AUTO_INCREMENT, `runoob_` varchar(100) NOT NULL, `runoob_author` varchar(40) NOT NULL, `submission_date` date DEFAULT NULL, PRIMARY KEY (`runoob_id`) ) ENGINE=InnoDB AUTO_INCREMENT=3 DEFAULT CHARSET=utf8 1 row in set (0.00 sec) --------------------------------------------------------------- cat /metadata/slave_db/runoob_tbl.sql ATTACH TABLE _ UUID '14dbff59-930e-4aa8-9f20-ccfddaf78077' ( `runoob_id` UInt32, `runoob_` String, `runoob_author` String, `submission_date` Nullable(Date), `_sign` Int8 MATERIALIZED 1, `_version` UInt64 MATERIALIZED 1 ) ENGINE = ReplacingMergeTree(_version) PARTITION BY intDiv(runoob_id, 4294967) ORDER BY tuple(runoob_id) SETTINGS index_granularity = 8192 ``` 可以看到： 1、在DDL转化时默认增加了2个隐藏字段：_sign(-1删除, 1写入) 和 _version(数据版本) 2、默认将表引擎设置为 ReplacingMergeTree，以 _version 作为 column version 3、原DDL主键字段 runoob_id 作为ClickHouse排序键和分区键 此外还有许多DDL处理，比如增加列、索引等，相应代码在`Parsers/MySQL` 目录下。 - Delete/Update操作 Update： ```mysql # Mysql端： UPDATE runoob_tbl set runoob_author='Mike' where runoob_id=2; mysql> select * from runoob_tbl; +-----------+----------------+---------------+-----------------+ | runoob_id | runoob_title | runoob_author | submission_date | +-----------+----------------+---------------+-----------------+ | 1 | MySQL-learning | Bob | 2021-01-06 | | 2 | MySQL-learning | Mike | 2021-01-06 | +-----------+----------------+---------------+-----------------+ 2 rows in set (0.00 sec) ---------------------------------------------------------------- # ClickHouse端： DESKTOP:) select *, _sign, _version from runoob_tbl order by runoob_id; SELECT *, _sign, _version FROM runoob_tbl ORDER BY runoob_id ASC Query id: c5f4db0a-eff6-4b49-a429-b55230c26301 ┌─runoob_id─┬─runoob_title───┬─runoob_author─┬─submission_date─┬─_sign─┬─_version─┐ │ 1 │ MySQL-learning │ Bob │ 2021-01-06 │ 1 │ 2 │ │ 2 │ MySQL-learning │ Mike │ 2021-01-06 │ 1 │ 4 │ │ 2 │ MySQL-learning │ Tim │ 2021-01-06 │ 1 │ 3 │ └───────────┴────────────────┴───────────────┴─────────────────┴───────┴──────────┘ 3 rows in set. Elapsed: 0.003 sec. ``` 可以看到，ClickHouse数据也实时同步了更新操作。 Delete： ```mysql # Mysql端 mysql> DELETE from runoob_tbl where runoob_id=2; mysql> select * from runoob_tbl; +-----------+----------------+---------------+-----------------+ | runoob_id | runoob_title | runoob_author | submission_date | +-----------+----------------+---------------+-----------------+ | 1 | MySQL-learning | Bob | 2021-01-06 | +-----------+----------------+---------------+-----------------+ 1 row in set (0.00 sec) ---------------------------------------------------------------- # ClickHouse端 DESKTOP:) select *, _sign, _version from runoob_tbl order by runoob_id; SELECT *, _sign, _version FROM runoob_tbl ORDER BY runoob_id ASC Query id: e9cb0574-fcd5-4336-afa3-05f0eb035d97 ┌─runoob_id─┬─runoob_title───┬─runoob_author─┬─submission_date─┬─_sign─┬─_version─┐ │ 1 │ MySQL-learning │ Bob │ 2021-01-06 │ 1 │ 2 │ └───────────┴────────────────┴───────────────┴─────────────────┴───────┴──────────┘ ┌─runoob_id─┬─runoob_title───┬─runoob_author─┬─submission_date─┬─_sign─┬─_version─┐ │ 2 │ MySQL-learning │ Mike │ 2021-01-06 │ -1 │ 5 │ └───────────┴────────────────┴───────────────┴─────────────────┴───────┴──────────┘ ┌─runoob_id─┬─runoob_title───┬─runoob_author─┬─submission_date─┬─_sign─┬─_version─┐ │ 2 │ MySQL-learning │ Mike │ 2021-01-06 │ 1 │ 4 │ │ 2 │ MySQL-learning │ Tim │ 2021-01-06 │ 1 │ 3 │ └───────────┴────────────────┴───────────────┴─────────────────┴───────┴──────────┘ 4 rows in set. Elapsed: 0.002 sec. ``` 可以看到，删除id为2的行只是额外插入了`_sign == -1`的一行记录，并没有真正删掉。 - 日志回放 MySQL 主从间数据同步时Slave节点将 BinLog Event 转换成相应的SQL语句，Slave 模拟 Master 写入。类似地，传统第三方插件沿用了MySQL主从模式的BinLog消费方案，即将 Event 解析后转换成 ClickHouse 兼容的 SQL 语句，然后在 ClickHouse 上执行（回放），但整个执行链路较长，通常性能损耗较大。不同的是，MaterializeMySQL 引擎提供的内部数据解析以及回写方案隐去了三方插件的复杂链路。回放时将 BinLog Event 转换成底层 Block 结构，然后直接写入底层存储引擎，接近于物理复制。此方案可以类比于将 BinLog Event 直接回放到 InnoDB 的 Page 中。 ### **同步策略** - 位点同步 v20.9.1版本前是基于位点同步的，ClickHouse每消费完一批 BinLog Event，就会记录 Event 的位点信息到 `.metadata` 文件: ```mysql [FavonianKong@Wsl[20:42:37]slave_db] $ cat ./.metadata Version: 2 Binlog File: mysql-bin.000003 Binlog Position:355005999 Data Version: 5 ``` 这样当 ClickHouse 再次启动时，它会把 {‘mysql-bin.000003’, 355005999} 二元组通过协议告知 MySQL Server，MySQL 从这个位点开始发送数据： ``` s1> ClickHouse 发送 {‘mysql-bin.000003’, 355005999} 位点信息给 MySQL s2> MySQL 找到本地 mysql-bin.000003 文件并定位到 355005999 偏移位置，读取下一个 Event 发送给 ClickHouse s3> ClickHouse 接收 binlog event 并完成同步操作 s4> ClickHouse 更新 .metadata位点 ``` **存在问题：** 如果MySQL Server是一个集群，通过VIP对外服务，MaterializeMySQL创建 database 时 host 指向的是VIP，当集群主从发生切换后，`{Binlog File, Binlog Position}` 二元组不一定是准确的，因为BinLog可以做reset操作。 ``` s1> ClickHouse 发送 {'mysql-bin.000003’, 355005999} 给集群新主 MySQL s2> 新主 MySQL 发现本地没有 mysql-bin.000003 文件，因为它做过 reset master 操作，binlog 文件是 mysql-bin.000001 s3> 产生错误复制 ``` 为了解决这个问题，v20.9.1版本后上线了 GTID 同步模式，废弃了不安全的位点同步模式。 - GTID同步 GTID模式为每个 event 分配一个全局唯一ID和序号，直接告知 MySQL 这个 GTID 即可，于是`.metadata`变为: ```mysql [FavonianKong@Wsl[21:30:19]slave_db] Version: 2 Binlog File: mysql-bin.000003 Executed GTID: 0857c24e-4755-11eb-888c-00155dfbdec7:1-783 Binlog Position:355005999 Data Version: 5 ``` 其中 `0857c24e-4755-11eb-888c-00155dfbdec7` 是生成 Event的主机`UUID`，`1-783`是已经同步的event区间 于是流程变为: ``` s1> ClickHouse 发送 GTID:0857c24e-4755-11eb-888c-00155dfbdec7:1-783 给 MySQL s2> MySQL 根据 GTID 找到本地位点，读取下一个 Event 发送给 ClickHouse s3> ClickHouse 接收 BinLog Event 并完成同步操作 s4> ClickHouse 更新 .metadata GTID信息 ``` ### 源码分析 - 概述 在最新源码 (v20.13.1.1) 中，ClickHouse 官方对 DatabaseMaterializeMySQL 引擎的相关源码进行了重构，并适配了 GTID 同步模式。ClickHouse 整个项目的入口 `main` 函数在 `/ClickHouse/programs/main.cpp` 文件中，主程序会根据接收指令将任务分发到 `ClickHouse/programs` 目录下的子程序中处理。本次分析主要关注 Server 端 `MaterializeMySQL` 引擎的工作流程。 - 源码目录 与 MaterializeMySQL 相关的主要源码路径： ```c++ ClickHouse/src/databases/MySQL //MaterializeMySQL存储引擎实现 ClickHouse/src/Storages/ //表引擎实现 ClickHouse/src/core/MySQL* //复制相关代码 ClickHouse/src/Interpreters/ //Interpreters实现，SQL的rewrite也在这里处理 ClickHouse/src/Parsers/MySQL //解析部分实现,DDL解析等相关处理在这里 ``` - 服务端主要流程 ClickHouse 使用 POCO 网络库处理网络请求，Client连接的处理逻辑在 ClickHouse/src/Server/*Handler.cpp 的 hander方法里。以TCP为例，除去握手，初始化上下文以及异常处理等相关代码，主要逻辑可以抽象成: ```c++ // ClickHouse/src/Server/TCPHandler.cpp TCPHandler.runImpl() { ... while(true) { ... if (!receivePacket()) //line 184 continue /// Processing Query //line 260 state.io = executeQuery(state.query, *query_context, ...); ... } ``` - 数据同步预处理 Client发送的SQL在executeQuery函数处理，主要逻辑简化如下： ```c++ // ClickHouse/src/Interpreters/executeQuery.cpp static std::tuple executeQueryImpl(...) { ... // line 354，解析器可配置 ast = parseQuery(...); ... // line 503, 根据语法树生成interpreter auto interpreter = InterpreterFactory::get(ast, context, ...); ... // line 525, 执行器interpreter执行后返回结果 res = interpreter->execute(); ... } ``` 主要有三点： 1、解析SQL语句并生成语法树 AST 2、InterpreterFactory 工厂类根据 AST 生成执行器 3、interpreter->execute() 跟进第三点，看看 InterpreterCreateQuery 的 excute() 做了什么： ```c++ // ClickHouse/src/Interpreters/InterpreterCreateQuery.cpp BlockIO InterpreterCreateQuery::execute() { ... // CREATE | ATTACH DATABASE if (!create.database.empty() && create.table.empty()) // line 1133, 当使用MaterializeMySQL时，会走到这里建库 return createDatabase(create); } ``` 这里注释很明显，主要执行 CREATE 或 ATTACH DATABASE，继续跟进 createDatabase() 函数： ```c++ // ClickHouse/src/Interpreters/InterpreterCreateQuery.cpp BlockIO InterpreterCreateQuery::createDatabase(ASTCreateQuery & create) { ... // line 208, 这里会根据 ASTCreateQuery 参数，从 DatabaseFactory 工厂获取数据库对象 // 具体可以参考 DatabasePtr DatabaseFactory::getImpl() 函数 DatabasePtr database = DatabaseFactory::get(create, metadata_path, ...); ... // line 253, 多态调用，在使用MaterializeMySQL时 // 上方get函数返回的是 DatabaseMaterializeMySQL database->loadStoredObjects(context, ...); } ``` 到这里，相当于将任务分发给DatabaseMaterializeMySQL处理，接着跟踪 loadStoredObjects 函数： ```c++ //ClickHouse/src/Databases/MySQL/DatabaseMaterializeMySQL.cpp template void DatabaseMaterializeMySQL::loadStoredObjects(Context & context, ...) { Base::loadStoredObjects(context, has_force_restore_data_flag, force_attach); try { // line87, 这里启动了materialize的同步线程 materialize_thread.startSynchronization(); started_up = true; } catch (...) ... } ``` 跟进startSynchronization() 绑定的执行函数： ```c++ // ClickHouse/src/Databases/MySQL/MaterializeMySQLSyncThread.cpp void MaterializeMySQLSyncThread::synchronization() { ... // 全量同步在 repareSynchronized() 进行 if (std::optional metadata = prepareSynchronized()) { while (!isCancelled()) { UInt64 max_flush_time = settings->max_flush_data_time; BinlogEventPtr binlog_event = client.readOneBinlogEvent(...); { //增量同步侦听binlog_envent if (binlog_event) onEvent(buffers, binlog_event, *metadata); } } } ... } ``` - 全量同步 MaterializeMySQLSyncThread::prepareSynchronized 负责DDL和全量同步，主要流程简化如下： ```c++ // ClickHouse/src/Databases/MySQL/MaterializeMySQLSyncThread.cpp std::optional MaterializeMySQLSyncThread::prepareSynchronized() { while (!isCancelled()) { ... try { //构造函数内会获取MySQL的状态、MySQL端的建表语句， MaterializeMetadata metadata(connection, ...); // line345, DDL相关转换 metadata.transaction(position, [&]() { cleanOutdatedTables(database_name, global_context); dumpDataForTables(connection, metadata, global_context, ...); }); return metadata; } ... } } ``` ClickHouse作为MySQL从节点，在MaterializeMetadata构造函数中对MySQL端进行了一系列预处理： 1、将打开的表关闭，同时对表加上读锁并启动事务 2、TablesCreateQuery通过SHOW CREATE TABLE 语句获取MySQL端的建表语句 3、获取到建表语句后释放表锁 继续往下走，执行到 metadata.transaction() 函数，该调用传入了匿名函数作为参数，一直跟进该函数会发现最终会执行匿名函数，也就是cleanOutdatedTables以及dumpDataForTables函数，主要看一下 dumpDataForTables 函数： ```c++ // ClickHouse/src/Databases/MySQL/MaterializeMySQLSyncThread.cpp static inline void dumpDataForTables(...) { ... //line293, 这里执行建表语句 tryToExecuteQuery(..., query_context, database_name, comment); } ``` 继续跟踪 tryToExecuteQuery 函数，会调用到 executeQueryImpl() 函数，上文提到过这个函数，但这次我们的上下文信息变了，生成的执行器发生变化，此时会进行 DDL 转化以及 dump table 等操作： ```c++ // ClickHouse/src/Interpreters/executeQuery.cpp static std::tuple executeQueryImpl(...) { ... // line 354，解析器可配置 ast = parseQuery(...); ... // line 503，这里跟之前上下文信息不同，生成interpreter也不同 auto interpreter = InterpreterFactory::get(ast,context, ...); ... // line 525, 执行器interpreter执行后返回结果 res = interpreter->execute(); ... } ``` 此时 InterpreterFactory 返回 InterpreterExternalDDLQuery，跟进去看 execute 函数做了什么： ```c++ // ClickHouse/src/Interpreters/InterpreterExternalDDLQuery.cpp BlockIO InterpreterExternalDDLQuery::execute() { ... if (external_ddl_query.from->name == "MySQL") { #ifdef USE_MYSQL ... // line61, 当全量复制执行DDL时，会执行到这里 else if (...->as()) return MySQLInterpreter::InterpreterMySQLCreateQuery( external_ddl_query.external_ddl, cogetIdentifierName(arguments[0]), getIdentifierName(arguments[1])).execute(); #endif } ... return BlockIO(); } ``` 继续跟进去发现 getIdentifierName(arguments[1])).execute() 会rewrite DDL： ```c++ // ClickHouse/src/Interpreters/MySQL/InterpretersMySQLDDLQuery.cpp ASTs InterpreterCreateImpl::getRewrittenQueries(...) { ... // 检查是否存在primary_key, 没有直接报错 if (primary_keys.empty()) throw Exception("cannot be materialized, no primary keys.", ...); ... // 添加 _sign 和 _version 列. auto sign_column_name = getUniqueColumnName(columns_name_and_type, "_sign"); auto version_column_name = getUniqueColumnName(columns_name_and_type, "_version"); // 这里悄悄把建表引擎修改成了ReplacingMergeTree storage->set(storage->engine, makeASTFunction("ReplacingMergeTree", ...)); ... return ASTs{rewritten_query}; } ``` 完成DDL转换之后就会去执行新的DDL语句，完成建表操作，再回到 dumpDataForTables： ```c++ // ClickHouse/src/Databases/MySQL/MaterializeMySQLSyncThread.cpp static inline void dumpDataForTables(...) { ... //line293, 这里执行建表语句 tryToExecuteQuery(..., query_context, database_name, comment); ... // line29, 这里开始 dump 数据并存放到MySQLBlockInputStream MySQLBlockInputStream input(connection, ...) } ``` - 增量同步 还记得startSynchronization() 绑定的执行函数吗？全量同步分析都是在 prepareSynchronized()进行的，那增量更新呢？ ```c++ // ClickHouse/src/Databases/MySQL/MaterializeMySQLSyncThread.cpp void MaterializeMySQLSyncThread::synchronization() { ... // 全量同步在 repareSynchronized() 进行 if (std::optional metadata = prepareSynchronized()) { while (!isCancelled()) { UInt64 max_flush_time = settings->max_flush_data_time; BinlogEventPtr binlog_event = client.readOneBinlogEvent(...); { //增量同步侦听binlog_envent if (binlog_event) onEvent(buffers, binlog_event, *metadata); } } } ... } ``` 可以看到，while 语句里有一个 binlog_event 的侦听函数，用来侦听 MySQL 端 BinLog 日志变化，一旦 MySQL 端执行相关操作，其 BinLog 日志会更新并触发 binlog_event，增量更新主要在这里进行。 ```c++ // ClickHouse/src/Databases/MySQL/MaterializeMySQLSyncThread.cpp void MaterializeMySQLSyncThread::onEvent(Buffers & buffers, const BinlogEventPtr & receive_event, MaterializeMetadata & metadata) { // 增量同步通过监听binlog event实现，目前支持四种event：MYSQL_WRITE_ROWS_EVENT、 // MYSQL_UPDATE_ROWS_EVENT、MYSQL_DELETE_ROWS_EVENT 和 MYSQL_QUERY_EVENT // 具体的流程可以查找对应的 onHandle 函数, 不在此详细分析 if (receive_event->type() == MYSQL_WRITE_ROWS_EVENT){...} else if (receive_event->type() == MYSQL_UPDATE_ROWS_EVENT){...} else if (receive_event->type() == MYSQL_DELETE_ROWS_EVENT){...} else if (receive_event->type() == MYSQL_QUERY_EVENT){...} else {/* MYSQL_UNHANDLED_EVENT*/} } ``` ### 小结 MaterializeMySQL 引擎是 ClickHouse 官方2020年主推的特性，由于该特性在生产环境中属于刚需且目前刚上线不久，整个模块处于高速迭代的状态，因此有许多待完善的功能。例如复制过程状态查看以及数据的一致性校验等。感兴趣的话可参考Github上的2021-Roadmap，里面会更新一些社区最近得计划。以上内容如有理解错误还请指正。 ### 引用 - ClickHouse社区文档 - ClickHouse社区源码 - MySQL实时复制与实现 - MaterializeMySQL引擎分析

       云、AI、5G等技术驱动，数据库行业迎来新的需求，云数据库也在不断演进升级。依托华为云与华为云Stack，通过全栈软硬件优化，华为云GaussDB进行了进阶与革新，以统一的架构，支持关系型与非关系型的数据库引擎。　　近日，在第十一届中国数据库技术大会上，笔者有幸采访到了华为云数据库产品总监张昆，张昆向我们详细解读了GaussDB如何做到架构革新，做到支持全场景全业务，并从解决方案与案例的维度分享了华为云数据库的优秀实践。华为云数据库产品总监 张昆 　　华为云GaussDB打造全场景数据库服务　　目前，华为云数据库产品覆盖开源和华为云GaussDB服务两大生态。开源生态服务主要在超越开源的前提下，为客户打造极致性价比的产品和服务；华为云GaussDB系列主要是面向金融政企客户打造的企业级商用数据库，满足客户对数据库高可靠、高性能的极致要求。　　华为云数据库产品总监张昆介绍了数据库服务的系列新品：　　华为云GaussDB适用于企业核心交易系统和海量事务型场景，支持集中式与分布式两种部署形态。华为云GaussDB(for MySQL)支持主备部署和分布式部署两种形式，提供优于原生MySQL7倍性能。　　面向企业新型应用的云原生多模GaussDB NoSQL系列服务提供3倍读写性能，自动弹性伸缩，具备企业级可靠性。GaussDB NoSQL基于GaussDB的计算存储分离架构创新，对于性能、成本、HA、扩容性、备份恢复等多种指标都有质的飞跃。　　华为云GaussDB(DWS)为各企业用户提供最佳性能、按需扩展、稳定可靠的全场景企业级数据仓库，满足客户超大规模数据的高性能查询分析诉求。值得一提的是，华为云GaussDB(DWS)数据仓库以单集群2048节点的超大规模，满分通过测试认证，是迄今为止信通院认证的最大规模分布式数据库集群，树立了业界新标杆。　　在谈到云数据库安全问题上，张昆表示，华为云数据库可提供密态数据库与防篡改数据库等技术新品，帮助客户构建安全可信、法律合规的应用全密态数据库业务全景，防止数据篡改与作弊，实现多方认同。　　据了解，目前，华为云数据库服务已在500+大客户中规模商用，遍布金融、政府、电信、能源、交通、物流、电商等行业。未来，华为云数据库将持续构建技术硬实力和优秀解决方案，使能行业数字化转型。　　华为云GaussDB让数据库迁移变得简单　　数据库迁移指的是从源库迁移到目标库。张昆把数据库迁移形象的比喻成从“旧家”搬到“新家”的过程，其中涉及到各种数据的搬迁，数量巨大，情况复杂，而且通常需要停机迁移，对业务影响极大，每个数据库迁移者都会经历客户如下亲切的问候。 　　迁移前：源库的运行状态如何，容量和复杂度如何，库表之间关系如何？如何选择合适的目标库及其规格，改造风险和工作量有多大？从源库迁移到目标库，有哪些对象不兼容，在目标库是否有替代方案？ 　　迁移中：如何保证结构迁移和数据迁移时，不影响源库/目标库正常运行的业务？源端按业务模块迁移时，源库和目标库如何进行持续的增量数据同步？源库对象较多，如何保障源库对象顺利迁移到目标库？ 　　迁移后：迁移完成时，如何保障迁移结果正确，包括结构的准确性与数据的准确性？迁移完成后，如何保障云上数据库的开发运维与性能的持续优化？……等等等等。 　　针对上述数据库迁移面临的众多问题，华为云推出了数据库迁移管理云化解决方案，帮助企业轻松上云，极简运维。那么，具体是如何帮助客户实现数据库迁移的呢？张昆从金融、消费者、泛互联网三大行业客户实践为我们带来了分享。 　　在金融行业，国有某大行核心业务已商用GaussDB，该银行把贵金属交易系统迁移上云，在这个业务场景下，通过数据库并行、渠道开关、应急回切、数据核对和监控等策略，采用灰度发布机制，按流量比例逐步切换，在保障生产稳定运行前提下验证整体迁移方案。 　　为客户带来了三大核心价值：（1）高可用。实现了同城单Region多AZ互联支持同城双活，金融级支持三层组网的管控高可用部署方案；（2）性能线性扩展。支持集群水平扩展，基本联机性能与0持平；（3）弹性部署。部署实例及应用要快速响应业务需求，数据库支持容器化部署。 　　在面向TO C的消费者领域，华为消费者业务为全球200多个国家和地区的6.7亿+用户、180万+开发者提供强大资源获取和弹性伸缩能力。张昆表示，“自己的狗粮自己吃”，因为只有自身实践过硬才能获得客户的信赖，目前，华为消费者业务数据库已全面切换上云，实现3AZ数据0丢失。 　　在泛互联网行业，张昆以游戏行业举例，开天创世在选择数据库过程中要求极高，快速部署和高性能低延时是其对数据库的基本要求。在游戏开服场景中，开天创世6小时内需要多次扩容，并且还要做到表级时间点恢复，支持游戏快速回档，扩容期间性能稳定，不影响游戏体验。 　　针对这个需求，客户采用了华为云多模GaussDB NoSQL系列服务，解决了玩家访问量突增的压力，实现了分钟级扩容和游戏快速回档。 　　写在最后，随着企业对云服务诉求的增加，越来越多的企业正在通过上“云”实现数字化升级。在Cloud 2.0时代，数据库是企业上云的一个重要竞争战场，未来，华为云数据库会以更开放的姿态，将积累多年的技术沉淀、运营经验分享出来，更好地满足各行业企业的多元化需求，为企业提供强有力的技术支持，让客户更专注于自身业务的创新与运营，加速企业数字变革。

123455

    今天的话题要从一个朋友的咨询开始    所以准备写一篇短文谈谈我对“存算分离”架构的理解，不一定全面，欢迎在评论区探讨。    其实这个朋友是误解了“存算分离”这个概念。他认为普通MySQL云数据库用evs做存储，计算资源和存储资源是分开的，比如可以单独扩容计算资源或单独扩容存储资源，所以就是存算分离的架构，其实这么理解是片面的。要理解“存算分离”架构，还得追根溯源，从传统MySQL主备架构说起。    这张图熟悉MySQL的人应该都见过，我们知道，MySQL的master端有数据变更时，备机是通过读取和回放binlog，涉及到三个线程，一个运行在主节点（log dump thread），其余两个(I/O thread, SQL thread)运行在备节点，三个线程配合完成数据复制的工作。但是，不难发现，这个架构在某些场景会有明显的缺陷：主库写入压力大时。当主库的写入压力比较大的时候，主备复制的时延会变大，因为需要回放完所有binlog的事务才会完全达到数据同步。增加只读节点时。增加备机/只读节点的速度很慢，因为我们需要将数据全量的复制到从节点，如果主节点此时存量的数据已经很多，那么扩展一个备机节点速度就会很慢高。使用多个只读节点时。存储的成本线性增长，如果数据库磁盘空间比较大，那么相应的所有只读节点挂载的磁盘空间都需要和主节点一样大，成本将会随着只读库数量增加进行线性增加。    这些问题通过存算分离架构就能得到很好的解决，以华为云GaussDB（for MySQL）为例，作为华为自研的最新一代高性能企业级分布式数据库，基于华为最新一代DFV分布式存储，采用计算存储分离架构，最高支持128TB的海量存储，可实现超百万级QPS吞吐。    首先，GaussDB（for MySQL）采用计算与存储解耦的技术架构，让所有的节点都共享一个存储，也就是说，增加计算节点时，无需调整存储资源，真正做到计算与存储分离，并且可支持 15 个只读节点的扩展，主节点和只读节点之间是 Active-Active 的 Failover 方式，计算节点资源得到充分利用，由于使用共享存储，降低了用户使用成本。完美契合了企业级数据库系统对高可用性、性能和扩展性、云服务托管的需求。GaussDB（for MySQL）将MySQL存储层变为独立的存储节点，在GaussDB（for MySQL）中认为日志即数据，将日志彻底从MySQL计算节点中抽离出来，都由存储节点进行保存，与传统 RDS for MySQL 相比，不再需要刷 page，所有更新操作都记录日志，不再需要 double write，从而大大减少了网络通信。    小结一下，以“存算分离”架构来答复一下上面的3个问题：    1. 当主库的写入压力比较大的时候，由于不再有double write入，主节点和只读节点之间的复制时延基本得以消除。    2. 增加只读节点的速度非常快，因为不再需要将数据全量的复制到只读节点，无论多大数据量，只需 5 分钟左右即可完成增加只读节点。    3. 使用多个只读节点时，因为只有一份存储，所以存储的成本不会有变化，存储空间越大，只读节点越多，节省成本越明显。

在日常工作中，很多数据一旦录入，轻易不会修改，但却常常会被调用。在对数据库有少量写请求，但有大量读请求的应用场景下，单个实例可能无法抵抗读取压力，甚至对主业务产生影响。遇到这种问题该怎么办？                                别担心，云数据库 GaussDB(for MySQL)只读节点帮您完美解决这个问题，让您轻松应对各种应用场景。为了实现读取能力的弹性扩展，分担数据库压力，您可以在某个区域中创建一个或多个只读节点，利用只读节点满足大量的数据库读取需求，以此增加应用的吞吐量。云数据库 GaussDB(for MySQL)是华为自研的最新一代企业级高扩展海量存储分布式数据库，完全兼容MySQL。基于华为最新一代DFV存储，采用计算存储分离架构，128TB的海量存储，无需分库分表，数据0丢失，既拥有商业数据库的高可用和性能，又具备开源低成本效益。创建只读节点：只读节点用于增强实例主节点的读能力，减轻主节点负载。一个实例中，最多支持15个只读节点。操作步骤：  登录管理控制台。单击管理控制台左上角的，选择区域和项目。选择“数据库 > 云数据库 GaussDB(for MySQL)”。进入云数据库GaussDB(for MySQL)信息页面。在“实例管理”页面，选择指定的实例，单击操作列的“更多 > 创建只读”，进入“创建只读”页面。您也可在实例的“基本信息”页面，单击拓扑图中的，创建只读节点。在“创建只读”页面，选择“故障倒换优先级”和“购买数量”，包周期单击“立即购买”，按需计费单击“立即创建”。只读节点升主节点GaussDB(for MySQL)是一个多节点的实例，其中一个节点是主节点（Master），其他节点为只读节点。除了因系统故障自动切换主备外，对于用于高可用演练，或者需指定某个节点为主节点的场景，您也可以手动切换主备，指定一个只读节点为新的主节点。手动切换：登录管理控制台。单击管理控制台左上角的，选择区域和项目。选择“数据库 > 云数据库 GaussDB(for MySQL)”。进入云数据库GaussDB(for MySQL)信息页面。在“实例管理”页面的实例列表中，选择对应实例，单击实例名称进入“基本信息”页面。在“基本信息”页面底部，选择目标只读节点，在“操作”列单击“只读升主”。在弹出框中单击“是”下发请求。a)   切换时可能会出现30秒左右的闪断，请确保应用具备重连机制。b)   切换过程中节点运行状态为“只读升主中”，此过程大概需要几秒或几分钟。c)   切换完成后，节点运行状态变为“正常”，您可查看到原先的只读节点和主节点的角色已经互换。自动切换：GaussDB(for MySQL)采用双活（Active-Active）的高可用实例架构，可读写的主节点和只读节点之间自动进行故障倒换（Failover），系统自动选取新的主节点。GaussDB(for MySQL)每个节点都有一个故障倒换优先级，决定了故障倒换时被选取为主节点的概率高低。故障倒换优先级的取值范围为1~16，数字越小，优先级越高，即故障倒换时，主节点会优先倒换到优先级高的只读节点上。当多个节点的优先级相同时，这些节点具有相同的概率被选取为主节点。GaussDB(for MySQL)按以下步骤自动选取主节点： 系统找出当前可以被选取的所有只读节点。 选择优先级最高的一个或多个只读节点。如果由于网络原因、复制状态异常等，第一个节点切换失败，则会尝试切换下一个，直至成功。删除只读节点对于“按需计费”模式的只读节点，您可根据业务需要，在GaussDB(for MySQL)数据库“基本信息”页面手动删除来释放资源。只读节点删除后，不可恢复，请谨慎操作。操作步骤：登录管理控制台。单击管理控制台左上角的，选择区域和项目。选择“数据库 > 云数据库 GaussDB(for MySQL)”。进入云数据库GaussDB(for MySQL)信息页面。在“实例管理”页面的实例列表中，选择对应实例，单击实例名称进入“基本信息”页面。在“基本信息”页面底部，选择目标只读节点，在“操作”列单击“删除”。为保证高可用，系统会保留一个正常只读节点不可被单独删除，只有删除实例时，才会被删除。在弹出框中单击“是”下发请求，稍后刷新“实例管理”页面，查看删除结果。赶紧戳这里，了解详情吧~~

https://support.huaweicloud.com/prtg-apache-kunpengbds/kunpenghbase_02_0001.html