tidb理论、架构
文章平均质量分 59
介绍tidb的内容
汪灵骅
资深DBA,oracle ACE
展开
-
TiDB-Binlog的适用场景
tidb到mysql、tidb、kafaka、binlog直接存储(relay log) 等等等等。多个pump分散抽取tidb的binlog,drainer合并抽取的binlog,发送给下游。3.将binlog提供给drainer,由drainer合并,提交给下游。2.每个pump只存上游的部分binlog,并且在自己这排序,pump存在高可用性,drainer(只有一个)没有。并不是只记录sql语句,而是参与的行的变更都会记录。1.是集群,非单个,高可用,可扩展。回滚的不记录,只记录提交的。原创 2024-04-11 10:29:34 · 118 阅读 · 0 评论 -
TiDB-TiCDC适用场景、部署方法
每个tikv都会有changelog,ticdc的capture组件会读取changelog,并且在本地排序,排序完后,这个ticdc会把changelog传送给owner的ticdc,由。------索引汇总不存在虚拟生成列(virtual generated columns)2.只能同步最少存在一个有效索引的表(简单来说,就是要有。3.不支持单独使用rawkv的tikv,必须是整个数据库。------索引每一列在表结构中明确定义非空。mysql、tidb、卡夫卡、。-满足下列条件的唯一索引为有效索引。原创 2024-04-10 08:45:00 · 346 阅读 · 0 评论 -
TiDB-Data Migration(DM)适用场景、部署
Dm worker对上游数据源是一对一的,其中一个dm worker出问题,free的会顶上去。Dm master做管理,调度。如果有10个分片,那起码要11个worker。1.兼容mysql迁移同步数据,全量+增量。worker数据量要大于源实例。Tidb5.4后支持gbk字符集。3.源端、目标端异构表同步。2.分表分库合并同步。大于等于10.1.2。原创 2024-04-09 09:00:54 · 321 阅读 · 0 评论 -
tidb-sync-diff-inspector(1)(数据校验)概念、适用场景
5.比对源端和目标端的chunk切片的校验核checksun(类似md5),如果某个chunk的校验核不一样,trunk拆分开,再次校验,以此类推(二分法),直到一个比较小的范围,然后逐条比较。并进行检查点存储,每10秒进行记录一次,防止sync-diff-inspector异常宕机,下次继续,可以直接从检查点继续。sharding参数,默认会去比对分片,想比较test1.haha1和test2.haha2,会自动把test2.haha2也拉进来一起和目标端比。原创 2024-04-08 13:53:51 · 329 阅读 · 0 评论 -
tidb-备份恢复技术的比对与选择
备份时可读写,备份速度快,适合大数据量的数据。备份集可读,可做异构恢复,备份速度较慢。数据量比较小,用逻辑备份。主库可运行,逻辑备份。原创 2024-04-07 09:30:00 · 100 阅读 · 1 评论 -
tidb-物理备份(1)-BR概念、适用场景
a为BR备份源端,b为BR恢复目标端(ticdc的源端),c为ticdc的备库。聚簇索引(tidb_enable_clustered_index)版本兼容问题(check-requirements)3.不推荐多个br备份、恢复同时进行。全局临时表(BR v5.3.0)3.tikv到外部存储各取所需。2.不提供业务使用的环境恢复。1.br找pd(元数据)3.备份到本地/外部存储。1.br找pd(元数据)原创 2024-04-07 08:45:00 · 199 阅读 · 0 评论 -
tidb监控-grafana、dashboard
查看网址:tiup cluster display tidb-hahaOverview,里面的几个大类(services port status/pd/tidb/tikv/system info)services port statusSystem-info指标PD指标Tidb server指标tikv指标dashboard内置在PD组件中,其他的普罗米修斯、grafana、告警这些都是单独组件原创 2024-03-26 13:46:11 · 248 阅读 · 0 评论 -
tidb-角色
orr_hisgrant'r_hislala'r_his'r_his。原创 2024-03-25 09:24:39 · 203 阅读 · 0 评论 -
tidb-用户
如果是给的角色的权限,需要set role all开启角色权限才能体现。用户、用户来自哪个主机(%代表任意)、密码(加密的)、是否锁定。原创 2024-03-25 09:24:07 · 385 阅读 · 0 评论 -
tidb参数设置
集群配置是记录在所有的配置文件中的。少部分tidb server。系统配置是记录在tikv中。Tidb server相关。原创 2024-03-22 09:01:54 · 275 阅读 · 0 评论 -
tidb连接方式(连接串)
tiup cluster display tidb-haha2.1mysql客户端登陆mysql -h127.0.0.1 -P4000 -uroot -p'-C64r^Rpe*Mw5Y93+7'2.2mysql workbench登陆Ctrl+回车执行选择的语句原创 2024-03-22 08:59:55 · 185 阅读 · 0 评论 -
tidb数据文件与日志
数据文件:region元数据(在哪个tikv上)根据拓扑文件查看文件安装路径。根据拓扑文件查看文件安装路径。根据拓扑文件查看文件安装路径。sst文件默认都在db下。数据文件:sst存数据。原创 2024-03-22 08:58:41 · 232 阅读 · 0 评论 -
tidb-TiFlash介绍
a去读tiflash,发现读不了,数据不一致,tiflash访问tikv当前读到哪里,并做标记。可以自动判断去tiflash还是tikv读,甚至混合读,需要2个表的内容,一个tikv,另一个要大量扫描用tiflash。参与复制,在1节点的tikv(行存)中的修改会在tiflash(列存)中复制。tiflash(列存),更多承载OLAP业务。tiflash不参与投票,无法直接写入,只能读和接收raft log。扫描大量的表,显示出一个报表,得出一个趋势。tikv(行存),更多承载OLTP业务。原创 2024-03-21 13:40:38 · 320 阅读 · 0 评论 -
TiDB的HTAP特性
tidb server作为协调者,会把tiflash每个列存region在tiflash之间做交换,让表连接发生在一个tiflash,做到不会垮tiflash做表连接。where里a.pid=b.pid,所以在上面过滤完后,对pid进行hash函数算法,hash值相同的a表和b表放在同一个tiflash,让表连接只在一个节点进行。首先并行所有tiflash中的表进行sql的过滤条件,并行操作,内存中。每个节点得出值,传到tidb server中,聚合。2张表都分布在3个tiflash中。原创 2024-03-21 13:39:39 · 283 阅读 · 0 评论 -
tidb DDL的执行流程
2.owner角色的tidb server定期查看job queue,负责执行ddl,它的workers模块从schema load模块中获取最新的结构信息,然后去job queue中按顺序(先进先出)抓取执行,执行后将job放入history queue中。----------1.2ddl(加索引的ddl)语句转化成job放在add index queue中。----------1.1ddl(非加索引的ddl)语句转化成job放在job queue中。owner由pd负责轮循。原创 2024-03-18 09:15:00 · 813 阅读 · 0 评论 -
tidb DML的读写流程
用户发出sql,语句会被tidb server的Protocol layer(协议层)接收,去pd获取tso时间戳,到parse(解析模块)将sql解析为ast语法树,传给compile模块(区分点查和非点查),再到execute模块(执行器),去tikv中读取数据。--------查某个表的行数,这个表在5个tikv上,每个tikv自己算好行数,汇总到tikv server的缓存里整合,cop task(协同处理)(多数节点都收到了)-------2.5清理锁信息,等于再向tikv写入清理锁的信息。原创 2024-03-18 08:30:00 · 2050 阅读 · 0 评论 -
tidb的sql的解析和编译
点查:唯一索引、主键索引为条件的增删改查,等于拿着key直接找数据,所以点查直接执行,不需要后面的优化。3.同时继续语句给到parse模块(解析),将sql转化为ast语法树,语法树给到compile模块。:根据前面的结果,结合统计信息,去看走全表扫描还是走索引,走索引看走哪个索引。:不需要的列消除(类似去重distinct)、外连接变内连接、等等。2.到pd client(与pd交互的模块)异步获取pd的tso。:合法性验证,表是否在数据库中存在、判断是否为点查 等等。原创 2024-03-17 09:30:00 · 412 阅读 · 0 评论 -
tikv总结(个人)
> ,2是key,W是写锁 ,@1表示锁的指向,指向key1,2表示key,100是事务开始时间start_ts,后面的不加锁,依附于第一行。拿着开始时间(100)和key(1)去lock的cf找到锁,1是key,W是写锁 ,pk表示主锁,key,100是事务开始时间start_ts,后面的不加锁,依附于第一行。(多数节点都收到了)的行,获取到了start_ts(100),拿着开始时间(100)和key(1)去default的cf找value(jack),成功获取值。原创 2024-03-17 09:00:00 · 918 阅读 · 0 评论 -
PD的架构与功能
pd集成了etcd,支持自动故障转移,不用担心单点故障。也通过etcd的raft保证了数据强一致性,不用担心数据丢失。一般3个节点,有个leader。原创 2024-03-16 10:00:00 · 1804 阅读 · 0 评论 -
TiKV数据读取和coprocessor
rafstore pool把raft log读出来,写给apply pool,apply pool拿着raft log,写到rocksdb kv中。Tidb server将sql语句要修改的数据载入到缓存中,用户发起commit,开始两阶段提交,会将缓存中修改的数据写入到tikv中。在10:05时想读1-95,但是1-95还在raft中,kv只到1-93,并记录下了挡球写进raft的1-97为readindex。在10:09时,readindex 97也写进kv了,此时1-95必定写进kv了,所以可读。原创 2024-03-16 08:15:00 · 1653 阅读 · 0 评论 -
TiKV的分布式Raft算法和选举机制
也会把写的信息以日志的方式发给region(follower)进行复制,当其他节点收到日志并持久化起来后,日志commited,leader将日志apply到rocksdb中,变成kv的数据。hertbeat time interval时间一到,没收到leader的统治信息,谁先到时间,谁就进入下个term,变成candidate(候选者),然后通过选举,成为新的leader。如果region过多,超过5w的region,管理成本很高,每个region要定期向pd去汇报自己的心跳,网络压力较大。原创 2024-03-15 09:00:00 · 894 阅读 · 0 评论 -
TiKV的MVCC和分布式事务流程
的行,获取到了start_ts(80),拿着开始时间(80)和key(4)去lock的cf找到锁 ,2是key,W是写锁 ,@1表示锁的指向,指向key1,2表示key,100是事务开始时间start_ts,后面的不加锁,依附于第一行。)>,1是key,W是写锁 ,pk表示主锁,key,100是事务开始时间start_ts,后面的不加锁,依附于第一行。的行,获取到了start_ts(100),拿着开始时间(100)和key(2)去lock的cf找锁,没发现锁,原创 2024-03-15 08:00:00 · 1151 阅读 · 0 评论 -
TiKV数据持久化和读取
1.将key value预写入到磁盘的日志中(wal动作)(以防断电,内存中丢失)(有个sync_log参数,如果true,那会直接写入磁盘中,不经过操作系统缓存,防止宕机导致操作系统的缓存被清空)(如果2个,当数据落盘sst后,wal文件就可以覆盖了)每个文件都有bloom filter(过滤器),如果它说这个key不在这个文件里,那key肯定不在里面,如果说在,那不一定在里面。后面的由后台进程继续。按照key排好序,二分查找法找key(因为是排好序的),找key如果在,返回,不在,找另外文件。原创 2024-03-14 14:55:35 · 507 阅读 · 0 评论 -
TiKV架构和作用
保证一个region在另2个副本中也存在,只有一个副本的rocksdb kv是leader角色,可读写,另外2个不行。raft协议会把修改应用到rocksdb kv上,然后region会将自己的修改复制到其他副本上。横向:raft协议,将修改内容应用到rocksdbkv,并且region自动复制到其他副本。:存指令的,对表的修改记录下来,然后让TiKV将指令应用到rocksdb kv中。不一定要从tikv中读出出来,到tidb server中做过滤,功能是靠集成在tikv中的rocksdb kv实现的。原创 2024-03-14 14:54:44 · 373 阅读 · 0 评论 -
Tidb server功能(3)
当写操作完成后,下一次的租约开始,从tikv中将数据重新缓存到缓存表中(cache table的refresh)。oom-action(sql超过上面阈值后,是中断显示error,还是记录日志行为,还是如何)而如果一个表只占一个region,这样的话,那个tikv非常繁忙,造成性能瓶颈。将这张小表(haha表)缓存到cache table中的语句(要求小于64m)可对表进行写操作(对tikv,而不是缓存表),此时读也是对tikv中的表读。租约时间中,能读,不能写。租约到了,缓存表过期,缓存表不可读了。原创 2024-03-14 08:15:00 · 742 阅读 · 0 评论 -
Tidb server功能(1)
根据前面的结果,结合统计信息,去看走全表扫描还是走索引,走索引看走哪个索引。:不需要的列消除(类似去重distinct)、外连接变内连接、等等。主键编号+表号=唯一key(T24_r1):合法性验证,表是否在数据库中存在等等。不用存在的主键做key。前面语法解析完生成的。原创 2024-03-13 16:34:20 · 432 阅读 · 0 评论 -
TiDB server架构
tikv client(所有交互请求都是通过tikv client 和tikv交互的)pd client(获得时间戳是pd client与pd进行交互的)的解析和编译,生成执行计划。membuffer(缓存)原创 2024-03-13 16:30:35 · 336 阅读 · 0 评论