主持人 > 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

  • Firebird 2.5

  • Firebird 2.1

  • 火鸟 2.0、1.5 或 1.0

由 16 位用户投票。 1 位用户弃权。

来源： habr.com

添加评论