服务器＃1是一个在Debian上运行的MySQL数据库服务器，它包含大量的表和一个超过100GB的特定表。
服务器＃2用作复制的MySQL从服务器，但是现在需要重置服务器＃2，并且由于出现问题而重新初始化复制。
目前服务器＃1的硬盘上没有足够的空间来执行完整的数据库转储（即less于100GB的可用空间）。 除了升级需要停机的硬件之外，从服务器＃1到＃2服务器转储数据库的最佳方式是什么？没有损坏，并且没有在服务器＃1中填满硬盘驱动器？
您可以在不使用中间文件的情况下执行此操作，也可以在此过程中重置复制指针，以免错过任何更新（并且必须重新同步）
停止复制从属
奴隶> mysql的奴隶停止;“
将主服务器转储到从服务器，使用--master-data=1标志
master> mysqldump -e –master-data = 1 –single-transaction $ DATABASE | ssh -C user @ slave'mysql $ DATABASE'
在从机上启动复制
奴隶> mysql'奴隶开始'
--master-data=1会导致mysqldump发出转储顶部的CHANGE MASTER TO ...设置，以设置复制二进制日志和偏移到转储发生时主服务器binlog中的确切点
-e使用扩展的输出格式，基本上每个插入语句有多组值，这在线上和应用于从机时都更为有效。
--single-transation告诉mysql在整个dump中打开一个事务，而不是使用LOCK TABLES 。
快速和肮脏的方式（从服务器＃1开始）：
mysqldump -u root -p bigdb | bzip2 -c | ssh -T user@server2 "cat > backup.sql.bz2"
您可以从远程主机转储mysql数据库，只需在mysqldump中使用–host或-h参数即可
server2# mysqldump -h server1 -u root -p --opt | gzip > database.sql.gz server2# zcat database.sql.gz | mysql -u root -p
你显然可以跳转到磁盘，但import往往比倾销慢。 如果server2上的CPU是瓶颈，并且磁盘速度很快，那么您可能需要跳过gzip步骤，这样可以最大限度地减less主服务器上的停机时间。
显然，我的答案跳过了详细的logging复制细节，并确保你有一个一致的转储复制，因为这些都在MySQL手册中处理。
显然NFS，如果服务器之间没有防火墙。 如果你有一个防火墙，你可能需要重新configuration它，以允许NFS的一些额外的stream量工作。
类似的解决scheme稍微复杂一点，就是在server1上使用smbmount，在server2上使用smbd。
如果你不想混淆防火墙（或者你不想在服务器之间发送未encryption的数据），我会推荐sshfs。
最好的办法是，如果复制不是一个选项，并且本地服务器没有足够的磁盘空间，那么就要承受停机时间，并从实时数据库文件中完成同步。
根据networking连接的速度，这可能会导致比安装新磁盘更less的停机时间。
或者，考虑添加一个临时的USB海量存储设备到服务器，并使用它来抓取完整的数据库转储。 这应该导致零宕机。
如果这些盒子与彼此之间的距离在合理的物理距离之内，你可以附加一个USB驱动器，并在那里做你的数据存储库。
另一种方法是使用ssh /pipe道（如果在nix-box上运行的话），尽pipe取决于你用于存储的后端，如果试图离开mysqlprocess运行，表锁可能会对大表造成痛苦。
从mysqlbox2，如下所示：
ssh mysqlbox1 "mysqldump <options for username/pw/tables-to-dump>" > /path/to/spacious/fs/dbdump
如果您严格使用myisam表，请将mysql和cp数据文件从server1closures到server2。 你也可以保持mysql的状态，并把全局读锁放在只读中，然后把表写到表中。
编辑清晰并添加：
您也可以将server1上的表mysqldump转换为标准输出，并通过pipe道连接到server2。 但是，对于100GB的表，可能需要一些时间，并且仍然会要求您在需要任何一致性时将其设置为只读。