Firebird 2.5 データベースから ODS12 形式へのストリーミング変換 (Firebird 3.0)

Firebird の各バージョンには、独自のバージョンのデータベース ディスク構造形式、O(n)D(isk)S(tructure) があります。 バージョン 2.5 までは、Firebird エンジンは以前のバージョンの ODS で動作できました。つまり、古いバージョンのデータベースは新しいバージョンで開かれ、互換モードで動作しましたが、Firebird 3.0 エンジンは独自の ODS バージョンのデータベースでのみ動作しました。 12.0。

3.0 に移行するには、バックアップ/復元によって 2.5 のデータベースを新しい形式に変換する必要があります。 もちろん、データベースは事前に変換の準備ができていることを前提としています。 メタデータとクエリは Firebird 3.0 との互換性がチェックされています。

標準的なアプローチに従う場合、バージョン 2.5 でバックアップを作成し、その後 3.0 をインストールして復元する必要があることを意味します。 十分な時間があればこのような手順でも問題ありませんが、大規模なデータベースを移行する場合や、数十のデータベースを同時に移行する場合など、時間が足りなくなった場合は、ストリーミング変換を使用すると 30 ～ 40% 高速になります。 これを正確に行う方法 (Windows および Linux で) は、カットの下をお読みください。

一般的な考え方は、パイプラインを使用して処理を高速化するということです。

gbak -b … база25 stdout | gbak -c … stdin база30

2.5 の Gbak はリニア形式でバックアップを生成し、それを stdout に送信します。これにより、stdin 経由で 3.0 から gbak がすぐに取得され、新しいデータベースが作成されます。

ネットワーク アクセス (localhost 経由であっても) はプロセスの速度を大幅に低下させるため、このようなパイプラインはローカル (ファイル) アクセス方法で編成する必要があります。

以下で Windows と Linux について詳しく説明します。

Windows

Windows の場合、最も簡単な方法は、Firebird の完全にスタンドアロン ビルドを作成することです。 このために私たちは取る 埋め込みアーカイブ Firebird 2.5、fbemded.dll の名前を fbclient.dll に変更し、「通常の」2.5 アーカイブから gbak.exe および (オプションで) isql.exe ユーティリティを追加します。

Firebird 3.0 の用途 単一アセンブリ 変更は必要ありません。

最も最小限のバージョン (ターゲット システムに VS2008/VS2010 ランタイム ライブラリをインストールする必要がない) には、次のファイルが含まれています。

25/gbak.exe
25/fbclient.dll
25/firebird.conf
25/firebird.log
25/firebird.msg
25/ib_util.dll
25/icudt30.dll
25/icuin30.dll
25/icuuc30.dll
25/Microsoft.VC80.CRT.manifest
25/msvcp80.dll
25/msvcr80.dll

30/fbclient.dll
30/firebird.conf
30/firebird.msg
30/gbak.exe
30/ib_util.dll
30/icudt52.dll
30/icudt52l.dat
30/icuin52.dll
30/icuuc52.dll
30/msvcp100.dll
30/msvcr100.dll
30/intl/fbintl.conf
30/intl/fbintl.dll
30/plugins/engine12.dll

経験豊富な管理者は、2.5 に intl/fbintl.dll および intl/fbintl.conf ファイルが含まれていないことに気づくかもしれません。 gbak は接続文字セットを使用せず、文字セット間でデータを変換しないため、これは事実ですが、Firebird 3.0 の「受信」側では、インデックスを作成するときにこれらのファイルが必要になります。

Firebird 3.0 では、firebird.conf に以下を追加することをお勧めします。

MaxUnflushedWrites = -1
MaxUnflushedWriteTime = -1

また、2.5と3.0では異なるIpcName値を設定することが望ましいです。

firebird.conf の他のパラメータの値を選択するときは、単純な考慮事項から進めます。データ転送の段階で、gbak は 2.5 つのプロセスで 3.0 を実行し、別のプロセスで 2.5 を実行します。その後、3.0 が終了し、XNUMX がビルドを開始します。インデックス。

3.0 でインデックス構築フェーズを高速化するには、TempCacheLimit パラメータのサイズを RAM の最大 40% に増やすことをお勧めします (もちろん、専用サーバーの場合)。

たとえば、サーバーに 16 GB の RAM がある場合、次のように入力できます。

TempCacheLimit=6G

もちろん、64 ビット プロセスでは 3 GB を超えるメモリを割り当てることができないため、この値は 32 ビット Firebird 2 にのみ設定できます。

2.5 では、このパラメータを変更する必要はありません。いずれにしても 2 GB を超えることはできず、バックアップ中の速度には影響しません。

操作を実行する前に、データベース ヘッダーのページ キャッシュが 0 に設定されていることを確認する必要があります (コマンド gstat -h databasename、ページバッファ行を参照してください)。

キャッシュがデータベース ヘッダーで明示的に設定されている場合、firebird.conf (および 3.0 では databases.conf) の値が上書きされ、値が不適切に大きい場合は過剰なメモリ消費とスワップが発生する可能性があります。

次に、ファイルをターゲット システムにコピーします。

変換は、「システム」Firebird 2.5 サービスを停止した後、ローカル管理者への昇格された権限を持つコマンド ラインで実行されます (例)。

set ISC_USER=владелец
"25/gbak" -z -b -g -v -st t -y 25.log база25 stdout|^
"30/gbak" -z -c -v -st t -y 30.log stdin база30

