注册 登录  
 加关注
查看详情
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

老狗的博客

尽管每一步都很微小,但我确认我在进步

 
 
 

日志

 
 
关于我
sky

认真生活,努力工作 热爱技术,关注DB,存储,分布式,中间层,java,c++,php

mysql 复制结构/ 故障处理 / 丛库之间同步  

2013-03-19 12:00:05|  分类: 默认分类 |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |

一.基本结构
mysql 的基本复制结构就是  一主<master> 多从<slave>, 多个slave从一个master 同步数据

mysql 复制结构/ 故障处理 / 丛库之间同步 - sky - 老狗的博客
 

优点:
1. 数据有多个replicas,  整体数据库系统的整体可用性,得以大大的提高,数据的安全有了大大的保证
2. 读压力可以被多个丛库进行分担,这种结构对于读压力较大的业务的扩展性较强

缺点:
1. 在这里master仍然是单点,master出现故障,会导致系统不可写,对于写的可用性难以得到保证
2. slave和master之间同步数据的方式 是通过日志进行异步的同步,仍然有丢失数据的可能,不能保证数据的完整性
3. slave和master之间的数据不一致,有一点的延迟,而且多个slave之间的延迟不同,多个rplicas之间数据不一致,不能保证数据的一致性
4. master只能有一个,写能力极难得到扩展,通过增加slave个数,扩展数据库的读能力受到 master io/带宽 等的限制,也难以提高,扩展性也有很大的限制


二. 衍伸变换

以以上的结构进行衍伸变换:
1. 扩展读的能力,增加复制的层次

mysql 复制结构/ 故障处理 / 丛库之间同步 - sky - 老狗的博客

缺点:
a.  引入中间层,引入了恢复的复杂性,如果transfer中间层坏掉,且启用了一台新的机器,则transfer为根的这颗子树的数据很可能需要重做,或者重新找同步位置,数据重做

 
2. 扩展读写能力,对数据库做sharding,分为m1,m2

mysql 复制结构/ 故障处理 / 丛库之间同步 - sky - 老狗的博客

缺点:
a. 引入sharding, 则增加了访问的复杂性,则需要提供 路由 机制
b. 引入了跨库事务,跨库查询,增加了 业务的复杂度
 

3. 当然也有可能是以上两者的混合(不再进行图示)

4.  保证数据的完整性
a. 使用存储

mysql 复制结构/ 故障处理 / 丛库之间同步 - sky - 老狗的博客
 
b. 使用同步/半同步复制

mysql 复制结构/ 故障处理 / 丛库之间同步 - sky - 老狗的博客
 
缺点:
(1), 使用以上两种方式,在极端情况下仍然不能保证不丢失数据,只能引入 先写日志的形式 ,如果出现问题,通过日志的形式进行修复

三. 复制控制

1. master的控制命令

(1). reset master
清空master的binlog index文件和binlog文件,master的binlog会再次从0开始
(2). show master status
记录了master binlog的位置

2. slave的控制命令
(1). change master to master_log_file='xx', master_log_pos='xx';
(2). start slave [io_thread|sql_thread] until master_log_file='xx', master_log_pos='xx'
(3). stop slave;
(4). set skip_slave_skip_counter=n;
(5). show slave status\G
(6). reset slave; 已经弃用,请使用change master to 完成切换


四. 故障处理
(1). master 故障,提拔一台slave为master
影响:
a. 在切换期间, 集群将不能提供写服务
步骤如下:
a. 断开业务端到slave1的所有连接,修改业务端配置,将slave1踢出业务端的配置,并打开slave1 read only配置
b. 观察slave1, 复制状态中的sql线程处于执行完毕状态,并执行flush tables命令
c. 在slave1已经打开binlog的状态下,上执行reset master
d. 将所有其他slave指向slave1
e. 观察复制状态ok, 关闭slave1的read only
f. 修改业务端配置,将slave1改为master

(2). slave故障
影响:
a. 本台slave不能提供服务
操作:
将其提出业务端配置即可


(3). transfer机器损坏
影响:
a. 影响以transfer机器为根的机器的复制
操作:
a. 最好的方式是修复transfer机器
b. 其次的方式是如果可以容忍数据丢失,则可以将其直接挂到transfer机器的备机上
c. 如果不能容忍数据丢失,transfer机器又无法修复,则必须将这个分支下的所有机器的数据针对新的master进行重做

五. 容灾方案
1. 考虑机房间的灾备

2. 整体集群的设计要冗余一部分压力,作为备用

3. 如果使用存储等作为方案,则关键零件的备用也是不可缺少的

4. 详细制定各种预案,并且定时演练

六. 细节问题

1. 在一个库中拆表过多可能的影响?
拆表过多,会造成系统文件过多,需要注意的问题:
a. 系统支持的单进程打开文件句柄的限制不够,极端情况inode节点数目也会不够
b. 文件过多,刷新数据的io操作将难以合并,容易造成写操作整体效率的降低
c. innodb的元数据通过innodb additional memory pool进行存放,拆表过大,将增加元数据的数据量,必须保证有足够的内存存放

2. sharding的策略选择?
sharding的策略可以如下选择:
a. 直接取余
b. 按段划分
c. 按位拆分
d. 按照时间拆分

3. 路由层的收敛
a. 路由层的实现可以通过server,也可以通过lib,不管怎么做,有必要将读和写都收敛起来,易于管理
b. configure 信息的管理以及推送

4. db运维的透明化
a. db对外应该 透明化,以一个Ip的形式 提供服务,集群内部实现读写分离,压力均衡
b. db对内的管理也应该简单化,通过服务化的接口提供 failover切换等操作

结论:
如果要用好db,必须跳出db的范畴,从业务端, 中间层, 数据库, ETL层 来看整体db, 从分布式的角度来看待db
  评论这张
 
阅读(134)| 评论(0)
推荐 转载

历史上的今天

在LOFTER的更多文章

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2018