爱可生 DBA 团队成员，主要负责 MySQL 故障处理和 SQL 审核优化。对技术执着，为客户负责。
一般Mysql主从复制有三个线程参与，都是单线程：Binlog Dump(主) -> IO Thread (从) -> SQL Thread(从)。
innodb_flush_log_at_trx_commit 是 MySQL 的一个系统变量，运行环境是 InnoDB 引擎。该变量定义了 InnoDB 在每次事务提交时，如何处理未刷入（flush）的重做日志信息（redo log）。它是 InnoDB 确保 ACID 属性中的持久性（Durability）的关键因素。当数据库发生故障，如崩溃或者断电，这项设置可以保护您的数据不会丢失。
事务(Transaction) 是访问和更新数据库的基本执行单元，一个事务中可能会包含多个 SQL 语句，事务中的这些 SQL 语句要么都执行，要么都不执行，而 MySQL 它是一个关系型数据库，它自然也是支持事务的。事务同时也是区分关系型数据库和非关系型数据库的一个重要的方面。
通俗来讲事务就是多步操作要么全部成功要么全部失败，保证最终状态一致。为了简化应用程序，使其可以忽略一些潜在错误和并发问题，数据库层对事务的ACID特性做了统一支持。
MySQL 主从复制是指数据可以从一个MySQL数据库服务器主节点复制到一个或多个从节点。MySQL 默认采用异步复制方式，这样从节点不用一直访问主服务器来更新自己的数据，数据的更新可以在远程连接上进行，从节点可以复制主数据库中的所有数据库或者特定的数据库，或者特定的表。
在数据修改的时候，不仅记录了redo，还记录了相对应的undo，如果因为某些原因导致事务失败或回滚了，可以借助该undo进行回滚。
MySQL通过复制（Replication）实现存储系统的高可用。目前，MySQL支持的复制方式有：
在MySQL的主从复制架构中，主库上经常会并发的执行很多SQL，只要这些SQL没有产生锁等待，那么同一时间并发好几个SQL线程是没有问题的。
启动mongodb：在安装的mongodb的文件夹下的bin目录打开cmd输入mongo，即可启动mongodb，cmd窗口关闭或者按ctrl+c即可退出mongodb
Redo log的刷盘操作将会是最终影响MySQL TPS的瓶颈所在。为了缓解这一问题，MySQL使用了组提交，将多个刷盘操作合并成一个，如果说10个事务依次排队刷盘的时间成本是10，那么将这10个事务一次性一起刷盘的时间成本则近似于1。
爱可生 DBA 团队成员，负责客户的数据库故障处理以及调优。擅长故障排查及性能优化。对数据库相关技术有浓厚的兴趣，喜欢分析各种逻辑。
本文是由爱可生研发团队出品的「图解MySQL」系列文章，不定期更新，但篇篇精品。欢迎大家持续关注～
MySQL是一个RDBMS（关系型数据库管理系统），由瑞典MySQL AB 公司开发，目前属于 Oracle 旗下产品。由于其体积小、速度快、拥有成本低，尤其是开放源码这一特点，广受各大企业欢迎，包括腾讯，阿里，百度，网易，Google，FaceBook等互联网巨头企业 随着互联网的高速发展，互联网服务可用性变得越发重要，数据容灾也随之成为各企业的关键任务。在数据容灾中，数据库集群如何处理数据一致性也成为了各企业需要解决的问题。特别在一些新兴的金融服务中，MySQL也逐渐成为其核心数据库，如何保证金钱的准
在事务的ACID特性中，原子性（A）、一致性（C）、持久性（D）由undo log和redo log实现，隔离性（I）由锁+MVCC实现
mysql默认是异步复制, 但是可以使用半同步插件(semisync_master.so和semisync_slave.so)来做半同步复制, 等待至少N个(rpl_semi_sync_master_wait_for_slave_count默认1)从库收到binlog后,才返回客户端提交成功. 当然超时(rpl_semi_sync_master_timeout默认10秒)后就变成异步了
其实就是innodb_flush_log_at_trx_commit和sync_binlog两个参数设置，都设置为 1 就是双 1 设置。MySQL 默认配置就是双 1 配置。
在学习《MySQL技术内幕：SQL编程》一书，并做了笔记。本博客内容是自己学了《MySQL技术内幕：SQL编程》事务编程一章之后，根据自己的理解做的笔记，内容和书本并不一致，不过书本实验都经过自己验证，基于MySQL5.7版本。做笔记的目的是方便自己复习，同时分享出来或许对其他人或许有点帮助
其实就是innodb_flush_log_at_trx_commit和sync_binlog两个参数设置，都设置为1就是双1设置。MySQL 默认配置就是双1配置。
数据库中的事务是指对数据库执行一批操作，这些操作最终要么全部执行成功，要么全部失败，不会存在部分成功的情况。
REPEATABLE READ是InnoDB的默认隔离级别。MySQL对它有如下的支持：
对这个问题的思考起源于一篇文字，文字中针对 MYSQL的隔离级别中的实现的问题进行了说明 MySQL Repeatable-Read 隔离级别一些误解 - 知乎 (zhihu.com) ，里面写的很详细，这里就不在详述了，感兴趣的同学可以去看，很涨知识，例如我，因为读了这篇文字，对于 PG MYSQL 在MVCC 的实现的问题，有了更深的认知。顺便说一句，写这篇文字的同学是阿里云POLARDB 的数据库开发者。https://zhuanlan.zhihu.com/p/402008512
上周五进行了一个大表删除的操作，在删除的过程中，出现了一点小问题，白白花费了两个小时，我这里记录了一下大概的过程，废话不多说了，直接看过程吧。
参考：http://www.linuxidc.com/Linux/2015-11/124942.htm
上面有写到基于容器的变化新建一个镜像，既然如此，那我在容器中对数据的修改应该会保存到新生成的镜像中，然后我再用新镜像new一个容器出来，数据更新部分不就保存到新容器中了？
近期，发现一个 MySQL 从节点提示同步异常。执行 show replica status 都被挂起。
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，决定是
那么如果在两阶段提交的过程中，发生了数据库的崩溃，MySQL内部会做什么事情来保证数据的一致性呢？以上述的update操作为例：
事务是数据库区别于文件系统的重要特性之一，提到事务肯定会想到事务的4个特性ACID，要保证业务的正常使用，必须保证ACID，ACID表示原子性(atomicity)、一致性(consistency)、隔离性(isolation)、持久性(durability)，一个运行良好的事务系统也是要求具备这些特征
今天想说的是，习惯使用ORACLE 的程序员，在MYSQL 留下的麻烦怎么被发现。这两种数据库在处理事务上是有不同的，oracle 默认不会自动commit， 而mysql 会默认 auto commit， 说道auto commit ，四大数据库，只有oracle 一家是不默认commit。
在之前的文章「简单了解InnoDB底层原理」聊了一下MySQL的Buffer Pool。这里再简单提一嘴，Buffer Pool是MySQL内存结构中十分核心的一个组成，你可以先把它想象成一个黑盒子。
innodb_flush_log_at_trx_commit 和 sync_binlog 是 MySQL 的两个配置参数。它们的配置对于 MySQL 的性能有很大影响（一般为了保证数据的不丢失，会设置为双1，该情形下数据库的性能也是最低的）。
MySQL 事务主要用于处理操作量大，复杂度高的数据。比如说，在人员管理系统中，你删除一个人员，你即需要删除人员的基本资料，也要删除和该人员相关的信息，如信箱，文章等等，这样，这些数据库操作语句就构成一个事务.
http://www.linuxidc.com/Linux/2015-11/124942.htm
今天这篇文章，是之前很早时候线上的一个案例，重新翻看的时候，觉得挺有意思，就再转发一遍。
他们有一个共同的字段, 叫做xid, 崩溃恢复的时候, 会按照顺序扫描redolog:
最近工作上的事情比较繁琐，回到家就想休息，今天介绍一个简单的测试innodb_flush_log_at_trx_commit参数对插入性能影响的方法吧。
某项目上出现 MySQL Crash，相关 errorlog 日志如下，从日志可以看出是 binlog error 导致的问题，但是无法确认具体原因，网上大部分资料都说是由于空间已满导致，后来在系统日志( /var/log/message)中确实找到了 / 分区空间已满的信息，所以基本可以确认 binlog error 是由于磁盘空间已满导致，进而造成 MySQL Crash。
MySQL 主从复制功能可以搭建从库来为 MySQL 创建一套在线的备份系统，但是自身不能独立实现切换；需要借助第三方高可用工具。然而当自身有大事务在运行时会阻塞一些 show 语句；例如“show master status”，造成误判。
MySQL作为当下最流行的开源关系型数据库，有一个很关键和基本的能力，就是必须能够保证数据不会丢。那么在这个能力背后，MySQL是如何设计才能保证不管在什么时间崩溃，恢复后都能保证数据不会丢呢？有哪些关键技术支撑了这个能力？本文将为我们一一揭晓。
本节将集中讨论下面三种GTID更新的时机，这部分相当重要，后面的故障案列会和这节有关。下面先来看一下他们的定义:
本文介绍了MySQL中的binlog组提交及其在MySQL Replication中的作用。binlog是MySQL中一种二进制日志，用于记录数据库的更改历史。在MySQL Replication中，通过binlog实现主从复制。当主库发生更改时，binlog会记录所有更改，并将更改发送到从库。从库根据binlog中的更改来更新自己的数据，从而保持与主库一致。在MySQL中，使用binlog可以实现多种功能，如灾难恢复、数据迁移、只读实例等。
当我们使用如上所述的语法的时候，这两种方式在事务(Transaction) 进行当中SELECT 到同一个数据表时，都必须等待其它事务数据被提交(Commit)后才会执行。
mysql的"双1验证"指的是innodb_flush_log_at_trx_commit和sync_binlog两个参数设置，这两个是是控制MySQL 磁盘写入策略以及数据安全性的关键参数。下面从参数含义，性能，安全角度阐述两个参数为不同的值时对db 性能,数据的影响。
日常开发中，大家肯定遇到过这些需求：“ 数据迁移、数据恢复、新建从库 ” 等等一系列任务，因为做这些需求我们肯定知道，会涉及到 大量的数据 的处理。
前面一篇，我们学习到了MySQL多版本并发控制（MVCC）实现原理，这一篇我们接着学习MySQL主从复制模式下的延迟解决方案。
分布式事务就是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上，以上是百度百科的解释，简单的说，就是一次大的操作由不同的小操作组成，这些小的操作分布在不同的服务器上，且属于不同的应用，分布式事务需要保证这些小操作要么全部成功，要么全部失败，本质上来说，分布式事务就是为了保证不同数据库的数据一致性。
如果回滚到上面设置的保存点s1,那么account表中的数据自然就没有了。这就是回滚事务。
看源码太费眼睛了. 还是gdb方便点, 为了方便低版本gdb的环境, 这里就不升级gdb了.
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
即时通信 IM
实时音视频
