Maclean’s Oracle Database Tech Blog Archives

2019-11-19 06:37:09.459 UTC [2705] FATAL: terminating autovacuum process due to administrator command 2019-11-19 06:38:35.142 UTC [2791] LOG: listening on IPv6 address “::1”, port 5432 2019-11-19 06:38:35.142 UTC [2791] LOG: listening on IPv4 address “127.0.0.1”, port 5432 2019-11-19 06:38:35.143 UTC [2791] LOG: listening on Unix socket “/var/run/postgresql/.s.PGSQL.5432” 2019-11-19 06:38:35.162 UTC [2792] LOG: database system was interrupted;…

pg_resetwal就是之前的pg_resetxlog pg_resetwal — 重置一个PostgreSQL数据库集簇的预写式日志以及其他控制信息   大纲 pg_resetwal [-f] [-n] [option…] {[-D] datadir}   描述   pg_resetwal会清除预写式日志（WAL）并且有选择地重置存储在 pg_control文件中的一些其他控制信息。如果这些文件已经被损坏， 某些时候就需要这个功能。当服务器由于这样的损坏而无法启动时， 这只应该被用作最后的手段。 在运行这个命令之后，就应该可以启动服务器， 但是记住数据库可能包含由于部分提交事务产生的不一致数据。 你应当立刻转储你的数据、运行initdb并且重新载入。重新载入后， 检查不一致并且根据需要修复之。 这个工具只能被安装服务器的用户运行，因为它要求对数据目录的读写访问。 出于安全原因，你必须在命令行中指定数据目录。pg_resetwal 不使用环境变量PGDATA。 如果pg_resetwal抱怨它无法为pg_control 决定合法数据，你可以通过指定-f（强制）选项强制它继续。 在这种情况下，丢失的数据将被替换为看似合理的值。可以期望大部分域是匹配的， 但是下一个 OID、下一个事务 ID 和纪元、下一个多事务 ID 和偏移以及 WAL 开始地址域可能还是需要人工协助。这些域可以使用下面讨论的选项设置。 如果你不能为所有这些域决定正确的值，-f还是可以被使用， 但是恢复的数据库还是值得怀疑：一次立即的转储和重新载入是势在必行的。 在你转储之前不要在该数据库中执行任何数据修改操作， 因为任何这样的动作都可能使破坏更严重。   选项   -f 即使pg_resetwal无法从pg_control 中确定有效的数据（如前面所解释的），也强迫pg_resetwal 继续运行。 -n -n（无操作）选项指示pg_resetwal打印从 pg_control重构出来的值以及要被改变的值，然后不修改任何东西退出。 这主要是一个调试工具，但是可以用来在允许pg_resetwal 真正执行下去之前进行完整性检查。 -V –version 显示版本信息然后退出。 -? –help 显示帮助然后退出。 只有当pg_resetwal无法通过读取pg_control 确定合适的值时，才需要下列选项。安全值可以按下文所述来确定。 对于接收数字参数的值，可以使用前缀0x指定 16 进制值。 -c xid,xid…

文章来源：https://yq.aliyun.com/articles/55691 pg_resetxlog说明 pg_resetxlog，用来重置/清空一个数据库集群的预写日志以及其它控制内容，其中控制内容由命令pg_controldata可以查看，而内容的来源则是位于$PGDATA/global目录下名为pg_control的控制文件 可选参数有：   yunbodeMacBook-Pro:~ postgres$ pg_resetxlog –help pg_resetxlog resets the PostgreSQL transaction log. Usage: pg_resetxlog [OPTION]… DATADIR Options: -e XIDEPOCH set next transaction ID epoch -f force update to be done -l XLOGFILE force minimum WAL starting location for new transaction log -m MXID,MXID set next and oldest multitransaction ID -n no update,…

文章来源：http://mysql.taobao.org/monthly/2017/04/04/   上期月报PgSQL · 特性分析 · Write-Ahead Logging机制浅析中简单介绍了PostgreSQL中WAL机制，其中讲到如果是创建checkpoint会触发刷新xlog日志页到磁盘，本文主要分析下PostgreSQL中checkpoint机制。   checkpoint又名检查点，一般checkpoint会将某个时间点之前的脏数据全部刷新到磁盘，以实现数据的一致性与完整性。目前各个流行的关系型数据库都具备checkpoint功能，其主要目的是为了缩短崩溃恢复时间，以Oracle为例，在进行数据恢复时，会以最近的checkpoint为参考点执行事务前滚。而在WAL机制的浅析中，也提过PostgreSQL在崩溃恢复时会以最近的checkpoint为基础，不断应用这之后的WAL日志。     检查点发生时机   在xlog.h文件中，有如下代码对checkpoint进行了相应的分类：     /* * OR-able request flag bits for checkpoints. The “cause” bits are used only * for logging purposes. Note: the flags must be defined so that it’s * sensible to OR together request flags arising from different requestors.…

pg_resetxlog – 重置一个 PostgreSQL 数据库集羣的预写日志以及其它控制内容 注意从pg 10开始 pg_resetxlog 被 pg_resetwal  替代    root@vultr:/usr/lib/postgresql/10/bin# ./pg_resetwal –help pg_resetwal resets the PostgreSQL write-ahead log. Usage: pg_resetwal [OPTION]… DATADIR Options: -c XID,XID set oldest and newest transactions bearing commit timestamp (zero in either value means no change) [-D] DATADIR data directory -e XIDEPOCH set next transaction ID epoch -f…

文章来源： http://blog.sina.com.cn/s/blog_544a710b0101a6xv.html 上一篇测试了通过pg_resetxlog来清理WAL，我们还可以通过它来恢复pg_control。   pg_control在$PGDATA/global下，很小，很不起眼。但一旦这个文件被损坏，PG就启不来。 cd $PGDATA/global mv pg_control ./.. 看日志，可以看到以下信息：   PANIC: could not open control file “global/pg_control”: No such file or directory LOG: checkpointer process (PID 5989) was terminated by signal 6: Aborted LOG: terminating any other active server processes WARNING: terminating connection because of crash of another server process DETAIL: The postmaster…

内容来源：https://www.cnblogs.com/cchust/p/4603599.html   FLUSH TABLES WITH READ LOCK简称(FTWRL)，该命令主要用于备份工具获取一致性备份(数据与binlog位点匹配)。由于FTWRL总共需要持有两把全局的MDL锁，并且还需要关闭所有表对象，因此这个命令的杀伤性很大，执行命令时容易导致库hang住。如果是主库，则业务无法正常访问；如果是备库，则会导致SQL线程卡住，主备延迟。本文将详细介绍FTWRL到底做了什么操作，每个操作的对库的影响，以及操作背后的原因。   FTWRL做了什么操作？   FTWRL主要包括3个步骤：   1.上全局读锁(lock_global_read_lock) 2.清理表缓存(close_cached_tables) 3.上全局COMMIT锁(make_global_read_lock_block_commit)   FTWRL每个操作的影响   上全局读锁会导致所有更新操作都会被堵塞；关闭表过程中，如果有大查询导致关闭表等待，那么所有访问这个表的查询和更新都需要等待；上全局COMMIT锁时，会堵塞活跃事务提交。由于FTWRL主要被备份工具使用，后面会详细解释每个步骤的作用，以及存在的必要性。FTWRL中的第1和第3步都是通过MDL锁实现，关于MDL的实现，我之前总结了MDL锁的文章，这里主要介绍清理表缓存的流程。   清理表缓存   每个表在内存中都有一个table_cache，不同表的cache对象通过hash链表维护。 访问cache对象通过LOCK_open互斥量保护，每个会话打开的表时，引用计数share->ref_count++， 关闭表时，都会去对引用计数share->ref_count–。 若发现是share对象的最后一个引用(share->ref_count==0)，并且share有old_version, 则将table_def_cache从hash链表中摘除，调用free_table_share进行处理。关键函数close table流程如下：   1.关闭所有未使用的表对象 2.更新全局字典的版本号 3.对于在使用的表对象，逐一检查，若表还在使用中，调用MDL_wait::timed_wait进行等待 4.将等待对象关联到table_cache对象中 5.继续遍历使用的表对象 6.直到所有表都不再使用，则关闭成功。   清理表缓存函数调用   mysql_execute_command->reload_acl_and_cache->close_cached_tables ->TABLE_SHARE::wait_for_old_version->MDL_wait::timed_wait-> inline_mysql_cond_timedwait   会话操作表流程   1.打开表操作，若发现还有old_version,则进行等待 2.share->ref_count++ 3.操作完毕，检查share->ref_count–是否为0 4.若为0,并且检查发现有新版本号，则认为cache对象需要重载 5.将cache对象摘除，调用MDL_wait::set_status唤醒所有等待的线程。   关闭表对象函数调用   dispatch_command->mysql_parse->mysql_execute_command-> close_thread_tables->close_open_tables->close_thread_table-> intern_close_table->closefrm->release_table_share->my_hash_delete->…

pg 中的常见几个数据页损坏坏块问题   could not read block N of relation X/Y/Z: read only 0 of 8192 bytes catalog is missing N attribute(s) for relid M WARNING: page verification failed, calculated checksum %u but expected %u ERROR: invalid page in block %u of relation %s     这些错误大部分情况下是 存储子系统:文件系统或磁盘的问题导致， 可以考虑先冷备份整个数据文件夹，然后设置参数 zero_damaged_pages和 ignore_checksum_failure 之后使用 pg_dumpall 导出全库 可以使用…

There is a special option: zero_damaged_pages=on that you can use on postgresql.conf, it is documented here. This option will allow for a pg_dump (or pg_dump_all) that do not stop on critical errors and get as much data back as possible, but you will loose the data that cannot be read.: (exceprt from documentation, I added…

最近在研究postgreSQL的特殊恢复手段；pg的表数据直接独占存放在单个或多个数据文件，这让pg本身的恢复格局较为简单。   postgreSQL的基本情况： 每个表和索引 都是单独的文件， 当表或索引太大时 会扩展到多个文件 每套库都有自己的数据字典表 pg_class等，pg_class的文件号是1529 pg_global表空间里记录了核心字典信息 就是有哪些数据库 和 数据库的oid postgreSQL的块头是 pageHeader ，pageheader 24个字节 之后是 ItemIdData 即行指针， 之后是free space，之后是数据tuple heap pageheader里没有该page的位置信息， 但这个文档 https://www.jianshu.com/p/375e2b9fd079 里说有pd_type和 pd_oid 信息， 即24个字节里的 最后4个字节，但源代码里看没有这些结构，源代码里最后4字节是 TransactionId(uint32) pd_prune_xid; https://doxygen.postgresql.org/bufpage_8h_source.html 。这些结构可能是某些特殊发行版本里搞出来的。 另外在tuple的ctid里有块号和行号，但是没有文件号，即如(0,0),(0,1),(0,3)这样的序列信息没有意义 基于以上事实做的一些实验： truncate table xx 表对应的文件马上被vacuum掉，即文件大小归零，文件没有被删除 delete from xx 删除全表， 表对应的文件马上被vacuum掉，即文件大小归零，文件没有被删除 drop table xx 表对应的文件马上被vacuum掉，即文件大小归零，文件没有被删除 以上三种情况会因为pg的page缺少必要区分page的page内特征信息（例如oracle的rdba)，虽然可以通过扫描磁盘获得这些块，但很难搞清楚这些块属于哪个文件（哪个表或索引） 另做了一个实验，在pg 12下创建2张表结构一致 ， 数据不一致。通过对这2张表对应对文件相互替换冒充，通过pg实例可以访问这2张表（被互相替换后），这说明pg是不验证也无法验证文件内容与库中的表的强一致性的。 page中缺乏一个重要的oid信息，这将导致pg的page不具有碎片扫描合并的可能性。     但因为pg在做drop…