利用日志传送来实现数据库的可用性-阿里云开发者社区

开发者社区> 技术小胖子> 正文

利用日志传送来实现数据库的可用性

简介:
+关注继续查看



这不是一个新技术,SQL SERVER2000时就已经有了,2005中没有什么太大的改进,,还是由三项操作组成:

1.  在主服务器中备份事务日志
2.  然后将备份的事务日志文件复制到辅助服务器中
3.  在辅助服务器中还原日志备份
 
大家看到了这个过程还是很简单的,也就是在实现的应用中,对你所正在使用听数据库进行一个事务日志备份。备份成功后,复制到辅助服务器,这个过程不应该是管理员手动执行,而应该是通过调度来实现。然后再做一个调度,在辅助服务器上进行还原。但日志传送到此就结束了,它并不会因为主要服务器故障而实现自动转移,这是实现不了的,这个转移工作已经要由手动来实现。这点和复制是一样的。如果是通过应用程序来连接的话,还要改源代码来实现转移。这和群集和镜像是不一样的。
 
日志传送所使用的角色:
主服务器和数据库  (生产用服务器及所使用到的数据库)
辅助服务器和数据库  (用于存放备份的服务器及相应数据库)
监视服务器     用于监视主要服务器和辅助服务器的通讯,以及主服务器的运行状态,
               应该是一个专门的服务器,那如果机器不够可以和辅助服务器在一起。
               可以监视主服务器是否做了备份,这个备份是否复制,辅助服务器什么候还原等等,那么这个地方,监视到出现问题怎么办,可以给管理员发邮件以通知管理员。这要结合作业来实现。
 
 
主服务器和辅助服务器的关系:可以不是一:一的关系,可以多个主要服务器对应一个辅助服务器,用于存放多个主要服务器上的备份,以节约硬件资源
 
这三个角色如何进行工作的,全部是通过SQL Server AGET来实现的,所以一定要确保在所有角色上都要运行代理服务,分别执行以下作业:
主要服务器: 备份作业
辅助服务器: 复制作业,还原作业
监视服务器:警报作业
但这一系列的作业,不需要我们一一创建,只要我们配置好日志传送之后,系统会自动创建。当然前提是数据库恢复模型应该是完全或是大容量日志
 
下面我们就来看一下具体的实施步骤:
1.  确定主服务器,辅助服务器和监视服务器
2.  为事务日志备份创建文件共享,是好是一个文件服务器(我们就在主要服务器上)
3.  制定主数据库的备份计划
4.  可以为主服务器配置一个或是多个辅助服务器,注意:辅助服务器上数据库不能写,但是可以查询,
5.  配置一个监视服务器,有两种方法,可以使用存储过程,也可以使用SSMS
 
有了上面的理论介绍,下面就可以动手了:
我们的目的很明确就是
配置日志传送
监视日志传送
实现手动的转移到辅助服务器
清除日志传送
 
步骤1:创建共享文件夹用于存放相关文件
         我们在SERVER1上创建两个共享文件夹, server2上创建一个共享文件夹,如上图所示:
其中  primarydata\logs 用于存放主服务器备份文件的。主服务器代理用户必须是域用户。
      Secondarydata\logs 系统会将 PRIMARY\logs中的日志复制到此供辅助服务器使用。
      Databaseback   用于存放生产数据库的副本
 
步骤2 备份主服务器上的数据库,注意一个数据库只能有一个日志传送
         我们以 dufei 数据库为例:辅助服务器上不能有同名数据库。
        backup database dufei to disk='c:\databasebackup\dufei.bak'
这个文件夹是主服务器上的一个共享文件夹
我们为了测试方便,我们在此创建一个表,并插入一条记录:
 
USE DUFEI
GO
CREATE TABLE YG
(
ID CHAR(4),
UNAME VARCHAR(10),
SEX CHAR(2)
)
INSERT INTO YG VALUES ('0001','岳雷','')
GO
BACKUP LOG DUFEI TO DISK='C:\DATABASEBACKUP\DUFEI.BAK'
GO
步骤3  开始在主服务器上配置日志传送
下面是添加辅助服务器:
我们这里选择第二种初始化辅助数据库的方法:
但这个时候确定键是不能用的,是因为我们的操作还没有结束。我们还要复制日志文件到SECONDARYDATA\logs文件夹下。
下面的操作就是指定还原事务日志的模式:
有两种模式,这两种模式差别是很大的。
 
