SQL Server 2012笔记分享-55：高可用知识总结

浏览数：19 / 时间：2015年06月12日

-------------------------------------------------------------------------------------------------------------

故障转移群集

虽然群集的共享存储是单点的，但是从存储层面来看，是配置了存储的冗余的，所以也一定程度上实现了冗余。
在群集模式下，一个SQL群集实例只在一个节点上是活跃的，即同一时刻每个SQL群集实例的服务只在群集中的一个节点上是处于运行的状态 ，所以如果有多个数据库，想把数据库放在不同节点上，实现负载的分离，那么需要为每一个数据库建立单独的实例，在整个SQL Server实例级别提供高可用性的保护，这一点和alwayon不太相同（alwayson是数据库级别的高可用）；
有一些限制：1）对硬件资源的要求，依赖于特定的硬件资源条件，需要共享存储。（共享磁盘可以在存储级别实现冗余）；2）数据库文件只存一份（潜在的单点故障，但是在存储级别还是有很多手段可以保证可用性，例如RAID技术、HBA卡冗余）可以通过群集服务器节点和网络资源的冗余规避服务器硬件、网络、操作系统及SQL Server服务级别的单点故障；
群集中windows网络名称和IP（这个和SQL server没有太大关系）和SQL server网络名称不一样（每装一个SQL实例，就会有一个SQL网络名称）；
Window 2008群集支持四种仲裁机制。1、多数节点（不依赖共享磁盘，必须有一半或以上的节点互联互通，适用于三个以上节点的群集）；2、节点和磁盘多数（除了每个节点具有投票权，仲裁磁盘也有一票，适用于偶数个节点的群集）；3、多数节点和文件共享（用共享文件夹代替共享磁盘，当多个节点不能构成多数的时候，看哪个节点可以访问文件共享，这个节点就会多一票）；4）非多数（仲裁磁盘）这个是看哪个节点拥有仲裁磁盘）；
当SQL加入到群集之后，SQL服务已经由群集接管了；SQL服务作为一种资源存在于群集中，我们停止SQL服务的时候，不能使用服务管理器或配置管理器，而是在群集中使服务资源“脱机”；SQL server服务资源在群集中依赖一块磁盘和SQL网络名称；
使用SQL安装关盘的“维护”向导，可以删除群集的节点，对群集节点进行正常的卸载；
为SQL群集升级补丁的时候，在SQL 2005平台必须在活动节点安装，然后自动更新到被动节点，时间较长，服务有中断；而SQL 2008群集则先陆续安装被动节点，然后再打主动节点；
无论单机实例还是群集实例都支持修改SQL的网络名称，但是不能改实例名称；1）如果是单机实例：改完后要重启机器，而且在SQL中要做一个额外的步骤，可以参考SQL 的联机帮助文档；SQL server的网络名记录在master库的一张系统表中，所以修改完成后，要同步修改表；2）如果是群集实例，直接在群集管理器中进行修改，首先把群集网络名称资源脱机，然后在属性中修改就行了；
SQL Server故障转移群集建立在Windows故障转移群集之上；
多个群集节点分别安装SQL Server服务组件，但互相协同作为一个整体对外提供同一个SQL实例的服务；
一旦实例的当前活动节点发生故障，其他节点上的群集服务自动协商并选择一个新的节点来接管该实例；
SQL群集实例对外使用一个虚拟网络名称 (Virtual Network Name)提供服务，节点间的SQL服务故障转移对客户端是透明的；

-------------------------------------------------------------------------------------------------------------

数据库镜像

两个实例，只能在两个实例之间，不考虑见证的情况下，数据是只有两份；
数据库级别的，以数据库为单位进行镜像；
数据的传输是单向的，永远只能在单点写入；
在单个数据库级别提供高可用性；
不依赖于任何特定的硬件资源条件；
既提供了服务器资源的冗余，又提供了数据的冗余
数据库的故障转移对客户端不是完全透明的
主体和镜像是两个独立的SQL服务实例，有不同的网络标识
镜像数据库不能直接提供数据访问（所有的读写请求只能在主数据库上）
只有在同步模式下，才能使用图形界面进行数据库的切换，如果在异步模式下切换，需要使用SQL语句；
通过在两个SQL Server实例间实时的进行数据变化的传输（利用事务日志信息）来同时提供服务器资源和数据的冗余保护
一旦主体实例 (Principal)上的数据库发生故障，该数据库可以自动或手动的方式切换到镜像实例 (Mirror)上继续提供服务
自动的故障切换需要通过安装第三个见证实例 (Witness)来提供支持
当主体数据库恢复工作后，将自动成为新的镜像数据库并和当前的主体数据库继续进行数据的同步
数据的传输可以使用同步或异步的模式 1）同步模式：无数据损失的风险，但性能影响相对较大； 2）异步模式：有数据损失的风险，但对性能的影响很小。区别在于：如果是同步模式，任何对事务提交的写入动作，写入完成后，并不是立刻确认提交成功，要等待对应的日志在镜像数据库也写入，并确认；异步模式是只要主的写入成功就算成功了，并不等待确认；所以如果是异步模式，可能会有数据丢失；