MySQL主从复制，读写分离是互联网常见的数据库架构，该架构最令人诟病的地方就是，在数据量较大并发量较大的场景下，主从延时会比较严重。
一、缘起 mysql主从复制，读写分离是互联网用的非常多的mysql架构，主从复制最令人诟病的地方就是，在数据量较大并发量较大的场景下，主从延时会比较严重。 为什么mysql主从延时这么大？ 回答：
写这篇文章是因为之前有一次删库操作，需要进行批量删除数据，当时没有控制好删除速度，导致产生了主从延迟，出现了一点小事故。
🍁 作者：知识浅谈，CSDN签约讲师，CSDN原力作者，后端领域优质创作者，热爱分享创作 💒 公众号：知识浅谈 📌 擅长领域：后端全栈工程师、爬虫、ACM算法 🔥 联系方式vx：zsqtcc 这次探索的问题： 什么是 Mysql主从同步？ Mysql主从同步为什么会有主从延迟？ 主从同步延迟解决方案？ 🤞这次都给他拿下🤞 为什么 主从同步 会暴露出问题呢？ 主从同步虽然满足了性能上要求，但一致性可能会有问题。 正菜来了🛴🛴🛴 🍖Mysql主从同步是？ 因为数据访问量的大量增长，单体数据库主键有
不久前用户反馈部门的 MySQL 数据库发生了数据更新丢失。为了解决这个问题，当时对用户使用的场景进行了分析。发现可能是因为用户在两台互为主从的机器上都进行了写入导致的数据丢失。
MySQL的复制架构允许获取事件的I/O线程和重放事件的SQL线程异步进行。但是在主库上并发执行的查询在从库中只能串行化执行，因为只有一个SQL线程来重放中继日志事件。
内容为慕课网的《高并发 高性能 高可用 Mysql 实战》视频的学习笔记内容和个人整理扩展之后的笔记，这一节讲述搭建Mysql三高架构中的复制，Mysql的复制在实战中实现比较简单，但是Mysql针对复制的内部优化却是一直在进行，这样说明这是值得重视和学习的内容，所以本节针对复制这一特征介绍相关的理论内容。
本文介绍了MySQL中的binlog组提交及其在MySQL Replication中的作用。binlog是MySQL中一种二进制日志，用于记录数据库的更改历史。在MySQL Replication中，通过binlog实现主从复制。当主库发生更改时，binlog会记录所有更改，并将更改发送到从库。从库根据binlog中的更改来更新自己的数据，从而保持与主库一致。在MySQL中，使用binlog可以实现多种功能，如灾难恢复、数据迁移、只读实例等。
听到原子这个关键字大家是不是联想到事务的ACID的原子性？两者相似，事务/语句执行要么全部成功，要么全部失败。MySQL 8.0 之前的版本 DDL 是非原子性的，对于多条sql构成的ddl语句比如 rename table t1 to t1_bak,t2 to t2_bak; 执行过程中如果遇到系统异常crash，有可能出现表t1被rename，但是t2没有被rename的情况。出现该情况的原因就是MySQL不支持原子的DDL。
首先主从复制是什么？简单来说是让一台MySQL服务器去复制另一台MySQL的数据，使两个服务器的数据保持一致。
MySQL 主从复制（Master-Slave Replication）是一种常见的数据库复制技术，它在数据库管理中发挥着重要的作用，有以下几个主要用途：
前段时间遇到一个线上问题，后来排查好久发现是因为主从同步延迟导致的，所以今天写一篇文章总结一下这个问题希望对你有用。如果觉得还不错,记得加个关注点个赞哦
1. 简介 MySQL 5.6引入了基于schema的并行复制，即如果binlog events操作的是不同schema的对象，不是DDL，且操作的对象没有对其他schema的foreign key关联，则这些binlog events在slave上做重放的时候可以并行。slave上依然还是有一条IO线程负责从master拉取binlog并写入relay log，之前负责重放relay log的SQL线程现在作为coordinator线程，根据读取到的relay log里的binlog event，决定是
吴夏，腾讯云TDSQL研发工程师，目前主要负责日志解析复制、数据传输同步模块的开发工作。
我们知道，InnoDB Cluster 是 Oralce 官方发布的用来管理 MySQL 组复制的一套工具，有了 InnoDB Cluster，MySQL 原生组复制的部署、运维、开发等将会变得非常简单。
某用户A反馈CDB实例读业务数据库没有响应，在控制台界面看到ro节点被剔除，剔除之前数据库监控上面cpu负载正常，活跃线程数出现大量的堆积；提单后，平台紧急介入，观察到ro节点出现大量的waiting for table metadata lock的报错。
在查询计数已成为问题的情况下，它们在另一个表中构建了计数，以便它们可以直接读取计数值而非计算计数。
InnoDB是MySQL的默认存储引擎,它使用多版本并发控制(MVCC)和锁机制来实现事务。
MySQL 内置的复制功能是构建基于 MySQL 的大规模、高性能应用的基础，复制解决的基本问题是让一台服务器的数据与其他服务器保持同步。
MySQL 主从复制的问题及解决方案
在上一期《时区信息记录表|全方位认识 mysql 系统库》中，我们详细介绍了mysql系统库中的时区信息记录表，本期我们将为大家带来系列第七篇《复制信息记录表|全方位认识 mysql 系统库》，下面请跟随我们一起开始 mysql 系统库的系统学习之旅吧！
之所以有这样一篇文章，是因为在前几天的一个晚上，要下班的时候，业务方忽然有一个需求，是需要恢复一个表里面的数据，当时问了下情况，大概是这样的：业务方不小心在一个表里面做了一个update的操作，可能是where条件没有写对，导致表里面的数据被写坏了，但是数据目前还没有落盘，只是在内存中的值修改了，现在要求恢复到之前的数据。万幸，这份数据是平台上某些商品的价格，基本上是有限个商品，然后价格值也都是固定的，之前有对这个价格表进行备份，于是给他直接重新导入了一份价格表的数据，这个问题也算是解决了。
日常工作中，我们经常会和主从复制架构打交道，现在一般的公司线上很少出现单点实例的裸奔情况，因为单点实例极易出现故障，而在实例运行的过程中，我们很难做到一直对实例进行备份。主从复制完美的解决了上面这个问题，而在主从复制的过程中，最常见的事情就是需要统计从库落后主库的时间，一般情况下，我们是需要主从的落后时间越小越好，因为小的数字意味着从库的数据和主库的数据基本保持一致。当然，在某些情况下，我们也会人为的设置这个延迟时间，举例子就是在一些高危操作之前，我们害怕出现一些误操作，这个时候我们往往设置主从的延迟时间，这样即使主库上进行了误操作，例如删除了表，由于主从库之间延迟时间的存在，我们的从库可以避免这个问题，从而保障数据的安全性。
Redo Log 是 MySQL InnoDB 存储引擎中的一种重要的日志工具。它主要用于记录数据库中所有的修改操作，包括但不限于插入、删除和更新等操作，以便在系统崩溃等异常情况下进行数据恢复。
其实很简单，就是基于主从复制架构，简单来说，就搞一个主库，挂多个从库，然后我们就单单只是写主库，然后主库会自动把数据给同步到从库上去。
日志文件中记录的到底是什么呢？mysql支持了两种日志格式，这两种日志格式也体现了各自的复制方式
由于我这里使用docker搭建，所以需要把配置文件和数据文件映射到宿主机，让容器运行时挂载数据
说起在线 DDL，最常见的操作莫过于在线加一个字段或者索引，不过如果数据量比较大的话，伴随而来的往往是长时间的等待，更要命的是系统在操作期间很可能会出现不可用的情况，所以一般只能等到凌晨操作，简直就是梦魇一般的存在。
今天在测试线上的一个基于binlog的恢复的功能的时候，发现了一个报错信息，差了半天，最后定位到问题所在，分析过程贴在这里，供大家参考。
Binlog 日志，全称为 Binary Log，是 MySQL 在 Server 层产生的一种日志。这种日志包含了对数据库执行变更的所有操作（例如 SQL 语句的执行）或者对于数据库的数据变更情况，记录了实例的所有 DML 和 DDL 操作。
第10章 复制 复制是通过在主库记录二进制日志，然后再在备库重放日志的方式来实现异步的数据复制。 复制通常不会对主库产生开销，主要是启用二进制日志带来的开销。除此之外每个备库也会对主库增加一些负载，例如网络io开销 复制如何工作： 在主库上把数据更改记录到二进制日志中。 备库将主库的日志复制到自己的中继日志中。 备库读取中继日志中的事件，将其重放到备库数据之上。 二进制日志是由服务器层面去实现的，事务日志是存储引擎层面的。先记录了二进制日志之后，MySQL才会去提交相关事务。 创建复制账号的时候虽然可以只设
mysql主从架构部署比较简单，常见架构根据主从节点个数不同分成 一主多从，多主一从，双主节点等。
由于HTTP是一种无状态协议，它将每个请求视为惟一的，与上一个和下一个请求无关，这就是为什么应用程序需要实现会话cookie等机制来管理会话中单个用户执行的操作。作为克服这一限制的替代方案，HTML5合并了WebSockets。WebSockets通过HTTP协议在客户端和服务器之间提供了一个持久的、双向的通信通道。
可以在任意个主从库之间建立复杂的复制拓扑结构，如普通的一主一（多）从、双（多）主复制、级联复制，MySQL 5.7.2后新增的多源复制，特殊场景下使用的Blackhole引擎与日志服务器等等。复制中的MySQL服务器须要遵循以下基本原则：
redo log包括两部分内容，分别是内存中的日志缓冲(redo log buffer)和磁盘上的日志文件(redo log file)。
主库记录二进制日志。在每次准备提交事务完成数据更新前，主库将数据更新的事件记录到二进制日志中。MySQL会按事务提交的顺序而非每条语句的执行顺序来记录二进制日志。在记录二进制日志后，主库会告诉存储引擎可以提交事务了。下一步，备库将主库的二进制日志复制到其本地的中继日志中。首先，备库会启动一个工作线程，称为I/O线程，I/O线程跟主库建立一个普通的客户端连接，然后在主库启动一个特殊的二进制转储线程，这个二进制转储线程会读取主库上二进制日志中的事件。他不会对事件进行轮询。如果该线程追赶上了主库，他将进入睡眠状态，直到主库发送信号量通知其有新的事件产生时才会被唤醒，备库I/O线程会将接收到的事件记录到中继日志中。
这是很早时候写的一篇文章，今天翻看历史文章的时候发现的，觉得还是有收获，就分享出来了。以下是文章原文：
接上一篇文章使用Xtrabackup备份MySQL数据库，下面介绍使用Xtrabackup实现MySQL数据库的增量备份
渗透测试面试题目 一、基础问题 1.请你用一分钟时间介绍下你自己 2.现在在哪个城市 3.最快什么时候可以到岗 4.项目经历 5.对面试的岗位职责和工作内容了解吗 二、技术问题 1.拿到一个待检测的站，你觉得应该先做什么 1)信息收集 1，获取域名的whois信息,获取注册者邮箱姓名电话等。 2，查询服务器旁站以及子域名站点，因为主站一般比较难，所以先看看旁站有没有通用性的cms或者其他漏洞。 3，查看服务器操作系统版本，web中间件，看看是否存在已知的漏洞，比如IIS，APACHE,NGINX的解析漏洞4
thr0cyte，Gr33k，花花，MrTools，R1ght0us，7089bAt
大数据平台的采集功能是从外部数据源采集数据存储到hive，采集方式分为全量采集、增量采集，增量采集适用于数据规模较大情况，有很多使用场景，但是在增量采集时，平台只能感知数据新增、更新，无法感知到数据删除，为了解决这个问题，本文选用了常用的外部数据源mysql为例进行binlog采集方案介绍。
binlog是mysql的一种二进制日志文件，用来记录数据的变化。mysql使用binlog进行主从复制，如图：
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
实时音视频
对象存储
即时通信 IM
