Ideas, releases, practical guides, and perspectives from the people building with MySQL.
本文也有英文版：English version。
MySQL官方从MySQL-5.6开始优化复制延迟问题，最先实现了 Schema 级别的 Binlog
并发应用。然而这个并发能力并不能解决日常的复制延迟。然后官方在
MySQL-5.7上实现了基于提交顺序的并发回放策略(Commit Order),
这种策略依赖主上的事务并发执行数量。主上并发执行的事务非常多的情况下，从库上回放的速度才会快。如果主上并发少，从库上回放速度仍然会变慢，产生复制延迟。因此官方又在
MySQL-5.7 上又实现了行级的并发策略(Writeset),
这种并发策略无论主上并发事务的多少，都能在从库上快速的并发回放。
我们很早以前就在线上全面使用了基于 writeset 的复制策略，writeset …
[获取更多]
大事务是MySQL中一个痛点问题， 不仅会带来复制延迟，也会带来大量的稳定性问题。上一篇文章《MySQL大事务提交优化》介绍了大事务在提交时带来的问题，以及AliSQL中做的技术优化。这篇文章会介绍大事务在半同步复制时的问题，以及AliSQL中如何解决这个问题。
在《MySQL大事务提交优化》中，我们提到大事务提交时写Binlog会导致系统出现如下奇怪的慢SQL。
1.3s，并且慢SQL记录里也没有看到长时间的锁等待。
--- title: MySQL · mysql · MySQL replication partial transaction author: 张远 ---
# replication 概述 目前MySQL支持的replication方式多种多样 1. 普通的master-slave
异步replication 2. 半同步的semi-sync replication
【数据存储与数据库】 【mysql】 【SQL】 【线程】 【阿里技术协会】 【并行复制】 【Transaction】 …
# GTID 简介 GTID (global transaction
identifier)在MySQL5.6时引入，GTID是事务的全局唯一标识。GTID结构如下 ``` GTID =
source_id:transaction_id ``` source_id:执行事务的原始实例的sever_uuid,
此事务GTID在备库apply时也不变。 transaction_id:事务的
【数据存储与数据库】 【mysql】 【线程】 【阿里技术协会】 【binlog】 【mysql5.7】 …
备注：插图来自网络搜索，如果觉得不当还请及时告知 ：)
一般而言，slave相对master延迟较大，其根本原因就是slave上的复制线程没办法真正做到并发。简单说，在master上是并发模式(以InnoDB引擎为主)完成事务提交的，而在slave上，复制线程只有一个sql thread用于binlog的apply，所以难怪slave在高并发时会远落后master。
ORACLE MySQL 5.6版本开始支持多线程复制，配置选项 slave_parallel_workers 即可实现在slave上多线程并发复制。不过，它只能支持一个实例下多个 database 间的并发复制，并不能真正做到多表并发复制。因此在较大并发负载时，slave还是没有办法及时追上master，需要想办法进行优化。
…
[获取更多]背景
主从切换是高可用MySQL架构的必要步骤（即使用不发生，也要有备无患）。一般设置为双M（M1、M2），假设当前状态为写M1，而M2只读，切换的大致流程如下：
1、 停止应用写M1，将M1设置为只读
【导读】
鉴于MySQL5.5数据库产品的性能提升不明显，软件产品稳定性不佳，且新增加的功能也不足突破，所以生产环境中只有几套应用使用MySQL5.5版本支撑，以培养与掌握MySQL5.5的经验和技术，所以个人对MySQL5.5系列的实战也不多。现有一个项目，因服务器配置的特殊性，以及业务特点、数据容量、数据访问等也非常特殊，不得不考虑采用MySQL5.5，且国内某mysql服务提供商技术人员指定要求的版本号为MySQL5.5.27。综合上述信息导致今天无意碰到一个MySQL数据库复制搭建过程中出现的错误信息，可能其他同行也可能会碰见，特此写一篇技术博文分享给大家。
…
[获取更多]