1.linux下的分布 数据库 有哪些？
2.分布式 | dble元数据更新同步
3.分布式 | 实战：将业务从 MyCAT 平滑迁移到 dble
4.深度分析 | MGR相同GTID产生不同transaction故障分析
5.分布式 | dble 分页技巧_主键是拆分列_连续翻页
6.分布式 | 数据库连接如何正确处理 TCP 连接三次握手失败
linux下的 数据库 有哪些？
你要的全在下面：数据库已经有4代了产品很多。DBA课程更新内容大纲：
序章 DBA职业体系与数据库产品趋势
What is 式源DBA？
DBA成长体系与职业方向(0-W-W-W-?)
数据库发展历史,产品迭代趋势与职业学习方向
第一部分 OLTP数据库-MySQL(约1天)
MySQL基础入门
MySQL数据库简介
什么是数据库？什么是OLTP?
为什么学习MySQL?MySQL产品迭代
一二线大厂MySQL主流版本功能使用与特性介绍(5.1,5.6,5.7,8.0)**独家
**MySQL部署与管理体系
5.7,8.0版本企业规范部署,启动
MySQL管理体系讲解
MySQL产品架构分析与基础管理
MySQL基础架构解析(一条SQL是如何执行的)
MySQL启动过程
MySQL连接的生命与使命
MySQL表结构实现原理
MySQL开发应用（约1.5天）
MySQL SQL基础应用
声明式式语言与SQL语言
SQL语言应用场景与sqlmode
MySQL开发工具选择与使用
MySQL字符串类型与字符集
MySQL语句类型介绍(DDL,DCL,DML,DQL)
SQL之查询基础
SQL之聚合与排序
SQL之数据更新
SQL之复杂查询
SQL之集合运算
MySQL SQL高级处理与开发
函数开发与应用
存储过程,触发器，事件
表分区管理及企业级应用场景
Online DDL解析与开源生态OPS
窗口函数讲解及应用场景
MySQL JSON开发及应用
一二线大厂MySQL企业级开发规范详解**独家
**MySQL核心技术
MySQL InnoDB索引实现原理及执行计划分析（约0.5天）
索引介绍
1. 索引的码分由来
2. 表和索引结构
3. 表聚簇与索引行
4. 表行与索引组织表
MySQL索引介绍
InnoDB索引B+ tree的索引设计
聚簇索引与二级索引
InnDB索引插入过程
数据类型对索引应用的使用影响
执行计划介绍及结果剖析
索引优化基础实战演练
企业级索引优化实战案例(亿万级QPS的索引优化与索引上线)**独家
**MySQL InnoDB存储引擎技术内幕与深入讲解（约1天）
Mysql存储引擎介绍与功能特性
InnoDB引擎源代码目录结构与存储引擎文件组织
InnoDB存储引擎核心架构介绍及解析
InnoDB数据存储结构
InnoDB事务详解及ACID特性解析
InnoDB 日志管理机制Undo与Redo
InnoDB事务与隔离级别
InnoDB MVCC及锁机制
MySQL日志管理与实战（0.5）
General log详解
Error log详解
企业级Binary log with Data pipeline **独家
**企业级Slowlog场景应用**独家
**MySQL备份恢复与迁移（0.5）
备份工具介绍与使用场景解析
一二线大厂过万数据节点备份策略**独家
**一二线大厂Mysqldump核心原理与企业级实战演练**独家
**一二线大厂Xtrabackup核心原理与企业级实战演练**独家
**Enterprise Backup企业级生态工具介绍与应用
MySQL主从复制深入（约1天）
主从复制简介与简单搭建
主从复制工作原理解析
主从数据一致性方案讲解(半同步，全同步)
MySQL主从复制实战
1. 延时复制
2. 过滤复制
3. 多源复制
MySQL GTID复制
企业级主从复制故障分析与处理方案
亿级QPS MySQL节点故障转移实战案例**独家
**MySQL高可用架构（1天）
一二线大厂过万集群规模高可用架构MHA+BLB企业级实战**独家
**Mycat,布式DBLE企业级实战
MySQL企业级优化与实战（约1天）
打造高性能MySQL
企业级MySQL参数优化实战**独家
**企业级T0级别故障案例解析**独家
**阿里云数据库产品(RDS与PolarDB)（选修二选一） （1天）
企业级RDS介绍,使用与故障案例(百度云RDS 运维DBA分享或交流)**独家
**企业级PolarDB业务场景解析(阿里团队PolarDB P7交付架构师分享或交流)**独家
**第二部分 NoSQL
Redis核心技术（2天）
Redis产品介绍与应用场景简析
Redis安装，部署，分布使用
Redis数据类型详解与应用
Redis集群架构讲解与实战(哨兵,式源12位 adpcm源码cluster)
千亿级Redis集群参数优化实战**独家
**千亿级企业级Redis核心案例讲解与业务场景解析**独家
**MongoDB核心技术（2天）
MongoDB产品介绍与应用场景简析
MongoDB安装,部署及架构解析
MongoDB数据类型与运维管理
MongoDB集群架构讲解与实战
企业级MongoDB参数优化实战**独家
**BAT千万元级别故障案例分享**独家
**ES核心技术（2天）
ES产品介绍与应用场景简析
ES安装,部署及架构解析
ES日常运维管理
第三部分 NewSQL（4天）
NewSQL-TiDB(仅学此一个+MySQL至少K起步) TUG核心成员-PingCAP官方认证讲师 **独家
**TiDB产品介绍与分布式数据库技术应用讲解
TiDB集群部署与日常管理
TiDB集群监控详解与指标应用
TiDB核心架构深入讲解与Raft协议深入浅出**独家
*企业级TiDB-DM理解与应用**独家
*1. 同城亿级流量Mysql热迁移TiDB**独家
**2. DM集群多源同步复制场景最佳实践(官方认证，业界唯二)**独家
**TiDB企业级业务开发最佳实践**独家
**TiFllash核心架构讲解与实战**独家
**TiDB打造HTAP实时数仓平台架构设计**独家
**Cloud TiDB(K8S上云实战)**独家
**TiDB4.0热升级5.0集群(简介：我司与Pingcap官方{ 开发人，码分交付专家7人，布式项目经理4人}封闭测试与在线升级全案例解析6.日项目完结,分布官方认证业界目前第一的业务场景与投入)
NewSQL-TDengine（1天 选修）
TDengine产品介绍
TDengine单机版与集群部署与管理
TDengine架构体系详解
TDengine企业级参数优化与实战
TDengine业务开发规范与业务场景实战
第四部分 企业级大规模数据库集群运维开发实战(W+年薪提升)**独家
**数据运维产品架构设计思路（0.5天）
什么是数据运维平台
企业级数据运维平台架构解析
数据运维平台企业级原型设计实战（0.5天）
数据库运维自动化工具开发(Shell,Python)（2天5选2，下期轮换）
MySQL亿万级流量运维平台开发
Redis亿万级流量运维平台开发
ES亿万级流量运维平台开发
MongoDB亿万级流量运维平台开发
TiDB亿万级流量运维平台开发
分布式 | dble元数据更新同步
本文以 dble 3...0 版本为例，式源探讨社区遇到的码分元数据同步问题。首先，布式我们关注到 sharding.xml 关键配置可能导致的分布表和字段查找问题。启动 dble 后，式源在所有后端节点建立表 sharding_2_t1，码分执行 reload @@config_all 命令时查询或插入数据时报找不到表元数据，这一现象引起关注。同样，在后端节点增加表 sharding_4_t1 的字段 age，执行 reload @@config_all 后查询 age 字段正常，但使用 order by 时提示找不到字段，问题引起思考。在解答这些疑问前，我们需要理解 reload @@config_all 和 reload @@metadata 的功能及其使用场景。
reload @@config_all 重新加载所有配置文件，涉及 user.xml、java 源码打包db.xml、sharding.xml 三个文件。该命令有三个可选参数：-s、-f 和 -r。-s 参数跳过测试后端链接，-f 关闭所有变更的 dbGroup（同时加-r参数则所有 dbGroup 都视为变更），-r 不做智能判断，将所有后端连接池全部重新加载。执行此命令时，表配置信息变更时，元数据才会被重载。而 reload @@metadata 则用于重新加载所有元数据信息，支持两种扩展的过滤表达式。
问题1和问题2的报错源于对 reload @@config_all 的误解，即认为所有场景下执行该命令都会触发重新加载元数据。实际上，只有配置发生变更时才会同步更新元数据，其他情况需要手动执行 reload @@metadata 来同步后端表的元数据。问题2中，select age from sharding_4_t1 查询成功，是因为此查询直接下发到后端节点执行，无需 dble 内部使用 age 字段。
为了排查元数据错误，可使用 check full @@metadata 查看 dble 中所有表的元数据信息，并支持多种条件过滤。setuptools 源码安装通过检查，发现表 sharding_2_t1 和表 sharding_4_t1 的元数据未同步到更新。执行 reload @@metadata 后再次检查，表sharding_2_t1 和表sharding_4_t1 已同步到正确的元数据信息。现在，可以对表执行常规操作而不会遇到错误。
分布式 | 实战：将业务从 MyCAT 平滑迁移到 dble
分布式架构迁移实战：从 MyCAT 到 dble 的平稳过渡
爱可生DBA团队成员肖亚洲分享了一次重要的项目迁移经验，客户面临将业务从MyCAT切换到dble的挑战，目标是实现最小变动。在迁移过程中，他们面临了多个关键问题和调整。
首先，参数配置是关键。MyCAT的某些参数需要调整为适应dble的内存管理，例如放弃threadlocal概念，参考actiontech.github.io/db...文档进行配置。同时，MyCAT的分片函数，如mod-long，由于处理长整型范围限制，与dble的哈希算法不兼容。建议切换到HashString算法，并处理历史数据导入问题。
引入dble的自定义算法，如PartitionByMod，caffe源码 卷积可以保持与MyCAT存储节点数据的兼容性，降低了数据迁移的工作量。然而，DBLE对SQL处理策略的调整可能影响到业务查询，因此需要仔细测试并确保业务SQL的准确执行。
更多关于DBLE对MyCat增强的细节，可参考actiontech.github.io/db...。这次迁移的成功，不仅解决了现有问题，也为后续的分布式架构优化提供了宝贵经验。
深度分析 | MGR相同GTID产生不同transaction故障分析
在MGR高可用方案的使用中，我们经常会遇到因网络抖动导致集群故障的情况。最近，某客户遇到了一个具体问题，即在生产环境中的一组MGR集群中，虽然在相同的GTIDafbf-1b8c-e8-f-a4:下执行了相同的事务，但binlog日志显示了不同的事务信息。具体现象是，primary节点执行了对world.IC_WB_RELEASE表的insert操作，但这一操作没有同步到secondary节点，导致secondary节点的数据与primary节点不一致。当表IC_WB_RELEASE发生delete操作时，这一数据不一致引发故障，使从节点脱离集群。
为深入分析此问题，jar内源码我们首先考察了主从实例在GTID相同但事务不同的原因。这一问题可能与特定的bug相关联，重点在于MGR同步事务的时序。MGR全组同步数据的Xcom组件基于paxos算法实现，每次提交新生事务时，主实例会将新生事务发送给从实例进行协商。在组内协商通过后，全组成员一起提交事务。每个节点以相同的顺序接收相同的事务日志，从而保持一致的状态。
在paxos算法中，有两个关键角色：提议者和接受者。算法的达成共识过程分为两个阶段。针对本文案例，我们需关注以下几个关键点：primary节点执行insert操作，向组内发送准备请求并收到大多数成员的确认，然后发送接受请求。同时，其他从节点由于网络原因未能接收到主实例的accept请求。其中一台从实例开始新的prepare请求，请求的值为no_op（空操作），并使用一个较大的ballot值（节点编号）。其他从实例由于收到过主节点的值，因此将主节点的提案作为新的提案，覆盖了主实例的提案，导致主实例的提案未被接受。
结合源码中的handle_ack_prepare逻辑，我们分析了这一过程。在accept阶段，主节点收到组内大多数成员的确认并接收到自己的learn_op信息，因此提交了自己的提案（binlog中的insert操作）。而其他实例的提案为no_op，因此没有进行任何事务提交。此时，主实例的GTID大于其他从实例的GTID，导致主从binlog中GTID相同但事务不同的现象。
当业务执行到对表world.IC_WB_RELEASE的delete操作时，主实例能够执行操作，而其他实例由于没有执行过插入操作，无法进行删除，从而导致集群分裂。这一过程总结了故障的根本原因。
为解决此问题，我们向官方提交了SR，并得到了反馈，修复将应用于社区版MySQL 5.7.和MySQL 8.0.中。对于使用企业版的客户，可申请最新的hotfix版本。在升级MySQL版本之前，如果再次遇到此类故障，需人工检查切换时binlog中的GTID信息与新主节点对应GTID的信息是否一致。如果不一致，需要人工修复至一致状态，确保原主节点能够安全加回集群。
对于使用MGR 5.7.之前社区版的DBA，需注意避免此类故障。爱可生开源社区提供了丰富的资源和指导，包括DBLE系列公开课、技术分享、使用指南和深度分析文章等。同时，开源分布式中间件DBLE和数据传输中间件DTLE的社区官网和GitHub主页提供了进一步的技术支持和交流。
分布式 | dble 分页技巧_主键是拆分列_连续翻页
钟悦，某大型国有银行数据库专家，多年从事MySQL和分布式中间件设计与实施工作。他也是DBLE开源项目的积极参与者。
一、场景描述
对于生成唯一编号的订单、交易流水表，通常应用层负责生成唯一ID，DBLE据此进行分库分表。本文聚焦于满足特定条件的场景下的分页技巧，条件包括：表结构与拆分方式。
二、直接翻页
MySQL支持使用LIMIT语法进行分页，但当页码增大时，直接翻页的性能逐渐恶化。原因在于此时DBLE无法下推计算给MySQL，导致MySQL执行LIMIT时需要处理更多数据，性能下降。
三、最佳实践
为了克服直接翻页的性能问题，关键在于解决DBLE只能下推LIMIT 0, n*M的局限。通过在DB层实现id排序，使用WHERE条件id > maxId过滤不需记录，可以实现LIMIT M的恒定。具体实践如下：
1. 获取首页
直接使用直接翻页SQL获取首页，并记录返回结果中id字段的最小值和最大值，分别为minId和maxId，用于后续翻页。
2. 向后/向前翻页
对于向后翻页，替换SQL中的maxId后，交给DBLE执行。返回的记录已按id排序，即为下一页内容。记得更新minId和maxId。同样，向前翻页替换minId后执行，确保minId更新。
最佳实践的限制与注意事项在于确保排序与id值的有效管理，避免在处理大量数据时超出MySQL的包大小限制。
分布式 | 数据库连接如何正确处理 TCP 连接三次握手失败
在分布式环境中，特别是处理数据库连接时，TCP三次握手失败可能遇到的问题和解决策略。爱可生dble团队开发成员鲍凤其分享了他的观察和经验。当dble初始化后端连接池时，可能会出现连接计数器与实际连接不符的情况，可能源于TCP syn_cookie机制的异常。通过调整TCP参数，如关闭syn_cookie，可以暂时缓解问题，但理解三次握手的异常处理至关重要。 在实验中，我们探讨了三种异常情况：当TCP第一次握手的SYN报文丢失时，客户端会重传，最多尝试六次，重试间隔为指数级增长。客户端内核参数tcp_synack_retries可以影响重试次数。
如果第二次握手的SYN+ACK报文丢失，客户端和服务器都会尝试重传，直到收到对方的响应。服务器在收到第三次SYN后，即使重传ACK，也会因为重试定时器未重置而继续发送。
第三次握手的ACK丢包，客户端连接已建立，但服务器持续重试，直至达到最大次数。客户端的连接状态显示为ESTABLISHED，而服务器在SYN_RECV状态。
针对客户端的行为，分为发送数据和无操作两种情况：发送数据时，如果连接被中断，客户端可能会重传多达十一次，直到数据成功发送或达到重传限制。TCP重传次数由tcp_retries2参数控制。
无操作情况下，如果MySQL服务端连接中断，客户端会保持挂起状态，直到TCP保活机制触发，如Linux内核的keep-alive参数可以调整保活时间和探测频率。
理解这些异常处理机制有助于在分布式环境中优化数据库连接的稳定性。