国内好像关注高可用性方面的比较少，其实sql server的Always On,cluster,Replication,database mirror,log shipping配合使用足以满足高可用的需求。
每次谈到SQL Server的高可用，很多的DBA，特别是SQL Server DBA心里一痛：因为大家都认为SQL Server无法或者很难实现SQL Server。也有很多的DBA朋友脑袋一拍，给出答案“高可用不就是微软的那几个技术吗，如Replication, Failover Clustering”…
1.难道SQL Server在高可用上面就显得这么的无力吗？
回答：不是的，其实SQL Server很给力。
2.为什么很多人总是抱怨SQL Server中高可用很难实现呢？
这里从几个方面来说。
首先，就所接触到的很多的项目（欧美居多），这些项目中不乏所谓的海量数据，也有很多的高性能应用，后面采用的都是SQL Server，而且还没有采用第三方的数据库辅助软件。
其次，我们说说人的问题。人都有这样一个习惯：每次出现问题之后，第一反应就是逃避，然后找个好的理由或者替罪羊，最后搞来搞去，就开始怪技术本身不行。这就有点类似，菜鸟用宝刀的时候，杀不死人，不贵本身的能力不行，而是怪刀不好。说到这里，就想到之前的CSDN密码泄露问题，很多人居然大骂微软的技术不行，这让那些已经用微软技术实现高安全的应用的公司看笑话。
再次，以偏概全的概念！很多人以为Replication就是高可用了，于是就一股脑的指望Replication可以解决他们的问题，殊不知：Replication只是实现高可用中的一个重要的组件而已，而不是全部。说到这里，是我想起几个类似误解，“以为JQuery就是ajax技术”，殊不知，jquery只是一个框架，可以用来实现ajax而已。有人认为“架构设计就是设计模式和架构模式的使用”，其实架构设计就是一种思维，而那些模式仅仅只是一个小的手段而已，把架构设计比喻为一个大楼，那些模式充其量就是一些砖头，而不是全部。
同理，Replication也仅仅只是实现高可用中的“一块砖”。
最后，对于技术的掌握程度不够，导致很多人遇到问题时候无法解决。而且也不知道找谁解决，去哪里找等。
3.高可用是用一个软件或者产品就搞定的吗？
这里很多人想到的就是Oracle的RAC，还有一些第三方的产品。不同的产品，封装的程度不一样，有的产品把很多的东西都封装了，只需使用人员学习如何使用工具就OK，不用掌握细节。但是，使用这些产品的时候，在进行部署和操作的时候，实际上就是在按照产品设计人的思想在搭建高可用而已，只是我们认为这个过程是“使用手册”而已。
而SQL Server本身没有提供这样的完全封装的产品，但是高可用设计中需要的重要核心技术和组件都已经有了，“钉子，螺丝，材料”都有了，就看你如何组装起来。
4.高可用仅仅只是数据库技术吗？
实现高可用，不仅仅只是数据库层面上面的内容，其实更多需要的是设计和架构能力。需要知道，软件，硬件，操作系统，网络，数据库等技术。
而且高可用也不是一个具体的技术，而是概念，实现的方法就是千千万。有人说“高可用就是读写分离”，“高可用就是负载均衡”，对吗？用脚趾头都可以回答这些问题。
5.没有万能的产品和万能的方案，一切都是“看情况而定”。
很多人在争论“无共享磁盘（数据库）”好，“水平拆分”好。这些说的直白一点：单独的讨论，没有任何的意义。不把技术用在具体的应用中，不带来经济价值，技术什么都不是。
产品，技术等本身都是有一定的使用范围和局限性的，很多社区的朋友在讨论的时候，总是喜欢一个万能的产品特性，例如，有人说“SQL Server 2012的AlwaysOn”可以实现高可用了。殊不知：技术是人在使用，产品只是我们人在设计中使用的一个零件而已，最后的设计还是看人。早在十多年前，就有很多的公司的大型应用就是采用SQL 2000做的，那时候，SQL Server还没有这么多的功能和组件。如果真的有神器，那就是什么人都会了，技术人员也就没有核心竞争力了，因为使用神器，人人都会！
OK，让我们重新正视高可用，看问题全面一点！另外就是sql server的高可用性应用没有形成一个常规的做法。
喜欢 
顶
难过
囧
围观
无聊
