alwaysOn+SQL群集+cluster 高可用方案测试

在SQL2012以前,高可用自动切换方案就是SQL群集了,优点就是切换完全自动,缺点也有很多,

然后2012出现了alwaysOn特性,在高可用上有了很大的提升,今天这个测试是将2个特性结合在一起做一个高可用的方案。

这个方案的优点就是数据上,主数据只有一份,而且不受alwaysOn节点数限制,缺点就是切换时间比alwaysOn本身的要长一些。

准备很简单,AD1台 测试足够。

然后先准备2台服务器,做cluster,注意第3台要做alwaysOn副本的机器千万不要现在加入cluster,

然后安装SQL群集,这个也很简单,照做就OK,对外给一个SQL2014的SQL群集,

然后把要做alwaysOn副本的机器先装SQL server,然后再加入cluster。

就是我这里的win2008C。

然后在SQL2014里做alwaysOn,也很简单,我添加的副本是非同步的。

在节点WIN2008A里也能看到2个服务,一个SQL群集的,一个alwaysOn的。

然后重启WIN2008A的SQL服务,测试转移情况。

自动整体迁移到了win2008B上,整个测试完成。

这个方案只是一个想法,平时估计不会有人用到这样的方案来实施。

然后幻想一下以后是否会变成,alwaysOn对外做一个sharding分片区,每个SQL群集做一个分片,

这样就完美了....

alwaysOn+SQL群集+cluster 高可用方案测试,码迷,mamicode.com

时间: 2024-10-22 12:58:22

alwaysOn+SQL群集+cluster 高可用方案测试的相关文章

SQL Server 高可用方案

方案一:Asynchronous Mirror + Alias 方案介绍 数据库服务器配置异步镜像关系,程序客户端连接串配置别名连接. 1. 在SQL Server客户端配置中创建别名,在客户端的连接串设置中用别名代替服务器名或IP地址. 2. 写一个实用程序,在镜像角色切换的时候,更新别名. 3. 更新别名可通过修改相应的注册表字符串来完成,位于HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSSQLServer\Client\ConnectTo 方案优缺点 优点

MYSQL数据库高可用方案探究

MySQL作为最关键的应用数据存储中心,如何保证MySQL服务的可靠性和持续性,是我们不得不细致考虑的一个问题.当master宕机的时候,我们如何保证数据尽可能的不丢失,如何保证快速的获知master宕机并进行相应的故障转移处理,都需要仔细考虑与规划. 要保证MySQL数据不丢失,replication是一个很好的解决方案,而MySQL提供了一套强大的replication机制,replication能极大地提升数据安全,异步复制的方式也保证了sql读写性能不受太大影响.在大量企业长期的使用和实

基于Sentinel的Redis高可用方案

数据存储我们在应用设计过程中非常重要的一部分,无论是关系型数据库,还是Redis.MongoDB等非关系型数据库,都有很多的高可用方案,还有一些针对不同业务设计的中间件,使其性能更有特色,更能保证数据存储的稳定和安全. 目前主流的Redis的数据存储架构有Redis单点,Redis主从,基于Sentinel的Redis主备.基于keepalive的redis主备,以及Redis集群Cluster,还有豌豆荚开源的Codis等是目前业内比较流行的解决方案,不同的存储架构,是若干个技术工程师,根据自

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

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

MySQL高可用方案MHA自动Failover与手动Failover的实践及原理

集群信息 角色                             IP地址                 ServerID      类型 Master                         192.168.244.10   1                 写入 Candicate master          192.168.244.20   2                 读 Slave                           192.168.244.

BizTalk Server 2010高可用方案

BizTalk Server 2010高可用方案 本文介绍了 Microsoft BizTalk Server 中通过对主机的各层进行扩展提供高可用性的方案. 分隔各个区域的功能分为不同的主机和中的层 BizTalk Server, ,管理员可以为每个主机提供冗余和缩放它们独立于其他主机. 若要为每个功能区域提供高可用性,应创建单独的主机,为每个主函数-接收. 处理. 发送和跟踪-和群集 BizTalk Server 数据库和企业单一登录的主密钥服务器. 小型 BizTalk Server 部署

Heartbeat+DRBD+MySQL高可用方案【转】

转自Heartbeat+DRBD+MySQL高可用方案 - yayun - 博客园 http://www.cnblogs.com/gomysql/p/3674030.html 1.方案简介 本方案采用Heartbeat双机热备软件来保证数据库的高稳定性和连续性,数据的一致性由DRBD这个工具来保证.默认情况下只有一台mysql在工作,当主mysql服务器出现问题后,系统将自动切换到备机上继续提供服务,当主数据库修复完毕,又将服务切回继续由主mysql提供服务. 2.方案优缺点 优点:安全性高.稳

centos7.5部署heartbeat+DRBD+mysql高可用方案

做双机热备方案需要用到Hearbeat和存储设备(如果没存储设备,可以用DRBD代替,但是最好用存储设备). Heartbeat:如果热备服务器在规定的时间内没有收到主服务器心跳消息那么热备服务器会认为主服务器宕机了,热备服务器就开始工作启动IP.服务等也就是启动故障转移程序.启动故障转移程序的同时并取得主服务器上相关资源服务的控制权,接替主服务器继续不间断的提供服务,从而达到资源及服务高可用性的目的. DRBD(代替存储设备):Distributed Replicated Block Devi

Mha-Atlas-MySQL高可用方案实践。

Mha-Atlas-MySQL高可用方案实践(一) Mha-Atlas-MySQL高可用方案实践 一,mysql-mha环境准备 1.1 实验环境: 1.2 软件包 用到得所有包 链接:https://pan.baidu.com/s/19tiKXNEW4C6oWi9OFmcDYA 提取码:be07 1) mha管理节点安装包: mha4mysql-manager-0.56-0.el6.noarch.rpm mha4mysql-manager-0.56.tar.gz 2) mha node数据节点