sqlserver2008集群

① 做开发的朋友们，sqlServer大家都用什么版本

各版本功能对比

从我最开始接触的SQL SERVER 2000 开始，已经经历了如此多的版本。下面简单阐述下各个版本新增的功能：
SQL SERVER 2000
日志传送
索引视图

SQL SERVER 2005
分区
数据库镜像
（只有 SQL Server 2005 Enterprise Edition SP1 和更高版本支持异步数据库镜像。）
联机索引
数据库快照
复制
故障转移群集
SQL SERVER 2008

数据压缩
资源调控器
备份压缩

SQL SERVER 2008 R2

R2标志表示这是SQL Server的一个中间版本，而不是一个主版本 .此版本目前我的客户中，使用还是非常多，性能稳定，虽然新增功能比较少：
新增数据中心版，最大支持256核.
Unicode压缩
(为Unicode存储提供一个简单的压缩方案，通过Unicode压缩，可以减少Unicode字符对空间的占用)

SQL SERVER 2012

AlwaysOn
Columnstore 索引
增强的审计功能
大数据支持

SQL SERVER 2014
这个版本的新特效特别多，和非常有用，可以多了解下.

内存优化表
备份加密
针对基数估计的新设计
AlwaysOn 增强功能
延迟持续性 （将部分或所有事务指定为延迟持久事务，从而能够缩短延迟）
分区切换和索引生成
(官网写得Partition Switching and Indexing，感觉是有问题的，其实就是分区表的单个分区可以重建)
列存储索引
缓冲池扩展 就是使用SSD 扩展缓冲池
增量统计信息
资源调控器增强功能
（--之前只能控制CPU和内存，2014 开始可以控制IO）
DBCC CHECK 支持maxdop 提示

SQL SERVER 2016

全程加密技术(Always Encrypted)
JSON支持
多TempDB数据库文件
（以前也是支持的，在2014 开始就在error log提示,2016中，在安装时就可以设置。）
Query Store
（前几天去参加微软的培训还讲到的，挺不错的功能。可以帮助解决参数嗅探的问题，数据库升级的时候也可以用到它）
支持R语言
Live Quer y St at ist ics
（可以更清晰的看到执行计划的开销（水流式））

SQL SERVER 2017
可恢复的在线索引重建
允许您在发生故障（例如故障切换到副本或磁盘空间不足）之后恢复在线索引重建操作。
IDENTITY_CACHE option
当此选项设置为OFF时，它可以避免在服务器意外重新启动或故障切换到辅助服务器的情况下，标识列值的间隙
CLR在.NET Framework中使用代码访问安全性（CAS），该框架不再支持安全边界。
使用PERMISSION_SET = SAFE创建的CLR程序集可能能够访问外部系统资源，调用非托管代码并获取sysadmin权限
图表数据库功能
用于多对多关系建模
Read-scale availability groups without cluster
可以在不依赖集群的情况下，搭建读的可用性组，分担读压力。不过此时不能实现高可用。
R/PYTHON 机器学习方面的功能

总结
总的来说,SQL SERVER 正在变得越来越好，希望越来越多的人更多的了解他.如果有什么其他疑问欢迎讨论。

② windows2008+sqlserver2008搭建集群，故障转移集群服务器，点击存储，添加磁盘上，无法找到适用于群集磁盘

呵呵，深奥啊，我自己说说一起探讨一下，我认为是3快硬盘安装或加载的不符合群集磁盘的要求，没有按照群集磁盘的要求来添加磁盘，你看看要把磁盘也添加到群集磁盘阵列中，应该怎么操作，大家共同研究研究。

③ SQLSERVER怎么搭建服务器集群实现负载均衡

很多组织机构慢慢的在不同的服务器和地点部署SQL Server数据库——为各种应用和目的——开始考虑通过SQL Server集群的方式来合并。

将SQL Server实例和数据库合并到一个中心的地点可以减低成本，尤其是维护和软硬件许可证。此外，在合并之后，可以减低所需机器的数量，这些机器就可以用于备用。