到此时三步就已经完成了。  备份----复制----还原。
 
最后我们再来指定监视服务器。
到这里为止,日志传送就配置结束了:点击确定
测试:到SERVER2上可以看到DUFEI数据库已经创建成功了,并且岳雷这条记录也出现在辅助数据库中。
并且在SERVER2的共享文件夹中可以看到相应的日志文件也复制过来了。
 
与复制的目的是一样的,结果也相同,都不能实现自动的转移,但事务复制要求参与的表必须要有主键,而日志传送不需要。
 
日志文件应该是两分钟复制一次,但我们也没有必要每次都打开文件夹来查看,我们可以利用监视功能来监视服务器的运行状况。并定义一个警报来对你的日志传送进行监控,如果发生了故障,则通过操作员。但默认情况下,警报肯定是用不了的,我们要设置一下,如:
我们在监视服务器上:会发生自动多出两个警报
如果希望这两个警报能正常工作,我们要设置一下,过程如下:
1.  定义操作员:
2.  配置警报:
此时,再启用网卡,则一切又OK了!
1.  查看日志传送状况Z
在监视服务器上:
 
可以测试一下,我们在主服务器上创建一个表,或是更新一条记录,会很快的反映到辅助服务器。
最近我们来看一下如何手动的实现故障转移
1.  我们手动停止主要服务器上的SQL SERVER服务,删除相应的DUFEI数据库所对应的MDF文件  再次启动服务器,会发现DUFEI数据库已经不能用了。
2.  在辅助服务器上,禁用代理,运行命令
此时,辅助服务器上的DUFEI数据库就不再是只读了。!
但要注意的是:监视服务器上的代理作业也应该禁用,不然会不停的发出警报。
 
好,我们的实验就到此结束了!
 
最后可以清除日志传送:
关于日志传送就介绍到此! 





 本文转自 dufei 51CTO博客,原文链接:http://blog.51cto.com/dufei/88720,如需转载请自行联系原作者

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
后疫情时代,用数据支持业务恢复创造新的可能性
2020年可以说每一天都在见证历史,新冠疫情的突然造访就如同“黑天鹅”不期而至,而企业现在还不开始数字化转型就如同“灰犀牛”存在潜在风险,当下在黑天鹅和灰犀牛的夹击下,经济和市场都产生了巨大的影响。
817 0
SQL SERVER数据库删除LOG文件和清空日志的方案
原文:SQL SERVER数据库删除LOG文件和清空日志的方案 数据库在使用过程中会使日志文件不断增加,使得数据库的性能下降,并且占用大量的磁盘空间。SQL Server数据库都有log文件,log文件记录用户对数据库修改的操作。
4153 0
Elasticsearch 日志监控方案
Elasticsearch 日志监控方案 -- ElastAlert,Watcher
152 0
PostgreSQL 10.1 手册_部分 III. 服务器管理_第 30 章 可靠性和预写式日志_30.5. WAL内部
30.5. WAL内部 WAL是自动被启用的。除了做一些设置满足存放WAL日志的磁盘空间需求以及一些必要的调节以外(参阅第 30.4 节),对管理员没有什么其他要求。 当每个新记录被写入时,WAL记录被追加到WAL日志中。
970 0
PostgreSQL 10.1 手册_部分 III. 服务器管理_第 30 章 可靠性和预写式日志
第 30 章 可靠性和预写式日志 目录 30.1. 可靠性 30.2. 预写式日志(WAL) 30.3. 异步提交 30.4. WAL配置 30.5. WAL内部 本章解释预写式日志如何用于获得有效的、可靠的操作。
861 0
13262
文章
0
问答
文章排行榜
最热
最新
相关电子书
更多
文娱运维技术
立即下载
《SaaS模式云原生数据仓库应用场景实践》
立即下载
《看见新力量:二》电子书
立即下载