本文目录一览：
- 1、mysql 核心内容-上
- 2、访问服务器mysql数据库，ssh登陆，分别使用的是什么协议？
- 3、五大常见的MySQL高可用方案(最全)
- 4、遵守gpl协议的mysql数据库 甲骨文是否有权收费
- 5、MySQL与Redis数据库连接池介绍（图示+源码+代码演示）
- 6、如何处理mysql数据库并发更新问题
mysql 核心内容-上
1、SQL语句执行流程
MySQL大体上可分为Server层和存储引擎层两部分。
Server层：
连接器：TCP握手后服务器来验证登陆用户身份，A用户创建连接后，管理员对A用户权限修改了也不会影响到已经创建的链接权限，必须重新登陆。
查询缓存：查询后的结果存储位置，MySQL8.0版本以后已经取消，因为查询缓存失效太频繁，得不偿失。
分析器：根据语法规则，判断你输入的这个SQL语句是否满足MySQL语法。
优化器：多种执行策略可实现目标，系统自动选择最优进行执行。
执行器：判断是否有权限，将最终任务提交到存储引擎。
存储引擎层
负责数据的存储和提取。其架构模式是插件式的，支持InnoDB、MyISAM、Memory等多个存储引擎。现在最常用的存储引擎是InnoDB，它从MySQL 5.5.5版本开始成为了默认存储引擎(经常用的也是这个)。
SQL执行顺序
2、BinLog、RedoLog、UndoLog
BinLog
BinLog是记录所有数据库表结构变更（例如create、alter table）以及表数据修改(insert、update、delete)的二进制日志，主从数据库同步用到的都是BinLog文件。BinLog日志文件有三种模式。
STATEMENT 模式
内容：binlog 记录可能引起数据变更的 sql 语句
优势：该模式下，因为没有记录实际的数据，所以日志量很少 IO 都消耗很低，性能是最优的
劣势：但有些操作并不是确定的，比如 uuid() 函数会随机产生唯一标识，当依赖 binlog 回放时，该操作生成的数据与原数据必然是不同的，此时可能造成无法预料的后果。
ROW 模式
内容：在该模式下，binlog 会记录每次操作的源数据与修改后的目标数据，StreamSets就要求该模式。
优势：可以绝对精准的还原，从而保证了数据的安全与可靠，并且复制和数据恢复过程可以是并发进行的
劣势：缺点在于 binlog 体积会非常大，同时，对于修改记录多、字段长度大的操作来说，记录时性能消耗会很严重。阅读的时候也需要特殊指令来进行读取数据。
MIXED 模式
内容：是对上述STATEMENT 跟 ROW 两种模式的混合使用。
细节：对于绝大部分操作，都是使用 STATEMENT 来进行 binlog 没有记录，只有以下操作使用 ROW 来实现：表的存储引擎为 NDB，使用了uuid() 等不确定函数，使用了 insert delay 语句，使用了临时表
主从同步流程：
1、主节点必须启用二进制日志，记录任何修改了数据库数据的事件。
2、从节点开启一个线程（I/O Thread)把自己扮演成 mysql 的客户端，通过 mysql 协议，请求主节点的二进制日志文件中的事件 。
3、主节点启动一个线程（dump Thread），检查自己二进制日志中的事件，跟对方请求的位置对比，如果不带请求位置参数，则主节点就会从第一个日志文件中的第一个事件一个一个发送给从节点。
4、从节点接收到主节点发送过来的数据把它放置到中继日志（Relay log）文件中。并记录该次请求到主节点的具体哪一个二进制日志文件内部的哪一个位置（主节点中的二进制文件会有多个）。
5、从节点启动另外一个线程（sql Thread ），把 Relay log 中的事件读取出来，并在本地再执行一次。
mysql默认的复制方式是异步的，并且复制的时候是有并行复制能力的。主库把日志发送给从库后不管了，这样会产生一个问题就是假设主库挂了，从库处理失败了，这时候从库升为主库后，日志就丢失了。由此产生两个概念。
全同步复制
主库写入binlog后强制同步日志到从库，所有的从库都执行完成后才返回给客户端，但是很显然这个方式的话性能会受到严重影响。
半同步复制
半同步复制的逻辑是这样，从库写入日志成功后返回ACK确认给主库，主库收到至少一个从库的确认就认为写操作完成。
还可以延伸到由于主从配置不一样、主库大事务、从库压力过大、网络震荡等造成主备延迟，如何避免这个问题？主备切换的时候用可靠性优先原则还是可用性优先原则？如何判断主库Crash了？互为主备的情况下如何避免主备循环复制？被删库跑路了如何正确恢复？( o )… 感觉越来越扯到DBA的活儿上去了。
RedoLog
可以先通过下面demo理解：
饭点记账可以把账单写在账本上也可以写在粉板上。有人赊账或者还账的话，一般有两种做法：
1、直接把账本翻出来，把这次赊的账加上去或者扣除掉。
2、先在粉板上记下这次的账，等打烊以后再把账本翻出来核算。
生意忙时选后者，因为前者太麻烦了。得在密密麻麻的记录中找到这个人的赊账总额信息，找到之后再拿出算盘计算，最后再将结果写回到账本上。
同样在MySQL中如果每一次的更新操作都需要写进磁盘，然后磁盘也要找到对应的那条记录，然后再更新，整个过程IO成本、查找成本都很高。而粉板和账本配合的整个过程就是MySQL用到的是Write-Ahead Logging 技术，它的关键点就是先写日志，再写磁盘。此时账本 = BinLog，粉板 = RedoLog。
1、 记录更新时，InnoDB引擎就会先把记录写到RedoLog（粉板）里面，并更新内存。同时，InnoDB引擎会在空闲时将这个操作记录更新到磁盘里面。
2、 如果更新太多RedoLog处理不了的时候，需先将RedoLog部分数据写到磁盘，然后擦除RedoLog部分数据。RedoLog类似转盘。
RedoLog有write pos 跟checkpoint
write pos ：是当前记录的位置，一边写一边后移，写到第3号文件末尾后就回到0号文件开头。
check point：是当前要擦除的位置，也是往后推移并且循环的，擦除记录前要把记录更新到数据文件。
write pos和check point之间的是粉板上还空着的部分，可以用来记录新的操作。如果write pos追上checkpoint，表示粉板满了，这时候不能再执行新的更新，得停下来先擦掉一些记录，把checkpoint推进一下。
有了redo log，InnoDB就可以保证即使数据库发生异常重启，之前提交的记录都不会丢失，这个能力称为crash-safe。 redolog两阶段提交：为了让binlog跟redolog两份日志之间的逻辑一致。提交流程大致如下：
1 prepare阶段 -- 2 写binlog -- 3 commit
当在2之前崩溃时，重启恢复后发现没有commit，回滚。备份恢复：没有binlog 。一致
当在3之前崩溃时，重启恢复发现虽没有commit，但满足prepare和binlog完整，所以重启后会自动commit。备份：有binlog. 一致
binlog跟redolog区别：
redo log是InnoDB引擎特有的；binlog是MySQL的Server层实现的，所有引擎都可以使用。
redo log是物理日志，记录的是在某个数据页上做了什么修改；binlog是逻辑日志，记录的是这个语句的原始逻辑，比如给ID=2这一行的c字段加1。
redo log是循环写的，空间固定会用完；binlog是可以追加写入的。追加写是指binlog文件写到一定大小后会切换到下一个，并不会覆盖以前的日志。
UndoLog
UndoLog 一般是逻辑日志，主要分为两种：
insert undo log
代表事务在insert新记录时产生的undo log, 只在事务回滚时需要，并且在事务提交后可以被立即丢弃
update undo log
事务在进行update或delete时产生的undo log; 不仅在事务回滚时需要，在快照读时也需要；所以不能随便删除，只有在快速读或事务回滚不涉及该日志时，对应的日志才会被purge线程统一清除
3、MySQL中的索引
索引的常见模型有哈希表、有序数组和搜索树。
哈希表：一种以KV存储数据的结构，只适合等值查询，不适合范围查询。
有序数组：只适用于静态存储引擎，涉及到插入的时候比较麻烦。可以参考Java中的ArrayList。
搜索树：按照数据结构中的二叉树来存储数据，不过此时是N叉树(B+树)。广泛应用在存储引擎层中。
B+树比B树优势在于：
B+ 树非叶子节点存储的只是索引，可以存储的更多。B+树比B树更加矮胖，IO次数更少。
B+ 树叶子节点前后管理，更加方便范围查询。同时结果都在叶子节点，查询效率稳定。
B+树中更有利于对数据扫描，可以避免B树的回溯扫描。
索引的优点：
1、唯一索引可以保证每一行数据的唯一性
2、提高查询速度
3、加速表与表的连接
4、显著的减少查询中分组和排序的时间
5、通过使用索引，可以在查询的过程中，使用优化隐藏器，提高系统的性能。
索引的缺点：
1、创建跟维护都需要耗时
2、创建索引时，需要对表加锁，在锁表的同时，可能会影响到其他的数据操作
3、 索引需要磁盘的空间进行存储，磁盘占用也很快。
4、当对表中的数据进行CRUD的时，也会触发索引的维护，而维护索引需要时间，可能会降低数据操作性能
索引设计的原则不应该：
1、索引不是越多越好。索引太多，维护索引需要时间跟空间。
2、 频繁更新的数据，不宜建索引。
3、数据量小的表没必要建立索引。
应该：
1、重复率小的列建议生成索引。因为重复数据少，索引树查询更有效率，等价基数越大越好。
2、数据具有唯一性，建议生成唯一性索引。在数据库的层面，保证数据正确性
3、频繁group by、order by的列建议生成索引。可以大幅提高分组和排序效率
4、经常用于查询条件的字段建议生成索引。通过索引查询，速度更快
索引失效的场景
1、模糊搜索：左模糊或全模糊都会导致索引失效，比如'%a'和'%a%'。但是右模糊是可以利用索引的，比如'a%' 。
2、隐式类型转换：比如select * from t where name = xxx , name是字符串类型，但是没有加引号，所以是由MySQL隐式转换的，所以会让索引失效 3、当语句中带有or的时候：比如select * from t where name=‘sw’ or age=14
4、不符合联合索引的最左前缀匹配：(A,B,C)的联合索引，你只where了C或B或只有B,C
关于索引的知识点：
主键索引：主键索引的叶子节点存的是整行数据信息。在InnoDB里，主键索引也被称为聚簇索引（clustered index）。主键自增是无法保证完全自增的哦，遇到唯一键冲突、事务回滚等都可能导致不连续。
唯一索引：以唯一列生成的索引，该列不允许有重复值，但允许有空值(NULL)
普通索引跟唯一索引查询性能：InnoDB的数据是按数据页为单位来读写的，默认每页16KB，因此这两种索引查询数据性能差别微乎其微。
change buffer：普通索引用在更新过程的加速，更新的字段如果在缓存中，如果是普通索引则直接更新即可。如果是唯一索引需要将所有数据读入内存来确保不违背唯一性，所以尽量用普通索引。
非主键索引：非主键索引的叶子节点内容是主键的值。在InnoDB里，非主键索引也被称为二级索引（secondary index）
回表：先通过数据库索引扫描出数据所在的行，再通过行主键id取出索引中未提供的数据，即基于非主键索引的查询需要多扫描一棵索引树。
覆盖索引：如果一个索引包含（或者说覆盖）所有需要查询的字段的值，我们就称之为覆盖索引。
联合索引：相对单列索引，组合索引是用多个列组合构建的索引，一次性最多联合16个。
最左前缀原则：对多个字段同时建立的组合索引(有顺序，ABC，ACB是完全不同的两种联合索引) 以联合索引(a,b,c)为例，建立这样的索引相当于建立了索引a、ab、abc三个索引。另外组合索引实际还是一个索引，并非真的创建了多个索引，只是产生的效果等价于产生多个索引。
索引下推：MySQL 5.6引入了索引下推优化，可以在索引遍历过程中，对索引中包含的字段先做判断，过滤掉不符合条件的记录，减少回表字数。
索引维护：B+树为了维护索引有序性涉及到页分裂跟页合并。增删数据时需考虑页空间利用率。
自增主键：一般会建立与业务无关的自增主键，不会触发叶子节点分裂。
延迟关联：通过使用覆盖索引查询返回需要的主键，再根据主键关联原表获得需要的数据。
InnoDB存储: * .frm文件是一份定义文件，也就是定义数据库表是一张怎么样的表。*.ibd文件则是该表的索引，数据存储文件，既该表的所有索引树，所有行记录数据都存储在该文件中。
MyISAM存储：* .frm文件是一份定义文件，也就是定义数据库表是一张怎么样的表。* .MYD文件是MyISAM存储引擎表的所有行数据的文件。* .MYI文件存放的是MyISAM存储引擎表的索引相关数据的文件。MyISAM引擎下，表数据和表索引数据是分开存储的。
MyISAM查询：在MyISAM下，主键索引和辅助键索引都属于非聚簇索引。查询不管是走主键索引，还是非主键索引，在叶子结点得到的都是目的数据的地址，还需要通过该地址，才能在数据文件中找到目的数据。
PS：InnoDB支持聚簇索引，MyISAM不支持聚簇索引
4、SQL事务隔离级别
ACID的四个特性
原子性（Atomicity）：把多个操作放到一个事务中，保证这些操作要么都成功，要么都不成功
一致性（Consistency）：理解成一串对数据进行操作的程序执行下来，不会对数据产生不好的影响，比如凭空产生，或消失
隔离性（Isolation，又称独立性）：隔离性的意思就是多个事务之间互相不干扰，即使是并发事务的情况下，他们只是两个并发执行没有交集，互不影响的东西；当然实现中，也不一定需要这么完整隔离性，即不一定需要这么的互不干扰，有时候还是允许有部分干扰的。所以MySQL可以支持4种事务隔离性
持久性（Durability）：当某个操作操作完毕了，那么结果就是这样了，并且这个操作会持久化到日志记录中
PS：ACID中C与CAP定理中C的区别
ACID的C着重强调单数据库事务操作时，要保证数据的完整和正确性，数据不会凭空消失跟增加。CAP 理论中的C指的是对一个数据多个备份的读写一致性
事务操作可能会出现的数据问题
1、脏读(dirty read)：B事务更改数据还未提交，A事务已经看到并且用了。B事务如果回滚，则A事务做错了
2、 不可重复读(non-repeatable read)：不可重复读的重点是修改: 同样的条件, 你读取过的数据, 再次读取出来发现值不一样了，只需要锁住满足条件的记录
3、 幻读(phantom read)：事务A先修改了某个表的所有纪录的状态字段为已处理，未提交；事务B也在此时新增了一条未处理的记录，并提交了；事务A随后查询记录，却发现有一条记录是未处理的造成幻读现象，幻读仅专指新插入的行。幻读会造成语义上的问题跟数据一致性问题。
4、 在可重复读RR隔离级别下，普通查询是快照读，是不会看到别的事务插入的数据的。因此，幻读在当前读下才会出现。要用间隙锁解决此问题。
在说隔离级别之前，你首先要知道，你隔离得越严实，效率就会越低。因此很多时候，我们都要在二者之间寻找一个平衡点。SQL标准的事务隔离级别由低到高如下： 上图从上到下的模式会导致系统的并行性能依次降低，安全性依次提高。
读未提交：别人改数据的事务尚未提交，我在我的事务中也能读到。
读已提交(Oracle默认)：别人改数据的事务已经提交，我在我的事务中才能读到。
可重复读(MySQL默认)：别人改数据的事务已经提交，我在我的事务中也不去读，以此保证重复读一致性。
串行：我的事务尚未提交，别人就别想改数据。
标准跟实现：上面都是关于事务的标准，但是每一种数据库都有不同的实现，比如MySQL InnDB 默认为RR级别，但是不会出现幻读。因为当事务A更新了所有记录的某个字段，此时事务A会获得对这个表的表锁，因为事务A还没有提交，所以事务A获得的锁没有释放，此时事务B在该表插入新记录，会因为无法获得该表的锁，则导致插入操作被阻塞。只有事务A提交了事务后，释放了锁，事务B才能进行接下去的操作。所以可以说 MySQL的RR级别的隔离是已经实现解决了脏读，不可重复读和幻读的。
5、MySQL中的锁
无论是Java的并发编程还是数据库的并发操作都会涉及到锁，研发人员引入了悲观锁跟乐观锁这样一种锁的设计思想。
悲观锁：
优点：适合在写多读少的并发环境中使用，虽然无法维持非常高的性能，但是在乐观锁无法提更好的性能前提下，可以做到数据的安全性
缺点：加锁会增加系统开销，虽然能保证数据的安全，但数据处理吞吐量低，不适合在读书写少的场合下使用
乐观锁：
优点：在读多写少的并发场景下，可以避免数据库加锁的开销，提高DAO层的响应性能，很多情况下ORM工具都有带有乐观锁的实现，所以这些方法不一定需要我们人为的去实现。
缺点：在写多读少的并发场景下，即在写操作竞争激烈的情况下，会导致CAS多次重试，冲突频率过高，导致开销比悲观锁更高。
实现：数据库层面的乐观锁其实跟CAS思想类似， 通数据版本号或者时间戳也可以实现。
数据库并发场景主要有三种：
读-读：不存在任何问题，也不需要并发控制
读-写：有隔离性问题，可能遇到脏读，幻读，不可重复读
写-写：可能存更新丢失问题，比如第一类更新丢失，第二类更新丢失
两类更新丢失问题：
第一类更新丢失：事务A的事务回滚覆盖了事务B已提交的结果 第二类更新丢失：事务A的提交覆盖了事务B已提交的结果
为了合理贯彻落实锁的思想，MySQL中引入了杂七杂八的各种锁：
锁分类
MySQL支持三种层级的锁定，分别为
表级锁定
MySQL中锁定粒度最大的一种锁，最常使用的MYISAM与INNODB都支持表级锁定。
页级锁定
是MySQL中锁定粒度介于行级锁和表级锁中间的一种锁，表级锁速度快，但冲突多，行级冲突少，但速度慢。所以取了折衷的页级，一次锁定相邻的一组记录。
行级锁定
Mysql中锁定粒度最细的一种锁，表示只针对当前操作的行进行加锁。行级锁能大大减少数据库操作的冲突。其加锁粒度最小，但加锁的开销也最大行级锁不一定比表级锁要好：锁的粒度越细，代价越高，相比表级锁在表的头部直接加锁，行级锁还要扫描找到对应的行对其上锁，这样的代价其实是比较高的，所以表锁和行锁各有所长。
MyISAM中的锁
虽然MySQL支持表，页，行三级锁定，但MyISAM存储引擎只支持表锁。所以MyISAM的加锁相对比较开销低，但数据操作的并发性能相对就不高。但如果写操作都是尾插入，那还是可以支持一定程度的读写并发
从MyISAM所支持的锁中也可以看出，MyISAM是一个支持读读并发，但不支持通用读写并发，写写并发的数据库引擎，所以它更适合用于读多写少的应用场合，一般工程中也用的较少。
InnoDB中的锁
该模式下支持的锁实在是太多了，具体如下：
共享锁和排他锁 (Shared and Exclusive Locks)
意向锁（Intention Locks）
记录锁（Record Locks）
间隙锁（Gap Locks）
临键锁 （Next-Key Locks）
插入意向锁（Insert Intention Locks）
主键自增锁 (AUTO-INC Locks)
空间索引断言锁（Predicate Locks for Spatial Indexes）
举个栗子，比如行锁里的共享锁跟排它锁：lock in share modle 共享读锁：
为了确保自己查到的数据没有被其他的事务正在修改，也就是说确保查到的数据是最新的数据，并且不允许其他人来修改数据。但是自己不一定能够修改数据，因为有可能其他的事务也对这些数据使用了 in share mode 的方式上了S 锁。如果不及时的commit 或者rollback 也可能会造成大量的事务等待。
for update排它写锁:
为了让自己查到的数据确保是最新数据，并且查到后的数据只允许自己来修改的时候，需要用到for update。相当于一个 update 语句。在业务繁忙的情况下，如果事务没有及时的commit或者rollback 可能会造成其他事务长时间的等待，从而影响数据库的并发使用效率。
Gap Lock间隙锁：
1、行锁只能锁住行，如果在记录之间的间隙插入数据就无法解决了，因此MySQL引入了间隙锁(Gap Lock)。间隙锁是左右开区间。间隙锁之间不会冲突。
2、间隙锁和行锁合称NextKeyLock，每个NextKeyLock是前开后闭区间。
间隙锁加锁原则(学完忘那种)：
1、加锁的基本单位是 NextKeyLock，是前开后闭区间。
2、查找过程中访问到的对象才会加锁。
3、索引上的等值查询，给唯一索引加锁的时候，NextKeyLock退化为行锁。
4、索引上的等值查询，向右遍历时且最后一个值不满足等值条件的时候，NextKeyLock退化为间隙锁。
5、唯一索引上的范围查询会访问到不满足条件的第一个值为止。
访问服务器mysql数据库，ssh登陆，分别使用的是什么协议？
访问网页服务器是HTTP协议，mysql数据库用的是tcp/ip协议 ssh登录用的ssh协议
五大常见的MySQL高可用方案(最全)
1. 概述
我们在考虑MySQL数据库的高可用的架构时，主要要考虑如下几方面：
如果数据库发生了宕机或者意外中断等故障，能尽快恢复数据库的可用性，尽可能的减少停机时间，保证业务不会因为数据库的故障而中断。
用作备份、只读副本等功能的非主节点的数据应该和主节点的数据实时或者最终保持一致。
当业务发生数据库切换时，切换前后的数据库内容应当一致，不会因为数据缺失或者数据不一致而影响业务。
关于对高可用的分级在这里我们不做详细的讨论，这里只讨论常用高可用方案的优缺点以及高可用方案的选型。
2. 高可用方案
2.1. 主从或主主半同步复制
使用双节点数据库，搭建单向或者双向的半同步复制。在5.7以后的版本中，由于lossless replication、logical多线程复制等一些列新特性的引入，使得MySQL原生半同步复制更加可靠。
常见架构如下：
通常会和proxy、keepalived等第三方软件同时使用，即可以用来监控数据库的 健康 ，又可以执行一系列管理命令。如果主库发生故障，切换到备库后仍然可以继续使用数据库。
优点：
架构比较简单，使用原生半同步复制作为数据同步的依据；
双节点，没有主机宕机后的选主问题，直接切换即可；
双节点，需求资源少，部署简单；
缺点：
完全依赖于半同步复制，如果半同步复制退化为异步复制，数据一致性无法得到保证；
需要额外考虑haproxy、keepalived的高可用机制。
2.2. 半同步复制优化
半同步复制机制是可靠的。如果半同步复制一直是生效的，那么便可以认为数据是一致的。但是由于网络波动等一些客观原因，导致半同步复制发生超时而切换为异步复制，那么这时便不能保证数据的一致性。所以尽可能的保证半同步复制，便可提高数据的一致性。
该方案同样使用双节点架构，但是在原有半同复制的基础上做了功能上的优化，使半同步复制的机制变得更加可靠。
可参考的优化方案如下：
2.2.1. 双通道复制
半同步复制由于发生超时后，复制断开，当再次建立起复制时，同时建立两条通道，其中一条半同步复制通道从当前位置开始复制，保证从机知道当前主机执行的进度。另外一条异步复制通道开始追补从机落后的数据。当异步复制通道追赶到半同步复制的起始位置时，恢复半同步复制。
2.2.2. binlog文件服务器
搭建两条半同步复制通道，其中连接文件服务器的半同步通道正常情况下不启用，当主从的半同步复制发生网络问题退化后，启动与文件服务器的半同步复制通道。当主从半同步复制恢复后，关闭与文件服务器的半同步复制通道。
优点：
双节点，需求资源少，部署简单；
架构简单，没有选主的问题，直接切换即可;
相比于原生复制，优化后的半同步复制更能保证数据的一致性。
缺点：
需要修改内核源码或者使用mysql通信协议。需要对源码有一定的了解，并能做一定程度的二次开发。
依旧依赖于半同步复制，没有从根本上解决数据一致性问题。
2.3. 高可用架构优化
将双节点数据库扩展到多节点数据库，或者多节点数据库集群。可以根据自己的需要选择一主两从、一主多从或者多主多从的集群。
由于半同步复制，存在接收到一个从机的成功应答即认为半同步复制成功的特性，所以多从半同步复制的可靠性要优于单从半同步复制的可靠性。并且多节点同时宕机的几率也要小于单节点宕机的几率，所以多节点架构在一定程度上可以认为高可用性是好于双节点架构。
但是由于数据库数量较多，所以需要数据库管理软件来保证数据库的可维护性。可以选择MMM、MHA或者各个版本的proxy等等。常见方案如下：
2.3.1. MHA+多节点集群
MHA Manager会定时探测集群中的master节点，当master出现故障时，它可以自动将最新数据的slave提升为新的master，然后将所有其他的slave重新指向新的master，整个故障转移过程对应用程序完全透明。
MHA Node运行在每台MySQL服务器上，主要作用是切换时处理二进制日志，确保切换尽量少丢数据。
MHA也可以扩展到如下的多节点集群：
优点：
可以进行故障的自动检测和转移;
可扩展性较好，可以根据需要扩展MySQL的节点数量和结构;
相比于双节点的MySQL复制，三节点/多节点的MySQL发生不可用的概率更低
缺点：
至少需要三节点，相对于双节点需要更多的资源;
逻辑较为复杂，发生故障后排查问题，定位问题更加困难;
数据一致性仍然靠原生半同步复制保证，仍然存在数据不一致的风险;
可能因为网络分区发生脑裂现象;
2.3.2. zookeeper+proxy
Zookeeper使用分布式算法保证集群数据的一致性，使用zookeeper可以有效的保证proxy的高可用性，可以较好的避免网络分区现象的产生。
优点：
较好的保证了整个系统的高可用性，包括proxy、MySQL;
扩展性较好，可以扩展为大规模集群;
缺点：
数据一致性仍然依赖于原生的mysql半同步复制;
引入zk，整个系统的逻辑变得更加复杂;
2.4. 共享存储
共享存储实现了数据库服务器和存储设备的解耦，不同数据库之间的数据同步不再依赖于MySQL的原生复制功能，而是通过磁盘数据同步的手段，来保证数据的一致性。
2.4.1. SAN共享储存
SAN的概念是允许存储设备和处理器（服务器）之间建立直接的高速网络（与LAN相比）连接，通过这种连接实现数据的集中式存储。常用架构如下：
使用共享存储时，MySQL服务器能够正常挂载文件系统并操作，如果主库发生宕机，备库可以挂载相同的文件系统，保证主库和备库使用相同的数据。
优点：
两节点即可，部署简单，切换逻辑简单；
很好的保证数据的强一致性；
不会因为MySQL的逻辑错误发生数据不一致的情况；
缺点：
需要考虑共享存储的高可用；
价格昂贵；
2.4.2. DRBD磁盘复制
DRBD是一种基于软件、基于网络的块复制存储解决方案，主要用于对服务器之间的磁盘、分区、逻辑卷等进行数据镜像，当用户将数据写入本地磁盘时，还会将数据发送到网络中另一台主机的磁盘上，这样的本地主机(主节点)与远程主机(备节点)的数据就可以保证实时同步。常用架构如下：
当本地主机出现问题，远程主机上还保留着一份相同的数据，可以继续使用，保证了数据的安全。
DRBD是linux内核模块实现的快级别的同步复制技术，可以与SAN达到相同的共享存储效果。
优点：
两节点即可，部署简单，切换逻辑简单；
相比于SAN储存网络，价格低廉；
保证数据的强一致性；
缺点：
对io性能影响较大；
从库不提供读操作；
2.5. 分布式协议
分布式协议可以很好解决数据一致性问题。比较常见的方案如下：
2.5.1. MySQL cluster
MySQL cluster是官方集群的部署方案，通过使用NDB存储引擎实时备份冗余数据，实现数据库的高可用性和数据一致性。
优点：
全部使用官方组件，不依赖于第三方软件；
可以实现数据的强一致性；
缺点：
国内使用的较少；
配置较复杂，需要使用NDB储存引擎，与MySQL常规引擎存在一定差异；
至少三节点；
2.5.2. Galera
基于Galera的MySQL高可用集群， 是多主数据同步的MySQL集群解决方案，使用简单，没有单点故障，可用性高。常见架构如下：
优点：
多主写入，无延迟复制，能保证数据强一致性；
有成熟的社区，有互联网公司在大规模的使用；
自动故障转移，自动添加、剔除节点；
缺点：
需要为原生MySQL节点打wsrep补丁
只支持innodb储存引擎
至少三节点；
2.5.3. POAXS
Paxos 算法解决的问题是一个分布式系统如何就某个值（决议）达成一致。这个算法被认为是同类算法中最有效的。Paxos与MySQL相结合可以实现在分布式的MySQL数据的强一致性。常见架构如下：
优点：
多主写入，无延迟复制，能保证数据强一致性；
有成熟理论基础；
自动故障转移，自动添加、剔除节点；
缺点：
只支持innodb储存引擎
至少三节点；
3. 总结
随着人们对数据一致性的要求不断的提高，越来越多的方法被尝试用来解决分布式数据一致性的问题，如MySQL自身的优化、MySQL集群架构的优化、Paxos、Raft、2PC算法的引入等等。
而使用分布式算法用来解决MySQL数据库数据一致性的问题的方法，也越来越被人们所接受，一系列成熟的产品如PhxSQL、MariaDB Galera Cluster、Percona XtraDB Cluster等越来越多的被大规模使用。
随着官方MySQL Group Replication的GA，使用分布式协议来解决数据一致性问题已经成为了主流的方向。期望越来越多优秀的解决方案被提出，MySQL高可用问题可以被更好的解决。
遵守gpl协议的mysql数据库 甲骨文是否有权收费
MySQL 遵守的不只是 GPL 协议，而是双授权模式（dual license）[8] 即你在遵守 GPL 协议的开源项目使用 MySQL，需要遵守 GPL 协议方能使用。如果你在非开源项目使用（即软件不打算开放源代码），且该软件用来销售，则需要向 MySQL 支付相应 license 费用。[9]
MySQL与Redis数据库连接池介绍（图示+源码+代码演示）
数据库连接池（Connection pooling）是程序启动时建立足够的数据库连接，并将这些连接组成一个连接池，由程序动态地对池中的连接进行申请，使用，释放。
简单的说：创建数据库连接是一个很耗时的操作，也容易对数据库造成安全隐患。所以，在程序初始化的时候，集中创建多个数据库连接，并把他们集中管理，供程序使用，可以保证较快的数据库读写速度，还更加安全可靠。
不使用数据库连接池
如果不使用数据库连接池，对于每一次SQL操作，都要走一遍下面完整的流程：
1.TCP建立连接的三次握手（客户端与 MySQL服务器的连接基于TCP协议）
2.MySQL认证的三次我收
3.真正的SQL执行
4.MySQL的关闭
5.TCP的四次握手关闭
可以看出来，为了执行一条SQL，需要进行大量的初始化与关闭操作
使用数据库连接池
如果使用数据库连接池，那么会 事先申请（初始化）好 相关的数据库连接，然后在之后的SQL操作中会复用这些数据库连接，操作结束之后数据库也不会断开连接，而是将数据库对象放回到数据库连接池中
资源重用：由于数据库连接得到重用，避免了频繁的创建、释放连接引起的性能开销，在减少系统消耗的基础上，另一方面也增进了系统运行环境的平稳性（减少内存碎片以及数据库临时进程/线程的数量）。
更快的系统响应速度：数据库连接池在初始化过程中，往往已经创建了若干数据库连接置于池中备用。 此时连接的初始化工作均已完成。对于业务请求处理而言，直接利用现有可用连接，避免了从数据库连接初始化和释放过程的开销，从而缩减了系统整体响应时间。
统一的连接管理，避免数据库连接泄露：在较为完备的数据库连接池实现中，可根据预先的连接占用超时设定，强制收回被占用连接。从而避免了常规数据库连接操作中可能出现的资源泄露。
如果说你的服务器CPU是4核i7的，连接池大小应该为((4*2)+1)=9
相关视频推荐
90分钟搞懂数据库连接池技术|linux后台开发
《tcp/ip详解卷一》： 150行代码拉开协议栈实现的篇章
学习地址：C/C++Linux服务器开发/后台架构师【零声教育】-学习视频教程-腾讯课堂
需要C/C++ Linux服务器架构师学习资料加qun 812855908 获取（资料包括 C/C++，Linux，golang技术，Nginx，ZeroMQ，MySQL，Redis，fastdfs，MongoDB，ZK，流媒体，CDN，P2P，K8S，Docker，TCP/IP，协程，DPDK，ffmpeg 等），免费分享
源码下载
下载方式：（Github中下载）
db_pool目录下有两个目录，mysql_pool目录为MySQL连接池代码，redis_pool为redis连接池代码
下面介绍mysql_pool
CDBConn解析
概念： 代表一个数据连接对象实例
相关成员：
m_pDBPool：该数据库连接对象所属的数据库连接池
构造函数： 绑定自己所属于哪个数据库连接池
Init()函数： 创建数据库连接句柄
CDBPool解析
概念：代表一个数据库连接池
相关成员：
Init()函数：常见指定数量的数据库实例句柄，然后添加到m_free_list中，供后面使用
GetDBConn()函数： 用于从空闲队列中返回可以使用的数据库连接句柄
RelDBConn()函数： 程序使用完该数据库句柄之后，将句柄放回到空闲队列中
测试之前，将代码中的数据库地址、端口、账号密码等改为自己的（代码中有好几处）
进入MySQL， 创建mysql_pool_test数据库
进入到mysql_pool目录下， 创建一个build目录并进入 ：
然后输入如下的命令进行编译
之后就会在目录下生成如下的可执行文件
输入如下两条命令进行测试： 可以看到不使用数据库连接池，整个操作耗时4秒左右；使用连接池之后，整个操作耗时2秒左右，提升了一倍
源码下载
下面介绍redis_pool
测试
进入到redis_pool目录下， 创建一个build目录并进入 ：
然后输入如下的命令进行编译
之后就会在目录下生成如下的可执行文件
输入如下的命令进行测试： 可以看到不使用数据库连接池，整个操作耗时182ms；使用连接池之后，整个操作耗时21ms，提升了很多
进入redis，可以看到我们新建的key：
如何处理mysql数据库并发更新问题
现象
Sysbench对MySQL进行压测, 并发数过大(5k)时, Sysbench建立连接的步骤会超时.
猜想
猜想: 直觉上这很简单, Sysbench每建立一个连接, 都要消耗一个线程, 资源消耗过大导致超时.
验证: 修改Sysbench源码, 调大超时时间, 仍然会发生超时.
检查环境
猜想失败, 回到常规的环境检查:
MySQL error log 未见异常.
syslog 未见异常.
tcpdump 观察网络包未见异常, 连接能完成正常的三次握手; 只观察到在出问题的连接中, 有一部分的TCP握手的第一个SYN包发生了重传, 另一部分没有发生重传.
自己写一个简单的并发发生器, 替换sysbench, 可重现场景. 排除sysbench的影响
猜想2
怀疑 MySQL 在应用层因为某种原因, 没有发送握手包, 比如卡在某一个流程上:
检查MySQL堆栈未见异常, 仿佛MySQL在应用层没有看到新连接进入.
通过strace检查MySQL, 发现 accept() 调用确实没有感知到新连接.
怀疑是OS的原因, Google之, 得到参考文档: A TCP “stuck” connection mystery【】
分析
参考文档中的现象跟目前的状况很类似, 简述如下:
正常的TCP连接流程:
Client 向 Server 发起连接请求, 发送SYN.
Server 预留连接资源, 向 Client 回复SYN-ACK.
Client 向 Server 回复ACK.
Server 收到 ACK, 连接建立.
在业务层上, Client和Server间进行通讯.
当发生类似SYN-flood的现象时, TCP连接的流程会使用SYN-cookie, 变为:
Client 向 Server 发起连接请求, 发送SYN.
Server 不预留连接资源, 向 Client 回复SYN-ACK, 包中附带有签名A.
Client 向 Server 回复ACK, 附带 f(签名A) (对签名进行运算的结果).
Server 验证签名, 分配连接资源, 连接建立.
在业务层上, Client和Server间进行通讯.
当启用SYN-cookie时, 第3步的ACK包因为 某种原因 丢失, 那么:
从Client的视角, 连接已经建立.
从Server的视角, 连接并不存在, 既没有建立, 也没有”即将建立” (若不启用SYN-cookie, Server会知道某个连接”即将建立”)
发生这种情况时:
若业务层的第一个包应是从 Client 发往 Server, 则会进行重发或抛出连接错误
若业务层的第一个包应是从 Server 发往 Client的, Server不会发出第一个包. MySQL的故障就属于这种情况.
TCP握手的第三步ACK包为什么丢失
参考文档中, 对于TCP握手的第三步ACK包的丢失原因, 描述为:
Some of these packets get lost because some buffer somewhere overflows.
我们可以通过Systemtap进一步探究原因. 通过一个简单的脚本:
probe kernel.function("cookie_v4_check").return
{
source_port = @cast($skb-head + $skb-transport_header, "struct tcphdr")-source
printf("source=%d, return=%d\n",readable_port(source_port), $return)
}
function readable_port(port) {
return (port ((19)-1)) 8 | (port 8)
}
观察结果, 可以确认cookie_v4_check (syn cookie机制进行包签名检查的函数)会返回 NULL(0). 即验证是由于syn cookie验证不通过, 导致TCP握手的第三步ACK包不被接受.
之后就是对其中不同条件进行观察, 看看是哪个条件不通过. 最终原因是accept队列满(sk_acceptq_is_full):
static inline bool sk_acceptq_is_full(const struct sock *sk){ return sk-sk_ack_backlog sk- sk_max_ack_backlog;}
恢复故障与日志的正关联
在故障处理的一开始, 我们就检查了syslog, 结论是未见异常.
当整个故障分析完成, 得知了故障与syn cookie有关, 回头看syslog, 里面是有相关的信息, 只是和故障发生的时间不匹配, 没有正关联, 因此被忽略.
检查Linux源码:
if (!queue-synflood_warned
sysctl_tcp_syncookies != 2
xchg(queue-synflood_warned, 1) == 0)
pr_info("%s: Possible SYN flooding on port %d. %s.
Check SNMP counters.\n",
proto, ntohs(tcp_hdr(skb)-dest), msg);
可以看到日志受到了抑制, 因此日志与故障的正关联被破坏.
粗看源码, 每个listen socket只会发送一次告警日志, 要获得日志与故障的正关联, 必须每次测试重启MySQL.
解决方案
这种故障一旦形成, 难以检测; 系统日志中只会出现一次, 在下次重启MySQL之前就不会再出现了; Client如果没有合适的超时机制, 万劫不复.
解决方案:
1. 修改MySQL的协议, 让Client先发握手包. 显然不现实.
2. 关闭syn_cookie. 有安全的人又要跳出来了.
3. 或者调高syn_cookie的触发条件 (syn backlog长度). 降低系统对syn flood的敏感度, 使之可以容忍业务的syn波动.
有多个系统参数混合影响syn backlog长度, 参看【】
下图为精华总结
请点击输入图片描述
