可能有人会说，你这一篇文章硬给扯成了三篇，这是写章回小说呢？
我感觉有点好笑。
老子道德经有云：上士闻道勤而行之。
我整个安装调试前前后后花了我一个多星期，期间还要抓图带注释记录，另外还得把踩的坑给记录下来，并找到填坑的方法。
这么费时费力、吃力不讨好的事儿我一直在干，你觉得我会和这种人计较吗？
当然了，我也只是个普通人，所以请允许我在此发发牢骚。
同时也让我继续写下去，好给那些真心求学和求进步的小伙伴们解疑释惑。
上一篇我们说到哪儿了？
没错，前面的准备工作已经完备，只欠东风了！
我们在此先回顾一下各节点服务器的信息列表。
- A89230 192.168.89.230 SQL Server 节点一（主）
- A89231 192.168.89.231 SQL Server 节点二（辅）
- A89219 192.168.89.219 文件共享服务器（共享见证）
- A89220 192.168.89.220 AD 服务器（域名服务器）域名：
sysadm.local - MSSql_Cluster 192.168.89.232 群集名称（虚拟 IP 地址）
- MSSql_Listener 192.168.89.233 SQL Server Always On 可用性组侦听器（虚拟 IP 地址）
创建 SQL Server 的 Always On 可用性组
操作对象：主节点服务器（A89230）
所谓可用性组，就是一组节点服务器，将这些节点服务器放在一起形成一个组，即是可用性组。
在正式开始之前，我们需要备份一下数据库，因为在创建可用性组时，备份数据库是先决条件之一。
备份数据库很简单，你以前怎么备份的就怎么备份，没有什么特殊的。
备份完成后，就可以开始创建可用性组了。
左侧导航栏内展开 Always On 高可用性 ，右击 可用性组 ，选择 新建可用性组向导(N)... 。
填入你喜欢的可用性组名称（比如：MSSql_Cluster ），并将下方两项打上勾。
选择你需要赋予高可用功能的数据库，并确保其状态满足先决条件（比如已备份）。
这个数据库可以是新建的，也可以是已有导入的，并且可以选择多个。
此外要切记，副节点上不能有相同名字的数据库存在。
在 副本 选项卡中，点击 添加副本(A)... ，添加其他服务器实例副本。
之后勾选上 自动故障转移 一栏，并确保 可用性模式 为同步提交，同时 可读辅助副本 选择 是 。
在 备份首选项 选项卡中，选择 任意副本 。
这个任意副本的意思，就是当任意节点故障后，其他正常的节点就可以接管并提供正常的服务。
谁正常谁就是主节点，各节点的地位是平等的，后期恢复故障的节点将成为辅助副本。
在 侦听器 选项卡中，选择 创建可用性组侦听器(C) ，并填写侦听器 DNS 名称及端口，同时设定为静态IP地址。
正如前两篇中所说，这个名称也是 DNS 名称，也是要能解析到正确的 IP 地址才行的。
比如本例中，侦听器名称为 MSSql_Listener ，端口 1433 ，IP地址 192.168.89.233 。
数据同步首选项，选择 完整的数据库和日志备份 ，并指定之前的共享文件夹路径。
比如：\\A89219\ClusterSharing 。
完成一系列校验、连接，直至创建成功完成。
效果测试
全部都做完了，让我们先来简单整理总结一下前面的内容，这对我们测试会有帮助。
我的做法如下，小伙伴们可以参考也可以自行测试。
首先，我们需要 Ping 得通侦听器的域名或IP，比如本例的 MSSql_Listener.sysadm.local 或 192.168.89.233 。
其次，使用 SSMS 可以正常连接到侦听器，并可以正常操作数据库或执行一些 SQL 语句。
再次，关闭任意一台节点服务器，SQL 服务连接虽然会出现短时间的抖动，但很快就会恢复正常访问。
最后，开启刚才关闭的节点服务器，待完全开启后，再关闭另一节点服务器，观察服务抖动与连接情况。
反复多次，最终验证其可靠性。
踩到的坑，含着泪也要自己填上
要说好运不可能天天有，但坑总是能赶上几个的，哈哈！
所以说，踩坑才是人生真谛，而能把坑给填上也算是牛人不是？
坑一：正在检查托管次要副本 XXX 的服务器实例上是否已存在所选数据库。
填坑：删除副本服务器上的相应数据库。
坑二：可用性组侦听器 XXX 的创建失败。
填坑：手动在 etc/hosts 文件中追加侦听器的域名解析，或通过追加主机域名后缀来解决。
比如：
192.168.89.233 MSSql_Listener
192.168.89.233 MSSql_Listener.sysadm.local
坑三：最后一步一直停留在“正在将 XXX 联接到 XXX 上的可用性组 XXX ” 。
填坑：通常是因为非域环境下无法成功进行 DNS 解析，故节点之间无法正常通讯，建议追加使用 DNS 后缀，比如 host.domain.local 。
在 计算机名/域更改 中点击 其他(M)... ，然后在 此计算机的主DNS后缀(P) 中填入相应域名。
在 高级 TCP/IP 设置 中设定 此连接的 DNS 后缀(S) 为自己刚才设定的域名后缀，比如：sysadm.local 。
最后别忘记最好在 etc\hosts 文件中追加域名解析记录。
192.168.89.233 MSSql_Listener.sysadm.local
坑四：操作系统找不到已输入的环境选项，提示错误代码 0x800700cb 。
填坑：导致这个问题的原因还是 DNS 解析不正常。
通常在非域环境下，只有一个主机名就会导致这个问题的发生，即使主动做了 IP 地址指向也无济于事，所以可以参考前面的坑给加个域名后缀即可。
坑五：消息 41105：无法创建名称和类型为“SQL Server 可用性组”的 Windows Server 故障转移群集 (WSFC) 资源
填坑：这个问题挺让人无语的，原因是系统认为你没有设定好 Windows 故障转移群集，所以就不能开启 Always On 可用性组。
这就是在开玩笑了，我明明已经创建好群集了对吧。
好吧，处理方法也很简单，只要打开 SQL Server 配置管理器 ，在 SQL 服务属性的 启用 Always On 可用性组 选项卡中，将那个勾去掉、确定，然后重新给勾上、确定，最后重启服务即可。
总结
有不少小伙伴会将两台或多台节点服务器做成虚拟机形式，但却跑在了同一台物理机上。
我个人感觉这样并不能达到真正意义上的高可用，因为物理机一旦出现问题，虚拟机再多也是要挂的。
所以最佳做法，即使是跑虚拟机，也应该是建立在不同物理机的基础上来实现高可用，这样比较好。
本文分前后共分三篇，内容较长，适合菜鸟小白反复阅读。
同时也可能我踩的坑不算多，欢迎小伙伴们有踩到不一样坑的情况讨论区中留言讨论。
好了，别忘记你们最后还有一件非常重要的事要做，那就是关注我、一键三连！
扫码关注@网管小贾，阅读更多
网管小贾的博客 / www.sysadm.cc
