IT瘾同步推荐

神同步OpenAI！中国团队Deep Principle领衔发布LLMs for Science评测，引爆外网

Fri, 16 Jan 2026 14:03:00 CST

作者丨论文团队

编辑丨ScienceAI

最近，一篇由中国团队领衔全球 24 所 TOP 高校机构发布，用于评测 LLMs for Science 能力高低的论文，在外网炸了！

当晚，Keras （最高效易用的深度学习框架之一）缔造者 François Chollet 转发论文链接，并喊出：「我们迫切需要新思路来推动人工智能走向科学创新。」

AI 领域 KOL Alex Prompter 分享论文核心摘要后，NBA 独行侠队老板 Mark Cuban 跟帖转发，硅谷投资人、欧洲家族办公室、体育媒体同时涌进评论区。

仅一夜，累计阅读量逼近 200 万。

值得一提的是，同一时间窗里，OpenAI 也发布了对于 AI 在科学发现领域能力评测的论文《FrontierScience: Evaluating Al's Ability to Perform Scientific Research Tasks》概述，指出现有评测标准在 AI for Science 领域失灵。

神同步 OpenAI、海外讨论出圈，究竟是什么样的一份工作成果，搅动了全球 AI 舆论场？

AI 距离可以助力科学发现还有多远？

前段时间，美国推出「创世纪计划」，号称要调动「自阿波罗计划以来最大规模的联邦科研资源」，目标是在十年内将美国科研的生产力和影响力翻倍。

但在人工智能估值泡沫隐现、能耗与产出比饱受质疑的当下，一面是资本的狂欢，另一面却是 AI 能力困于「文生图」等表层应用的尴尬；一面是各类大语言模型频繁霸榜 GPQA、MMMU 等题库式 Benchmark 的层出不穷，另一面却是现有 LLMs 还无法准确解析简单核磁图谱的尴尬现状。

人们不禁要问：能在题库拿高分，就能助力科学发现吗？现在的模型距离科学发现还有多远？究竟什么样的 AI 模型可以胜任，拓宽人类的生存边界？这些讨论，在中美 AI 竞争白热化的当下变得愈发浓烈。

在此背景下，由中国 AI for Science 领域的初创企业「深度原理 Deep Principle」领衔麻省理工学院、哈佛、普林斯顿、斯坦福、剑桥、牛津等全球 24 所科研院校共同发布的《Evaluating LLMs in Scientific Discovery》论文，正式回答该时代之问。

论文推出了 LLM for Science 首套评测体系 SDE（Scientific Discovery Evaluation），从科学问题到研究项目，对 GPT-5、Claude-4.5、DeepSeek-R1、Grok-4 等全球主流大语言模型在生物、化学、材料、物理领域的科学研究与发现能力完成摸底。

同以往评测体系不同的是，SDE 对模型能力的考量，从简单的问答式，引向了具体的「假设 -> 实验 -> 分析」实验场景。

研究发现，GPT-5、Claude-4.5、DeepSeek-R1、Grok-4 平均准确率 50–70%，远低于它们在 GPQA、MMMU 等题库上的 80–90%；在 86 道「SDE-Hard」难题中，最高分不足 12%，共同暴露出多步推理、不确定性量化和实验与理论闭环的短板。

更值得警惕的是，模型规模与推理能力的提升已呈现明显的「边际效益递减」。

GPT-5 相较于前一代模型，参数规模和推理算力显著增加，但在 SDE 基准的四大科学领域中，平均准确率仅提升 3%-5%，部分场景（如 NMR 结构解析）甚至出现性能下滑。

换句话说，当前大语言模型在推动科学发现方面的表现，还不如一个普通的本科生。

能领衔 24 所顶尖科研院校发布的背后团队是谁？

《Evaluating LLMs in Scientific Discovery》论文通讯作者段辰儒，是「深度原理 Deep Principle」创始人兼 CTO。早在 2021 年，在 MIT 攻读化学博士期间，他就已在图灵奖得主 Yoshua Bengio 的支持下，发起了 AI for Science 社区的建立，并在 NeurIPS 上举办 AI for Science workshop。

2024 年初，他与 MIT 物理化学博士贾皓钧回国，共同创立「深度原理 Deep Principle」。贾皓钧任 CEO，段辰儒任 CTO，两人虽为 95 后，但已在全球 AI for Science 创业领域小有名气。

创业一年半以来，其已获得线性资本、高瓴创投、蚂蚁集团等多家知名机构的投资，且与晶泰科技、深势科技等 AI for Science 领域的知名企业建立战略合作关系。

「深度原理 Deep Principle」从创立之初，就带着全球 AI for Science 头部研究者们的期待。目前「深度原理 Deep Principle」已深入全球材料研发中的第一线，将生成式人工智能同量子化学结合起来，致力于推动材料发现等领域进入新纪元。

在过去的一年中，他们在 Nature 大子刊和 JACS 等顶级期刊上不断扔出重磅成果，宣告着他们的技术领先和开放交流的「95 后创业公司」心态。从开拓扩散生成模型（Diffusion Models）在化学反应的生成，证明「不止要生成材料，更需要生成材料的合成路径」，到机器学习势（Machine Learning Potentials, MLPs）和扩散生成模型的直接对比，证明传统的机器学习势不是「万能」的，再到现在组织各大顶级学者和高校推出 SDE，证明传统一问一答的 Benchmark 不能带领我们走向科学超级智能，精准切入 AI for Science 领域的核心冲突。

但同时，对于所有的 AI4S 公司而言，在商业真金白银的检验中，AI 能否真正解决新产品研发问题、满足客户期待，是日复一日必须面对的拷问。

随着与行业头部客户的商业化合作落地，「深度原理 Deep Principle」的数据库中已经汇聚了来源于客户与自己实验室、大量来自第一线的真实工业研发场景数据和模型应用经验。

学术圈的深耕与在 AI for Science 商业化第一线的积累，让「深度原理 Deep Principle」在提出要构建一把新尺子评测 LLMs for Science 能力时，一呼百应，摇来了 23 家全球 TOP 科学发现机构的 50 余位科学家，成立了制定 SDE 的「梦之队」。

这其中，不乏活跃在 LLM 领域的大牛学者们，比如：

孙欢（Huan Sun），MMMU 发起人，俄亥俄州立教授
杜沅岂（Yuanqi Du），康奈尔博士，AI4Science 社区「运营大管家」
王梦迪，普林斯顿最年轻教授，AI+Bio Safety 先驱者
Philippe Schwaller，IBM RXN 之父，EPFL 教授

而「深度原理 Deep Principle」前期积累的科学发现场景，成为了后来 SDE 评测体系的前身。

在经历近 9 个月的跨高校跨学科跨时区的协作后，《Evaluating LLMs in Scientific Discovery》论文正式发布，通讯单位赫然写着：深度原理，杭州，中国。

自此，汇聚着全球顶级科学发现机构的集体智慧，来自中国的创业团队「深度原理 Deep Principle」，和大洋彼岸的 OpenAI，同时站在了向 AI for Science—— 这一人类通往终极 AGI 顶峰攀登的起跑线。

或许千百年后，当人类回望 AGI 时代，在 21 世纪的四分之一结束的当口，这场由中美团队共同呼应的，对于 AI for Science 的严肃讨论，把 LLMs 在各类问答式榜单上的内卷，向真正科学发现的星辰大海推近了一步。

至于怎么通往彼岸，段辰儒表示：「当大语言模型在各种科学问答榜单表现饱和，但还不能有效支持科学发现时，就像『考试成绩好』不等于『顶级研究者』，说明我们需要新的评测体系与训练路径。」

「深度原理 Deep Principle」与 20 多所机构的 50 多位合作者的研究证明了，目前 LLM 的发展路径并不能「顺便攻克」科学发现。

这条通往科学超级智能之路，需要更多有识之士共同并肩而行。

开源实时数据同步工具NiFi

Sat, 09 Nov 2024 21:04:10 CST

Apache NiFi简介

Apache NiFi 是一个强大的数据流管理和自动化工具，旨在简化数据的采集、传输、处理和分发。它特别适合于构建和管理复杂的数据流管道，支持从各种数据源到不同目标系统的数据传输。

Apache NiFi主要功能

Apache NiFi 是一个用于自动化数据流的强大工具，具有广泛的功能集，旨在支持从各种数据源到不同目标的复杂数据流管道。以下是 Apache NiFi 的主要功能：

数据采集与传输：
- 支持从多种数据源采集数据，包括文件系统、数据库、HTTP 服务、消息队列（如 Kafka）、传感器设备等。
- 支持将数据传输到多种目标系统，如 HDFS、数据库、云存储服务、REST API 等。
数据流可视化：
- 提供直观的 Web 用户界面，用户可以通过拖拽和配置处理器来设计和管理数据流。
- 实时显示数据流的状态和性能指标，便于监控和调试。
数据处理与转换：
- 提供丰富的内置处理器，支持数据的解析、转换、清洗、聚合和格式化等操作。
- 支持复杂的数据处理逻辑，如条件路由、数据分片、合并和拆分。
动态路由与优先级控制：
- 支持根据数据内容或属性动态路由数据到不同的处理器或目标。
- 允许为数据流设置优先级，以控制数据处理的顺序和速度。
实时流处理：
- 支持实时数据流处理，能够在数据到达时立即执行处理操作。
- 事件驱动架构，处理器在接收到数据或触发条件时自动执行。
分布式架构与扩展性：
- 支持多节点集群部署，可以水平扩展以处理大规模数据流。
- 集群中的节点通过 Apache ZooKeeper 进行协调和管理。
数据安全与合规：
- 支持数据加密、访问控制和用户身份验证，确保数据的安全性。
- 提供数据审计功能，记录数据流的处理历史和用户操作。
错误处理与重试机制：
- 自动处理数据传输和处理过程中出现的错误，支持重试和故障转移。
- 提供数据回退和恢复功能，确保数据的可靠性和完整性。
可扩展性与集成性：
- 支持自定义处理器和控制器服务的开发，用户可以根据需要扩展 NiFi 的功能。
- 与其他大数据工具和框架（如 Apache Kafka、Hadoop、Spark）紧密集成，支持复杂的数据处理和分析工作流。
监控与管理：
- 提供详细的日志记录和监控功能，帮助用户了解数据流的执行状态和性能指标。
- 支持告警和通知机制，用户可以根据特定条件设置告警，及时响应异常情况。

Apache NiFi 的设计目标是提供一个灵活、高效且易于管理的数据流管理平台，适用于各种数据集成和处理场景。其丰富的功能集使其成为企业数据管道构建和管理的理想选择。

Apache NiFi的优势

灵活性：通过丰富的处理器和自定义开发能力，NiFi 可以适应各种复杂的数据处理需求。
可扩展性：支持多节点集群部署，可以水平扩展以处理大规模数据流。
可视化管理：提供直观的 Web UI，用户可以轻松设计和管理数据流，无需编写复杂的代码。
高可用性：通过故障转移和数据重试机制，确保数据流的高可用性和可靠性。
安全性：支持数据加密、访问控制和审计，确保数据的安全性和隐私保护。

Apache NiFi的架构

Apache NiFi 的架构设计旨在提供一个灵活、高效且可扩展的数据流管理平台。它采用模块化设计，支持分布式部署，能够处理各种规模和复杂度的数据流任务。

核心组件

Web UI（用户界面）：NiFi 提供了一个直观的 Web 用户界面，用于设计、监控和管理数据流。用户可以通过拖拽和配置组件来构建数据流，并实时查看数据流的状态和性能指标。
FlowFile：FlowFile 是 NiFi 中的数据单元，包含数据内容和属性。每个 FlowFile 都有唯一标识符和元数据，支持数据的高效传输和处理。
处理器（Processor）：处理器是执行特定数据处理任务的基本单元。NiFi 提供了丰富的内置处理器，用于数据采集、转换、路由和传输。用户还可以开发自定义处理器以满足特定需求。
连接（Connection）：连接用于在处理器之间传递 FlowFile。连接可以配置为使用不同的队列策略，以控制数据的流动速度和优先级。
流程组（Process Group）：流程组用于组织和管理多个处理器和连接，形成逻辑上的子流程。这有助于复杂数据流的模块化设计和维护。
控制器服务（Controller Service）：控制器服务提供共享的配置和服务，例如数据库连接池、分布式缓存等。它们可以在多个处理器之间复用，提高资源利用率。
报告任务（Reporting Task）：报告任务用于生成和发送 NiFi 系统的运行状态和指标数据，通常用于监控和告警系统。

工作流和数据流

数据采集与处理：
- 数据流从输入处理器开始，输入处理器从外部数据源（如文件系统、HTTP、Kafka）获取数据并生成 FlowFile。
- 中间处理器对 FlowFile 进行处理，包括数据解析、转换、过滤和聚合等操作。
数据路由与分发：
- 根据业务规则和条件，NiFi 可以将 FlowFile 路由到不同的处理器或流程组。
- 输出处理器将处理后的 FlowFile 发送到目标系统（如 HDFS、数据库、云存储）。
实时监控与管理：
- Web UI 提供实时数据流监控功能，用户可以查看处理器的性能指标、队列长度、处理速率等。
- 用户可以动态调整数据流的配置和参数，以优化性能和处理逻辑。

分布式架构

多节点集群：
- NiFi 支持多节点集群部署，可以通过增加节点来扩展处理能力。集群中的每个节点都可以执行数据流任务。
- 集群节点通过 Apache ZooKeeper 进行协调和管理，以确保任务的负载均衡和高可用性。
高可用性与故障转移：
- NiFi 采用主从架构，集群中一个节点为主节点（Primary Node），负责调度任务和管理集群配置。
- 在主节点故障时，集群会自动选举新的主节点，确保数据流的持续性和可靠性。

安全性

用户认证与授权：
- 支持多种认证机制（如 LDAP、Kerberos），确保只有授权用户才能访问和管理 NiFi 系统。
- 提供细粒度的权限控制，用户可以对不同的数据流组件和操作进行授权。
数据加密：
- 支持数据传输加密和存储加密，确保数据在传输和存储过程中的安全性。
审计与日志：
- 提供详细的审计日志记录，记录用户操作和数据流处理历史，便于合规性检查和故障排查。

Apache NiFi 的架构设计使其成为一个灵活、可扩展和安全的数据流管理平台，适用于各种规模和复杂度的数据集成和处理任务。其模块化设计和丰富的功能集使得用户能够高效地构建和管理复杂的数据流管道。

Airflow、Kafka的对比

Apache NiFi、Apache Airflow 和 Apache Kafka 都是现代数据处理和管理生态系统中的重要工具，但它们各自的设计目的和应用场景有所不同。以下是它们的详细对比：

特性	Apache NiFi	Apache Airflow	Apache Kafka
主要用途	实时数据流管理和自动化	工作流调度和管理	消息队列和流处理
架构特点	可视化界面，事件驱动架构	编程接口定义工作流（DAGs），基于调度器和执行器	发布/订阅模型，分布式架构
数据处理	实时数据采集、转换和路由	批处理任务调度，不直接处理数据流	高吞吐量的消息传输，支持实时流处理
扩展性与部署	多节点集群，水平扩展	分布式调度和执行，支持多种执行器	水平扩展，通过分区和副本实现容错
安全性	细粒度权限控制和数据加密	用户认证和授权（RBAC）	SSL 加密、SASL 认证和 ACL 授权
应用场景	实时数据集成、物联网数据采集、日志管理和监控	定时数据处理任务、复杂的 ETL 管道、机器学习工作流	实时数据传输、日志收集和分析、事件驱动架构

对比总结

实时 vs 批处理：
- NiFi：适合实时数据流处理和自动化。
- Airflow：适合批处理任务调度和复杂的工作流管理。
- Kafka：适合高吞吐量的消息传输和实时流处理。
用户界面 vs 编程接口：
- NiFi：提供可视化界面，适合需要快速构建和管理数据流的场景。
- Airflow：提供编程接口，适合需要灵活定义复杂工作流的场景。
- Kafka：主要通过编程接口和命令行工具进行管理和配置。
数据流管理 vs 工作流调度 vs 消息队列：
- NiFi：专注于数据流的管理和处理。
- Airflow：专注于任务调度和工作流管理。
- Kafka：专注于消息队列和流处理。

根据具体的需求和场景，企业可以选择合适的工具或组合使用这些工具来构建复杂的数据处理和管理生态系统。例如，可以使用 NiFi 进行数据采集和预处理，使用 Kafka 进行高吞吐量的消息传输，使用 Airflow 进行批处理任务的调度和管理。

✨基于Spring-Data-Elasticsearch 优雅的实现多字段搜索 + 高亮 + 分页 + 数据同步✨

Sun, 16 Oct 2022 15:13:47 CST

theme: devui-blue highlight: a11y-dark

持续创作，加速成长！这是我参与「掘金日新计划 · 10 月更文挑战」的第17天，点击查看活动详情

系列说明

本系列文章基于我的开源微服务项目【校园博客】进行分析和讲解，所有源码均可在GitHub仓库上找到。系列文章地址请见我的校园博客专栏。

GitHub地址： https://github.com/stick-i/scblogs

目前项目还有很大改进和完善的空间，欢迎各位有意愿的同学参与项目贡献（尤其前端），一起学习一起进步。

项目的技术栈主要是：
后端 Java + SpringBoot + SpringCloud + Nacos + Getaway + Fegin + MybatisPlus + MySQL + Redis + ES + RabbitMQ + Minio + 七牛云OSS + Jenkins + Docker
前端 Vue + ElementUI + Axios（说实话前端我不太清楚）

前言

本篇文章主要是一些对Spring-Data-Elasticsearch使用上的记录和讲解，对原理和基础知识并没有介绍，适合有一定ES基础的朋友阅读。

为了给项目添加一个好的搜索功能，我去学习了一下elasticsearch。

在学习elasticsearch-client的期间，发现它提供的api不太优雅，用起来也不太舒服，而且我觉得有些操作完全是可以封装在内部的，比如获取数据后，对数据转化为bean的操作；还有属性高亮，不仅设置比较麻烦，而且设置完成的高亮居然是单独在一个字段里的，需要开发者去手动的替换才行，这些操作我觉得其实都可以封装在内部的，害，个人感慨，请勿介意。

然后我就去看了一下spring-data里面提供的 es 操作库，发现有很多操作都封装的比较完善，使用起来也比较优雅，于是我便使用spring-data-elasticsearch完成了这个功能，查阅了很多资料、博客、官方文档，有些地方我觉得官方文档讲的也不够详细，导致走了很多弯路，也可能是我没有找到详细的文档。

为了方便大家学习和少走弯路，也便于本人日后回顾，故记录于此。

本篇文章讲的内容是在项目的 /blog-service/blog-content-server 路径下，感兴趣的同学欢迎随时查看，觉得不错的话也欢迎点点star噢。

技术要点

使用 copyTo 和 ElasticsearchRepository 完成的多字段搜索。
使用注解 @Highlight 和 @HighlightField 完成的高亮显示。
使用 Pageable 和 SearchPage 实现分页和高亮两不误的接口。
使用 RabbitMQ 完成 MySQL 和 elasticsearch 的数据同步。

依赖项

我当前的环境：

springboot 2.6.6
elasticsearch 7.12
kibana 7.12（这个不是必须的）
然后当前版本的spring默认是用的 7.15.2 的我担心和我的es不兼容，就加了个标签给它改了一下版本：
```
    <elasticsearch.version>7.12.1</elasticsearch.version>
```

核心依赖其实就这一个，这里面已经依赖了elasticsearch需要的一些依赖，例如 elasticsearch-rest-high=level-client。

  <dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-data-elasticsearch</artifactId>
</dependency>

然后如果跟我一样使用 RabbitMQ 做数据同步的话，还需要引用mq的依赖：

  <!--AMQP依赖，包含RabbitMQ-->
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-amqp</artifactId>
</dependency>
<!-- json序列化依赖，需要手动配置bean -->
<dependency>
<groupId>com.fasterxml.jackson.core</groupId>
<artifactId>jackson-databind</artifactId>
</dependency>

配置文件

这里需要配置elasticsearch的账号密码

  spring:
  elasticsearch:
    uris: "http://localhost:9200"
    username: 12345
    password: 12345

核心代码

实体类BlogDoc

下面是我代码当中跟 es 进行交互的实体类，代码上有相关的注释，我将一些多余的、意义不大的属性删掉了，方便大家查看。

  package cn.sticki.blog.content.pojo;

import com.fasterxml.jackson.annotation.JsonIgnore;
import lombok.Data;
import org.springframework.data.annotation.Id;
import org.springframework.data.elasticsearch.annotations.Document;
import org.springframework.data.elasticsearch.annotations.Field;
import org.springframework.data.elasticsearch.annotations.FieldType;

import java.util.Date;

/**
 * Blog ES文档类型
 *
 * @author 阿杆
 * @version 1.0
 * @date 2022/7/8 15:24
 */
@Data
@Document(indexName = "blog")
public class BlogDoc {

/**
 * 博客id
 */
@Id
Integer id;

/**
 * 封面图链接
 */
@Field(type = FieldType.Keyword, index = false)
String coverImage;

/**
 * 标题
 */
@Field(type = FieldType.Text, analyzer = "ik_max_word", copyTo = "descriptiveContent")
String title;

/**
 * 描述
 */
@Field(type = FieldType.Text, analyzer = "ik_max_word", copyTo = "descriptiveContent")
String description;

/**
 * 创建时间
 */
@Field(type = FieldType.Date, pattern = "uuuu-MM-dd HH:mm:ss")
Date createTime;

/**
 * 发表状态（1表示已发表、2表示未发表、3为仅自己可见、4为回收站、5为审核中）
 */
@Field(type = FieldType.Integer)
Integer status;

/**
 * 由其他属性copy而来，主要用于搜索功能，不需要储存数据
 */
@JsonIgnore
@Field(type = FieldType.Text, analyzer = "ik_max_word", ignoreFields = "descriptiveContent", excludeFromSource = true)
String descriptiveContent;

}

注解说明：

