log文件

ORACLE Physical Standby DG 之switch over

生来就可爱ヽ(ⅴ<●) 提交于 2020-02-28 04:06:51
DG架构图如下: 计划,切换之后的架构图: DG切换: 主备切换: 这里所有的数据库数据文件、日志文件的路径是一致的 【旧主库】主库primarydb切换为备库standby3 主库检查switchover_status列的状态,是否支持switchover操作:如果该列值为"TO STANDBY"则表示primary 数据库支持转换为standby 角色 prod> select switchover_status from v$database; SWITCHOVER_STATUS -------------------- TO STANDBY SQL> alter database commit to switchover to physical standby ; SQL> select instance_name,status from v$instance; SQL> shutdown immediate 【新建备库】新建备库standby3切换为主库 检查v$database视图的switchover_status列的状态,是否支持switchover操作: SQL> select switchover_status from v$database; SWITCHOVER_STATUS -------------------- TO PRIMARY SQL>

DG 参数详解

被刻印的时光 ゝ 提交于 2020-02-28 04:04:49
1.与角色无关的参数 ◆ DB_UNIQUE_NAME :数据库唯一名。对于物理standby,DB_NAME必须相同,对于逻辑standby,DB_NAME可以不同,所以在10g中引入DB_UNIQUE_NAME参数用来区分DG配置中的每个数据库,默认值为DB_NAME. 例:DB_UNIQUE_NAME=STEPHEN ◆ LOG_ARCHIVE_CONFIG :定义DG配置中包含的DB_UNIQUE_NAME。它为DG提供安全检查:数据库之前的连接时允许的。 例:LOG_ARCHIVE_CONFIG='DG_CONFIG=(STEPHEN,STANDBY)' ◆ LOG_ARCHIVE_MAX_PROCESSES :最大归档进程数。默认值为2,需要调大,最大值为30.值如果太大,会影响归档切换速度和一致性关闭数据库。 例:LOG_ARCHIVE_MAX_PROCESSES=30 2.主角色参数 ◆ LOG_ARCHIVE_DEST_ n :DG传输redo data的主要参数,还用于指定Online redo log 和Standby redo log文件的归档日志文件存储位置。一般用LOG_ARCHIVE_DEST_1指定本地归档目录,LOG_ARCHIVE_DEST_2指定DG传输redo data存储目录。 该参数的主要属性: 属性 描述 LOCATION 指定归档目录

Oracle Data Guard 理论知识

杀马特。学长 韩版系。学妹 提交于 2020-02-28 04:02:00
Oracle Data Guard 理论知识 来源: Linux 社区 作者: tianlesoftware RAC , Data Gurad , Stream 是 Oracle 高可用性体系中的三种工具,每个工具即可以独立应用,也可以相互配合。他们各自的侧重点不同,适用场景也不同。 RAC 它的强项在于解决单点故障和负载均衡,因此 RAC 方案常用于 7*24 的核心系统,但 RAC 方案中的数据只有一份,尽管可以通过 RAID 等机制可以避免存储故障,但是数据本身是没有冗余的,容易形成单点故障。 Data Gurad 通过冗余数据来提供数据保护, Data Gurad 通过日志同步机制保证冗余数据和主数据之前的同步,这种同步可以是实时,延时,同步,异步多种形式。 Data Gurad 常用于异地容灾和小 企业 的高可用性方案,虽然可以在 Standby 机器上执行只读查询,从而分散 Primary 苏菊哭的性能压力,但是 Data Gurad 决不是性能解决方案。 Stream 是以 Oracle Advanced Queue 为基础实现的数据同步,提供了多种级别的灵活配置,并且 Oracle 提供了丰富的 API 等开发支持, Stream 更适用在应用层面的数据共享。 在 Data Gurad 环境中,至少有两个 数据库 ,一个处于 Open 状态对外提供服务

Nginx之常用基本配置(一)

