TiDB

作者：李坤 热点问题概述 一直以来，TiDB 的数据访问热点问题，是用户比较关注的问题。为什么这个问题如此突出呢？这其实是“分布式”带来的结构效应。单机数据库由于只有一个节点，是不存在热点问题的(因为性能的上限就是单机的处理能力)，而分布式数据库集群存在多个节点，在达到存储扩展、读写能力扩展的目的上，我们希望大量的读写压力能够平摊在每个节点上，TiDB 也一直在朝着这个目标靠近。 数据库也存在二八原则，80% 的读写在 20% 的最新数据上，以使用最广泛的 MySQL 为例，很多从 MySQL 迁移到 TiDB 的业务，迁移前会使用自增主键，将随机写转为顺序写提高性能。而这种方式，在写入 QPS 较大的 TiDB 集群上，会造成写入热点，原因是 TiDB 使用 range 的方式来进行数据分片，导致新写入的数据集中在一个 range 范围所在的节点，对于这部分写入就会退化成单机的写入性能，未能利用分布式读写扩展的优势。 直面问题 为了解决这些问题，TiDB 在很早之前的 2.0 版本就开始设法改进，这就是新增的表属性 SHARD_ROW_ID_BITS，它的原理是将自动生成的主键在二进制的高几位进行一个位翻转从而将单调递增的 ID 转化为一定范围内的随机 ID，来达到自动将写入数据的压力分摊到不同节点，由于多数业务对于主键通常只需要不重复而不是单调递增

把数据从tidb中导出到mysql数据库中 # docker ps 找出容器id # 进入容器 # docker exec -it 44a9fa0f6c02 sh # 发现是4000端口映射到了主机的3306端口 # 访问tidb mysql -h192.168.11.222 -P 3306 -u root -p -D common # 导出数据 mydumper -h 192.168.11.222 -P 3306 -u root -p 'pass' -t 4 -F 256 -B common -T emails -o /opt/common/ # 把线上环境备份，并且rename，然后 mysqldump -uroot -p --default-character-set='utf8' common emails > /opt/emails20200514.sql use common; alter table emails rename to emails20200514; CREATE TABLE `emails` ( `id` int(11) unsigned NOT NULL AUTO_INCREMENT, `email` varchar(500) CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL, `status`

1. 引言 分布式事务主要应用领域主要体现在 数据库领域、微服务应用领域。微服务应用领域一般是柔性事务，不完全满足 ACID 特性，特别是 I 隔离性，比如说 saga 不满足隔离性，主要是通过根据分支事务执行成功或失败，执行相应的前滚的重试或者后滚的补偿操作来达成全局事务的最终一致性，但是全局事务与全局事务之间没有隔离性。 笔者了解到的分布式事务方案有 2PC 的 XA 规范，以及 Google 的 percolator 方案（ TiDB 就采用这个实现，本质上是基于全局时间戳的乐观锁版本校验）。 mysql 的 XA 应用场景分为外部 XA 与内部 XA ，内部 XA 用于 binlog 与 stroage engine 之间，协调 binlog 与 redo 事务写入的原子性。外部 XA 用于 mysql 节点与 mysql 节点之间，协调跨物理库之间的原子性。本文主要介绍外部 XA 。 基于 mysql 的 XA 两阶段事务提交(2PC) 分布式事务，需要一个事务协调器（ TransactionManager ）来接受应用提交的全局事务 (Global Transaction) ，全局事务经过 TM 的分解后，分解成多个分支事务 (Branch Transaction) ，每个分支事务在具体的某个 mysql 实例上运行，其中 mysql 作为资源管理器（ Resource

