MySQL小型高可用架构(组合)
2016-02-24 13:47
531 查看
一、MySQL
MySQL小型高可用架构
方案:MySQL双主、主从 + Keepalived主从自动切换
服务器资源:两台PC Server
优点:架构简单,节省资源
缺点:无法线性扩展,主从失败之后需要手动恢复主从架构
MySQL中型高可用架构
方案:MMM + MySQL双主 + 多从高可用方案
服务器资源:
1、至少五台PC Server,2台MySQL主库,2台MySQL从库,1台MMM Monitor;
2、1台MMM Monitor选择低配;
3、如果不采用F5作为从库的负载均衡器,可用2台PC SERVER部署LVS或HAProxy+Keepalived组合来代替;
优点:双主热备模式,读写分离,SLAVE集群可线性扩展
缺点:读写分离需要在程序端解决,Master大批量写操作时会产生主从延时
MySQL大型高可用架构
主要思路:中间件+MySQL Sharding
如方案:Cobar等中间件+MySQL技术
图片略。
另外,还分享些MySQL一些主流的高可用架构
1、MySQL双主 + Keepalived主备自动切换方案(上面已有)
2、MySQL主从 + Keepalived主从自动切换方案(上面已有)
3、MMM+MySQL双主 + 多从高可用方案(上面已有)
4、MySQL + Pecemaker(Heartbeat) + DRBD高可用
5、MySQL + RHCS 高可用方案
6、MySQL + Cluser 集群架构
7、Percona Xtradb Cluster 集群高可用性解决方案
8、中间件 + MySQL 大型集群解决方案(上面已提到)
MySQL + Pecemaker(Heartbeat) + DRBD高可用 && MySQL + RHCS 高可用方案
Percona Xtradb Cluster 集群高可用性解决方案
MySQL多机房部署架构参考
二、Oracle
1、Oracle ActiveDataGuard
服务器资源:2台PC Server
1、Oracle自己的容灾系统,数据库完全冗余保护,可跨IDC部署;
2、Oracle 11g 以上版本Standby可Redo模式打开,可作为数据仓库使用,也可以作为备份数据库;
3、可切换,一般会采用手动切换方式。
2、Oracle RAC
服务器资源:至少两台PC Server作为RAC节点,SAN存储一台,
其他资源:光纤网络环境
RAC的特性:
1、高可用性:保证只要有一个存活的节点,就不会断业务,保持业务连续性
2、双机双工:RAC是并行模式工作的,节点间关系是Active对Active,每个节点都能为客户端提供服务
3、易伸缩:RAC的增加、删除节点非常方便
4、高吞吐量:节点数量和吞吐量是正比关系
3、Oracle MAA
方案:RAC+ASM+Standby(RAC)部署
服务器资源:RAC所需要资源*2
其他资源:异地机房
备注:MAA实质上就是RAC+DataGuard的结合体。
Oracle还有很多其他高可用架构,比如结合Oracle Golden Gate做复制等等……
三、MongoDB
MongoDB高可用架构
方案:MongoDB复制集+Sharding分片
服务器资源:
1、9台:6台PC Server作为shared节点,3台作为仲裁节点,三个Mongos和Config各部署在三个Shared节点上,如上图;
2、横向扩展分片,一组分片由3台PC Server构成;
3、仲裁节点服务器不存储实际数据,因此低配即可。
备注:
1、考虑到高可扩展问题,放弃MongoDB主从复制方案;
2、对数据安全要求非常高的业务,每组分片可由5台PC Server构成;
3、建议开发人员结合业务选出最合适的片键。
四、Redis
Redis小型高可用架构
方案:Redis主从复制+Keepalived实现Failover
服务器资源:两台PC Server
优点:架构简单,节省资源
缺点:主从切换有间隔,这期间客户端将收到错误
方案:Redis Sentinel实现Failover
服务器资源:
1、两台PC Server部署Redis,一台Redis Sentinel;
2、Redis可选择一主多从架构;
3、一台Redis Sentinel选择低配。
优点:Redis官方自带HA方案,Redis作者所编写,具备
缺点:发生Failover之后,客户端需要手动更正地址
Redis中型高可用架构
方案:Redis主从+Haproxy负载均衡
服务器资源:至少3台PC Server部署Redis主从,两台PC Server部署Haproxy
优点:读写分离,横向扩展Slave
缺点:Master为单点
Redis大型高可用架构
方案:Twemproxy实现Redis存储分片
服务器资源:至少6台PC Server部署Redis主从,至少3台PC Server部署Twemproxy,2台PC Server部署HAProxy
优点:分片,负载均衡,Redis和Twemproxy都可以横向扩展
缺点:Twemproxy所存在的缺点:
1、Twemproxy节点扩展,原来的数据需要重新处理分布,避免出现找不到key值;
2、扩展Redis节点,数据不会自动均匀分布,而需人工处理。
MySQL小型高可用架构
方案:MySQL双主、主从 + Keepalived主从自动切换
服务器资源:两台PC Server
优点:架构简单,节省资源
缺点:无法线性扩展,主从失败之后需要手动恢复主从架构
MySQL中型高可用架构
方案:MMM + MySQL双主 + 多从高可用方案
服务器资源:
1、至少五台PC Server,2台MySQL主库,2台MySQL从库,1台MMM Monitor;
2、1台MMM Monitor选择低配;
3、如果不采用F5作为从库的负载均衡器,可用2台PC SERVER部署LVS或HAProxy+Keepalived组合来代替;
优点:双主热备模式,读写分离,SLAVE集群可线性扩展
缺点:读写分离需要在程序端解决,Master大批量写操作时会产生主从延时
MySQL大型高可用架构
主要思路:中间件+MySQL Sharding
如方案:Cobar等中间件+MySQL技术
图片略。
另外,还分享些MySQL一些主流的高可用架构
1、MySQL双主 + Keepalived主备自动切换方案(上面已有)
2、MySQL主从 + Keepalived主从自动切换方案(上面已有)
3、MMM+MySQL双主 + 多从高可用方案(上面已有)
4、MySQL + Pecemaker(Heartbeat) + DRBD高可用
5、MySQL + RHCS 高可用方案
6、MySQL + Cluser 集群架构
7、Percona Xtradb Cluster 集群高可用性解决方案
8、中间件 + MySQL 大型集群解决方案(上面已提到)
MySQL + Pecemaker(Heartbeat) + DRBD高可用 && MySQL + RHCS 高可用方案
Percona Xtradb Cluster 集群高可用性解决方案
MySQL多机房部署架构参考
二、Oracle
1、Oracle ActiveDataGuard
服务器资源:2台PC Server
1、Oracle自己的容灾系统,数据库完全冗余保护,可跨IDC部署;
2、Oracle 11g 以上版本Standby可Redo模式打开,可作为数据仓库使用,也可以作为备份数据库;
3、可切换,一般会采用手动切换方式。
2、Oracle RAC
服务器资源:至少两台PC Server作为RAC节点,SAN存储一台,
其他资源:光纤网络环境
RAC的特性:
1、高可用性:保证只要有一个存活的节点,就不会断业务,保持业务连续性
2、双机双工:RAC是并行模式工作的,节点间关系是Active对Active,每个节点都能为客户端提供服务
3、易伸缩:RAC的增加、删除节点非常方便
4、高吞吐量:节点数量和吞吐量是正比关系
3、Oracle MAA
方案:RAC+ASM+Standby(RAC)部署
服务器资源:RAC所需要资源*2
其他资源:异地机房
备注:MAA实质上就是RAC+DataGuard的结合体。
Oracle还有很多其他高可用架构,比如结合Oracle Golden Gate做复制等等……
三、MongoDB
MongoDB高可用架构
方案:MongoDB复制集+Sharding分片
服务器资源:
1、9台:6台PC Server作为shared节点,3台作为仲裁节点,三个Mongos和Config各部署在三个Shared节点上,如上图;
2、横向扩展分片,一组分片由3台PC Server构成;
3、仲裁节点服务器不存储实际数据,因此低配即可。
备注:
1、考虑到高可扩展问题,放弃MongoDB主从复制方案;
2、对数据安全要求非常高的业务,每组分片可由5台PC Server构成;
3、建议开发人员结合业务选出最合适的片键。
四、Redis
Redis小型高可用架构
方案:Redis主从复制+Keepalived实现Failover
服务器资源:两台PC Server
优点:架构简单,节省资源
缺点:主从切换有间隔,这期间客户端将收到错误
方案:Redis Sentinel实现Failover
服务器资源:
1、两台PC Server部署Redis,一台Redis Sentinel;
2、Redis可选择一主多从架构;
3、一台Redis Sentinel选择低配。
优点:Redis官方自带HA方案,Redis作者所编写,具备
缺点:发生Failover之后,客户端需要手动更正地址
Redis中型高可用架构
方案:Redis主从+Haproxy负载均衡
服务器资源:至少3台PC Server部署Redis主从,两台PC Server部署Haproxy
优点:读写分离,横向扩展Slave
缺点:Master为单点
Redis大型高可用架构
方案:Twemproxy实现Redis存储分片
服务器资源:至少6台PC Server部署Redis主从,至少3台PC Server部署Twemproxy,2台PC Server部署HAProxy
优点:分片,负载均衡,Redis和Twemproxy都可以横向扩展
缺点:Twemproxy所存在的缺点:
1、Twemproxy节点扩展,原来的数据需要重新处理分布,避免出现找不到key值;
2、扩展Redis节点,数据不会自动均匀分布,而需人工处理。
相关文章推荐
- mysql基于RHCS、Gtid主从复制的高性能、LB、HA集群架构
- MySQL + KeepAlived + LVS 单点写入主主同步高可用架构
- LoadRunner监控mysql利器-SiteScope(转)
- PL/SQL developer连接oracle出现“ORA-12154:TNS:could not resolve the connect identifier specified”问题的解决
- sql2008 在创建维护计划时出现错误:属性 ErrorLogFile 不可用于....的解决方法
- 使用zabbix 2.4 监控mysql----自带模板
- PL/SQL Developer中汉字显示乱码问题
- .Net架构设计设计(三)SqlServer集群搭建
- SQL Server代理(11/12):维护计划作业
- MYSQL-- 每半月一个分区,自动维护 (顶)
- sql文件导入时报错2006 – MySQL server has gone away
- 使用pgpool-ii 搭建postgresql 高可用、负载均衡架构
- MySQL 高可用架构在业务层面细化分析研究
- mysql常用监控脚本命令整理
- Oracle12c64位下使用PL/SQLDeveloper的解决办法
- MySQL server has gone away报错原因分析/
- 【转】MySQL 高可用架构在业务层面的分析研究
- Ubuntu14.04 系统下Django配置使用Postgresql数据库配置
- MySQL中TPS和QPS的计算方式
- mysql error code 1153:Got a packet bigger than ‘max_allowed_packet’