核能气质少年 提交于 2020-02-28 03:52:58
  上一篇博客我们大概介绍了一下nginx,nginx的架构,nginx编译安装和nginx命令的用法,回顾请参考 https://www.cnblogs.com/qiuhom-1874/p/12366808.html ;今天我们来配置简单的配置下nginx和一些简单指令说明。   nginx和httpd类似都是高度模块化的软件,不同的模块有着不同的功能,想要把nginx配置好,首先我们需要了解各个模块的用法以及模块选项的用法和说明。首先我们来了解下nginx用yum安装后,程序环境 [root@www ~]# rpm -ql nginx /etc/logrotate.d/nginx /etc/nginx/fastcgi.conf /etc/nginx/fastcgi.conf.default /etc/nginx/fastcgi_params /etc/nginx/fastcgi_params.default /etc/nginx/koi-utf /etc/nginx/koi-win /etc/nginx/mime.types /etc/nginx/mime.types.default /etc/nginx/nginx.conf /etc/nginx/nginx.conf.default /etc/nginx/scgi_params /etc/nginx/scgi_params

Beats:使用Elastic Stack监控RabbitMQ

旧巷老猫 提交于 2020-02-28 02:31:50
RabbitMQ是一个开放源消息代理,创建于2007年以实现AMQP,并且在过去的十二年中,通过不断增加的插件列表,它已包括HTTP,STOMP,SMTP和其他协议。它也是Kafka的一个强劲的竞争者。在今天的文章中,我们将详述如何使用Elastic Stack来监控RabbitMQ。 RabbitMQ简介 RabbitMQ是消息队列软件,也称为消息代理或队列管理器。 简单地说; 它是定义队列的软件,应用程序连接到该队列以传输一条或多条消息。 一条消息可以包含任何种类的信息。 例如,它可能具有有关应在另一个应用程序(甚至可能在另一个服务器上)上启动的过程或任务的信息,或者可能只是一条简单的文本消息。 队列管理器软件存储消息,直到接收应用程序连接并从队列中取出消息为止。 接收应用程序然后处理该消息。 消息队列的基本体系结构很简单-有一些称之为生产者(producers)的客户端应用程序,它们可以创建消息并将其传递到代理(消息队列)。 其他应用程序(称为消费者,也即consumers)连接到队列并订阅要处理的消息。 软件可以充当消息的生产者或消费者,或者既充当消息的消费者又充当生产者。 存储在队列中的消息将被存储,直到消费者检索到它们为止。 在下面我们来具体介绍如何使用Elastic Stack来把我们想要的RabbitMQ日志导入到Elastic Stack中,并对日志进行分析。

基于logrotate进行自动化日志切割、日志压缩和周期删除

我只是一个虾纸丫 提交于 2020-02-27 16:09:46
前言 这篇博文以课程课件为蓝本来探讨logrotate和自动化日志处理的一系列课题,细节和深层次原理部分略有删减, 是一篇被课程耽误了的技术博文。 既然谈的很直白,是一篇被课程耽误了的技术博文,如若有打着博客做引导或者拿着开源工具不开源之类的讨伐和道德绑架,恕不回复。 这里是分割线,不废话了,直接切入正文,对课程有兴趣,想深入理解logrotate的朋友可以关注文末课程介绍:) 1.日志切割的概念、必要性和基本思路 1.1 什么是日志切割 日志切割是指当应用或系统的日志文件达到设定的触发条件(如按照一定的时间周期:每天,按照大小:500MB),对其进行切割/分割处理,类似截断处理,把原本容量比较大的日志文件“劫走”转存为另外一个日志文件留存归档,这一刻之后产生的日志,继续输出到文件头被重置为0的日志文件中。 变化的部分 :日志文件的容量(瘦身变小),日志文件的个数(多出一份被切割下的历史日志) 不变的部分 :日志文件名不变 此外,一段时间后,我们还需要删除时间久远的日志文件,整个过程也被俗称为日志滚动(log rotation)。 1.2 为什么要进行日志切割 在线应用(包括操作系统)在长期运行过程中,会产生很多过程日志记录,通常是应用程序记录的一些对系统管理员或者程序开发者有用的信息的文件,诸如正在执行什么、发生了什么错误等一系列信息。 随着日志记录的不断积累,日志文件越来越大

mysqlbinlog 查看binlog时报错unknown variable 'default-character-set=utf8'

