Mc: 如果文件大小匹配，Minio 无法在更改后镜像文件

@xoxys你可以分享你的mc mirror命令行吗？

@harshavardhana肯定：

mc mirror --no-color --overwrite --remove downloads/testing /local/path/testing

你好，

我也确认我有完全相同的问题。 使用--md5不会做任何事情（顺便说一句，minIO 客户端指南中缺少此选项）。

我还在本地删除了文件，创建了一个具有相同名称的新文件，并放置了一些大小完全相同的随机内容，但文件没有上传。

我正在运行最新版本的 minIO ( RELEASE.2020-07-31T03-39-05Z ) 和 mc( RELEASE.2020-07-31T23-34-13Z )。

作为“解决方法”，唯一的方法是mc rm --recursive --force然后mc cp --recursive但这根本没有效率。

mc mirror --json --overwrite --remove --preserve --md5 "${APTLY_DIR}/apt/db" "${APTLY_MINIO_PATH}/apt/db"
{
 "status": "success",
 "total": 0,
 "transferred": 0,
 "speed": 0
}

请问有这方面的更新吗？

这实际上非常容易重现。

mc mb minio/test
mkdir tmp
cd tmp
echo "this is some random content" > content.txt
mc mirror --json --overwrite --remove --preserve --md5 ./ minio/test/
# {
#  "status": "success",
#  "source": "/root/tmp/content.txt",
#  "target": "minio/test/content.txt",
#  "size": 28,
#  "totalCount": 1,
#  "totalSize": 28
# }
# {
#  "status": "success",
#  "total": 0,
#  "transferred": 56,
#  "speed": 2485.540810183332
# }

echo "this is SOME rand0m c0ntent" > content.txt
# Note the file size is the same but the content is different.

mc mirror --json --overwrite --remove --preserve --md5 ./ minio/test/
# {
#  "status": "success",
#  "total": 0,
#  "transferred": 0,
#  "speed": 0
# }

rm content.txt
mc mirror --json --overwrite --remove --preserve --md5 minio/test/ ./
# {
#  "status": "success",
#  "source": "minio/test/content.txt",
#  "target": "content.txt",
#  "size": 28,
#  "totalCount": 1,
#  "totalSize": 28
# }
# {
#  "status": "success",
#  "total": 0,
#  "transferred": 56,
#  "speed": 9440.131109935215
# }

cat content.txt # the file content is the original content from the first 'echo command'
# this is some random content

嗨@aureq ，
完成当前正在处理的问题后，我将立即对此进行调查。

使用来自@aureq的复制器进行

• 好的：
  
  
  
  • https://dl.min.io/client/mc/release/linux-amd64/archive/mc.RELEASE.2020-05-16T01-44-37Z
  
  
• 坏的：
  
  
  
  • mc.RELEASE.2020-05-28T23-43-36Z
  
  
  • mc.RELEASE.2020-06-16T19-24-41Z
  
  
  • mc.RELEASE.2020-07-11T04-53-20Z
  
  
  • mc.RELEASE.2020-07-17T02-52-20Z
  
  
  • mc.RELEASE.2020-07-31T23-34-13Z
  
  
  • mc.RELEASE.2020-08-08T02-33-58Z
  
  

伟大的！
非常有用的信息。
谢谢你。

@ebozduman我知道有逻辑可以检查目标中是否已经存在“相同文件”，然后跳过该文件以加快整个过程。 在我们的用例中，总是镜像所有文件而不进行这种优化是非常好的，因为我们很少有 100% 相同的文件。 也就是说，为了安全起见，我想犯错：效率稍低，但没有机会“忘记”文件。
禁用逻辑的方法会很棒。 例如 --force 或 --force-overwrite 效果。

@jnweiger在这种情况下，您将在同步之间等待更长的时间...就我个人而言，我不想要全局忽略标志或其他任何东西...我希望进行有效且有效的同步

另一种方法可能是比较文件上最后修改的时间戳。

@xoxys，@aureq，@jnweiger，@ i0x71，

最后一个问题：你们中的任何一个人都没有使用多站点设置，对吧？
那是;您的设置中运行了一个 minio 服务器，对吗？

@ebozduman正确，此处设置单服务器

