修改备份中的数据库以删除重复键标记,以免在还原时失败

这篇帖子是我过去 24 小时的精简版,尽管它实际上还没有成功,所以我希望有人能在下面发帖说明哪里出了问题。

我的 Discourse 更新因重复键而失败,我的一个标签重复了。为了解决更新问题,我需要进行一次全新的 Discourse 安装,然后加载我最新的备份,但加载失败,因为它抱怨重复键。所以,我需要进入备份内部编辑有问题的标签,将其更改为其他内容。

出于某种原因,重新压缩的备份(已修复重复标签问题)比原始备份小得多,并且在我尝试恢复时失败,因此重新压缩过程出了点问题。

1) 查找备份: 要查找您的 Discourse 备份,您可以使用以下命令:

sudo find / -name "*.tar.gz"

这将搜索您的系统上所有扩展名为“.tar.gz”的备份文件。默认情况下,它应该在您的容器内:shared/backups/default

2) 创建副本: 找到要使用的备份后,请创建该文件的副本,以确保您拥有原始文件的备份。使用“cp”命令:

bash

sudo cp /path/to/original_backup.tar.gz /path/to/copy_backup.tar.gz

3) 提取副本: 使用“tar”命令提取复制的备份文件的内容:

bash

tar -xzvf /path/to/copy_backup.tar.gz

这将把备份文件提取到一个临时目录。

4) 编辑数据库中的标签: 导航到提取的备份文件,并使用文本编辑器打开相关的数据库文件。我遇到了重复的“socialmedia”标签问题,这阻止了成功恢复。在一个大的数据库中,有很多标签的实例,很可能也有您要查找的特定标签,所以我使用 Nano 中的 Ctrl W 搜索了“immutable socialmedia”,这直接带我到了那里。

sudo nano /path/to/extracted_database.sql

我将一个“socialmedia”标签实例编辑为“socialmedia2”,然后快速搜索以检查它现在是否只出现一次。一旦恢复成功,我就可以从管理部分修复这些标签。

5) 重新压缩: 编辑备份文件后,创建一个包含已更正内容的新备份文件。使用以下命令压缩修改后的文件:

tar -czvf /path/to/new_modified_backup.tar.gz /path/to/modified_files_directory

6) 移动到正确的文件: 将新的修改后的备份文件移动到存储备份的适当目录。默认位置通常是“/shared/backups/default”:

sudo mv /path/to/new_modified_backup.tar.gz /shared/backups/default/

7) 停止和启动服务: 在恢复修改后的备份之前,请确保停止相关服务,以避免在恢复过程中可能发生的冲突。使用“./launcher stop app”命令停止 Discourse 应用程序:

./launcher stop app

8) 恢复备份: 要从修改后的备份恢复,请使用指向新备份文件的“discourse restore”命令:

discourse restore /shared/backups/default/new_modified_backup.tar.gz

或者您可以通过您的网站上的 /admin 进行操作,因为它现在应该出现在备份部分。

9) 验证恢复: 恢复过程完成后,我通过检查 Discourse 应用程序和数据库来验证更改是否成功,以确保已删除重复的“socialmedia”标签。

10) 启动服务: 我重新启动了之前停止的服务,以使 Discourse 应用程序重新联机。我使用“./launcher start app”命令启动 Discourse 应用程序:

./launcher start app

11) 删除临时文件和额外备份: 成功恢复备份后,我删除了在此过程中创建的任何临时文件和额外备份,以释放磁盘空间。使用“rm”命令删除文件:

sudo rm -r /path/to/temporary_directory
sudo rm /path/to/copy_backup.tar.gz
3 个赞

为什么?

为什么你不能通过重启应用程序、进入容器、进入 postgres 然后立即处理数据输入来“在线”修复这个问题?

1 个赞

我没想到会出现错误,所以我已经将新版本的 Discourse 部署到了我的服务器上。重复键错误出现在备份中,而不是干净安装的应用程序中,但我无法恢复备份,因为它要求先修复错误。

所以我不得不尝试编辑备份中的标签。

但是你看到了更新中的错误吗?

下次让你的生活更轻松,并就地修复。

应用程序未运行,我也无法重新加载它,因此我更新到了最新的 Discourse 版本以尝试修复此问题。这意味着除了备份之外,我无法访问数据库。

这肯定是我在这里发布的一个小众案例,更好的选择是在我仍然可以直接访问应用程序数据库时注意到问题并修复它,但我错过了它,也找不到其他选择。

1 个赞

没关系。至少你已经证明了这是可能的,学到了一些新东西,并为其他人提供了一个额外的选择。

干得好!:clap:

3 个赞

谢谢,尽管原始文件是 128MB,而新文件是 29MB,所以我认为服务器上的重新压缩可能由于文件过长而截断了文件。

这个过程似乎应该有效,但我最终得到的文件无法用于恢复我的 discourse。

1 个赞

你选择的路径风险更大,但肯定是可以完成的?也许有人能就这个问题提供一些建议。

你可以假设可以从备份中再次重复这个操作,所以……

1 个赞

这个问题解决了吗?看起来像是一个操作指南,但你们的网站似乎仍然有问题。

也许你们的做法是我不理解的,但通常你只需要运行 ./launcher start app 来启动旧容器,有什么原因导致你不能这样做吗?

然后你可以使用 Rails 或 SQL 工具来修复旧容器中的数据库,然后再尝试运行 bootstrap/rebuild。

或者,你们可能将数据库迁移到了旧容器无法处理的程度。

我以前在恢复一个一年或更久以前的网站的备份时做过类似的操作。我认为数据库转储足够小,我可以用 vim 编辑它。

1 个赞

感谢您的回复。

它拒绝启动,因为我们落后了几个版本,所以我通过创建一个新的容器并上传了旧的备份来更新到最新的 Discourse,但它由于重复的键而拒绝了该备份。

或者您可能迁移了数据库,超出了旧容器的处理能力。

是的,很可能是这样。我现在具体做了什么有点模糊,但我根据这里的故障排除建议独立更新了一些东西。其中之一是获取最新的 PostgreSQL 版本。

我能够在 vim 中编辑它。

我能够在 Nano 中编辑它,一切看起来都很好,但重新压缩的文件太小了,所以某个地方出了问题……也许我无法在 Nano 中编辑它。当时看起来是成功的。

我希望有人能发现其中的错误并纠正我,这样它就能成为一个“操作指南”。

接下来我会查看:

  • 重新进行整个解压。保持不变地进行压缩。检查压缩大小是否与之前相同。如果不是,也许你没有使用相同的选项进行压缩?

  • 再次解压,检查你正在编辑的文件的文件大小。编辑它,保存它,确认大小没有显著变化。

1 个赞

一点更新。我团队里的其他人上周也在处理这个问题,但没有找到解决方案,所以我又试了一次,这次是通过编辑我本地系统上的数据库。

我做了什么:

  1. 下载了我想要恢复的旧备份
  2. 使用 7zip 解压文件
  3. 使用 visual studio code 打开 dump.sql
  4. 直接在数据库中找到重复的标签。
  5. 通过搜索标签周围的“ ”找到了看起来像是标签列表的内容。在我的例子中是“socialmedia”。找到的实例中,标签似乎是倒数第二个和第三个。

  1. 编辑了一个,使其显示为

132 ‘socialmedia2’:1A socialmedia2 en_GB 3

  1. 使用 7zip 重新压缩 dump.sql 文件
  • 添加到存档
  • 存档格式 .gzip
  1. 重新压缩主备份文件
  • 添加到存档
  • 存档格式 .tar (gzip 尚不可用)
  1. 您现在应该看到一个已压缩的 .tar 修复备份文件

  2. 使用 7zip 压缩 .tar 文件以创建 .tar.gz 文件,以匹配 Discourse 使用的格式

  • 添加到存档
  • 存档格式 .gzip
  1. 上传到备份并通过管理部分进行恢复

此时我遇到了一个错误消息:

正在提取转储文件…
[2023-08-08 15:09:15] EXCEPTION: No such file or directory @ rb_check_realpath_internal - /var/www/discourse/tmp/restores/default/2023-08-08-150913/dump.sql.gz

有人知道我在上述过程中遗漏了什么吗?
我唯一能想到的是,它正在查找的路径使用了今天的日期而不是备份的日期(我写这个的时候是 2023-08-08)。

这是我之前帖子 此处 的后续。我再次发帖,以便将来其他人进行此操作时更容易找到,如果它有效的话。

我在笔记本电脑上编辑数据库的操作如下:

  1. 从管理部分下载要恢复的旧备份
  2. 使用 7zip 解压文件
  3. 使用 visual studio code 打开 dump.sql
  4. 直接在数据库中找到重复的标签。
  5. 通过搜索标签周围的空格来找到似乎是标签列表的内容。在我的例子中是 ‘socialmedia’。找到的实例中,标签似乎是倒数第二个和第三个。

  1. 编辑其中一个,使其显示为

132 ‘socialmedia2’:1A socialmedia2 en_GB 3

  1. 使用 7zip 重新压缩 dump.sql 文件
  • 添加到存档
  • 存档格式 .gzip
  1. 重新压缩主备份文件
  • 添加到存档
  • 存档格式 .tar (gzip 尚不可用)
  1. 您现在应该看到一个已压缩的 .tar 备份文件

  2. 使用 7zip 压缩 .tar 文件以创建 .tar.gz 文件,以匹配 Discourse 使用的格式

  • 添加到存档
  • 存档格式 .gzip
  1. 上传到备份并从管理部分恢复

此时我遇到了一个错误消息:

正在提取转储文件…
[2023-08-08 15:09:15] 异常:No such file or directory @ rb_check_realpath_internal - /var/www/discourse/tmp/restores/default/2023-08-08-150913/dump.sql.gz

有人知道我在上述过程中错过了什么吗?
我唯一能想到的是,它正在查找的路径使用了今天的日期而不是备份的日期(我写这个的时候是 2023-08-08)。

1 个赞

我认为备份文件的确切名称可能很重要:论坛名称、日期和时间戳、版本标识符。因此,如果解包、修改和重新打包,我建议重建为与原始文件相同的名称。但当然要妥善保管原始文件。

1 个赞

我已将新主题中的帖子合并到此帖中,因为将此问题集中在一个地方将使未来的旅行者更容易跟踪。 :+1:

1 个赞

感谢 @Ed_S,我保留了原始名称,因为我在其他地方读到它很重要。我上面关于备份恢复工具正在寻找但找不到以下内容的疑问:/var/www/discourse/tmp/restores/default/2023-08-08-150913/dump.sql.gz

这是我进行恢复的日期。

1 个赞

啊,抱歉。这确实有点奇怪。临时目录可能完全按照今天的日期命名,但找不到 sql 转储文件看起来不太好。

如果您列出 tar 文件内容,您是否在其中看到了该文件名?在我的例子中

root@ubuntu-2gb-nbg1-1:/var/discourse/shared/standalone/backups/default# tar vtfz forumname-2023-08-03-HHMMSS-v2023mmddhhmmss.tar.gz dump.sql.gz | head
-rw-r--r-- discourse/www-data 16336925 2023-08-03 05:31 dump.sql.gz
1 个赞

谢谢 Ed,那个文件不存在。抱歉耽搁了,我离开网络一段时间了。

那里没有正确命名的文件,所以我只是尝试手动创建一个空文件:

sudo mkdir -p /var/www/discourse/tmp/restores/default/2023-08-22-121010/

但是每次我点击恢复时,它都会寻找一个略有不同的文件(最后 6 位数字)。我猜它正在寻找一个由时间戳生成的文件夹,所以每次我点击恢复按钮时,它正在寻找的文件夹都会改变。

我怀疑你的第 10 步创建 tar 文件时出了问题。你能看到它吗?你能用 file 命令描述它吗?你能用 tar tvfz 列出它的内容吗?

1 个赞