@Document(indexName = "blog")：声明该实体类对应es中的哪个 索引库。
@Id：声明该字段对应索引库当中的id。
@JsonIgnore：这个应该很熟悉吧，就是 在json序列化时将对象中的一些属性忽略掉，使返回的json数据不包含该属性。
@Field(...) ，这些其实都 对应es的api调用时传入的字段，有一点es基础会很容易看懂，也可以看看我写的elasticsearch专栏下的其他文章，前几篇是我学基础的时候记录的。
- type = FieldType.Integer ：声明字段属性，如果不写，默认为auto，就是es会帮你自动匹配成最合适的字段类型，建议还是写一下。
- index = false ：声明该字段不需要建立索引，一般用于不会被拿来搜索、排序、统计的字段，比如我这里写的封面图链接。
- analyzer = "ik_max_word" ：声明该text字段需要使用的分词器，我这里是用的ik分词器，需要开发者去手动安装，但对中文分词比较友好。
- excludeFromSource = true：翻译出来意思是“从源中排除”，应该是指这个字段的属性不会插入到es索引库当中吧，这个字段是我用来``copy_to`的，主要是搜索的时候使用，本身并不会直接存入数据，所以这个字段如果有数据，我希望插入的时候把它忽略。
- copyTo = "descriptiveContent"：这个就是跟es的copy_to一样，就是说把当前属性拷贝到“descriptiveContent”当中，可以拷贝多个属性到同一个字段中，便于搜索、查询。
- pattern = "uuuu-MM-dd HH:mm:ss" ：声明该自定义的格式字符串，一般在type = FieldType.Date时使用。
- format：跟pattern差不多，官方解释是用于定义至少一种预定义格式。如果未定义，则使用默认值*_date_optional_time 和epoch_millis*。也就是只能使用给定的枚举值，不能自定义，自定义的话得用pattern。下图是谷歌翻译的官方解释：

实体类属性copy_to

大家都知道，在es当中如果有多个字段需要被同时查询（比如我的博客业务，要搜索内容的时候，我会把用户输入的关键字同时拿来匹配标题和文章描述），那可以用 multi_match、 query_string进行多字段查询，也可以用 copy_to将多个字段复制到一个新属性上再去查新属性，这几种方法都是可以的，但是copy_to它的性能会高一些，尤其是在同时要查的属性非常多的时候，这属于是一种储存换取速度的方式。

copy_to的属性在上面已经讲过了，跟es的api用来起来差不多的，但是我上面的代码还写了一个 descriptiveContent：

  /**
 * 由其他属性copy而来，主要用于搜索功能，不需要储存数据
 */
@JsonIgnore
@Field(type = FieldType.Text, analyzer = "ik_max_word", ignoreFields = "descriptiveContent", excludeFromSource = true)
String descriptiveContent;

这个属性就是被cope_to到的那个属性，但实际上我们在写代码的时候并不会给它赋值或者取值或者别的怎么样，总是就是希望他尽可能透明，仅在对es时有效，因为es里是已经提前定义好这个索引库了的，es创建索引库的代码我会贴在文章最后。

这是因为，后面我们要使用 ElasticsearchRepository的时候，被查询的字段如果不存在于这个实体类，idea会有一个很碍眼的提示， ~~作为强迫症患者~~，这就引发了我的思考，是不是我们在定义实体类的时候，要和定义索引库的时候一样给出全部的字段呢？尽管这个字段只是一个“隐身”的字段。 ~~为了把这个碍眼的提示去掉~~ 为了让代码变得更可读一点，所以我加上了这个字段，并加了一些忽略的属性使它尽可能隐身。

Mapper层（Repository）

核心代码如下，具体解释和分析在下面：

  package cn.sticki.blog.content.mapper;

import cn.sticki.blog.content.pojo.BlogDoc;
import org.springframework.data.domain.Pageable;
import org.springframework.data.elasticsearch.annotations.Highlight;
import org.springframework.data.elasticsearch.annotations.HighlightField;
import org.springframework.data.elasticsearch.annotations.HighlightParameters;
import org.springframework.data.elasticsearch.core.SearchPage;
import org.springframework.data.elasticsearch.repository.ElasticsearchRepository;

/**
 * BlogRepository操作类
 * 提供save、findById、findAll、count、delete、exists等接口
 *
 * @author 阿杆
 * @version 1.0
 * @date 2022/7/9 10:53
 */
public interface BlogRepository extends ElasticsearchRepository<BlogDoc, Long> {

/**
 * 通过描述内容来搜索博客
 *
 * @param descriptiveContent 描述语句
 * @param pageable           分页
 * @return 博客列表
 */
@SuppressWarnings("SpringDataRepositoryMethodReturnTypeInspection")
@Highlight(fields = {
@HighlightField(name = "title", parameters = @HighlightParameters(requireFieldMatch = false)),
@HighlightField(name = "description", parameters = @HighlightParameters(requireFieldMatch = false)),
})
SearchPage<BlogDoc> findByDescriptiveContent(String descriptiveContent, Pageable pageable);

}

继承ElasticsearchRepository

这个其实就有点像继承 BaseMapper，它会给你提供一些基础的CRUD方法，方便你直接使用，比如save、delete、find之类的。
它是个泛型类，两个参数分别是 <实体类，id的类型>。
在该接口下（BlogRepository）按照特殊的命名规则声明的方法，可以直接调用，不需要开发者实现接口，且它返回的内容是已经封装好的， 你需要的数据会被封装在你提供的实体类里面（不用手动解析数据）。

大概就是 findByXxxAndXxxOrXxx() 这个类型，具体的可以参考官网： https://docs.spring.io/spring-data/elasticsearch/docs/4.3.5/reference/html/#elasticsearch.query-methods.criterions，这里也截一点给大家看看（谷歌浏览器翻译的）：
也可以使用 @Query 注解写原生的 api 请求接口，不太优雅，个人不推荐使用。

然后这里我只添加了一个方法：

  SearchPage<BlogDoc> findByDescriptiveContent(String descriptiveContent, Pageable pageable);

这个意思就是所通过 DescriptiveContent 属性来查询数据，后面的两个参数一个是搜索的内容，一个是分页的参数（分页需要配合支持分页的返回值才行）。

这个findByXxx的Xxx属性必须是实体类里面存在的属性才可以，不然会提示错误：

高亮显示

  @SuppressWarnings("SpringDataRepositoryMethodReturnTypeInspection")
@Highlight(fields = {
@HighlightField(name = "title", parameters = @HighlightParameters(requireFieldMatch = false)),
@HighlightField(name = "description", parameters = @HighlightParameters(requireFieldMatch = false)),
})

使用注解 @Highlight 和 @HighlightField，来设置高亮的字段，使用 @HighlightParameters 来添加高亮的参数。

我这里设置了requireFieldMatch = false，这个参数是 取消只有字段匹配才给高亮的规则，这是因为我搜索的字段是由另外两个字符copyTo而来的，高亮的内容肯定是在另外两个字段里面，设置该参数可以让其他字段的高亮也展示出来。

这里还有一篇高亮显示的教程文章，我讲的比较粗糙，他这个写的比较详细，贴给大家学习： https://blog.csdn.net/qq_45794678/article/details/111188548

官方文档给的说明就这么点。。。 ~~怕我学会了然后教别人吗~~。。。

分页功能

通过 Pageable 做参数和 SearchPage 做返回值来完成了对分页的需求，传参的时候使用 PageRequest.of(page, size) 来创建分页参数即可。

得到结果后仅需将分页的内容替换掉实体类的内容即可，并且数据里面包含有获取页码的信息的接口：

Service层

核心代码如下：

  @Service
public class BlogContentServiceImpl implements BlogContentService {

@Resource
private BlogRepository blogRepository;

/**
 * 搜索博客
 *
 * @param key 搜索内容
 * @param page 页码
 * @param size 页大小
 * @return 搜索到的结果列表
 */
@Override
public List<BlogDoc> searchBlog(String key, int page, int size) {
// 1. 获取数据
SearchPage<BlogDoc> searchPage = blogRepository.findByDescriptiveContent(
// 1.1 设置key和分页，这里是从第0页开始的，所以要-1
key,PageRequest.of(page - 1, size));
// 2. 高亮数据替换
List<SearchHit<BlogDoc>> searchHitList = searchPage.getContent();
ArrayList<BlogDoc> blogDocList = new ArrayList<>(searchHitList.size());
for (SearchHit<BlogDoc> blogHit : searchHitList) {
// 2.1 获取博客数据
BlogDoc blogDoc = blogHit.getContent();
// 2.2 获取高亮数据
Map<String, List<String>> fields = blogHit.getHighlightFields();
if (fields.size() > 0) {
// 2.3 通过反射，将高亮数据替换到原来的博客数据中
BeanMap beanMap = BeanMap.create(blogDoc);
for (String name : fields.keySet()) {
beanMap.put(name, fields.get(name).get(0));
}
}
// 2.4 博客数据插入列表
blogDocList.add(blogDoc);
}
return blogDocList;
}

}

替换高亮数据

到这里其实就只要做一件事了，因为Repository返回的数据已经帮你封装好实体类了，不需要再去json转bean了，它唯一的缺点就是，高亮数据还是得自己去做替换，所以我上面这些代码也就是做了这一件事，就是把高亮的数据替换掉原来的数据。

这里我用到了 BeanMap，代码里不用写死属性名称，相对来说更优雅一点，如果有需要的话，也可以把中间这一段分离成一个单独的方法，可以提供给不同的类使用。

数据同步

数据同步指的是 elasticsearch 和 MySQL 的数据同步，由于我的项目做的是微服务架构，我的 博客服务和 博客内容服务是两个微服务（本文讲的是博客内容服务），博客服务提供文章的 增删改查功能，并连接MySQL，博客内容服务提供 搜索功能，并连接ES，故两者的数据需要同步。

这里我使用的是RabbitMQ，主要逻辑如下：

用户新建修改或删除博客时，博客服务发送消息到MQ中，发到自己的交换机里，并指定key。
内容服务提前创建队列并绑定到博客服务的交换机中。
当内容服务接收到消息时，做出对应的操作。

核心代码如下：

  /**
 * 内容服务对博客服务的消息队列监听器
 *
 * @author 阿杆
 * @version 1.0
 * @date 2022/7/10 9:32
 */
@Slf4j
@Component
public class BlogServerListener {

@Resource
private BlogRepository blogRepository;

@RabbitListener(bindings = @QueueBinding(
exchange = @Exchange(name = BLOG_EXCHANGE),
value = @Queue(name = BLOG_SAVE_QUEUE),
key = {BLOG_INSERT_KEY, BLOG_UPDATE_KEY}
))
public void saveListener(BlogDoc blogDoc) {
log.debug("save blogDoc，{}", blogDoc);
blogRepository.save(blogDoc);
}

@RabbitListener(bindings = @QueueBinding(
exchange = @Exchange(name = BLOG_EXCHANGE),
value = @Queue(name = BLOG_DELETE_QUEUE),
key = BLOG_DELETE_KEY
))
public void deleteListener(Long blogId) {
log.debug("delete blog ,id->{}", blogId);
blogRepository.deleteById(blogId);
}

}

其实可以看出，通过Repository来实现这些操作都是很简单的。

需要注意的是，这里的save操作，是 ES的全量更新，所以发送过来的数据，一定要是完整的数据，否则会导致部分字段丢失。

然后发送消息的大概就是代码是：

  rabbitTemplate.convertAndSend(BLOG_EXCHANGE, BLOG_UPDATE_KEY, blog);

MQ序列化配置

这里RabbitMQ的序列化配置我也贴一下，这个可以让MQ消息变成json格式的。

  package cn.sticki.common.amqp.autoconfig;

import org.springframework.amqp.support.converter.Jackson2JsonMessageConverter;
import org.springframework.amqp.support.converter.MessageConverter;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

/**
 * @author 阿杆
 * @version 1.0
 * @date 2022/6/25 18:01
 */
@Configuration
public class AmqpMessageConverterConfig {

@Bean
public MessageConverter messageConverter() {
return new Jackson2JsonMessageConverter();
}

}

后记

本篇文章主要使用了 ElasticsearchRepository 和相关注解来完成了一些常有的需求，比较优雅（个人认为）的实现了查询分页和高亮的功能（网上找到的教程都没有把分页和高亮一起适配的）。但如果有更为复杂的需求，可能还是需要使用 ElasticsearchRestTemplate来完成。官网： https://docs.spring.io/spring-data/elasticsearch/docs/4.3.5/reference/html/#elasticsearch.operations.resttemplate

超级好用的免费开源文件同步工具：Syncthing

Mon, 27 Dec 2021 10:09:20 CST

相信不少小伙伴跟TJ君有一样的经历，当然相信也会有小伙伴是因为更换设备导致的文件丢失，不管怎么说，临时用用还行，平时大家还是不要把重要的文件直接存储在微信上，还是该备份的备份，该传输到本地的传输。存到网盘？你确定不开通个VIP那上传下载速度能用？

那么今天的问题就来了，平时大家都用什么文件传输工具呢？

今天TJ君要和大家分享的就是一款免费、开源的文件同步工具， Syncthing

作为一款P2P性质的文件同步工具，Syncthing在Github上广受欢迎，已经收获了42k的Star！

Syncthing有五大特点：

1、避免数据丢失
2、安全防范攻击者
3、便捷使用
4、自动化运行
5、高兼容性

像Windwos、macOS、Android、Linux这些主流平台都支持Syncthing，所以Syncthing可以跨平台的进行文件传输。

目前最新的版本是v1.18.5版本，在18天前更新，说明作者也一直在优化迭代。

以windows为例，只需要安装好Syncthing电脑端的应用程序，打开浏览器访问 http://127.0.0.1:8384/ 就可以进入 Syncthing传输平台。

如果在其他设备，例如手机端也安装完Syncthing，便会有同步提示，通过后就可以进行文件传输了。速度很快哦！

不知道大家有没有从TJ的图中发现，虽然Syncthing的开源项目都是英文描述，但是其使用界面却是中文的，算不算也是给我们大天朝的一个小小的福利呢？想试试这款工具传输文件进行备份的小伙伴们，赶紧来试试吧！

扫描下方二维码，关注公众号“TJ君”，回复“Syncthing”，获取仓库地址！

数据同步工具之FlinkCDC/Canal/Debezium对比-技术圈

Sun, 31 Oct 2021 12:10:29 CST

前言

数据准实时复制（CDC）是目前行内实时数据需求大量使用的技术，随着国产化的需求，我们也逐步考虑基于开源产品进行准实时数据同步工具的相关开发，逐步实现对商业产品的替代。本文把市面上常见的几种开源产品，Canal、Debezium、Flink CDC 从原理和适用做了对比，供大家参考。

本文首发微信公众号《import_bigdata》

Debezium

Debezium is an open source distributed platform for change data capture. Start it up, point it at your databases, and your apps can start responding to all of the inserts, updates, and deletes that other apps commit to your databases. Debezium is durable and fast, so your apps can respond quickly and never miss an event, even when things go wrong.

Debezium是一种CDC（Change Data Capture）工具，工作原理类似大家所熟知的Canal, DataBus, Maxwell等，是通过抽取数据库日志来获取变更。

Debezium最初设计成一个Kafka Connect 的Source Plugin，目前开发者虽致力于将其与Kafka Connect解耦，但当前的代码实现还未变动。下图引自Debeizum官方文档，可以看到一个Debezium在一个完整CDC系统中的位置。

Kafka Connect 为Source Plugin提供了一系列的编程接口，最主要的就是要实现SourceTask的poll方法，其返回 List<SourceRecord>将会被以最少一次语义的方式投递至Kafka。

Debezium MySQL 架构

Debezium抽取原理

Reader体系构成了MySQL模块中代码的主线，我们的分析从Reader开始。

Reader继承关系

从名字上应该可以看出，真正主要的是SnapshotReader和BinlogReader，分别实现了对MySQL数据的全量读取和增量读取，他们继承于AbstractReader，里面封装了共用逻辑，下图是AbstractReader的内部设计。

可以看到，AbstractReader在实现时，并没有直接将enqueue喂进来的record投递进Kafka，而是通过一个内存阻塞队列BlockingQueue进行了解耦，这种设计有诸多好处：

职责解耦

如上的图中，在喂入BlockingQueue之前，要根据条件判断是否接受该record；在向Kafka投递record之前，判断task的running状态。这样把同类的功能限定在特定的位置。

线程隔离

BlockingQueue是一个线程安全的阻塞队列，通过BlockingQueue实现的生产者消费者模型，是可以跑在不同的线程里的，这样避免局部的阻塞带来的整体的干扰。如上图中的右侧，消费者会定期判断running标志位，若running被stop信号置为了false，可以立刻停止整个task,而不会因MySQL IO阻塞延迟相应。

Single与Batch的互相转化

Enqueue record是单条的投递record，drain_to是批量的消费records。这个用法也可以反过来，实现batch到single的转化。

可能你还知道阿里开源的另一个MySQL CDC工具canal，他只负责stream过程，并没有处理snapshot过程，这也是debezium相较于canal的一个优势。

对于Debezium来说，基本沿用了官方搭建从库的这一思路，让我们看下官方文档描述的详细步骤。

MySQL连接器每次获取快照的时候会执行以下的步骤：

获取一个全局读锁，从而阻塞住其他数据库客户端的写操作。
开启一个可重复读语义的事务，来保证后续的在同一个事务内读操作都是在一个一致性快照中完成的。
读取binlog的当前位置。
读取连接器中配置的数据库和表的模式（schema）信息。
释放全局读锁，允许其他的数据库客户端对数据库进行写操作。
（可选）把DDL改变事件写入模式改变topic（schema change topic），包括所有的必要的DROP和CREATEDDL语句。
扫描所有数据库的表，并且为每一个表产生一个和特定表相关的kafka topic创建事件（即为每一个表创建一个kafka topic）。
提交事务。
记录连接器成功完成快照任务时的连接器偏移量。

部署

基于 Kafka Connect

最常见的架构是通过 Apache Kafka Connect 部署 Debezium。Kafka Connect 为在 Kafka 和外部存储系统之间系统数据提供了一种可靠且可伸缩性的方式。它为 Connector 插件提供了一组 API 和一个运行时：Connect 负责运行这些插件，它们则负责移动数据。通过 Kafka Connect 可以快速实现 Source Connector 和 Sink Connector 进行交互构造一个低延迟的数据 Pipeline：

Source Connector（例如，Debezium）：将记录发送到 Kafka
Sink Connector：将 Kafka Topic 中的记录发送到其他系统

如上图所示，部署了 MySQL 和 PostgresSQL 的 Debezium Connector 以捕获这两种类型数据库的变更。每个 Debezium Connector 都会与其源数据库建立连接：

MySQL Connector 使用客户端库来访问 binlog。
PostgreSQL Connector 从逻辑副本流中读取数据。

除了 Kafka Broker 之外，Kafka Connect 也作为一个单独的服务运行。默认情况下，数据库表的变更会写入名称与表名称对应的 Kafka Topic 中。如果需要，您可以通过配置 Debezium 的 Topic 路由转换来调整目标 Topic 名称。例如，您可以：

将记录路由到名称与表名不同的 Topic 中
将多个表的变更事件记录流式传输到一个 Topic 中

变更事件记录在 Apache Kafka 中后，Kafka Connect 生态系统中的不同 Sink Connector 可以将记录流式传输到其他系统、数据库，例如 Elasticsearch、数据仓库、分析系统或者缓存（例如 Infinispan）。

Debezium Server

另一种部署 Debezium 的方法是使用 Debezium Server。Debezium Server 是一个可配置的、随时可用的应用程序，可以将变更事件从源数据库流式传输到各种消息中间件上。

下图展示了基于 Debezium Server 的变更数据捕获 Pipeline 架构：

Debezium Server 配置使用 Debezium Source Connector 来捕获源数据库中的变更。变更事件可以序列化为不同的格式，例如 JSON 或 Apache Avro，然后发送到各种消息中间件，例如 Amazon Kinesis、Google Cloud Pub/Sub 或 Apache Pulsar。

嵌入式引擎

使用 Debezium Connector 的另一种方法是嵌入式引擎。在这种情况下，Debezium 不会通过 Kafka Connect 运行，而是作为嵌入到您自定义 Java 应用程序中的库运行。这对于在您的应用程序本身内获取变更事件非常有帮助，无需部署完整的 Kafka 和 Kafka Connect 集群，也不用将变更流式传输到 Amazon Kinesis 等消息中间件上。

特性

Debezium 是一组用于 Apache Kafka Connect 的 Source Connector。每个 Connector 都通过使用该数据库的变更数据捕获 (CDC) 功能从不同的数据库中获取变更。与其他方法（例如轮询或双重写入）不同，Debezium 的实现基于日志的 CDC：

确保捕获所有的数据变更。
以极低的延迟生成变更事件，同时避免因为频繁轮询导致 CPU 使用率增加。例如，对于 MySQL 或 PostgreSQL，延迟在毫秒范围内。
不需要更改您的数据模型，例如 ‘Last Updated’ 列。
可以捕获删除操作。
可以捕获旧记录状态以及其他元数据，例如，事务 ID，具体取决于数据库的功能和配置。

Flink CDC

2020 年 7 月提交了第一个 commit，这是基于个人兴趣孵化的项目；
2020 年 7 中旬支持了 MySQL-CDC；
2020 年 7 月末支持了 Postgres-CDC；

一年的时间，该项目在 GitHub 上的 star 数已经超过 800。

Flink CDC 发展

Flink CDC 底层封装了 Debezium， Debezium 同步一张表分为两个阶段：

全量阶段：查询当前表中所有记录；
增量阶段：从 binlog 消费变更数据。

大部分用户使用的场景都是全量 + 增量同步，加锁是发生在全量阶段，目的是为了确定全量阶段的初始位点，保证增量 + 全量实现一条不多，一条不少，从而保证数据一致性。从下图中我们可以分析全局锁和表锁的一些加锁流程，左边红色线条是锁的生命周期，右边是 MySQL 开启可重复读事务的生命周期。

以全局锁为例，首先是获取一个锁，然后再去开启可重复读的事务。这里锁住操作是读取 binlog 的起始位置和当前表的 schema。这样做的目的是保证 binlog 的起始位置和读取到的当前 schema 是可以对应上的，因为表的 schema 是会改变的，比如如删除列或者增加列。在读取这两个信息后，SnapshotReader 会在可重复读事务里读取全量数据，在全量数据读取完成后，会启动 BinlogReader 从读取的 binlog 起始位置开始增量读取，从而保证全量数据 + 增量数据的无缝衔接。

表锁是全局锁的退化版，因为全局锁的权限会比较高，因此在某些场景，用户只有表锁。表锁锁的时间会更长，因为表锁有个特征：锁提前释放了可重复读的事务默认会提交，所以锁需要等到全量数据读完后才能释放。

经过上面分析，接下来看看这些锁到底会造成怎样严重的后果：

Flink CDC 1.x 可以不加锁，能够满足大部分场景，但牺牲了一定的数据准确性。Flink CDC 1.x 默认加全局锁，虽然能保证数据一致性，但存在上述 hang 住数据的风险。

Flink CDC 1.x得到了很多用户在社区的反馈，主要归纳为三个：

全量 + 增量读取的过程需要保证所有数据的一致性，因此需要通过加锁保证，但是加锁在数据库层面上是一个十分高危的操作。底层 Debezium 在保证数据一致性时，需要对读取的库或表加锁，全局锁可能导致数据库锁住，表级锁会锁住表的读，DBA 一般不给锁权限。
不支持水平扩展，因为 Flink CDC 底层是基于 Debezium，起架构是单节点，所以Flink CDC 只支持单并发。在全量阶段读取阶段，如果表非常大 (亿级别)，读取时间在小时甚至天级别，用户不能通过增加资源去提升作业速度。
全量读取阶段不支持 checkpoint：CDC 读取分为两个阶段，全量读取和增量读取，目前全量读取阶段是不支持 checkpoint 的，因此会存在一个问题：当我们同步全量数据时，假设需要 5 个小时，当我们同步了 4 小时的时候作业失败，这时候就需要重新开始，再读取 5 个小时。

通过上面的分析，可以知道 2.0 的设计方案，核心要解决上述的三个问题，即支持无锁、水平扩展、checkpoint。

目前，Flink CDC 2.0 也已经正式发布，此次的核心改进和提升包括：

并发读取，全量数据的读取性能可以水平扩展；
全程无锁，不对线上业务产生锁的风险；
断点续传，支持全量阶段的 checkpoint。

本文发自微信公众号《import_bigdata》

Canal

canal [kə'næl]，译意为水道/管道/沟渠，主要用途是基于 MySQL 数据库增量日志解析，提供增量数据订阅和消费。

早期阿里巴巴因为杭州和美国双机房部署，存在跨机房同步的业务需求，实现方式主要是基于业务 trigger 获取增量变更。从 2010 年开始，业务逐步尝试数据库日志解析获取增量变更进行同步，由此衍生出了大量的数据库增量订阅和消费业务。

基于日志增量订阅和消费的业务包括：

数据库镜像
数据库实时备份
索引构建和实时维护(拆分异构索引、倒排索引等)
业务 cache 刷新
带业务逻辑的增量数据处理

当前的canal支持源端MySQL版本包括 5.1.x , 5.5.x , 5.6.x , 5.7.x , 8.0.x。

工作原理

MySQL主备复制原理

MySQL master 将数据变更写入二进制日志( binary log, 其中记录叫做二进制日志事件binary log events，可以通过 show binlog events 进行查看)
MySQL slave 将 master 的 binary log events 拷贝到它的中继日志(relay log)
MySQL slave 重放 relay log 中事件，将数据变更反映它自己的数据

canal 工作原理

canal 模拟 MySQL slave 的交互协议，伪装自己为MySQL slave,向MySQL master发送dump协议
MySQL master收到 dump 请求，开始推送 binary log 给 slave (即 canal )
canal 解析 binary log 对象(原始为 byte 流)

Binlog获取详解

Binlog发送接收流程，流程如下图所示:

首先，我们需要伪造一个slave，向master注册，这样master才会发送binlog event。注册很简单，就是向master发送COM_REGISTER_SLAVE命令，带上slave相关信息。这里需要注意，因为在MySQL的replication topology中，都需要使用一个唯一的server id来区别标示不同的server实例，所以这里我们伪造的slave也需要一个唯一的server id。

接着实现binlog的dump。MySQL只支持一种binlog dump方式，也就是指定binlog filename + position，向master发送COM_BINLOG_DUMP命令。在发送dump命令的时候，我们可以指定flag为BINLOG_DUMP_NON_BLOCK，这样master在没有可发送的binlog event之后，就会返回一个EOF package。不过通常对于slave来说，一直把连接挂着可能更好，这样能更及时收到新产生的binlog event。

Dump命令包图如下所示:

如上图所示,在报文中塞入binlogPosition和binlogFileName即可让master从相应的位置发送binlog event。

canal结构

说明：

server代表一个canal运行实例，对应于一个jvm，也可以理解为一个进程
instance对应于一个数据队列（1个server对应1..n个instance)，每一个数据队列可以理解为一个数据库实例。

Server设计

server代表了一个canal的运行实例，为了方便组件化使用，特意抽象了Embeded(嵌入式) / Netty(网络访问)的两种实现

Embeded : 对latency和可用性都有比较高的要求，自己又能hold住分布式的相关技术(比如failover)
Netty : 基于netty封装了一层网络协议，由canal server保证其可用性，采用的pull模型，当然latency会稍微打点折扣，不过这个也视情况而定。(阿里系的notify和metaq，典型的push/pull模型，目前也逐步的在向pull模型靠拢，push在数据量大的时候会有一些问题)

Instance设计

instance代表了一个实际运行的数据队列，包括了EventPaser,EventSink,EventStore等组件。

抽象了CanalInstanceGenerator，主要是考虑配置的管理方式：

manager方式：和你自己的内部web console/manager系统进行对接。(目前主要是公司内部使用，Otter采用这种方式) spring方式：基于spring xml + properties进行定义，构建spring配置.

下面是canalServer和instance如何运行：

    canalServer.setCanalInstanceGenerator(new CanalInstanceGenerator() {      
      
            public CanalInstance generate(String destination) {      
                Canal canal = canalConfigClient.findCanal(destination);      
                // 此处省略部分代码 大致逻辑是设置canal一些属性      
      
                CanalInstanceWithManager instance = new CanalInstanceWithManager(canal, filter) {      
      
                    protected CanalHAController initHaController() {      
                        HAMode haMode = parameters.getHaMode();      
                        if (haMode.isMedia()) {      
                            return new MediaHAController(parameters.getMediaGroup(),      
                                parameters.getDbUsername(),      
                                parameters.getDbPassword(),      
                                parameters.getDefaultDatabaseName());      
                        } else {      
                            return super.initHaController();      
                        }      
                    }      
      
                    protected void startEventParserInternal(CanalEventParser parser, boolean isGroup) {      
                        //大致逻辑是 设置支持的类型      
                        //初始化设置MysqlEventParser的主库信息，这处抽象不好，目前只支持mysql      
                    }      
      
                };      
                return instance;      
            }      
        });      
        canalServer.start(); //启动canalServer      
      
        canalServer.start(destination);//启动对应instance      
        this.clientIdentity = new ClientIdentity(destination, pipeline.getParameters().getMainstemClientId(), filter);      
        canalServer.subscribe(clientIdentity);// 发起一次订阅，当监听到instance配置时，调用generate方法注入新的instance

instance模块：

eventParser (数据源接入，模拟slave协议和master进行交互，协议解析)
eventSink (Parser和Store链接器，进行数据过滤，加工，分发的工作)
eventStore (数据存储)
metaManager (增量订阅&消费信息管理器)

EventParser设计

大致过程：

整个parser过程大致可分为几步：

Connection获取上一次解析成功的位置 (如果第一次启动，则获取初始指定的位置或者是当前数据库的binlog位点)
Connection建立链接，发送BINLOG_DUMP指令

    // 0. write command number      
// 1. write 4 bytes bin-log position to start at      
// 2. write 2 bytes bin-log flags      
// 3. write 4 bytes server id of the slave      
// 4. write bin-log file name

Mysql开始推送Binaly Log
接收到的Binaly Log的通过Binlog parser进行协议解析，补充一些特定信息(补充字段名字，字段类型，主键信息，unsigned类型处理)
传递给EventSink模块进行数据存储，是一个阻塞操作，直到存储成功
存储成功后，由CanalLogPositionManager定时记录Binaly Log位置

EventSink设计

说明：

数据过滤：支持通配符的过滤模式，表名，字段内容等
数据路由/分发：解决1:n (1个parser对应多个store的模式)
数据归并：解决n:1 (多个parser对应1个store)
数据加工：在进入store之前进行额外的处理，比如join

数据1:n业务

为了合理的利用数据库资源，一般常见的业务都是按照schema进行隔离，然后在mysql上层或者dao这一层面上，进行一个数据源路由，屏蔽数据库物理位置对开发的影响，阿里系主要是通过cobar/tddl来解决数据源路由问题。

所以，一般一个数据库实例上，会部署多个schema，每个schema会有由1个或者多个业务方关注。

数据n:1业务

同样，当一个业务的数据规模达到一定的量级后，必然会涉及到水平拆分和垂直拆分的问题，针对这些拆分的数据需要处理时，就需要链接多个store进行处理，消费的位点就会变成多份，而且数据消费的进度无法得到尽可能有序的保证。

所以，在一定业务场景下，需要将拆分后的增量数据进行归并处理，比如按照时间戳/全局id进行排序归并。

EventStore设计

目前仅实现了Memory内存模式，后续计划增加本地file存储，mixed混合模式。
借鉴了Disruptor的RingBuffer的实现思路

RingBuffer设计：

定义了3个cursor

Put : Sink模块进行数据存储的最后一次写入位置 Get : 数据订阅获取的最后一次提取位置 Ack : 数据消费成功的最后一次消费位置

借鉴Disruptor的RingBuffer的实现，将RingBuffer拉直来看：

实现说明：

Put/Get/Ack cursor用于递增，采用long型存储buffer的get操作，通过取余或者与操作。(与操作：cusor & (size - 1) , size需要为2的指数，效率比较高)

HA机制设计

canal的ha分为两部分，canal server和canal client分别有对应的ha实现

canal server: 为了减少对mysql dump的请求，不同server上的instance要求同一时间只能有一个处于running，其他的处于standby状态.
canal client: 为了保证有序性，一份instance同一时间只能由一个canal client进行get/ack/rollback操作，否则客户端接收无法保证有序。

整个HA机制的控制主要是依赖了zookeeper的几个特性，watcher和EPHEMERAL节点(和session生命周期绑定)，可以看下我之前zookeeper的相关文章。

Canal Server:

大致步骤：

canal server要启动某个canal instance时都先向zookeeper进行一次尝试启动判断 (实现：创建EPHEMERAL节点，谁创建成功就允许谁启动)
创建zookeeper节点成功后，对应的canal server就启动对应的canal instance，没有创建成功的canal instance就会处于standby状态
一旦zookeeper发现canal server A创建的节点消失后，立即通知其他的canal server再次进行步骤1的操作，重新选出一个canal server启动instance
canal client每次进行connect时，会首先向zookeeper询问当前是谁启动了canal instance，然后和其建立链接，一旦链接不可用，会重新尝试connect

Canal Client的方式和canal server方式类似，也是利用zookeeper的抢占EPHEMERAL节点的方式进行控制。

本文发自微信公众号《import_bigdata》

总结

CDC 的技术方案非常多，目前业界主流的实现机制可以分为两种：

基于查询的 CDC：

离线调度查询作业，批处理。把一张表同步到其他系统，每次通过查询去获取表中最新的数据；
无法保障数据一致性，查的过程中有可能数据已经发生了多次变更；
不保障实时性，基于离线调度存在天然的延迟。

基于日志的 CDC：

实时消费日志，流处理，例如 MySQL 的 binlog 日志完整记录了数据库中的变更，可以把 binlog 文件当作流的数据源；
保障数据一致性，因为 binlog 文件包含了所有历史变更明细；
保障实时性，因为类似 binlog 的日志文件是可以流式消费的，提供的是实时数据。

对比常见的开源 CDC 方案，我们可以发现：

对比增量同步能力:

        - 基于日志的方式，可以很好的做到增量同步；          
- 而基于查询的方式是很难做到增量同步的。

对比全量同步能力，基于查询或者日志的 CDC 方案基本都支持，除了 Canal。
而对比全量 + 增量同步的能力，只有 Flink CDC、Debezium、Oracle Goldengate 支持较好。
从架构角度去看，该表将架构分为单机和分布式，这里的分布式架构不单纯体现在数据读取能力的水平扩展上，更重要的是在大数据场景下分布式系统接入能力。例如 Flink CDC 的数据入湖或者入仓的时候，下游通常是分布式的系统，如 Hive、HDFS、Iceberg、Hudi 等，那么从对接入分布式系统能力上看，Flink CDC 的架构能够很好地接入此类系统。
在数据转换 / 数据清洗能力上，当数据进入到 CDC 工具的时候是否能较方便的对数据做一些过滤或者清洗，甚至聚合？

在 Flink CDC 上操作相当简单，可以通过 Flink SQL 去操作这些数据；
但是像 DataX、Debezium 等则需要通过脚本或者模板去做，所以用户的使用门槛会比较高。

另外，在生态方面，这里指的是下游的一些数据库或者数据源的支持。Flink CDC 下游有丰富的 Connector，例如写入到 TiDB、MySQL、Pg、HBase、Kafka、ClickHouse 等常见的一些系统，也支持各种自定义 connector。

基于Binlog的实时同步功能——debezium、canel、databus技术选型 | holmofy

Sat, 30 Oct 2021 23:19:38 CST

去年的一篇文章大致地讲了我对MQ的一些认识，事实上Kafka在内的现代MQ，功能远不止这些。后面整理好自己的思路，肯定会再写一篇文章来讲讲。这篇文章的主角就是与MQ息息相关的CDC技术。

#1. CDC技术

CDC全称叫：change data capture，是一种基于数据库数据变更的事件型软件设计模式。

比如有一张订单表trade，订单每一次变更录入到一张trade_change的队列表。然后另外一个调度线程可以消费trade_change这张队列表来做一些数据统计，如每日的付款用户统计、每日的下单用户统计等。

这就是我毕业入职的第一家公司的报表统计逻辑。这个设计在订单量小的时候是看不出问题的，而一旦某一时刻订单量增多。基于MySQL的队列表由于B+树的写入吞吐量不够，导致MySQL CPU经常飙升。比如双十一，618这样的大促，程序员就得在颤颤巍巍中度过。

其次，从MySQL同步到ElaticSearch是根据 last_modify_time时间扫索引增量同步的，这就要求表上必须创建 last_modify_time索引，Scheduler一多也会无形地增加MySQL的读取负担。

B+的写入性能肯定是不如直接顺序写文件的，B+树的本质就是牺牲写性能，换取磁盘上的随机读的查找结构，所以大部分数据库都会设计 Buffer Pool来管理B+树脏页，以避免频繁的随机IO。
同时为了防止Buffer数据丢失同时为了保证事务的ACID，所以就有了 Redo-log来进行崩溃恢复， Undo-log来做未提交事务的撤销。这些日志都是顺序写入，远比B+树的随机写性能高。

#2. 基于Binlog的CDC

Binlog是MySQL 3.23.14引进的，它包含所有的描述数据库修改的事件——DML(增删改)、DDL(表结构定义与修改)操作。

与InnoDB中的 redo-log、 undo-log不同，binlog和 slow_query_log一样是server层的日志，所以InnoDB和MyISAM等各种存储引擎的数据修改都会记录到这个日志中。

MySQL拥有分层架构，支持可插拔的存储引擎，所以服务层的binlog与 InnoDB引擎的redo-log是不同的两个事物，这也是为什么MySQL支持以 STATEMENT格式直接将sql语句存入binlog。而像PostgreSQL这样的数据库， WAL日志除了作为redo-log用于保证事务的持久性外，WAL日志在Replica过程中也扮演着与MySQL的binlog相同的角色, 但是需要用 Logical Decoding将WAL日志解析成数据流或SQL语句。

对于CDC的架构设计，在大数据量的分布式场景下，我们都是使用binlog来做事件源。

一方面，将binlog复制到Kafka，再由Kafka下游的消费者处理这些事件不影响数据库的核心业务，可以降低系统的耦合度；

另一方面，binlog和Kafka都是基于日志的顺序写入，Kafka的吞吐量远比B+树高，系统的整体性能也能得到改善。

目前基于binlog的CDC技术已经很成熟了，在github上也有很多实现，通过 Change Data Capture、 replication、 binlog等关键词可以搜索到相关项目。在此列举一下：

Project	Language	Description
alibaba/Canal	Java	阿里巴巴 MySQL binlog 增量订阅&消费组件
debezium/debezium	Java	Debezium is an open source distributed platform for change data capture. Replicates from MySQL to Kafka. Uses mysql-binlog-connector-java. Kafka Connector. A funded project supported by Redhat with employees working on it full time.
linkedin/databus	Java	Precursor to Kafka. Reads from MySQL and Oracle, and replicates to its own log structure. In production use at LinkedIn. No Kafka integration. Uses Open Replicator.
zendesk/Maxwell	Java	Reads MySQL event stream, output events as JSON. Parses ALTER/CREATE TABLE/etc statements to keep schema in sync. Written in java. Well maintained.
noplay/python-mysql-replication	Python	Pure python library that parses MySQL binary logs and lets you process the replication events. Basically, the python equivalent of mysql-binlog-connector-java
shyiko/mysql-binlog-connector-java	Java	Library that parses MySQL binary logs and calls your code to process them. Fork/rewrite of Open Replicator. Has tests.
confluentinc/bottledwater-pg	C	Change data capture from PostgreSQL into Kafka
uber/storagetapper	Go	StorageTapper is a scalable realtime MySQL change data streaming, logical backup and logical replication service
moiot/gravity	Go	A Data Replication Center
whitesock/open-replicator	Java	Open Replicator is a high performance MySQL binlog parser written in Java. It unfolds the possibilities that you can parse, filter and broadcast the binlog events in a real time manner.
mardambey/mypipe	Scala	Reads MySQL event stream, and emits events corresponding to INSERTs, DELETEs, UPDATEs. Written in Scala. Emits Avro to Kafka.
Yelp/mysql_streamer	Python	MySQLStreamer is a database change data capture and publish system. It’s responsible for capturing each individual database change, enveloping them into messages and publishing to Kafka.
actiontech/dtle	Go	Distributed Data Transfer Service for MySQL
krowinski/php-mysql-replication	PHP	Pure PHP Implementation of MySQL replication protocol. This allow you to receive event like insert, update, delete with their data and raw SQL queries.
dianping/puma	Java	本系统还会实现数据库同步（同构和异构），以满足数据库冗余备份，数据迁移的需求。
JarvusInnovations/Lapidus	Javascript	Streams data from MySQL, PostgreSQL and MongoDB as newline delimited JSON. Can be run as a daemon or included as a Node.js module.

这里只讨论Java语言的几个实现。首先 whitesock/open-replicator和 shyiko/mysql-binlog-connector-java是专门用来解析MySQL binlog的库，后者也是在前者的基础上重构的。 debezium/debezium、 linkedin/databus、 zendesk/Maxwell三个中间件binlog解析都是基于这两个库。

#3. Canal vs. Debezium vs. databus vs. MaxWell

1、 alibaba/Canal

优点：

阿里开源，有大厂实践背书
资料大都是中文的，方便学习

缺点：

定位于MySQL binlog解析，所以只能支持MySQL数据库的CDC
Github上项目活跃度很一般，issue堆积了太多，13、14年的问题都还没解决。

2、 debezium/debezium

优点：

Rethat开源，专干开源的国际大厂背书
支持MySQL、PostgreSQL、Oracle、SqlServer、MongoDB主流数据库
文档详细，资料齐全
社区完善，在 Gitter上有专门的问题讨论区。
与Kafka很好集成，可作为Kafka Connector插件使用， embed模式支持嵌入自己的程序方便控制，也支持 Server模式单独运行。
支持SMT消息体转换，OpenTracing分布式链路追踪等集成功能

缺点：

文档大多数是英文的，得多花点耐心

有意思的是阿里开源的 Flink流处理系统也是使用Debezium来做CDC，当然它还支持Canel、Maxwell

Kafka创始人创办的 confluentinc刚开始开源了 bottledwater-pg，最后也投入了debezium的怀抱，有官方的认可。

3、 linkedin/databus

优点：

国际大厂领英开源
支持MySQL和Oracle

缺点：

项目已经很久没有人维护了
文档也很一般
暂时不支持Kafka集成，只能用 Databus Client消费binlog。

Kafka最早是 Jay Kreps在领英创建并开源的，可能是Jay Kreps觉得Kafka在大数据领域大有可图，所以就带着Linkedin的几个工程师一起创立了 Confluent专注于Kafka生态的开发与维护。

在Kafka文档 Log-Compact一节可以看到这段话：

This functionality is inspired by one of LinkedIn’s oldest and most successful pieces of infrastructure—a database changelog caching service called Databus. Unlike most log-structured storage systems Kafka is built for subscription and organizes data for fast linear reads and writes. Unlike Databus, Kafka acts as a source-of-truth store so it is useful even in situations where the upstream data source would not otherwise be replayable.

可以看出Databus是Linkedin非常老的一个基础服务，Kafka的Log Compact的一些设计也源自于Databus。

4、 zendesk/maxwell

优点：

相当简单，下载下来，简单进行配置就能运行
文档相对来说，还算齐全
支持Kafka、RabbitMQ、Redis等队列

缺点：

文档是英文的，不过好在maxwell相对简单。
没啥明显缺点。非要说个缺点，就是和前三者比身份不够显赫，zendesk这家美国公司没怎么听过。

综合下来，Debezium是最佳选择。

#4. Debezimu-MySQL的配置

要使用debezium需要预先对mysql服务进行配置。

#4.1. MySQL配置

1）创建单独的用户，并授予debezium需要的权限

1             
2             
3

mysql>CREATEUSER'user'@'localhost'IDENTIFIEDBY'password';             
mysql>GRANTSELECT, RELOAD,SHOWDATABASES, REPLICATION SLAVE, REPLICATION CLIENTON*.*TO'user'IDENTIFIEDBY'password';             
mysql>FLUSH PRIVILEGES;

MySQL提供的权限： https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html

debezium需要几个权限的作用：

Keyword	Description
`SELECT`	`SELECT`查询权限。只被用在初始化阶段。
`RELOAD`	执行 `FLUSH`语句清除重新加载内部缓存。只被用在初始化阶段。
`SHOW DATABASES`	执行 `SHOW DATABASE`语句。只被用在初始化阶段。
`REPLICATION SLAVE`	读取MySQL binlog。
`REPLICATION CLIENT`	执行 `SHOW MASTER STATUS`、 `SHOW SLAVE STATUS`、 `SHOW BINARY LOGS`等语句。

2）开启MySQL服务的binlog功能

server-id=223344             
log_bin=mysql-bin             
binlog_format=ROW             
binlog_row_image=FULL             
expire_logs_days=10

各项配置的作用：

Property	Description
`server-id`	在MySQL集群中每个server和replication的 `server-id`必须是唯一的。Debezium是作为MySQL的replication，启动后也会分配一个 `server-id`给debezium-connector。
`log_bin`	binlog文件的前缀
`binlog_format`	`binlog-format`必须设置成 `ROW`模式。
`binlog_row_image`	`binlog_row_image`必须设置成 `FULL`。 `ROW`模式下binlog需要记录所有的列。
`expire_logs_days`	binlog的过期时间。默认位 `0`, 意味着不会自动删除。这个值可根据自己的环境需求进行设置。

mysql的 binlog有三种模式：
STATEMENT模式只记录SQL语句，从节点通过执行同步过来的sql在从库中再执行一遍。 STATEMENT模式的问题是有些语句(比如 update t set num=num+1 limit 1)可能会产生不一致性，而且 STATEMENT模式下sql发给异构系统将会无法使用。
ROW模式会直接复制修改的数据行，但是有可能会导致日志量过大，比如执行一条 update t set num=num+1，修改了一万行就会有一万行日志，肯定没有 STATEMENT模式来的快。
MIXED模式，则将两者结合，默认情况下使用statement，某些情况会切换为基于行的复制。
具体可以参考这个回答

还有几项可选配置项：

开启全局事务ID(GTIDs)方便确认主从备份切换时之间的数据一致性。MySQL有主从切换就不能用binlog物理位置来标识binlog消费offset了，此时需要用全局的gtid。

配置MySQL会话超时时间用于大表的快照读阶段。

开启原始SQL语句的记录用于查看每条binlog记录的原始SQL。

#4.2. 准备Kafka环境，在Kafka-connect中安装Debezium

Kafka需要依赖 Zookeeper管理集群，所以还需要准备zookeeper环境。

1）下载Debezium： https://debezium.io/releases/

2）配置Kafka-connect插件路径，并将Debezimu插件解压到该目录

1	plugin.path=/kafka/connect

3）启动Kafka-connect进程：

Kafka-connect可以用单机版( standalone)和分布式版( distributed)两种启动方式：

standalone模式下，启动时直接提供 properties文件来创建Connector任务。
distributed模式下，提供 REST接口对Connector任务进行增删改查。

#4.3. Debezium的基础配置

在 distributed模式下可以，调用 POST /connectors接口创建Debezium的Connector任务，任务的基本配置如下：

{             
"name":"inventory-connector",             
"config": {             
"connector.class":"io.debezium.connector.mysql.MySqlConnector",             
"database.hostname":"192.168.99.100",             
"database.port":"3306",             
"database.user":"debezium-user",             
"database.password":"debezium-user-pw",             
"database.server.id":"184054",             
"database.server.name":"fullfillment",             
"database.include.list":"inventory",             
"database.history.kafka.bootstrap.servers":"kafka:9092",             
"database.history.kafka.topic":"dbhistory.fullfillment",             
"include.schema.changes":"true"             
}             
}

这个配置主要是数据库的用户名密码，需要同步的数据库和相关数据表，以及kafka地址和数据库schema变更存储的topic。

Debezium-Connector的所有配置： https://debezium.io/documentation/reference/1.4/connectors/mysql.html#mysql-connector-properties

#5. binlog解析的难点与Debezium工作原理

binlog的 ROW模式下类似于csv是没有shema的，我们将 row_image设置成full模式，不管update操作只涉及几列，都会把完整的行数据写入到binlog。

#5.1. 表结构随时都会修改，需要解析ddl并维护一份schema用于事件的生成

数据库客户端查询数据库的时候，客户端拿到的都是数据库当前的schema。因为schema随时可以改变，这意味着主从备份的时候，debezium不能只使用当前的schema，因为debezium可能正在处理较旧的事件。

比如，有一张trade_info表，在某个时间点T添加了payment字段，在T之前的binlog是没有payment字段的，T之后的binlog才有payment。那Debezium生成事件也应该是在T之前有payment字段，T之后没有payment字段。

MySQL在binlog中不仅包含行级修改，还包括了数据库的DDL语句。当Debezium的Connector读取binlog并遇到这些DDL语句时，它会解析这些DDL并更新内存中每个表shema。Debezium使用这个shema就能标识每次增删改操作的结构从而生成事件。

#5.2. 内存里的schema维护存在问题

崩溃或正常重启后，怎么还原schema，如果使用数据库当前的schema会怎样呢：

假如在T0~T1的时间内，表结构A发生过增加列的DDL操作，那在处理T0时间段A表的binlog时，拿到的表结构为T1的schema，就会出现列不匹配的情况. 比如之前的异常: column size is not match for table: xx , 12 vs 13
假如在T0~T1发生了增加 C1列、删除了C2列，此时拿到的列的总数还是和T0时保持一致，但是对应的列会错位
假如在T0~T1发生了drop table的DDL，此时拿表结构时会出现无法找到表的异常，一直阻塞整个binlog处理，比如not found [xx] in db

很明显，不能直接查数据库当前的schema来为之前的binlog生成事件。Debezium和Canal都有自己的解决方案：

Debezium会把所有DDL语句以及DDL在binlog的位置单独存在一个 history的topic中，这个topic可以用 database.history.kafka.topic进行配置。
当Debezium的Connector崩溃或正常停止重启后，Connector重新从原来的位置读取binlog。但是存在内存里的schema已经没有了，所以它会重新解析history中的DDL语句重建表结构。

alibaba/canal提供了 TableMetaTSDB的功能可以存储表结构的时序数据。

#5.3. Kafka无法保证多个partition的消费顺序

因为Debezium会重新解析history topic的DDL语句，我们希望DDL语句能按正常顺序解析，但是Kafka无法保证多个partition的消费顺序，所以history的topic的partition个数必须设置成1。

#5.4. 消费DDL

Debezium不希望用户直接使用history topic。因为里面包含了binlog中的所有ddl语句。

如果用户想要消费自己关心的表的DDL语句，Debezium提供了 schema change topic，这个topic名字被命名为 serverName，这个serverName通过 database.server.name配置。

#6. Debezium踩坑记录

debezium配置起来还是比较简单的，但是这么复杂的项目，坑还是比较多的。

#6.1. 关闭快照初始化

Debezium的Connector第一次启动时，会给你的数据库执行一次快照初始化。

因为对于老项目，早期的binlog肯定已经被删掉了，这个时候Debezium会帮你把数据库的所有数据都写到Kafka里，这次快照之后的增删改操作通过解析binlog写入kafka。这也是为什么Debezium需要获取数据库 SELECT权限的原因。

但是快照读有这么几个问题：

在执行快照初始化过程中，Connector重启或者Kafka-connect Rebalance，重启后Debezium会重新初始化快照。因为Debezium的快照是通过 SELECT * FROM table扫描全表实现的，没有记录进度，非常粗暴。
为了防止快照初始化过程中表的schema会变更，快照初始化前会获取全局读锁。

可以通过 snapshot.locking.mode属性配置是否获取全局读锁， snapshot.locking.mode=none即可关闭。

snapshot只适合在备份从库上执行，否则可能会影响正常用户的使用，通过 snapshot.mode可以对初始化进行配置，这个选项支持以下几个配置值：

initial(default)- 只有当binlog的offset没有记录的时候才会执行一次快照初始化。

when_needed- 有需要时就会执行，比如第一次offset没有记录，或者Connector停了很久早期的binlog被删掉了，当前的offset已经不可用了，或者GTID对不上的时候。

never- 从不执行初始化。第一次启动Connector时就从binlog头部开始读取。需要注意，这种配置需要binlog包含所有的历史记录。

schema_only- Connector初始化时只读取表的 schame而不读取数据。如果你只需要Connector启动后的数据库变更，那这个配置很有用。

schema_only_recovery- 用于恢复重启后丢失的schema，但是这个只能用在自上次提交binlog-offset后，schema没有发生任何变更。

initial_only- 这个配置在文档里没有，代码里可以看到，这个是只用来执行快照的。

用一句话总结一下： initial先全量后增量同步， schema_only和 never是只增量同步， initial_only是只全量同步。

#6.2. 修改topic

Debezium默认的行为是将一张表上的 INSERT、 UPDATE、 DELETE操作记录到一个topic。Topic命名规则是 <serverName>.<databaseName>.<tableName>

如果进行分库了，比如 server0上有 db01和 db02两个逻辑库， server1上有 db11和 db12两个逻辑库，这四个逻辑库上都有一张 order表。那此时就会有4个topic。

如果我们想把它们路由到同一个topic上，就需要用到 Kafka-Connect提供的SMT功能了：

transforms=route             
transforms.route.type=org.apache.kafka.connect.transforms.RegexRouter             
transforms.route.regex=([^.]+)\\.([^.]+)\\.([^.]+)             
transforms.route.replacement=$3

Kafka-Connect提供了一个 RegexRouter、 TimestampRouter、 MessageTimestampRouter几个SMT让我们修改数据存入的topic。这里的RegexRouter，允许我们用正则表达式来对 Debezium默认的topic进行修改。

#6.3. Decimal数据的处理

对于MySQL中的 decimal类型的数据，Java里会转成 BigDecimal，但是以json格式存入kafka的时候就会丢失精度。

毕竟json出自JS， JS中只支持number数值类型，对应到Java就是double类型。

Debezium支持 decimal.handling.mode选项可以将decimal配置成 string类型。

#6.4. 时间类型数据的处理

Debezium底层的binlog解析用的是 shyiko/mysql-binlog-connector-java。这中间做了很多转换：

mysql(Asia/Shanghai)	binlog-connector	debezium	debezium schema
date (2021-01-28)	LocalDate (2021-01-28)	Integer (18655)	io.debezium.time.Date
time (17:29:04)	Duration (PT17H29M4S)	Long (62944000000)	io.debezium.time.MicroTime
timestamp (2021-01-28 17:29:04)	ZonedDateTime (2021-01-28T09:29:04Z)	String (2021-01-28T09:29:04Z)	io.debezium.time.ZonedTimestamp
datetime (2021-01-28 17:29:04)	LocalDateTime (2021-01-28T17:29:04)	Long (1611854944000)	io.debezium.time.Timestamp

date类型，最后在Debezium中会调用 LocalDate.toEpochDay转成了基于1970年的天数。

time类型，在binlog解析库中，被转成了Duration，在Debezium中最后被转成了毫秒值。

timestamp类型，最后在Debezium中被转成了一个ISO格式的字符串，但是时区默认是UTC时区。

datetime类型，最后在Debezium中被转成了一个long类型，时区是写死的UTC时区。

文档里有MySQL时间类型与存入Kafka类型的映射表

总之，Debezium时间的处理混乱不堪。所以我为Debezium写了一个 datetime-converter的补丁可以将这四种类型转成字符串。配置如下：

converters=datetime             
datetime.type=com.darcytech.debezium.converter.MySqlDateTimeConverter             
datetime.format.date=yyyy-MM-dd             
datetime.format.time=HH:mm:ss             
datetime.format.datetime=yyyy-MM-dd HH:mm:ss             
datetime.format.timestamp=yyyy-MM-dd HH:mm:ss             
datetime.format.timestamp.zone=UTC+8

#6.5. 墓碑事件

Debezium会生成5种事件：

createevents：对应MySQL种的INSERT语句。

{                 
"op":"c",                 
"ts_ms":1465491411815,                 
"before":null,                 
"after": {                 
"id":1004,                 
"first_name":"Anne",                 
"last_name":"Kretchmar",                 
"email":"annek@noanswer.org"                 
},                 
"source": {                 
"version":"1.4.2.Final",                 
"connector":"mysql",                 
"name":"mysql-server-1",                 
"ts_ms":0,                 
"snapshot":false,                 
"db":"inventory",                 
"table":"customers",                 
"server_id":0,                 
"gtid":null,                 
"file":"mysql-bin.000003",                 
"pos":154,                 
"row":0,                 
"thread":7,                 
"query":"INSERT INTO customers (first_name, last_name, email) VALUES ('Anne', 'Kretchmar', 'annek@noanswer.org')"                 
}                 
}

此时payload种的before字段为null，after字段为新增的记录值。

updateevents：对应MySQL种的UPDATE语句。

{                 
"before": {                 
"id":1004,                 
"first_name":"Anne",                 
"last_name":"Kretchmar",                 
"email":"annek@noanswer.org"                 
},                 
"after": {                 
"id":1004,                 
"first_name":"Anne Marie",                 
"last_name":"Kretchmar",                 
"email":"annek@noanswer.org"                 
},                 
"source": {                 
"version":"1.4.2.Final",                 
"name":"mysql-server-1",                 
"connector":"mysql",                 
"name":"mysql-server-1",                 
"ts_ms":1465581029100,                 
"snapshot":false,                 
"db":"inventory",                 
"table":"customers",                 
"server_id":223344,                 
"gtid":null,                 
"file":"mysql-bin.000003",                 
"pos":484,                 
"row":0,                 
"thread":7,                 
"query":"UPDATE customers SET first_name='Anne Marie' WHERE id=1004"                 
},                 
"op":"u",                 
"ts_ms":1465581029523                 
}

此时payload中，before为更新前的数据，after为更新后的数据。

Primary key updates：修改主键的操作，会生成一个 DELETE事件和 CREATE事件：
- DELETE事件会有 __debezium.newkey的消息头。这个值是更新后的新主键。
- CREATE事件会有 __debezium.oldkey的消息头。这个值是更新前的老主键。

deleteevents：对应MySQL的DELTE语句。

{                 
"schema": { ... },                 
"payload": {                 
"before": {                 
"id":1004,                 
"first_name":"Anne Marie",                 
"last_name":"Kretchmar",                 
"email":"annek@noanswer.org"                 
},                 
"after":null,                 
"source": {                 
"version":"1.5.0.Beta2",                 
"connector":"mysql",                 
"name":"mysql-server-1",                 
"ts_ms":1465581902300,                 
"snapshot":false,                 
"db":"inventory",                 
"table":"customers",                 
"server_id":223344,                 
"gtid":null,                 
"file":"mysql-bin.000003",                 
"pos":805,                 
"row":0,                 
"thread":7,                 
"query":"DELETE FROM customers WHERE id=1004"                 
},                 
"op":"d",                 
"ts_ms":1465581902461                 
}                 
}

此时payload中，before为删除前的数据，after为null。

Tombstone events：Debezium会为删除操作生成一条key与DELETE事件相同、value为null的空消息(墓碑事件)。

墓碑事件主要用于 Kafka的compact——Kafka会删除具有相同key的早期事件。但是要让Kafka删除所有具有相同key的消息，需要将消息指设置成null。

需要特别注意，墓碑事件的消息value为null，需要为这个事件做特殊处理。

#6.6. 禁用Kafka-Connect的Schema配置

Kafka-Connect为了保证每条消息是可以自我描述的，所以都会带schema。如果我们使用了 JsonConverter进行序列化，默认情况下，kafka中的消息格式是这样的：

{             
"schema": {/* ... */},             
"payload": {             
"op":"u",             
"source": {             
...             
},             
"ts_ms":"...",             
"before": {             
"field1":"oldvalue1",             
"field2":"oldvalue2"             
},             
"after": {             
"field1":"newvalue1",             
"field2":"newvalue2"             
}             
}             
}

这里面的schema会包含下面payload里每个字段的类型解释，会导致Kafka中存储的消息非常臃肿。可以在Kafka-Connect中将Key和Value的schema禁用掉：

key.converter=org.apache.kafka.connect.json.JsonConverter             
value.converter=org.apache.kafka.connect.json.JsonConverter             
key.converter.schemas.enable=false             
value.converter.schemas.enable=false

更好的解决方案是使用中心化的Schema Registry。Debezium也推荐使用这种方式。

在github搜索 schema registry关键词查找相关项目。 Debezium在文档中推荐 Apicurio API and Schema Registry和 Confluent Schema Registry这两种SchemaRegistry。

#6.7. 对Debezium生成的消息进行处理

没有shema的时候，Debezium默认生成的数据格式是这样的：

{             
"op":"u",             
"source": {             
...             
},             
"ts_ms":"...",             
"before": {             
"field1":"oldvalue1",             
"field2":"oldvalue2"             
},             
"after": {             
"field1":"newvalue1",             
"field2":"newvalue2"             
}             
}

消息体中 before表示变更前的数据， after表示变更后的数据， source表示来源于哪个数据库、哪张表、哪个事务(GTID)。

为了方便与其他Connector集成，比如让 kafka-connect-jdbc把消息都写到另一个数据库中。那这个时候我们只想要 after里面的数据了。

Debezium提供了一个 Event-Flat的SMT，我们只需要和上面的RegexRouter一样配置一下就可以了：

1 2	transforms=unwrap,... transforms.unwrap.type=io.debezium.transforms.ExtractNewRecordState

那如果是删除操作呢，删除操作会生成两个事件，一个delete事件有before没有after，还有一个和delete事件key相同的墓碑事件消息体为null。ExtractNewRecordState可以配置怎么处理 delete记录：

transforms=unwrap,...             
transforms.unwrap.type=io.debezium.transforms.ExtractNewRecordState             
transforms.unwrap.drop.tombstones=true             
transforms.unwrap.delete.handling.mode=drop

delete.handling.mode指定delete记录的处理模式，默认为 drop也就是delete记录将会被ExtractNewRecordState丢弃。 drop.tombstones指定要不要丢弃墓碑事件。

更多配置可以参考官方文档

#6.8. kafka-connect的坑

kafka broker本身有个配置 auto.create.topics.enable默认为true——当发送消息到一个不存在的topic时，kafka会自动创建这个topic，这些自动创建的topic会使用 num.partitions和 default.replication.factor指定的partition数和replicas数创建topic。生产环境一般是不建议使用kafka broker中的自动创建主题的，因为这可能会带来很大的维护成本，我们希望不同情况使用不同的主题配置。

另外，kafka-connect启动时默认会创建三个 connect内部使用的topic，这三个topic名字由 config.storage.topic、 offset.storage.topic、 status.storage.topic三个配置指定，它们分别存储connector的配置和offset以及当前的状态。

如果想要对这三个自动创建的topic进行一些配置，可以参考 connect的文档

如果你是手动创建需要注意：

config的partition必须为1；

offset和kafka内建的 __consumer_offsets类似，如果要支持更大的kafka-connect集群，可以把partition设大一点。

这三个topic的 cleanup.policy都必须设置成compacted模式。

如果是source connector内部要自动创建topic，可以使用connector的一些配置，具体可以参考：

Configuring Auto Topic Creation for Source Connectors

Customization of Kafka Connect automatic topic creation

Refs:

^ Debezium Document: https://debezium.io/documentation/reference/1.4/

^ Debezium FAQ: https://debezium.io/documentation/faq/

^ Confluent Document: https://docs.confluent.io/platform/current/overview.html

^ Aliyun DTS服务原理: https://www.alibabacloud.com/help/zh/doc-detail/176085.htm

^ Aliyun DTS应用场景: https://www.alibabacloud.com/help/zh/doc-detail/176086.htm

rsync+inotify-tools实现数据实时同步方案_Ljohn的技术博客_51CTO博客

Wed, 07 Jul 2021 15:30:10 CST

rsync数据同步优缺点

与传统的cp、tar备份方式相比，rsync具有安全性高、备份迅速、支持增量备份等优点，通过rsync可以解决对实时性要求不高的数据备份需求，例如定期的备份文件服务器数据到远端服务器，对本地磁盘定期做数据镜像等。

随着应用系统规模的不断扩大，对数据的安全性和可靠性也提出的更好的要求，rsync在高端业务系统中也逐渐暴露出了很多不足。首先，rsync同步数据时，需要扫描所有文件后进行比对，进行差量传输。如果文件数量达到了百万甚至千万量级，扫描所有文件将是非常耗时的。而且正在发生变化的往往是其中很少的一部分，这是非常低效的方式。其次，rsync不能实时的去监测、同步数据，虽然它可以通过linux守护进程的方式进行触发同步，但是两次触发动作一定会有时间差，这样就导致了服务端和客户端数据可能出现不一致，无法在应用故障时完全的恢复数据。基于以上原因，rsync+inotify组合出现了！

inotify

inotify是一种强大的、细粒度的、异步的文件系统事件监控机制，linux内核从2.6.13起，加入了inotify支持，通过inotify可以监控文件系统中添加、删除，修改、移动等各种细微事件，利用这个内核接口，第三方软件就可以监控文件系统下文件的各种变化情况，而inotify-tools就是这样的一个第三方软件。

一、环境准备

操作系统：CentOS release 6.8 (Final) x86_64

服务器IP：

     rsync_server（数据源）192.168.0.44
rsync_client（目标端）192.168.0.45
           1.
      2.

同步目录：

     rsync_server       /app/rsync_server
rsync_client       /app/rsync_client 
           1.
      2.

二、安装及配置rsync

客户端配置（目标端）

1、安装rsync

     # yum -y install rsync xinetd
# cp /etc/xinetd.d/rsync{,.bak}
# vim /etc/xinetd.d/rsync
service rsync
{
        disable = no            #修改为no
        flags           = IPv6
        socket_type     = stream
        wait            = no
        user            = root
        server          = /usr/bin/rsync
        server_args     = --daemon
        log_on_failure  += USERID
}
# /etc/init.d/xinetd start 
           1.
      2.
      3.
      4.
      5.
      6.
      7.
      8.
      9.
      10.
      11.
      12.
      13.
      14.
      15.

2、配置rsync

     # vim /etc/rsyncd.conf    #创建配置文件

logfile = /var/log/rsyncd.log    #日志文件位置，启动rsync后自动产生这个文件，无需提前创建
pidfile = /var/run/rsyncd.pid    #pid文件的存放位置
lockfile = /var/run/rsync.lock   #支持max connections参数的锁文件
secretsfile = /etc/rsync.pass    #用户认证配置文件，里面保存用户名称和密码，后面会创建这个文件
motdfile = /etc/rsyncd.Motd    #rsync启动时欢迎信息页面文件位置（文件内容自定义）
[app_rsync_client]   #自定义名称
path = /app/rsync_client/    #rsync服务端数据目录路径
comment = app_rsync_client    #模块名称与[app_rsync_client]自定义名称相同
uid = root    #设置rsync运行权限为root
gid = root    #设置rsync运行权限为root
port =873
use chroot = no    #默认为true，修改为no，增加对目录文件软连接的备份
read only = no    设置rsync服务端文件为读写权限
list = no    #不显示rsync服务端资源列表
mac connections = 200
timeout = 600
auth users = rsync    #执行数据同步的用户名，可以设置多个，用英文状态下逗号隔开
hosts allow = 192.168.0.45   #允许进行数据同步的客户端IP地址，可以设置多个，用英文状态下逗号隔开
hosts deny = 192.168.0.46,192.168.0.47    #禁止数据同步的客户端IP地址，可以设置多个，用英文状态下逗号隔开,先允许后拒绝
           1.
      2.
      3.
      4.
      5.
      6.
      7.
      8.
      9.
      10.
      11.
      12.
      13.
      14.
      15.
      16.
      17.
      18.
      19.
      20.
      21.

3、配置rsync同步的账户密码

     # vim /etc/rsync.pass    #配置文件，添加以下内容
rsync:123456    #格式，用户名:密码，可以设置多个，每行一个用户名:密码
           1.
      2.

4、赋权启动rsync

     # chmod 600 /etc/rsyncd.conf 
# chmod 600 /etc/rsync.pass 
# /etc/init.d/xinetd restart
           1.
      2.
      3.

服务端配置（数据源）

1、安装rsync

     # yum install rsync xinetd
# vim /etc/xinetd.d/rsync
service rsync
{
        disable = no    #修改为no
        flags           = IPv6
        socket_type     = stream
        wait            = no
        user            = root
        server          = /usr/bin/rsync
        server_args     = --daemon
        log_on_failure  += USERID
}

           1.
      2.
      3.
      4.
      5.
      6.
      7.
      8.
      9.
      10.
      11.
      12.
      13.
      14.

2、配置rsync同步的账户密码

     # vim /etc/passwd.txt
123456

# chmod 600 /etc/passwd.txt

           1.
      2.
      3.
      4.
      5.

3、测试手动同步

     # mkdir -pv /app/rsync_server && touch /app/rsync_server/test.txt
在rsync_server的/app/rsync_server目录下创建文件test.txt，在rsync_server端运行同步命令同步数据：

rsync -avH --port=873 --progress --delete  /app/rsync_client/ rsync@192.168.0.45::app_rsync_client --password-file=/etc/passwd.txt

注释：
/app/rsync_server/             #数据源的目录
-password-file=/etc/passwd.txt #数据源的密码文件
rsync@10.15.43.228::app_rsync_client #rsync目标端rsync服务端配置的用户名，app_rsync_client目标端rsync服务端配置的模块名称

检查客户端rsync_client目录

# ls /app/rsync_client/
test.txt
           1.
      2.
      3.
      4.
      5.
      6.
      7.
      8.
      9.
      10.
      11.
      12.
      13.
      14.

三、安装Inotify-tools实时触发rsync进行同步

这里可以参考github上的官方wiki文档（包含安装及配置使用示例）
https://github.com/rvoicilas/inotify-tools/wiki

1、下载安装Inotify-tools

     # uname -r        #Linux下支持inotify的内核最小为2.6.13
2.6.32-642.el6.x86_64

# 安装前要先下载epel源
# yum install inotify-tools -y

查看其程序是否安装成功
# rpm -qa inotify-tools
inotify-tools-3.14-1.el6.x86_64

查看程序包含的文件
#rpm -ql inotify-tools
/usr/bin/inotifywait
/usr/bin/inotifywatch
/usr/lib64/libinotifytools.so.0
/usr/lib64/libinotifytools.so.0.4.1
/usr/share/doc/inotify-tools-3.14
/usr/share/doc/inotify-tools-3.14/AUTHORS
/usr/share/doc/inotify-tools-3.14/COPYING
/usr/share/doc/inotify-tools-3.14/ChangeLog
/usr/share/doc/inotify-tools-3.14/NEWS
/usr/share/doc/inotify-tools-3.14/README
/usr/share/man/man1/inotifywait.1.gz
/usr/share/man/man1/inotifywatch.1.gz

           1.
      2.
      3.
      4.
      5.
      6.
      7.
      8.
      9.
      10.
      11.
      12.
      13.
      14.
      15.
      16.
      17.
      18.
      19.
      20.
      21.
      22.
      23.
      24.
      25.

2、配置inotify-tools

     # sysctl -a|egrep -i "max_queued_events|max_user_watches|max_user_instances"    #修改inotify默认参数（inotify默认内核参数值太小）
fs.inotify.max_user_instances = 128
fs.inotify.max_user_watches = 8192
fs.inotify.max_queued_events = 16384
fs.epoll.max_user_watches = 201420

# vim /etc/sysctl.conf 添加
fs.inotify.max_queued_events = 99999999
fs.inotify.max_user_watches = 99999999
fs.inotify.max_user_instances = 65535

#sysctl  -p   参数立即生效

# cat /proc/sys/fs/inotify/{max_user_instances,max_user_watches,max_queued_events}  #检查参数是否生效
65535
99999999
99999999


注释：
    max_queued_events：inotify队列最大长度，如果值太小，会出现"** Event Queue Overflow **"错误，导致监控文件不准确
    max_user_watches：要同步的文件包含多少目录，可以用：find /app/rsync_server/ -type d | wc -l 统计，必须保证max_user_watches值大于统计结果（这里/app/rsync_server/为同步文件目录）
    max_user_instances：每个用户创建inotify实例最大值
           1.
      2.
      3.
      4.
      5.
      6.
      7.
      8.
      9.
      10.
      11.
      12.
      13.
      14.
      15.
      16.
      17.
      18.
      19.
      20.
      21.
      22.
      23.

3、创建实时同步脚本

     # vim  /usr/local/inotify/rsync.sh
#!/bin/bash
src_dir="/app/rsync_server/"
dst_dir="app_rsync_client"
exclude_dir="/usr/local/inotify/exclude.list"
rsync_user="rsync"
rsync_passwd="/etc/passwd.txt"
dst_ip="192.168.0.45"
rsync_command(){
                  rsync -avH --port=873 --progress --delete --exclude-from=$exclude_dir $src_dir $rsync_user@$ip::$dst_dir --password-file=$rsync_passwd
}
for ip in $dst_ip;do
     rsync_command
done
    /usr/bin/inotifywait -mrq --timefmt '%d/%m/%y %H:%M' --format '%T %w%f%e' -e close_write,modify,delete,create,attrib,move $src_dir \
| while read file;do
   for ip in $dst_ip;do
       rsync_command
       echo "${file} was rsynced" >> /tmp/rsync.log 2>&1
   done
 done 

注释：
    src_dir="/app/rsync_server/"    #源服务器同步目录
    dst_dir="app_rsync_client"    #目标服务器rsync同步目录模块名称
    exclude_dir="/usr/local/inotify/exclude.list"    #不需要同步的目录，如果有多个，每一行写一个目录，使用相对于同步模块的路径；
    例如：不需要同步/app/rsync_server/"目录下的a目录和b目录下面的b1目录，exclude.list文件可以这样写
    a/
    b/b1/
    
    rsync_user="rsync"    #目标服务器rsync同步用户名
    rsync_passwd="/etc/passwd.txt"    #目标服务器rsync同步用户的密码在源服务器的存放路径
    dst_ip="192.168.0.45"    #目标服务器ip，多个ip用空格分开
           1.
      2.
      3.
      4.
      5.
      6.
      7.
      8.
      9.
      10.
      11.
      12.
      13.
      14.
      15.
      16.
      17.
      18.
      19.
      20.
      21.
      22.
      23.
      24.
      25.
      26.
      27.
      28.
      29.
      30.
      31.
      32.
      33.

      
##赋权，添加开机启动

# chmod +x /usr/local/inotify/rsync.sh
# touch /usr/local/inotify/exclude.list
# vim /etc/rc.d/rc.local
nohup /bin/sh /usr/local/inotify/rsync.sh &
# nohup /bin/sh /usr/local/inotify/rsync.sh &

           1.
      2.
      3.
      4.
      5.
      6.
      7.
      8.
      9.

4、测试

     在rsync_server（数据源）192.168.0.44的/app/rsync_server创建文件
# cd /app/rsync_server
# touch test{1..9}
# touch test{a..j}
# ls
test1  test2  test3  test4  test5  test6  test7  test8  test9  testa  testb  testc  testd  teste  testf  testg  testh  testi  testj

在rsync_client（目标端）192.168.0.45上查看已经同步
# cd /app/rsync_client
# ls
test1  test2  test3  test4  test5  test6  test7  test8  test9  testa  testb  testc  testd  teste  testf  testg  testh  testi  testj
           1.
      2.
      3.
      4.
      5.
      6.
      7.
      8.
      9.
      10.
      11.

如果以上测试都通过，说明inotify实时触发rsync同步脚本运行正常。
至此，Linux下Rsync+Inotify-tools实现数据实时同步完成。如果要双向同步可以把以上反过来部署一次。

FAQ

Q1:
#rsync -avH --port=873 --progress --delete /app/rsync_client/ rsync@192.168.0.45::app_rsync_client --password-file=/etc/passwd.txt

@ERROR: auth failed on module app_rsync_client
rsync error: error starting client-server protocol (code 5) at main.c(1503) [sender=3.0.6]

A：如果出现这个错误，请详细检查配置文件是否有误，建议删掉无用的注释

Q2:
#rsync -avH --port=873 --progress --delete /app/rsync_client rsync@192.168.0.45::app_rsync_client --password-file=/etc/passwd.txt

sending incremental file list
rsync: link_stat “/app/rsync_client” failed: No such file or directory (2)

A:检查客户端及服务端文件夹是否存在，这里应该还有一个坑，就是这里是在服务端(数据源)同步，目录应该指向“/app/rsync_client”

因此，如果是同步应用程序目录，建议这里的源目录，与目标目录设置为同一个。

mysql主从同步设置的重要参数log_slave_updates_ITPUB博客

Sat, 26 Jun 2021 14:39:24 CST

说明：最近部署了mysql的集群环境，详细如下M01和M02为主主复制，M01和R01为主从复制；在测试的过程中发现了以下问题：

1、M01和M02的主主复制是没有问题的（从M01写入数据能同步到M02，从M02写入数据能够同步到M01);

2、主从同步的时候，当从M01写入的时候，数据可以写入到R01；

3、当从M02写入的时候，数据就不能写入到R01；

问题的原因：log_slave_updates参数的状态为NO

mysql的官网说明如下：

Normally, a slave does not log to its own binary log any updates that are received from a master server. This option tells the slave to log the updates performed by its SQL thread to its own binary log. For this option to have any effect, the slave must also be started with the --log-bin option to enable binary logging. Prior to MySQL 5.5, the server would not start when using the --log-slave-updates option without also starting the server with the --log-bin option, and would fail with an error; in MySQL 5.5, only a warning is generated. (Bug #44663) --log-slave-updates is used when you want to chain replication servers. For example, you might want to set up replication servers using this arrangement:

A -> B -> C

Here, A serves as the master for the slave B, and B serves as the master for the slave C. For this to work, B must be both a master and a slave. You must start both A and B with --log-bin to enable binary logging, and B with the --log-slave-updates option so that updates received from A are logged by B to its binary log.

a) M01同步从M02同步数据过来的时候，log_slave_updates参数用来控制M01是否把所有的操作写入到binary log，默认的情况下mysql是关闭的;

b) R01数据的更新需要通过读取到M01的binary log才能进行更新，这个时候M01是没有写binary log的，所以当数据从M02写入的时候，R01也就没有更新了。。

问题的解决方法：

log_slave_updates：默认值为OFF;

Dynamic Variable：NO

处理方法：修改/etc/my.cnf，增加一行log_slave_updates=1，重启数据库后就可以了；

总结：设置完该参数后，数据库的架构就可以设置成M01和M02为主主同步，R01通过M01进行主从同步；

应用的写操作中M02上面进行，读操作中R01上面进行（如果读操作很多的话，可以在M01上面架设多台只读数据库），当M02发生故障后，系统的写操作自动迁移到M01上面。这种架构基本可以保证大部分公司的应用需求；

MySQL 数据库双向同步复制 - mindwind - 博客园

Sat, 26 Jun 2021 12:52:56 CST

MySQL 复制问题的最后一篇，关于双向同步复制架构设计的一些设计要点与制约。

问题和制约

数据库的双主双写并双向同步场景，主要考虑数据完整性、一致性和避免冲突。对于同一个库，同一张表，同一个记录中的同一字段的两地变更，会引发数据一致性判断冲突，尽可能通过业务场景设计规避。双主双写并同步复制可能引发主键冲突，需避免使用数据库自增类主键方案。另外，双向同步潜在可能引发循环同步的问题，需要做回环控制。

如上图所示，复制程序写入时也会产生 binlog，如何识别由复制程序产生的 binlog 并将其过滤掉是避免循环复制的关键。

原生 Dual Master 方案

MySQL 自身支持双主配置，但并没有去解决潜在的主键和双写带来的数据一致性冲突。对于双向同步潜在的循环复制问题，MySQL 在 binlog 中记录了当前 MySQL 的 server-id。一旦有了 server-id 的值之后，MySQL 就很容易判断某个变更是从哪一个 Server 最初产生的，所以就很容易避免出现循环复制的情况。而且，还可以配置不打开记录 slave 的 binlog 选项（--log-slave-update），MySQL 就不会记录复制过程中的变更到 binlog 中，就更不用担心可能会出现循环复制的情形了。

从 MySQL 自身的方案中可以找到切入点，就是如果能在 binlog 中打上标记，就有办法判断哪些 binlog 是复制产生的，并将其过滤。使用 MySQL 的方案则过于耦合 MySQL 的配置，在大规模部署的线上生产系统中容易因为 MySQL 配置错误导致问题。

自定义标记 SQL 方案

为了和 MySQL 配置解耦合，可以考虑一种通用的标记 SQL 方案。简单来说，就是在同步复制入库时插入特殊的标记 SQL 语句来标记这是来自复制程序的变更，这个标记 SQL 会进入 binlog 中。而在复制程序读取时，通过识别这个标记 SQL 来过滤判断。

binlog 中存储了对数据产生变更影响的的 SQL 语句，这些 SQL 语句组成了一段一段的事务，如下图所示：

绿色区是业务运行产生的正常事务，红色区是复制程序写入产生的事务，其中蓝色块是标记 SQL。标记 SQL 分别在事务开始后与事务结束前，标记 SQL 更新一张预定义的区别于业务表的标记表。那么每次复制程序去批量读取 binlog 内容时，可能存在下面 5 种情况，如下图所示：

批量读取范围全落在绿色区内。
批量读取范围起点落在绿色区，终点落在红色区。
批量读取范围起点落在红色区，终点落在绿色区。
批量读取范围起点和终点都在绿色区，但中间涵盖了一段红色区。
批量读取范围全落在红色区。

如上只有第 5 种情况，一个事务被拆成 3 段来同步。中间一段因为没有事务头和尾的标记，复制程序读取时将无法判断，导致循环同步，需要避免。通过把复制程序的批量读取范围固定设置为至少大于或等于写入的事务长度范围，避免了第 5 种情况。复制程序批量读取 binlog 日志事件时，通过标记 SQL 来过滤，避免了循环复制，实现了回环控制。

总结

本文考虑了在 MySQL 双主写入场景下双向同步复制的一些设计要点和制约。以原生实现为参考，给出了一种自定义实现方式的设计要点分析。而对于同库同表同记录同字段的同时两地变更，则必然引发数据一致性冲突，在复制同步层面无法区分哪边的更新为准。通常会考虑以最后时间戳来恢复到一致状态，但时间戳实际也会产生误差，此类场景不多见最好还是尽可能还是在业务场景设计上来规避。

参考

[1] MySQL Internals Manual. Replication.
[2] MySQL Internals Manual. The Binary Log. [3] in355hz. 数据库 ACID 的实现.
[4] jb51. MySQL 对 binlog 的处理说明.
[5] repls. 浅析 innodb_support_xa 与 innodb_flush_log_at_trx_commit.
[6] 68idc. MySQL 5.6 之 DBA 与开发者指南.
[7] csdn. 高性能 MySQL 主从架构的复制原理及配置详解.
[8] agapple. Otter 双向回环控制.

下面是我的微信公众号「瞬息之间」，除了写技术的文章、还有产品、行业和人生的思考，希望能和更多走在这条路上同行者交流。

使用logstash同步至ES的几个坑 - 一位帅气的网友的个人空间 - OSCHINA - 中文开源技术交流社区

Mon, 26 Apr 2021 15:52:26 CST

1.前言

记录使用logstash从sqlserver同步数据到ES中遇到的几点问题。使用的版本是es6.8.3+logstash6.8.3

2.logstash配置文件

2.1input

      input {
    jdbc {
        jdbc_driver_library => "/usr/local/logstash-6.8.3/logstashconfs/sqljdbc4.jar"#sqlserver的驱动jar包jdbc_driver_class => "com.microsoft.sqlserver.jdbc.SQLServerDriver"
        jdbc_connection_string => "jdbc:sqlserver://192.168.1.101:1433;databaseName=test;"
        jdbc_user => "sa"
        jdbc_password => "123456"
        jdbc_default_timezone => "Asia/Shanghai"
		jdbc_paging_enabled => "true"#分页record_last_run => true#记录上一次运行的值use_column_value => true#使用数据库中的字段追踪tracking_column => "update_time"#追踪的字段名称tracking_column_type => "timestamp"#追踪的字段类型last_run_metadata_path => "/usr/local/logstash-6.8.3/logstashconfs/sync-logs/consumer_statistics_update_time"#上一次运行的值存储的文件地址clean_run => false#使用数据库中的字段追踪statement => "SELECT * FROM v_test WHERE update_time>:sql_last_value and update_time<GETDATE() "#sql语句schedule => "*/5 * * * * *"#每5s执行一次}
}

statement

由于要查的数据是表关联的数据,一开始想的是建立多个jdbc,把数据存到es的不同的索引中,利用父子文档进行关联查询,

后来发现这种办法效率差,而且影响ES的性能,所以解决办法就是在sqlserver中建立好多表联查好的视图,

这里的 statement中的v_test就是创建好的视图.

由于设置了Logstash 增量更新, 必须要使用 update_time>:sql_last_value and update_time<GETDATE()这种限制条件,这样才可以保证数据不丢失也不重复

具体原因见: 如何使用 Logstash 实现关系型数据库与 ElasticSearch 之间的数据同步

schedule

网上的很多教程都说最小间隔是1min,实际上是可以做到秒级的.

schedule => "*/5 * * * * *"只要在前面再加一个* 单位就是秒,这里就是每5s执行一次

2.2filter

      filter {
	if ![test]{ruby{code =>'event.set("test","")'}}	
	mutate{
		convert => { "id" => "integer" }
		remove_field => ["@timestamp"]
		remove_field => ["@version"]
	}
}

这里主要是对从sqlserver数据库查出来的数据进行一些处理,我这里删去了大多数的内容,仅保留一些代表性的.

if ![test]{ruby{code =>'event.set("test","")'}}

这个的意思是 test字段为null时,使用ruby这个语言进行处理, code =>''这里面就是写代码的

event.set("test","")意思就是设置test字段的内容为""

当然我们也可以先 event.get("test"),获取test字段的内容,然后在进行一系列处理后,再 event.set,这样就可以保存处理后的字段的值

ruby语言的具体语法可以参考这个: Ruby教程

convert => { "id" => "integer" }

这个的意思就是将id字段的类型转化为integer,如果某个字段是时间类型可以转化为timestamp类型

2.3output

      output {
		elasticsearch {
			hosts => ["htkj101:9200","htkj102:9200","htkj103:9200"]
			index => "consumer_statistics"#索引名称document_id => "%{id}"#索引的iddocument_type => "consumer_statistics"#索引的type,这个在6.x版本以后就已经被废弃,可以忽略这个template_name => "consumer_statistics"#索引模板的名称}
}

document_id => "%{id}"

文档的id就是导入数据的id,这样设置可以实现幂等性

template_name => "consumer_statistics"

索引模板的名称 consumer_statistics,ES会调用模板名称为 consumer_statistics创建索引.

当然前提是你得先创建好这个模板

3.索引模板的创建

指令

      curl -H "Content-Type: application/json" -XPUT http://htkj101:9200/_template/consumer_statistics -d '在这里输入你创建的模板'

模板

      {
	"template": "consumer_statistics",
	"order": 2,
	"version": 60001,
	"index_patterns": ["consumer_statistics"],
	"settings": {
		"index": {
			"refresh_interval": "5s",
			"max_result_window": "2147483647"#设置from+size的最大值}
	},
	"mappings": {
		"_default_": {
			"dynamic_templates": [{
				"message_field": {
					"path_match": "message",
					"mapping": {
						"norms": false,
						"type": "text"
					},
					"match_mapping_type": "string"
				}
			}, {
				"string_fields": {
					"mapping": {
						"norms": false,
						"type": "text",
						"fields": {
							"keyword": {
								"ignore_above": 1024,#设置不被索引的字段长度"type": "keyword"
							}
						}
					},
					"match_mapping_type": "string",
					"match": "*"
				}
			}],
			"properties": {
				"@timestamp": {
					"type": "date"
				},
				"geoip": {
					"dynamic": true,
					"properties": {
						"ip": {
							"type": "ip"
						},
						"latitude": {
							"type": "half_float"
						},
						"location": {
							"type": "geo_point"
						},
						"longitude": {
							"type": "half_float"
						}
					}
				},
				"@version": {
					"type": "keyword"
				}
			}
		}
	},
	"aliases": {}
}

"max_result_window": "2147483647"

在业务处理的过程中往往需要分页,ES的JAVA-API是通过from,size来设置分页数量和每页的数量,

在默认的情况下from+size必须要小于10000,但是如果实际需求大于10000,则必须在这里设置

我这里设置的是 max_result_window的最大值,实际情况中不需要设置如此之大,

因为ES会在内存中进行排序,如果一次返回的结果过大,可能会导致服务宕机.

"ignore_above": 1024

这里默认是256,意思是如果某一个字段的内容超过256字节的话,那么将不会被索引.

也就是说从ES中是能够看到这条数据的存在,但是如果你指定查询条件,是查不出来的.

举个例子,现在ES中有id,test两个字段,一共100条数据

test字段中只有一条数据超过了256字节,现在我查询test字段中包含"1"的数据,

即使这个超过256字节的数据含有1,但是也不会被查询到.

为了能够让他被索引到,这里将256改成1024,即只有超过1024字节才会不被索引.

完整命令

      curl -H "Content-Type: application/json" -XPUT http://htkj101:9200/_template/consumer_statistics -d '
{"template":"consumer_statistics","order":2,"version":60001,"index_patterns":["consumer_statistics"],"settings":{"index":{"refresh_interval":"5s","max_result_window":"2147483647"}},"mappings":{"_default_":{"dynamic_templates":[{"message_field":{"path_match":"message","mapping":{"norms":false,"type":"text"},"match_mapping_type":"string"}},{"string_fields":{"mapping":{"norms":false,"type":"text","fields":{"keyword":{"ignore_above":1024,"type":"keyword"}}},"match_mapping_type":"string","match":"*"}}],"properties":{"@timestamp":{"type":"date"},"geoip":{"dynamic":true,"properties":{"ip":{"type":"ip"},"latitude":{"type":"half_float"},"location":{"type":"geo_point"},"longitude":{"type":"half_float"}}},"@version":{"type":"keyword"}}}},"aliases":{}}'

在创建模板的过程中,发现总是创建失败,后来发现弄成这样的两行,就不会出错了.

数据同步工具 Elasticsearch-datatran v6.2.9 发布

Mon, 19 Apr 2021 22:33:41 CST

数据同步工具 Elasticsearch-datatran 6.2.9 发布， Elasticsearch-datatran 由 bboss 开源的数据同步迁移工具，支持在Elasticsearch、关系数据库(mysql,oracle,db2,sqlserver、达梦等)、Mongodb、HBase、Hive、Kafka、文本文件、SFTP/FTP多种数据源之间进行海量数据同步；支持日志文件实时增量采集到kafka/elasticsearch/database。

Elasticsearch版本兼容性：支持各种Elasticsearch版本（1.x,2.x,5.x,6.x,7.x,+）之间相互数据迁移

v6.2.9 功能改进

数据同步改进：完善ip2region和geoip数据库热加载机制
Restclient改进：升级httpcliet组件版本到最新的官方版本4.5.13
Restclient改进：升级fastxml jackson databind版本2.9.10.8
Restclient改进：增加对elasticsearch pit机制的支持，参考用例：

testPitId方法

https://gitee.com/bboss/eshelloword-spring-boot-starter/blob/master/src/test/java/org/bboss/elasticsearchtest/springboot/SimpleBBossESStarterTestCase.java
数据同步工具扩展：增加日志文件采集插件，支持全量和增量采集两种模式，实时采集日志文件数据到kafka/elasticsearch/database

使用文档： https://esdoc.bbossgroups.com/#/filelog-guide

日志文件采集插件使用案例：
之前版本升级6.2.9注意事项，需手动修改增量同步状态表结构，增加下面三个字段：
```
     status number(1) ,  //数据采集完成状态：0-采集中（默认值）  1-完成  适用于文件日志采集 默认值 0
