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に送信します。stdoutはすぐにstdinを介して3.0からgbakを取得し、新しいデータベースを作成します。
ネットワークアクセス（ローカルホスト経由であっても）によりプロセスが大幅に遅くなるため、ローカル（ファイル）アクセス方式を使用してこのようなパイプラインを編成する必要があります。
以下では、WindowsおよびLinuxの詳細を見ていきます。
窓
Windowsの場合、最も簡単な方法は、Firebirdの完全に自律的なビルドを作成することです。 これを行うには、 Firebird 2.5 embed-archiveを使用し 、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
経験豊富な管理者は、intl / fbintl.dllとintl / fbintl.confが2.5に含まれていないことに気付くかもしれません。 これは、gbakが接続文字を使用したり、文字間でデータを変換したりしないためです。ただし、Firebird 3.0の「受信」側では、インデックスを作成するときにこれらのファイルが必要です。
firebird.confで、Firebird 3.0は以下を追加することを推奨します。
MaxUnflushedWrites = -1 MaxUnflushedWriteTime = -1
また、2.5と3.0に異なるIpcName値を設定することをお勧めします。
他のパラメーターの値を選択するとき、firebird.confは単純な検討から進みます。データ転送段階で、1つのプロセスでgbakが2.5を実行し、他の3.0では2.5が終了し、3.0がインデックスの構築を開始します。
3.0でインデックスを構築する段階をスピードアップするには、TempCacheLimitパラメーターのサイズを〜40％RAMに増やすことをお勧めします（もちろん、専用サーバーの場合）。
たとえば、サーバーに16 GBのRAMがある場合、次のように配置できます。
TempCacheLimit=6G
もちろん、32ビットプロセスは2ギガバイトを超えるメモリを割り当てることができないため、この値は64ビットFirebird 3にのみ設定できます。
2.5では、このパラメーターを変更する必要はありません。既に2ギガバイトを超えることはできません。また、バックアップ中の速度に影響しません。
操作を実行する前に、データベースヘッダーのページキャッシュが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スタイル」）を使用し、「hat」（「^」文字）は改行文字をエスケープします。これは、長いコマンドを入力するときに便利です。 -st（atus）オプションはFirebird 2.5.8で登場し、gbakプロセスの動作時間に関するデータをプロトコルに書き込むことができます（詳細についてはドキュメントを参照してください）。
Linux
Linuxでは、Firebird 3はtommathライブラリに依存しています。 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へのリンク（symlink）を作成する必要があります。 これを行うには、まずtommath.so.1を見つける必要があります。
Ubuntuの検索パスは
/usr/lib/x86_64-linux-gnu/
ですが、他のDebianベースのディストリビューションでは異なる場合があります。
2番目の問題は、Firebird 3.0.1以前では、2つの異なるバージョンのサーバーをインストールする簡単な方法がなかったことです。 「必要なプレフィックスを使用してソースからコンパイルする」オプションは、その相対的な複雑さのため、考慮しません。
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 3.0のクリーンインストールを実行する必要があります。これは、リポジトリではなく通常のtar.gzインストーラーから行うのが最適です リポジトリ内のバージョンが遅れる場合があります。
また、Linuxデータベースを復元して再インストールした後、新しいデータベースにfirebirdユーザーの所有者がいることを確認する必要があります。
そうでない場合は、修正する必要があります
chown firebird.firebird database
まとめ
時間とディスクスペースの節約に加えて、ストリーム変換には別の重要な利点があります-既存のFirebird 2.5を削除せずにデータベース変換が行われるため、変換が失敗した場合のロールバックが大幅に簡素化されます（ほとんどの場合、移行プロセス中のスペース不足または予期しない再起動による）。
時間の節約は、「古典的な」変換が「バックアップ時間」と「回復時間」であるという事実によるものです。 リカバリは、バックアップファイルからのデータの読み取りとインデックスの構築の2つの部分で構成されています。
ストリーミング変換では、合計時間は「バックアップ時間+ 5〜10％」および「インデックス作成時間」として取得されます。
具体的な結果はデータベースの構造に依存しますが、平均して、回復時間は二重バックアップ時間にほぼ等しくなります。 したがって、バックアップ時間をユニットごとに取る場合、「クラシック変換」は3単位の時間、およびストリーム変換-2単位の時間を意味します。 TempCacheLimitの増加は、時間の短縮にも役立ちます。
一般に、実際のストリーム変換により、代替バックアップとレストランの時間を30〜40％節約できます。
ご質問は？
コメントにすべての質問を書くか、この記事の方法論の著者および共著者であるibase ruのbsのiBaseのリードシステムエンジニアであるVasily Sidorovに質問を送信してください。