本文根据韩锋老师在〖deeplus直播第235期〗线上分享演讲内容整理而成。 （文末有韩锋老师亲笔签名版新书赠送，不容错过！） 大家好，我是韩锋，一个数据库领域资深从业者（好吧，我是个70后）。近些年来，主要从事数据库产品、架构等工作。本文我将以个人感受，谈谈在新时期下数据库架构优化工作的一些问题，供大家参考。 下面的分享，我将从外部环境对数据库架构的影响、当前架构中若干热门的技术问题、之前的架构实践经历，以及个人如何成长等方面谈谈我的感受。 新时期数据库架构优化 - 环境篇 首先谈下外部因素对架构工作的影响。有些同学可能会感到疑惑，架构问题不是技术问题嘛，为什么还要考虑外部因素？这里是有个误区的，架构的本质是为了解决企业的业务问题，针对某一问题可能有很多种解法，选择最为合适的（而非最优的）是考验一个架构师的核心能力。 正如上图中，右下角的描述“脱离企业环境的架构，都是耍流氓”。那么影响架构的外部因素有哪些呢？ 单位属性： 包括企业、事业、军工等。不同单位属性，对架构诉求点是有差异的，粗浅的理解企业单位是追求利益最大化的、事业单位更多会从公共视角考虑问题、而军工则会从国防安全角度思考； 行业属性： 包括互联网、金融、制造业、能源、交通等等。不同行业属性，同样存在差异。例如互联网企业往往比较激进，容易考虑一些自研、开源产品；金融企业则相对稳健，多从稳定安全角度考虑等； 用户属性：

TiDB 从诞生之时就带着云原生的标签，并且底层存储引擎 TiKV 也在 2019 年成为了 CNCF （云原生计算基金会）的孵化项目。 我们很早就认识到，云提供的基础设施可编程、按量付费等区别于传统数据中心的核心特质，正是释放 TiDB 弹性伸缩潜力的最佳载体。 而在另一方面，由于有状态应用天生的复杂性和数据资产不可估量的重要性，云原生革命的上半场仍聚焦在运维流程更易标准化、故障也相对可容忍的无状态应用上。随着 Kubernetes 与 Docker Swarm 的容器编排之战尘埃落定，无状态应用编排问题在几年内迅速得到解决后，如何在云上构建坚实可靠的数据层作为新的问题浮出了水面。相信很多有识之士早已看到了这些问题，准备“寻机而动”。不过，有那么一群人已经脚踏实地付诸行动了。 是的，有那么一群人，在他们眼中，TiDB 与云是天生互相吸引、互相需要的，用“佳偶天成”来形容二者的关系并不为过 。这群人就是 PingCAP 的 Cloud 团队，一群义无反顾的云原生信仰者、一群“上能修 DB、下能改容器”的技术 Nerds、一群 TiDB 和云的忠实 “CP 粉”。我们就是这群人，而这篇文章就是希望能打动屏幕面前的你，加入我们 —— “不负韶华，共谱云与 TiDB 的和谐乐章”。好了，务虚到此结束，下面我们来点实在的。 TiDB Operator TiDB Operator 是

作者介绍：胡梦宇，知乎数据架构平台开发工程师 背景 Apache Hive 是基于 Apache Hadoop 的一个数据仓库工具，可以将结构化的数据文件映射为一张数据库表，并且提供了 Hive SQL 进行查询和分析，在离线数仓中被广泛使用。 Hive Metastore 是 Hive 的元信息管理工具，它提供了操作元数据的一系列接口，其后端存储一般选用关系型数据库如 Derby、 MySQL 等。现在很多除了 Hive 之外计算框架都支持以 Hive Metastore 为元数据中心来查询底层 Hadoop 生态的数据，比如 Presto、Spark、Flink 等等。 在知乎，我们是将元信息存储在 MySQL 内的，随着业务数据的不断增长，MySQL 内已经出现单表数据量两千多万的情况，当用户的任务出现 Metastore 密集操作的情况时，往往会出现缓慢甚至超时的现象，极大影响了任务的稳定性。长此以往，MySQL 在未来的某一天一定会不堪重负，因此优化 Hive 的元数据库势在必行。 在去年，我们做过数据治理，Hive 表生命周期管理，定期去删除元数据，期望能够减少 MySQL 的数据量，缓解元数据库的压力。但是经过实践，发现该方案有以下缺点： 数据的增长远比删除的要快，治标不治本； 在删除超大分区表（分区数上百万）的分区时，会对 MySQL 造成一定的压力，只能单线程去做

