Mysql之高可用

使用缓存Memcache,

  1,可使用Hash算法由客户端决定路由到哪个Memcache服务器上;客户端完全不用关心数据存储在哪个Memcache服务器上;完全隔离了客户端与服务端;由于是Hash,在数组中查找,选择到指定Memcache服务器非常迅速;

前提:维持固定数量的Memcache服务器数不变,总会正确地选择Memcache服务器,拿到正确的缓存数据。

事实上,随着业务的发展,Memcache服务器的数量总是在增加,如果只是简单的Hash%Memcache数来选择指定的缓存服务器,每多增加一台Memcache服务器都会导致更高的缓存失败率。

IMPORTANT:   分布式缓存设计核心点:在设计分布式cache系统的时候,我们需要让key的分布均衡,并且在增加cache server后,cache的迁移做到最少。

为了解决这种问题,有两种方案:consistent[一致性hash]和modula

一致性hash算法ketama的做法是:选择具体的机器节点不在只依赖需要缓存数据key的hash本身了,而机器节点本身也进行了hash运算。

关于一致性hash算法ketama的相关介绍,可参考:http://blog.csdn.net/kongqz/article/details/6695417

http://blog.csdn.net/sparkliang/article/details/5279393

时间: 2024-10-13 00:14:40

Mysql之高可用的相关文章

CoroSync + Drbd + MySQL 实现MySQL的高可用集群

Corosync + DRBD + MySQL 构建高可用MySQL集群 节点规划: node1.huhu.com172.16.100.103 node2.huhu.com172.16.100.104 资源名称规划 资源名称:可以是除了空白字符外的任意ACSII码字符 DRBD设备:在双节点上,此DRBD设备文件,一般为/dev/drbdN,主设备号147 磁盘:在双方节点上,各自提供存储设备 网络配置:双方数据同步所使用的网络属性 DRBD从Linux内核2.6.33起已经整合进内核 1.配置

mysql复制(高可用架构方案的基础)

mysql复制:把一个数据库实例上所有改变复制到另外一个数据库库服务器实例的过程特点:1.没有改变就无所谓复制 ;改变是复制的根本与数据源2.所有的改变:是指可以复制全部改变,也可以复制部分改变 可以在全部改变中根据业务需求选择部分库和部分表的复制复制的场景: 1.数据库容灾 2.需求:创建一个从数据服务器,做数据的测试和分析 3.负载均衡 4.复制时高可用架构方案的基础 mysql高可用架构特点1.数据库故障的检测与排除2.主从数据库的切换3.数据的备份和保护 mysql高可用架构常用方案1.

基于keepalived搭建MySQL的高可用集群

http://www.cnblogs.com/ivictor/p/5522383.html 基于keepalived搭建MySQL的高可用集群 MySQL的高可用方案一般有如下几种: keepalived+双主,MHA,MMM,Heartbeat+DRBD,PXC,Galera Cluster 比较常用的是keepalived+双主,MHA和PXC. 对于小公司,一般推荐使用keepalived+双主,简单. 下面来部署一下 配置环境: 角色                          

corosync+pacemaker+mysql+drbd 实现mysql的高可用

corosync corosync的由来是源于一个Openais的项目,是Openais的一个子 项目,可以实现HA心跳信息传输的功能,是众多实现HA集群软件中之一,heartbeat与corosync是流行的Messaging Layer (集群信息层)工具.而corosync是一个新兴的软件,相比Heartbeat这款很老很成熟的软件,corosync与Heartbeat各有优势,博主就不在这里比较之间的优势了,corosync相对于Heartbeat只能说现在比较流行. pacemaker

搭建MySQL MHA高可用

本文内容参考:http://www.ttlsa.com/mysql/step-one-by-one-deploy-mysql-mha-cluster/ MySQL MHA 高可用集群 环境: Linux: centos 6.6 MySQL: 5.5.49 MHA: mha4mysql-manager-0.56-0.el6.noarch.rpm(管理端) 以及 mha4mysql-node-0.56-0.el6.noarch.rpm(节点) 192.168.178.128 MySQL主从环境: M

Heartbeat+Drbd+Mysql主从高可用实现

在上一篇中已经实现了MySQL服务的高可用,MySQL的数据目录放在drbd的共享目录中,并且只有获取到heartbeat资源的VIP才能挂载共享目录,从而启动MySQL服务,但是两端的数据使用drbd同步,保证发生故障时,服务和资源能够从一个节点切换到另外一个节点,下面是一个简略的架构图: 对于MySQL服务,一般在生产环境中都要做主从结构,从而保证数据的完整性,所以这次要在这个架构的前提下,在两个heartbeat节点下再部署一台MySQL从库,而主库是heartbeat集群中的一台(主库的

分布式数据存储 - MySQL主从复制高可用方案

前面几篇文章说道MySQL数据库的高可用方案主从复制.主从复制的延迟产生原因.延迟检测及延迟解决方案(并未从根本上解决),这种主从复制方案保证数据的冗余的同时可以做读写分离来分担系统压力但是并非是高可用方案,因为主从节点中主节点仍然是单点的,一旦主节点宕机会导致应用中写失败.双主复制虽然很好的避免主节点的单点故障,但是未提供统一访问入口来实现负载均衡,如果其中master宕掉的话需要手动切换到另外一个master,而不能自动进行切换.本篇文章就来剖析主从复制的高可用. 一.基础概念介绍 Keep

heartbeat V2实现MySQL+NFS高可用

heartbeatV2实现MySQL+NFS高可用  实验前准备 1.时间需要同步,建议使用NTP服务器同步时间并且创建时间同步计划   #ntpdate 172.16.0.1  //第一个节点   #ntpdate 172.16.0.1  //第二个节点   crontab  -e     */3 * * * *  /usr/sbin/ntpdate 172.16.0.1 > /dev/null 2.root用户基于密钥认证的时候 ssh-keygen -t rsa -P '' //节点一 s

使用drbd结合corosync实现mysql的高可用集群服务

DRBD:Distributed Replicated Block Dvice 分布式复制块设备,它可以将两个主机的硬盘或者分区做成镜像设备,类似于RAID1的原理,只不过它会将主节点的数据主动通过网络同步到从节点做成镜像,当主节点发生故障,让从节点成为主节点,因为是镜像设备,所以数据不会丢失.corosync在这里的作用就是将drbd通过pacemaker做成高可用服务的资源,以便于主从节点间的自动切换.drbd由于使用各节点之间自身的硬盘设备,因此对于需要共享存储的场景不失为一种节约成本的解

技术实战:基于 MHA 方式实现 MySQL 的高可用(转)

转自:http://os.51cto.com/art/201307/401702_all.htm MHA故障转移可以很好的帮我们解决从库数据的一致性问题,同时最大化挽回故障发生后的数据.本文分享了基于 MHA 方式实现 Mysql 的高可用的技术实战,希望对您有所帮助. AD:51CTO网+ 首届中国APP创新评选大赛火热招募中…… 数据的重要性对于人们来说重要程度不说自明,在信息时代,数据有着比人们更大的力量,我们也知道最近的斯诺登事件,军事专家对于他掌握的数据给出的评价是,相当于美军十个重装