弄明白日志号的原理之后,一段时间又有点忘记了,干脆整理一遍: (一)wal文件命名规则 1)在$PGDATA目录下面的pg_xlog目录中存放着xlog日志文件(10.1之后变为了pg_wal): total 165896-rw-r--r-- 1 apple staff 660K 11 22 15:46 000000010000000000000013.dump-rw------- 1 apple staff 295B 11 22 16:12 000000010000000000000014.0

问题出现 我们在线上巡检中发现,一个实例的pg_xlog目录,增长到4G,很是疑惑.刚开始怀疑是日志归档过慢,日志堆积在pg_xlog目录下面,未被清除导致.于是检查归档目录下的文件,内容如下.但发现新近完成写入的日志文件都被归档成功了(即在pg_xlog/archive_status里面,有对应的xxx.done文件). ls -lrt pg_xlog ... -rw------- xxxx xxxx Jun : 0000000100000035000000DE -rw------- xxxx

前言 oracle中的redo日志我们无法直接读取,然而对于KingbaseES数据库,我们可以利用sys_waldump工具解析wal日志,查看wal日志记录的信息. 我们可以利用 sys_waldump --rmgr=list看一下有哪些管理类型: [](javascript:void(0) [kingbase@localhost data]$ sys_waldump --rmgr=list XLOG Transaction Storage CLOG Database Tablespace

  关键字:wal日志归档  搭建从库 restore_command master 194.1 slave 194.4 wal归档目录 /backup/pgsql/pg_arch/ xlog目录 /var/lib/pgsql/9.5/data/pg_xlog   我们知道pg的从库的搭建是通过基础备份和完整的wal日志完成的,那么如果主库的wal日志已经被归档或异常丢失,如果通过备份进行搭建从库呢? 我们可以通过restore_command命令把wal归档拷贝回xlog目录完成.具体的操作如

​ 案例说明: 本案例通过对KingbaseES V8R3集群failover切换过程进行观察,分析了主备库切换后wal日志的变化,对应用者了解KingbaseES V8R3(R6) failover切换过程有一定的帮助. 以下为现场案例: failover切换后主备库的wal日志信息: 新主库数据库服务启动故障:(sys_log) =如下所示,在sys_log中,新主库启动startup后,建立流复制,流复制的起始wal日志是:" 00000004000000050000002A",

案例说明: 1.对于集群中的wal日志,除了需要在备库执行recovery外,在集群主备切换(switchover或failover)时,sys_rewind都要读取wal日志,将数据库恢复到一致性状态. 2.对于集群主备库中的wal日志,在清理时,经过测试,理论上在checkpoint所在的wal日志之前的都可以清理,但这是比较理想的状态,在生产环境中,建议保留3天到一个星期的wal日志,避免因为主备延迟,导致在集群切换时,因为缺少wal日志失败. 3.对于KingbaseES V8R6的集群

一,Win10 打开 MSDTC 1,Win+R 打开运行窗口,输入 dcomcnfg,打开组件服务窗口 2,在组件服务 catalog下找到 Distributed Transaction Coordinator下的本地DTC 3,打开本地DTC的属性,设置安全tab,选中“网络DTC访问”,勾选“允许远程客户端”,“允许远程管理”,“允许入站”,“允许出站”,“要求相互进行身份验证”,DTC登陆账户为:NT Authority\Network Service 二,恢复Windows Task

  SQL Server:查看SQL日志文件大小命令:dbcc sqlperf(logspace) DBA 日常管理工作中,很重要一项工作就是监视数据库文件大小,及日志文件大小.如果你管理数据库的有很多的话,每天一个一个数据库的去查看文件大小就太费神了,那就写个SQL脚本吧,放到 SQL Agent 中,每天自动去查看各个数据库文件及日志文件的大小,然后再通过数据库邮件,Email 到我们手中,岂不快哉!当然,可以把每天的记录存放到数据库中去,这样数据库及日志文件的增长趋势,我们也就一目了然了.

我们可以在mysql的安装目录下看到mysql的二进制日志文件,如mysql-bin.000***等,很多人都不及时的处理,导致整个硬盘被塞满也是有可能的.这些是数据库的操作日志.它记录了我们平时使用的sql语句命令,即使这个sql语句没有被执行,也会被记录,它包括执行时间之类的都详细在案,其实 它的目的有两个:一是方便我们查错和恢复数据库:二是为了主从服务器之间同步数据用的,主从服务器上所有操作都记录在日志里,从服务器可以根据这些日志来进行相同的操作,确保主从两个同步. 关键词: mysql

在SQL SERVER下跟踪sql采用事件探查器,而在mysql下如何跟踪sql呢? 其实方法很简单,开启mysql的日志log功能,通过查看跟踪日志即可. 开启mysql的日志log方法: windows环境下的配置方法: 我使用的版本:Version: 5.0.37-community-nt-log (MySQL Community Edition (GPL)) 找到my.ini,我的是在“G:\Program Files (x86)\MySQL\MySQL Server 5.0”目录下,

由于报警日志文件很大,而每天都应该查看报警日志(查看有无“ORA-”,Error”,“Failed”等出错信息),故想找到一种比较便捷的方法,查看当天报警日志都有哪些错误. 在网上查了几天的资料,尝试综合清除告警日志内容及建外部表的方式来解决这一问题. 一:备份并清除告警日志内容 将每天的告警日志备份好,然后进行清除. 1:备份报警日志 在$ORACLE_HOME/SID/bdump/   目录下, 按日期备份alert_ORACLE_你的实例名.LOG这个文件,如:alert_ORACLE_o

错误描述: 发布时控制台出现: 部署错误: 尚未授予访问 Tomcat 服务器的权限.请在服务器管理器的 Tomcat 定制器中设置 "manager-script" 角色的正确用户名和口令.有关详细信息, 请查看服务器日志.  错误分析: 查看tomcat目录下conf>tomcat-users.xml文件,原因是没有指定manager-script的角色,打开文件在其中添加以下代码: <role rolename="manager-script"/&

本人还是个菜鸟,下面是我的经验之谈,能解决一些问题,有不对的地方,敬请斧正. 我的是CentOS6.3+MySQL5.1.57. 重启了一次服务器后,使用> mysql -u root -p登陆是出现下面的错误: ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/tmp/mysql.sock' (2) 于是,我检察mysql状态: > /etc/rc.d/init.d/mysqld  status

WAL日志介绍 wal全称是write ahead log,是postgresql中的online redo log,是为了保证数据库中数据的一致性和事务的完整性.而在PostgreSQL 7中引入的技术.它的中心思想是"先写日志后写数据",即要保证对数据库文件的修改应放生在这些修改已经写入到日志之后,同时,在PostgreSQL 8.3以后又加入了WalWriter日志写进程,可以保证事务提交记录不是在提交时同步写入到磁盘,而是异步写入,这样就极大的减轻了I/O的压力.所以说WAL日

查看mysql日志方法: mysql默认不允许我们查看日志.需要更改一些设置 1 vi 更改配置文件 允许用户查看日志文件 sudo vi /etc/mysql/mysql.conf.d/mysqld.cnf 把68 69行前面的#删除 显示行号方法:shift : nu 跳转行方法: 68 shfit+g2 重启mysql服务 终端运行: sudo service mysql restart 3 进入 cd /var/log/mysql/ 能够查看里面有mysql的日志文件vi mysql.l

--linux下查看alert日志文件的两种方法: --方法1: SQL> show parameter background_dump_dest; NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ background_dump_dest string /home/oracle/admin/ora125/bdump SQL> ho ls /home/o

logdashboard 日志面板是我在Github写的一个开源项目,旨在让查看日志变的方便快捷.在线预览 现在功能有日志检索.趋势图.异常堆栈快速查看.日志详情等 logdashboard支持自定义日志模型可以记录更多自定义的属性. logdashboard支持的日志来源有以下两种,推荐在开发时使用文件源,部署生产环境时使用数据库源 文件源 数据库源 在部署时支持页面授权与自定义身份验证过滤器 更多介绍请参见官网 快速入门 确保机器上安装了DotNetCore SDK,打开PowerShell

这是<ABP大型项目实战>系列文章的一篇.   项目发布到生产环境后难免会有错误. 那么如何进行调试和排错呢?   我看到俱乐部里有人是直接登陆生产服务器把数据库下载到开发机器进行调试排错. 这种办法是不适用于大型项目的: 首先,大型项目(特别是全球都有分公司的大型项目)很有可能24小时都有人在使用.所以尽量避免直接登录生产服务器操作,就算部署,也应该用DevOps.蓝绿部署等办法. 另外,如果大型项目有采用金丝雀发布和A/B测试,那么把数据库下载到开发机器这种方法是很不适用的. 即使大型项目

场景描述: 应用程序运行在 Docker环境中,经常使用的查看后台日志的命令是:docker attach 容器名该命令优点:实时输出:不足之处:日志大量输出的时候,屏幕一闪而过,不便于调试,并且有一个比较严重的问题,就是该命令在某些容器环境下,由于配置不同,ctrl+c命令退出的时候,会直接导致该容器停止. 其实,docker自身是集成封装了一些关于查看日志的命令的,组合使用,可帮助日常快速定位问题: * 显示所有 log * 显示实时 log * 使用 tail 查看 log 尾部 * 使用

查看tomcat日志通常用 tail -n  或者 tail -f 或者grep 或者 vi cat等命令去查看异常信息,但是日志是在不停地刷屏,tail是动态的在变的,我们往往期望从日志最后一行往前一页一页的翻页查看,从而找到异常信息,而less 工具,是对文件或其它输出进行分布显示的工具,是linux查看文件内容的工具,功能极其强大 1.语法: less 参数 文件名称  /  less  文件名称 2.导航 j   向前移动一行 k   向后移动一行 g   移动到第一行 G   移动到最