MySql day-43 （ 扩展 ）

不停库不锁表在线主从配置
http://seanlook.com/2015/12/14/mysql-replicas/

1.1 xtrabackup
mysqldump对于导出10G以下的数据库或几个表，还是适用的，而且更快捷。一旦数据量达到100-500G，无论是对原库的压力还是导出的性能，mysqldump就力不从心了。Percona-Xtrabackup备份工具，是实现MySQL在线热备工作的不二选择，可进行全量、增量、单表备份和还原。（但当数据量更大时，可能需要考虑分库分表，或使用 LVM 快照来加快备份速度了）

XtraBackup优势 ：

无需停止数据库进行InnoDB热备
增量备份MySQL
流压缩到传输到其它服务器
能比较容易地创建主从同步
备份MySQL时不会增大服务器负载

主从不同步

http://www.rfyy.net/archives/2309.html
http://blog.51cto.com/storysky/259280

Mysql主从不同步解决方法
主从同步配置好后，运行了一时间，出现了不同步现象，用命令检查，看到从上报下面错误：
msyq > show slave status \G;
Last_Errno: 1062
Last_Error: Error ‘Duplicate entry ‘149’ for key ‘PRIMARY’’ on query. Default database: ‘zabbix’. Query: ‘insert into escalations (escalationid,actionid,status,triggerid,itemid,eventid,r_eventid) values (149,7,0,16272,null,3334811,null)’

看这个报错，应该是主MYSQL上建表时，主键有重复的值报错，造成从不能同步。
解决的办法是在从库上执行:
mysql> slave stop;
mysql> set GLOBAL SQL_SLAVE_SKIP_COUNTER=1;
mysql> slave start;
上面的方法可以解决问题，还有一种解决问题的办法是通过修改mysql的配置文件，让从库的同步线程忽略这个错误，方法：

修改mysql配置文件 /etc/my.cnf 在 [mysqld]下加一行 slave_skip_errors = 1062 ,保存重启mysql
mysql slave可以正常同步了.

MYSQL主从同步故障一例及解决过程！
公司里有两个mysql服务器做主从同步，某天Nagios发来报警短信，mysqla is down…赶紧联系机房，机房的人反馈来的信息是 HARDWARE ERROR 后面信息省略，让机房记下错误信息后让他们帮忙重启下看是不是能正常起来，结果竟然正常起来了，赶紧导出所有数据。
问题又出现了，nagios 又报警，mysql_AB error，检查从库
show slave status \G; 果然
Slave_IO_Running: Yes
Slave_SQL_Running: No
而且出现了1062错误，还提示
Last_SQL_Error: Error ‘Duplicate entry ‘1001-164761-0’ for key ‘PRIMARY’’ on query. Default database: ‘bug’. Query: ‘insert into misdata (uid,mid,pid,state,mtime) values (164761,1001,0,-1,1262623560)’
很显然，由于主库重启导致 从库数据不同步而且主键冲突。查看error 日志发现error日志文件变得好大，比以前大了将近好几倍，
tail -f mysql_error.log 最开始查看到的是这条信息
发现这条信息
[ERROR] Slave SQL: Error ‘Duplicate entry ‘1007-443786-0’ for key ‘PRIMARY’’ on query. Default database: ‘ufo’. Query: ‘insert into misdata (uid,mid,pid,sta
te,mtime) values (443786,1007,0,-1,1262598003)’, Error_code: 1062
100104 17:39:05 [Warning] Slave: Duplicate entry ‘1007-443786-0’ for key ‘PRIMARY’ Error_code: 1062
100104 17:39:05 [ERROR] Error running query, slave SQL thread aborted. Fix the problem, and restart the slave SQL thread with “SLAVE START”. We stopped at log ‘ufolog.000058
8’ position 55793296
报错和上面的意思差不多，

最先想到的就是首先手动同步一下，从库上首先 stop slave;停止同步
进入主库锁表，
FLUSH TABLES WITH READ LOCK；
mysql> show master status;
±------------------±----------±-------------±-----------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |
±------------------±----------±-------------±-----------------+
| ufo.000063 | 159164526 | | |
±------------------±----------±-------------±-----------------+
1 row in set (0.00 sec)
进入从库
mysql>change master to master_host=‘192.168.1.141’, master_user=‘slave’,
master_password=‘xxx’,
master_port=3306,
master_log_file=‘ufo.000063’,
master_log_pos=159164526;

完成上面这些后
start slave;
回到主库
unlock tables; 解锁

