TiDB

上篇文章 介绍了用于将 binlog 同步到 MySQL / TiDB 的 Loader package，本文往回退一步，介绍 Drainer 同步到不同下游的机制。 TiDB Binlog（github.com/pingcap/tidb-binlog） 用于收集 TiDB 的 binlog，并准实时同步给下游。 同步数据这一步重要操作由 Drainer 模块支持，它可以将 binlog 同步到 TiDB / MySQL / Kafka / File （增量备份）等下游组件。 对于 TiDB 和 MySQL 两种类型的下游组件，Drainer 会从 binlog 中还原出对应的 SQL 操作在下游直接执行； 对于 Kafka 和 File（增量备份）两种类型的下游组件，输出约定编码格式的 binlog。用户可以定制后续各种处理流程，如更新搜索引擎索引、清除缓存、增量备份等。TiDB Binlog 自带工具 Reparo 实现了将增量备份数据（下游类型为 File（增量备份））同步到 TiDB / MySQL 的功能。 本文将按以下几个小节介绍 Drainer 如何将收到的 binlog 同步到下游： Drainer Sync 模块：Drainer 通过 Sync 模块调度整个同步过程，所有的下游相关的同步逻辑统一封装成了 Syncer 接口。 恢复工具 Reparo （读音：reh

互联网时代，从衣食住行到社交娱乐，几乎所有的业务都离不开数据库服务的支撑，可以说关系数据库是信息社会中最无可替代的基础设施。作为一个基石组件，数据库系统之所以有重要的价值，其本质的原因在于数据库系统提供事务支持。 数据库的本质其实就是做三件事：转账，记账，订票。但是天下没有免费的午餐， 数据库系统实现之难，也在于实现可靠而高性能的事务引擎。 实现数据库的事务系统，也就意味着郑重承诺，我们系统能够支持： 原子性：转账不能部分成功部分失败； 一致性：系统约束必须保持； 隔离性：并发事务需要保证正确处理； 持久性：数据不能丢。 另外，系统的处理能力、吞吐量，或者说系统的运行成本，都直接决定于事务引擎处理速度和能力。 简而言之，数据库系统需要提供事务保证，而且要高效地处理并发事务。更大的挑战在于，如何在基于不可靠硬件的分布式环境下，实现可靠而高效的分布式事务，提供更强高效的 OLTP 处理能力。 我们在做什么？ TiDB 从一开始就定位于分布式的关系数据库，TiDB 架构组一直致力于 TiDB 事务引擎的架构设计和研发工作，不断解决分布式事务的各种挑战和难题，提升 TiDB 稳定性和 OLTP 处理能力，其中包括但不限于： 实现完整的基于 Percolator 论文的分布式事务引擎，确保分布式语境下事务原子性和一致性 。将 TiDB、PD、TiKV 等分布式组件有效整合

2020 年这个春天格外特殊， 我们在 全员远程办公 中开启了新目标、新征程， 当然，我们招纳人才的脚步也不会停歇。 是的，我们在招人， PingCAP 2020 招聘季正式开启了！ 去年招聘季 我们为大家介绍了这些有趣的团队： 无法抑制内心技术躁动的 TiDB 团队 传说中「面试通过率最低、难度最高」的 TiKV 团队 最具活力的 AP 团队 让 TiDB 在云端跳舞的 Cloud 团队 「效率至上」的 EE 团队 今年各个团队积极拓展职责边界，在团队职责、团队名称等方面都有了一些令人惊喜的新变化： 原 AP 团队正式更名为 Real-Time Analytics，继续专注面向实时分析和 HTAP 场景的产品开发，并与 TiDB 团队以及负责产品规划与管理的 PM 团队共同组成 PingCAP 三个研发部门之一（R&D Group Dept.1），专注 TiDB 产品研发。 原 TiKV 团队进一步细分为专注于分布式存储层构建的 Storage Team、专注于分布式数据库架构领域的 Arch Team 以及专注于分布式系统整体性能的 Scheduling Team，并与效率工具、生态工具研发团队共同组成 PingCAP 另一研发部门（R&D Group Dept.2，后文简称 R2D2），专注提升工程效率，构建全球知名的分布式系统生态。 Cloud 团队与「效率至上」的 EE