filePath varchar(500)  //日志文件路径，默认值""
fileId varchar(500)  //日志文件indoe标识，默认值""
```
Restclient改进：设每个elasticsearch数据源默认版本兼容性为7，为了处理启动时无法连接es的情况，可以根据连接的es来配置和调整每个elasticsearch数据源的配置，示例如下： elasticsearch.version=7.12.0
调整gradle构建脚本语法，保持与gradle 7的兼容性
Restclient改进：elasticsearch节点自动发现和故障节点健康检查后台线程模型调整为daemon模式
http-proxy改进：http-proxy节点自动发现和故障节点健康检查后台线程模型调整为daemon模式

超3亿活跃用户的多活架构，数据同步与流量调度怎么做？ - 架构 - dbaplus社群：围绕Data、Blockchain、AiOps的企业级专业社群。技术大咖、原创干货，每天精品原创文章推送，每周线上技术分享，每月线下技术沙龙。

Thu, 01 Apr 2021 14:05:21 CST

一、多活业务架构

1、OPPO多活架构原则

第一，主线多活。

多活成本比较高的，双活是两倍，三活可能成本会低一些，但三活的难度更大。因此没有办法对所有业务进行多活，只能对主线做多活。

第二，是保障多数用户。

举个例子，系统有个充值的功能，充值功能本身是强一致的，完全不能允许任何的延迟或者是副本的读。

但是多活切换之后，只有少数用户在切换的前几分钟有充值的，这部分用户余额可能没有通过过去，只需要对这部分用户进行服务降级，其他绝大多数用户是可以使用完整的服务的。

第三，数据分类，应用不同的CAP模型。

CAP定理不是针对的业务功能，比如说账号、支付、登录，CAP定理是对数据的要求。一个功能可能用到多个数据，数据本身的一致性、可用性、延迟的容忍是不一样的。

所以需要对业务功能用到的数据进行分类，比如余额数据、流水数据、日志数据、个人资料数据……我们对每个数据进行一致性、可用性的需求分析，一致性要求很强，这个数据就选用同城高可用的数据库服务。这个数据一致性要求不高、允许延迟，就可以选择异地高可用的数据库服务。

所以这个业务来说不是整体使用一个CAP模型，在业务内部，因为不同的数据分类，使用了不同的模型，因此业务有时候存在部分降级的情况。

第四，平台业务SDK化。

OPPO的业务比较多，比如浏览器、软件商店、广告务、音乐、视频等非常多的业务，这些业务都用了平台化的服务，比如评论系统、消息系统，还有账号鉴权的系统等等。

OPPO公司的机房比较多，主要的就有好几个机房，我们的上层业务是分布在不同的机房里面去，这对平台业务来说就比较麻烦，上层业务可能只需要做双活就行了，而平台业务可能就要做七活、甚至八活，而且七、八个机房都要有读和写，难度就非常大。

为解决这个问题，我们提出平台业务进行SDK化思路，把这种平台型业务，拆分成独立的域名，从SDK开始拆分，这样我们平台业务只需要单独做多活就行了，不需要在每个机房都提供读写的能力。

第五，数据最终一致。

第六，我们的记录日志、流水，避免修改、计数操作。

2、同城多活业务架构

上图是典型同城多活的业务架构，应用层是完全无状态的，随便打流量。四层采用DPDK技术开发，七层包括Nginx和API网关两个组件，Nginx只用来做SSL卸载、WAF防火墙，其他功能都是API网关来提供。

数据层以主备为主，写流量只会写到Master节点，但是读的流量可以访问slave节点，但是也不一定，看业务本身数据一致性要求，如果要求非常强一致的，我们的读也只会指向Master节点。

需要注意，我们把Nginx和API网关都放到同一个容器中，两只之间采用进程间通信。这样的好处是，我们扩容的时候，我们可以将整个七层同步去扩容，而不会存在某一层组件容量不足的情况。

另外就是注册中心，我们没有使用 k8s本身的一个注册功能，而是自己基于数据库，实现了AP模型的注册中心，保证注册中心的跨机房高可用。同时注册中心兼容Consul协议，从而更好的融入开源生态。多个k8s集群的实例，都会注册到统一的注册中心里面去。这个注册的动作，是由发布平台完成的，好处是应用发布的时候，发布平台可以提前摘掉流量，避免重启影响服务的成功率。

3、异地多活业务架构——单元化

异地多活，比较典型的架构是单元化，就是将用户进行分片，将不同的用户分片放到不同的机房里面去，这样可以做到一个完全的扩展，随着用户规模的增加，我们可以很容易去扩展机房的数量，这些都可以持续的去增加的，包括每个机房的容量也可能不一样。比如有的机房大，有的机房小，我们可以调整每个机房存放的单元数量。

这里确实实现了多活，每个机房都有流量，每个机房也是读写，是完全的多活，但是单元高可用的问题如何解决，单元的归属机房故障了，如果把这个单元转移另一个机房继续提供服务。

4、异地双活业务架构

上图是我们使用较多的异地双活架构，首先我们将用户按照地域维度进行了一个单元划分，比如说按照地域将用户划分为七个大区单元。

注意这个单元划分是用户首次访问服务的时候进行的，然后客户端就保存了单元号，就不会产生变化了，所以用户出差，换到因为另外一个地域里面去，它所属的单元号我们是不会变化的，还是访问单元归属的机房，这个时候可能就不是访问最优的机房。

这样的好处是，当一个用户移动的时候，数据访问就不会在两个机房之间跳来跳去，避免双向同步的数据冲突问题，很容易实施。

数据层在两个机房，都是完全全量的，两个机房间数据是做双向同步，没有谁是主谁是从的区分，是完全对等的架构。

用户流量调度按单元进行，这样可以保证一个用户，他只会访问其中一个机房，不会在南北两个机房之间跳来跳去，就算是用户出差也是如此，按照首次访问服务时的地域来划分的单元。只要我们的调度规则没有变更的情况下，一个用户他永远只会在其中一个机房读写，这样的好处就是，第一个可以避免我们的同步的冲突，第二个好处就是容忍了数据延迟的情况，比如说一个用户他永远是看到北方机房，南北之间数据同步的延迟日常情况下其实是感知不到的。

这个架构是非常简单，只需要在客户端网络库里面做一些封装，对用户进行单元划分，按单元进行流量调度就可以了，双向同步比较好实施，延迟、冲突，这些问题都可以避免。

除了地域之外，也可以按照账号或者设备来划分单元。按账号或者设备划分单元的好处是，如果按照地域划分单元，在用户删除手机APP这种情况下，APP里面保存的单元号就没有了，下次访问服务的时候就需要重新分配单元号，因为地域可能和之前不同了，就可能分配到不同的单元号，按账号或者设备划分就没有这个问题，重新分配还是原来的单元号。

前面说到，南北机房的数据层都是全量的，一般情况下，按地域的划分单元的模式，就算重新分配了单元号，也不影响数据的读写访问。

5、异地双活——评论系统案例

上图是平台型业务-评论系统异地生活的案例，评论系统从SDK开始，就进行了域名拆分，避免了在业务域名所在机房内部去做跨机房的评论服务调用，影响服务的可用性和性能。

如上图所示，我们只对MySQL原始数据层做了南北双机房同步，第二层的评论元数据表，还有第三层的一个Cache，这两层实际上没做同步的。两个机房分别基于MySQL数据独自去重建第二层的元数据表，第三层的Cache，以及重建其他的数据源。

这样好处就是，我们只有一个数据源做了南北机房的同步，就可以避免双数据源同步的时候，两个数据源之间会存在同步的进度不一致，从而两个数据源之间的依赖关系出现问题。

举个例子，我们上面的评论表、点赞表这一层，最上面这一层做了同步以后，我们中间第二层如果也做了同步，然后第二层同步以后，两个数据可能存在差异，比如说第一层同步快一点，第二层同步得慢一点，同样是南方的用户，他们看到这个数据之间的存在不匹配的问题。

因为用户流量调度是按单元进行的，两个机房的数据虽然有差异，有延迟，但是用户感知不到的。一个用户要么看到南方机房，要么看到北方机房，我们评论数量两个机房有差异，点赞数量有差异，回复数都有差异，但是无所谓，用户是感知不到差异的。需要注意的一点，就是当多活切换的时候，用户能感知到一个差异，但日常情况下用户感知不到这个差异。

6、异地N活业务架构

上图是比较复杂异地N活业务架构。它基本的思路就是对用户进行两级的划分。第一级按照设备和账号划分单元，其中单元里面既有登录的用户，也有未登录的用户。

在第二级划分的单元内部，我们再应用异地双活的模式，或者是同城多活的模式，比如说左边单元1，按照地域做第二级的划分，把它划分成南北两个副本，既然是副本，肯定数据是全量的，是异地双活模式，两个副本数据做双向同步，这种模式适用非强一致的业务。

那么强一致的业务怎么办呢？比如右边的单元4，跨同城的两个机房，单元内部采用同城多活的模式，就是共享跨机房高可用的数据层，是主备的的。这种模式适合强一致的业务。

前面说了单元内部主要两种模式，第一种是异地双活，双向同步，主主模式，读写在本机房，然后做双向同步；第二种是同城多活，主备的模式，跨机房共享主备切换的数据层。除此之外，单元内部还可以选择主从，冷备等模式。

7、服务部署

上图是服务部署架构。服务部署分为几大部分。

第一部分是中心域。

中心域主要是部署一些运营管理后台，还有一些爬虫，还有一些非常长尾的应用，但这些业务可能不太重要，也不需要做一个多活。中心域的读写都是在中心机房，然后把数据单向同步到其他单元机房。

第二部分是全局域。

全局域主要存放非单元分片维度的数据，比如评论、消息等。这些数据不能按统一维度进行拆分，需要全量的访问，放到全局域的数据都是全量的。

第三部分是单元域。

存放按单元拆分的数据，比如用户订单、收藏、下载记录等。

8、服务路由

用户会先请求到API网关，API网关根据请求的单元号参数，判断是是否访问错了机房，如果访问错了，就做重定向，或者跨机房转发，用户自己选择的其中一种模式。转发的模式比较依赖于两个机房之间的专线的带宽和稳定性，重定向模式机房之间的带宽要求会低一些，客户端重新发起请求，这两个机房之间的网络专线要求低一些。

前面说到用户首次请求的时候，会给客户端分配一个单元号，这个单元号将会存储起来，以后每次业务请求都会带上这个单元号。

请求到了单元内部，单元号会做一个全链路的传递，全链路传递是通过调用链来实现的，调用链可以把一些参数做全链路的传递。应用实例打上了单元号的标签，微服务调用方通过单元号对实例进行筛选，防止请求打到其他单元。

数据访问层要做一个兜底的操作，可能由于服务路由还是其他的一些原因，不小心访问错了单元，这个数据层有可能访问错，所以数据访问层要做一个兜底，根据传过来单元号，做拒绝或者转发。

9、用单元化解决业务扩展性问题

单元化不只是可以用来解决多活的问题，也可以用来解决业务扩展性问题。在一个机房内部，如果服务1000万用户，他可能需要10个数据库，服务1亿个用户，需要100个数据库，如果100个数据库让每个应用实例都连上的话，连接数就太多了。

可以在一个机房内部也拆分多个单元，每个单元保证1000万、2000万左右的用户，随着用户的增长，我们再将单元数量进行增加就行了，这样就可以保证每一个单元内部的服务规模受控。

二、多活数据同步

1、MySQL同城多活

上图是MySQL同城多活架构，MySQL对外看上去是一个集群，只有一个IP。我们需要解决的问题是：怎么让跨机房的集群看到的是同一个IP？这里就用到了Anycast技术，IP的作用可以理解为域名，我们把一个 VIP用Anycast技术，将它路由到两个机房，或者是三个机房。我们是路由到三个机房，然后就到了机房内部，再通过 ECMP协议将流量再分到多个四层负载均衡节点。

通过Anycast第一层路由到不同的机房，第二层的ECMP再路由到基于DPDK技术开发的四层负载均衡节点。这样我们整个的数据库对外看到的VIP就是同一个了，所有机房看到VIP都是同一个。利用Anycast和ECMP两个技术，实现跨AZ共享VIP。

然后是数据层，数据层我们现在是一主三从，然后需要2个以上slave同步成功，才能完成最终的成功。

MySQL版本需要5.7以上，操作系统内核需要打一个 toa补丁，这样经过四层负载均衡之后，MySQL Server才能拿到真正来源IP。因为我们这边要做一个IP白名单的授权，如果不打补丁，拿到的来源IP就是四层负载均衡的IP，就没法做IP白名单授权了。当然top补丁有一个缺陷，就是只能支持ipv4，这在内网使用问题不大。

底层采用了开源的MySQL拓扑管理组件，通过检测我们数据库节点的情况，然后做重新选组做切换，然后通知SLB改变后端指向，流量打到新的master节点，

Anycast不是必须的，也可以用域名代替，但是域名有个问题，需要重新接连的时候才会发起解析，所以域名切换的时候可能会切不干净。Anycast做切换是立即生效的，因为这是路由协议的一个变更，马上就能切过去，不存在解析不干净和生效不一致的问题。

Anycast除了内网之外，外网也用的比较多，比如说谷歌上负载均衡器，它发布的IP就是Anycast的IP，在公网环境下，在不同的地区路由到不同的一个真实地址，包括我们 DNS Server也是用Anycast去发布的，在不同的区域，路由到就近的IDC，所以Anycast技术应用还比较广泛。

2、MySQL异地多活

上图是MySQL的异地多活架构，重点在于提升同步的性能，从源库订阅到数据以后，不是直接写目标库，而是先存起来，在目标机房部署中继日志模块。这样的好处是，我们可以在网络上快速的传输过去，中继日志并行去写目标库。

这个设计性能提升非常大，OPPO实际业务场景下，这个模式比订阅后直接写目标库提升了几倍。因为引入了中继日志，就存在两阶段提交的问题。比如中继日志写成功，但是中继日志写目标库没有成功。这就存在数据一致性问题，需要用到两阶段提交。

还有就是数据压缩和加密，对数据的安全和同步性能也非常重要。

然后是多消费者支持，订阅模块会保存数据，每个订阅方可以维持自己的消费位点，彼此之间没有干扰，从而减少多订阅方同步对 Source DB的压力。

3、MySQL订阅——数据最终一致

以前面提到的评论系统为例，数据同步只同步MySQL那一层，而其他的数据源Cache、MQ、ES、排序服务等，分别订阅MySQL binlog重新构建。

原则上，我们尽量只同步底层的一份MySQL数据，其他数据源订阅MySQL重建。前面说到，MySQL只需要订阅一次，Jins程序自己存储了一份数据到本地文件队列，然后分别重放到Cache、MQ、ES等其他数据源，也可以多次重放数据。

如果多数据源分别进行同步的话，多个数据源同步的进度是没法保证协调一致的，必然有的数据源快，有的数据源慢，这有可能导致两个数据源之间的关联关系出现一些程序错误。所以我们尽量只同步一个数据源，再基于MySQL重建其他的数据源，避免进度不一致的问题。

4、MySQL数据对比&修复

OPPO的业务场景，很多地方都非常依赖底层的 MySQL数据同步，两个机房之间之间到底有没有差异，是蛮重要的。

因此我们设计了一个独立的MySQL比对修复工具，就执行上图这样一个SQL语句，通过这个SQL语句，对一段时间之内的所有数据算一个异或的值，通过异或值去比对两个机房之间数据差异，如果比对有差异，我们再缩小比对范围，逐步逼近到差异的记录行，这个语句的执行效率还是蛮高的。

但是这个方案有个不足，要求我们数据库里面有一个时间戳的字段，程序会对比前一个周期内的所有记录的异或值，判断两个机房之间数据是否有差异。

另外一重要场景就是数据修复，因为业务可能配置错了数据库、应用实例配置生效不一致，再比如A单元数据写到B单元，这个时候需要修复数据，通过这个工具，把两个数据库不一致的数据行整理出来，然后人工做识别或者批量修复。

5、Redis多活

Redis同城多活的架构如上图所示，我们在Redis Server上面做了一层代理，下层Redis Server没有使用Redis cluster技术，代理将流量进行分片，分发到了不同的Redis Group里面去，每个Group里面就是普通的Redis主从。

主从之间采用binlog的同步，因为Redis本身没有binlog，我们把 AOF做了改造，把让它变成binlog的这种格式，这里改造的工作量不大。

然后代理也支持两种模式，一种是重定向模式，一种是转发模式。转发模式就是写主读从，它只会把写流量转到了主机房里面去，但是从机房是能读的。重定向模式就不一样，重定向模式是非常更强一致的，读写都只能在主机房。

前面反复提到，CAP是针对数据的，是指数据本身的延迟或者差异的容忍度，所以这两种模式都需要支持，有的数据它就是要强一致，一定要到主库里面的去读，但有的数据它允许从库读，允许延迟。

异地多活也很简单，异地多活两个机房各部署一个组件去订阅同机房的Redis，订阅Redis的binlog，订阅的数据写到MQ里面去，两个机房分别重放binlog，实现起来并不复杂。

最后简单说一下binlog的格式，里面包括了命令、数据产生的机房、递增的序号，还有一个时间戳。还需要注意的一点，Redis持久化RDB也要改造一下，RDB需要包含一个 binlog offset，binlog读取偏移量，需要把它记下来，因为主从颠倒的时候，我们订阅程序要重新从offset开始继续订阅下面的命令。

三、GSLB流量调度

1、Http DNS

最后讲我们的GSLB流量调度，首先是为什么要使用Http DNS。

第一个是防劫持。

DNS劫持，DNS是多级缓存，部分环节存在解析劫持的情况。

DNS黑洞，这个大家可能遇到比较少，什么叫DNS黑洞呢？就是运营商监控到某个域名有恶意的请求，封杀他的时候不小心扩大了封杀的范围，我们已经出现过几次这种情况，有时候某个地区甚至可以把整个cn顶级域名全封杀，这种封杀的范围很大，称之为DNS黑洞。整个2020年已经发生过多次这种情况了，某个地域整个顶级域名都给你封杀掉，大家都解决不了。

第二个是快速生效。

首先是DNS本身的多级缓存，这个时间不受控制，但它可能不是主要问题，更主要的问题是客户端长连接。

我们还没上Http DNS之前，业务使用了客户端长连接，需要20分钟甚至一个小时才能大部分流量调度走。主要的原因就在客户端长连接，DNS做了变更以后，只有客户端重新发起连接的时候，它才会发重新发起解析，才拿到新的IP，如果连接没断开，就一直不会转移，所以这部分长连接用户根本就切不走。

如果是机房入口网络故障还好，连接天然会断开，如果是因为业务自己的问题，需要把流量切走，这种情况下就会发现根本切不走，所以客户端长连接是比较重要的问题。所以客户端网络库需要处理一下，解析变更的时候，需要主动去关闭连接，但是传统DNS，没有解析变更的通知机制，不发起解析就不知道解析变更了，这里就进入了循环了，需要仔细的思考一下流程。

第三个是精准调度。

传统的DNS解析只能获取到IP这一个参数，首先IP信息不准确，包括运营商归属、地域归属，都不是很准确，国外运营商特别多，情况更严重。现在IPv6也在快速的推广，信息不准确的情况更为严重。其次传统DNS无法做到用户维度、设备维度的解析。

最后是生效一致性。

单元一旦发生调度以后，在单元内的所有用户要同时调走，不能说一部分先调走，一部分后调走，这样数据写入就乱了，需要保证全体用户生效的一致性。

2、单元调度

下面讲单元调度的主要流程

第一步: 划分用户单元

划分用户单元主要有三种模式：

按设备划分单元；
按账号划分单元；
按地域划分单元。

这里有个地方需要注意，我们为了划分单元，客户端肯定要传一些参数，如果按账号划分单元，需要传账号ID；按设备划分单元，需要传设备的IMEI,或者国内Android厂商推行的OpenID；按地域划分单元很简单，直接从IP里面可以获取，不用客户端传递参数。

因为隐私合规要求，比如说海外业务，直接传用户的ID或设备信息，是违规的，因为我们这个调度的域名它是一个独立的域名，它不是业务本身的，这个域名很难跟用户解释，即使跟用户签了协议，因为业务主体的不同，可能也不一定包含了这个域名，所以我们做了一个匿名化处理，设计了两个新参数，一个叫ADG（匿名设备分组），一个叫AUG（匿名用户分组）。

我们将账号ID和10万取模的值定义为AUG,设备ID与10万取模的值定义为ADG。通过这种方式，把设备和账号分成10万个桶，然后对桶分单元，比如说1~5000桶是单元1，5000~1万桶是单元2。这样我们就不用传真实的设备ID和真实账号。

第二步：客户端获取单元号。

客户端首次访问业务的时候要分一个单元号，这样就算按地域划分单元，基本上也不会出现变更，只要用户的APP不被删除，我们OPPO手机的好处就是，我们的APP是不怕被删除的，我们的数据不会被清掉；但如果是一个外发的APP，可能就存在APP删除，这个可以考虑用设备或者账号分单元。获取到单元号之后，就永久保存在客户端。

第三步：客户端解析域名IP。

域名解析的时候会带上单元号的参数，获取这个单元对应的IP列表，然后客户端缓存IP列表。需要注意的一点是缓存机制，建议根据网络环境进行缓存，比如WiFi名称，或者运营商的名称，底层的缓存数据结构就是域名加上网络环境的名称。这样的好处就是，用户网络切换的时候，比如说家里面是WiFi，我们拿的是IP1，我们一出门，网络环境变了，我们取出的缓存IP就是IP2，在每个网络环境都是缓存最优的IP。

另外一点需要注意是：我们为每个单元还分配了一个单元域名，这是一个传统DNS域名，主要是降级的时候使用。可以设想一下，如果我们没有为每个单元单独分配一个传统DNS域名，一旦降级的时候就会走到业务的主域名，而传统DNS是不能携带任何参数的，无法做到按单元进行解析，用户流量就全都乱了。

所以每个单元分配一个域名的好处就是，降级的时候只要降级到我们这个单元的域名，这样大多数用户解析结果还是准确的，不准确的一部分通过API网关重定向或者内部转发，只要很少用户需要走这个路径，绝大多数用户还是最佳的路径。

第四步：客户端重定向。

因为调度过程当中还有一部分用户在访问旧的IP，我们是通过API网关，把新机房IP直接告诉客户端，客户端立即用新IP重试，并且异步去刷新解析，如果只是反馈一个状态码，告诉客户端需要重新刷新解析，客户端的总请求时间就会拉得比较长，这就是重定向模式。

但除了重定向模式，还有转发模式，但是转发模式比较依赖机房之间的专线带宽和稳定性，如果公司规模不是很大的话，机房之间的专线带宽和稳定性可能赶不上公网，重定向模式可能更适合一些。

3、单元调度注意事项

数据层联动，举一个用户余额充值的例子，这是非常强一致的，我们可以维护一个数据不一致用户清单，比如说有用户刚刚进行了充值，这个数据还没在各个机房达成一致，机房调度的时候，只是这一部分用户需要进行服务降级，其他用户还可以继续提供完整的服务。

4、域名解析刷新时机

接下来讲域名解析刷新时机。因为HttpDNS是直连解析的，不像传统DNS有多级的缓存，如果我们还沿用传统DNS的 TTL方式来刷新解析，这个TTL就不能设置的太短，太短了HttpDNS Server的压力非常大。TTL设置过长又不能满足业务快速恢复的要求。

所以域名解析的及时刷新依赖另外两种途径，第一种途径是失败。我们请求一个服务，要么连接错误，要么响应内容出现错误，比如说我们响应了500，或者其他我们认可的一个响应值（客户端可以自己定一个规则），我们访问失败的时候，就需要立即去刷新一下域名解析，因为请求失败的时候可能需要做一个机房调度，不管是业务后端出现了问题，或者是连接不上，这种情况都需要做机房调度，需要客户端刷新解析。

第二种途径是指令，如果是因为我们带宽不足，做活动，或者其他原因的，需要把流量切走，这时我们可以通过API网关下发指令，下发指令也是随着API网关的正常的业务请求，响应Header带下去，不是单独的通道，也不是通过Push推送。

这样我们就可以兜底，要么会请求失败，会立即刷新解析。要么请求成功，响应header就会携带指令。所以用户一定能走到失败和指令其中一条路径。因此我们做了调度变更以后，用户一定会刷新，不再依赖TTL了，过期时间可以设置非常长，这样我们绝大多数请求，都不会发生真正的解析请求。

通常情况下，传统DNS有2%~3%的解析失败率，还是挺高的。通过这种方式，我们就可以把解析成功率做到99.5%以上，日常情况下甚至能做到接近100%。

5、调度生效一致性

下面讲一讲调度生效的一致性，当我们的客户端降级到传统DNS的时候，就会解析到错误的机房，在调用生效过程当中，也会访问到旧的机房，所以我们在API网关会做一个拦截，因为每个请求都带上了单元号，API网关就可以判断这个请求是否请求到了正确的机房，如果请求错了机房，API网关把请求定向单元当前归属的机房。

定向用户请求有两种模式，一种是转发模式，API网关直接转发到新机房的业务后端实例。另一种是重定向模式，API网关在响应header携带了重定向指令，以及新机房的IP（避免客户端多一次的请求），客户端立即重试新IP。

转发模式需要消耗较多的机房专线带宽，重定向模式的总体时长更高，业务可以自由选择两种模式。

解析刷新采用并行跑马的模式，客户端会并行请求两个HttpDNS Server和一个传统DNS，三个请求同时发出去。如果HttpDNS Server请求成功，哪个先到就用哪个，如果两个HttpDNS Server请求都失败，就使用传统DNS解析结果。因为每个单元都分配一个传统域名，所以传统DNS解析结果和HttpDNS解析结果也基本是一致，只有极少数用户会解析错误，API网关重定向一次以后也能纠正过来。

6、调度决策大脑

调度决策大脑会收集很多路的原始监控数据，比如客户端调用链的数据、外网拨测平台的数据、机房网络监控的数据等等，多路数据汇总到决策大脑里，进行比对分析，得出故障的结论。

调度决策大脑一定要依赖多路监控数据源，因为单路数据的质量无法保证，比如可能会出现拨测用例配置错误、网络监控数据丢失等，所以单路数据都是不可信的，需要多路数据源做交叉的比对，过滤抖动、防止误判。

调度决策大脑最终会输出一个指令，指令只会告诉你故障类型，比如：机房故障、运营商线路故障、机房之间网络（DCI)故障，或者是容量不足、业务自身出现了问题等。业务自身出现问题，比如业务的数据库故障，也需要切到另外的机房去。

决策指令同时发到两个地方，既要发给接入层，也要发给数据层，为什么需要这样呢？

假设我们同城两个机房之间，专线出现了故障，两个机房的数据库肯定达不成一致，同步不过去了。这个情况下，假设我们的数据库选主B机房，而接入层保留A机房， A机房的数据库完全写不进去，即使写进去也是错误的，这里我们要保证数据层和接入层两边选择的机房要一致。

所以这种专线故障情况下，我们是调度决策大脑来通知，做统一的决策，同时通知接入层、数据层做联动，选择同一机房，这个主机房的选择是事先配置好的，它不是由我们刚刚说的Raft组件来解决的。

7、调度效果

上图是我们9月份做过的一次机房调度的效果，基本上做到分钟级（实际上是秒级的）的生效，是很陡的一个曲线。

四、总结

最后，给大家总结一下今天分享的内容：

>>>>

Q&A

Q1：Http DNS也有缓存的吧？

A1 ：对，刚刚提到我们Http DNS缓存时间非常长，缓存了一周的时间，而且缓存的时候是根据环境来缓存的，就是按照 WiFi名称、运营商的名称来做缓存，这样网络切换的时候可以拿到最优的IP。

缓存的时间非常长，是因为域名解析的刷新，是不依赖缓存过期的，如果能请求成功，API网关在响应Header就会带上调度指令，如果请求失败客户端也会主动去刷新解析。因此解析的刷新，是不依赖缓存过期时间的。

Q2：同城多活网络是怎么配置的？两个机房使用相同的ip地址，还是不同的？

A2 ：对于跨机房高可用的数据库来说，用户看到的是同一个IP，第一层使用Anycast路由到机房，第二层使用ECMP路由到多个四层负载均衡节点，单个四层负载均衡的流量扛不住，四层负载均衡是一个集群，通过ECMP实现流量分发。

多余入口流量来说，前面架构图可以看到，接入层在两个机房从四层、七层都是独立的，接入层有2组出口IP，如果其中一个机房运营商线路出现问题，根据调度决策系统的指令，自动停止该运营商线路的IP解析。

Q3：老师能介绍一下多活带来什么业务收益吗？是什么契机促使 OPPO开始做异地多活？

A3 ：OPPO业务多活的三个核心诉求是成本、扩展、容灾。

成本是指业务总体技术运营成本，包括基础设施的资源成本、研发成本，还包括业务中断的成本、品牌和口碑的成本；

扩展是因为业务规模过大，一个服务需要调用数百个三方实例、一个数据库被数百个实例连接、一个服务需要连接几十个数据库，这就需要对用户进行分片，缩小业务规模，自然演进到单元化多活的架构；

容灾一方面是极端情况下用户数据可靠性保障的需求，另一方面还是业务过于复杂、处理的链路很长，总有一些意想不到情况的发生，频率还挺高，问题定位到恢复的时间达不到公司RTO的要求。机房内部共享了运营商线路、DNS、SNAT防火墙、负载均衡、K8S集群、注册中心、监控等等资源，而机房之间是相对隔离的环境，同时出问题的概率大为降低。在业务出现无法自动恢复的故障时，先切换机房恢复业务，然后再从容定位问题根因。

Q4：随着业务发展启用多个订阅时，如何减少对数据库的压力？

A4 ：我们从数据库源库订阅出来以后，先落地到本地文件队列，然后多个订阅方可以维持自己的同步位点，所以对于源数据库来说，只会有一次订阅。

Q5：请问同城双活方案MHA manager部署在哪个数据中心？

A5 ：我们这里不是MHA，我们用的是一个开源的Raft组件，部署在同城的3个机房，通过Raft组件检测数据库的状态、触发切换。

Q6：Http DNS和Local DNS的区别是什么？

A6 ：Http DNS走的是HTTP协议，客户端直连解析，没有运营商的多级缓存。Local DNS就是运营商的DNS，成功率低，还有劫持、黑洞等问题，而且这两年黑洞频率是越来越高了，前几年基本上很少出现黑洞情况。传统DNS劫持情况现在好一些了，像移动端的接口劫持相对来说会少一些，H5的劫持多一点。

Http DNS就是依赖HTTP协议做解析，但这个压力会比较大，因为Http DNS没有多级缓存，所有请求都到我们的机房，所以刷新机制的设计就非常关键，前面一个章节详细介绍解析刷新的时机。

HttpDNS还有一个好处，因为是自定义的协议，可以传递其他参数，比如设备信息、账号信息，这样才能够实现按用户单元进行解析、调度。

Q7：能否制定统一的用户单元划分规则？

A7 ：这个问题比较好，我们最开始也是想这样子的，我们有云服务、广告、信息流、音乐、视频等业务，起初也想整个公司使用一套单元划分规则，这样业务之间可以做到单元内封闭调用，避免跨机房的调用。

最终的方案，业务之间没有使用同一套单元划分规则。主要原因是：比如说有个业务他经常会做活动，做活动的时候他需要将一部分用户调度走，如果全公司用一套规则的话，所有业务都要跟着调度走，其他业务是不同意的。所以我们是每个业务自己制定单元划分规则。

那这里怎样解决业务之间跨机房调用呢？前面说到了平台型业务SDK化，上层业务之间本身没有强依赖，音乐、软件商店、视频之间本身没有强依赖，他们主要是依赖平台型服务，如账号、评论服务、消息中心、推送服务等。这些平台型业务我们最开始也是提供机房内部API去给其他业务器调用，这就导致我们的平台型服务在每一个机房都要去部署，每个机房都要提供读写功能。所以我们将平台型域名拆分出来，从SDK就开始就和业务域名分开，平台型自己做多活。当然平台型业务无法做到100%的SDK化拆分，平台型服务的部分数据也需要单向同步到各机房，提供本地查询的服务。

Q8：Redis日志是哪个开源组件做到的来的？

A8 ：Redis binlog是OPPO自己修改的，基于AOF修改，简单说一下binlog的格式，

使用logstash同步mysql 多表数据到ElasticSearch实践 - 三度 - 博客园

Wed, 13 Jan 2021 09:26:52 CST

参考样式即可，具体使用配置参数根据实际情况而定

      input {  
    jdbc {  
      jdbc_connection_string => "jdbc:mysql://localhost/数据库名"  
      jdbc_user => "root"  
      jdbc_password => "password"  
      jdbc_driver_library => "mysql-connector-java-5.1.45-bin.jar所在位置"  
      jdbc_driver_class => "com.mysql.jdbc.Driver"
      codec => plain {charset => "UTF-8"}
      record_last_run => true
      jdbc_paging_enabled => "true"  
      jdbc_page_size => "1000"  
      statement => "sql statement"   
      schedule => "* * * * *"  
      type => "数据库表名1"  
      tags => "数据库表名1"
    }
    jdbc {  
      jdbc_connection_string => "jdbc:mysql://localhost/数据库名"  
      jdbc_user => "root"  
      jdbc_password => "password"  
      jdbc_driver_library => "mysql-connector-java-5.1.45-bin.jar所在位置"  
      jdbc_driver_class => "com.mysql.jdbc.Driver"
      codec => plain {charset => "UTF-8"}
      record_last_run => true
      jdbc_paging_enabled => "true"  
      jdbc_page_size => "1000"  
      statement => "sql statement"   
      schedule => "* * * * *"  
      type => "数据库表名2"
      tags => "数据库表名2"
    }
}  

filter {  
    json {  
        source => "message"  
        remove_field => ["message"]  
    }  
}  

output {  
    if [type] == "数据库表名1"{
        elasticsearch {
            hosts => ["els的host地址"]  
            index => "数据库表名1对应的els的index"  
            document_id => "%{唯一id}"
        }
    }
    if [type] == "数据库表名2"{
        elasticsearch {
            hosts => ["els的host地址"]  
            index => "数据库表名2对应的els的index"  
            document_id => "%{唯一id}"
        }
    }
    stdout {   
        codec => json_lines  
    }  
}

MySQL如何实时同步数据到ES？试试这款阿里开源的神器！

Thu, 05 Nov 2020 00:50:41 CST

SpringBoot实战电商项目mall（40k+star）地址： github.com/macrozheng/…

摘要

mall项目中的商品搜索功能，一直都没有做实时数据同步。最近发现阿里巴巴开源的 canal可以把MySQL中的数据实时同步到Elasticsearch中，能很好地解决数据同步问题。今天我们来讲讲 canal的使用，希望对大家有所帮助！

canal简介

canal主要用途是对MySQL数据库增量日志进行解析，提供增量数据的订阅和消费，简单说就是可以对MySQL的增量数据进行实时同步，支持同步到MySQL、Elasticsearch、HBase等数据存储中去。

canal工作原理

canal会模拟MySQL主库和从库的交互协议，从而伪装成MySQL的从库，然后向MySQL主库发送dump协议，MySQL主库收到dump请求会向canal推送binlog，canal通过解析binlog将数据同步到其他存储中去。

canal使用

接下来我们来学习下canal的使用，以MySQL实时同步数据到Elasticsearch为例。

组件下载

首先我们需要下载canal的各个组件 canal-server、 canal-adapter、 canal-admin，下载地址：https://github.com/alibaba/canal/releases

canal的各个组件的用途各不相同，下面分别介绍下：
- canal-server（canal-deploy）：可以直接监听MySQL的binlog，把自己伪装成MySQL的从库，只负责接收数据，并不做处理。
- canal-adapter：相当于canal的客户端，会从canal-server中获取数据，然后对数据进行同步，可以同步到MySQL、Elasticsearch和HBase等存储中去。
- canal-admin：为canal提供整体配置管理、节点运维等面向运维的功能，提供相对友好的WebUI操作界面，方便更多用户快速和安全的操作。
由于不同版本的MySQL、Elasticsearch和canal会有兼容性问题，所以我们先对其使用版本做个约定。

应用	端口	版本
MySQL	3306	5.7
Elasticsearch	9200	7.6.2
Kibanba	5601	7.6.2
canal-server	11111	1.1.15
canal-adapter	8081	1.1.15
canal-admin	8089	1.1.15

MySQL配置

由于canal是通过订阅MySQL的binlog来实现数据同步的，所以我们需要开启MySQL的binlog写入功能，并设置 binlog-format为ROW模式，我的配置文件为 /mydata/mysql/conf/my.cnf，改为如下内容即可；

   [mysqld]
## 设置server_id，同一局域网中需要唯一
server_id=101 
## 指定不需要同步的数据库名称
binlog-ignore-db=mysql  
## 开启二进制日志功能
log-bin=mall-mysql-bin  
## 设置二进制日志使用内存大小（事务）
binlog_cache_size=1M  
## 设置使用的二进制日志格式（mixed,statement,row）
binlog_format=row  
## 二进制日志过期清理时间。默认值为0，表示不自动清理。
expire_logs_days=7  
## 跳过主从复制中遇到的所有错误或指定类型的错误，避免slave端复制中断。
## 如：1062错误是指一些主键重复，1032错误是因为主从数据库数据不一致
slave_skip_errors=1062  
复制代码

配置完成后需要重新启动MySQL，重启成功后通过如下命令查看binlog是否启用；

   show variables like '%log_bin%'
复制代码

   +---------------------------------+-------------------------------------+
| Variable_name                   | Value                               |
+---------------------------------+-------------------------------------+
| log_bin                         | ON                                  |
| log_bin_basename                | /var/lib/mysql/mall-mysql-bin       |
| log_bin_index                   | /var/lib/mysql/mall-mysql-bin.index |
| log_bin_trust_function_creators | OFF                                 |
| log_bin_use_v1_row_events       | OFF                                 |
| sql_log_bin                     | ON                                  |
+---------------------------------+-------------------------------------+
复制代码

再查看下MySQL的binlog模式；

   show variables like 'binlog_format%';  
复制代码

   +---------------+-------+
| Variable_name | Value |
+---------------+-------+
| binlog_format | ROW   |
+---------------+-------+
复制代码

接下来需要创建一个拥有从库权限的账号，用于订阅binlog，这里创建的账号为 canal:canal；

   CREATE USER canal IDENTIFIED BY 'canal';  
GRANT SELECT, REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'canal'@'%';
FLUSH PRIVILEGES;
复制代码

创建好测试用的数据库 canal-test，之后创建一张商品表 product，建表语句如下。

   CREATE TABLE `product`  (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `title` varchar(255) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
  `sub_title` varchar(255) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
  `price` decimal(10, 2) NULL DEFAULT NULL,
  `pic` varchar(255) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
  PRIMARY KEY (`id`) USING BTREE
) ENGINE = InnoDB AUTO_INCREMENT = 2 CHARACTER SET = utf8 COLLATE = utf8_general_ci ROW_FORMAT = Dynamic;
复制代码

canal-server使用

将我们下载好的压缩包 canal.deployer-1.1.5-SNAPSHOT.tar.gz上传到Linux服务器，然后解压到指定目录 /mydata/canal-server，可使用如下命令解压；

   tar -zxvf canal.deployer-1.1.5-SNAPSHOT.tar.gz
复制代码

   ├── bin
│   ├── restart.sh
│   ├── startup.bat
│   ├── startup.sh
│   └── stop.sh
├── conf
│   ├── canal_local.properties
│   ├── canal.properties
│   └── example
│       └── instance.properties
├── lib
├── logs
│   ├── canal
│   │   └── canal.log
│   └── example
│       ├── example.log
│       └── example.log
└── plugin
复制代码

修改配置文件 conf/example/instance.properties，按如下配置即可，主要是修改数据库相关配置；

   # 需要同步数据的MySQL地址
canal.instance.master.address=127.0.0.1:3306
canal.instance.master.journal.name=
canal.instance.master.position=
canal.instance.master.timestamp=
canal.instance.master.gtid=
# 用于同步数据的数据库账号
canal.instance.dbUsername=canal
# 用于同步数据的数据库密码
canal.instance.dbPassword=canal
# 数据库连接编码
canal.instance.connectionCharset = UTF-8
# 需要订阅binlog的表过滤正则表达式
canal.instance.filter.regex=.*\\..*
复制代码

使用 startup.sh脚本启动 canal-server服务；

   sh bin/startup.sh
复制代码

启动成功后可使用如下命令查看服务日志信息；

   tail -f logs/canal/canal.log
复制代码

   2020-10-26 16:18:13.354 [main] INFO  com.alibaba.otter.canal.deployer.CanalController - ## start the canal server[172.17.0.1(172.17.0.1):11111]
2020-10-26 16:18:19.978 [main] INFO  com.alibaba.otter.canal.deployer.CanalStarter - ## the canal server is running now ......
复制代码

启动成功后可使用如下命令查看instance日志信息；

   tail -f logs/example/example.log 
复制代码

   2020-10-26 16:18:16.056 [main] INFO  c.a.o.c.i.spring.support.PropertyPlaceholderConfigurer - Loading properties file from class path resource [canal.properties]
2020-10-26 16:18:16.061 [main] INFO  c.a.o.c.i.spring.support.PropertyPlaceholderConfigurer - Loading properties file from class path resource [example/instance.properties]
2020-10-26 16:18:18.259 [main] INFO  c.a.otter.canal.instance.spring.CanalInstanceWithSpring - start CannalInstance for 1-example 
2020-10-26 16:18:18.282 [main] WARN  c.a.o.canal.parse.inbound.mysql.dbsync.LogEventConvert - --> init table filter : ^.*\..*$
2020-10-26 16:18:18.282 [main] WARN  c.a.o.canal.parse.inbound.mysql.dbsync.LogEventConvert - --> init table black filter : ^mysql\.slave_.*$
2020-10-26 16:18:19.543 [destination = example , address = /127.0.0.1:3306 , EventParser] WARN  c.a.o.c.p.inbound.mysql.rds.RdsBinlogEventParserProxy - ---> begin to find start position, it will be long time for reset or first position
2020-10-26 16:18:19.578 [main] INFO  c.a.otter.canal.instance.core.AbstractCanalInstance - start successful....
2020-10-26 16:18:19.912 [destination = example , address = /127.0.0.1:3306 , EventParser] WARN  c.a.o.c.p.inbound.mysql.rds.RdsBinlogEventParserProxy - prepare to find start position just last position
 {"identity":{"slaveId":-1,"sourceAddress":{"address":"localhost","port":3306}},"postion":{"gtid":"","included":false,"journalName":"mall-mysql-bin.000006","position":2271,"serverId":101,"timestamp":1603682664000}}
2020-10-26 16:18:22.435 [destination = example , address = /127.0.0.1:3306 , EventParser] WARN  c.a.o.c.p.inbound.mysql.rds.RdsBinlogEventParserProxy - ---> find start position successfully, EntryPosition[included=false,journalName=mall-mysql-bin.000006,position=2271,serverId=101,gtid=,timestamp=1603682664000] cost : 2768ms , the next step is binlog dump
复制代码

如果想要停止 canal-server服务可以使用如下命令。

   sh bin/stop.sh
复制代码

canal-adapter使用

将我们下载好的压缩包 canal.adapter-1.1.5-SNAPSHOT.tar.gz上传到Linux服务器，然后解压到指定目录 /mydata/canal-adpter，解压完成后目录结构如下；

   ├── bin
│   ├── adapter.pid
│   ├── restart.sh
│   ├── startup.bat
│   ├── startup.sh
│   └── stop.sh
├── conf
│   ├── application.yml
│   ├── es6
│   ├── es7
│   │   ├── biz_order.yml
│   │   ├── customer.yml
│   │   └── product.yml
│   ├── hbase
│   ├── kudu
│   ├── logback.xml
│   ├── META-INF
│   │   └── spring.factories
│   └── rdb
├── lib
├── logs
│   └── adapter
│       └── adapter.log
└── plugin
复制代码

修改配置文件 conf/application.yml，按如下配置即可，主要是修改canal-server配置、数据源配置和客户端适配器配置；

   canal.conf:
  mode: tcp # 客户端的模式，可选tcp kafka rocketMQ
  flatMessage: true # 扁平message开关, 是否以json字符串形式投递数据, 仅在kafka/rocketMQ模式下有效
  zookeeperHosts:    # 对应集群模式下的zk地址
  syncBatchSize: 1000 # 每次同步的批数量
  retries: 0 # 重试次数, -1为无限重试
  timeout: # 同步超时时间, 单位毫秒
  accessKey:
  secretKey:
  consumerProperties:
    # canal tcp consumer
    canal.tcp.server.host: 127.0.0.1:11111 #设置canal-server的地址
    canal.tcp.zookeeper.hosts:
    canal.tcp.batch.size: 500
    canal.tcp.username:
    canal.tcp.password:

  srcDataSources: # 源数据库配置
    defaultDS:
      url: jdbc:mysql://127.0.0.1:3306/canal_test?useUnicode=true
      username: canal
      password: canal
  canalAdapters: # 适配器列表
  - instance: example # canal实例名或者MQ topic名
    groups: # 分组列表
    - groupId: g1 # 分组id, 如果是MQ模式将用到该值
      outerAdapters:
      - name: logger # 日志打印适配器
      - name: es7 # ES同步适配器
        hosts: 127.0.0.1:9200 # ES连接地址
        properties:
          mode: rest # 模式可选transport(9300) 或者 rest(9200)
          # security.auth: test:123456 #  only used for rest mode
          cluster.name: elasticsearch # ES集群名称
复制代码

添加配置文件 canal-adapter/conf/es7/product.yml，用于配置MySQL中的表与Elasticsearch中索引的映射关系；

   dataSourceKey: defaultDS # 源数据源的key, 对应上面配置的srcDataSources中的值
destination: example  # canal的instance或者MQ的topic
groupId: g1 # 对应MQ模式下的groupId, 只会同步对应groupId的数据
esMapping:
  _index: canal_product # es 的索引名称
  _id: _id  # es 的_id, 如果不配置该项必须配置下面的pk项_id则会由es自动分配
  sql: "SELECT
        p.id AS _id,
        p.title,
        p.sub_title,
        p.price,
        p.pic
        FROM
        product p"        # sql映射
  etlCondition: "where a.c_time>={}"   #etl的条件参数
  commitBatch: 3000   # 提交批大小
复制代码

使用 startup.sh脚本启动 canal-adapter服务；

   sh bin/startup.sh
复制代码

启动成功后可使用如下命令查看服务日志信息；

   tail -f logs/adapter/adapter.log
复制代码

   20-10-26 16:52:55.148 [main] INFO  c.a.o.canal.adapter.launcher.loader.CanalAdapterLoader - Load canal adapter: logger succeed
2020-10-26 16:52:57.005 [main] INFO  c.a.o.c.client.adapter.es.core.config.ESSyncConfigLoader - ## Start loading es mapping config ... 
2020-10-26 16:52:57.376 [main] INFO  c.a.o.c.client.adapter.es.core.config.ESSyncConfigLoader - ## ES mapping config loaded
2020-10-26 16:52:58.615 [main] INFO  c.a.o.canal.adapter.launcher.loader.CanalAdapterLoader - Load canal adapter: es7 succeed
2020-10-26 16:52:58.651 [main] INFO  c.alibaba.otter.canal.connector.core.spi.ExtensionLoader - extension classpath dir: /mydata/canal-adapter/plugin
2020-10-26 16:52:59.043 [main] INFO  c.a.o.canal.adapter.launcher.loader.CanalAdapterLoader - Start adapter for canal-client mq topic: example-g1 succeed
2020-10-26 16:52:59.044 [main] INFO  c.a.o.canal.adapter.launcher.loader.CanalAdapterService - ## the canal client adapters are running now ......
2020-10-26 16:52:59.057 [Thread-4] INFO  c.a.otter.canal.adapter.launcher.loader.AdapterProcessor - =============> Start to connect destination: example <=============
2020-10-26 16:52:59.100 [main] INFO  org.apache.coyote.http11.Http11NioProtocol - Starting ProtocolHandler ["http-nio-8081"]
2020-10-26 16:52:59.153 [main] INFO  org.apache.tomcat.util.net.NioSelectorPool - Using a shared selector for servlet write/read
2020-10-26 16:52:59.590 [main] INFO  o.s.boot.web.embedded.tomcat.TomcatWebServer - Tomcat started on port(s): 8081 (http) with context path ''
2020-10-26 16:52:59.626 [main] INFO  c.a.otter.canal.adapter.launcher.CanalAdapterApplication - Started CanalAdapterApplication in 31.278 seconds (JVM running for 33.99)
2020-10-26 16:52:59.930 [Thread-4] INFO  c.a.otter.canal.adapter.launcher.loader.AdapterProcessor - =============> Subscribe destination: example succeed <=============
复制代码

如果需要停止 canal-adapter服务可以使用如下命令。

   sh bin/stop.sh
复制代码

数据同步演示

经过上面的一系列步骤，canal的数据同步功能已经基本可以使用了，下面我们来演示下数据同步功能。

首先我们需要在Elasticsearch中创建索引，和MySQL中的product表相对应，直接在Kibana的 Dev Tools中使用如下命令创建即可；

   PUT canal_product
{
  "mappings": {
    "properties": {
      "title": {
        "type": "text"
      },
      "sub_title": {
        "type": "text"
      },
      "pic": {
        "type": "text"
      },
      "price": {
        "type": "double"
      }
    }
  }
}
复制代码

创建完成后可以查看下索引的结构；

   GET canal_product/_mapping
复制代码

之后使用如下SQL语句在数据库中创建一条记录；

   INSERT INTO product ( id, title, sub_title, price, pic ) VALUES ( 5, '小米8', ' 全面屏游戏智能手机 6GB+64GB', 1999.00, NULL );
复制代码

创建成功后，在Elasticsearch中搜索下，发现数据已经同步了；

   GET canal_product/_search
复制代码

再使用如下SQL对数据进行修改；

   UPDATE product SET title='小米10' WHERE id=5
复制代码

修改成功后，在Elasticsearch中搜索下，发现数据已经修改了；

再使用如下SQL对数据进行删除操作；

   DELETE FROM product WHERE id=5
复制代码

删除成功后，在Elasticsearch中搜索下，发现数据已经删除了，至此MySQL同步到Elasticsearch的功能完成了！

canal-admin使用

将我们下载好的压缩包 canal.admin-1.1.5-SNAPSHOT.tar.gz上传到Linux服务器，然后解压到指定目录 /mydata/canal-admin，解压完成后目录结构如下；

   ├── bin
│   ├── restart.sh
│   ├── startup.bat
│   ├── startup.sh
│   └── stop.sh
├── conf
│   ├── application.yml
│   ├── canal_manager.sql
│   ├── canal-template.properties
│   ├── instance-template.properties
│   ├── logback.xml
│   └── public
│       ├── avatar.gif
│       ├── index.html
│       ├── logo.png
│       └── static
├── lib
└── logs
复制代码

创建canal-admin需要使用的数据库 canal_manager，创建SQL脚本为 /mydata/canal-admin/conf/canal_manager.sql，会创建如下表；

修改配置文件 conf/application.yml，按如下配置即可，主要是修改数据源配置和 canal-admin的管理账号配置，注意需要用一个有读写权限的数据库账号，比如管理账号 root:root；

   server:
  port: 8089
spring:
  jackson:
    date-format: yyyy-MM-dd HH:mm:ss
    time-zone: GMT+8

spring.datasource:
  address: 127.0.0.1:3306
  database: canal_manager
  username: root
  password: root
  driver-class-name: com.mysql.jdbc.Driver
  url: jdbc:mysql://${spring.datasource.address}/${spring.datasource.database}?useUnicode=true&characterEncoding=UTF-8&useSSL=false
  hikari:
    maximum-pool-size: 30
    minimum-idle: 1

canal:
  adminUser: admin
  adminPasswd: admin
复制代码

接下来对之前搭建的 canal-server的 conf/canal_local.properties文件进行配置，主要是修改 canal-admin的配置，修改完成后使用 sh bin/startup.sh local重启 canal-server：

   # register ip
canal.register.ip =

# canal admin config
canal.admin.manager = 127.0.0.1:8089
canal.admin.port = 11110
canal.admin.user = admin
canal.admin.passwd = 4ACFE3202A5FF5CF467898FC58AAB1D615029441
# admin auto register
canal.admin.register.auto = true
canal.admin.register.cluster = 
复制代码

使用 startup.sh脚本启动 canal-admin服务；

   sh bin/startup.sh
复制代码

启动成功后可使用如下命令查看服务日志信息；

   tail -f logs/admin.log
复制代码

   020-10-27 10:15:04.210 [main] INFO  org.apache.coyote.http11.Http11NioProtocol - Starting ProtocolHandler ["http-nio-8089"]
2020-10-27 10:15:04.308 [main] INFO  org.apache.tomcat.util.net.NioSelectorPool - Using a shared selector for servlet write/read
2020-10-27 10:15:04.534 [main] INFO  o.s.boot.web.embedded.tomcat.TomcatWebServer - Tomcat started on port(s): 8089 (http) with context path ''
2020-10-27 10:15:04.573 [main] INFO  com.alibaba.otter.canal.admin.CanalAdminApplication - Started CanalAdminApplication in 31.203 seconds (JVM running for 34.865)
复制代码

访问canal-admin的Web界面，输入账号密码 admin:123456即可登录，访问地址：http://192.168.3.101:8089

登录成功后即可使用Web界面操作canal-server。

参考资料

canal官方文档：https://github.com/alibaba/canal/wiki

配置文件地址

github.com/macrozheng/…

本文 GitHub github.com/macrozheng/… 已经收录，欢迎大家Star！

基于 Flink SQL CDC 的实时数据同步方案 (developer.aliyun.com)

Mon, 09 Nov 2020 00:00:00 CST

整理：陈政羽（Flink 社区志愿者）

Flink 1.11 引入了 Flink SQL CDC，CDC 能给我们数据和业务间能带来什么变化？本文由 Apache Flink PMC，阿里巴巴技术专家伍翀 (云邪）分享，内容将从传统的数据同步方案，基于 Flink CDC 同步的解决方案以及更多的应用场景和 CDC 未来开发规划等方面进行介绍和演示。

1、传统数据同步方案
2、基于 Flink SQL CDC 的数据同步方案（Demo）
3、Flink SQL CDC 的更多应用场景
4、Flink SQL CDC 的未来规划
直播回顾：
https://www.bilibili.com/video/BV1zt4y1D7kt/

传统的数据同步方案与 Flink SQL CDC 解决方案

业务系统经常会遇到需要更新数据到多个存储的需求。例如：一个订单系统刚刚开始只需要写入数据库即可完成业务使用。某天 BI 团队期望对数据库做全文索引，于是我们同时要写多一份数据到 ES 中，改造后一段时间，又有需求需要写入到 Redis 缓存中。

很明显这种模式是不可持续发展的，这种双写到各个数据存储系统中可能导致不可维护和扩展，数据一致性问题等，需要引入分布式事务，成本和复杂度也随之增加。我们可以通过 CDC（Change Data Capture）工具进行解除耦合，同步到下游需要同步的存储系统。通过这种方式提高系统的稳健性，也方便后续的维护。

Flink SQL CDC 数据同步与原理解析

CDC 全称是 Change Data Capture ，它是一个比较广义的概念，只要能捕获变更的数据，我们都可以称为 CDC 。业界主要有基于查询的 CDC 和基于日志的 CDC ，可以从下面表格对比他们功能和差异点。

经过以上对比，我们可以发现基于日志 CDC 有以下这几种优势：

· 能够捕获所有数据的变化，捕获完整的变更记录。在异地容灾，数据备份等场景中得到广泛应用，如果是基于查询的 CDC 有可能导致两次查询的中间一部分数据丢失
· 每次 DML 操作均有记录无需像查询 CDC 这样发起全表扫描进行过滤，拥有更高的效率和性能，具有低延迟，不增加数据库负载的优势
· 无需入侵业务，业务解耦，无需更改业务模型
· 捕获删除事件和捕获旧记录的状态，在查询 CDC 中，周期的查询无法感知中间数据是否删除

基于日志的 CDC 方案介绍

从 ETL 的角度进行分析，一般采集的都是业务库数据，这里使用 MySQL 作为需要采集的数据库，通过 Debezium 把 MySQL Binlog 进行采集后发送至 Kafka 消息队列，然后对接一些实时计算引擎或者 APP 进行消费后把数据传输入 OLAP 系统或者其他存储介质。

Flink 希望打通更多数据源，发挥完整的计算能力。我们生产中主要来源于业务日志和数据库日志，Flink 在业务日志的支持上已经非常完善，但是在数据库日志支持方面在 Flink 1.11 前还属于一片空白，这就是为什么要集成 CDC 的原因之一。

Flink SQL 内部支持了完整的 changelog 机制，所以 Flink 对接 CDC 数据只需要把CDC 数据转换成 Flink 认识的数据，所以在 Flink 1.11 里面重构了 TableSource 接口，以便更好支持和集成 CDC。

重构后的 TableSource 输出的都是 RowData 数据结构，代表了一行的数据。在RowData 上面会有一个元数据的信息，我们称为 RowKind 。RowKind 里面包括了插入、更新前、更新后、删除，这样和数据库里面的 binlog 概念十分类似。通过 Debezium 采集的 JSON 格式，包含了旧数据和新数据行以及原数据信息，op 的 u表示是 update 更新操作标识符，ts_ms 表示同步的时间戳。因此，对接 Debezium JSON 的数据，其实就是将这种原始的 JSON 数据转换成 Flink 认识的 RowData。

选择 Flink 作为 ETL 工具

当选择 Flink 作为 ETL 工具时，在数据同步场景，如下图同步结构：

通过 Debezium 订阅业务库 MySQL 的 Binlog 传输至 Kafka ，Flink 通过创建 Kafka 表指定 format 格式为 debezium-json ，然后通过 Flink 进行计算后或者直接插入到其他外部数据存储系统，例如图中的 Elasticsearch 和 PostgreSQL。

但是这个架构有个缺点，我们可以看到采集端组件过多导致维护繁杂，这时候就会想是否可以用 Flink SQL 直接对接 MySQL 的 binlog 数据呢，有没可以替代的方案呢？

答案是有的！经过改进后结构如下图：

社区开发了 flink-cdc-connectors 组件，这是一个可以直接从 MySQL、PostgreSQL 等数据库直接读取全量数据和增量变更数据的 source 组件。目前也已开源，开源地址：

https://github.com/ververica/flink-cdc-connectors

flink-cdc-connectors 可以用来替换 Debezium+Kafka 的数据采集模块，从而实现 Flink SQL 采集+计算+传输（ETL）一体化，这样做的优点有以下：

· 开箱即用，简单易上手
· 减少维护的组件，简化实时链路，减轻部署成本
· 减小端到端延迟
· Flink 自身支持 Exactly Once 的读取和计算
· 数据不落地，减少存储成本
· 支持全量和增量流式读取
· binlog 采集位点可回溯*

基于 Flink SQL CDC 的数据同步方案实践

下面给大家带来 3 个关于 Flink SQL + CDC 在实际场景中使用较多的案例。在完成实验时候，你需要 Docker、MySQL、Elasticsearch 等组件，具体请参考每个案例参考文档。

案例 1 : Flink SQL CDC + JDBC Connector

这个案例通过订阅我们订单表（事实表）数据，通过 Debezium 将 MySQL Binlog 发送至 Kafka，通过维表 Join 和 ETL 操作把结果输出至下游的 PG 数据库。具体可以参考 Flink 公众号文章：《Flink JDBC Connector：Flink 与数据库集成最佳实践》案例进行实践操作。

https://www.bilibili.com/video/BV1bp4y1q78d

案例 2 : CDC Streaming ETL

模拟电商公司的订单表和物流表，需要对订单数据进行统计分析，对于不同的信息需要进行关联后续形成订单的大宽表后，交给下游的业务方使用 ES 做数据分析，这个案例演示了如何只依赖 Flink 不依赖其他组件，借助 Flink 强大的计算能力实时把 Binlog 的数据流关联一次并同步至 ES 。

例如如下的这段 Flink SQL 代码就能完成实时同步 MySQL 中 orders 表的全量+增量数据的目的。

   CREATE TABLE orders (
  order_id INT,
  order_date TIMESTAMP(0),
  customer_name STRING,
  price DECIMAL(10, 5),
  product_id INT,
  order_status BOOLEAN
) WITH (
  'connector' = 'mysql-cdc',
  'hostname' = 'localhost',
  'port' = '3306',
  'username' = 'root',
  'password' = '123456',
  'database-name' = 'mydb',
  'table-name' = 'orders'
);

SELECT * FROM orders

为了让读者更好地上手和理解，我们还提供了 docker-compose 的测试环境，更详细的案例教程请参考下文的视频链接和文档链接。

视频链接：
https://www.bilibili.com/video/BV1zt4y1D7kt
文档教程：
https://github.com/ververica/flink-cdc-connectors/wiki/中文教程

案例 3 : Streaming Changes to Kafka

下面案例就是对 GMV 进行天级别的全站统计。包含插入/更新/删除，只有付款的订单才能计算进入 GMV ，观察 GMV 值的变化。

视频链接：
https://www.bilibili.com/video/BV1zt4y1D7kt
文档教程：
https://github.com/ververica/flink-cdc-connectors/wiki/中文教程

Flink SQL CDC 的更多应用场景

Flink SQL CDC 不仅可以灵活地应用于实时数据同步场景中，还可以打通更多的场景提供给用户选择。

Flink 在数据同步场景中的灵活定位

· 如果你已经有 Debezium/Canal + Kafka 的采集层 (E)，可以使用 Flink 作为计算层 (T) 和传输层 (L)
· 也可以用 Flink 替代 Debezium/Canal ，由 Flink 直接同步变更数据到 Kafka，Flink 统一 ETL 流程
· 如果不需要 Kafka 数据缓存，可以由 Flink 直接同步变更数据到目的地，Flink 统一 ETL 流程

Flink SQL CDC : 打通更多场景

· 实时数据同步，数据备份，数据迁移，数仓构建
优势：丰富的上下游（E & L），强大的计算（T），易用的 API（SQL），流式计算低延迟
· 数据库之上的实时物化视图、流式数据分析
· 索引构建和实时维护
· 业务 cache 刷新
· 审计跟踪
· 微服务的解耦，读写分离
· 基于 CDC 的维表关联

下面介绍一下为何用 CDC 的维表关联会比基于查询的维表查询快。

■ 基于查询的维表关联

目前维表查询的方式主要是通过 Join 的方式，数据从消息队列进来后通过向数据库发起 IO 的请求，由数据库把结果返回后合并再输出到下游，但是这个过程无可避免的产生了 IO 和网络通信的消耗，导致吞吐量无法进一步提升，就算使用一些缓存机制，但是因为缓存更新不及时可能会导致精确性也没那么高。

■ 基于 CDC 的维表关联

我们可以通过 CDC 把维表的数据导入到维表 Join 的状态里面，在这个 State 里面因为它是一个分布式的 State ，里面保存了 Database 里面实时的数据库维表镜像，当消息队列数据过来时候无需再次查询远程的数据库了，直接查询本地磁盘的 State ，避免了 IO 操作，实现了低延迟、高吞吐，更精准。

Tips：目前此功能在 1.12 版本的规划中，具体进度请关注 FLIP-132 。

未来规划

· FLIP-132 ：Temporal Table DDL（基于 CDC 的维表关联）
· Upsert 数据输出到 Kafka
· 更多的 CDC formats 支持（debezium-avro, OGG, Maxwell）
· 批模式支持处理 CDC 数据
· flink-cdc-connectors 支持更多数据库

总结

本文通过对比传统的数据同步方案与 Flink SQL CDC 方案分享了 Flink CDC 的优势，与此同时介绍了 CDC 分为日志型和查询型各自的实现原理。后续案例也演示了关于 Debezium 订阅 MySQL Binlog 的场景介绍，以及如何通过 flink-cdc-connectors 实现技术整合替代订阅组件。除此之外，还详细讲解了 Flink CDC 在数据同步、物化视图、多机房备份等的场景，并重点讲解了社区未来规划的基于 CDC 维表关联对比传统维表关联的优势以及 CDC 组件工作。

希望通过这次分享，大家对 Flink SQL CDC 能有全新的认识和了解，在未来实际生产开发中，期望 Flink CDC 能带来更多开发的便捷和更丰富的使用场景。

Q & A

1、GROUP BY 结果如何写到 Kafka ？

因为 group by 的结果是一个更新的结果，目前无法写入 append only 的消息队列中里面去。更新的结果写入 Kafka 中将在 1.12 版本中原生地支持。在 1.11 版本中，可以通过 flink-cdc-connectors 项目提供的 changelog-json format 来实现该功能，具体见文档。

文档链接：
https://github.com/ververica/flink-cdc-connectors/wiki/Changelog-JSON-Format

2、CDC 是否需要保证顺序化消费？

是的，数据同步到 kafka ，首先需要 kafka 在分区中保证有序，同一个 key 的变更数据需要打入到同一个 kafka 的分区里面。这样 flink 读取的时候才能保证顺序。

MYSQL logstash 同步数据到es的几种方案对比以及每种方案数据丢失原因分析。

Wed, 07 Oct 2020 15:59:50 CST

MYSQL logstash 同步增量数据到ES

最近一段时间，在使用mysql通过logstash-jdbc同步数据到es,但是总是会有一定程度数据丢失。logstash-jdbc无非是通过sql遍历数据表的所有数据，然后同步到es。

对于表里面的所有字段都需要查出来然后同步到es中去。本地测试数据表结构如下:

    CREATE TABLE `user` (      
  `id` bigint(20) NOT NULL AUTO_INCREMENT,      
  `username` varchar(32) CHARACTER SET utf8 NOT NULL,      
  `upnum` decimal(20,0) NOT NULL,      
  `last_update_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,      
  PRIMARY KEY (`id`),      
  KEY `last_update_time` (`last_update_time`)      
) ENGINE=InnoDB AUTO_INCREMENT=25094590 DEFAULT CHARSET=latin1;

