总体来说注意以下几点
-
slave上查询尽量用到索引
-
master my.cnf 配置优化
-
比主从更可靠的是drbd+keepalive,hearbeat好像更专业点
- slave同步过滤 过滤user表，看效果
#replicate-wild-ignore-table =performance_schema.%
gtid
[MySQL 5.6] GTID内部实现、运维变化及存在的bug
http://mysqllover.com/?p=594
gtid-mode用来设置是否开启GTID功能，如果要开启GTID功能，需要同时开启log-bin和log_slave_updates功能，另外还需要开启enforce_gtid_consistency功能。gtid_mode参数可以设置为on、off、upgrade_step_1、upgrade_step_2四种值，其中upgrade_step_1和upgrade_step_2是给将来mysql可能的新功能预留的，对当前的myql没有任何意义。同时，mysql建议在mysql_upgrade的时候，关闭gtid_mode功能和enforce_gtid_consistency功能，因为Mysql在upgrade期间可能会操作非事务的MyISAM存储引擎表，会引起报错
SHOW CREATE TABLE mysql.gtid_executed\G
select @@global.gtid_executed\G
将GTID值持久化保存在一张InnoDB表中，并与用户事务一起进行提交，从而实现数据的一致性
START TRANSACTION;
# user statement
......
INSERT INTO mysql.gtid_executed VALUES (...)
END;
需要注意的是表mysql.gtid_executed是在主服务器和从服务器上有进行更新的，而表slave_relay_log_info仅在从服务器上更新
MySQL 5.7对于表mysql.gtid_executed的更新策略也有些不同，如果没有主服务器没有开启log_bin或者从服务器没有开启log_slave_updates，其会每一个事物更新表gtid_executed，这样服务器重启后可以快速知道当前服务器执行到的GTID位置。因此，用户可能在服务器上看到类似如下的内容
select * from mysql.gtid_executed;
select thread_id,thread_os_id,name,processlist_command,processlist_state from threads where name like '%compress%'\G
参考http://blog.csdn.net/yinwenjie/article/details/52935140
因为主从现在在用，所以关注一下
工作原理
MySQL一主多从搭建方式
master my.cnf
# my.cnf文件中没有涉及Replicaion机制的配置信息，就不在这里列出了
......
# 开启日志
log_bin
# 以下这些参数会在后文进行说明 (红色参数要特别注意)
sync_binlog=1
binlog_format=mixed
binlog-do-db=qiang
binlog_checksum=CRC32
binlog_cache_size=2M
max_binlog_cache_size=1G
max_binlog_size=100M
# 必须为这个MySQL服务节点设置一个集群中唯一的 server id信息
server_id=140
# 只用MySQL客户端，都可以进行设置：
# 这里我们直接使用root账号进行同步，但是生产环境下不建议这样使用
> grant replication slave on *.* to root@192.168.61.141 identified by '123456'
# 通过以下命令，可以查看设置完成后的Master节点工作状态
> show master status;
+----------------+----------+--------------+------------------+-------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+----------------+----------+--------------+------------------+-------------------+
| kp2-bin.000002 | 404 | qiang | | |
+----------------+----------+--------------+------------------+-------------------+
slave my.cnf
# my.cnf文件中没有涉及Replicaion机制的配置信息，就不在这里列出了
......
# 开启日志
log-bin
sync_relay_log=1
# 必须为这个MySQL服务节点设置一个集群中唯一的server id信息
server_id=142
......
# 请注意这里设置的用户名和密码信息要和Master上的设置一致
# 另外master log file所指定的文件名也必须和Master上使用的日志文件名一致
> change master to master_host='192.168.61.140',master_user='root',master_password='123456', master_log_file='kp2-bin.000002',master_log_pos=120;
# 启动Savle同步
> start slave;
# 然后我们就可以使用以下命令查看salve节点的同步状态
> show slave status;
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 192.168.61.140
Master_User: root
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: kp2-bin.000002
Read_Master_Log_Pos: 404
Relay_Log_File: vm2-relay-bin.000002
Relay_Log_Pos: 565
Relay_Master_Log_File: kp2-bin.000002
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
......
Master_Server_Id: 140
Master_UUID: 19632f72-9a90-11e6-82bd-000c290973df
Master_Info_File: /var/lib/mysql/master.info
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State: Slave has read all relay log; waiting for the slave I/O thread to update it
Master_Retry_Count: 86400
......
Auto_Position: 0
一主多从方案的使用建议
一主多从的MySQL集群方式主要针对读密集型业务系统，其主要目标是将MySQL服务的读写压力进行分离。
使用固态硬盘作为MySQL服务的块存储基础，并使用RAID 10磁盘阵列作为硬件层构建方案——这是生产环境下单个MySQL服务节点的基本组成逻辑
应使用一个独立的Salve节点作为备用的Master节点，虽然这种方式不可作为异地多活方案的基础但可作为本地高可用方案的实现基础。当然，为了防止由于日志错误导致的备份失败，这个备份的Salve节点也可以采用MySQL Replicaion机制以外的第三方同步机制，例如：Rsync、DRBD。Rsync是笔者在工作实践中经常使用的，进行MySQL数据增量同步的方式，而DRBD的差异块同步方式是互联网上能够找到最多资料的方式：
在后续的文章中，我们还会专门讨论针对Master节点的集群调整方案，并且建议读者如何使用适合系统自身业务的高可用方案。例如使用Keepalived / Heartbeat进行主备Master节点的切换
复杂的统计查询需要专门的Salve节点进行支持。参与生产环境实时业务处理的任何MySQL服务节点，在这些服务节点上所运行的SQL查询应该尽可能简单，并且需要使用索引对检索进行支持。特别是数据量非常大的数据表，必须保证所有的检索操作都有索引提供支持，否则Table Full Scan的检索过滤方式不但会拖慢检索操作本身，还可能会明显拖慢其它的事务操作。通过MySQL提供的执行计划功能，技术人员能够很方便实现以上的要求。如果您的业务系统存在复杂的业务查询要求，例如周期性的财务流水报表，周期性的业务分组统计报表等，那么您最好专门准备一个（或多个）脱离实时业务的Salve节点，完成这个工作
需要业务系统开发人员投入的维护精力就会呈几何级增长。
高可用层面的问题：在MySQL一主多从集群中，虽然存在多个Salve节点（read业务性质节点），但是一般只存在一个Master节点（write业务性质节点）。某一个（或多个）Salve节点崩溃了，不会对整个集群造成太大影响（但可能影响上层业务系统的某一个子系统）
本文转自 liqius 51CTO博客，原文链接：http://blog.51cto.com/szgb17/1870724，如需转载请自行联系原作者