2019 年 11 月初，我们开启了「TiDB 挑战赛第一季之 性能挑战赛 」，比赛为期三个月，期间选手将通过完成一系列难度不同的任务来获得相应的积分。赛程过去三分之一时，已经取得了十分耀眼的 阶段性成果 。三个月过去，性能挑战赛已经圆满落幕，最终的积分排行也新鲜出炉，选手们的参赛成果让人非常惊喜，让我们回顾一下选手们是如何在“TiDB 性能提升”之路上，过五关斩六将的吧～ 最终积分排名与奖项揭晓 注：本次比赛的完整积分榜详见 活动页面 。 本次 TiDB 性能挑战赛，总共有 165 位社区开发者参赛，包括 23 支参赛队伍和 122 位个人参赛者（按照比赛规则，有 PingCAP 人员参与的小组不计入挑战赛最终排名，即上图中有 TiDB Logo 标示的选手）。 本次比赛奖项设置为：一等奖 1 名，二等奖 2 名，三等奖 3 名，其余分数高于 600 分的团队或个人为优秀奖，各团队和个人的获奖情况如下： 一等奖：.* Team（15050 积分）。 二等奖：niedhui（4300 积分）和 catror（3500 积分）。 三等奖：pingyu（2600 积分）、Renkai（2550 积分）和 js00070（1800 积分）。 优秀奖：ekalinin（1450 积分）、mmyj（1050 积分）、AerysNan（750 积分）、MaiCw4J（650 积分）

位于 M87 中心的特大质量黑洞示意图（© EHT Collaboration） 今天的文章我想从这张模糊的照片说起。 相信很多小伙伴对这张照片并不陌生，这是去年人类第一次拍摄的 M87 中心黑洞的照片，从1915年，爱因斯坦提出相对论预言黑洞的存在到 2019 年我们终于第一次「 看到 」了黑洞的样子，中间整整相隔了 100 多年，这对于人类认识黑洞乃至认识宇宙都是一个里程碑式的事件。人类是一个感性的动物，所谓「 一图胜千言 」很多时候一张图传达的信息超过千言万语。 关于黑洞我不想展开太多，今天我们聊聊「 望远镜 」。 前几天，在 TiDB 4.0 的开发分支中，我们引入了一个新功能叫做：Key Visualizer（下面简称 KeyViz），说起来这个小工具也并不复杂，就是用不同颜色的方框来显示整个数据库的不同位置数据访问频度和流量。一开始我们只是仅仅将它定位为一个给 DBA 用来解决数据库热点问题的调优辅助小工具，但是从昨晚开始我就一直在把玩这个小东西，突然觉得它对于分布式数据库来说背后的意义远不及此。 在 CNCF 对 Cloud Native 的定义中，有一条叫做「Observability」，通用的翻译叫系统的「可观测性」。过去我一直苦于寻找一个例子说明什么叫做一个「可观测」的系统，在 KeyViz 这个项目上，我找到了对这点绝佳的体现。 举几个直观的小例子。你知道

上篇文章 中，我们简单介绍了 TiFlash 的设计和架构，TiFlash 是即将随着 TiDB 3.1 版本发布（3月）的列存引擎，大幅提升了 TiDB 在实时分析场景下的性能。同时和 TiDB 体系无缝结合，可实时更新，弹性扩展，保持 TiDB 的 ACID 事务特性和快照隔离级别，可用于严肃场景的实时分析。 那么 TiFlash 到底有多快？ 为了更直观回答这个问题，我们用最新版本的 TiFlash 进行了一次全新的对比测试。测试选取了传统交易型数据库（及其列存扩展），分析型数据库和大数据计算引擎进行对比，分别是 Oracle、MySQL、MariaDB ColumnStore、Greenplum 和 Apache Spark。 其中 MySQL 可以承担在线交易业务，但是分析速度对比针对分析场景特化的产品就相当堪忧；而列存数据库则无法承担在线交易，无论是无更实时新存储结构还是高频少量数据访问性能都很难符合在线交易业务要求。 而 TiDB 作为 HTAP 数据库，在交易场景已经大量验证的前提下，加上 TiFlash 后在分析侧又能达到怎样的性能呢？借助 TiFlash 的一致性数据同步特型，用户可否以一个优异的速度直接对实时数据进行分析呢？ 这次我们一起来看一组来自美国交通部的有趣数据，它包含了从 1987 至今的飞机起降和准点情况。 大家可以使用 Percona Lab 的

