MySql实现主从热备和读写分离
MySql 主从热备份⼯作原理
简单的说：就是主服务器上执⾏过的sql语句会保存在binLog⾥⾯，别的从服务器把他同步过来，然后重复执⾏⼀遍，那么它们就能⼀直同步啦。
我们进⼀步详细介绍原理的细节， 这有⼀张图：
以上是⼀个主-从复制（热备)的例⼦。
整体上来说，复制有3个步骤：
1. 作为主服务器的Master，会把⾃⼰的每⼀次改动（每条sql语句）都记录到⼆进制⽇志Binarylog中。
2. 作为从服务器Slave， 会⽤master上的账号登陆到 master上，读取master的Binarylog，写⼊到⾃⼰的中继⽇志 Relaylog。
3. 然后从服务器⾃⼰的sql线程会负责读取这个中继⽇志，并执⾏⼀遍。
到这⾥主服务器上的更改就同步到从服务器上了，这种复制和重复都是mysql⾃动实现的，我们只需要配
置即可。
整个过程，MySQL使⽤3个线程来执⾏复制同步功能，其中两个线程(Sql线程和IO线程)在从服务器，另外⼀个线程(IO线程)在主服务器。
主-主互相复制实际只是把上⾯的例⼦反过来再做⼀遍。
所以我们以这个例⼦介绍原理。
实际操作
实际操作是
主服务器， 配置要记录在binLog⾥⾯的数据库，同时设置⼀个给从服务器登录的账号。
从服务器， 配置relayLog，配置主服务器的地址和端⼝，还有主服务器给的登录账号。
1. 在主服务器上设置给从服务器登录⽤的账号
rant replication slave on *.* to 'relay_user1'@'192.168.1.168' identified by 'pass123456';
注意：
jdk的下载安装与配置视频从服务器地址为：192.168.1.168，换成你的从机器的IP地址，这样就只允许从服务器登录，相对安全些。
⽤户名为： relay_user1
密码为： pass123456，⾃⼰按需要修改。
2. 修改MySQL配置⽂件
如果有Workbench，可以在左边的Navigator栏到Options File，然后进⾏配置，如果想直接修改配置⽂件，⽂件的位置请看结尾的后记3.
主服务器的myf配置
log-bin=master-a-bin
binlog-format=ROW //⼆进制⽇志的格式，有row、statement和mixed三种类型
server-id=1//要求各个服务器的这个id必须不⼀样
binlog-do-db=test //我们想让主服务器记录下操作的数据库。好让从服务器去复制的。
auto_increment_offset = 1//设置AUTO_INCREMENT起点，关于这个看后记4
auto_increment_increment = 10//设置AUTO_INCREMENT增量
//下⾯是⼀些别的配置，你可以跳过不看的
//
浮点数与十六进制转换工具gtid-mode=on//启⽤GTID，可看结尾的后记2说明
enforce-gtid-consistency=true//启⽤GTID
master-info-repository=TABLE//默认是file，选择table⽅式保存
relay-log-info-repository=TABLE//默认是file，选择table⽅式保存
sync-master-info=1//实时同步
sync-master-info=1//实时同步
slave-parallel-workers=2//设定从服务器的SQL线程数；0表⽰关闭多线程复制功能
binlog-checksum=CRC32 //⽇志校验
master-verify-checksum=1//启⽤校验
slave-sql-verify-checksum=1//启⽤校验
innodb_flush_log_at_trx_commit=1//每N次事务提交或事务外的指令都需要把⽇志写⼊（flush）硬盘
sync_binlog=1//This makes MySQL synchronize the binary log’s contents to disk each time it commits a transaction  从服务器的myf配置
log-bin=master-a-bin.log
binlog-format=mixed//请保持这两个⼀致
server-id=2
auto_increment_offset = 1
auto_increment_increment = 10
log-slave-updates=true//log-slave-updates 意思是，中继⽇志执⾏之后，这些变化是否需要计⼊⾃⼰的binarylog。当你的从服务器需要作为另外⼀个服
//配置主服务器相关的信息
replicate-do-db = test
report-host = 192.168.0.101
report-user = repl_user
report-password = 112122
report-port = 3306
//别的⼀些配置，可以跳过不看
sync_binlog=1
gtid-mode=on
enforce-gtid-consistency=true
master-info-repository=TABLE
relay-log-info-repository=TABLE
sync-master-info=1
slave-parallel-workers=2
binlog-checksum=CRC32
master-verify-checksum=1
slave-sql-verify-checksum=1
mysql无法连接到服务器binlog-rows-query-log-events=1
这样就算配置完咯，我不会告诉你我是⽤workbench改的，然后在apply的时候，把它复制下来粘贴到这⾥的，需要注意的是，如果你数据库原本就有表创建了，从服务器没有这个表的话，
请⼿动创建⼀个，
请⼿动创建⼀个，
请⼿动创建⼀个。
因为这个建表语句在这个同步操作前就执⾏过，没保存啊。我已经帮你试过了，下⾯试错误⽇志⾥⾯的信息.
2015-10-05 22:00:32 2628 [Warning] Slave: Table 'test.user' doesn't exist Error_code: 1146
2015-10-05 22:00:32 2628 [ERROR] Error running query, slave SQL thread aborted. Fix the problem, and restart the slave SQL thread with "SLAVE START". We stopped at log 'bin0001.000003' position 151
另外需要说的是，如果遇到这样的错误，请改正后重启下。
3. 重启同步
stop slave;
change master to master_host='192.168.0.101',master_user='repl_user',master_password='pass123456',master_auto_position=1;
start slave;
既然都配置好了，那就重启下，让配置⽣效
可以在主服务器打印下信息，看下有没启动成功先的
mysql> show master status ;
从服务器;
mysql> show slave status ;
如果打印的内容中，下⾯两句后⾯都为yes，那就恭喜你，正常运⾏咯
slave_io_running : yes
slave_sql_running : yes
Slave_IO_Running: 是否要从Master复制⼆进制数据
Slave_SQL_Running: 是否执⾏从Master复制过来的⼆进制数据
Slave_IO_Running和Slave_SQL_Running的值均为Yes时为同步开启;
前⾯已经说过了，从服务器会有两个线程的，⼀个IO线程和⼀个执⾏sql的线程。
说到这⾥，我不得不吐槽下在window下的cmd那个界⾯有多那么让⼈想死。
真的可以让⼈抓狂的。
然后试下在主服务器插⼊点数据，在从服务器能否同步回来？ 如果不能请打开或者之类的⽂件。
W7⽤户：
错误⽇志在：C:\ProgramData\MySQL\MySQL Server 5.6\data\你的电脑名.err
搭配问题
1. 单⼀master和多slave
多Slave之间并不相互通信，只能与master进⾏通信。如下：
如果写操作较少，⽽读操作很多时，可以采取这种结构。
keil5 keygen 下载你可以将读操作分布到其它的slave，从⽽减⼩master的压⼒。
但是，
当slave增加到⼀定数量时，slave对master的负载以及⽹络带宽都会成为⼀个严重的问题。
这种结构虽然简单，但是，它却⾮常灵活，⾜够满⾜⼤多数应⽤需求。
⼀些建议：
(1) 不同的slave扮演不同的作⽤(例如使⽤不同的索引，或者不同的存储引擎)；
(2) ⽤⼀个slave作为备⽤master，只进⾏复制；
(3) ⽤⼀个远程的slave，⽤于灾难恢复；
2. 主动模式的Master-Master (双主热备）
Master-Master复制的两台服务器，既是master，⼜是另⼀台服务器的slave。如图：
主动的Master-Master复制有⼀些特殊的⽤处。
例如，地理上分布的两个部分都需要⾃⼰的可写的数据副本。
这种结构最⼤的问题就是更新冲突。
假设⼀个表只有⼀⾏(⼀列)的数据，其值为1，如果两个服务器分别同时执⾏如下语句：
在第⼀个服务器上执⾏：
mysql> UPDATE tbl SET col=col + 1;
在第⼆个服务器上执⾏：
mysql> UPDATE tbl SET col=col * 2;
那么结果是多少呢？⼀台服务器是4，另⼀个服务器是3，但是，这并不会产⽣错误。
实际上，MySQL并不⽀持其它⼀些DBMS⽀持的多主服务器复制(Multimaster Replication)，这是MySQL的复制功能很⼤的⼀个限制(多主服务器的难点在于解决更新冲突)，但是，如果你实在有这种需求，你可以采⽤MySQL Cluster，以及将Cluster和
Replication结合起来，可以建⽴强⼤的⾼性能的数据库平台。
但是，可以通过其它⼀些⽅式来模拟这种多主服务器的复制。
3. 主动-被动模式的Master-Master (Master-Master in Active-Passive Mode)
这是master-master结构变化⽽来的，它避免了M-M的缺点，实际上，这是⼀种具有容错和⾼可⽤性的系统。它的不同点在于其中⼀个服务只能进⾏只读操作。如图：
max函数个税公式解释4. 带 从服务器的Master-Master结构(Master-Master with Slaves)
这种结构的优点就是提供了冗余。在地理上分布的复制结构，它不存在单⼀节点故障问题，⽽且还可以将读密集型的请求放到slave 上。
上。
后记
1. 整体架构图
最后我们想搭建⼀个下⾯这样的的集环境
1. 负载均衡– /
2.
3.
4. 动静分离egg的e发音音标
2. 关于MySql5.6的新特性
由于Mysql 5.6 引⼊了 GTID(Global Transaction ID)，保证 Slave 在复制的时候不会重复执⾏相同的事务操作；
其次，是⽤全局事务 IDs代替由⽂件名和物理偏移量组成的复制位点，定位 Slave 需要复制的 binlog 内容，在旧的 binlog 事件基础上新增两类事件
1. Previous_gtids_log_event 该事件之前的全局事务 ID 集合
2. Gtid_log_event 标记之后的事务对应的全局事务 ID
MySQL 5.6 的 binlog ⽂件中，每个事务的开始不是 “BEGIN” ，⽽是 Gtid_log_event 事件。
优点:
1. 使⽤ GTIDs 作为主备复制的位点，在写 binlog 时⽤ Gtid_log_event 标记事务
2. 主从复制不再基于master的binary logfile和logfile postition，从服务器连接到主服务器之后，把⾃⼰曾经获取到的
GTID(Retrieved_Gtid_Set)发给主服务器，主服务器把从服务器缺少的GTID及对应的transactions发过去即可.
3. 采⽤多个sql线程，每个sql线程处理不同的database，提⾼了并发性能，即使某database的某条语句暂时卡住，也不会影响到后续对
其它的database进⾏操作.
对⽐：
以前采⽤类似于C语⾔那样的⽂件和偏移量的⽅式来做的。这个要是偏移没同步好，出的就是⼀堆bug，现在是⼀个⼀个事务队列的样式，相对安全了。
3.配置⽂件的位置
window下
⼀开始以为配置⽂件是安装的MySql⽬录下的my-default.ini，后来⽤workbench发现配置⽂件是在C:\ProgramData\MySQL\MySQL Server 5.6\my.ini。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。