☰

可靠地将数据库转储直接写入远程文件系统（Linux）

tag-icon • tag-icon database migration file-transfer database-backup sshfs
可靠地将数据库转储直接写入远程文件系统（Linux）

我需要将一个非常大的数据库（约 320 GB）从服务器1到服务器2（Linux）。由于扩展版本不同，数据库只能在服务器2从转储文件中描述这里。

问题是我没有足够的空间服务器1首先在那里写入转储文件，然后将其复制到服务器2并验证总数。我需要一种可靠的方法将数据直接写入服务器2，最大限度地降低腐败风险。

我试过：

  • 通过管道将垃圾从服务器1到服务器2使用nc。
  • 直接将转储文件写入服务器2挂载在服务器1使用sshfs。

两个转储文件似乎都已损坏（大小差别很大，并且与导入的不同阶段的损坏相关的错误）。

我迁移了这样的数据库（但规模小得多），没有出现问题。有人能建议一种更好、更可靠的方法来完成这种大规模传输吗？

更新：尝试了 NFS，结果相同。显然远程文件系统无法处理如此大量的数据。生成的 SQL 文件中明显缺少块，导致导入期间出现语法错误。每次尝试时，文件的不同部分都会损坏。

答案1

那么先在服务器 1 上安装外部 NFS 共享，然后在转储后安装到服务器 2 怎么样？这就是我执行 Oracle 数据库数据泵和 RMAN 备份（类似于您的转储）的方式，最佳结果是将生产服务器（服务器 1）复制到测试服务器（服务器 2）并恢复备份。我们的外部 NFS 依赖于 NAS，但任何 Gnu/Linux 都可以完成这项工作，只需安装必要的软件包即可

跟随这些步骤对于 Debian，设置共享后通过 /etc/fstab 将其挂载到服务器 1 和服务器 2 上

nfs_server:/path/to/share /server1or2filesystem/mountpoint nfs rw,hard,intr,timeo=600,actimeo=0,proto=tcp,bg,rsize=262144,wsize=262144 0 0

我从未遇到过 NFS 共享上的转储损坏问题（除非发生连接故障），并且如果您在测试 NFS 时再次发现损坏，您可以尝试本地部分转储，以便在本地转储也损坏时丢弃转储工具上的错误配置。

答案2

尝试先进先出系统（安德鲁·FS）。 这文件系统是本身设计为可扩展的，面向网络并能为您的问题提供良好的解决方案。如果Ubuntu使用开放AFS。请记住，在建立可靠的连接之前，需要进行一些配置和设置。

答案3

您可以尝试通过这个单行程序直接导入它：

mysqldump --add-drop-table --extended-insert --force --log-error=error.log -uUSER -pPASS OLD_DB_NAME | ssh -C user@newhost "mysql -uUSER -pPASS NEW_DB_NAME"

但无法通过网络可靠地复制。您确定没有网络或文件系统问题吗？

答案4

我得到了最佳答案这里最好的方法是通过远程转储源数据库直接在接收服务器上创建转储文件：

pg_dump -h remoteserver -U remoteuser remotedbname -Fc -f my_old_server_backup.dump

这比通过网络文件系统写入大型 SQL 文件要可靠得多。我现在有一个正常运行的迁移数据库！

相关内容