合 PG启动报错invalid record length at 10/26583018: wanted 24, got 0
Tags： PGPostgreSQL启动报错
现象
PG启动数据库，后台日志报错：
1 2 3 4 5 6 7 8 9 | 2023-12-13 15:12:11.611 CST [12168] FATAL: the database system is starting up 2023-12-13 15:12:11.823 CST [26468] FATAL: the database system is starting up 2023-12-13 15:12:11.830 CST [1968] FATAL: the database system is starting up 2023-12-13 15:12:11.981 CST [21320] LOG: database system was not properly shut down; automatic recovery in progress 2023-12-13 15:12:12.018 CST [21320] LOG: redo starts at 10/264D5640 2023-12-13 15:12:12.025 CST [21320] LOG: invalid record length at 10/26583018: wanted 24, got 0 2023-12-13 15:12:12.025 CST [21320] LOG: redo done at 10/26582FE8 system usage: CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s 2023-12-13 15:12:12.161 CST [7272] FATAL: the database system is starting up 2023-12-13 15:12:12.432 CST [11496] FATAL: the database system is starting up |
potgresql 启动失败 日志报错‘0/F43F3C8 处的记录长度不合法：想要 24，但得到的是 0‘ ’英文提示 invalid record length at 0/F43F3C8: wanted 24, got 0
对于9.6及以前版本，工具命令pg_resetwal 叫 pg_resetxlog，它的本职工作是清理不需要的WAL文件
解决
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 | E:\Program Files\postgres\bin> E:\Program Files\postgres\bin>.\pg_ctl.exe stop -D ..\data -m immediate 等待服务器进程关闭 .... 完成 服务器进程已经关闭 E:\Program Files\postgres\bin>.\pg_resetwal -f -D ..\data 重置预写日志 E:\Program Files\postgres\bin>.\pg_ctl.exe start -D ..\data 等待服务器进程启动 ........2023-12-13 15:14:51.855 CST [37964] LOG: redirecting log output to logging collector process 2023-12-13 15:14:51.855 CST [37964] HINT: Future log output will appear in dire ctory "log". . 完成 服务器进程已经启动 |
pg_resetwal
pg_resetwal — 重置一个PostgreSQL数据库集簇的预写式日志以及其他控制信息
大纲
pg_resetwal [ --force | -f ] [ --dry-run | -n ] [option...] [ --pgdata | -D ] datadir
描述
pg_resetwal会清除预写式日志（WAL）并且有选择地重置存储在pg_control文件中的一些其他控制信息。如果这些文件已经被损坏，某些时候就需要这个功能。当服务器由于这样的损坏而无法启动时，这只应该被用作最后的手段。
在运行这个命令之后，就可能可以启动服务器，但是记住数据库可能包含由于部分提交事务产生的不一致数据。你应当立刻转储你的数据、运行initdb并且重新载入。重新载入后，检查不一致并且根据需要修复之。
这个工具只能被安装服务器的用户运行，因为它要求对数据目录的读写访问。出于安全原因，你必须在命令行中指定数据目录。pg_resetwal不使用环境变量PGDATA。
如果pg_resetwal抱怨它无法为pg_control决定合法数据，你可以通过指定-f（强制）选项强制它继续。在这种情况下，丢失的数据将被替换为看似合理的值。可以期望大部分域是匹配的，但是下一个 OID、下一个事务 ID 和纪元、下一个多事务 ID 和偏移以及 WAL 开始位置域可能还是需要人工协助。这些域可以使用下面讨论的选项设置。如果你不能为所有这些域决定正确的值，-f还是可以被使用，但是恢复的数据库还是值得怀疑：一次立即的转储和重新载入是势在必行的。在你转储之前不要\在该数据库中执行任何数据修改操作，因为任何这样的动作都可能使破坏更严重。
选项
-f--force即使
pg_resetwal无法从pg_control中确定有效的数据（如前面所解释的），也强迫pg_resetwal继续运行。-n--dry-run-n/--dry-run选项指示pg_resetwal打印从pg_control重构出来的值以及要被改变的值，然后不修改任何东西退出。这主要是一个调试工具，但是可以用来在允许pg_resetwal真正执行下去之前进行完整性检查。-V--version显示版本信息然后退出。
-?--help显示帮助然后退出。
只有当pg_resetwal无法通过读取pg_control确定合适的值时，才需要下列选项。安全值可以按下文所述来确定。对于接收数字参数的值，可以使用前缀0x指定 16 进制值。
-c *xid*,*xid*--commit-timestamp-ids=*xid*,*xid*本人提供Oracle(OCP、OCM)、MySQL(OCP)、PostgreSQL(PGCA、PGCE、PGCM)等数据库的培训和考证业务，私聊QQ646634621或微信dbaup66，谢谢！