半城伤御伤魂 提交于 2020-02-27 14:19:11
某次排查用户充值到账问题,想从主库的binlog中找一些线索,裸的binlog文件是无法直视的,mysqlbinlog这个工具是用来查看binlog文件内容的(使用方式man mysqlbinlog查看),但是使用mysqlbinlog将binlog文件转换成人类可读的内容时却报错: mysqlbinlog: unknown variable 'default-character-set=utf8' 原因是mysqlbinlog这个工具无法识别binlog中的配置中的default-character-set=utf8这个指令。 两个方法可以解决这个问题 一、在MySQL的配置/etc/my.cnf中将default-character-set=utf8 修改为 character-set-server = utf8,但是这需要重启MySQL服务,如果你的MySQL服务正在忙,那这样的代价会比较大。 二、mysqlbinlog --no-defaults mysql-bin.000004 命令打开 我使用的是二方法 作者:旧旧的 <393210556@qq.com> 解决问题的方式,就是解决它一次 来源: https://www.cnblogs.com/widgetbox/p/12371685.html

mysql(windows or linux)忘记密码

帅比萌擦擦* 提交于 2020-02-27 04:05:31
提示:1045 access denied for user 'root'@'localhost' using password yes 连接数据库时候弹出这个,然后又忘记密码了请看 转载请注明出处 http://blog.csdn.net/yc7369 曾经由于这个问题找了各种方法,各种行不通,最后将可用方法进行了记录,今日将其整理,以高来者 Linux: 先跳转到 mysql 文件夹下 #mysqld_safe --user=mysql --skip-grant-tables --skip-networking & # mysql -u root mysql mysql> UPDATE user SET Password=PASSWORD(’newpassword’) where USER=’root’; mysql> FLUSH PRIVILEGES; mysql> quit # /etc/init.d/mysql restart # mysql -uroot -p Enter password: < 输入新设的密码 newpassword> mysql> Windows: 法1、 1 在服务里面先把 mysql 服务停止 2 然后在 C:\Program Files\MySQL\MySQL Server 5.6 下找到my.ini 文件, my*.ini 文件 并在

应急响应

China☆狼群 提交于 2020-02-27 01:16:04
什么是应急响应 PDCERF模型 P (Preparation准备) D (Detection诊断) C (Containment抑制) E (Eradication根除) R (Recovery恢复) F (follow-up跟踪) 其实就是为了快速定位问题点,快速解决问题原因 应急工具: ls, ifconfig , ps ,top busybox webshell 检查。病毒查杀 诊断:CPU 占用 -> 挖矿 阻断: 比如拔网线 根除: 黑客如何攻进来的,利用什么漏洞,在服务器中做了什么,清除后门,webshell等 恢复,监控: 应急报告 BusyBox BusyBox 是一个集成了三百多个最常用Linux命令和工具的软件。 运维人员开始top、ps等未查找到异常进程是由于该病毒涉及到 Linux动态链接库预加载机制, 是一种常用的进程隐藏方法,而系统的ls,ps等命令已被通过so库的preload机制被病毒劫持。 而busybox是静态编译的,不依赖于系统的动态链接库,从而不受ld.so.preload的劫持,能够正常操作文件。 BusyBox下载 cd /bin/ wget https://busybox.net/downloads/binaries/1.30.0-i686/busybox chmod 755 busybox 使用: busybox top #

Docker 常用命令与操作

一世执手 提交于 2020-02-26 22:07:37
介绍 此命令集合版本为 1.11.1 及以上 基础类 查看docker信息 # 查看docker版本 docker version # 显示docker系统的信息 docker info # 日志信息 docker logs # 故障检查 service docker status # 启动关闭docker sudo service docker start|stop 日志类 查看容器日志 docker logs -f <容器名orID> docker daemon 日志位置 也称之为 引擎日志 根据系统不同各不相同 * CoreOS - journalctl -u docker.service * Ubuntu(16.04) - journalctl -u docker.service * Ubuntu(14.04) - /var/log/upstart/docker.log * Boot2Docker - /var/log/docker.log * Debian GNU/Linux 8 - journalctl -u docker.service * Debian GNU/Linux 7 - /var/log/daemon.log * CentOS 7/RHEL 7 - journalctl -u docker.service * CentOS - /var/log