pg_filedumpの別の新機能：PostgreSQLディレクトリの復元

前回の記事では、 pg_filedumpユーティリティを使用して、完全に停止したPostgreSQLデータベースからデータ、または少なくともその一部を復元する方法を学びました。 どこかにテーブルから対応するセグメントの数を知っていると仮定しました。 テーブルの内容の一部を知っている場合、たとえば単純なgrepを使用して、そのセグメントを見つけることは実際に難しくありません。 ただし、より一般的なケースでは、これはそれほど簡単ではありません。 さらに、テーブルの正確なレイアウトを知っていると仮定しましたが、これも事実とは程遠いものです。 そのため、最近、同僚と私はpg_filedumpの新しいパッチを作成し、これらの問題を解決できるようにしました。

そこで、testというテーブルを復元したいとします。 テーブルの名前を覚えていなくても怖くないので、以下で説明する方法を使用すると、データベース内のすべてのテーブルの名前を取得できます。 テーブルに関する情報はpg_classカタログテーブルに格納され、そのセグメントには常に1259の番号が付けられます。

pg_filedumpの最新バージョンを使用すると、pg_classを次のように読み取ることができます。

./pg_filedump -D name,oid,oid,oid,oid,oid,oid,~ /path/to/base/16384/1259 | grep COPY | grep test
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

pg_filedumpに渡すデコードのタイプのリストに注意してください。

 name,oid,oid,oid,oid,oid,oid,~
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここで最初に、テーブルの最初の7列の型名を渡します（pg_classスキームは既知であり、ドキュメントで説明されています ）。チルダは残りの列を無視するように指示します。 この場合、それらはまだ私たちにとって興味深いものではありません;それらをすべてリストする必要はありません。

出力例：

 COPY: test 2200 16387 0 10 0 16385 COPY: test 2200 16387 0 10 0 16385 COPY: test_pkey 2200 0 0 10 403 16391
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

最後の列はrelfilenode、つまりセグメント番号です。 彼が必要です！ 覚えておいて、16385。

ただし、テーブルのレイアウトはわかりません。 pg_attributeカタログテーブルは、それを見つけるのに役立ちます。そのrelfilenodeはハードコードされ、1249に相当します。ところで、 pg_class.hファイル内のすべてのカタログテーブルのrelfilenodeを見ることができます 。

pg_attributeでドックを開き、デコードします ：

 ./pg_filedump -D oid,name,oid,int,smallint,~ /path/to/base/16384/1249 | grep COPY | grep 16385
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

出力例：

 COPY: 16385 k 23 -1 4 COPY: 16385 v 25 -1 -1 COPY: 16385 ctid 27 0 6 COPY: 16385 xmin 28 0 4 COPY: 16385 cmin 29 0 4 COPY: 16385 xmax 28 0 4 COPY: 16385 cmax 29 0 4 COPY: 16385 tableoid 26 0 4
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ご覧のとおり、テーブルにはkとvという名前の2つの列があります（残りはシステム列であり、MVCCが機能するために必要なものです。 ここで、23と25はatttypid、つまり列タイプです。 しかし、これらのタイプが何であるかを理解する方法

答えはpg_typeカタログテーブルに含まれています（relfilenode = 1247、 dock ）：

 ./pg_filedump -i -D name,~ /path/to/base/16384/1247 | grep -A5 -E 'OID: (23|25)'
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

出力例：

  XMIN: 1 XMAX: 0 CID|XVAC: 0 OID: 23 Block Id: 0 linp Index: 8 Attributes: 30 Size: 32 infomask: 0x0909 (HASNULL|HASOID|XMIN_COMMITTED|XMAX_INVALID) t_bits: [0]: 0xff [1]: 0xff [2]: 0xff [3]: 0x07 COPY: int4 -- XMIN: 1 XMAX: 0 CID|XVAC: 0 OID: 25 Block Id: 0 linp Index: 10 Attributes: 30 Size: 32 infomask: 0x0909 (HASNULL|HASOID|XMIN_COMMITTED|XMAX_INVALID) t_bits: [0]: 0xff [1]: 0xff [2]: 0xff [3]: 0x07 COPY: text
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

したがって、必要な情報はすべて手元にあります。 テーブルはテストと呼ばれ、relfilenode 16385を持ち、2つの列（int4型のkとtext型のv）が含まれています。 これで、 前の記事で説明したように、その内容をダンプできます 。

実際にあなたがこの知識を必要としないことを願っています:)質問や追加があれば、コメントでそれらを見て喜んでいるでしょう！