数据同步脚本分为全量同步与增量同步。

全量同步sql如下:

    select id,username,upnum,last_update_time from user where id>{$MIN_ID} and id<{$MAX_ID}

通过shell的方式在每次执行之前替换脚本里面的最大最小ID,每批查询10万ID数据。

增量同步sql:

    select id,username,upnum,last_update_time from user where last_update_time>=:last_sql_value

增量同步，每次记录last_update_time最后时间，然后每次查询查询上一次时间之后的数据。最终结果，增量丢数据！！！

方案1

每次查询last_update_time 时间大于等于上一次数据时间的数据，分页查询。

    select * from (select id,username,upnum,last_update_time from user where last_update_time>=:last_sql_val) as a limit 10000 offset 10000

这种方案会涉及到几个问题:

1) 相同last_update_time的数据导致数据最终查询出来的顺序有可能不确定。导致有可能在查第一页的时候，数据id=100001的数据在第二页，但是当分页到第二页的时候，id=100001的数据又在第一页了，从而导致这条数据不会被同步。

2）last_update_time 使用的是ON UPDATE CURRENT_TIMESTAMP，时间是更新语句执行的时间。但是只有当更新语句事务提交的时候才会被查询到。这种情况，当一条数据在 2020-09-30 00:00:00执行update语句，但是因为事务提交时间比较长，到 2020-09-30 00:00:03的时候才提交。这个时候在 2020-09-30 00:00:03的时候，同步sql有可能已经是翻页翻到时间为 2020-09-30 00:00:02的数据了，因此导致数据丢失。

