PostgreSQL?pg_filenode.map文件介紹

更新時(shí)間：2022年09月16日 10:46:46 作者：foucus、

這篇文章主要介紹了PostgreSQL誤刪pg_filenode.map怎么辦，文中通過(guò)示例代碼介紹的非常詳細(xì)，對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值，需要的朋友們下面隨著小編來(lái)一起學(xué)習(xí)吧

今天在網(wǎng)上看到有人問(wèn)誤刪pg_filenode.map該如何恢復(fù)或者重建，解決這個(gè)問(wèn)題前我們先來(lái)了解下pg_filenode.map文件。

對(duì)于PostgreSQL中的每張表在磁盤(pán)上都有與之相關(guān)的文件，而這些文件的名字便是relfilenode，我們可以通過(guò)pg_class的relfilenode字段去查詢。

但是有一部分特殊的表我們會(huì)發(fā)現(xiàn)其對(duì)應(yīng)的該字段為0，官方文檔的解釋為：0表示這是一個(gè)“映射”關(guān)系，其磁盤(pán)文件名取決于低層狀態(tài)。那么哪些表的relfilenode字段會(huì)是0呢？這些relfilenode為0的表對(duì)應(yīng)的文件又該如何去查找呢？

我們都知道對(duì)于一張普通表，其relfilenode和oid默認(rèn)是一樣的，例如：

bill=# create table t(id int);
CREATE TABLE
bill=# select oid,relname,relfilenode from pg_class where relname = 't';
  oid  | relname | relfilenode
-------+---------+-------------
 24919 | t       |       24919
(1 row)

但是當(dāng)我們對(duì)該表進(jìn)行了例如vacuum full、truncate之類的操作后，那么relfilenode便會(huì)發(fā)生變化：

bill=# vacuum FULL t;
VACUUM
bill=# select oid,relname,relfilenode from pg_class where relname = 't';
  oid  | relname | relfilenode
-------+---------+-------------
 24919 | t       |       24922
(1 row)

那么我們?cè)賮?lái)看看那些relfilenode為0的表：

bill=# select oid, relname, relfilenode,reltablespace
bill-# from pg_class
bill-# where relfilenode = 0 and relkind = 'r'
bill-# order by reltablespace;
 oid  |        relname        | relfilenode | reltablespace
------+-----------------------+-------------+---------------
 1247 | pg_type               |           0 |             0
 1249 | pg_attribute          |           0 |             0
 1255 | pg_proc               |           0 |             0
 1259 | pg_class              |           0 |             0
 3592 | pg_shseclabel         |           0 |          1664
 1262 | pg_database           |           0 |          1664
 2964 | pg_db_role_setting    |           0 |          1664
 1213 | pg_tablespace         |           0 |          1664
 1261 | pg_auth_members       |           0 |          1664
 1214 | pg_shdepend           |           0 |          1664
 2396 | pg_shdescription      |           0 |          1664
 1260 | pg_authid             |           0 |          1664
 6100 | pg_subscription       |           0 |          1664
 6000 | pg_replication_origin |           0 |          1664
(14 rows)

這些表通過(guò)reltablespace字段我們也可以發(fā)現(xiàn)分為兩類：一類是pg_type、pg_attribute、pg_proc和pg_class，它們是非共享的表，在內(nèi)核中我們稱為Nail表。而另一類則是reltablespace為1664的，即在pg_global表空間里的共享表。

而為什么這些系統(tǒng)表的relfilenode為0呢？因?yàn)閷?duì)于這種訪問(wèn)十分頻繁的系統(tǒng)表，我們不希望每次都是從一些其它的系統(tǒng)表去查詢，這樣性能便會(huì)非常低，它們便是通過(guò)pg_filenode.map文件去進(jìn)行管理的。

在pg_filenode.map文件中，將這些系統(tǒng)表的oid與relfileno做映射，而這個(gè)文件的大小為512，剛好是一個(gè)OS disk sector的大小。同時(shí)PG做了對(duì)齊處理，在源碼上用RelMapFile結(jié)構(gòu)體與之對(duì)應(yīng)。結(jié)構(gòu)體大小為：628+44=496+16=512。也就是說(shuō)這個(gè)文件最多存放62條系統(tǒng)catalog表的記錄。

由于這個(gè)文件的重要性，剛好與disk sector大小對(duì)齊，減少文件crash的機(jī)率。

typedef struct RelMapping
{
	Oid			mapoid;			/* OID of a catalog */
	Oid			mapfilenode;	/* its filenode number */
} RelMapping;
typedef struct RelMapFile
{
	int32		magic;			/* always RELMAPPER_FILEMAGIC */
	int32		num_mappings;	/* number of valid RelMapping entries */
	RelMapping	mappings[MAX_MAPPINGS];
	pg_crc32c	crc;			/* CRC of all above */
	int32		pad;			/* to make the struct size be 512 exactly */
} RelMapFile;

接著我們來(lái)具體看看這個(gè)文件里面存放的內(nèi)容是什么樣的：

如上圖所示，可以將該文件分為四個(gè)部分。

第一部分：2717 0059，表示文件頭魔法數(shù)據(jù)字。

#define RELMAPPER_FILEMAGIC0x592717/* version ID value */

第二部分：0011 0000，表示文件中包含的映射對(duì)象數(shù)。我們可以通過(guò)以下SQL驗(yàn)證：

