SQLSERVER怎么搭建服务器集群实现负载均衡(服务器负载均衡如何实现)

市面上存在两种数据库负载均衡的思路：1

基于数据库连接的负载均衡：例如总共有100个数据库连接，50个连接登录到数据库机器A，另外50个连接登录到数据库机器B，这样每个连接中接下来的所有请求全都是发往同一台数据库机器的

这种数据库负载均衡的思路模拟了WEB上的负载均衡方法，但是由于WEB连接是短时间连接(连接建立后，获取需要的HTML等资源后，连接马上被关闭)，而数据库连接是长时间连接(连接建立后，可长时间保持，客户可不停向数据库发送SQL请求，数据库做出回答，如此不断循环直到连接被人为或因错而断开为止)，因此这种数据库负载均衡思路存在着明显的缺点：有可能会发生绝大部分的请求压力都集中到某台数据库机器上去，从而使得负载均衡效果失效

2

基于批处理请求的负载均衡：在建立数据库连接的时候，会同时与每台数据库服务器建立连接，之后针对客户端的每次请求，都会根据负载均衡算法，独立地选出某个数据库节点来执行这个请求

此种思路符合数据库长时间连接的特征，不存在上面所述的基于连接的负载均衡方法的缺点

市面上的负载均衡厂商，既有基于连接的，也有基于批处理请求的，用户需仔细辨别才能找到自己想要的合适产品

确定下你的集群提供哪个协议服务，比如TCP服务。（当然也可以多协议混搭，我的就是HTTP提供主服务，TCP提供命令管理）。然后选择一个消息格式用于RPC通信(JSON,XML,ProtocolBuffer等)，这个很关键，(encode,decode)直接影响你集群的处理速度。当这些都确定后，你可以用mina写一个Slave,比如就是很简单的HelloWorld,消息格式为JSON。测试ok后将这个Slave复制多份，那么这就是一个Slave群了。

-+-+-+-+-+-+-+-+-+-+-+-

-+-+mysql的主从配置+-+-

-+-+-+-+-+-+-+-+-+-+-+-

#############################################################################

常用命令

1安装一个mysqld服务

  mysqld  install  

2开启mysql服务        关闭mysql服务  

  net start mysql      net stop mysql

2开启一个 mysql 的 3307端口

  命令行 进入解压目录\bin目录下

   解压目录\bin> mysql -uroot  -p  -P3307 -h127001

-u 用户名

-p密码

-P端口

-h网址

#启动从库

Start slave

#停止从库

Stop slave

#############################################################################

开始

用一台电脑测试

先在本电脑上安装一个mysql（集成的也行）

解压文件

然后解压另一个mysql到电脑目录

》》》》》1

在解压目录创建一个mysqlini

把一下文档写进去配置一个端口号为3307

#mysqld

[mysqld]

port=3307

basedir=D:\mysqlsever         #D:\mysqlsever 改成你解压目录

datadir=D:\mysqlsever\data    #D:\mysqlsever 改成你解压目录

安装一个mysqld服务    mysqld  install

开启mysql服务         net start mysql

不能正常启动请查看配置

》》》》2

#主库3306

在命令行或者

grant 权限 on 数据库对象 to 用户

GRANT all privileges REPLICATION SLAVE,RELOAD,SUPER ON 

TO mysql_backup1@''

IDENTIFIED BY '123456'with grant option;

flush privileges;

》》》3

在主库运行   SHOW MASTER STATUS       //运行后查看File和Postion

如  File mysql-bin000002   Postion 120

在从库运行  

CHANGE MASTER TO master_host = '127001',

master_user = 'mysql_backup',

master_password = '123456',

master_log_file = 'mysql-bin000001',#看上面的File  从库对照主库写

master_log_pos = 4791;#看上面的Postion    从库对照主库写

如果报错就停止就重新运行

#启动从库

Start slave

#停止从库

Stop slave

在从库运行  Show slave status

Slave_IO_Running

Slave_SQL_Running

两个字段全部是是Yes基本上就成功了

测试

在主库上建立一个表  在从库上刷新

############################################################################

CoreOS集群的架设比架设一个传统服务器集群更加容易。一方面因为 CoreOS 使用了 Cloud-init 自动化了集群信息的配置，另一方面则是受益于 etcd 分布式存储实现的消息分发和服务器自发现机制。这些便利性正是 CoreOS 系统设计充分为集群架构考虑带来的效率提升。

安装 CoreOS

CoreOS 的安装方法和传统 Linux 系统有很大的不同。鉴于是基础教程，在这一篇中，我们会使用官方的Vagrant镜像一步一步的构建CoreOS的VirtualBox虚拟机集群。本文使用了Linux/Mac作为测试环境，Vagrant从16版已经支持Windows，但需要安装Putty作为登录工具，略有不同，具体使用方法见 链接。  

需要顺带说明一点，比较仔细的使用者可能已经发现官方提供的镜像中有一个是“ ISO镜像文件”，然而这个镜像实际上只是一个 Live CD，也就免安装的试用镜像，直接使用这个ISO启动的系统是不具备服务自发现和分布式消息分发的能力的。通过ISO镜像安装集群的方式我们会放到专题篇的内容里面详述。好，现在进入正题吧。