3）主从同步导致数据分页查询不到。一般都用es了，都会有主从同步，而es数据同步也是在从库中读取数据同步的。因此主从同步的这个时间延时也会导致数据查询不正确。

方案2

不分页查询，避免分页造成的数据丢失。不分页查询的话，需要将数据查询的时间区间减少。调整logstatsh调度频率，每5秒钟执行一次，每次查询数据10万条。

    select id,username,upnum,last_update_time from user where last_update_time>=:last_sql_val limit 10000

这个方案的问题:

1) 查询条件是大于等于。因此，当在last_update_time 临界时间 2020-09-30 00:00:00有10万条数据(比如添加字段初始化数据)，就会让整个数据更新脚本 原地踏步
2) 主从同步，已经事务提交延迟的问题依然存在

方案3

使用两个脚本同步数据，新增一个5分钟延迟的同步脚本，减少数据丢失的概率

    select id,username,upnum,last_update_time from user where last_update_time>:last_sql_val limit 10000

    select id,username,upnum,last_update_time from user where last_update_time>:last_sql_val and last_update_time<DATE_SUB(NOW(),INTERVAL 5 MINUTE) limit 30000

这个方案的问题:
1) 不会出现原地踏步的情况，但是在同时间的数据可能会有数据丢失
2) 可以减少因为主从同步，事务提交延迟的数据丢失，但是没办法确保100%不丢失

方案4

使用binlog的方式同步到es。但是对于现有的历史数据，还是需要通过遍历数据表的方式进行同步。

结论

以上内容是目前在工作中mysql同步数据到es的几个方案。按目前网络中大部分文章，都是通过logstash进行数据同步。

但是请注意，logstash的方案是有可能造成成数据丢失的。而这种数据丢失对于insert操作而言，还是可以确定是否有没有丢数据。毕竟对比一下两边的数据量就可以了。

但是，对于update操作呢，怎么确定是否全部同步过去了呢。假如您有一个几千万用户单据信息，而且还是关于钱的，怎么样确定每次更新都正确无误的同步到了es呢？

基于上面的分析，最靠谱的办法，还是通过binlog的方式同步es。

实时数据同步服务如何保证消息的顺序性

Sun, 16 Aug 2020 08:48:15 CST

上一篇 介绍了移山(数据迁移平台)实时数据同步的整体架构；
本文主要介绍移山(数据迁移平台)实时数据同步是如何保证消息的顺序性。

可以访问这里查看更多关于大数据平台建设的原创文章。

一. 什么是消息的顺序性？

消息生产端将消息发送给同一个MQ服务器的同一个分区，并且按顺序发送；

消费消费端按照消息发送的顺序进行消费。

二. 为什么要保证消息的顺序性？

在某些业务功能场景下需要保证消息的发送和接收顺序是一致的，否则会影响数据的使用。

需要保证消息有序的场景

移山的实时数据同步使用 canal 组件订阅MySQL数据库的日志，并将其投递至 kafka 中（想了解移山实时同步服务架构设计的可以点这里）；
kafka 消费端再根据具体的数据使用场景去处理数据（存入 HBase、MySQL 或直接做实时分析）；
由于binlog 本身是有序的，因此写入到mq之后也需要保障顺序。

假如现在移山创建了一个实时同步任务，然后订阅了一个业务数据库的订单表；
上游业务，向订单表里插入了一个订单，然后对该订单又做了一个更新操作，则 binlog 里会自动写入插入操作和更新操作的数据，这些数据会被 canal server 投递至 kafka broker 里面；
如果 kafka 消费端先消费到了更新日志，后消费到插入日志，则在往目标表里做操作时就会因为数据缺失导致发生异常。

三. 移山实时同步服务是怎么保证消息的顺序性