剛好是17行數(shù)據(jù)，和前面0011一致。

bill=# select relname,relfilenode from pg_class where pg_relation_filepath(oid) like 'base/16385/%' and relfilenode = 0;
              relname              | relfilenode
-----------------------------------+-------------
 pg_toast_1255                     |           0
 pg_toast_1255_index               |           0
 pg_proc_oid_index                 |           0
 pg_proc_proname_args_nsp_index    |           0
 pg_type_oid_index                 |           0
 pg_type_typname_nsp_index         |           0
 pg_attribute_relid_attnam_index   |           0
 pg_attribute_relid_attnum_index   |           0
 pg_class_oid_index                |           0
 pg_class_relname_nsp_index        |           0
 pg_class_tblspc_relfilenode_index |           0
 pg_attribute                      |           0
 pg_proc                           |           0
 pg_type                           |           0
 pg_toast_1247                     |           0
 pg_toast_1247_index               |           0
 pg_class                          |           0
(17 rows)

第三部分：04eb 0000 4095 0000，這一類便是實(shí)際的映射關(guān)系04eb即對(duì)象的oid，4095表示對(duì)象的relfilenode。

第四部分：ebfa f3a4，文件尾的校驗(yàn)值，通過(guò)crc32算法對(duì)文件名計(jì)算得出：

/* verify the CRC */

INIT_CRC32C(crc);

COMP_CRC32C(crc, (char *) map, offsetof(RelMapFile, crc));

FIN_CRC32C(crc);

if (!EQ_CRC32C(crc, map->crc))

ereport(FATAL,

(errmsg(“relation mapping file “%s” contains incorrect checksum”,

mapfilename)));

介紹完pg_filenode.map文件我們來(lái)回答前面的問(wèn)題，如果誤刪了該文件怎么辦呢？

如果該文件某個(gè)數(shù)據(jù)庫(kù)下的該文件刪除，那么該庫(kù)便無(wú)法連接：

pg14@vm-192-168-204-153-> psql bill bill

psql: error: connection to server on socket “/home/pg14/pgdata/.s.PGSQL.2022” failed: FATAL: could not open file “base/16385/pg_filenode.map”: No such file or directory

但是不會(huì)影響其它庫(kù)的連接：

pg14@vm-192-168-204-153-> psql postgres

psql (14.1)

Type “help” for help.

postgres=#

而如果global目錄下的該文件誤刪，那么所有庫(kù)均無(wú)法連接：

pg14@vm-192-168-204-153-> psql postgres

psql: error: connection to server on socket “/home/pg14/pgdata/.s.PGSQL.2022” failed: FATAL: could not open file “global/pg_filenode.map”: No such file or directory

pg14@vm-192-168-204-153-> psql bill

psql: error: connection to server on socket “/home/pg14/pgdata/.s.PGSQL.2022” failed: FATAL: could not open file “global/pg_filenode.map”: No such file or directory

因此我們可以知道，當(dāng)pg_filenode.map文件損壞或者被誤刪后，那么至少對(duì)應(yīng)的庫(kù)肯定是連接不上了，那么我們也沒(méi)辦法手工去創(chuàng)建該文件了。

不過(guò)一般來(lái)說(shuō)大部分庫(kù)的這個(gè)文件都是一樣的，很少會(huì)去對(duì)該文件進(jìn)行修改，除非你對(duì)這些系統(tǒng)表進(jìn)行了vacuum full之類的操作。而如果你真的不幸該庫(kù)做過(guò)類似操作那該怎么辦呢？只好先從其它庫(kù)拷貝一個(gè)文件過(guò)來(lái)，然后pg_filedump本庫(kù)的pg_class的數(shù)據(jù)文件看看相應(yīng)的系統(tǒng)表的信息，然后要注意，不要去直接修改pg_filenode.map文件，而是要去修改數(shù)據(jù)文件的文件名，讓其滿足pg_filenode.map中的映射關(guān)系。

為什么呢？我們前面說(shuō)過(guò)該文件尾部有一個(gè)根據(jù)文件名進(jìn)行計(jì)算的校驗(yàn)值，如果直接修改pg_filenode.map文件的話，則會(huì)提示校驗(yàn)值不對(duì)：

psql: error: connection to server on socket “/home/pg14/pgdata/.s.PGSQL.2022” failed: FATAL: relation mapping file “base/16385/pg_filenode.map” contains incorrect checksum

總結(jié)：

誤刪pg_filenode.map怎么辦？首先運(yùn)氣好的話從別的庫(kù)拷貝一個(gè)該文件，如果可用的話就可以直接使用。

而如果你的庫(kù)上該文件中的系統(tǒng)表做過(guò)vacuum full之類的操作，那么便需要通過(guò)類似pg_filedump的方式去pg_class的數(shù)據(jù)文件中獲取相關(guān)的信息，然后手動(dòng)修改相關(guān)數(shù)據(jù)文件名讓其滿足pg_filenode.map中的映射關(guān)系。

當(dāng)然該方法會(huì)很麻煩，所以還是要注意千萬(wàn)別誤刪了你的pg_filenode.map！

到此這篇關(guān)于PostgreSQL pg_filenode.map文件介紹的文章就介紹到這了,更多相關(guān)PostgreSQL pg_filenode.map內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

您可能感興趣的文章: