首页 > 数据库 >SQL SERVER Alway-on 灾难恢复方案 1 2 3

SQL SERVER Alway-on 灾难恢复方案 1 2 3

时间：2023-06-19 17:06:33浏览次数：58

标签：主库数据库 SERVER DOWN Alway 10.50 SQL

SQL SERVER Alway-on 灾难恢复方案 1 2 3_数据库

SQL SERVER 这个数据库估计快被人遗忘了，但实际上很多IT 力量薄弱的公司的首选的数据库就是 SQL SERVER，大部分人认为他简单，好上手，并且问题少,SQL SERVER 本身的高可用方式主要就是 Always-on. 一般Always-on 是三台机器。下面就针对多种情况中的DOWN机后,数据库是否可以恢复正常工作,做一些相关的检验.

在安装ALWAY-ON 注意几点

1 建议三台机器

2 建议WINDOWS 2016 + SQL SERVER 2016 为最低版本，这样安装后可以不使用域验证或者证书验证。

3 需要安装WINDOWS 故障转移功能

4 建议把防火墙关闭

SQL SERVER Alway-on 灾难恢复方案 1 2 3_python_02

并且需要安装WINDOWS的故障转移功能

SQL SERVER Alway-on 灾难恢复方案 1 2 3_数据库_03

SQL SERVER Alway-on 灾难恢复方案 1 2 3_大数据_04

安装WINDOWS的故障转移集群，需要将集群内的机器的名字改为统一的后缀。

SQL SERVER Alway-on 灾难恢复方案 1 2 3_分布式_05

还需要将每个机器的DNS解析配置

C:\Windows\System32\drivers\etc

打开host 文件

10.50.132.205   sqls-dr-t03.gwmfc.com
10.50.132.204   sqls-dr-t02.gwmfc.com
10.50.132.203   sqls-dr-t01.gwmfc.com

SQL SERVER Alway-on 灾难恢复方案 1 2 3_python_06

安装故障转移集群，输入服务器名称

SQL SERVER Alway-on 灾难恢复方案 1 2 3_数据库_07

SQL SERVER Alway-on 灾难恢复方案 1 2 3_分布式_08

进行测试，因为没有使用active Directory 配置可以跳过一些警告

SQL SERVER Alway-on 灾难恢复方案 1 2 3_分布式_09

集群本身是需要一个VIP IP 的

SQL SERVER Alway-on 灾难恢复方案 1 2 3_python_10

SQL SERVER Alway-on 灾难恢复方案 1 2 3_大数据_11

SQL SERVER Alway-on 灾难恢复方案 1 2 3_数据库_12

SQL SERVER Alway-on 灾难恢复方案 1 2 3_python_13

这里就有三个节点

SQL SERVER Alway-on 灾难恢复方案 1 2 3_数据库_14

下面就需要安装SQL SERVER ALWAY ON

首先需要检查 SQL SERVER 的服务中的关于AWO 功能打开了

SQL SERVER Alway-on 灾难恢复方案 1 2 3_大数据_15

打开任意的一个SQL SERVER数据库并创建一个数据库

SQL SERVER Alway-on 灾难恢复方案 1 2 3_分布式_16

需要对要做ALWAYS的数据库进行一个全备

SQL SERVER Alway-on 灾难恢复方案 1 2 3_数据库_17

点击创建高可用组，---新建可用组向导

SQL SERVER Alway-on 灾难恢复方案 1 2 3_数据库_18

添加其他节点到AWO组中

SQL SERVER Alway-on 灾难恢复方案 1 2 3_分布式_19

在做SQL SERVER AWO 实际上要有两个VIP 一个是WIDNOWS 的故障转移集群的VIP 一个是SQL SERVER 本身的AWO 属于高可用组的VIP

SQL SERVER Alway-on 灾难恢复方案 1 2 3_大数据_20

选择自动种子设定

SQL SERVER Alway-on 灾难恢复方案 1 2 3_数据库_21

高可用就成功安装完毕了

SQL SERVER Alway-on 灾难恢复方案 1 2 3_大数据_22

SQL SERVER Alway-on 灾难恢复方案 1 2 3_分布式_23

test 的高可用数据库就安装完毕了

SQL SERVER Alway-on 灾难恢复方案 1 2 3_python_24

下面就开始进行相关的故障转移的测试

1 从库DOWN

2 主库DOWN

3 两个从DOWN

4 一主一个从DOWN

5 全DOWN

1 从库DOWN 不会影响业务，我们将10.50.132.205 直接关机，还是可以通过VIP 访问数据库

SQL SERVER Alway-on 灾难恢复方案 1 2 3_分布式_25

在恢复了205 后，SQL SERVER 会自动启动并接入到AWO 集群内

SQL SERVER Alway-on 灾难恢复方案 1 2 3_python_26

2 主库DOWN

SQL SERVER Alway-on 灾难恢复方案 1 2 3_java_27

这边我们关闭主库，在关闭主库，我们的应用会受到影响，已经连接的应用都会被关闭，如果

1 可用性是异步提交的，则主库不进行切换，待主库恢复后，业务可以恢复正常

SQL SERVER Alway-on 灾难恢复方案 1 2 3_大数据_28

2 如果可用性都是同步提交，则会进行故障自动转移

SQL SERVER Alway-on 灾难恢复方案 1 2 3_python_29

则在关闭主库后，会通过选择机制自动选择一个从库变为主库

SQL SERVER Alway-on 灾难恢复方案 1 2 3_python_30

通过VIP 206 是可以继续访问业务，业务不会受到影响

SQL SERVER Alway-on 灾难恢复方案 1 2 3_分布式_31

在主库开机后，（短时间，主库自动变为从库并加入到集群中）

SQL SERVER Alway-on 灾难恢复方案 1 2 3_数据库_32

3 两个从库DOWN

在关闭两个从库后，数据库库主库无法访问了。

SQL SERVER Alway-on 灾难恢复方案 1 2 3_python_33

尝试将数据库恢复到可以读取的状态

SQL SERVER Alway-on 灾难恢复方案 1 2 3_数据库_34

无法将数据库恢复为可读取的状态

SQL SERVER Alway-on 灾难恢复方案 1 2 3_数据库_35

此时机器的数据库无法进度读取，或恢复单机的情况，

具体我们做了如下的工作

1 我们尝试将WINDOWS WCFS 中的10.50.1.203 windows 集群中无法删除

2 我们将10.50.132.203 的故障转移服务删除后

3 将SQL SERVER ALWAYSON 服务从SQL SERVER 服务中取消

然后数据库仍然处于挂起并且做任何操作均显示，test数据库属于可用性组，无法进行操作。

此时我们的结论是，必须回复另外至少一台服务器的情况下，才能删除可用性组，将数据库恢复为单机模式。

下图为开启 10.50.132.204 后， 10.50.132.203 的状态

SQL SERVER Alway-on 灾难恢复方案 1 2 3_java_36

结论为只要有一台机器恢复后，则应用就可以继续使用数据库服务。

必须至少有两台服务器工作的状态下，数据库才能提供服务。

4 一主一从DOWN 机

我们将 10.50.132.205 和 10.50.132.203 关掉，状态与两台从数据库DOWN机是一致的。

SQL SERVER Alway-on 灾难恢复方案 1 2 3_分布式_37

SQL SERVER Alway-on 灾难恢复方案 1 2 3_数据库_38

我们尝试将test数据库从高可用中移除，也是失败了。

结论：只要两个数据库服务器DOWN机的情况下，数据库则陷入无法读取的失控的状态，并很难恢复。除非两个节点开启的状态下，才可以恢复数据库，或应用服务可以访问数据库。

5 三台服务器全部挂机的状态，并且在无次序的开机后，数据库是可以恢复的，正常访问的。

另外两台的AWO如果两台机器均挂机后，在开启的状况一般也是能恢复的，如果出现挂起的状态可以删除可用性组的方式，将数据库恢复为单机的模式，

SQL SERVER Alway-on 灾难恢复方案 1 2 3_python_39

在通过restore database 数据库名 with recovery的方式就可以将数据库恢复为单机模式。此时还需要将AWO 上的VIP 在服务的数据库上作为子IP 进行挂载提供提供对外服务。

SQL SERVER Alway-on 灾难恢复方案 1 2 3_java_40

SQL SERVER Alway-on 灾难恢复方案 1 2 3_数据库_41

标签：主库,数据库,SERVER,DOWN,Alway,10.50,SQL
From： https://blog.51cto.com/u_14150796/6515984

相关文章

