快乐学习
前程无忧、中华英才非你莫属!

Day8-MySQL架构实战(MHA)–高级篇(故障处理)

一、前言

我突然发现,由于业务、网络的复杂性会让主从架构出现各种棘手的问题。

Slave_SQL_Running: No   mysql同步故障,遇到过很多次!

初步解决方案只能跳过错误了:

stop slave;

set global sql_slave_skip_counter=1;

start slave;

Slave_IO_Running: No

stop slave;

reset slave all;

CHANGE MASTER TO MASTER_HOST='192.168.1.60',MASTER_USER='repl',MASTER_PASSWORD='123456',MASTER_LOG_FILE='mysql-bin.000012',MASTER_LOG_POS=107;

start slave;

show slave status;

      

如果出现故障可以参考如下两篇文章

http://storysky.blog.51cto.com/628458/259280/

http://www.jb51.net/article/109107.htm

1、在slave机器上设置只读权限并且关闭自动清除执行完的中继日志relay log

将以下参数加入my.cnf里:

[mysqld]

read_only = 1

relay_log_purge = 0

注:设置read_only只读模式的目的是防止slave上被人工误写入数据,保证主从数据一致性。

   关闭自动清除执行完的中继日志relay log的目的是假如一台从库没有接受完主库的binlog,通过MHA把最新的slave上的中继日志发送到最老的slave上,识别差异中继日志并补齐数据。

我们可以通过定时任务,写入crontab里,例如每天凌晨5点清除一下relay log,那么可以这样:

安装:

CentOS系统安装crontab:

[root@CentOS ~]# yum install crontabs

定时清理中继日志,

# crontab -l  0 5 * * * /usr/local/mysql/bin/mysql -S /tmp/mysql.sock -uroot -pzhangtongle123 -e "set global relay_log_purge = 1;flush logs;set global relay_log_purge = 0;flush logs;"

———————————————————————————————————————–

二、数据库进化

1、淘宝数据库初创

2、开始进化

3、进化历程

4、大多数公司的架构

5、读写分离架构实现 

经过性能的基准测试,HaProxy,性能最好,其次MaxxScale 然后是OneProxy、

个人总结:MaxScale,非常灵活,可扩展性强,分库分表不是很成熟,不久的将来应该会很nb。服务要收费,说明人家做的好,才做服务收费!

 

最重要的问题!只要做集群,主从复制是核心,如果解决在业务高峰期,延迟的问题才是王道~。

保证集群秒级别数据同步!看了一下MySQL5.5是不支持多线程复制的,比它高的版本已经开启了,做好充足迁移可靠的方案,并且测试稳定的时候,可以考虑升级到最新版本~。。用钱直接上最牛逼的大内存这个可以有~,Mysql也可以玩最新版本,但是你得可控,不可控就不要玩~。,单表数据超过1千万,肯定要把xxx日期的,拆开并存储为归档表做归档标识!不拆不行,索引即使做的再好,前端高并发的select,和小白的各种selcet * ,也会堵你的服务器~, 大表就得进行策略性的拆分!以上是个人总结,不喜勿pen~

三、主从复制易发生的问题

      1.问题一:主从复制,中继日志不断增长,如何设置中继日志自动清除

  vi 配置文件my.cnf,在mysqld下增添

  relay_log_purge=1 (自动清除中继日志打开)

  重启mysql,这样SQL Thread每执行完一个events时才会判断该relay-log是否需要,已经不再需要则自动删除

  2.问题二:主从同步失败,如何快速同步?

  跳过错误,继续同步。设置SQL_slave_skip_counter=1;来快速恢复主从架构,但是此时主从架构的数据可能已经不一致了。 set global sql_slave_skip_counter=N; 当N等于1时,表示跳过若干个event,直到当前事务结束,而当N大于1时,每跳过一个event,都要N–设置–slave-skip- errors=[ err_code1[,err_code2][,all]] 跳过出现指定错误的SQL.如果要断开主从架构,应先stop slave io_thread;等待执行完relay log里的内容再stop slave;

  3.问题三: io线程始终保持为connecting状态

  主从架构中,从库的io_thread一直保持connecting状态。先理解Slave_IO_Running 为connecting,的含义。造成的主要有三个:

  1、网络不通 (是否打开防火墙)

  2、复制用户的密码不对 (主从同步指定的用户密码主机名限制)

  3、pos不对 (指定的position不正确)

  4.主键冲突,报1062错误

  主从架构中,从库复制报1062错误,主键冲突。如果binlog是基于语句级复制,很容易出现上面的问题。设置 innodb_autoincr_lock_mode=0或是1或修改binlog_format=mixed|row

  5.从库同步慢

  主从架构中,从库的同步数据非常慢。出现主从同步慢的原因有:

  1.主从同步延迟与系统时间的关系,查看主从两台机器间系统时间差

  2.主从同步延迟与压力、网络、机器性能的关系,查看从库的io,cpu,mem及网络压力

  3.主从同步延迟与lock锁的关系(myisam表读时会堵塞写),尽量避免使用myisam表。一个实例里面尽量减少数据库的数量。

  6. change master时报错ERROR 1201 (HY000)

  表现:在搭建主从时,报1201错误 。ERROR 1201 (HY000): Could not initialize master info structure; more error messages can be found in the MySQL error log

  解决方法:出现这个问题的原因是之前曾做过主从复制!需要reset slave后再change

打赏

未经允许不得转载:同乐学堂 » Day8-MySQL架构实战(MHA)–高级篇(故障处理)

分享到:更多 ()

评论 1

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址
  1. #1
    小小乐3年前 (2017-05-01)回复

特别的技术,给特别的你!

联系QQ:1071235258QQ群:226134712
error: Sorry,暂时内容不可复制!