问题描述
在将一个非常大的表（约500百万行）从一个MySQL模式迁移到另一个模式时，使用了mysqldump备份工具。由于数据库位于AWS上，用户通过终端与Ubuntu服务器建立SSH连接，然后从命令行运行命令。一切都按预期工作，用户可以在终端上看到进程输出，但是一旦电脑休眠或遇到网络连接中断，就会遇到一个问题：client_loop: send disconnect: Broken pipe。
尽管这可能是正常情况，但是重新连接到Ubuntu服务器后，用户在终端上看不到进程输出，也无法在进程列表中看到相应的进程。用户不确定终端与服务器失去连接后，mysqldump会在服务器上终止而未完成。
为了确保情况，用户想要知道：
1. 是否可能发生这种情况？
2. mysqldump将其进程日志记录在哪里，以便可以查看日志文件并了解发生了什么？
解决方案
请注意以下操作可能会因版本不同而有所变化，请确保在进行任何操作之前做好备份。
是否可能发生连接中断导致mysqldump中止？
是的，当你的终端关闭时，该进程的标准输出文件描述符也会关闭，因此没有地方可以写入输出。
mysqldump输出写入日志文件
一种方法是将输出重定向到文件中，这样你可以在终端上看不到输出，但可以看到文件的大小逐渐增加，直到备份完成。
使用以下命令将输出重定向到文件：
mysqldump > backup_file_name.sql
这样，你将不会在终端上看到输出，但会在备份完成时看到文件的增长。
使用screen或tmux保持终端会话
你还可以使用诸如screen或tmux之类的程序来保持终端会话，以便在重新连接时可以重新连接到输出。然而，不要将备份内容直接写入终端，这样会导致写入速度变慢。
你可以使用以下命令创建一个新的screen会话并运行mysqldump：
screen -S mysqldump_session
mysqldump > backup_file_name.sql
在这种情况下，你可以通过以下命令重新连接到会话：
screen -r mysqldump_session
使用tee同时输出到终端和文件
如果你希望在终端上看到输出的同时，将输出写入文件，你可以使用tee命令：
mysqldump | tee backup_file.sql
这将把输出分割并同时写入终端和文件。
关于备份的建议
如果你正在备份AWS RDS实例，它已经具有一些自动备份，并且可以通过UI或编程方式触发手动备份。如果你在自己的实例上备份运行的MySQL，并且将备份存储在同一实例上，这实际上不是一个很好的备份。你应该将备份文件复制到S3或其他位置。
请注意，尽管终端输出中只显示类似于Dump progress: 0/1 tables, 281222750/435250801 rows的信息，使用tee命令仍然可以将这些信息写入文件中，以便在需要时进行检查。
总结
在Linux/Ubuntu上，你可以通过将输出重定向到文件、使用screen或tmux来保持终端会话，或者使用tee命令同时输出到终端和文件，来解决mysqldump输出日志问题。确保在进行任何操作之前做好备份，并根据实际情况选择适合你的方法。
这些建议基于你提供的问题描述和回复，可能会因不同环境和版本而有所不同。在执行任何操作之前，请确保理解操作的影响并做好必要的准备工作。