@xoxys，@aureq，@jnweiger，@ i0x71，

最后一个问题：你们中的任何一个人都没有使用多站点设置，对吧？
那是; 您的设置中运行了一个 minio 服务器，对吗？

我也遇到了同样的问题，如果有帮助，我正在使用单个 minio 服务器设置。

@ebozduman同样在这里，它也是一个单一的站点设置。 所以单个minio服务器正在运行。

@xoxys，@aureq，@jnweiger，@ i0x71，@dpgarrick，

正如@harshavardhana在他的PR#3353评论中解释的那样，回答我的问题：

我问：

@harshavardhana ，请检查 PR#3226：“差异：在未找到多主上下文时禁用比较 modtimes”以及您的评论。 看起来这个 PR 试图在这里修复的东西，实际上是故意删除的。 所以，Issue #3331 看起来不像是回归。

@harshavardhana回答：

这样做的原因是我们无法知道哪个是最新的@ebozduman，因为 last-modified 不是正确的了解方式 - 这就是如果需要基于“mtime”的镜像，则需要主动/主动的原因。

因此，这是一个示例，您可以如何使用mc mirror的--active-active标志作为解决方案：

- Start your minio server

- From <strong i="27">@aureq</strong>' s easy reproduction steps, create your buckets and source files:
     $ mc mb myminio/test
     $ mkdir tmp
     $ echo "this is some random content" > ./tmp/content.txt
     $ mkdir tmp1
     $ echo "this is SOME rand0m c0ntent" > ./tmp1/content.txt
"./tmp1/content.txt" will have a later/newer "mtime" than "./tmp/content.txt"

- Start your active/active session that watches changes in the "./tmp/" directory and copies
over those changed files instantly to the minio server side, including modified files/objects
that happen to stay the same size and have a newer "mtime":
     $ mc mirror --active-active -a ./tmp/ myminio/test/
Your "./tmp/" directory content will be mirrored/copied over into "myminio/test/" as soon as
mirror active/active session starts to sync the contents and it also preserves original file
attributes, including "mtime".

- Copy "./tmp1/content.txt" file into "./tmp/" and preserve the file attributes. This will trigger
automatic copy of the new content.txt file that has a newer "mtime".
     $ mc copy -a ./tmp1/content.txt ./tmp/
If you try to copy the same file with an older 'mtime", mirroring process will not sync this file
onto the destination.

我希望--active-active标志和上面的示例有助于解决您的场景中的问题。
请让我们知道您的想法，因为我们打算关闭此问题。

@ebozduman感谢您提供详细信息和示例。 --active-active到底在做什么？ 我真的不明白，看起来这个功能没有记录。

@ebozduman感谢您提供信息。

从mc mirror命令的帮助中可以看出--active-active - enable active-active multi-site setup 。 我的用例是将本地目录备份到单个站点的 minio 部署上，所以我同意@xoxys 的观点，也许文档需要更新？

从快速测试来看， mc mirror --active-active功能似乎与mc mirror --watch类似。 如果mc mirror --active-active -a ./tmp my-minio/tmp-bak命令始终在一个终端中运行，则它能够成功捕获我对 ./tmp 目录中文件的更改，包括文件大小相同的更改。

但是我的用例是我想（手动）通过运行mc mirror -a /path/to/mydir my-minio/path/to/backup-of-mydir命令定期将目录备份到 minio 上，即没有像mc mirror --watch或mc mirror --active-active在背景。 对于该用例，此问题中描述的原始“实际”与“预期”行为仍然存在。 此外，如果由于某种原因mc mirror --active-active -a命令被中断并再次重新启动，则在命令停止时对导致相同文件大小的文件发生的任何更改将再次不会被捕获。

那么我的手动备份用例是不支持还是只能通过连续运行mc mirror --active-active作为守护程序来实现？

一些更可配置的选项来强制mc mirror通过检查大小 + modtime 对文件进行操作（即使只在使用-a标志时允许 modtime）或使用 md5 校验和至少对我有帮助，类似于 rclone 的行为方式，例如，请参见https://rclone.org/commands/rclone_sync/和此处的--checksum标志https://rclone.org/flags/

@xoxys ，