实时同步服务消息处理整体流程如下：

我们主要通过以下两个方面去保障保证消息的顺序性。

1. 将需要保证顺序的消息发送到同一个partition

1.1 kafka的同一个partition内的消息是有序的

kafka 的同一个 partition 用一个write ahead log组织，是一个有序的队列，所以可以保证FIFO的顺序；
因此生产者按照一定的顺序发送消息，broker 就会按照这个顺序把消息写入 partition，消费者也会按照相同的顺序去读取消息；
kafka 的每一个 partition 不会同时被两个消费者实例消费，由此可以保证消息消费的顺序性。

1.2 控制同一key分发到同一partition

要保证同一个订单的多次修改到达 kafka 里的顺序不能乱，可以在Producer 往 kafka 插入数据时，控制同一个key （可以采用订单主键key-hash算法来实现）发送到同一 partition，这样就能保证同一笔订单都会落到同一个 partition 内。

1.3 canal 需要做的配置

canal 目前支持的mq有 kafka/rocketmq，本质上都是基于本地文件的方式来支持了分区级的顺序消息的能力。我们只需在配置 instance 的时候开启如下配置即可：

1> canal.properties

# leader节点会等待所有同步中的副本确认之后再确认这条记录是否发送完成
canal.mq.acks = all

备注：

这样只要至少有一个同步副本存在，记录就不会丢失。

2> instance.properties

1 # 散列模式的分区数
2 canal.mq.partitionsNum=2
3 # 散列规则定义 库名.表名: 唯一主键，多个表之间用逗号分隔
4 canal.mq.partitionHash=test.lyf_canal_test:id

备注：

同一条数据的增删改操作产生的 binlog 数据都会写到同一个分区内；

查看指定topic的指定分区的消息，可以使用如下命令：

bin/kafka-console-consumer.sh --bootstrap-server serverlist --topic topicname --from-beginning --partition 0

2. 通过日志时间戳和日志偏移量进行乱序处理

将同一个订单数据通过指定key的方式发送到同一个 partition 可以解决大部分情况下的数据乱序问题。

2.1 特殊场景

对于一个有着先后顺序的消息A、B，正常情况下应该是A先发送完成后再发送B。但是在异常情况下：

A发送失败了，B发送成功，而A由于重试机制在B发送完成之后重试发送成功了；
这时对于本身顺序为AB的消息顺序变成了BA。

移山的实时同步服务会在将订阅到的数据存入HBase之前再加一层乱序处理。

2.2 binlog里的两个重要信息

使用 mysqlbinlog 查看 binlog：

/usr/bin/mysqlbinlog --base64-output=decode-rows -v /var/lib/mysql/mysql-bin.000001

执行时间和偏移量：

备注：

每条数据都会有执行时间和偏移量这两个重要信息， 下边的校验逻辑核心正是借助了这两个值；
执行的sql 语句在 binlog 中是以base64编码格式存储的，如果想查看sql 语句，需要加上： --base64-output=decode-rows -v 参数来解码；
偏移量：
- Position 就代表 binlog 写到这个偏移量的地方，也就是写了这么多字节，即当前 binlog 文件的大小；
- 也就是说后写入数据的 Position 肯定比先写入数据的 Position 大， 因此可以根据 Position 大小来判断消息的顺序。

3.消息乱序处理演示

3.1 在订阅表里插入一条数据，然后再做两次更新操作：

MariaDB [test]> insert into lyf_canal_test (name,status,content) values('demo1',1,'demo1 test');
Query OK, 1 row affected (0.00 sec)
 
MariaDB [test]> update lyf_canal_test set name = 'demo update' where id = 13;
Query OK, 1 row affected (0.00 sec)
Rows matched: 1 Changed: 1 Warnings: 0
 
MariaDB [test]> update lyf_canal_test set name = 'demo update2',content='second update',status=2 where id = 13;
Query OK, 1 row affected (0.00 sec)

3.2 产生三条需要保证顺序的消息

把 插入，第一次更新，第二次更新这三次操作产生的 binlog 被 canal server 推送至 kafka 中的消息分别称为： 消息A，消息B，消息C。

消息A：
消息B：
消息C：

3.3 网络原因造成消息乱序

假设由于不可知的网络原因：

kafka broker收到的三条消息分别为： 消息A，消息C，消息B；
则 kafka 消费端消费到的这三条消息先后顺序就是： 消息A，消息C，消息B
这样就造成了消息的乱序，因此 订阅到的数据在存入目标表前必须得加乱序校验处理。

3.4 消息乱序处理逻辑

我们利用HBase的特性，将数据主键做为目标表的 rowkey。当 kafka 消费端消费到数据时，乱序处理主要流程（摘自禧云数芯大数据平台技术白皮书）如下：

demo的三条消息处理流程如下：
1> 判断消息A 的主键id做为rowkey在hbase的目标表中不存在，则将消息A的数据直接插入HBase：

2> 消息C 的主键id做为rowkey，已经在目标表中存在，则这时需要拿消息C 的执行时间和表中存储的执行时间去判断：

如果消息C 中的执行时间小于表中存储的执行时间，则证明消息C 是重复消息或乱序的消息，直接丢弃；
消息C 中的执行时间大于表中存储的执行时间，则直接更新表数据（本demo即符合该种场景）：
消息C 中的执行时间等于表中存储的执行时间，则这时需要拿消息C 的偏移量和表中存储的偏移量去判断：
- 消息C 中的偏移量小于表中存储的偏移量，则证明消息C 是重复消息，直接丢弃；
- 消息C 中的偏移量大于等于表中存储的偏移量，则直接更新表数据。

3> 消息B 的主键id做为rowkey，已经在目标表中存在，则这时需要拿消息B 的执行时间和表中存储的执行时间去判断：

由于消息B中的执行时间小于表中存储的执行时间（即消息C 的执行时间），因此消息B 直接丢弃。

3.5 主要代码

kafka 消费端将消费到的消息进行格式化处理和组装，并借助 HBase-client API 来完成对 HBase 表的操作。

1> 使用 Put组装单行数据

/**
* 包名： org.apache.hadoop.hbase.client.Put
* hbaseData 为从binlog订阅到的数据，通过循环，为目标HBase表
* 添加rowkey、列簇、列数据。
* 作用：用来对单个行执行加入操作。
*/
Put put = new Put(Bytes.toBytes(hbaseData.get("id")));
// hbaseData 为从binlog订阅到的数据，通过循环，为目标HBase表添加列簇和列
put.addColumn(Bytes.toBytes("info"), Bytes.toBytes(mapKey), Bytes.toBytes(hbaseData.get(mapKey)));

2> 使用 checkAndMutate，更新 HBase表的数据

只有服务端对应rowkey的列数据与预期的值符合期望条件（大于、小于、等于）时，才会将put操作提交至服务端。

// 如果 update_info（列族） execute_time（列） 不存在值就插入数据，如果存在则返回false
boolean res1 = table.checkAndMutate(Bytes.toBytes(hbaseData.get("id")), Bytes.toBytes("update_info")) .qualifier(Bytes.toBytes("execute_time")).ifNotExists().thenPut(put);
 
// 如果存在，则去比较执行时间
if (!res1) {
// 如果本次传递的执行时间大于HBase中的执行时间，则插入put
boolean res2 =table.checkAndPut(Bytes.toBytes(hbaseData.get("id")), Bytes.toBytes("update_info"),
Bytes.toBytes("execute_time"), CompareFilter.CompareOp.GREATER, Bytes.toBytes(hbaseData.get("execute_time")),put);
 
// 执行时间相等时，则去比较偏移量，本次传递的值大于HBase中的值则插入put
if (!res2) {
boolean res3 = table.checkAndPut(Bytes.toBytes(hbaseData.get("id")),
Bytes.toBytes("update_info"), Bytes.toBytes("execute_position"), CompareFilter.CompareOp.GREATER, Bytes.toBytes(hbaseData.get("execute_position")),put);
}
}

四.总结

目前移山的实时同步服务，kafka 消费端是使用一个线程去消费数据；
如果将来有版本升级需求，将消费端改为多个线程去消费数据时，要考虑到多线程消费时有序的消息会被打乱这种情况的解决办法。

Mysql和Redis数据同步策略 - 元思 - 博客园

Wed, 24 Jun 2020 09:55:37 CST

为什么对缓存只删除不更新

不更新缓存是防止并发更新导致的数据不一致。
所以为了降低数据不一致的概率，不应该更新缓存，而是直接将其删除，
然后等待下次发生cache miss时再把数据库中的数据同步到缓存。

先更新数据库还是先删除缓存?

有两个选择：
1. 先删除缓存，再更新数据库
2. 先更新数据库，再删除缓存

如果先删除缓存，有一个明显的逻辑错误：考虑两个并发操作，线程A删除缓存后，线程B读该数据时会发生Cache Miss，然后从数据库中读出该数据并同步到缓存中，此时线程A更新了数据库。
结果导致，缓存中是老数据，数据库中是新数据，并且之后的读操作都会直接读取缓存中的脏数据。（直到key过期被删除或者被LRU策略踢出）
如果数据库更新成功后，再删除缓存，就不会有上面这个问题。
可能是由于数据库优先，第二种方式也被称为Cache Aside Pattern。

Cache Aside Pattern

cache aside在绝大多数情况下能做到数据一致性，但是在极端情况仍然存在问题。

首先更新数据库(A)和删除缓存(B)不是原子操作，任何在A之后B之前的读操作，都会读到redis中的旧数据。
但是，正常情况下操作缓存的速度会很快，通常是毫秒级，出现上述情况的概率很低。
更新完数据库后，线程意外被kill掉，由于没有删除缓存，缓存中的脏数据会一直存在。
线程A读数据时cache miss，从Mysql中查询到数据，还没来得及同步到redis中,
此时线程B更新了数据库并把Redis中的旧值删除。随后，线程A把之前查到的数据同步到了Redis。
显然，此时redis中的是脏数据。
通常数据库读操作比写操作快很多，所以除非线程A在同步redis前意外卡住了，否则发生上述情况的概率极低。

虽然以上情况都有可能发生，但是发生的概率相比“先删除缓存再更新数据库”会低很多。

Read/Write Through Pattern

cache aside是我们自己的应用程序维护两个数据存储系统，而Read/Write Through Pattern是把同步数据的问题交给缓存系统了，应用程序不需要关心。
Read Through是指发生cache miss时，缓存系统自动去数据库加载数据。
Write Through是指如果cache miss，直接更新数据库，然后返回，如果cache hit，则更新缓存后，由缓存系统自动同步到数据库。
以Redis为例，通常我们不会把数据库的数据全部缓存到redis，而是采用一定的数据精简或压缩策略，以节省缓存空间。
就是说，让缓存系统设计出通用的缓存方案不太现实，不过根据自己的业务定制一个在项目内部通用的中间件是可行的。

Write Behind

Write Behind方案在更新数据时，只更新缓存，不更新数据库。而是由另外一个服务异步的把数据更新到数据库。
逻辑上，和Linux中的write back很类似。这个设计的好处是，I/O操作很快，因为是纯内存操作。
但是由于异步写库，可能要牺牲一些数据一致性，譬如突然宕机会丢失所有未写入数据库的内存数据。

阿里巴巴的Canal中间件是一种相反的设计，它先更新mysql，然后通过binlog把数据自动同步到redis。
这种方案会全量同步数据到redis，不适合只缓存热点数据的应用。

总结

以上没有哪种方案是完美的，都无法做到强一致性。
我们总要在性能和数据准确性之间做出妥协。

https://www.pixelstech.net/article/1562504974-Consistency-between-Redis-Cache-and-SQL-Database
https://coolshell.cn/articles/17416.html
为什么不更新缓存，而是直接删除

otter 数据同步项目 at master · alibaba/otter · GitHub

Sun, 21 Jun 2020 19:08:27 CST

环境搭建 & 打包

环境搭建：

进入$otter_home目录
执行：mvn clean install
导入maven项目。如果eclipse下报"Missing artifact com.oracle:ojdbc14:jar:10.2.0.3.0"，修改$otter_home/pom.xml中"${user.dir}/lib/ojdbc14-10.2.0.3.0.jar"为绝对路径，比如"d:/lib/ojdbc14-10.2.0.3.0.jar"

打包：

进入$otter_home目录
执行：mvn clean install -Dmaven.test.skip -Denv=release
发布包位置：$otter_home/target

项目背景

阿里巴巴B2B公司，因为业务的特性，卖家主要集中在国内，买家主要集中在国外，所以衍生出了杭州和美国异地机房的需求，同时为了提升用户体验，整个机房的架构为双A，两边均可写，由此诞生了otter这样一个产品。

otter第一版本可追溯到04~05年，此次外部开源的版本为第4版，开发时间从2011年7月份一直持续到现在，目前阿里巴巴B2B内部的本地/异地机房的同步需求基本全上了otte4。

目前同步规模：

同步数据量6亿
文件同步1.5TB(2000w张图片)
涉及200+个数据库实例之间的同步
80+台机器的集群规模

项目介绍

名称：otter ['ɒtə(r)]

译意：水獭，数据搬运工

语言：纯java开发

定位：基于数据库增量日志解析，准实时同步到本机房或异地机房的mysql/oracle数据库. 一个分布式数据库同步系统

工作原理

原理描述：

1. 基于Canal开源产品，获取数据库增量日志数据。什么是Canal, 请点击

2. 典型管理系统架构，manager(web管理)+node(工作节点)

a. manager运行时推送同步配置到node节点

b. node节点将同步状态反馈到manager上

3. 基于zookeeper，解决分布式状态调度的，允许多node节点之间协同工作.

什么是canal?

otter之前开源的一个子项目，开源链接地址： http://github.com/alibaba/canal

Introduction

See the page for introduction: Introduction.

QuickStart

See the page for quick start: QuickStart.

AdminGuide

See the page for admin deploy guide : AdminGuide

常见问题

See the page for FAQ: FAQ

版本相关:

1. 建议版本：4.2.15 (otter开源版本从内部演变而来，所以初始版本直接从4.x开始)

2. 下载发布包： download

3. maven依赖：暂无

问题反馈

注意：canal&otter QQ讨论群已经建立，群号：161559791 ，欢迎加入进行技术讨论。

1.qq交流群： 161559791

2.邮件交流： jianghang115@gmail.com

3.新浪微博： agapple0002

4.报告issue： issues

MySQL 双活同步复制的四种方案_咸鱼的梦想专栏-CSDN博客_mysql双机同步复制

Fri, 19 Jun 2020 16:17:07 CST

对于数据实时同步，其核心是需要基于日志来实现，是可以实现准实时的数据同步，基于日志实现不会要求数据库本身在设计和实现中带来任何额外的约束。

基于MySQL原生复制主主同步方案

这是常见的方案，一般来说，中小型规模的时候，采用这种架构是最省事的。

两个节点可以采用简单的双主模式，并且使用专线连接，在master_A节点发生故障后，应用连接快速切换到master_B节点，反之也亦然。有几个需要注意的地方，脑裂的情况，两个节点写入相同数据而引发冲突，同时把两个节点的auto_increment_increment（自增步长）和auto_increment_offset（自增起始值）设成不同值。其目的是为了避免master节点意外宕机时，可能会有部分binlog未能及时复制到slave上被应用，从而会导致slave新写入数据的自增值和原先master上冲突了，因此一开始就使其错开；当然了，如果有合适的容错机制能解决主从自增ID冲突的话，也可以不这么做，使用更新的数据版本5.7+，可以利用多线程复制的方式可以很大程度降低复制延迟，同时，对复制延迟特别敏感的另一个备选方案，是semi-sync半同步复制，基本上无延迟，不过事务并发性能会有不小程度的损失，特别是在双向写的时候，需要综合评估再决定。

基于Galera replication方案

Galera是Codership提供的多主数据同步复制机制，可以实现多个节点间的数据同步复制以及读写，并且可保障数据库的服务高可用及数据一致性，基于Galera的高可用方案主要有MariaDB Galera Cluster和Percona XtraDB Cluster（简称PXC）。

目前PXC用的会比较多一些，数据严格一致性，尤其适合电商类应用，不过PXC也是有其局限性的，如果并发事务量很大的话，建议采用InfiniBand网络，降低网络延迟，因为PXC存在写扩大以及短板效应，并发效率会有较大损失，类似semi-sync半同步复制，Gelera实际只能用三个节点，网络抖动造成的性能和稳定性习惯性问题

基于Group Replication方案

通过Paxos协议提供数据库集群节点数据强一致保证，MGR准确来说是MySQL官方推出的高可用解决方案，基于原生复制技术，并以插件的方式提供，并且集群间所有节点可写入，解决了单个集群的写入性能，所有节点都能读写，解决网络分区导致的脑裂问题，提升复制数据的可靠性，不过现实还是有些残酷，目前尝鲜的并不是很多，同时仅支持InnoDB表，并且每张表一定要有一个主键，用于做write set的冲突检测，必须打开GTID特性，二进制日志格式必须设置为ROW，用于选主与write set

COMMIT可能会导致失败，类似于快照事务隔离级别的失败场景，目前一个MGR集群最多支持9个节点，不支持外键于save point特性，无法做全局间的约束检测与部分部分回滚，二进制日志不支持binlog event checksum

基于canal方案

对于数据库的实时同步，阿里巴巴专门有一个开源项目，即otter来实现分布式数据库的同步复制，其核心思想仍然是通过获取数据库的增量数据日志，来进行准实时的同步复制。因此otter本身又依赖于另外一个开源项目即canal，该项目重点则是获取增量数据库同步日志信息。

当前otter的重点是实现mysql间的数据库同步复制，基本即利用的类似技术来实现两个mysql数据库间的双向同步数据库复制。要注意这个双向本身指既可以A->B，也可以从B->A，在某个时间节点本身是单向的。

主从复制分成三步：

master将改变记录到二进制日志(binary log)中（这些记录叫做二进制日志事件，binary log events，可以通过show binlog events进行查看）；

slave将master的binary log events拷贝到它的中继日志(relay log)；

slave重做中继日志中的事件，将改变反映它自己的数据。

canal原理相对比较简单：

canal模拟mysql slave的交互协议，伪装自己为mysql slave，向mysql master发送dump协议

mysql master收到dump请求，开始推送binary log给slave(也就是canal)
canal解析binary log对象(原始为byte流)

更多参考 https://github.com/alibaba/canal

12c ADG的同步和异步灾备方案

Thu, 18 Jun 2020 11:18:34 CST

Jian Zhang

概述

================

Active Data Guard Far Sync是Oracle 12c的新功能（也称为Far Sync Standby），Far Sync功能的实现是通过在距离主库(Primary Database)相对较近的地点配置Far Sync实例，主库(Primary Database) 同步(synchronous)传输redo到Far Sync实例，然后Far Sync实例再将redo异步(asynchronous)传输到终端备库(Standby Database)。这样既可以保证零数据丢失又可以降低主库压力。Far Sync实例只有密码文件，init参数文件和控制文件，而没有数据文件。

如果redo 传输采用Maximum Availability模式，我们可以在距离生产中心(Primary Database)相对较近的地点配置Far Sync实例，主库(Primary Database)同步(synchronous)传输redo到Far Sync实例，保证零数据丢失（zero data loss），同时主库和Far Sync距离较近，网络延时很小，因此对主库性能影响很小。然后Far Sync实例再将redo异步(asynchronous)发送到终端备库(Standby Database)。

如果redo 传输采用Maximum Performance模式，我们可以在距离生产中心(Primary Database)相对较近的地点配置Far Sync实例，主库(Primary Database) 异步传输redo到Far Sync实例，然后Far Sync实例再负责传输redo到其他多个终端备库(Standby Database)。这样可以减少主库向多个终端备库(Standby Database)传输redo的压力（offload）。

Far Sync配置对于Data Guard 角色转换(role transitions)是透明的，即switchover/failover命令方式与12c之前相同。

考虑到可能发生Data Guard 角色转换，即switchover/failover，可以在距离备库较近的地方也配置Far Sync实例，这个Far Sync实例只有在当前的备库切换为主库后才启用。

考虑到Far Sync实例的单点故障，可以在距离主库交近的地点配置2个Far Sync实例，起到备用的作用。

本文重点是测试Far Sync安装配置。

Far Sync示意图

================

创建配置Far Sync

================

1. 创建Data Guard，方法与11.2相同，详细过程参考《 Active Database Duplication for A standby database》

2. 创建配置Far Sync实例，Far Sync实例只有密码文件，init参数文件和控制文件，而没有数据文件。

创建Far Sync实例的控制文件，在主库执行：

SQL> ALTER DATABASE CREATE FAR SYNC INSTANCE CONTROLFILE AS '/tmp/controlfs01.ctl';

3. 设置主库redo同步传输到Far Sync实例，修改主库LOG_ARCHIVE_DEST_2参数：

LOG_ARCHIVE_DEST_2='SERVICE=dg12cfs SYNC AFFIRM MAX_FAILURE=1 ALTERNATE=LOG_ARCHIVE_DEST_3

VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=dg12cfs'

4. 设置Far Sync实例异步传输redo到备库，修改Far Sync实例LOG_ARCHIVE_DEST_2参数：

LOG_ARCHIVE_DEST_2='SERVICE=dg12cs ASYNC

VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE) DB_UNIQUE_NAME=dg12cs'

5. 为了解决Far Sync实例的单点故障，可以在距离主库较近的地点配置2个Far Sync实例。

6. 创建完成后确认：

SQL> select * from V$DATAGUARD_CONFIG;

DB_UNIQUE_NAME PARENT_DBUN DEST_ROLE CURRENT_SCN CON_ID

------------------------------ ------------------------------ ----------------- ----------- ----------

dg12cfs dg12cp FAR SYNC INSTANCE 682995 0

dg12cs dg12cfs PHYSICAL STANDBY 682995 0

dg12cp NONE PRIMARY DATABASE 683138 0

详细配置过程和测试案例请参考附件： Oracle_12c_Active_Data_Guard_Far_Sync_v1.pdf

Oracle GoldenGate系统之----双向同步数据表_ITPUB博客

Fri, 05 Jun 2020 16:57:59 CST

双向同步与单向同步类似，但需要着重注意两个问题：防止数据循环和防止数据冲突。
1、防止数据循环
在EXTRACT进程中忽略REPLICAT的事务，一般排除提取用户的操作，并且与需要同步的用户分开
如USERID SCOTT,PASSWORD TIGER
TRANLOGOPTIONS EXCLUDEUSER SCOTT
2、防止数据冲突
一般要从应用层面解决，避免操作相同的数据。

以下是配置步骤和参数。假设是A、B两个库之间的同步配置。
从A到B
-- 管理进程配置
GGSCI (dgrac) 1> edit param mgr