GO下载 https://golang.org/dl/ IDE-goland下载 http://www.jetbrains.com/go/ 本次安装go1.9.3.windows-amd64.msi和goland-2017.3.1.exe版本。 安装Go 双击安装包，一路next下去就可以了。 安装成功后，使用go version可以查看go版本，确定是否安装成功。 配置系统环境变量 GOROOT就是go的安装目录 GOPATH是作为编译后二进制的存放目的地和import包时的搜索路径 (其实也是你的工作目录, 你可以在src下创建你自己的go源文件, 然后开始工作) 不要把GOPATH设置成go的安装路径 GOPATH之下主要包含三个目录: bin、pkg、src bin目录主要存放可执行文件; pkg目录存放编译好的库文件, 主要是*.a文件; src目录下主要存放go的源文件 需要把GOPATH中的可执行目录也配置到环境变量中, 否则你自行下载的第三方go工具就无法使用了 在path中增加：%GOROOT%/bin;%GOPATH%/bin; 安装Goland 执行安装文件，一路next就行了。因为是试用版本，故有三十天的限制。到期重装就可以了。 直接跳过license环节，进入工程配置界面。license可以后续再配置 路径配置到gopath下面 进入工程界面，右键new

一 TiDb简介 　TiDB 是 PingCAP 公司受 Google Spanner / F1 论文启发而设计的开源分布式 HTAP (Hybrid Transactional and Analytical Processing) 数据库，结合了传统的 RDBMS 和NoSQL 的最佳特性。TiDB 兼容 MySQL，支持无限的水平扩展，具备强一致性和高可用性。TiDB 的目标是为 OLTP(Online Transactional Processing) 和 OLAP (Online Analytical Processing) 场景提供一站式的解决方案。TiDB 具备如下核心特点： 1 高度兼容 MySQL 　大多数情况下，无需修改代码即可从 MySQL 轻松迁移至 TiDB，分库分表后的 MySQL 集群亦可通过 TiDB 工具进行实时迁移。 2水平弹性扩展 　通过简单地增加新节点即可实现 TiDB 的水平扩展，按需扩展吞吐或存储，轻松应对高并发、海量数据场景。 3分布式事务 　TiDB 100% 支持标准的 ACID 事务。 4 真正金融级高可用 　相比于传统主从 (M-S) 复制方案，基于 Raft 的多数派选举协议可以提供金融级的 100% 数据强一致性保证，且在不丢失大多数副本的前提下，可以实现故障的自动恢复 (auto-failover)，无需人工介入。 5

摘自 https://pingcap.com/docs-cn/ TiDB 是 PingCAP 公司设计的开源分布式 HTAP (Hybrid Transactional and Analytical Processing) 数据库，结合了传统的 RDBMS 和 NoSQL 的最佳特性。TiDB 兼容 MySQL，支持无限的水平扩展，具备强一致性和高可用性。 TiDB 的目标是为 OLTP (Online Transactional Processing) 和 OLAP (Online Analytical Processing) 场景提供一站式的解决方案。 TiDB 具备如下特性： 高度兼容 MySQL 大多数情况下 ，无需修改代码即可从 MySQL 轻松迁移至 TiDB，分库分表后的 MySQL 集群亦可通过 TiDB 工具进行实时迁移。 水平弹性扩展 通过简单地增加新节点即可实现 TiDB 的水平扩展，按需扩展吞吐或存储，轻松应对高并发、海量数据场景。 分布式事务 TiDB 100% 支持标准的 ACID 事务。 真正金融级高可用 相比于传统主从 (M-S) 复制方案，基于 Raft 的多数派选举协议可以提供金融级的 100% 数据强一致性保证，且在不丢失大多数副本的前提下，可以实现故障的自动恢复 (auto-failover)，无需人工介入。 一站式 HTAP 解决方案

源自 https://www.cnblogs.com/1ning/p/8985999.html 简介 TiDB 是 PingCAP 公司受 Google Spanner / F1 论文启发而设计的开源分布式 HTAP (Hybrid Transactional and Analytical Processing) 数据库，结合了传统的 RDBMS 和 NoSQL 的最佳特性。TiDB 兼容 MySQL，支持无限的水平扩展，具备强一致性和高可用性。TiDB 的目标是为 OLTP (Online Transactional Processing) 和 OLAP (Online Analytical Processing) 场景提供一站式的解决方案 特性 1）高度兼容 MySQL 大多数情况下，无需修改代码即可从 MySQL 轻松迁移至 TiDB，分库分表后的 MySQL 集群亦可通过 TiDB 工具进行实时迁移。 2）水平弹性扩展 通过简单地增加新节点即可实现 TiDB 的水平扩展，按需扩展吞吐或存储，轻松应对高并发、海量数据场景。 3）分布式事务 TiDB 100% 支持标准的 ACID 事务。 4）真正金融级高可用 相比于传统主从 (M-S) 复制方案，基于 Raft 的多数派选举协议可以提供金融级的 100% 数据强一致性保证，且在不丢失大多数副本的前提下，可以实现故障的自动恢复