当寻找一个备用，比如高可用性的环境，企业常常决定部署Microsoft的集群架构。我常常被问到小的集群(由较少的节点组成)SQL Server实例和作为中心解决方案的大的集群哪一种更好。在我们比较了这两个集群架构之后，我让你们自己做决定。

什么是Microsoft集群服务器

MSCS是一个Windows Server企业版中的内建功能。这个软件支持两个或者更多服务器节点连接起来形成一个“集群”，来获得更高的可用性和对数据和应用更简便的管理。MSCS可以自动的检查到服务器或者应用的失效，并从中恢复。你也可以使用它来(手动)移动服务器之间的负载来平衡利用率以及无需停机时间来调度计划中的维护任务。

这种集群设计使用软件“心跳”来检测应用或者服务器的失效。在服务器失效的事件中，它会自动将资源(比如磁盘和IP地址)的所有权从失效的服务器转移到活动的服务器。注意还有方法可以保持心跳连接的更高的可用性，比如站点全面失效的情况下。

MSCS不要求在客户计算机上安装任何特殊软件，因此用户在灾难恢复的经历依赖于客户-服务器应用中客户一方的本质。客户的重新连接常常是透明的，因为MSCS在相同的IP地址上重启应用、文件共享等等。进一步，为了灾难恢复，集群的节点可以处于分离的、遥远的地点。

在集群服务器上的SQL Server

SQL Server 2000可以配置为最多4个节点的集群，而SQL Server 2005可以配置为最多8个节点的集群。当一个SQL Server实例被配置为集群之后，它的磁盘资源、IP地址和服务就形成了集群组来实现灾难恢复。

SQL Server 2000允许在一个集群上安装16个实例。根据在线帮助，“SQL Server 2005在一个服务器或者处理器上可以支持最多50个SQL Server实例，”但是，“只能使用25个硬盘驱动器符，因此如果你需要更多的实例，那么需要预先规划。”

注意SQL Server实例的灾难恢复阶段是指SQL Server服务开始所需要的时间，这可能从几秒钟到几分钟。如果你需要更高的可用性，考虑使用其他的方法，比如log shipping和数据库镜像。

单个的大的SQL Server集群还是小的集群

下面是大的、由更多的节点组成的集群的优点：

◆更高的可用新(更多的节点来灾难恢复)。

◆更多的负载均衡选择(更多的节点)。

◆更低廉的维护成本。

◆增长的敏捷性。多达4个或者8个节点，依赖于SQL版本。

◆增强的管理性和简化环境(需要管理的少了)。

◆更少的停机时间(灾难恢复更多的选择)。

◆灾难恢复性能不受集群中的节点数目影响。

下面是单个大的集群的缺点：

◆集群节点数目有限(如果需要第9个节点怎么办)。

◆在集群中SQL实例数目有限。

◆没有对失效的防护——如果磁盘阵列失效了，就不会发生灾难恢复。

◆使用灾难恢复集群，无法在数据库级别或者数据库对象级别，比如表，创建灾难恢复集群。

虚拟化和集群

虚拟机也可以参与到集群中，虚拟和物理机器可以集群在一起，不会发生问题。SQL Server实例可以在虚拟机上，但是性能可能会受用影响，这依赖于实例所消耗的资源。在虚拟机上安装SQL Server实例之前，你需要进行压力测试来验证它是否可以承受必要的负载。

在这种灵活的架构中，如果虚拟机和物理机器集群在一起，你可以在虚拟机和物理机器之间对SQL Server进行负载均衡。比如，使用虚拟机上的SQL Server实例开发应用。然后在你需要对开发实例进行压力测试的时候，将它灾难恢复到集群中更强的物理机器上。

集群服务器可以用于SQL Server的高可用性、灾难恢复、可扩展性和负载均衡。单个更大的、由更多的节点组成的集群往往比小的、只有少数节点的集群更好。大个集群允许更灵活环境，为了负载均衡和维护，实例可以从一个节点移动到另外的节点。

④ 如何实现mssql数据库负载均衡

