升级到SQL Server 2012

系统升级日记（1）- 升级到SQL Server 2012 最近一段时间在公司忙于将各类系统进行升级，其最主要的目标有两个，一个是将TFS2010升级到TFS2013，另外一个是将SharePoint 2010升级到SharePoint 2013。本记录旨在记录升级过程中的一般性准备工作及在升级中可能

系统升级日记（1）- 升级到SQL Server 2012

　　最近一段时间在公司忙于将各类系统进行升级，其最主要的目标有两个，一个是将TFS2010升级到TFS2013，另外一个是将SharePoint 2010升级到SharePoint 2013。本记录旨在记录升级过程中的一般性准备工作及在升级中可能存在的各种坑的解决方案。本记录会大量引用外部文章来作为解释说明，并不是一个step by step的指引，本文章并不适合小白用户而适合具有一定IT管理经验的人阅读。另外本文也并不保证完全正确。

 

第一篇：SQL Server 2012的群集安装

1. 基本的拓扑结构描述

存储环境：

　　我司具有两个计算机机房，一个主机房和一个备机房，两个机房相隔40公里通过裸光纤连接，在8K数据包的情况下裸光纤的延迟在4毫秒。对存储本身进行了群集，当往主机房存储写入的时候会实时同步到备份机房。

云环境：

      办公网使用Windows Server 2012 Hyper-V搭建了云服务，Hyper-V本身做了群集，虚拟机放在存储上，这样可以保证虚拟机在几十秒内能够从主机房移动到备机房。

整个网络以高可用性为主，以保证在遇到主机房完全损毁时可以无损的迁移到备机房。

2. 现在的SQL Server 2008 R2环境

    现在的SQL Server 2008 R2放于一台相对强悍的物理服务器上，并且未作群集，上面承载了所有SharePoint站点数据库、TFS数据库及其它几个小型业务系统数据库。

3. 升级所要考虑的问题

环境：

     Windows Server 2012 R2 + SQL Server 2012

高可用性：

     考虑到原先在一台物理服务器上，并且数据都存在本机磁盘上，可靠性太差。所以这次需要考虑高可用性方案，总结为两点：

为什么选择故障转移群集？

         对于SQL Server来说，提供了3种方式的高可用性，大致总结为：

         1：镜像(Mirror)，特点是存储为两份，主节点可读写，备节点不可读写。镜像实际上通过事务日志传递来实现两份数据同步。当主节点失效后，会立即启用备节点。Windows Server不需要做群集。从SQL Server 2005就开始支持，并且使用SQL Server标准版即可。关于此种方式更详细的介绍请参考：

         2：Always on(AlwaysOn Failover Cluster Instances)，特点是存储为两份，主节点可读写，备节点可读。Windows Server必须做群集。这个特性是SQL Server 2012才开始支持的。具体可以参考：

         3：故障转移群集(Windows Server Failover Clustering with SQL Server)：特点是存储为一份，主节点可读写，备节点不可读写，当主节点失效后会自动切换到备节点，，而且此操作对于应用程序来说是透明的。Windows Server必须要做群集。具体的可以参 考：

         考虑到我们的存储本身就是群集的，将数据存储两份有些浪费我们的存储资源，所以我们最终选择了第三种方案，也就是故障转移群集。

4. 故障转移群集需要注意的事项

5. 就地升级问题

　　非SQL Server群集不能就地升级到SQL Server群集中，必须要重新安装。

6. 数据迁移

　　数据迁移非常简单，只要将原SQL Server 2008 R2的数据库backup之后，再restore回SQL Server 2012上即可。

 总结：

         相对而言，SQL Server的迁移过程是最简单的，SharePoint才是最折磨人的。当然下一节我会介绍TFS的迁移过程。

posted on