作者：叶奔, 殷成文 不久前我们开源了基于 Kubernetes 的混沌测试工具 Chaos Mesh® ，Chaos Mesh 提供了模拟系统异常状况的能力，但这只是混沌工程中的一环，完整混沌工程核心原则包含了系统稳定状态的定义、提出假设、运行实验以及验证和改进。 本篇文章主要介绍我们是如何在 Chaos Mesh 和 Argo 的基础上打造自己的自动化测试平台 TiPocket ，实现完全自动化的混沌测试，构成混沌测试完整闭环。 为什么需要 TiPocket? 为了确保用户的数据安全，我们需要确保给用户提供的每一个 TiDB 版本都已经经过了严格的测试，所以我们为 TiDB 设计了各种异常场景，并实现了数十个测试 Case，所以在我们的 Kubernetes 集群中，可能同时运行着十几个甚至几十个混沌实验，即使我们拥有了 Chaos Mesh 来帮助我们管理错误注入，但这还远不够，我们还需要去管理 TiDB 集群，需要去收集指标，需要去分析结果，同时进行如此多的混沌实验，另一方面，我们还需要对 TiDB 生态中的其他工具进行混沌测试，这是无法想象的，因此，我们开发了 TiPocket 来解放自己。 TiPocket 是一个基于 Kubernetes 和 Chaos Mesh 的完全自动化测试框架，目前我们主要使用它用来测试 TiDB 集群，不过由于它 All-in-K8s

本文收录在个人博客： www.chengxy-nds.top ，技术资料共享，同进步 最近部门订单业务调整，收拢其他业务线的下单入口，做个统一大订单平台。需要梳理各业务线的数据表，但每个业务线库都有近百张和订单相关的表，挨个表一个一个字段的弄脑瓜子嗡嗡的。 为了不重复 CV 操作，抱着一丝希望开始在 GitHub 里找，看看有没有什么工具可以用，结果就真的发现了宝藏， screw （螺丝钉），居然可以生成数据库文档，优秀啊~。 一、数据库支持 [x] MySQL [x] MariaDB [x] TIDB [x] Oracle [x] SqlServer [x] PostgreSQL [x] Cache DB 二、配置 1、pom文件 引入 screw 核心包， HikariCP 数据库连接池， HikariCP 号称性能最出色的数据库连接池。 <!-- screw核心 --> <dependency> <groupId>cn.smallbun.screw</groupId> <artifactId>screw-core</artifactId> <version>1.0.3</version> </dependency> <!-- HikariCP --> <dependency> <groupId>com.zaxxer</groupId> <artifactId>HikariCP

#发送告警邮件 cat check_backup.sh #!/bin/bash . ~/.bash_profile BASEDIR=`dirname $0` cd $BASEDIR parse_line(){ EMAIL="xxxxxx@126.com;xxxxxx@126.com" } parse_line python tidb_backup_check.py >check_backup_status.html 2>/dev/null mutt -e 'set content_type="text/html"' -e 'set from="tidb@admin.com"' -e 'set realname="TiDB_Admin"' -s "TiDB Backup Status Check" "xxxx@126.com";${EMAIL}" <check_backup_status.html #获取具体的告警内容 cat tidb_backup_check.py #!/usr/bin/env python import psycopg2 as pg from datetime import datetime, date, time import json import prettytable as pt from prettytable import PrettyTable

云栖号资讯：【 点击查看更多行业资讯 】 在这里您可以找到不同行业的第一手的上云资讯，还在等什么，快来！ 高并发，几乎是每个程序员都想拥有的经验。原因很简单：随着流量变大，会遇到各种各样的技术问题，比如接口响应超时、CPU load升高、GC频繁、死锁、大数据量存储等等，这些问题能推动我们在技术深度上不断精进。 在过往的面试中，如果候选人做过高并发的项目，我通常会让对方谈谈对于高并发的理解，但是能系统性地回答好此问题的人并不多，大概分成这样几类： 1、对数据化的指标没有概念：不清楚选择什么样的指标来衡量高并发系统？分不清并发量和QPS，甚至不知道自己系统的总用户量、活跃用户量，平峰和高峰时的QPS和TPS等关键数据。 2、设计了一些方案，但是细节掌握不透彻：讲不出该方案要关注的技术点和可能带来的副作用。比如读性能有瓶颈会引入缓存，但是忽视了缓存命中率、热点key、数据一致性等问题。 3、理解片面，把高并发设计等同于性能优化：大谈并发编程、多级缓存、异步化、水平扩容，却忽视高可用设计、服务治理和运维保障。 4、掌握大方案，却忽视最基本的东西：能讲清楚垂直分层、水平分区、缓存等大思路，却没意识去分析数据结构是否合理，算法是否高效，没想过从最根本的IO和计算两个维度去做细节优化。 这篇文章，我想结合自己的高并发项目经验，系统性地总结下高并发需要掌握的知识和实践思路，希望对你有所帮助