SQL Server 负载均衡集群
一个应用系统随着业务量的提高,以及访问量和数据流量的快速增长，各个核心部分的处理性能和计算强度也相应增大，使得单一设备根本无法承担。在此情况下，如果扔掉现有设备去做大量的硬件升级，必将造成现有资源的浪费，而且下一次业务量的提升，又将导致再一次硬件升级的高额成本投入。于是，负载均衡机制应运而生。 对于应用系统的负载均衡的硬件和软件比比皆是，因为应用服务器上的程序基本上认为是不变化的，而且一般的各个应用服务器上的程序是不交互的。因此应用服务器的负载均衡非常好做，只需要能够进行分流的软件或者硬件把多个客户端的连接分配到多个应用服务器上去即可。
因为数据库内的数据是频繁变化的，为了数据的一致性以及锁资源的分配协调等，所以像应用服务器那样只有分流是不够的，各个节点需要频繁的交互。这也是数据库集群软件难做的原因，当然也是卖的贵的原因了。

Oracle Real Application Clusters
对于数据库负载均衡，大家最为耳熟能详的就是Oracle RAC了。RAC是双机并行服务器(8i及以前版本称作Oracle Parallel Server，OPS)，用来在集群环境下实现多机共享数据库，以保证应用的高可用性，同时可以自动实现并行处理及均分负载，还能实现数据库在故障时的排错和无断点恢复。它可以自动进行负载平衡、故障修复和规划停机时间，以支持高可用性应用程序。若并行服务器中某节点失效，透明的应用程序容错能够把用户自动转接到另一节点上继续运行，应用程序在用户没有察觉的情况下继续执行。这使周期性和非周期性发生故障的系统增大了连续可用性。进程的失效可以完全透明地转移到另一节点上去，通过适当地配置，可以指定所有查询都在客户端进行缓存，这样它们便可以在转移后的节点上重新设置。
Moebius for SQL Server
截至到SQL Server 2008，微软还是没有推出负载均衡组件，只能靠第三方软件来实现，好在这个软件是几个从微软出来的人写的，也算是个小小的巧合。说他们是微软出来的并不是说他们的技术多厉害，而是他们利用SQL Server的一些内部接口把集群做的非常透明， 无论是应用程序的调用还是开发/管理人员的使用都和面对一个数据库一样。
他们的实现原理是这样的：和SQL Server镜像一样，每个数据库节点都有自己的数据，也就是无共享磁盘架构。他们称之为“中间件”的程序宿主在数据库的内部，每个节点数据库上写入数据导致数据变化时，SQL Server会激活“中间件”，“中间件”把变化的数据同步到其他的节点上。其他节点发生变化也是一样。因为“中间件”宿主在数据库内， 所以它能够把每个同步的Session和SQL Server的Session绑定到一起，也就是使用户的执行和数据的同步成为一个原子操作，从而保证数据在每时每刻都是一致的。因此查询可以随便到每个机器上去查，从而做到了真正的负载均衡。
这是一种叫"数据库路由器"的技术,这种技术的特点是灵活性好,但效率比RAC要低，毕竟RAC是在引擎里实现的不管怎么样有比没有强!

⑤ 简述mysql该怎样进行集群部署

mysql集群部署操作如下：
1、在MySQL集群中.当table引擎为NDBCLUSTER时才做集群，其他非NDBCLUSTER表和一般MySQL数据库表一样，不会共享数据。NDBCLUSTER表数据存储在Data node服务器内存中，Data Node可以为1台或多台服务器，它们之间存放共享数据。Data Node服务器可以分组数据。
例如：2,3,4,5为四台Data Node服务器ID. 2,3为组0； 4，5为组1； 2，3维持数据相同，4，5维持数据相同。 组0和组1维持数据不同。
2、sql node服务器中，非NDBCLUSTER数据存在本身数据库中，table引擎为NDBCLUSTER时，数据存储在Data Node中。当查询NDBCLUSTER表时，它会从Data node集群中提起数据.
3、Manager server管理SQl node和Data node状态。