この例では、引用符で「スラッシュ」を使用し (有効な「unix スタイル」)、「ハット」 (「^」文字) で改行文字をエスケープします。これは、長いコマンドを入力するときに便利です。 -st(atus) オプションは Firebird 2.5.8 で登場し、gbak プロセスの実行時間に関するデータをログに記録できるようにします (詳細については、ドキュメントを参照してください)。

Linux

Linux では、Firebird 3 は tomath ライブラリに依存します。 CentOS (RHEL) では、このライブラリは epel リポジトリにあり、Ubuntu (Debian) ではシステム リポジトリにあります。

CentOS の場合は、まず epel リポジトリに接続してから、次のことを行う必要があります。

yum install libtommath

Ubuntu には追加のリポジトリを含める必要はありませんが、Ubuntu 16 と Ubuntu 18 では異なるバージョンのパッケージ (それぞれ libtommath0 と libtommath1) がインストールされます。

Firebird 3.0 は tommath.so.0 を検索し、Ubuntu 18 の場合はさらに tommath.so.0 から tommath.so.1 へのリンク (シンボリックリンク) を作成する必要があります。 これを行うには、まず tommath.so.1 を見つける必要があります。

Ubuntuで検索されたパス - /usr/lib/x86_64-linux-gnu/ですが、他の Debian ベースのディストリビューションでは異なる場合があります。

3.0.1 番目の問題は、Firebird XNUMX までは、XNUMX つの異なるサーバー バージョンをインストールする簡単な方法がなかったという事実に関連しています。 「必要なプレフィックスを使用してソースからコンパイルする」オプションは比較的複雑であるため、考慮しません。

Firebird 3.0.2以降が実装されている場合 --enable-binreloc でビルドする および別のインストーラー オプション (-path パス)。

tommath ライブラリと、必要に応じて tommath.so.0 のシンボリックリンクがシステムに追加されていると仮定すると、現在の (この記事の執筆時点で) Firebird 3.0.4 ディストリビューションを /opt などにインストールできます。 /fb3:

./install.sh -path /opt/fb3

その後、Firebird システムサービスを停止し、ストリーミング変換を開始できます。

Firebird を停止するときは、クラシック モードの Firebid 2.5 プロセスは通常、xinetd によって開始されることに注意してください。したがって、xinetd の Firebird サービスを無効にするか、xinetd を完全に停止する必要があります。

Linux 上の 3.0 の firebird.conf では、MaxUnflushed パラメータを設定したり (Windows でのみ機能します)、Firebird 2.5 の設定を変更したりする必要はありません。

Linux では、Firebird 2.5 のローカル (ファイル) アクセスは Windows の組み込みバージョンと同等ではありません。2.5 サーバーは gbak プロセス (ネットワーク部分なし) で動作しますが、アクセス権はユーザー ベースに対してチェックされます。ログインだけでなくパスワードも必要となります。

export ISC_USER=username ISC_PASSWORD=password
/opt/firebird/bin/gbak -b … база25 stdout
|/opt/fb3/bin/gbak -c … stdin база30

変換が成功したら、まず「追加」の Firebird 3.0 をアンインストールし、次に「メイン」の Firebird 2.5 をアンインストールし、その後 Firebird 2.5 のクリーン インストールを実行する必要があります。これは、リポジトリだからです。 リポジトリ内のバージョンが遅れている可能性があります。

また、Linux 上でデータベースを復元して再インストールした後、新しいデータベースが Firebird ユーザーによって所有されていることを確認する必要があります。

そうでない場合は、修正する必要があります。

chown firebird.firebird database

合計

時間とディスク容量の節約に加えて、ストリーミング変換にはもう 2.5 つの重要な利点があります。既存の Firebird XNUMX を削除せずにデータベース変換が行われるため、変換が失敗した場合 (ほとんどの場合、容量不足や移行中の予期しない再起動が原因で) のロールバックが大幅に簡素化されます。プロセス）。

時間の節約は、「クラシック」変換が「バックアップ時間」に「復元時間」を加えたものであるためです。 リカバリは、バックアップ ファイルからのデータの読み取りとインデックスの構築の XNUMX つの部分で構成されます。

ストリーミング変換の場合、合計時間は「バックアップ時間 + XNUMX ～ XNUMX%」と「インデックス構築時間」として求められます。

具体的な結果はデー​​タベースの構造によって異なりますが、平均すると、リカバリ時間はバックアップ時間の約 XNUMX 倍になります。 したがって、バックアップ時間を単位とすると、「クラシック変換」は XNUMX 単位時間、ストリーミングは XNUMX 単位時間となります。 TempCacheLimit を増やすと、時間をさらに短縮できます。

一般に、実際のストリーミング変換により、代替バックアップと復元にかか​​る時間を 30 ～ 40% 節約できます。

質問は？

すべての質問をコメントに記入するか、方法論の著者でありこの記事の共著者である Vasily Sidorov (iBase ru の bs の iBase リーディング システム エンジニア) に送信してください。

登録ユーザーのみがアンケートに参加できます。 ログインお願いします。

Firebird のどのバージョンを使用していますか?

• ファイアバード 3.x

• ファイアバード2.5

• ファイアバード2.1

• ファイアバード 2.0、1.5、または 1.0

16 人のユーザーが投票しました。 1 ユーザーが棄権しました。

出所： habr.com