主持人 > Firebird 2.5 數據庫到 ODS12 格式的流式轉換（Firebird 3.0）

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 並創建一個新數據庫。

有必要使用本地（文件）訪問方法來組織這樣的管道，因為網絡訪問（即使通過本地主機）將顯著減慢該過程。

我們將在下面詳細介紹 Windows 和 Linux。

Windows

對於 Windows，最簡單的方法是製作完全獨立的 Firebird 版本。 為此我們採取 嵌入存檔 Firebird 2.5，將 fbemded.dll 重命名為 fbclient.dll，從“常規”2.5 存檔中添加 gbak.exe 和（可選）isql.exe 實用程序。

火鳥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開始構建索引。

為了加快 3.0 中的索引構建階段，建議將 TempCacheLimit 參數的大小增加到 ~40% RAM（當然，如果它是專用服務器）。

例如，如果服務器有 16 GB RAM，那麼您可以將 

TempCacheLimit=6G

當然，該值只能針對 64 位 Firebird 3 設置，因為任何 32 位進程都無法分配超過 2 GB 的內存。

在2.5中，這個參數不需要改變——反正不能超過2GB，而且不影響備份時的速度。

在執行操作之前，需要檢查數據庫頭中的頁緩存是否設置為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-style”），並且“帽子”（“^”字符）轉義換行符，這在鍵入長命令時很有用。 -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 的鏈接（符號鏈接）。 為此，您首先需要找到 tommath.so.1。

Ubuntu 中搜索的路徑 - /usr/lib/x86_64-linux-gnu/，但其他基於 Debian 的發行版可能有所不同。

第二個問題與 Firebird 3.0.1 及之前版本有關，沒有簡單的方法來安裝兩個不同的服務器版本。 我們不考慮“從具有所需前綴的源代碼編譯”選項，因為它相對複雜。

對於 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 的全新安裝 - 最好使用常規 tar.gz 安裝程序，而不是通過存儲庫，因為。 存儲庫中的版本可能會落後。

另外，在Linux上恢復數據庫並重新安裝後，您需要檢查新數據庫是否屬於firebird用戶所擁有。

如果情況並非如此，則需要進行更正。

chown firebird.firebird database

總

除了節省時間和磁盤空間之外，流式轉換還有另一個重要優點 - 數據庫轉換無需刪除現有的 Firebird 2.5 即可完成，這大大簡化了轉換不成功時的回滾（通常是由於遷移過程中缺乏空間或意外重啟）過程）。

節省時間是因為“經典”轉換是“備份時間”加上“恢復時間”。 恢復由兩部分組成：從備份文件中讀取數據和建立索引。

通過流式轉換，總時間為“備份時間加上百分之五到百分之十”和“索引構建時間”。

具體結果取決於數據庫的結構，但平均而言，恢復時間大約是備份時間的兩倍。 因此，如果我們以備份時間為單位，那麼“經典轉換”是三個時間單位，流媒體是兩個時間單位。 增加 TempCacheLimit 有助於進一步減少時間。

一般來說，實踐中的流式轉換可以節省 30-40% 的備用備份和恢復時間。

問題？

請在評論中寫下所有問題，或將其發送給該方法論的作者和本文的合著者 - Vasily Sidorov，iBase 領先系統工程師，ibase ru 的 bs。

只有註冊用戶才能參與調查。 登入， 請。

您使用什麼版本的火鳥？

  • 火鳥 3.x

  • 火鳥 2.5

  • 火鳥 2.1

  • 火鳥 2.0、1.5 或 1.0

16 位用戶投票。 1 位用戶棄權。

來源： www.habr.com

添加評論