PORT 7801
DYNAMICPORTLIST 7802-7820
AUTOSTART ER *
AUTORESTART ER *,RETRIES 3,WAITMINUTES 2,RESETMINUTES 60
STARTUPVALIDATIONDELAY 5
PURGEOLDEXTRACTS ./dirdat/*,USECHECKPOINTS,MINKEEPDAYS 7

--EXTRACT配置
GGSCI (dgrac) 2> add extract exts1,tranlog,begin now
EXTRACT added.

GGSCI (dgrac) 3> edit param exts1
extract exts1
setenv(NLS_LANG=AMERICAN_AMERICA.ZHS16GBK)
userid scott@wailon,passwordtiger
tranlogoptions excludeuser scott
exttrail /u01/app/ogg/dirdat/l1
table lrj.s1;

GGSCI (dgrac) 4> add exttrail /u01/app/ogg/dirdat/l1,extract exts1
EXTTRAIL added.

-- PUMP配置
GGSCI (dgrac) 5> add extract pumps1 ,exttrailsource /u01/app/ogg/dirdat/l1,begin now
EXTRACT added.

GGSCI (dgrac) 6> edit param pumps1
extract pumps1
setenv(NLS_LANG="AMERICAN_AMERICA.ZHS16GBK")
userid scott @wailon,password tiger
rmthost 192.168.56.101,mgrport 7801
rmttrail /u01/app/ogg/dirdat/s1
PASSTHRU
table lrj.s1;

GGSCI (dgrac) 7> add rmttrail /u01/app/ogg/dirdat/s1,extract pumps1
RMTTRAIL added.

--REPLICAT配置

GGSCI (dgrac) 8> edit param reps1
replicat reps1
setenv(NLS_LANG=AMERICAN_AMERICA.ZHS16GBK)
userid scott @wailon, password tiger
assumetargetdefs
reperror default,discard
discardfile /u01/app/ogg/dirout/reps1.dsc,append,megabytes 100
map lrj.s1,target lrj.s1,&
colmap(usedefaults,"ENAME" = "USERNAME"),&
-- 解决冲突，更新记录不存在时插入，但只插入更新的列，其他列为空，还是要人工处理
RESOLVECONFLICT (UPDATEROWMISSING, (DEFAULT, OVERWRITE));
HANDLECOLLISIONS

-- 启动所有进程
GGSCI (dgrac) 9> start mgr
MGR is already running.

GGSCI (dgrac) 10> info all

Program Status Group Lag at Chkpt Time Since Chkpt

MANAGER     RUNNING
EXTRACT     RUNNING     EXTS1       00:00:00      00:00:09
EXTRACT     RUNNING     PUMPS1      00:00:00      00:00:07
REPLICAT    RUNNING     REPS1       00:00:00      00:00:05

从B到A

--管理进程配置
GGSCI (dg) 1> edit param mgr

PORT 7801
DYNAMICPORTLIST 7802-7820
AUTOSTART ER *
AUTORESTART ER *,RETRIES 3,WAITMINUTES 2,RESETMINUTES 60
STARTUPVALIDATIONDELAY 5
PURGEOLDEXTRACTS ./dirdat/*,USECHECKPOINTS,MINKEEPDAYS 7

-- EXTRACT配置
GGSCI (dg) 2> add extract exts1,tranlog,begin now
EXTRACT added.

GGSCI (dg) 3> edit param exts1
extract exts1
setenv(NLS_LANG=AMERICAN_AMERICA.ZHS16GBK)
userid scott@ogg,passwordtiger
tranlogoptions excludeuser scott
exttrail /u01/app/ogg/dirdat/l1
table lrj.s1;

GGSCI (dg) 4> add exttrail /u01/app/ogg/dirdat/l1,extract exts1
EXTTRAIL added.

--PUMP配置
GGSCI (dg) 5> add extract pumps1 ,exttrailsource /u01/app/ogg/dirdat/l1,begin now
EXTRACT added.

GGSCI (dg) 6> edit param pumps1
extract pumps1
setenv(NLS_LANG="AMERICAN_AMERICA.ZHS16GBK")
userid scott@ ogg,password tiger
rmthost 192.168.56.131,mgrport 7801
rmttrail /u01/app/ogg/dirdat/s1
PASSTHRU
table lrj.s1;

GGSCI (dg) 7> add rmttrail /u01/app/ogg/dirdat/s1,extract pumps1
RMTTRAIL added.

-- REPLICAT配置

GGSCI (dg) 8> edit param reps1
replicat reps1
setenv(NLS_LANG=AMERICAN_AMERICA.ZHS16GBK)
userid scott @ogg, password tiger
assumetargetdefs
reperror default,discard
discardfile /u01/app/ogg/dirout/reps1.dsc,append,megabytes 100
map lrj.s1,target lrj.s1,&
colmap(usedefaults,"ENAME" = "USERNAME"),&
RESOLVECONFLICT (UPDATEROWMISSING, (DEFAULT, OVERWRITE));
HANDLECOLLISIONS

-- 启动所有进程
GGSCI (dg) 9> start mgr
MGR is already running.

GGSCI (dg) 10> info all

Program Status Group Lag at Chkpt Time Since Chkpt

MANAGER     RUNNING
EXTRACT     RUNNING     EXTS1       00:00:00      00:00:09
EXTRACT     RUNNING     PUMPS1      00:00:00      00:00:07
REPLICAT    RUNNING     REPS1       00:00:00      00:00:05

数据测试
B端插入：
02:44:09 LRJ@ogg>select* from s1
02:44:12 2 /

     EMPNO USERNAME   JOB              MGR HIREDATE            SAL       COMM     DEPTNO
---------- ---------- --------- ---------- ------------ ---------- ---------- ----------
      7369 SMITH      CLERK           7902 17-DEC-80          1000        100         20
      7499 ALLEN      SALESMAN        7698 20-FEB-81          1800        400         30
      7521 WARD       SALESMAN        7698 22-FEB-81          1450        600         30
      7566 JONES      MANAGER         7839 02-APR-81          3175        100         20
      7654 MARTIN     SALESMAN        7698 28-SEP-81          1450       1500         30
      7698 BLAKE      MANAGER         7839 01-MAY-81          3050        100         30
      7782 CLARK      MANAGER         7839 09-JUN-81          2650        100         10
      7788 SCOTT      ANALYST         7566 19-APR-87          3200        100         20
      7839 KING       PRESIDENT            17-NOV-81          5200        100         10
      7844 TURNER     SALESMAN        7698 08-SEP-81          1700        100         30
      7876 ADAMS      CLERK           7788 23-MAY-87          1300        100         20
      7900 JAMES      CLERK           7698 03-DEC-81          1150        100         30
      7902 FORD       ANALYST         7566 03-DEC-81          3200        100         20
      7934 MILLER     CLERK           7782 23-JAN-82          1500        100         10
      2000 yojan

15 rows selected.

02:45:41 LRJ@ogg>insertinto s1(empno,username,sal) values(4000,'GZITECH',2000);

1 row created.

02:45:46 LRJ@ogg>commit;

Commit complete.

A端查看：
02:45:50 LRJ@ogg>select* from s1;

16 rows selected.

A端插入：
09:34:18 LRJ@wailon>insertinto s1(empno,ename,job) values(3000,'WAILON','CLERK');

1 row created.

09:34:40 LRJ@wailon>commit;

Commit complete.

B端查看：
09:34:42 LRJ@wailon>select* from s1;

17 rows selected.

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/429786/viewspace-1062584/，如需转载，请注明出处，否则将追究法律责任。

MySQL 同步复制及高可用方案总结

Thu, 09 Apr 2020 12:11:16 CST

1.前言

mysql作为应用程序的数据存储服务，要实现mysql数据库的高可用。必然要使用的技术就是数据库的复制，如果主节点出现故障可以手动的切换应用到从节点，这点相信运维同学都是知道，并且可以实现的。但是这种情况只是手动的切换，对可用性有要求的业务需要分别实现主库和从库的高可用，保障在数据库出现down机的情况下，可以自动实现数据库的故障转移，保障应用的可用性和用户体验。

本文将会对一些常用的数据库高可用方案进行介绍，根据你不同的场景，选择合适的高可用方案即可。

2.MMM高可用方案

2.1.Mysql-MMM介绍

MMM(Master-Master replication managerfor Mysql，Mysql主主复制管理器)是一套灵活的脚本程序，基于perl实现，用来对mysql replication进行监控和故障迁移，并能管理mysql Master-Master复制的配置(同一时间只有一个节点是可写的)。

2.2.组件

mmm_mond：监控进程，负责所有的监控工作，决定和处理所有节点角色活动。此脚本需要在监管机上运行。

mmm_agentd：运行在每个mysql服务器上的代理进程，完成监控的探针工作和执行简单的远端服务设置。此脚本需要在被监管机上运行。

mmm_control：一个简单的脚本，提供管理mmm_mond进程的命令。

mysql-mmm的监管端会提供多个虚拟IP（VIP），包括一个可写VIP，多个可读VIP，通过监管的管理，这些IP会绑定在可用mysql之上，当某一台mysql宕机时，监管会将VIP迁移至其他mysql。

在整个监管过程中，需要在mysql中添加相关授权用户，以便让mysql可以支持监理机的维护。授权的用户包括一个mmm_monitor用户和一个mmm_agent用户，如果想使用mmm的备份工具则还要添加一个mmm_tools用户。

2.3.架构图

正常工作时：

主节点故障时：

2.4.MMM优点

（1）高可用性，扩展性好，出现故障自动转移，对于主主同步，在同一时间只提供一台数据库写操作，保证数据的一致性。

（2）配置简单，容易操作。

2.5.MMM缺点

（1）需要一台备份服务器，浪费资源

（2）需要多个虚拟IP

（3）agent可能意外终止，引起裂脑。

3.MHA介绍

MHA（Master High Availability）目前在MySQL高可用方面是一个相对成熟的解决方案，它由日本DeNA公司youshimaton（现就职于Facebook公司）开发，是一套优秀的作为MySQL高可用性环境下故障切换和主从提升的高可用软件。在MySQL故障切换过程中，MHA能做到在0~30秒之内自动完成数据库的故障切换操作，并且在进行故障切换的过程中，MHA能在最大程度上保证数据的一致性，以达到真正意义上的高可用。

3.1.MHA架构介绍

该软件由两部分组成：MHA Manager（管理节点）和MHA Node（数据节点）。MHA Manager可以单独部署在一台独立的机器上管理多个master-slave集群，也可以部署在一台slave节点上。MHA Node运行在每台MySQL服务器上，MHA Manager会定时探测集群中的master节点，当master出现故障时，它可以自动将最新数据的slave提升为新的master，然后将所有其他的slave重新指向新的master。整个故障转移过程对应用程序完全透明。

在MHA自动故障切换过程中，MHA试图从宕机的主服务器上保存二进制日志，最大程度的保证数据的不丢失(配合mysql半同步复制效果更佳)，但这并不总是可行的。例如，如果主服务器硬件故障或无法通过ssh访问，MHA没法保存二进制日志，只进行故障转移而丢失了最新的数据。使用MySQL 5.5的半同步复制，可以大大降低数据丢失的风险。MHA可以与半同步复制结合起来。如果只有一个slave已经收到了最新的二进制日志，MHA可以将最新的二进制日志应用于其他所有的slave服务器上，因此可以保证所有节点的数据一致性。

注意：目前MHA主要支持一主多从的架构，要搭建MHA,要求一个复制集群中必须最少有三台数据库服务器，一主二从，即一台充当master，一台充当备用master，另外一台充当从库，因为至少需要三台服务器，出于机器成本的考虑，淘宝也在该基础上进行了改造，目前淘宝TMHA已经支持一主一从。

3.2.MHA架构图

正常工作时架构图：

主库down机时架构：

3.3.故障转移过程

（1）从宕机崩溃的master保存二进制日志事件（binlog events）;

（2）识别含有最新更新的slave；

（3）应用差异的中继日志（relay log）到其他的slave；

（4）应用从master保存的二进制日志事件（binlog events）；

（5）提升一个slave为新的master；

（6）使其他的slave连接新的master进行复制；

（7）在新的master启动vip地址，保证前端请求可以发送到新的master。

3.4.MHA优点

（1）不需要备份服务器

（2）不改变现有环境

（3）操作非常简单

（4）可以进行日志的差异修复

（5）可以将任意slave提升为master

3.5.MHA缺点

（1）需要全部节点做ssh秘钥

（2）MHA出现故障后配置文件会被修改，如果再次故障转移需要重新修改配置文件。

（3）自带的脚本还需要进一步补充完善，且用perl开发，二次开发困难。

4.DRBD+（heartbeat,corosync）

4.1. 方案简介

本方案采用Heartbeat或者corosync双机热备软件来保证数据库的高稳定性和连续性，数据的一致性由DRBD这个工具来保证（如果可以尽量放到分布式存储上面）。默认情况下只有一台mysql在工作，当主mysql服务器出现问题后，系统将自动切换到备机上继续提供服务，当主数据库修复完毕，又将服务切回继续由主mysql提供服务。

4.2. 组件

Heartbeat,corosync作为心跳检测机制，监控primary节点的状态。当主节点宕掉之后，迅速提升secondary节点为新的主节点，并切换IP；

drbd负责数据同步

4.3. 架构图

4.4. 数据同步过程

mysql进行刷盘时，会通过不同的sync方式，最终将数据写入disk；

drbd收到刷盘成功的信息后，将对应的磁盘块位置，和变更动作，通过网络传递至secondary节点；

secondary的drbd接收到变更信息后，将这些信息落盘；

4.5. 切换过程

前提：secondary节点的mysql服务不启动；

heartbeat检测到primary的mysql服务停止，则摘掉IP、umount掉数据盘、将primary切换为secondary；

在原来的secondary上，提升drbd同步为primary，挂载数据盘，启动mysql服务、绑定IP；

从库跟着IP和端口自动进行迁移；

4.6. 方案优点

（1）历史悠久、安全性高、稳定性高、可用性高、出现故障自动切换。

（2）数据一致性强

4.7. 方案缺点

（1）需要一台备份服务器，浪费资源

（2）不方便扩展

（3）无论drbd还是headbetart，corosync都可能发生裂脑

5.Mysql route介绍

5.1.什么是mysql route

MySQL Router是处于应用client和dbserver之间的轻量级代理程序，它能检测，分析和转发查询到后端数据库实例，并把结果返回给client。是mysql-proxy的一个替代品。其架构图和功能如下。

（1）Router实现读写分离，程序不是直接连接数据库IP，而是固定连接到mysql router。MySQL Router对前端应用是透明的。应用程序把MySQL Router当作是普通的mysql实例，把查询发给MySQL Router,而MySQL Router会把查询结果返回给前端的应用程序。

（2）从数据库服务器故障，业务可以正常运行。由MySQL Router来进行自动下线不可用服务器。程序配置不需要任何修改。

（3）主数据库故障，由MySQL Router来决定主从自动切换，业务可以正常访问。程序配置不需要做任何修改。

5.2.读写分离原理

MySQL Router接受前端应用程序请求后，根据不同的端口来区分读写，把连接读写端口的所有查询发往主库，把连接只读端口的select查询以轮询方式发往多个从库，从而实现读写分离的目的。读写返回的结果会交给MySQL Router,由MySQL Router返回给客户端的应用程序。

5.3.Mysql router用途

MySQL Router的主要用途是读写分离，主主故障自动切换，负载均衡，连接池等。

5.4.Mysql router主主故障自动切换的坑

Mysql router主主故障切换功能经过测试没有问题，但是有一个比较大的坑需要注意，主库发生切换之后，从库的连接的master服务器地址不会发生改变，需要自己写脚本进行判断。

5.5.优点

（1）基于DAL层实现mysql的高可用。

（2）可以同时实现主主故障切换和读写分离。

（3）插件式架构允许用户进行额外的功能扩展。

5.6.缺点

（1）高可用功能需要进一步完善：存在主库切换之后，从库不会自动切换主库地址的坑。

（2）读写情况使用不同端口，需要修改应用程序。

6.mysql Cluster

国内用的非常少，主要因为一下三点：

（1）需要更改存储引擎

（2）付费

（3）国内几乎没有使用案例

优点：

高可用，可用率达99.999%

7.结束语

上面的高可用方案，只是我自己比较熟悉的，而且也是应用比较多的。mysql毕竟发展了有20多年了，各种高可用方案还是很多的，其他的高可用方案各位钥匙有兴趣，可以自己研究。

彻底终结MySQL同步延迟问题 - 简书

Tue, 24 Mar 2020 08:46:53 CST

作为一名DBA，在工作中会经常遇到一些MySQL主从同步延迟的问题，这些同步慢的问题，其实原因非常多，可能是因为主从的网络问题导致，可能是因为网络带宽问题导致，可能是因为大事务导致，也可能是因为单线程复制导致的延迟。最近遇到一个很典型的同步延迟问题，将分析过程写出来，希望对广大DBA在排查同步延迟问题有比较系统的方法论。

首先交代一下背景（不交代背景和场景的问题分析都是耍流氓）

最近有一组DB出现比较大的延迟，这组DB是专门用来存储监控数据，每分钟会使用load data的方式导入大量的数据。为了节省空间，将原来使用压缩表的innodb引擎转换成了TokuDB引擎，使用的版本和引擎如下：

MySQL Version： 5.7

Storage Engine： TokuDB

转换后，发现主从延迟逐渐增大，基本每天落后主机大概50个binlog左右，大概延迟7.5个小时左右的数据，主机每天大概产生160个binlog，binlog列表如下图所示：

由于对该业务非常熟悉，因此很快就定位到造成主从同步延迟的原因，并很快就解决了延迟的问题。这里不直接说解决办法，而是想描述一套完整的解决主从延迟问题的思考方式，和大家一起来系统的做一些思考。带着问题去思考延迟的根本原因和解决办法。我想，这也许会更有意义。授人以鱼，不如授人以渔。接下来我们就一起开脑洞。

首先，既然产生了主从延迟，就说明在从机上的消费速度赶不上主机binlog产生的速度。我们先来思考一下可能的原因，并根据现场的蛛丝马迹去验证猜想的正确性。其实所谓的问题排查，就是提出可能问题猜想，然后不断去证明的过程。不同的是，每个人的经验不同，排查的质量也不尽头相同，仅此而已。那就来从各个可能的方面开脑洞吧。

网络

网络可能导致主从延迟的问题，比如主机或者从机的带宽打满、主从之间网络延迟很大，有可能会导致主上的binlog没有全量传输到从机，造成延迟。

我的那组DB的IO线程已经将对应的binlog近乎实时的拉取到了从机DB上，基本排除网络导致的延迟。还可以结合网络质量相关监控来进一步确认是网络的问题。

机器性能

从机使用了烂机器？之前有遇到过有的业务从机使用了很烂的机器，导致的主从延迟。比如主机使用SSD而从机还是使用的SATA。从机用烂机器的观念需要改改，随着DB自动切换的需求越来越高，尤其是我所在的金融行业，从机至少不要比主机配置差。

从机高负载？有很多业务会在从机上做统计，把从机服务器搞成高负载，从而造成从机延迟很大的情况，这种使用top命令即可快速发现。

从机磁盘有问题？磁盘、raid卡、调度策略有问题的情况下，有的时候会出现单个IO延迟很高的情况，比如raid卡电池充放电的时候，在没有设置强行write back的情况下得会将write back模式修改为write through。使用iostat命令查看DB数据盘的IO情况，是否是单个IO的执行时间很长，块大小和磁盘队列情况等，可以比较一下DB盘的IO调度规则以及块大小的设置等。使用iostat查看IO运行情况：

从IO情况看也没什么问题，单个IO延迟很小，iops很低，写带宽也不大。调度规则（cat /sys/block/fioa/queue/scheduler）和块大小等和主机设置是一样的，排除磁盘的问题。

从运行指标看，机器负载很低，机器性能也可以排除。

大事务

是否是经常会有大事务？这个可能广大DBA们会遇到比较多，比如在RBR模式下，执行带有大量的delete操作，或者在MBR模式下删除的时候添加了不确定语句（类似limit），又或者一个表的alter操作等，都会导致延迟情况的发生。这种通过查看processlist相关信息以及使用mysqlbinlog查看binlog中的SQL就能快速进行确认。这个设想也被排除。

锁

锁冲突问题也可能导致从机的SQL线程执行慢，比如从机上有一些select .... for update的SQL，或者使用了MyISAM引擎等。此类问题，可以通过抓去processlist以及查看information_schema下面和锁以及事务相关的表来查看。

经过排查也并未发现锁的问题。

参数

参数部分使用如果是innodb引擎，可以根据自己的使用环境调整innodb_flush_log_at_trx_commit、sync_binlog参数来提升复制速度，那组DB使用的TokuDB，则可以优化tokudb_commit_sync、tokudb_fsync_log_period、sync_binlog等参数来做调整。这些参数调整后，复制的延迟情况会有一些作用。

备注：这种调整可能会影响数据的安全性，需要结合业务来考虑。

多线程

多线程问题可能是DBA们遇到最多的问题，之前在5.1和5.5版本，mysql的单线程复制瓶颈就广受诟病。从5.6开始mysql正式支持多线程复制。

很容易想到，如果是单线程同步的话，单个线程存在写入瓶颈，导致主从延迟。那就先调整为多线程试试效果。

可以通过show processlist查看是否有多个同步线程，也可以查看参数的方式查看是否使用多线程（show variables like '%slave_parallel%'）

当你看到是上图这种结果的时候，恭喜你，你使用的是单线程。使用下面那行命令改造成多线程复制：

STOP SLAVE SQL_THREAD;SET GLOBAL slave_parallel_type='LOGICAL_CLOCK';SET GLOBAL slave_parallel_workers=8;START SLAVE SQL_THREAD;

改造后如下图所示：

我的环境如上图所示，本来就已经是多线程复制了，因此问题的根源也不在是否开启多线程复制上。但是当我使用show processlist查看复制状态的时候，大多数情况下发现只有1个SQL线程在执行，如下图所示：

通过上面的图可以发现，基本都是一个线程在执行，那么可以初步判定是多线程的威力没有得到很好的发挥，为了更有力地说明问题，想办法统计出来每个同步线程使用的比率。统计方法如下:

1、将线上从机相关统计打开（出于性能考虑默认是关闭的），打开方法可以如下如下SQL：

UPDATE performance_schema.setup_consumers SET ENABLED = 'YES' WHERE NAME LIKE 'events_transactions%';

UPDATE performance_schema.setup_instruments SET ENABLED = 'YES', TIMED = 'YES'WHERE NAME = 'transaction';

2、创建一个查看各个同步线程使用量的视图，代码如下：

USE test;

CREATE VIEW rep_thread_count AS SELECT a.THREAD_ID AS THREAD_ID,a.COUNT_STAR AS COUNT_STAR FROM performance_schema.events_transactions_summary_by_thread_by_event_name a WHERE a.THREAD_ID in (SELECT b.THREAD_ID FROM performance_schema.replication_applier_status_by_worker b);

3、一段时间后，统计各个同步线程的使用比率，SQL如下:

SELECT SUM(COUNT_STAR) FROMrep_thread_count INTO @total;

SELECT 100*(COUNT_STAR/@total) AS thread_usage FROMrep_thread_count;

结果如下：

从上面的结果我们可以看出，绝大多数情况下，都是一个线程在跑，在监控这种存在大量数据导入的场景，肯定容易出现瓶颈。如果能提高各个线程并发执行的能力，可能很好地改善同步延迟的情况，那该如何来解决呢？

组提交

我们不妨从多线程同步的原理来思考，在5.7中，多线程复制的功能有很很大的改善，支持LOGICAL_CLOCK的方式，在这种方式下，并发执行的多个事务只要能在同一时刻commit，就说明线程之间没有锁冲突，那么master就可以将这一组的事务标记并在slave机器上安全的进行并发执行。因此，可以尽可能地使所有线程能在同一时刻提交，这样就能很大程度上提升从机的执行的并行度，从而减少从机的延迟。

有了这个猜想后，很自然想到了人为控制尽可能多地使所有线程在同一时刻提交，其实官方已经给我们提供了类似的参数，参数如下：

binlog_group_commit_sync_delay

#参数说明见： https://dev.mysql.com/doc/refman/5.7/en/replication-options-binary-log.html#sysvar_binlog_group_commit_sync_delay

备注：这个参数会对延迟SQL的响应，对延迟非常敏感的环境需要特别注意，单位是微秒

binlog_group_commit_sync_no_delay_count

#参数说明见： https://dev.mysql.com/doc/refman/5.7/en/replication-options-binary-log.html#sysvar_binlog_group_commit_sync_no_delay_count

备注：这个参数取到了一定的保护作用，在达到binlog_group_commit_sync_no_delay_count设定的值的时候，不管是否达到了binlog_group_commit_sync_delay设置定的阀值，都立即进行提交。

由于是监控的DB，主要是load数据，然后展示，1秒左右的导入延迟对业务没什么影响，因此将两个参数调整为：

SET GLOBAL binlog_group_commit_sync_delay = 1000000;

SET GLOBAL binlog_group_commit_sync_no_delay_count = 20;

#备注，这两个参数请根据业务特性进行调整，以免造成线上故障。

为了防止导入SQL堆积，设置SET GLOBAL binlog_group_commit_sync_no_delay_count为20，在达到20个事务的时候不管是否达到了1秒都进行提交。减少对业务的影响。

设置完这两个参数后，发现并发复制瞬间提升了好多，很多时候8个线程都能跑满。于是将线程调整到16个。运行一段事件后，再次统计各个同步线程的使用比率，发现并发度提升了非常多，新的比率如下图所示：

通过show slave status查看，发现从机延迟越来越小，目前已经完全追上，并稳定运行了一周。

回顾总结

最后，简单总结一下：

在遇到主从延迟的问题的时候，可以从如下几个地方开脑洞，寻找蛛丝马迹，找到问题的根源，对症下药，药到病除，排查范围包括但不限于如下几方面：

网络方面

性能方面

配置方面（参数优化）

大事务

锁

多线程复制

组提交

通过上面对整个问题排查的梳理，希望广大DBA遇到类似复制延迟的问题都能彻底终结。

参考资料：

https://dev.mysql.com/doc/refman/5.7/en/replication-options-binary-log.html

https://www.percona.com/blog/2016/02/10/estimating-potential-for-mysql-5-7-parallel-replication/

百万级商品数据实时同步，查询结果秒出

Sat, 21 Mar 2020 00:00:00 CST

前阵子老板安排了一个新任务，要建设一个商家商品搜索系统，能够为用户提供快速、准确的搜索能力，在用户输入搜索内容时，要能从商家名称和商品名称两个维度去搜索，搜索出来的结果，按照准确率排序，并按商家所属商品的关联关系，来组合数据结构，同时提供API给业务系统调用。

背景很简单，现实蛮复杂！我们面临以下几个难题： ①商家数据库和商品数据库是多台不同的服务器，并且数据量达百万级，如何才能实现跨数据库的数据同步呢？
②商家和商品的数据是有从属关系的，不然就会把肯德基的香辣鸡腿堡挂到麦当劳去，这就尴尬了！
③商家商品数据是经常更新的，比如修改价格、库存、上下架等，那搜索服务可不能搜出一堆过时的数据，如果客户明明搜出来的商品，点进去后却已下架了，那么客户就要吐槽了！如何实现搜索数据与源数据库增删改均实时同步呢？
带着以上3个问题，我们开始了搜索服务的整体架构设计。

系统架构设计思路

为了设计出合适的系统架构，我们分析了现状。首先，商家数据和商品数据分别存储在2个独立的MySQL8数据库，为满足商家数据和商品数据的关联，我们需要将两个库中所需要的表实时ETL到我们的搜索系统数据库。
其次，数据从商家、商品数据库ETL到搜索系统数据库后，需要实时的组合成为商家关联商品数据结构，并以父子文档的格式，存储到ES中。
最后，商家、商品数据库的增删改操作，需要实时的同步到ES中，也就是ES中的数据，需要支持实时的增加、删除和修改。
为此，我们设计了2个canal组件，第一个canal实现数据ETL，把商家、商品数据库的某些表及字段，抽取到搜索服务数据库；再利用第二个canal，读取搜索服务MySQL数据库的binlog，实时传输到kafka消息队列，再由canal adapter对数据进行关联、父子文档映射等，将处理好的数据存储到ElasticSearch中。

具体系统架构设计如下图所示。

商家商品搜索系统架构设计

项目实战

1、环境及软件说明

操作系统：CentOS 7canal：canal.adapter-1.1.4，canal.deployer-1.1.4kafka：kafka_2.12-2.3.0ElasticSearch：elasticsearch-6.3.2kibana：kibana-6.3.2

2、利用Canal实现数据ETL到MySQL8

这个步骤是利用canal从2个独立的MySQL8数据库中，抽取需要的表到搜索服务的MySQL数据库。

2.1 安装canaldeployer

（1）解压canal.deployer-1.1.4.tar.gz（2）配置canal deployer进入canaldeployer/conf目录，修改canal.properties文件，主要配置serverMode、MQ和destination三部分。首先，我们serverMode修改为kafka模式，增加系统缓冲能力以及提高系统稳定性：

serverMode

接着，配置kafka的MQ信息（kafka请自行安装）：

kafka MQ信息

最后，配置需要实例化的instance，这里配置了3个，表示canal deploy会启动这3个实例，同步MySQL的binlog到kafka的topic内。如下图所示：

destinations实例配置

（3）配置canal deployer instance进入canaldeployer/conf/example目录，发现有一个 instance.properties文件，这是canal给的示例，我们可以参考其配置。①我们拷贝整个example目录，并重命名为上个步骤配置的destination之一，如xxxsearch；②进入xxxsearch目录，编辑instance.properties文件，主要配置源数据库信息、所需数据表及字段，以及指定kafka的topic名，这样源数据库的binlog就会转换为json数据，并实时的通过canal deployer传输到kafka该topic中。如下所示：

canaldeploy instance 源数据库配置

canaldeploy instance kafka topic配置

③进入canaldeployer/bin目录，执行./startup.sh，启动canal deployer及所属实例。至此canal deployer搭建完成。

2.2 安装canal.adapter

我们需要利用canal.adapter将kafka topic中的binlog json数据，经过清洗转换等操作，存储到MySQL8中。由于canal原生是不支持MySQL8的，故我们需要做一些调整。（1）增加MySQL8连接驱动解压canal.adapter-1.1.4.tar.gz，进入canaladapter/lib目录，移除mysql-connector-java-5.1.40.jar，导入mysql-connector-java-8.0.18.jar
（2）配置canal adapter，使数据输出到MySQL8。进入canaladapter/conf目录，编辑application.yml文件，主要配置消费kafka、源数据库信息和搜索系统数据库信息，如下所示：

ETL到MySQL8配置

接着，进入canaladapter/conf/rdb目录，以官方提供的mytest_user.yml为例，配置kafka topic名、源数据库名、源数据表名，以及目标数据库名和目标数据表名， 建议一张表对应一个yml文件。

ETL表结构映射配置

（3）启动canaladapter进入canaladapter/bin目录，执行./startup.sh，启动canal adapter，观察logs/adapter/adapter.log日志文件，手动在搜索系统数据库新增一条记录，看是否会打印如下日志，即有2条记录，一条INFO，一条DEBUG，则表示配置成功。 canaladapter日志至此，数据ETL阶段搭建完成，数据可从两个不同的MySQL8数据库，实时同步到搜索服务的MySQL数据库。

3、实现数据多表关联、父子文档映射

（1）配置第二个canal的canaladapter进入canaladapter/conf目录，编辑application.yml文件，主要配置消费kafka、搜索系统数据库，和ES连接信息，如下所示：

canaladapter MQ及mysql配置

canaladapter ES配置

（2）配置多表关联进入canaladapter/conf/es目录，vim mytest_user.yml，编辑多表关联配置：

多表关联配置

注意，sql支持多表关联自由组合, 但是有一定的限制:（a）主表不能为子查询语句（b）只能使用left outer join即最左表一定要是主表（c）关联从表如果是子查询不能有多张表（d）主sql中不能有where查询条件(从表子查询中可以有where条件但是不推荐, 可能会造成数据同步的不一致, 比如修改了where条件中的字段内容)（e）关联条件只允许主外键的'='操作不能出现其他常量判断比如: on a.role_id=b.id and b.statues=1（f）关联条件必须要有一个字段出现在主查询语句中比如: on a.role_id=b.id 其中的 a.role_id 或者 b.id 必须出现在主select语句中（g）Elastic Search的mapping 属性与sql的查询值将一一对应(不支持 select *), 比如: select a.id as _id, a.name, a.email as _email from user, 其中name将映射到es mapping的name field, _email将映射到mapping的_email field, 这里以别名(如果有别名)作为最终的映射字段. 这里的_id可以填写到配置文件的 _id: _id映射.

（3）配置父子文档以官方的biz_order.yml为例，vim biz_order.yml，配置父子文档映射：

配置父子文档映射

（4）在ElasticSearch6中，建立index和父子文档映射关系进入kibana页面，点击Dev Tools，执行如下命令，即可建立索引及父子文档映射：建立index和父子文档映射其中，ES6和kibana的安装，在此无特别配置，不做赘述。
（5）启动canal adapter进入canaladapter/bin目录，执行./startup.sh，启动canal adapter，观察logs/adapter/adapter.log日志文件，手动在搜索系统数据库新增一条记录，看是否会打印如下日志，如打印则表示配置成功。正确配置adapter日志示例

4、运行结果

现在，我们可以通过kibana来执行DSL语句来查询看看。我们事先已在商家系统中增加了一个“肯德基”商店，然后在商品系统中添加了“西红柿”和”新鲜西红柿“2个商品，并将商品关联到“肯德基”上。接着我们查询”肯德基“或者“西红柿”，得到以下是查询的结果（去除了ES默认字段）：通过DSL查询的结果由图可见，我们可以通过商家名查询商品，也可通过商品名查询商店和商品，并且canal支持数据的实时增删改，所以ES的数据也会与商家系统和商品系统保持一致，同时数据结构包含商家及对应的商品，满足业务需求。

5、总结

至此，基于Canal、kafka、MySQL8、ElasticSearch6技术的商家商品搜索系统基础框架搭建完成。我们采用canal deployer实时读取商家、商品系统的MySQL数据库binlog，并发送至kafka，接着由canal adapter消费kafka，并将binlog json数据进行多表关联、父子文档映射，最后存储到ES6中，供上层搜索服务调用。搜索服务系统最终成功上线，为公司百万级商家商品提供实时数据同步，秒级搜索结果展示，达到业务要求，老板说了，给研发团队每人加个鸡腿！想想还有点小激动，嘿嘿~~

利用ogg实现oracle到kafka的增量数据实时同步 | 伦少的博客

Sat, 01 Feb 2020 17:34:04 CST

前言

ogg即Oracle GoldenGate是Oracle的同步工具，本文讲如何配置ogg以实现Oracle数据库增量数据实时同步到kafka中，其中同步消息格式为json。
下面是我的源端和目标端的一些配置信息：

-	版本	OGG版本	ip	别名
源端	OracleRelease 11.2.0.1.0	Oracle GoldenGate 11.2.1.0.3 for Oracle on Linux x86-64	192.168.44.128	master
目标端	kafka_2.11-1.1.0	Oracle GoldenGate for Big Data 12.3.1.1.1 on Linux x86-64	192.168.44.129	slave1

1、下载

可在这里或旧版本查询下载
注意：源端和目标端的文件不一样，目标端需要下载Oracle GoldenGate for Big Data,源端需要下载Oracle GoldenGate for Oracle具体下载方法见最后的附录截图。

2、源端（Oracle）配置

注意：源端是安装了oracle的机器，oracle环境变量之前都配置好了

2.1 解压

先建立ogg目录

1 2	mkdir -p /opt/ogg unzip V34339-01.zip

解压后得到一个tar包，再解压这个tar

1 2	tar xf fbo_ggs_Linux_x64_ora11g_64bit.tar -C /opt/ogg chown -R oracle:oinstall /opt/ogg （使oracle用户有ogg的权限，后面有些需要在oracle用户下执行才能成功）

2.2 配置ogg环境变量

为了简单方便起见，我在/etc/profile里配置的，建议在生产中配置oracle的环境变量文件/home/oracle/.bash_profile里配置，为了怕出问题，我把OGG_HOME等环境变量在/etc/profile配置了一份，不知道这是否是必须的。

1	vim /etc/profile

1            
2            
3

export OGG_HOME=/opt/ogg            
export LD_LIBRARY_PATH=$ORACLE_HOME/lib:/usr/lib            
export PATH=$OGG_HOME:$PATH

使之生效

1	source/etc/profile

测试一下ogg命令

ggsci

如果命令成功即可进行下一步，不成功请检查前面的步骤。

2.3 oracle打开归档模式

1 2	su - oracle sqlplus / as sysdba

执行下面的命令查看当前是否为归档模式

1	archive log list

SQL> archive log list            
Database log mode	       No Archive Mode            
Automatic archival	       Disabled            
Archive destination	       USE_DB_RECOVERY_FILE_DEST            
Oldest online log sequence     12            
Current log sequence	       14

若为Disabled，手动打开即可

conn / as sysdba (以DBA身份连接数据库)             
shutdown immediate (立即关闭数据库)             
startup mount (启动实例并加载数据库，但不打开)             
alterdatabasearchivelog; (更改数据库为归档模式)             
alterdatabaseopen; (打开数据库)             
altersystemarchivelogstart; (启用自动归档)

再执行一下

1	archive log list

Database log mode	       Archive Mode            
Automatic archival	       Enabled            
Archive destination	       USE_DB_RECOVERY_FILE_DEST            
Oldest online log sequence     12            
Next log sequence to archive   14            
Current log sequence	       14

可以看到为Enabled，则成功打开归档模式。

2.4 Oracle打开日志相关

OGG基于辅助日志等进行实时传输，故需要打开相关日志确保可获取事务内容，通过下面的命令查看该状态

1	selectforce_logging, supplemental_log_data_minfromv$database;

1            
2            
3

FORCE_ SUPPLEMENTAL_LOG            
------ ----------------            
NO     NO

若为NO，则需要通过命令修改

1 2	alterdatabaseforcelogging; alterdatabaseaddsupplementallogdata;

再查看一下为YES即可

SQL> select force_logging, supplemental_log_data_min from v$database;             
             
FORCE_ SUPPLEMENTAL_LOG             
------ ----------------             
YES    YES

2.5 oracle创建复制用户

首先root用户建立相关文件夹，并赋予权限

1 2	mkdir -p /u01/app/oracle/oggdata/orcl chown -R oracle:oinstall /u01/app/oracle/oggdata/orcl

然后执行下面sql

SQL> create tablespace oggtbs datafile '/u01/app/oracle/oggdata/orcl/oggtbs01.dbf' size 1000M autoextend on;             
             
Tablespace created.             
             
SQL>  create user ogg identified by ogg default tablespace oggtbs;             
             
User created.             
             
SQL> grant dba to ogg;             
             
Grantsucceeded.

2.6 OGG初始化

1 2	ggsci create subdirs

ggsci            
            
Oracle GoldenGate Command InterpreterforOracle            
Version 11.2.1.0.3 14400833 OGGCORE_11.2.1.0.3_PLATFORMS_120823.1258_FBO            
Linux, x64, 64bit (optimized), Oracle 11g on Aug 23 2012 20:20:21            
            
Copyright (C) 1995, 2012, Oracle and/or its affiliates. All rights reserved.            
            
            
            
GGSCI (ambari.master.com) 1> create subdirs            
            
Creating subdirectories under current directory /root            
            
Parameter files                /root/dirprm: created            
Report files                   /root/dirrpt: created            
Checkpoint files               /root/dirchk: created            
Process status files           /root/dirpcs: created            
SQL script files               /root/dirsql: created            
Database definitions files     /root/dirdef: created            
Extract data files             /root/dirdat: created            
Temporary files                /root/dirtmp: created            
Stdout files                   /root/dirout: created            
            
            
GGSCI (ambari.master.com) 2>

2.7 Oracle创建测试表

创建一个用户,在该用户下新建测试表，用户名、密码、表名均为 test_ogg。

createusertest_oggidentifiedbytest_oggdefaulttablespaceusers;             
grantdbatotest_ogg;             
conn test_ogg/test_ogg;             
createtabletest_ogg(idint,namevarchar(20),primarykey(id));

3 目标端（kafka）配置

1            
2            
3

mkdir -p /opt/ogg            
unzip 123111_ggs_Adapters_Linux_x64.zip            
tar xf ggs_Adapters_Linux_x64.tar  -C /opt/ogg/

3.2 环境变量

1	vim /etc/profile

1            
2            
3

export OGG_HOME=/opt/ogg            
export LD_LIBRARY_PATH=$JAVA_HOME/jre/lib/amd64:$JAVA_HOME/jre/lib/amd64/server:$JAVA_HOME/jre/lib/amd64/libjsig.so:$JAVA_HOME/jre/lib/amd64/server/libjvm.so:$OGG_HOME/lib            
export PATH=$OGG_HOME:$PATH

1	source/etc/profile

同样测试一下ogg命令

ggsci

3.3 初始化目录

1	create subdirs

4、OGG源端配置

4.1 配置OGG的全局变量

先切换到oracle用户下

1             
2             
3

su oracle             
cd/opt/ogg             
ggsci

GGSCI (ambari.master.com) 1> dblogin userid ogg password ogg            
Successfully logged into database.            
            
GGSCI (ambari.master.com) 2> edit param ./globals

然后和用vim编辑一样添加

1	oggschema ogg

4.2 配置管理器mgr

GGSCI (ambari.master.com) 3> edit param mgr            
PORT 7809            
DYNAMICPORTLIST 7810-7909            
AUTORESTART EXTRACT *,RETRIES 5,WAITMINUTES 3            
PURGEOLDEXTRACTS ./dirdat/*,usecheckpoints, minkeepdays 3

说明：PORT即mgr的默认监听端口；DYNAMICPORTLIST动态端口列表，当指定的mgr端口不可用时，会在这个端口列表中选择一个，最大指定范围为256个；AUTORESTART重启参数设置表示重启所有EXTRACT进程，最多5次，每次间隔3分钟；PURGEOLDEXTRACTS即TRAIL文件的定期清理

4.3 添加复制表

GGSCI (ambari.master.com) 4> add trandata test_ogg.test_ogg            
            
Logging of supplemental redo data enabledfortable TEST_OGG.TEST_OGG.            
            
GGSCI (ambari.master.com) 5> info trandata test_ogg.test_ogg            
            
Logging of supplemental redologdata is enabledfortable TEST_OGG.TEST_OGG.            
            
Columns supplementally loggedfortable TEST_OGG.TEST_OGG: ID

4.4 配置extract进程

GGSCI (ambari.master.com) 6> edit param extkafka            
extract extkafka            
dynamicresolution            
SETENV (ORACLE_SID ="orcl")            
SETENV (NLS_LANG ="american_america.AL32UTF8")            
userid ogg,password ogg            
exttrail /opt/ogg/dirdat/to            
table test_ogg.test_ogg;

说明：第一行指定extract进程名称；dynamicresolution动态解析；SETENV设置环境变量，这里分别设置了Oracle数据库以及字符集；userid ggs,password ggs即OGG连接Oracle数据库的帐号密码，这里使用2.5中特意创建的复制帐号；exttrail定义trail文件的保存位置以及文件名，注意这里文件名只能是2个字母，其余部分OGG会补齐；table即复制表的表名，支持*通配，必须以;结尾

添加extract进程：

1 2	GGSCI (ambari.master.com) 16> add extract extkafka,tranlog,begin now EXTRACT added.

(注：若报错

1	ERROR: Could not create checkpoint file /opt/ogg/dirchk/EXTKAFKA.cpe (error 2, No such file or directory).

执行下面的命令再重新添加即可。

1	create subdirs

)

添加trail文件的定义与extract进程绑定：

1 2	GGSCI (ambari.master.com) 17> add exttrail /opt/ogg/dirdat/to,extract extkafka EXTTRAIL added.

4.5 配置pump进程

pump进程本质上来说也是一个extract，只不过他的作用仅仅是把trail文件传递到目标端，配置过程和extract进程类似，只是逻辑上称之为pump进程

GGSCI (ambari.master.com) 18> edit param pukafka             
extract pukafka             
passthru             
dynamicresolution             
userid ogg,password ogg             
rmthost 192.168.44.129 mgrport 7809             
rmttrail /opt/ogg/dirdat/to             
table test_ogg.test_ogg;

说明：第一行指定extract进程名称；passthru即禁止OGG与Oracle交互，我们这里使用pump逻辑传输，故禁止即可；dynamicresolution动态解析；userid ogg,password ogg即OGG连接Oracle数据库的帐号密码rmthost和mgrhost即目标端(kafka)OGG的mgr服务的地址以及监听端口；rmttrail即目标端trail文件存储位置以及名称。

分别将本地trail文件和目标端的trail文件绑定到extract进程：

GGSCI (ambari.master.com) 1> add extract pukafka,exttrailsource /opt/ogg/dirdat/to             
EXTRACT added.             
GGSCI (ambari.master.com) 2> add rmttrail /opt/ogg/dirdat/to,extract pukafka             
RMTTRAIL added.

4.6 配置define文件

Oracle与MySQL，Hadoop集群（HDFS，Hive，kafka等）等之间数据传输可以定义为异构数据类型的传输，故需要定义表之间的关系映射，在OGG命令行执行：

GGSCI (ambari.master.com) 3> edit param test_ogg             
defsfile /opt/ogg/dirdef/test_ogg.test_ogg             
userid ogg,password ogg             
table test_ogg.test_ogg;

在OGG主目录下执行(oracle用户)：

./defgen paramfile dirprm/test_ogg.prm             
             
***********************************************************************             
Oracle GoldenGate Table Definition GeneratorforOracle             
Version 11.2.1.0.3 14400833 OGGCORE_11.2.1.0.3_PLATFORMS_120823.1258             
Linux, x64, 64bit (optimized), Oracle 11g on Aug 23 2012 16:58:29             
             
Copyright (C) 1995, 2012, Oracle and/or its affiliates. All rights reserved.             
             
             
Starting at 2018-05-23 05:03:04             
***********************************************************************             
             
Operating System Version:             
Linux             
Version#1 SMP Wed Apr 12 15:04:24 UTC 2017, Release 3.10.0-514.16.1.el7.x86_64             
Node: ambari.master.com             
Machine: x86_64             
softlimithardlimit             
Address Space Size   :    unlimited    unlimited             
Heap Size            :    unlimited    unlimited             
File Size            :    unlimited    unlimited             
CPU Time             :    unlimited    unlimited             
             
Process id: 13126             
             
***********************************************************************             
**            Running with the following parameters                  **             
***********************************************************************             
defsfile /opt/ogg/dirdef/test_ogg.test_ogg             
userid ogg,password ***             
table test_ogg.test_ogg;             
Retrieving definitionforTEST_OGG.TEST_OGG             
             
             
             
Definitions generatedfor1 tablein/opt/ogg/dirdef/test_ogg.test_ogg

将生成的/opt/ogg/dirdef/test_ogg.test_ogg发送的目标端ogg目录下的dirdef里：

1	scp -r /opt/ogg/dirdef/test_ogg.test_ogg root@slave1:/opt/ogg/dirdef/

5、OGG目标端配置

5.1 开启kafka服务

1            
2            
3

cd/opt/kafka_2.11-1.1.0/            
bin/zookeeper-server-start.sh config/zookeeper.properties            
bin/kafka-server-start.sh config/server.properties

5.2 配置管理器mgr

GGSCI (ambari.slave1.com) 1>  edit param mgr            
PORT 7809            
DYNAMICPORTLIST 7810-7909            
AUTORESTART EXTRACT *,RETRIES 5,WAITMINUTES 3            
PURGEOLDEXTRACTS ./dirdat/*,usecheckpoints, minkeepdays 3

5.3 配置checkpoint

checkpoint即复制可追溯的一个偏移量记录，在全局配置里添加checkpoint表即可。

1 2	edit param ./GLOBALS CHECKPOINTTABLE test_ogg.checkpoint

5.4 配置replicate进程

GGSCI (ambari.slave1.com) 4> edit param rekafka            
REPLICAT rekafka            
sourcedefs /opt/ogg/dirdef/test_ogg.test_ogg            
TARGETDB LIBFILE libggjava.so SET property=dirprm/kafka.props            
REPORTCOUNT EVERY 1 MINUTES, RATE            
GROUPTRANSOPS 10000            
MAP test_ogg.test_ogg, TARGET test_ogg.test_ogg;

说明：REPLICATE rekafka定义rep进程名称；sourcedefs即在4.6中在源服务器上做的表映射文件；TARGETDB LIBFILE即定义kafka一些适配性的库文件以及配置文件，配置文件位于OGG主目录下的dirprm/kafka.props；REPORTCOUNT即复制任务的报告生成频率；GROUPTRANSOPS为以事务传输时，事务合并的单位，减少IO操作；MAP即源端与目标端的映射关系

5.5 配置kafka.props

1 2	cd/opt/ogg/dirprm/ vim kafka.props

gg.handlerlist=kafkahandler //handler类型            
gg.handler.kafkahandler.type=kafka            
gg.handler.kafkahandler.KafkaProducerConfigFile=custom_kafka_producer.properties //kafka相关配置            
gg.handler.kafkahandler.topicMappingTemplate=test_ogg //kafka的topic名称，无需手动创建            
gg.handler.kafkahandler.format=json //传输文件的格式，支持json，xml等            
gg.handler.kafkahandler.mode=op  //OGGforBig Data中传输模式，即op为一次SQL传输一次，tx为一次事务传输一次            
gg.classpath=dirprm/:/opt/kafka_2.11-1.1.0/libs/*:/opt/ogg/:/opt/ogg/lib/*

1	vim custom_kafka_producer.properties

bootstrap.servers=192.168.44.129:9092//kafkabroker的地址            
acks=1            
compression.type=gzip //压缩类型            
reconnect.backoff.ms=1000//重连延时            
value.serializer=org.apache.kafka.common.serialization.ByteArraySerializer            
key.serializer=org.apache.kafka.common.serialization.ByteArraySerializer            
batch.size=102400            
linger.ms=10000

其中需要将后面的注释去掉，ogg不识别注释，如果不去掉会报错

5.6 添加trail文件到replicate进程

1 2	GGSCI (ambari.slave1.com) 2> add replicat rekafka exttrail /opt/ogg/dirdat/to,checkpointtable test_ogg.checkpoint REPLICAT added.

6、测试

6.1 启动所有进程

在源端和目标端的OGG命令行下使用start [进程名]的形式启动所有进程。
启动顺序按照源mgr——目标mgr——源extract——源pump——目标replicate来完成。
全部需要在ogg目录下执行ggsci目录进入ogg命令行。
源端依次是

1             
2             
3

start mgr             
start extkafka             
start pukafka

目标端

1 2	start mgr start rekafka

可以通过info all 或者info [进程名] 查看状态，所有的进程都为RUNNING才算成功
源端

GGSCI (ambari.master.com) 5> info all             
             
Program     Status      Group       Lag at Chkpt  Time Since Chkpt             
             
MANAGER     RUNNING             
EXTRACT     RUNNING     EXTKAFKA    04:50:21      00:00:03             
EXTRACT     RUNNING     PUKAFKA     00:00:00      00:00:03

目标端

GGSCI (ambari.slave1.com) 3> info all             
             
Program     Status      Group       Lag at Chkpt  Time Since Chkpt             
             
MANAGER     RUNNING             
REPLICAT    RUNNING     REKAFKA     00:00:00      00:00:01

6.2 异常解决

如果有不是RUNNING可通过查看日志的方法检查解决问题，具体通过下面两种方法

1	vim ggser.log

或者ogg命令行,以rekafka进程为例

1	GGSCI (ambari.slave1.com) 2> view report rekafka

列举其中我遇到的一个问题：
异常信息

1             
2             
3

SEVERE: Unable tosetproperty on handler'kafkahandler'(oracle.goldengate.handler.kafka.KafkaHandler). Failed tosetproperty: TopicName:="test_ogg"(class: oracle.goldengate.handler.kafka.KafkaHandler).             
oracle.goldengate.util.ConfigException: Failed tosetproperty: TopicName:="test_ogg"(class: oracle.goldengate.handler.kafka.KafkaHandler).             
at ......

具体原因是网上的教程是旧版的，设置topicName的属性为:

1	gg.handler.kafkahandler.topicName=test_ogg

新版的这样设置

1	gg.handler.kafkahandler.topicMappingTemplate=test_ogg

大家可根据自己的版本进行设置，附上stackoverflow原答案

I tried to move data from Oracle Database to Kafka using Golden gate adapter Version 12.3.0.1.0             
             
In new version there is no topicname             
             
The following resolves the topic name using the short table name             
gg.handler.kafkahandler.topicMappingTemplate=test             
             
In previous version we have gg.handler.kafkahandler.topicName=test

6.3 测试同步更新效果

现在源端执行sql语句

conn test_ogg/test_ogg             
insert into test_ogg values(1,'test');             
commit;             
update test_oggsetname='zhangsan'whereid=1;             
commit;             
delete test_oggwhereid=1;             
commit;

查看源端trail文件状态

1 2	ls -l /opt/ogg/dirdat/to* -rw-rw-rw- 1 oracle oinstall 1464 May 23 10:31 /opt/ogg/dirdat/to000000

查看目标端trail文件状态

1 2	ls -l /opt/ogg/dirdat/to* -rw-r----- 1 root root 1504 May 23 10:31 /opt/ogg/dirdat/to000000

查看kafka是否自动建立对应的主题

1	bin/kafka-topics.sh --list --zookeeper localhost:2181

在列表中显示有test_ogg则表示没问题
通过消费者看是否有同步消息

bin/kafka-console-consumer.sh --bootstrap-server 192.168.44.129:9092 --topic test_ogg --from-beginning             
{"table":"TEST_OGG.TEST_OGG","op_type":"I","op_ts":"2018-05-23 10:31:28.000078","current_ts":"2018-05-23T10:36:48.525000","pos":"00000000000000001093","after":{"ID":1,"NAME":"test"}}             
{"table":"TEST_OGG.TEST_OGG","op_type":"U","op_ts":"2018-05-23 10:31:36.000073","current_ts":"2018-05-23T10:36:48.874000","pos":"00000000000000001233","before":{},"after":{"ID":1,"NAME":"zhangsan"}}             
{"table":"TEST_OGG.TEST_OGG","op_type":"D","op_ts":"2018-05-23 10:31:43.000107","current_ts":"2018-05-23T10:36:48.875000","pos":"00000000000000001376","before":{"ID":1}}

显然，Oracle的数据已准实时同步到Kafka,格式为json,其中op_type代表操作类型，这个可配置，我没有配置则按默认的来，默认为

1             
2             
3

gg.handler.kafkahandler.format.insertOpKey = I             
gg.handler.kafkahandler.format.updateOpKey = U             
gg.handler.kafkahandler.format.deleteOpKey = D

before代表操作之前的数据，after代表操作后的数据，现在已经可以从kafka获取到同步的json数据了，后面可以用SparkStreaming和Storm等解析然后存到hadoop等大数据平台里

6.4 SparkStreaming测试消费同步消息

具体代码可参考 Spark Streaming连接Kafka入门教程
下面附上消费成功的结果图

7、更新：后续遇到的问题

在后面的使用过程中发现上面同步到kafka的json数据中少一些我们想要的一些，下面讲一下我是如何解决的
首先建表：

CREATETABLE"TCLOUD"."T_OGG2"             
("ID"NUMBER(*,0),             
"TEXT_NAME"VARCHAR2(20),             
"AGE"NUMBER(*,0),             
"ADD"VARCHAR2(100),             
"IDD"VARCHAR2(100),             
CONSTRAINT"T_OGG2_PK"PRIMARYKEY("ID","IDD")             
             
)

为什么不用之前建的表，主要是之前的字段太少，不容易看出问题，现在主要是增加几个字段，然后id,idd是联合主键。
看一下按照之前的配置，同步到kafka的数据(截取部分数据)

{"table":"TCLOUD.T_OGG2","op_type":"I","op_ts":"2018-05-31 11:46:09.512672","current_ts":"2018-05-31T11:46:15.292000","pos":"00000000000000001903","after":{"ID":4,"TEXT_NAME":null,"AGE":0,"ADD":null,"IDD":"8"}}             
{"table":"TCLOUD.T_OGG2","op_type":"U","op_ts":"2018-05-31 11:49:10.514549","current_ts":"2018-05-31T11:49:16.450000","pos":"00000000000000002227","before":{},"after":{"ID":4,"TEXT_NAME":"lisi","IDD":"7"}}             
{"table":"TCLOUD.T_OGG2","op_type":"U","op_ts":"2018-05-31 11:49:48.514869","current_ts":"2018-05-31T11:49:54.481000","pos":"00000000000000002373","before":{"ID":4,"IDD":"7"},"after":{"ID":1,"IDD":"7"}}             
             
{"table":"TCLOUD.T_OGG2","op_type":"D","op_ts":"2018-05-31 11:52:38.516877","current_ts":"2018-05-31T11:52:45.633000","pos":"00000000000000003161","before":{"ID":1,"IDD":"7"}}

现在只有insert的数据是全的，update更新非主键字段before是没有数据的，更新主键before只有主键的数据，delete只有before的主键字段，也就是update和delete的信息是不全的，且没有主键信息（程序里是不能判断哪一个是主键的），这样对于程序自动解析同步数据是不利的（不同的需求可能不一样），具体自己可以分析，就不啰嗦了，这里主要解决，有需要before和after全部信息和主键信息的需求。

7.1 添加before

在源端extract里添加下面几行

GGSCI (ambari.master.com) 33> edit param extkafka             
GETUPDATEBEFORES             
NOCOMPRESSDELETES             
NOCOMPRESSUPDATES

重启 extkafka

1 2	stop extkafka start extkafka

然后测试

1             
2             
3

{"table":"TCLOUD.T_OGG2","op_type":"U","op_ts":"2018-05-31 14:48:55.630340","current_ts":"2018-05-31T14:49:01.709000","pos":"00000000000000003770","before":{"ID":1,"AGE":20,"IDD":"1"},"after":{"ID":1,"AGE":1,"IDD":"1"}}             
{"table":"TCLOUD.T_OGG2","op_type":"U","op_ts":"2018-05-31 14:48:55.630340","current_ts":"2018-05-31T14:49:01.714000","pos":"00000000000000004009","before":{"ID":1,"AGE":20,"IDD":"2"},"after":{"ID":1,"AGE":1,"IDD":"2"}}             
{"table":"TCLOUD.T_OGG2","op_type":"U","op_ts":"2018-05-31 14:48:55.630340","current_ts":"2018-05-31T14:49:01.715000","pos":"00000000000000004248","before":{"ID":1,"AGE":20,"IDD":"8"},"after":{"ID":1,"AGE":1,"IDD":"8"}}

发现update之后before里有数据即可，但是现在before和after的数据都不全（只有部分字段）

网上有的说只添加GETUPDATES即可，但我测试了没有成功，关于每个配置项什么含义可以参考 https://blog.csdn.net/linucle/article/details/13505939（有些配置的含义里面也没有给出）
参考： http://www.itpub.net/thread-2083473-1-1.html

7.2 添加主键

在kafka.props添加

1	gg.handler.kafkahandler.format.includePrimaryKeys=true

重启 rekafka

1 2	stop rekafka start rekafka

测试：

{"table":"TCLOUD.T_OGG2","op_type":"U","op_ts":"2018-05-31 14:58:57.637035","current_ts":"2018-05-31T14:59:03.401000","pos":"00000000000000004510","primary_keys":["ID","IDD"],"before":{"ID":1,"AGE":1,"IDD":"1"},"after":{"ID":1,"AGE":20,"IDD":"1"}}

发现有primary_keys，不错~

参考： http://blog.51cto.com/lyzbg/2088409

7.3 补全全部字段

如果字段补全应该是Oracle没有开启全列补充日志

SQL> select supplemental_log_data_all from v$database;             
             
SUPPLE             
------             
NO

通过以下命令开启

SQL> alter database add supplemental log data(all) columns;             
             
Database altered.             
             
SQL> select supplemental_log_data_all from v$database;             
             
SUPPLE             
------             
YES             
             
SQL>

测试一下

1             
2             
3

{"table":"TCLOUD.T_OGG2","op_type":"U","op_ts":"2018-05-31 15:27:45.655518","current_ts":"2018-05-31T15:27:52.891000","pos":"00000000000000006070","primary_keys":["ID","IDD"],"before":{"ID":1,"TEXT_NAME":null,"AGE":1,"ADD":null,"IDD":"1"},"after":{"ID":1,"TEXT_NAME":null,"AGE":20,"ADD":null,"IDD":"1"}}             
{"table":"TCLOUD.T_OGG2","op_type":"U","op_ts":"2018-05-31 15:27:45.655518","current_ts":"2018-05-31T15:27:52.893000","pos":"00000000000000006341","primary_keys":["ID","IDD"],"before":{"ID":1,"TEXT_NAME":null,"AGE":1,"ADD":null,"IDD":"2"},"after":{"ID":1,"TEXT_NAME":null,"AGE":20,"ADD":null,"IDD":"2"}}             
{"table":"TCLOUD.T_OGG2","op_type":"U","op_ts":"2018-05-31 15:27:45.655518","current_ts":"2018-05-31T15:27:52.895000","pos":"00000000000000006612","primary_keys":["ID","IDD"],"before":{"ID":1,"TEXT_NAME":null,"AGE":1,"ADD":null,"IDD":"8"},"after":{"ID":1,"TEXT_NAME":null,"AGE":20,"ADD":null,"IDD":"8"}}

到现在json信息里的内容已经很全了，基本满足了我想要的，附图：

启发我发现和Oracle全列补充日志没有开启有关的博客： https://blog.csdn.net/huoshuyinhua/article/details/79013387
开启命令参考： https://blog.csdn.net/aaron8219/article/details/16825963

注：博客上讲到，开启全列补充日志会导致磁盘快速增长，LGWR进程繁忙，不建议使用。大家可根据自己的情况使用。

8、关于通配

如果想通配整个库的话，只需要把上面的配置所有表名的改为 ，如test_ogg.test_ogg改为 test_ogg.,但是kafka的topic不能通配，所以需要把所有的表的数据放在一个topic即可，后面再用程序解析表名即可。

9、附录

目标端在这里，下载下来后文件名123111_ggs_Adapters_Linux_x64.zip

源端在旧版本查询下载，下载后文件名为V34339-01.zip

参考资料

基于OGG的Oracle与Hadoop集群准实时同步介绍

赏

感谢您的支持!

支付宝

微信

本文由 董可伦 发表于伦少的博客 ,采用署名-非商业性使用-禁止演绎 3.0进行许可。

非商业转载请注明作者及出处。商业转载请联系作者本人。

本文标题：利用ogg实现oracle到kafka的增量数据实时同步

本文链接： https://dongkelun.com/2018/05/23/oggOracle2Kafka/

基于OGG的Oracle与Hadoop集群准实时同步介绍 - 偶素浅小浅 - 博客园

Sat, 01 Feb 2020 17:33:27 CST

MySQL 同步复制及高可用方案总结

Tue, 15 Oct 2019 15:41:19 CST

1.前言

本文将会对一些常用的数据库高可用方案进行介绍，根据你不同的场景，选择合适的高可用方案即可。

2.MMM高可用方案

2.1.Mysql-MMM介绍

2.2.组件

mmm_mond：监控进程，负责所有的监控工作，决定和处理所有节点角色活动。此脚本需要在监管机上运行。

mmm_agentd：运行在每个mysql服务器上的代理进程，完成监控的探针工作和执行简单的远端服务设置。此脚本需要在被监管机上运行。

mmm_control：一个简单的脚本，提供管理mmm_mond进程的命令。

2.3.架构图

正常工作时：

主节点故障时：

2.4.MMM优点

（1）高可用性，扩展性好，出现故障自动转移，对于主主同步，在同一时间只提供一台数据库写操作，保证数据的一致性。
（2）配置简单，容易操作。

2.5.MMM缺点

（1）需要一台备份服务器，浪费资源
（2）需要多个虚拟IP
（3）agent可能意外终止，引起裂脑。

3.MHA介绍

3.1.MHA架构介绍

3.2.MHA架构图

正常工作时架构图：

主库down机时架构：

3.3.故障转移过程

（1）从宕机崩溃的master保存二进制日志事件（binlog events）;
（2）识别含有最新更新的slave；
（3）应用差异的中继日志（relay log）到其他的slave；
（4）应用从master保存的二进制日志事件（binlog events）；
（5）提升一个slave为新的master；
（6）使其他的slave连接新的master进行复制；
（7）在新的master启动vip地址，保证前端请求可以发送到新的master。

3.4.MHA优点

（1）不需要备份服务器
（2）不改变现有环境
（3）操作非常简单
（4）可以进行日志的差异修复
（5）可以将任意slave提升为master

3.5.MHA缺点

（1）需要全部节点做ssh秘钥
（2）MHA出现故障后配置文件会被修改，如果再次故障转移需要重新修改配置文件。
（3）自带的脚本还需要进一步补充完善，且用perl开发，二次开发困难。

4.DRBD+（heartbeat,corosync）

4.1.方案简介

4.2.组件

Heartbeat,corosync作为心跳检测机制，监控primary节点的状态。当主节点宕掉之后，迅速提升secondary节点为新的主节点，并切换IP；
drbd负责数据同步

4.3.架构图

4.4.数据同步过程

mysql进行刷盘时，会通过不同的sync方式，最终将数据写入disk；
drbd收到刷盘成功的信息后，将对应的磁盘块位置，和变更动作，通过网络传递至secondary节点；

secondary的drbd接收到变更信息后，将这些信息落盘；

4.5.切换过程

前提：secondary节点的mysql服务不启动；

heartbeat检测到primary的mysql服务停止，则摘掉IP、umount掉数据盘、将primary切换为secondary；

在原来的secondary上，提升drbd同步为primary，挂载数据盘，启动mysql服务、绑定IP；

从库跟着IP和端口自动进行迁移；

4.6.方案优点

（1）历史悠久、安全性高、稳定性高、可用性高、出现故障自动切换。
（2）数据一致性强

4.7.方案缺点

（1）需要一台备份服务器，浪费资源
（2）不方便扩展
（3）无论drbd还是headbetart，corosync都可能发生裂脑

5.Mysql route介绍

5.1.什么是mysql route

（2）从数据库服务器故障，业务可以正常运行。由MySQL Router来进行自动下线不可用服务器。程序配置不需要任何修改。

（3）主数据库故障，由MySQL Router来决定主从自动切换，业务可以正常访问。程序配置不需要做任何修改。

5.2.读写分离原理

5.3.Mysql router用途

MySQL Router的主要用途是读写分离，主主故障自动切换，负载均衡，连接池等。

5.4.Mysql router主主故障自动切换的坑

5.5.优点

（1）基于DAL层实现mysql的高可用。
（2）可以同时实现主主故障切换和读写分离。
（3）插件式架构允许用户进行额外的功能扩展。

5.6.缺点

（1）高可用功能需要进一步完善：存在主库切换之后，从库不会自动切换主库地址的坑。
（2）读写情况使用不同端口，需要修改应用程序。

6.mysql Cluster

国内用的非常少，主要因为一下三点：
（1）需要更改存储引擎
（2）付费
（3）国内几乎没有使用案例

优点：
高可用，可用率达99.999%

6.1.结束语

版权申明：作者：西门飞冰，一名90后it男，一直在北京工作，热爱运动，热爱冒险，热爱旅行。由作者原创投稿，版权归原创者所有。除非无法确认，我们都会标明作者及出处，如有侵权烦请告知，我们会立即删除并表示歉意，谢谢。

关注民工哥技术之路微信公众号对话框回复关键字：1024 可以获取一份最新整理的技术干货：包括系统运维、数据库、redis、MogoDB、电子书、Java基础课程、Java实战项目、架构师综合教程、架构师实战项目、大数据、Docker容器、ELK Stack、机器学习、BAT面试精讲视频等。

基于datax的数据同步平台 - 黄小雪 - 博客园

Wed, 28 Aug 2019 22:14:23 CST

一、需求

由于公司各个部门对业务数据的需求，比如进行数据分析、报表展示等等，且公司没有相应的系统、数据仓库满足这些需求，最原始的办法就是把数据提取出来生成excel表发给各个部门，这个功能已经由脚本转成了平台，交给了DBA使用，而有些数据分析部门，则需要运维把生产库的数据同步到他们自己的库，并且需要对数据进行脱敏，比如客户的身份证号、手机号等等，且数据来源分散在不同的机器，不同的数据库实例里，这样就无法使用MySQL的多源复制，只能用写脚本通过SQL语句实现，随着业务的发展，导致堆积到运维部门的同步数据任务越来越多，一个任务对应一个脚本，有的脚本多达20多张表，脚本超过10个以后，每次同步失败、或者对脚本里的参数进行增删改查，都要从10多个脚本里的10多个SQL去找，这是一件非常痛苦的事情，耗费时间、没有效率，且容易改错，是一件吃力不讨好的事。为此开发了一个数据同步平台，将同步任务的增删改查、执行的历史日志全部放到平台里，然后交给DBA去自己去操作。

市面上也有一些ETL工具，比如kettle，但是为了练手决定重新造轮子。

二、平台简介

平台主要用于数据同步、数据处理等等ETL操作。

平台基于阿里的开源同步工具datax3.0开发。

开发语言：Python、Django、celery、bootstrap、jquery

系统：Centos 7 64位

注意：时间紧迫，平台只支持MySQL数据库，其它的sqlserver等等后期再开发。

datax3.0 介绍： https://yq.aliyun.com/articles/59373

datax3.0 github 地址： https://github.com/alibaba/DataX

项目地址： https://github.com/hanson007/FirstBlood

三、功能模块

1、数据同步

主要用于数据同步

2、SQL脚本（后期开发，包括备份模块等等。）

保存并执行各种增删改查SQL语句。

3、批处理作业

将数据同步、SQL脚本等等各个模块的子任务组合成一个批处理作业。借鉴了数据库客户端工具Navicat Premium 的批处理作业功能。

支持作业定时调度。

4、数据库管理工具（web界面后期开发）

主要用于管理生产数据库的IP、用户名、密码等等信息，供其它模块调用。

目前模块的表已建好，生产库的信息需要通过其它平台同步或者用数据库客户端工具导入，web界面的增删改查后期开发。目前生产环境里是将其它平台保存的所有生产库IP、用户名、密码等等信息同步到此平台里。

5、接口

提供查询批处理作业执行历史的接口，供其它部门使用。（主要还是大数据部门，他们写了一个程序，根据我这边每次同步后的结果，是成功还是失败，再进行下一步的操作。）

后续接口按业务部门的需求再开发。

6、权限（Django自带）

平台管理员账号拥有模块的所有权限，仅供运维部门使用。

普通人员账号只能查看数据同步、批处理作业，以及执行历史，不能新增、修改、执行作业或任务。主要提供给业务部门使用。

查看批处理作业的执行历史接口没有权限控制，普通人员也能调用。

四、表结构设计

1、生产数据库信息

功能：主要用于保存各种生产库的 ip、用户名、密码等等信息。

表名：databaseinfo

名称	类型	约束条件	说明
id	int	不允许为空	自增主键
name	varchar	不允许为空、不允许重复	生产库英文标识。
description	varchar	不允许为空	生产库的业务信息描述
host	varchar	不允许为空、不允许重复	生产库的IP地址。
user	varchar	不允许为空	生产数据库的用户名
passwd	varchar	不允许为空	生产数据库的密码
db	varchar	不允许为空	生产数据库中的某一个库
type	varchar	不允许为空	生产数据库类型。比如MySQL、sqlserver
create_time	datetime	不允许为空	创建时间，默认为当前时间
modify_time	datetime	不允许为空	修改时间，默认为当前时间，数据变化时自动改为当前时间。

2.数据库同步任务

功能：用于保存数据库同步任务的各种参数，主要为datax的json配置文件里的各种参数。

表名：datax_job

名称	类型	约束条件	说明
id	int	不允许为空	自增主键
name	varchar	不允许为空，不允许重复	数据同步任务的英文标识
description	varchar	不允许为空	任务的详细描述
querySql	longtext	不允许为空	提取数据时的查询SQL
reader_databaseinfo_id	int	不允许为空	读取数据库（从哪个生产库执行SQL提取数据，对应databaseinfo表的主键）
writer_table	varchar	不允许为空	写入表名（提取的数据插入到哪张表里）
writer_databaseinfo_id	int	不允许为空	写入数据库（提数据的数据插入到哪个数据库里）
writer_preSql	longtext	允许为空	写入前执行的SQL（比如同步数据前需要清空写入的表）
writer_postSql	longtext	允许为空	写入后执行的SQL（比如同步完数据后需要再结合其它表执行数据分析）
create_time	datetime	不允许为空	创建时间，默认为当前时间
modify-time	datetime	不允许为空	修改时间，默认为当前时间，数据变化时自动改为当前时间。

3.写入表的列信息

功能：保存同步任务时写入到表的哪些列。比如写入表有20个字段，此时只需要往其中的10个字段写入信息，就需要保存这10个列名。

注意：* 星号代码写入到表的所有字段。

表名：datax_job_writer_column

名称	类型	约束条件	说明
id	int	不允许为空	自增主键
name	varchar	不允许为空	列名
datax_job_id	int	不允许为空	数据同步任务ID，关联datax_job表的主键。
create_time	datetime	不允许为空	创建时间，默认为当前时间
modify_time	datetime	不允许为空	修改时间，默认为当前时间，随着数据的变化而变为当前时间。

4.数据同步任务实例

功能：用于保存数据同步任务的执行历史。

方便自己及业务部门进行任务的分析和排错，省的每次同步失败后还得帮他们查日志。现在直接将日志记录表里，在平台开个账号后，让业务部门自己去查。

每一个数据同步任务执行后，可以看成是一个实例，类似面向对象里实例化。将任务的执行时间、执行结果等等保存起来。借鉴了腾讯蓝鲸的作业平台表结构设计思想。（麻花藤啊麻花藤，给你冲了几十年的点卡，终于是回了一点点利息。）

表名：datax_job_instance

说明：instance_id也对应datax生成的日志文件名，当需要在页面查看datax生成的日志时就通过instance_id去查找日志文件，并将其实时输出到页面。

名称	类型	约束条件	说明
id	int	不允许为空	自增主键
instance_id	bigint	任务实例ID ,不允许重复	任务实例ID（由datax_job的id号+13位时间戳组成）
name	varchar	不允许为空	任务名称（执行时，datax_job表的name，同下面的字段一样）
description	varchar	不允许为空	任务描述
querySql	longtext	不允许为空	查询SQL语句
reader_databaseinfo_host	varchar	不允许为空	读取数据库IP
reader_databaseinfo_description	varchar	不允许为空	读取数据库描述
writer_table	varchar	不允许为空	写入表
writer_databaseinfo_host	varchar	不允许为空	写入数据库IP
writer_databaseinfo_description	varchar	不允许为空	写入数据库描述
writer_preSql	longtext	允许为空	写入数据前执行的SQL语句
writer_postSql	longtext	允许为空	写入数据后执行的SQL语句
trigger_mode	int	不允许为空	触发模式 1 自动 2 手动（默认自动）
status	int	不允许为空	状态 0 正在执行 1 执行完成
result	int	不允许为空	执行结果 0 成功 1 失败 2 未知
start_time	datetime	不允许为空	开始时间
end_time	datetime	允许为空	结束时间

5.批处理作业

功能：保存批处理作业。

表名：batch_job

名称	类型	约束条件	说明
id	int	不允许为空	自增主键
name	varchar	不允许为空，不允许重复	名称
description	varchar	不允许为空	描述
create_time	datetime	不允许为空	创建时间
modify_time	datetime	不允许为空	修改时间

6.批处理作业详情

功能：保存批处理作业的各个子任务。

比如一个批处理作业包含8个数据同步任务，一个SQL脚本任务，则将这几个任务的id保存起来。

表名：batch_job_details

说明：字段subjob_id，对应其它子任务的ID。比如，类型为数据同步，则对应datax_job表的主键。类型为SQL脚本，则对应SQL脚本表的主键。（SQL脚本后期开发）

名称	类型	约束条件	说明
id	int	不允许为空	自增主键
batch_job_id	int	不允许为空	批处理作业ID，对应batch_job表的主键
subjob_id	int	不允许为空	子作业ID，对应其它子任务的主键。
type	int	不允许为空	类型 1 数据同步 2 SQL脚本 3 备份。主要用于后期扩展
create_time	datetime	不允许为空	创建时间
modify_time	datetime	不允许为空	修改时间

7.批处理作业执行实例

功能：保存批处理作业的执行历史日志。功能同数据同步实例一样。

表名：batch_job_instance

名称	类型	约束条件	说明
id	int	不允许为空	自增主键
instance_id	bigint	不允许为空、不允许重复	实例ID（由batch_job表的id号+13位时间戳组成）
name	varchar	不允许为空	名称
description	varchar	不允许为空	描述
trigger_mode	int	不允许为空	触发模式 1 自动 2 手动（默认自动）
status	int	不允许为空	状态 0 正在执行 1 执行完成
result	int	不允许为空	执行结果 0 成功 1 失败 2 未知
start_time	datetime	不允许为空	开始时间
end_time	datetime	不允许为空	结束时间

8.批处理作业执行实例详情

功能：保存批处理作业执行实例的各个子任务实例

表名：batch_job_instance_details

说明：每个批处理作业执行时，实际是执行各个其它功能模块的子任务，而每个子任务都会保存子任务实例ID。

比如一个批处理作业有8个数据同步任务，1个备份任务（后期开发），执行后，datax_job_instance表会保存这8个数据同步任务的实例，备份实例表则保存备份实例ID。然后再将8个同步任务实例的ID及1个备份实例ID保存到batch_job_instance_details表里，查询时只要通过各个子任务的实例ID关联查询。

名称	类型	约束条件	说明
id	int	不允许为空	自增主键
instance_id	bigint	不允许为空	实例ID，对应batch_job_instance表的instance_id
subjob_instance_id	bigint	不允许为空	子作业实例ID，比如datax_job_instance表的instance_id
type	int	不允许为空	类型 1 数据同步 2 SQL脚本 3 备份。主要用于后期扩展

9.建表语句

+ View Code

五、功能详解

2、数据同步

功能：底层使用阿里的datax3.0工具进行同步。可以新增、修改同步任务。每个任务对应一张表。在页面添加任务后，执行时就在后台生成基于datax3.0的json配置文件。并且可以实时查看datax生成的同步日志，也可以查看任务的执行历史。

　　衍生：增量同步

需要源表里增加时间戳字段，两种方案。

（1）如果历史数据不变，每次只同步前一天的数据。

（2）如果历史数据变化，需要在目标库里加一张临时表，每次同步时将前一天或前一个小时的时间戳有变化的数据插入到临时表里。再将临时表里的数据更新或插入到目标表里。

操作

（1）首页

点击“数据同步->作业”，进入数据同步首页，可以查看所有的数据同步任务

（2）新增同步任务

点击首页的“新增”按钮，进入新增任务页面，填完表单后点击保存。

（3）更新、运行同步任务

在数据同步首页点击“任务名称”，进入任务更新页面。可以对任务的SQL、数据库等等信息进行修改。

（1）执行任务

在更新页面点击“Run”按钮，可以执行任务。

（1）执行历史

点击“数据同步->执行历史”，在执行历史首页可以查看数据同步任务的执行历史，并且可以按照任务名称、描述、读取数据库、执行状态等等进行搜索。

衍生：由于执行历史是一个日志记录，随着时间推移，数据量会越来越多，为了减小平台数据库的压力，按照业务量大小可以只保存一年、或者半年的数据。

（1）同步日志

在执行历史首页点击“任务名称”，可以实时查看同步日志。

日志是由工具datax生成的日志文件，文件名为执行时任务的ID号+13位时间戳组成。平台只保存文件名，查看日志时，后台通过文件名将日志文件内容实时输出到页面。

2.批处理作业

功能描述：

将数据同步、SQL脚本（3.0版本后期开发）等等子任务组合成一个批处理作业，并发执行。并且支持linux crontab格式的定时执行。

时间紧迫，暂时不支持任务串行，或者任务之间的依赖，比如A执行完成，并且成功后才能执行B，类似功能后期3.0版本开发。

操作

（1）批处理作业首页

点击“批处理作业->作业列表”，进入批处理作业首页

（2）新增批处理作业

点击“新增”按钮，进入新增批处理作业页面。

选择“执行时间”、勾选“是否启用”等等参数，填好表单后点击保存。后台会根据执行时间自动执行。

（3）更新、运行批处理作业

在批处理作业首页点击“任务名称”后，进入更新页面，可以修改批处理作业参数。

点击“Save”按钮，保存更新后的批处理作业。

在更新页面点击“Run”按钮可手动执行批处理作业。

（4）执行历史

点击“批处理作业->执行历史”，即可进入批处理作业 - 执行历史首页。

可以按照任务名称、执行结果等等搜索历史的执行作业。

点击“任务名称”进入批处理作业详情 - 执行历史，可查看批处理作业执行时它的子任务。

（5）执行日志

在“批处理作业详情 - 执行历史”页面，点击“任务名称”可查看每个子任务的日志。如类型为数据同步的子任务，它的日志就是调的datax的日志文件内容。

datax 3.0配合crontab实现数据定时增量同步

Sun, 18 Aug 2019 10:22:46 CST

使用datax 实现数据增量同步踩坑记录

前提概要

由于项目上需要将a服务器数据同步至b服务器，一开始使用mysql主从复制，但是由于主从同步无法触发位于b服务器的触发器，只能放弃此方案。后来找到了datax可以实现数据同步同时也可以触发触发器，决定使用此方案。

datax准备

安装datax，python，jdk datax下载及安装地址
根据自身需求选择合适的writer和reader，我这里选择的是mysqlwriter和mysqlreader
下面是我使用的json文件，有两点需要注意
1. 我在 where 使用了sql 语句 create_time > FROM_UNIXTIME(${create_time}) and create_time < FROM_UNIXTIME(${end_time}) ，其中FROM_UNIXTIME()是mysql时间戳转换为时间格式的函数，${name}是datax提供的占位符后面会使用到
2. reader中连接字符串添加了 useUnicode=true&characterEncoding=utf8 ，因为没有加这个导入到目标数据库中文乱码了，虽然我两边的数据库都是utf8mb4格式的

   {
   "job": {
     "setting": {
       "speed": {
         "channel": 3
       },
       "errorLimit": {
         "record": 0,
         "percentage": 0.02
       }
     },
     "content": [
       {
         "reader": {
           "name": "mysqlreader",
           "parameter": {
             "username": "root",
             "password": "root",
             "where": "create_time > FROM_UNIXTIME(${create_time}) and create_time < FROM_UNIXTIME(${end_time})",
             "column": [
               "clue_atta_id",
               "url",
               "create_time",
               "atta_type",
               "clue_id",
               "name",
               "attachment_id",
               "attr_sequence"
             ],
             "connection": [
               {
                 "table": [
                   "bus_clue_atta"
                 ],
                 "jdbcUrl": [
                   "jdbc:mysql://x.x.x.x:3306/dbname"
                 ]
               }
             ]
           }
         },
         "writer": {
           "name": "mysqlwriter",
           "parameter": {
             "writeMode": "insert",
             "username": "root",
             "password": "root",
             "column": [
               "clue_atta_id",
               "url",
               "create_time",
               "atta_type",
               "clue_id",
               "name",
               "attachment_id",
               "attr_sequence"
             ],
             "session": [
               "set session sql_mode='ANSI'"
             ],
             "connection": [
               {
                 "jdbcUrl": "jdbc:mysql://x.x.x.x:3306/dbname?useUnicode=true&characterEncoding=utf8",
                 "table": [
                   "bus_clue_atta"
                 ]
               }
             ]
           }
         }
       }
     ]
   }
 }

shell脚本准备

因为我有多张表，编写一个脚本
- 需要添加source /etc/profile ，因为在cron的系统环境和shell的环境不一样，会导致 java commond not found错误参考地址
- $(date +%s) 为获取系统当前时间戳， $(($end_time - 60)) 为算术表达式计算60前的时间戳
- "-Dcreate_time=$create_time -Dend_time=$end_time"这里就是datax使用占位符的作用，可以将外部自定义参数传入
- >>/home/gzjp/datax_log/bus_clue_atta_log.date +%Y%m%d 2>&1 我这里把日期都放入每天的日志文件以免单一文件过大
- 最后由于我的同步的表格较少我直接使用 & 进行后台操作以免发生阻塞

  #!/bin/bash
source /etc/profile
# 截至时间设置为当前时间戳
end_time=$(date +%s)
# 开始时间设置为60s前时间戳
create_time=$(($end_time - 60))
/home/gzjp/datax/bin/datax.py /home/gzjp/jobs/bus_clue_atta_job.json -p "-Dcreate_time=$create_time -Dend_time=$end_time" >>/home/gzjp/datax_log/bus_clue_atta_log.`date +%Y%m%d`  2>&1 &
/home/gzjp/datax/bin/datax.py /home/gzjp/jobs/bus_clue_job.json -p "-Dcreate_time=$create_time -Dend_time=$end_time" >>/home/gzjp/datax_log/bus_clue_log.`date +%Y%m%d`  2>&1 &
/home/gzjp/datax/bin/datax.py /home/gzjp/jobs/bus_attachment.json -p "-Dcreate_time=$create_time -Dend_time=$end_time" >>/home/gzjp/datax_log/bus_attachment_log.`date +%Y%m%d`  2>&1 &

crontab 定时任务准备

  $ crontab -e

*/1 * * * * /home/gzjp/jm_db_sync.sh >/dev/null 2>&1