MYSQL client 有了更多的新功能
MYSQL8 中的client中的新功能，方便在MYSQL的client中操作可以不用在切换到LINUX平台下操作某些LINUX的命令。使用的场景主要在于在MYSQL中操作数据库的命令的适合，同时还想在监控一下当前的性能，之前可能会开两个窗口，在MYSQL8后，这样的事情可能会少不少。到底我们能做什么1 ......
POSTGRESQL UPDATE 如何提高I/O 能力
POSTGRESQL的数据扫描，其实和其他的数据库也无差，无非就是数据块的扫描以及索引的扫描，这里POSTGRESQL数据扫描也叫TUPLESCAN。在POSTGRESQL8.3版本后再HEAP表的修改中，有一个概念叫HOT，通过新的概念提高了堆表的性能，减少了I/O。早起的POSTGRESQL更新的方式是修改索引中的数......
POSTGRESQL RC事务处理与ORACLE MYSQL 的区别 --对PGFANS 群里面的问题的分解
有一个同学在PGFANS群里面提了一个问题，在他实验的某个操作中发现PG和ORACLE使用同样的操作流程后，得到的结果不一致。所以下面准备验证并找到一些可以解释的原因。测试库名test测试表test测试数据id age 1 202 223 24首先我们要确认 PG的隔离 RC......
POSTGRESQL analyze table 到底做了什么与扩展统计
PostgreSQL 中对表的状态是有单独的命令来进行状态的收集的，到底怎么对表来进行状态的收集，并且都做了什么，我们怎么来依靠这些信息来对查询进行有益的帮助。这些都将在这篇文章里面探讨。首先我们对PG12中，关于Analyze 的注释来仔细的阅读一遍ANALYZE collectsstatisticsabout......
POSTGRESQL PG_REWIND 从源代码看功能
PG_REWIND是PG9.6开始提供的功能，主要的作用在于通过PG_REWIND让PG复制中的数据库快速的与预定的“主库”进行数据同步，而复制的方式是是文件块的方式，并且可以避过重复的数据块。所以复制的速度是快的，在不少的高可用方式中都被作为主库失败后的快速的将主库加入原有集群并作为从......
分布式两大流派 POSTGRESQL -XC 了解一下
分布式数据库有两大流派，NEWSQLVS POSTGRESQL-XC，NEWSQL的分布式主流的理论来源自GOOGLE的分布式数据库spanner，以及相关理论的白皮书，而令一派的分布式数据库来自于POSTGRESQL-XC，今天我们看看到底POSTGRESQL-XC这个流派的方式是什么，有什么特点，当下那些分布式数据库采用了......
POSTGRESQL Postgres-XL 了解一下
上次分析的POSTGRES-XC的结构, 实际上POSTGRES-X系列一直在发展, POSTGRES除了XC还有XL的高可用的结构.Postgres-XL是一款Postgres-XC升级的产品，如果说PGXC是在PG添加了集群的功能主打OLTP的功能为卖点，PGXL是一款基于PGXC添加了OLAP功能的支持MPP架构的，但不是简单的PO......
POSTGRESQL 创建一个表到底有什么说的? 可说的挺多的
创建一张表,到底有什么说的, 下面是POSTGRESQL创建数据表的官方文档的内容截图. 那我们就往下看,到底我们可以说点什么建表的开头是关于临时表的问题,其中临时表的global和local,在目前的V12的版本中并没有具体的含义,问题1，POSTGRESQL怎么创建一个看似global的temparytab......
POSTGRESQL 主节点失败后, 在多变的情况下重新让他融入复制中
POSTGRESQL 在主从流复制中,在主库失败切换后,从库变为主库后,如果主库不是因为硬件的原因,想继续拉起来,并且加入到新的复制关系中,一般都会通过pg_rewind的程序来进行拉起来.但不少问题反馈对pg_rewind在重新拉起旧主库出现问题,到底有什么情况下pg_rewind对你的数据库重新建立......
POSTGRESQL 设置hugepage 可以让系统使用内存更有效率，防止OOM
https://www.percona.com/blog/why-linux-hugepages-are-super-important-for-database-servers-a-case-with-postgresql/https://bbs.huaweicloud.com/blogs/detail/156799Hugepage是什么，基于LINUX系统，大页面对虚拟内存管理是有必要的。除标准的4KB页面之外，还进行内存中的大页面......

赞助商

阅读排行