在5.6以后，可以通过命令动态修改.

注意有些命令是需要主从都要执行，有些命令是只在slave执行。

gtid_mode 的几种状态值说明：
OFF: 不产生 GTID, 基于 binlog+position,也不能接受GTID的日志。默认值
OFF_PERMISSIVE:  不生产 GTID,但作为slave可以识别GTID事务也可以识别非GTID事务
ON_PERMISSIVE: 产生GTID，slave可以处理GTID事务和非GTID事务
ON: 产生GTID事务，slave只接受GTID事务

实验一：将传统复制切换到GTID复制

启用GTID:

set @@global.enforce_gtid_consitency=warn;
set @@global.enforce_gtid_consistency=on;
set @@global.gtid_mode=OFF_PERMISSIVE; #不产生gtid,但可以处理gtid
set @@global.gtid_mode=ON_PERMISSIVE; #产生gtid,也可以处理gtid
show status like ‘ONGOING_ANONYMOUS_TRANSACTION_COUNT’;
set @@global.gtid_ode=on;

stop slave [for channel ‘channel’];change master to master_auto_postion=1; start slave;（slave)

更改复制到自动识别GTID环境 Continue reading →

在5.7下半同步是以插件的形式出现的，所以在启用半同步前要先安装半同步插件 semisync_master.so

On the master:

INSTALL PLUGIN rpl_remi_sync_master SONAME ‘semisync_master.so’;

On slave slave:

INSTALL PLUGIN rpl_semi_sync_slave SONAME ‘semisync_slave.so’;

在my.cnf里配置,要写在mysqld段

master:

[mysqld]
repl_semi_sync_master_enable=1
repl_semi_sync_master_timeout=1000 #1 second

slave:

[mysqld]

repl_semi_sync_slave_enable=1

卸载插件：

uninstall plugin rpl_semi_sync_master;#master
uninstall plugin rpl_semi_sync_slave; #slave

在主上设置slave的数量，用来接受slave返回的次数数量2,用来分析 show global variables like ‘%semi%’;

set global rpl_semi_sync_master_wait_for_slave_count=2;

监控：

show global status like ‘rpl_semi_sync%’;

架构为两主一从，两主为同一台服务器的多实例，安装方法请参考上篇文章http://blog.haohtml.com/archives/17300。

主master1    IP: 192.168.1.116     PORT: 3306
主master2    IP: 192.168.1.116     PORT: 3307
从slave        IP: 192.168.1.200     PORT: 3306

两主为全新安装。如果以前安装过的话，可以将原来的数据库删除掉，再执行 reset master即可。(否则需要将两个主的想着库表使用 mysqldump到从中)

[master1 3306] my.cnf
[client]
port=3306
socket=/data/mysql/mysql3306/tmp/mysql.sock

[mysqld]
basedir=/data/mysql/mysql3306
datadir=/data/mysql/mysql3306/datadir
#socket=/var/lib/mysql/mysql.sock
socket=/data/mysql/mysql3306/tmp/mysql.sock
port=3306

log-bin=mysql-bin
binlog-format=row

# 二进制日志的格式：有row、statement和mixed三种   Continue reading →

http://www.cnblogs.com/gomysql/p/3650645.html

1. 一个存放记录(row)的page，由page header、page trailer、page body组成。如下图:^[2]
   
   

Continue reading →

这两个名字虽然都叫做索引，但这并不是一种单独的索引类型，而是一种数据存储方式。对于聚簇索引存储来说，行数据和主键B+树存储在一起，辅助键B+树只存储辅助键和主键，主键和非主键B+树几乎是两种类型的树。对于非聚簇索引存储来说，主键B+树在叶子节点存储指向真正数据行的指针，而非主键。

InnoDB使用的是聚簇索引，将主键组织到一棵B+树中，而行数据就储存在叶子节点上，若使用”where id = 14″这样的条件查找主键，则按照B+树的检索算法即可查找到对应的叶节点，之后获得行数据。若对Name列进行条件搜索，则需要两个步骤：第一步在辅助索引B+树中检索Name，到达其叶子节点获取对应的主键。第二步使用主键在主索引B+树种再执行一次B+树检索操作，最终到达叶子节点即可获取整行数据。

MyISM使用的是非聚簇索引，非聚簇索引的两棵B+树看上去没什么不同，节点的结构完全一致只是存储的内容不同而已，主键索引B+树的节点存储了主键，辅助键索引B+树存储了辅助键。表数据存储在独立的地方，这两颗B+树的叶子节点都使用一个地址指向真正的表数据，对于表数据来说，这两个键没有任何差别。由于索引树是独立的，通过辅助键检索无需访问主键的索引树。

MyISAM索引用的B+ tree来储存数据，MyISAM表的索引和数据是分开的，MyISAM索引的指针指向的是键值的地址(0XX开始之类的物理地址)，地址存储的是数据，如下图：

为了更形象说明这两种索引的区别，我们假想一个表如下图存储了4行数据。其中Id作为主索引，Name作为辅助索引。图示清晰的显示了聚簇索引和非聚簇索引的差异。

x

我们重点关注聚簇索引，看上去聚簇索引的效率明显要低于非聚簇索引，因为每次使用辅助索引检索都要经过两次B+树查找，这不是多此一举吗？聚簇索引的优势在哪？

1 由于行数据和叶子节点存储在一起，这样主键和行数据是一起被载入内存的，找到叶子节点就可以立刻将行数据返回了，如果按照主键Id来组织数据，获得数据更快。

2 辅助索引使用主键作为”指针” 而不是使用地址值作为指针的好处是，减少了当出现行移动或者数据页分裂时辅助索引的维护工作，使用主键值当作指针会让辅助索引占用更多的空间，换来的好处是InnoDB在移动行时无须更新辅助索引中的这个”指针”。也就是说行的位置（实现中通过16K的Page来定位，后面会涉及）会随着数据库里数据的修改而发生变化（前面的B+树节点分裂以及Page的分裂），使用聚簇索引就可以保证不管这个主键B+树的节点如何变化，辅助索引树都不受影响。

参考：http://www.tuicool.com/articles/ZRN3qu

转：http://www.cnblogs.com/shijingxiang/articles/4743324.html

http://fireflyclub.org/?/article/37

http://www.cnblogs.com/yuyue2014/p/4738007.html

注意这篇文章并非死锁的，而是锁等待

如果遇到死锁了，怎么解决呢？找到原始的锁ID，然后KILL掉一直持有的那个线程就可以了， 但是众多线程，可怎么找到引起死锁的线程ID呢？ MySQL 发展到现在，已经非常强大了，这个问题很好解决。 直接从数据字典连查找。

Continue reading →