MySQL是当今最流行的开源数据库，阅读其源码是一件大有裨益的事情(虽然其代码感觉比较凌乱)。而笔者阅读一个Server源码的习惯就是先从其网络IO模型看起。于是，便有了本篇博客。
MySQL的服务实现通过后台多个线程、内存池、文件交互来实现对外服务的，不同线程实现不同的资源操作，各个线程相互协助，共同来完成数据库的服务。MySQL常用的后台线程概括如下，分为Master Thread，IO Thread，Purge Thread，Page Cleaner Thread
Mysql的复制是一个异步复制的过程，从一个主（master）的复制到另一个备（salve）的。在主备之间实现复制过程主要有三个线程来完成，其中两个线程（sql线程和IO线程）在备端，另一个线程（IO线程）在主端。
今天主要聊一下MySQL的异步复制、全同步复制与半同步复制，目前我们生产库实际上用的就是异步复制了，后面再转成半同步复制。
随着访问量的不断增加，单台MySQL数据库服务器压力不断增加，需要对MYSQL进行优化和架构改造，MYQSL优化如果不能明显改善压力情况，可以使用高可用、主从复制、读写分离来、拆分库、拆分表来进行优化。
CentOs7.3 搭建 MySQL 5.7.19 主从复制，以及复制实现细节分析 概念 主从复制可以使MySQL数据库主服务器的主数据库，复制到一个或多个MySQL从服务器从数据库，默认情况下，复制异步; 根据配置，可以复制数据库中的所有数据库，选定的数据库或甚至选定的表。 MySQL中主从复制的优点 横向扩展解决方案 在多个从库之间扩展负载以提高性能。在这种环境中，所有写入和更新在主库上进行。但是，读取可能发生在一个或多个从库上。该模型可以提高写入的性能（由于主库专用于更新），同时在多个从库上读取，可以
搭建MySQL主从后，很多时候不知道从的状态是否ok，有时候出现异常不能及时知道，这里通过shell脚本结合zabbix实现监控并告警
1.从库的IO线程向主库的主进程发送请求，主库验证从库，交给主库IO线程负责数据传输; 2.主库IO线程对比从库发送过来的master.info里的信息，将binlog文件信息，偏移量和binlog文件名等发送给从库 3.从库接收到信息后，将binlog信息保存到relay-bin中，同时更新master.info的偏移量和binlog文件名 4.从库的SQL线程不断的读取relay-bin的信息，同时将读到的偏移量和文件名写道relay-log.info文件，binlog信息写进自己的数据库，一次同步操作完成。 5.完成上次同步后，从库IO线程不断的向主库IO线程要binlog信息 6.从库如果也要做主库，也要打开log_bin 和log-slave-update参数
当master服务器上的数据发生改变时(增、删、改)，则将其改变写入二进制binlog日志中；slave服务器会在一定时间间隔内对master二进制日志进行探测其是否发生改变，如果发生改变，则开启一个I/O 线程请求master二进制事件，同时主节点为每个I/O线程启动一个dump线程，用于向其发送二进制事件，并保存至从库本地的中继日志中，从库(从节点)将启动SQL线程从中继日志中读取二进制日志，在本地重放，使得其数据和主节点的保持一致，最后IO线程和SQL线程将进入睡眠状态，等待下一次被唤醒。
锁定所有表（防止数据库状态值变化，锁定后，这时候只能读，不能写，写请求会在解锁后执行）
复制状态信息查看可以通过一些语句如（show slave status）和相关的系统表来进行查看，它们之前有对应的关系
在Innodb存储引擎中，后台线程的主要作用是负责刷新内存池中的数据，保证缓冲池中的内存缓存的是最近的数据。此外它会将已经修改的数据文件刷新到磁盘文件中，保证数据库在发生异常的情况下，Innodb能够恢复到正常的运行状态。上一节中我们讲到了redo log的刷盘操作，其实就是后台线程帮忙完成的。
2用户名密码验证(通过授权表做的验证数据库一启动,会把授权表加载到内存中 mysql.user mysql.db mysql.table_priv mysql.column_priv)
之前部署了mysql主从同步环境（Mysql主从同步(1)-主从/主主环境部署梳理），针对主从同步过程中slave延迟状态的监控梳理如下： 在mysql日常维护工作中，对于主从复制的监控主要体现在： 1）检查数据是否一致；主从数据不同步时，参考下面两篇文档记录进行数据修复： mysql主从同步(3)-percona-toolkit工具（数据一致性监测、延迟监控）使用梳理 利用mk-table-checksum监测Mysql主从数据一致性操作记录 2）监控主从同步延迟，同步延迟的检查工作主要从下面两方面着手：
某业务CDB实例，每天在特地时间段内（ 00:07:00 - 00:08:00左右）机器对应IO监控出现写入尖刺，且主从实例都有类似现象，从机器监控可以看到，问题确实存在。
这篇文章是讲述 InnoDB 刷盘策略系列文章的第三篇。本文主要讲述 性能调优。另外2篇文章参考
云原生技术使组织能够在公共、私有和混合云等现代动态环境中构建和运行可扩展的应用程序。容器、服务网格、微服务、不可变基础设施和声明式 API 就是这种方法的例证。
前面学完了JDBC，接下来带大家感受一下MySQL集群！其实什么是MySQL集群？简单的说就是一群机器（服务器）的集合，它们连在一起来工作。 其实各种数据库都有自己的集群，常常的多： 我们要学习的
Mysql复制概念说明 Mysql内建的复制功能是构建大型，高性能应用程序的基础。将Mysql的数据分布到多个系统上去，这种分布的机制，是通过将Mysql的某一台主机的数据复制到其它主机（slaves）上，并重新执行一遍来实现的。复制过程中一个服务器充当主服务器，而一个或多个其它服务器充当从服务器。主服务器将更新写入二进制日志文件，并维护文件的一个索引以跟踪日志循环。这些日志可以记录发送到从服务器的更新。当一个从服务器连接主服务器时，它通知主服务器从服务器在日志中读取的最后一次成功更新的位置。从服务器接收从
很多时候，程序员对mysql处于频繁使用，但都一知半解的程度，除了会加个索引，貌似也没啥优化的技能了。事实上，mysql能有今日的成就，必然不是靠个索引就吃饭的。更何况很多情况下，索引什么的应用层面也解决不了实际问题。那么，我们就需要深入到mysql内部去一探究竟。
系统层是相应的数据字典，数据文件和日志文件,其中binlog是MySQL Server层的，放在这里是因为和InnoDB有密切的关系。
一、master记录二进制日志。在每个事务更新数据完成之前，master在二进制日志记录这些改变。MySQL将事务写入二进制日志，即使事务中的语句都是交叉执行的。在事件写入二进制日志完成后，master通知存储引擎提交事务。 二、slave将master的binary log拷贝到它自己的中继日志。首先，slave开始一个工作线程——I/O线程。I/O线程在master上打开一个普通的连接，然后开始binlog dump process。Binlog dump process从master的二进制日志中读取事件，如果已经执行完master产生的所有文件，它会睡眠并等待master产生新的事件。I/O线程将这些事件写入中继日志。 三、SQL slave thread（SQL从线程）处理该过程的最后一步。SQL线程从中继日志读取事件，并重新执行其中的事件而更新slave的数据，使其与master中的数据一致。
MySQL 主从复制（replication）是一个异步的复制过程。从一个实例（Master）复制到另一个实例（Slave），整个过程需要由 Master 上的 IO 进程 和 Slave 上的 Sql 进程 与 IO 进程 共同完成。 首先 Master 端必须打开 binary log（bin-log），因为整个复制过程实际上就是 Slave 端从 Master 端获取相应的二进制日志，然后在本地完全顺序的执行日志中所记录的各种操作。 原理图如下：
MySQL的 Replication 是一个异步的复制过程（mysql5.1.7以上版本分为异步复制和半同步两种模式），从一个 Mysql instace(我们称之为 Master)复制到另一个 Mysql instance(我们称之 Slave)。在 Master 与 Slave 之间的实现整个复制过程主要由三个线程来完成，其中两个线程(Sql线程和IO线程)在 Slave 端，另外一个线程(IO线程)在 Master 端。
◆ 一、概述 mysql主从是常用的高可用架构之一，也是使用最广泛的的系统架构。在生产环境中mysql主从复制有时会出现复制错误问题。MySQL主从复制中的问题（Coordinator stopped beacause there were errors in the workers......） ◆ 二、mysql主从复制原理 mysql主从复制是一个异步复制过程（总体感觉是实时同步的）,mysql主从复制整个过程是由三个线程完成。slave端有两个线程（SQL线程和IO线程），Master端有另一个（I
初次接触二阶段提交，源于想以事务的方式实现对 MongoDB 中多个集合数据的修改，而 MongoDB 本身不支持事务，官方推荐的方案就是使用二阶段提交。
先来说说这俩语法的概念，第一种kill query pid指的是断开当前线程中正在执行的语句，而不断开线程连接。第二种kill pid的方法指的是断开该线程的连接，如果线程中有正在执行的语句，那么也会停止这个语句。
提示：公众号展示代码会自动折行，建议横屏阅读 一、问题描述 某业务CDB实例，每天在特地时间段内（ 00:07:00 - 00:08:00左右）机器对应IO监控出现写入尖刺，且主从实例都有类似现象，从机器监控可以看到，问题确实存在。 不仅master，进行同步的slave上有相同的现象，业务方希望找到导致该IO尖刺问题稳定出现的原因。 二、问题分析 首先确定问题来源，上图所示监控为机器级别，机器IO写入负载是否来源于mysqld进程？如果来源于mysqld进程，是来自于mysqld进程的哪一部分
DML(data manipulation language)：数据操纵语句，用于添加、删除、更新和查询数据库记录，并检查数据完整性，常用的语句有select、update、insert、delete
今天回家重新看了看《高性能MySQL》这本书里面复制一节，每次看都有不同的收获，这里把我自己觉得比较重要的一些点罗列出来，大家可以温故知新一下：
2、show slave status查看seconds_behind_master值反复在0、500、0、500、0、500之间跳动。
在MySQL复制环境中，我们通常只根据 Seconds_Behind_Master 的值来判断SLAVE的延迟。这么做大部分情况下尚可接受，但并不够准确，而应该考虑更多因素。
这种主从复制环境在单机应用的时候没有问题，但是在实际的生产环境中，会存在复制延迟的问题。
管理mysql主从有2年多了，管理过200多组mysql主从，几乎涉及到各个版本的主从，本博文属于总结性的，有一部分是摘自网络，大部分是根据自己管理的心得和经验所写，整理了一下，分享给各位同行，希望对大家有帮助，互相交流。
中间件dble测试成员，主要负责dble的日常测试工作，热衷于探索发现，学习新技术。
本文介绍了MySQL数据库在国产化ARM环境中出现的第一个大坑——从库复制延迟。作者首先分析了导致这一现象的原因，包括主库的binlog dump线程、从库的IO线程、从库的SQL线程及协调线程等各个方面的因素。然后，作者进行了详细的调试和分析，发现了社区版MySQL在ARM架构下存在的获取CPU缓存行大小函数兼容性BUG。最后，作者提出了解决方案并在国产ARM架构中使用TXSQL避免了这个问题。
对于计算机学科来说，计算机网络相关知识的重要性不言而喻。平时我们框架用的多了，对于底层网络 IO 的处理关注的并不算多（如果不让你用 Spring，你还能写出个 Web 接口吗？），但对于中间件以及框架的开发者来说，网络 IO 的处理却是最需要关注的地方。
Mysql为了解决这个风险并提高复制的性能，将Slave端的复制改为两个进程来完成。提出这个改进方案的人是Yahoo!的一位工程师“Jeremy Zawodny”。这样既解决了性能问题，又缩短了异步的延时时间，同时也减少了可能存在的数据丢失量。当然，即使是换成了现在这样两个线程处理以后，同样也还是存在slave数据延时以及数据丢失的可能性的，毕竟这个复制是异步的。只要数据的更改不是在一个事物中，这些问题都是会存在的。如果要完全避免这些问题，就只能用mysql的cluster来解决了。不过mysql的cluster是内存数据库的解决方案，需要将所有数据都load到内存中，这样就对内存的要求就非常大了，对于一般的应用来说可实施性不是太大。
Q：为啥要引入主从同步机制？ A：防止业务数据库突然宕掉，不能快速的恢复业务正常运行，有利于数据库架构的健壮性，提升访问速度，方便运维保证的数据物理安全(容灾备份)；
本文介绍了如何利用 MySQL 5.7 的行锁信息表特性，通过解析 binlog，实时监控行锁状态，从而实现对 MySQL 5.7 的行锁的全局统计和优化。
Mysql作为数据库在不同的机器和不同的业务环境中具有不同的调优方式，和我们做任何事情一样，涉及到边界确定的就是我们需要关注的。所有了解mysql实现的边界参数是我们调优的重点。
以下的内容，希望你的环节是在8.011 以上的环境中操作，部分需要在8.018 以上环境操作
在 第25 和 第27 篇文章中，和你介绍了主备切换流程。通过这些内容的讲解，你应该已经很清楚了：在一主一备的双 M 架构里，主备切换只需要把客户端流量切到备库；而在一主多从架构里，主备切换除了要把客户端流量切到备库外，还需要把从库接到新主库上。
我们知道，mysql数据库，为了得到更高性能，一般会读写分离，主库用于写操作，比如用于执行insert，update操作，从库用于读，也就是最常见的select操作。像下面这个图这样。
3月16日在北京举行的腾讯云自研数据库CynosDB交流会圆满落下帷幕。现将技术团队分享的内容整理如下。
到这里本系列已经接近尾声了，是时候对常见引起主从延迟的情形进行一个总结了。我想如果我一开始就把这些情形拿出来也许大家对具体的原因不是那么清楚，但是经过本系列的学习，我相信当我说起这些情形的时候大家都很清楚它的原因了。当然如果还有其他造成延迟的情形也欢迎大家一起讨论。
之前部署了Mysql主从复制环境（Mysql主从同步(1)-主从/主主环境部署梳理），在mysql同步过程中会出现很多问题，导致数据同步异常。 以下梳理了几种主从同步中可能存在的问题: 1）slave运行过慢不能与master同步，也就是MySQL数据库主从同步延迟 MySQL数据库slave服务器延迟的现象是非常普遍的，MySQL复制允许从机进行SELECT操作，但是在实际线上环境下，由于从机延迟的关系，很难将读取操作转向到从机。这就导致了有了以下一些潜规则：“实时性要求不高的读取操作可以放到slave服
MySQL主从复制涉及到三个线程，一个运行在主节点（log dump thread），其余两个(I/O thread, SQL thread)运行在从节点，如下图所示:
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
实时音视频
云直播
对象存储
