半自动化搭建Data Guard的想法和实践(一)

简介:     一直以来搭建Data Guard是一件看起来还蛮有含量的工作,因为这其中涉及的工作比较琐碎,比较细,况且手工搭建起来都会碰到各种各样的问题,如果中途碰到一点儿小问题,那可能需要花点时间来排查,如果想要脚本自动化,那简直寸步难行。
    一直以来搭建Data Guard是一件看起来还蛮有含量的工作,因为这其中涉及的工作比较琐碎,比较细,况且手工搭建起来都会碰到各种各样的问题,如果中途碰到一点儿小问题,那可能需要花点时间来排查,如果想要脚本自动化,那简直寸步难行。所以搭建Data Guard一方面会需要很多的提前准备和配置,另一方面这个工作自动化的驱动力不够,毕竟环境不会像MySQL业务一样动辄几十成百上千的规模,所以由此而来,好像搭建一个套环境的成本也值了,如果尝试自动化,半自动化,那花费的时间估计够搭建10套环境了。所以目前来看,行业内也鲜有自动化搭建的案例。
      当然如果一件事情本来你需要花2个小时搞定,结果花了10分钟就能搞定,那么对于工作来说,这就是一种福利了,另一方面从规范角度来看,自动化,半自动化,一个重要的基础就是标准化,规范化。这些基础做不好,那么自动化,半自动化也是磕磕绊绊。所以我也是借这个机会来完善规范一些我们做的不好的地方。举个例子来说明就具体多了。
我在备库配置网络的时候,把主库的listener.ora拷贝到备库,修改了HOST信息,就准备启动监听,但是奇怪的是监听怎么都启动不了。错误信息如下:
$ lsnrctl start LISTENER_1529
LSNRCTL for Linux: Version 11.2.0.4.0 - Production on 28-JUL-2016 16:37:17
Copyright (c) 1991, 2013, Oracle.  All rights reserved.
Starting /U01/app/oracle/product/11.2.0.4/bin/tnslsnr: please wait...
TNSLSNR for Linux: Version 11.2.0.4.0 - Production
System parameter file is /U01/app/oracle/product/11.2.0.4/network/admin/listener.ora
Log messages written to /U01/app/oracle/diag/tnslsnr/stest3/listener_1529/alert/log.xml
Listening on: (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=stest3.cyou.com)(PORT=1529)))
TNS-01201: Listener cannot find executable /U01/app/oracle/product/11.2.0.4/db_1/bin/oracle for SID test
Listener failed to start. See the error message(s) above...
对于网络监听这块,本身Oracle的解析就有些不是很健壮的地方,有些空格的约束问题,更多的细节,可以参考http://blog.itpub.net/23718752/viewspace-1061787/
所以根据错误,看起来和空格还没有关系,但是我排除再三,排除了字符集,空格,DB信息错误等,还是没有找到问题的症结。一筹莫展的时候,突然发现listener.ora中的ORACLE_HOME为/U01/app/oracle/product/11.2.0.4/db_1,在主库则为/U01/app/oracle/product/11.2.0.4,最后发现是这样一个问题,看起来着实让人有些无奈。而这种问题说实在的解决了对自己的技术提高有多少,我看未必,但是又厄待解决。
    所以这也更加坚定了我简化Data Guard配置的一个决心。
    而另外一个考虑就是基于安全和脚本的健壮性,我决定使用半自动化搭建的方式,主库就是主库,容不得半点失误,所以我不会考虑在主动自动化运行任何的脚本,脚本都需要确认审核后执行,对于配置的添加和修改尤其需要注意,而对于备库而言,自动化则大有可为,所以我需要在主库中获取一些基本的元数据文件(比如listener.ora之类的文件),改进处理后放入备库。大体的流程图如下:

首先第1步就是从主库中获取这些元数据文件,只有抓取,没有任何写入。
第二步是在中控机器中进行元数据文件的处理,这大体涉及以下几个方面:
1. 在tnsnames.ora中添加备库的tns连接串,修改host
 2.istener.ora修改host为备库主机名
 3. hosts中追加主机名的配置
 4. 添加db_unique_name到参数文件中
 5. 添加local_listener
 6. 添加dg_broker_start
 7. 添加standby_file_management=auto
 8. 添加db_file_name_convert
 9. 添加log_file_name_convert
10.开通主备库的防火墙权限
第三步则是在主库中进行配置,大体有如下的工作:
  1.修改/etc/hosts,追加备库的配置
    10.127.133.190    stest2.cyou.com
   2. 追加配置到tnsnames.ora,修改host为主机名
        stest2=(DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = stest2.cyou.com)(PORT = 1529))) (CONNECT_DATA = (SERVICE_NAME = test)(server=dedicated)))
    3.检查主库是否force logging,是否含有standby logfile,是否启用spfile,是否启用dg broker,是否设置local_listener
第四步则是把生成的文件,脚本拷贝到备库端,在备库运行部署。有下面的一些工作需要考虑。
    1./sbin/ifconfig得到IP 根据db名改为主机名
    生成类似下面的形式,
            IP                         <db_unique_name><dg_number>.oracle.com
            10.127.133.190    stest2.oracle.com
    2.追加主库的配置
    10.127.xxxx    test.oracle.com     --参考主库的/etc/hosts
    3.hostname stest2.cyou.com    
    4.修改 /etc/sysconfig/network
    5.创建必要的目录结构,比如审计日志的目录(基于参数audit_file_dest)
    6.启动监听