我是定时每分钟跑一次脚本， 注意一定要处理输入文件，因为cron会见执行情况通过mail发给用户，时间长系统会被塞爆

有意义的参考内容

https://helpcdn.aliyun.com/document_detail/62149.html

IT瘾同步推荐

神同步OpenAI！中国团队Deep Principle领衔发布LLMs for Science评测，引爆外网

开源实时数据同步工具NiFi

Apache NiFi简介

Apache NiFi主要功能

Apache NiFi的优势

Apache NiFi的架构

核心组件

工作流和数据流

分布式架构

安全性

Airflow、Kafka的对比

相关文章:

✨基于Spring-Data-Elasticsearch 优雅的实现 多字段搜索 + 高亮 + 分页 + 数据同步✨

theme: devui-blue highlight: a11y-dark

系列说明

前言

技术要点

依赖项

配置文件

核心代码

实体类BlogDoc

注解说明：

实体类属性copy_to

Mapper层（Repository）

继承ElasticsearchRepository

高亮显示

分页功能

Service层

替换高亮数据

数据同步

MQ序列化配置

后记

超级好用的免费开源文件同步工具：Syncthing

数据同步工具之FlinkCDC/Canal/Debezium对比-技术圈

前言

Debezium

Debezium MySQL 架构

部署

基于 Kafka Connect

Debezium Server

嵌入式引擎

特性

Flink CDC

Flink CDC 发展

Canal

工作原理

Binlog获取详解

canal结构

Server设计

Instance设计

EventParser设计

EventSink设计

EventStore设计

HA机制设计

总结

基于Binlog的实时同步功能——debezium、canel、databus技术选型 | holmofy

#1. CDC技术

#2. 基于Binlog的CDC

#3. Canal vs. Debezium vs. databus vs. MaxWell

#4. Debezimu-MySQL的配置

#4.1. MySQL配置

#4.2. 准备Kafka环境，在Kafka-connect中安装Debezium

#4.3. Debezium的基础配置

#5. binlog解析的难点与Debezium工作原理

#5.1. 表结构随时都会修改，需要解析ddl并维护一份schema用于事件的生成

#5.2. 内存里的schema维护存在问题

#5.3. Kafka无法保证多个partition的消费顺序

#5.4. 消费DDL

#6. Debezium踩坑记录

#6.1. 关闭快照初始化

#6.2. 修改topic

#6.3. Decimal数据的处理

#6.4. 时间类型数据的处理

#6.5. 墓碑事件

#6.6. 禁用Kafka-Connect的Schema配置

#6.7. 对Debezium生成的消息进行处理

#6.8. kafka-connect的坑

rsync+inotify-tools实现数据实时同步方案_Ljohn的技术博客_51CTO博客

rsync数据同步优缺点

✨基于Spring-Data-Elasticsearch 优雅的实现多字段搜索 + 高亮 + 分页 + 数据同步✨