回到从库 查看
show slave status \G;
发现正常了，长处了一口气。可是还没过一分钟，发现又开始报错了，还是最开始那个错误，这是怎么回事…
于是又想到了跳过错误的办法，（不过我不太喜欢用这种方法）马上进入从库
stop slave;
set global sql_slave_skip_counter=1; （1是指跳过一个错误）
slave start;
再show slave status \G;查看
还是报错 只不过 原来的 164761 变成了 165881，连续执行了几次后
除了上面的数值 在变，错误依然还在
郁闷了，看来只能先强制跳过 1062错误了，于是修改从库的/etc/my.cnf文件
在里面的[mysqld]下面加入了一行
slave-skip-errors = 1062 (忽略所有的1062错误)
重启下从库的mysql /etc/init.d/mysqld restart
再 show slave status \G;一下发现正常了，但是我知道这时的数据可能已经不同步了，
再次查看一下日志，让我感到意外的是tail -f mysql_error.log 出现大量的
…
100106 16:54:21 [Warning] Statement may not be safe to log in statement format. Statement: delete from system_message_1 where to_uid = 181464 ORDER BY id ASC LIMIT 1
…
日志里面有大量的这种警告，意思应该是statement 格式不安全，用vim 打开他看了一下，发现好多这类警告，我说为什么错误日志怎么变这么大了呢！！
statement format 应该是 binlog的一种格式，进入从库查看一下
show global variables like ‘binlog_format’;
果然当前的格式为statement

我需要把格式改为 mixed格式
修改从库的 my.cfg
在[mysqld]下面加入下面这行
binlog_format=mixed

然后重启mysql服务，发现错误日志里的 警告 都停止了。这回清静多了~~

我突然想起一件事，记得有朋友说过 RBR 模式可以解决很多因为主键冲突导致的主从无法同步情况，想到这里我就想要不要把 slave-skip-errors = 1062 去掉再试试，
于是就进入到my.cnf 里在注释掉了 slave-skip-errors = 1062
再次重新启动 mysql服务
进入从库
show slave status \G;
…
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
…

恢复了！！！有观察了一段时间没有出现问题这才放心，

看来导致 mysql 主从复制出错的原因还真不少修复的办法也不止一个，binlog的格式也是其中之一。
希望遇到和这次一样问题的朋友看到这篇文章后会得到 一些启发和解决问题的方法~~

主主
关于 auto_increment https://blog.csdn.net/leshami/article/details/39779509
http://www.cnblogs.com/ygqygq2/p/6045279.html

在企业中，数据库高可用一直是企业的重中之重，中小企业很多都是使用mysql主从方案，一主多从，读写分离等，但是单主存在单点故障，从库切换成主库需要作改动。因此，如果是双主或者多主，就会增加mysql入口，增加高可用。不过多主需要考虑自增长ID问题，这个需要特别设置配置文件，比如双主，可以使用奇偶，总之，主之间设置自增长ID相互不冲突就能完美解决自增长ID冲突问题。

1.两台mysql都可读写，互为主备，默认只使用一台（masterA）负责数据的写入，另一台（masterB）备用；
2.masterA是masterB的主库，masterB又是masterA的主库，它们互为主从；
3.两台主库之间做高可用,可以采用keepalived等方案（使用VIP对外提供服务）；
4.所有提供服务的从服务器与masterB进行主从同步（双主多从）;
5.建议采用高可用策略的时候，masterA或masterB均不因宕机恢复后而抢占VIP（非抢占模式）；
这样做可以在一定程度上保证主库的高可用,在一台主库down掉之后,可以在极短的时间内切换到另一台主库上（尽可能减少主库宕机对业务造成的影响），减少了主从同步给线上主库带来的压力；

但是也有几个不足的地方:

1.masterB可能会一直处于空闲状态（可以用它当从库，负责部分查询）；
2.主库后面提供服务的从库要等masterB先同步完了数据后才能去masterB上去同步数据，这样可能会造成一定程度的同步延时；
架构的简易图如下:

mysql-proxy 实现读写分离
http://blog.51cto.com/zzclinux/1980487

mysql-proxy类似的产品有：
mycat 基于阿里的开源软件cobar，官网 www.mycat.io
https://my.oschina.net/ruoli/blog/1789370

mycat实现分库分表
https://www.cnblogs.com/joylee/p/7513038.html

atlas 出自于360，不维护不更新了 https://blog.csdn.net/AnPHPer/article/details/80566385

mysql环形主从
http://ask.apelearn.com/question/11437

mysql架构演变 http://www.aminglinux.com/bbs/thread-8025-1-1.html

MHA架构
http://blog.51cto.com/xiaoshuaigege/2060768
比较复杂的mysql集群架构 http://ask.apelearn.com/question/17026