SQL Server高可用的常见问题分析
(编辑:jimmy 日期: 2024/12/29 浏览:3 次 )
每次谈到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还没有这么多的功能和组件。
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还没有这么多的功能和组件。
下一篇:jdbc连接sql server数据库问题分析