--active-active完全同步，特别是对于更复杂的场景，如多站点设置，如mc mirror --help页面所述：

  --active-active                    enable active-active multi-site setup

由于--active-active完全同步，因此它也支持mtime更改。

我们在常规镜像期间停止检查mtime更改的另一个原因是，有时mtime更改不一定表示真正的更改。 由于这个原因，当有mtime更改时，我们有一些用户不想同步，因为一些应用程序，例如jekyll build ，修改mtime没有好处根本原因并大大扩展了同步过程。

欢迎您针对缺少有关--active-active标志的信息/文档提出问题。
我也会在我们的团队会议上提出这个问题。

@dpgarrick ，

谢谢您的意见。
对您的评论的一项澄清：

此外，如果由于某种原因 mc mirror --active-active -a 命令被中断并再次重新启动，则在命令停止时对导致相同文件大小的文件发生的任何更改都不会再次被捕获。

实际上，当mc mirror --active-active进程在某些中断后重新启动时，它首先会同步在资源和目标之间发现的所有更改。 所以，它会拾起一切。

不幸的是，就 mtime 更改而言，不支持手动备份/镜像。

是的，你总是可以在 shell 中守护进程。

@dpgarrick ，

谢谢您的意见。
对您的评论的一项澄清：

此外，如果由于某种原因 mc mirror --active-active -a 命令被中断并再次重新启动，则在命令停止时对导致相同文件大小的文件发生的任何更改都不会再次被捕获。

实际上，当mc mirror --active-active进程在某些中断后重新启动时，它首先会同步在资源和目标之间发现的所有更改。 所以，它会拾起一切。

当我按如下方式测试时，这并没有发生：

mkdir tmpdir
echo "1234" > tmpdir/tmp
mc mirror --active-active -a ./tmpdir my-minio/tmpdir-mirror

等待 5 秒然后中断mc mirror
mc cat my-minio/tmpdir-mirror/tmp应该显示1234
现在做

echo "0000" > tmpdir/tmp
mc mirror --active-active -a ./tmpdir my-minio/tmpdir-mirror

等待 5 秒然后中断mc mirror
mc cat my-minio/tmpdir-mirror/tmp现在应该显示0000但仍显示“1234”

我的版本

mc version RELEASE.2020-08-20T00-23-01Z
my-minio    Version: 2020-08-27T05:16:20Z

不幸的是，就 mtime 更改而言，不支持手动备份/镜像。

在这种情况下，例如，应该使用哪些 mc 命令通过自动化的夜间 cron 作业可靠地将数据备份到 minio？ 我运行手动和自动备份，但都以这种方式使用 mc mirror 并且由于各种原因我不想运行mc mirror作为备份的守护进程

@ebozduman
刚刚意识到这个问题与#3060 重复

从这里和那里的所有讨论中，我理解为什么默认行为是这样的，但如果这个问题可以记录在mc mirror的帮助中会很好

似乎现阶段唯一的解决方法是使用rclone

@dpgarrick ，

你说的对。 此时唯一的解决方法是使用rclone 。

有一个关于如何使用rclone的 MinIO 文档： Rclone with MinIO Server

我仍然无法让它工作......这就是我现在尝试过的：

我已经开始镜像：

mc mirror --active-active --no-color --overwrite --remove --quiet upload/mirror /path/to/local/dir/mirror

• 在镜像 diffs 的初始启动时同步
• 镜像命令启动后（仍在运行！）上载/镜像上的更改未同步到本地目录（现在等待 > 5 分钟）

我需要的是一种定期或连续从中央upload.example.com minio服务器镜像到多个网络服务器本地目录的方法......

也许那是因为我尝试从远程 minio 服务器镜像到本地 fs？ 主动-主动/监视镜像是否仅从本地 fs 到远程 minio 工作？ 在这种情况下，这对我来说也不是解决方案，我还需要检查 rclone。

@xoxys，@aureq，@jnweiger，@ i0x71，@dpgarrick，

最后，我们确实修复了这个问题， PR#3402 ，它将在下一个 mc 版本中提供。

我暂时关闭这个问题。
如果您愿意，可以选择修复程序并在您的设置中尝试它，并告诉我们它是如何进行的。