这些步骤做好了之后,80%的工作就完成了。我们就可以看看怎么来搭建备库了。一种方式是使用duplicate来在线从头主库同步数据到备库,这种方式简单快捷,也是推荐的方式。
两个命令即可搞定。
 rman target sys@test auxiliary sys/xxxx@stest2 nocatalog
duplicate target database for standby from active database nofilenamecheck;
 这些工作都完成了,就完成了90%,还剩下最后一步,即配置DG Broker,这个是作为一个基本的标准规范,省时省力。
在主库运行两个命令即可搞定,这个步骤手动完成,因为是最后的收官阶段,一旦有问题,这个阶段一定会抛出异常。
create configuration dg_test as
primary database is test
connect identifier is test;

add database stest2 as
connect identifier is test2
maintained as physical;
脚本已经开始写了,感觉越写发现有很多的细节需要准备,越是这样,越觉得这件事情还是值得去做的。


目录
相关文章
|
人工智能 自然语言处理 测试技术
从人工到AI驱动:天猫测试全流程自动化变革实践
天猫技术质量团队探索AI在测试全流程的落地应用,覆盖需求解析、用例生成、数据构造、执行验证等核心环节。通过AI+自然语言驱动,实现测试自动化、可溯化与可管理化,在用例生成、数据构造和执行校验中显著提效,推动测试体系从人工迈向AI全流程自动化,提升效率40%以上,用例覆盖超70%,并构建行业级知识资产沉淀平台。
从人工到AI驱动:天猫测试全流程自动化变革实践
|
人工智能 JavaScript 前端开发
自动化测试框架的演进与实践###
本文深入探讨了自动化测试框架从诞生至今的发展历程,重点分析了当前主流框架的优势与局限性,并结合实际案例,阐述了如何根据项目需求选择合适的自动化测试策略。文章还展望了未来自动化测试领域的技术趋势,为读者提供了宝贵的实践经验和前瞻性思考。 ###
505 11
|
存储 数据采集 监控
Python定时爬取新闻网站头条:从零到一的自动化实践
在信息爆炸时代,本文教你用Python定时爬取腾讯新闻头条,实现自动化监控。涵盖请求、解析、存储、去重、代理及异常通知,助你构建高效新闻采集系统,适用于金融、电商、媒体等场景。(238字)
1852 2
|
Java 测试技术 API
自动化测试工具集成及实践
自动化测试用例的覆盖度及关键点最佳实践、自动化测试工具、集成方法、自动化脚本编写等(兼容多语言(Java、Python、Go、C++、C#等)、多框架(Spring、React、Vue等))
974 6
|
存储 SQL 关系型数据库
MySQL 动态分区管理:自动化与优化实践
本文介绍了如何利用 MySQL 的存储过程与事件调度器实现动态分区管理,自动化应对数据增长,提升查询性能与数据管理效率,并详细解析了分区创建、冲突避免及实际应用中的关键注意事项。
651 0
|
运维 监控 安全
从实践到自动化:现代运维管理的转型与挑战
本文探讨了现代运维管理从传统人工模式向自动化转型的必要性与路径,分析了传统运维的痛点,如效率低、响应慢、依赖经验等问题,并介绍了自动化运维在提升效率、降低成本、增强系统稳定性与安全性方面的优势。结合技术工具与实践案例,文章展示了企业如何通过自动化实现运维升级,推动数字化转型,提升业务竞争力。
|
运维 监控 持续交付
自动化运维在现代数据中心的应用与实践####
本文探讨了自动化运维技术在现代数据中心中的应用现状与实践案例,分析了其如何提升运维效率、降低成本并增强系统稳定性。通过具体实例,展示了自动化工具如Ansible、Puppet及Docker在环境配置、软件部署、故障恢复等方面的实际应用效果,为读者提供了一套可参考的实施框架。 ####
|
监控 jenkins 测试技术
软件测试中的自动化测试策略与实践##
本文旨在探讨自动化测试在软件开发生命周期中的重要性,以及如何有效地实施自动化测试策略。通过分析自动化测试的优势和挑战,结合具体的实践案例,提出了一系列实用的自动化测试方法和技巧。本文不仅为读者提供了理论知识的深入解析,还强调了实际操作中的关键注意事项,旨在帮助读者更好地理解和应用自动化测试技术,提高软件质量。 ##
342 27
|
Kubernetes Java 持续交付
小团队 CI/CD 实践:无需运维,Java Web应用的自动化部署
本文介绍如何使用GitHub Actions和阿里云Kubernetes(ACK)实现Java Web应用的自动化部署。通过CI/CD流程,开发人员无需手动处理复杂的运维任务,从而提高效率并减少错误。文中详细讲解了Docker与Kubernetes的概念,并演示了从创建Kubernetes集群、配置容器镜像服务到设置GitHub仓库Secrets及编写GitHub Actions工作流的具体步骤。最终实现了代码提交后自动构建、推送镜像并部署到Kubernetes集群的功能。整个过程不仅简化了部署流程,还确保了应用在不同环境中的稳定运行。
1664 9
|
敏捷开发 Java 测试技术
软件测试中的自动化策略与实践
在快速迭代的软件开发周期中,自动化测试是确保产品质量和提升开发效率的关键。本文将深入探讨自动化测试的重要性,介绍实用的自动化测试框架,并通过一个具体的代码示例,说明如何实现一个简单的自动化测试脚本。
332 12

热门文章

最新文章