正如系列的第一篇所提到的，Cloud-init 通常依赖于具体平台的实现定制，将其直接在物理机上使用并不是主流的使用方法。对于这种安装方法， 官方有一篇文档提供了详细的步骤，这里不再进行详细讨论。

首先来看一下 CoreOS 原生支持的平台。截止到目前，最新版本的CoreOS v540已经支持的平台如下图。

可以看到除去安装到本地的 Bare Metal，其余基本是针对主流的云服务平台定制的版本。这里的定制主要是 Cloud-init 等启动服务的配置，那么如何知道 CoreOS 已经支持自动化的集群部署的平台有哪些呢？我们可以从 CoreOS 源代码的 coreos-base 目录里得到答案。

这些 oem 开头的目录就是平台定制的实现。其中每个目录中的 files/cloud-configyml 文件，就是 Cloud-init 的配置文件。在每一种平台安装 CoreOS 的方式各有不同，可以从官方网站相应的页面找到相应步骤。这里我们选择其中的 Vagrant 作为演示的目标平台。

在 Vagrant 上部署 CoreOS 集群

使用 Vagrant 建立 CoreOS 集群可以说是最简单且经济的方式了，使用本地虚拟机构建，特别适合快速验证 CoreOS 的功能。

预备

需要准备的东西，包括一台连接到互联网的 Mac 或者桌面 Linux 电脑，安装好 Git、VirtualBox 和 Vagrant。

通过 Git 下载官方的 Vagrant 仓库：

git clone https://githubcom/coreos/coreos-vagrantgit

下载完成后，我们接下来配置 CoreOS 集群。

配置

为了使用集群服务器的自发现功能，我们需要一个能用来唯一标识一个集群并提供集群信息的地址。CoreOS 官方提供了这个服务，当然我们也可以使用自己搭建的私有集群标识服务器。鉴于搭建私有标识服务器属于比较进阶的内容，我们会在这个系列的后续文章详述。

通过浏览器或命令行 curl 访问地址 https://discoveryetcdio/new可以得到一个新的集群标识 URL（如果是在Windows下，可以直接使用浏览器访问这个URL地址），这个 URL 会在配置 user-data 时候使用到。

curl https://discoveryetcdio/new

进入 coreos-vagrant 目录，将 user-datasample 和 configrbsample 两个文件各备份一份，并去掉 sample 后缀。得到 user-data 和 configrb 文件。

首先修改 user-data 文件，它将作为启动的配置文件提供给 CoreOS 操作系统。值得一提的是，在这个配置中，可以使用两个变量 $private_ipv4 和 $public_ipv4，它们会在实际运行的时候被自动替换为主机的真实外网 IP 和内网 IP 地址。

这里我们需要做的只是将其中 discovery所在行前面的注释符合“#”去掉，然后替换它的值为我们刚刚获得的集群标识 URL 地址。简单来说，所有使用了同一个标识 URL 的主机实例都会在 CoreOS 启动时自动加入到同一个集群中，这就实现了无需人工干预的集群服务器自发现。

#cloud-config 

coreos: 

  etcd: 

    # generate a new token for each unique cluster from https://discoveryetcdio/new 

    # WARNING: replace each time you 'vagrant destroy' 

    discovery: <集群标识URL地址> 

    addr: $public_ipv4:4001 

peer-addr: $public_ipv4:7001 

然后修改 configrb 文件，这里包含了 Vagrant 虚拟机的配置。通过这个文件实际上可以覆写任何 Vagrantfile 里的参数，但是目前我们只需要关注 $num_instances 和 $update_channel 这两个参数的值。

$num_instances 表示将启动的 CoreOS 集群中需要包含主机实例的数量； $update_channel 表示启动的 CoreOS 实例使用的升级通道，可以是 ‘stable’，’beta’ 或 ‘alpha’。

$num_instances=3 

$update_channel='stable'

CoreOS 没有跨越式的版本发布，而是使用与 Arch Linux 类似的平滑的滚动升级，确保用户任何时候下载到的版本都是最新发布的系统镜像，并且从根本上解决了服务器系统在运行几年后，由于无法平滑升级而被迫重新安装的情况。此外 CoreOS 提供了 Stable、Beta 和 Alpha 三种升级通道，用于满足不同用户对系统新特性和稳定性的平衡。关于升级通道的切换，可参考官方的文档。

启动

启动集群，执行：

vagrant up

查看集群运行状态，所有的集群实例都已经启动。

vagrant up 

Current machine states: 

core-01                   running (virtualbox) 

core-02                   running (virtualbox) 

core-03                   running (virtualbox)

此时，在 CoreOS 集群的内部正发生着许多故事，集群的实例之间通过自发现服务，相互认识了对方并建立了联系。它们具备了在集群中任意一个实例节点控制整个集群的能力。是的，一个功能完备的 CoreOS 服务器集群已经完全运行起来了。

我现在使用的是小鸟云，他们目前官网有活动，3折优惠，建议去看看！

很多组织机构慢慢的在不同的服务器和地点部署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的高可用性、灾难恢复、可扩展性和负载均衡。单个更大的、由更多的节点组成的集群往往比小的、只有少数节点的集群更好。大个集群允许更灵活环境，为了负载均衡和维护，实例可以从一个节点移动到另外的节点。