日志文件中记录的到底是什么呢？mysql支持了两种日志格式，这两种日志格式也体现了各自的复制方式
谁也不能保证计算机系统能够永远无故障的执行下去。网络波动、磁盘损坏等现网高频故障，机房掉电、服务器硬件失效等低频却又致命的故障，时刻考验着我们的系统。
刚看见这个题目的时候还是有点懵逼的，后来才反应过来其实问的就是 redo log 的两阶段提交
正所谓理论造航母，现实小帆船。单有理论，不动手实践，学到的知识犹如空中楼阁。接下来，我们一起来看下如何一步步进行 MySQL Replication 的配置。
MySQL 主从复制的问题及解决方案
在做最后一个MySQL NBU备份的时候，发现从库有问题，好奇的是怎么主从状态异常没有告警呢？先不管这么多了，处理了这个问题再完善告警内容。
我们在平时工作中，使用最多的数据库就是 MySQL 了，随着业务的增加，如果单单靠一台服务器的话，负载过重，就容易造成宕机。
Undo Log（回滚日志）是MySQL中的一种重要数据结构，用于实现事务的ACID特性中的"Atomicity"（原子性）和"Isolation"（隔离性）。
Mysql为了解决这个风险并提高复制的性能，将Slave端的复制改为两个进程来完成。提出这个改进方案的人是Yahoo!的一位工程师“Jeremy Zawodny”。这样既解决了性能问题，又缩短了异步的延时时间，同时也减少了可能存在的数据丢失量。当然，即使是换成了现在这样两个线程处理以后，同样也还是存在slave数据延时以及数据丢失的可能性的，毕竟这个复制是异步的。只要数据的更改不是在一个事物中，这些问题都是会存在的。如果要完全避免这些问题，就只能用mysql的cluster来解决了。不过mysql的cluster是内存数据库的解决方案，需要将所有数据都load到内存中，这样就对内存的要求就非常大了，对于一般的应用来说可实施性不是太大。
今天回家重新看了看《高性能MySQL》这本书里面复制一节，每次看都有不同的收获，这里把我自己觉得比较重要的一些点罗列出来，大家可以温故知新一下：
那么如果在两阶段提交的过程中，发生了数据库的崩溃，MySQL内部会做什么事情来保证数据的一致性呢？以上述的update操作为例：
今天来和大家分享MySQL的三个日志文件，可以说 MySQL 的多数特性都是围绕日志文件实现，而其中最重要的有以下三种：
异步复制：主库将事件写入二进制日志，但不知道从库是否接收成功，也不知道从库什么时候重放二进制日志，如果主库崩溃，则在主库提交的事务可能还没有传输到从库，这种情况下如果主从故障切换，从库还没有传输到从库的事务将丢失
一旦使用 MySQL 的复制功能，就很大可能会碰到主备切换的情况。也许是为了迭代升级服务器，或者是主库出现问题时，将一台备库转换成主库，或者只是希望重新分配容量。不过出于什么原因，都需要将新主库的信息告诉其它备库。
主备复制过程中有很大可能会出现各种问题，接下来我们就讨论一些比较普遍的问题，以及当遇到这些问题时，如何解决或者预防问题发生。
之前几周有幸被京东智联云的市场同事推荐参与麦思博的一个视频课程的录制，题目是与MongoDB相关的内容。在ppt里也写到了推荐学员可以对比参照其他数据的原理和特点，来学习和理解MongoDB的一些原理和特点，而自己最近在学习的时候，正好发现了一处MongoDB与MySQL设计非常相似的地方，即今天要介绍的写确认相关的内容。
简单说，复制就是将来自一个MySQL数据库服务器（主库）的数据复制到一个或多个MySQL数据库服务器（从库）。传统的MySQL复制提供了一种简单的Primary-Secondary复制方法，默认情况下，复制是单向异步的。MySQL支持两种复制方式：基于行的复制和基于语句的复制。这两种方式都是通过在主库上记录二进制日志（binlog）、在从库重放中继日志（relylog）的方式来实现异步的数据复制。二进制日志或中继日志中的记录被称为事件。所谓异步包含两层含义，一是主库的二进制日志写入与将其发送到从库是异步进行的，二是从库获取与重放日志事件是异步进行的。这意味着，在同一时间点从库上的数据更新可能落后于主库，并且无法保证主从之间的延迟间隔。
MYSQL 的 GROUP REPLICATION 估计大多数的公司都没有用，即使用也不是在主要的项目和关键的地方。所以网上相关MYSQL Group Replicaiton 的的修复的东西也不多。赶巧，最近我们的测试系统的 MGR 崩溃了。
要实施复制，首先必须打开 master 端的 binlog 功能，否则无法实现。因为整个复制过程实际上就是 slave 从 master 获取该 binlog 然后再在自己身上完全顺序的执行 binlog 中所记录的各种更新操作。
随着网站访问和请求量的增加，单台数据库服务器的连接已耗尽，会出现连接请求还在等待，或是数据库服务器崩溃等现象，这时候我们考虑如何减少数据库的连接，可以通过优化代码、使用缓存、数据库读写分离等方式解决此问题。 什么是读写分离：将数据库的读、写操作分别作用到不同的数据库（不同物理机）上。 适用场景：读操作远大于写操作，包含大量复杂统计、离线计算等任务（比如定时按各维度对数据进行统计分析，或者结算佣金等） 研究了一阵，在配置的过程中出现各种问题。。今天刚配置好 windows系统环境：本机+VM虚拟机：MySql5.6，先安装好MySql 找到MySql5.6的 my.ini配置文件，在 C:\ProgramData\MySQL\MySQL Server 5.6目录中，ProgramData文件夹默认是隐藏的 Mysql主从同步的现实： 1、Master库将变更记录到binlog中 2、Slave将master的binlog拷贝到它的relay log(中继日志)中 3、slave重做中继日志中的事件 可以通过中间价实现读写分离，如Ameba，Corba，mysql-Proxy(官方)
https://segmentfault.com/a/1190000041758784
我的网站上一直有好多人留言催更 MySQL 日志（undo log、redo log、binlog）的文章。
MySQL5.7 默认参数下我们开启了半同步，在一个事务提交（commit） 的过程时，在 MySQL 层的 write binlog 步骤后，Master 节点需要收到至少一个 Slave 节点回复的 ACK （表示收到了binlog ）后，才能继续下一个事务；
相信很多人都已经发现了，数据上云进程越来越快了，很多企业都在加快把云下数据库搬到云上的速度，同时企业对于云上数据库的要求也变得越来越高，毕竟数据的完整可靠承载着一家企业业务持续发展的使命，这种重要性不用多说大家也都明白。那么云数据库怎么实现事务零丢失的呢？云数据库具备了哪些优点呢？接下来一起来了解一下。
MySQL的复制默认是异步的，主从复制至少需要两个MYSQL服务，这些MySQL服务可以分布在不同的服务器上，也可以在同一台服务器上。
今天在工作中遇到了一个问题，就是某个服务器的从库由于磁盘问题，产生了延迟，而监控和报警没有发觉，没有报警提示，当我清理磁盘之后，发现一个问题，从库已经无法落后主库24个小时了，好的一点是主库的binlog文件都还在，但是从库应用relay-log的速度小于relay-log的生成速度，所以导致这个从库的SBM(second behind master)一直缓慢上升，想了半天没有好的办法，最终通过设置innodb_flush_log_at_trx_commit=0的方法暂时得到缓解。关于mysql中的这个参数，之前简单做过一些了解，今天看了下官方的手册，大概翻译如下：
同时处于执行状态的所有事务，是否可以并行？ 不可以。因为多个执行中的事务是由可能出现锁冲突的，锁冲突之后会产生锁等待问题。
Java面试通关手册（Java学习指南，欢迎Star，会一直完善下去，欢迎建议和指导）：https://github.com/Snailclimb/Java_Guide
docker安装步骤 https://docs.docker.com/install/linux/docker-ce/centos/#install-docker-ce-1
本文翻译自国外论坛 medium，原文地址：https://medium.com/@interviewready/data-replication-in-distributed-system-87f7d265ff28
他们有一个共同的字段, 叫做xid, 崩溃恢复的时候, 会按照顺序扫描redolog:
MHA（Master High Availability）目前在MySQL高可用方面是一个相对成熟的解决方案，它由日本DeNA公司youshimaton（现就职于Facebook公司）开发，是一套优秀的作为MySQL高可用性环境下故障切换和主从提升的高可用软件。在MySQL故障切换过程中，MHA能做到在0~30秒之内自动完成数据库的故障切换操作，并且在进行故障切换的过程中， MHA能在最大程度上保证数据的一致性，以达到真正意义上的高可用。
根据上图可以看到QPS：10.73k,实际上真实的并发大量数据到达的时候，我这里最高的QPS是将近15k.而目前单个数据库分片(实例)4CPU8G内存的配置下，最高的性能是7k的QPS。
可以在任意个主从库之间建立复杂的复制拓扑结构，如普通的一主一（多）从、双（多）主复制、级联复制，MySQL 5.7.2后新增的多源复制，特殊场景下使用的Blackhole引擎与日志服务器等等。复制中的MySQL服务器须要遵循以下基本原则：
二进制日志文件并不是每次写的时候都会同步到磁盘，当发生宕机的时候，可能会有最后一部分数据没有写入到binlog中，这给恢复和复制带来了问题。当sync_binlog=1表示每写缓冲一次就同步到磁盘，表示同步写磁盘的方式来写binlog。也就是说每当向MySQL提交一次事务，MySQL将进行一次fsync之类的磁盘同步命令来将binlog_cache的数据强制刷到磁盘中sync_binlog的值默认为0，sync_binlog=0时表示采用操作系统机制进行缓冲数据同步。采用sync_binlog=1时，会增加磁盘IO的次数，会影响写入性能。sync_binlog=1时，并不是100%安全，会存在相应的问题。比如说使用Innodb引擎时，在一个事务发出commit前，会将binlog立即刷到磁盘中。如果这时候已经写入到binlog中，但是还没有提交就已经挂了，那么MySQL重启时，会将通过Redo log、Undo log将这个事务回滚掉，但是binlog已经记入了该事务信息，不能回滚掉。所以我们需要设置innodb_support_xa=1确保MySQL服务层的binlog和MySQL存储引擎层的Redo log、Undo log之间的数据一致性。
复制解决的基本问题 让一台服务器的数据让其他服务器保持同步，一台主库的数据可以同步到多台备库上，悲苦本身也可以被配置成另外一台服务器的主库。 MySQL支持两种复制方式：基于行的复制和基于语句的复制（逻辑复制）。这两种都是在主库上记录二进制日志，在备库重放日志的方式来实现异步的数据复制， 这说明同一时间主备库存在不一致，并且无法保证主备之间的延迟。 常见的复制用途 数据分布：MySQL通常复制不会造成很大的贷款压力，但基于行的复制会比基于语句的复制带宽压力大， 可以随意停止或开始复制，并在不同的地理位置来分
“高可用”是互联网一个永恒的话题，先避开MySQL不谈，为了保证各种服务的高可用有几种常用的解决方案。
随着腾讯云业务高速发展以及 MySQL 生态的演进，TencentDB for MySQL迎来了最快增速的时代，通过参与开源协同，TencentDB for MySQL 团队从服务、管控、内核和架构等几个维度，不断夯实稳定性、降低成本、丰富 DBaaS 产品功能，为公司自研业务和腾讯云客户提供不断进步的 MySQL 生态数据库产品服务。 1 PartⅠ 最美年代遇到的最大挑战 随着性能与稳定性的不断提高，腾讯云数据库 TencentDB for MySQL 在近两年得到了快速发展，实例个数、行业覆盖率、业
mysql主从架构部署比较简单，常见架构根据主从节点个数不同分成 一主多从，多主一从，双主节点等。
MySQL主从复制涉及到三个线程，一个运行在主节点（log dump thread），其余两个(I/O thread, SQL thread)运行在从节点：
原因：1.数据安全问题，如果你将数据存贮在容器中，当容器rm后，你就无了，当然你可以使用外挂数据卷的方式，但我在某些大佬的文章上看到，即使你外挂的数据卷，docker volumes的设计是围绕union fs镜像层提供持久化存贮，如果容器异常崩溃，数据库未正常关闭，则可能损坏数据，而且外挂数据卷对物理机硬件损伤较大（这段话是我从大佬文章里抄的，但前面rm数据就不见了是我实践过的）
为帮助开发者更好的了解和运用数据库，腾讯云数据库团队特出品《深入浅出理解云数据库》系列文章，从数据库的基本概念到云数据库特性及应用，从数据库基础原理知识到腾讯云经典实战案例解读，带你走进云数据库的世界。关注“腾讯云数据库”微信公众号，开启2020年的DB修炼之旅。 第一回请点击：深入浅出理解云数据库，年薪百万DBA之路 · 第一回 1 PartⅠ 云数据库的市场分析及应用 1. 市场分析 在讲云数据库之前，我们先来看一下云计算的整个市场。 业内对云计算主要分为三类，公有云、私有云、混合云。公有云
注: 此系列内容来自网络，未能查到原作者。感觉不错，在此分享。不排除有错误，可留言指正。
看过我之前文章《一条Update语句的执行过程是怎样的？》的朋友都基本知道【点击文章传送门~🙌】，在整个Update更新语句中会涉及到三种日志，分别是undo log(回滚日志）、redo log (重做日志) 、binlog (归档日志)，也有两阶段提交，没看过的不要紧，可以结合本篇文章一起看，会有1+1>2的效果。
👨💻个人主页： 才疏学浅的木子 🙇♂️ 本人也在学习阶段如若发现问题，请告知非常感谢 🙇♂️ 📒 本文来自专栏： MySQL 🌈 每日一语：人的一生，好不好只有自己知道，乐不乐只有自己明白。 🌈 本文目录 主从复制流程 主从复制的类型 主从复制内容方式 主从复制的优点 主从复制流程 MySQL主从复制是基于主服务器在二进制日志跟踪所有对数据库的更改。因此要进行复制，必须在主服务器上启用二进制日志。 每个从服务器从主服务器接收已经记录到日志的数据，当从服务器连接到主服务器时，它通知主服务器
MySQL 主从复制（Master-Slave Replication）是一种常见的数据库复制技术，它在数据库管理中发挥着重要的作用，有以下几个主要用途：
首先主从复制是什么？简单来说是让一台MySQL服务器去复制另一台MySQL的数据，使两个服务器的数据保持一致。
常见的MySQL主要有两种结构：Hash索引和B+ Tree索引，我们使用的是InnoDB引擎，默认的是B+树
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
即时通信 IM
实时音视频
