Mc: Minio gagal untuk mencerminkan file setelah perubahan jika ukuran file cocok

@xoxys dapatkah Anda membagikan baris perintah mc mirror ?

@harshavardhana yakin:

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

Hai,

Saya juga mengonfirmasi bahwa saya memiliki masalah yang sama persis . Menggunakan --md5 tidak melakukan apa-apa (btw, opsi ini tidak ada dalam panduan klien minIO).

Saya juga menghapus file secara lokal, membuat yang baru dengan nama yang sama dan meletakkan beberapa konten acak dengan ukuran yang sama persis tetapi file tidak diunggah.

Saya menjalankan versi terbaru minIO ( RELEASE.2020-07-31T03-39-05Z ) dan mc( RELEASE.2020-07-31T23-34-13Z ).

Sebagai "solusi", satu-satunya cara adalah mc rm --recursive --force dan kemudian mc cp --recursive tetapi ini tidak efisien sama sekali.

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

Apakah ada pembaruan tentang ini?

Ini sebenarnya sangat mudah untuk direproduksi.

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

Hai @aureq ,
Saya akan menyelidiki ini segera setelah saya selesai dengan masalah yang sedang saya kerjakan.

Diuji dengan reproduksi dari @aureq :

• BAGUS:
  
  
  
  • https://dl.min.io/client/mc/release/linux-amd64/archive/mc.RELEASE.2020-05-16T01-44-37Z
  
  
• BURUK:
  
  
  
  • 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
  
  

Besar!
Informasi yang sangat membantu.
Terima kasih.

@ebozduman Saya mengerti ada logika yang memeriksa, jika "file yang sama" sudah ada di tujuan dan kemudian melewatkan file untuk mempercepat seluruh proses. Dalam kasus penggunaan kami, akan baik-baik saja untuk selalu mencerminkan semua file tanpa pengoptimalan seperti itu, karena kami jarang memiliki file yang 100% identik. Artinya, saya ingin berbuat salah di sisi aman: menjadi sedikit kurang efisien, tetapi tidak ada kesempatan untuk "melupakan" file.
Cara untuk menonaktifkan logika akan sangat bagus. Misalnya efek --force atau --force-overwrite.

@jnweiger dalam hal ini Anda akan menunggu lebih lama di antara sinkronisasi... Secara pribadi saya tidak ingin bendera pengabaian global atau apa pun... Saya ingin sinkronisasi yang berfungsi DAN efisien

Cara lain dapat membandingkan cap waktu terakhir yang dimodifikasi pada file.

@xoxys , @aureq , @jnweiger , @i0x71 ,

Satu pertanyaan terakhir: salah satu dari Anda, tidak menggunakan pengaturan multi-situs, bukan?
Itu adalah; ada satu server minio yang berjalan di pengaturan Anda, benar?

@ebozduman benar, pengaturan server tunggal di sini

@xoxys , @aureq , @jnweiger , @i0x71 ,

Satu pertanyaan terakhir: salah satu dari Anda, tidak menggunakan pengaturan multi-situs, bukan?
Itu adalah; ada satu server minio yang berjalan di pengaturan Anda, benar?

Saya juga mengalami masalah yang sama dan saya menggunakan satu set server minio, jika itu membantu.

@ebozduman Sama di sini, ini juga satu pengaturan situs. Jadi server minio tunggal berjalan.

@xoxys , @aureq , @jnweiger , @i0x71 , @dpgarrick ,

Seperti yang dijelaskan @harshavardhana dalam komentarnya di PR#3353 , untuk menjawab pertanyaan saya:

Saya bertanya:

@harshavardhana , Silakan periksa PR#3226: "diff: Nonaktifkan membandingkan modtimes ketika konteks multimaster tidak ditemukan" dan komentar Anda di sana. Sepertinya apa yang coba diperbaiki di sini dengan PR ini, sebenarnya sengaja dihilangkan saat itu. Jadi, Edisi #3331 tidak terlihat seperti regresi.

@harshavardhana menjawab:

Alasan untuk ini adalah kami tidak memiliki cara untuk mengetahui @ebozduman terbaru karena modifikasi terakhir bukanlah cara yang tepat untuk mengetahuinya - itulah mengapa aktif/aktif diperlukan jika pencerminan berbasis "mtime" diperlukan.

Jadi, berikut adalah contoh bagaimana Anda dapat menggunakan flag mc mirror 's --active-active sebagai solusi:

- 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.

Saya harap flag --active-active dan contoh di atas membantu menyelesaikan masalah dalam skenario Anda.
Harap beri tahu kami pendapat Anda karena niat kami adalah untuk menutup masalah ini.

@ebozduman Terima kasih atas detail dan contohnya. Apa sebenarnya yang dilakukan --active-active ? Saya tidak begitu mengerti dan sepertinya fitur ini tidak didokumentasikan.

@ebozduman Terima kasih atas informasinya.

Dari bantuan pada perintah mc mirror dikatakan --active-active - enable active-active multi-site setup . Kasus penggunaan saya mencadangkan direktori lokal ke satu penyebaran minio situs, jadi saya setuju dengan @xoxys bahwa mungkin dokumentasi perlu diperbarui?

Dari tes cepat mc mirror --active-active tampaknya berfungsi mirip dengan mc mirror --watch . Jika perintah mc mirror --active-active -a ./tmp my-minio/tmp-bak dibiarkan berjalan setiap saat dalam satu terminal, maka ia dapat berhasil menangkap perubahan saya ke file di direktori ./tmp termasuk perubahan di mana ukuran filenya sama.

Tetapi kasus penggunaan saya adalah saya ingin (secara manual) mencadangkan direktori ke minio secara berkala dengan menjalankan perintah mc mirror -a /path/to/mydir my-minio/path/to/backup-of-mydir , yaitu tanpa sesuatu seperti mc mirror --watch atau mc mirror --active-active terus berjalan di Latar Belakang. Untuk kasus penggunaan itu, perilaku "aktual" vs "yang diharapkan" asli yang dijelaskan dalam masalah ini masih ada. Juga jika karena alasan apa pun perintah mc mirror --active-active -a diinterupsi dan dimulai ulang lagi, setiap perubahan saat perintah dihentikan yang terjadi pada file yang menghasilkan ukuran file yang sama tidak akan diambil lagi.

Jadi apakah kasus penggunaan pencadangan manual saya tidak didukung atau hanya mungkin dengan terus menjalankan mc mirror --active-active sebagai daemon?

Beberapa opsi yang lebih dapat dikonfigurasi untuk memaksa mc mirror untuk beroperasi pada file dengan memeriksa ukuran + modtime (bahkan jika hanya mengizinkan modtime ketika flag -a digunakan) atau menggunakan checksum md5 setidaknya akan membantu saya, mirip dengan bagaimana rclone berperilaku, misalnya lihat https://rclone.org/commands/rclone_sync/ dan tandai --checksum sini https://rclone.org/flags/

@xoxys ,

--active-active melakukan sinkronisasi penuh dan perawatan khusus ini diperlukan terutama untuk skenario yang lebih kompleks seperti pengaturan multi-situs seperti yang dikatakan halaman mc mirror --help :

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

Karena --active-active melakukan sinkronisasi penuh, itu juga menghormati perubahan mtime .

Alasan lain kami berhenti memeriksa perubahan mtime selama pencerminan reguler adalah bahwa terkadang perubahan mtime tidak selalu menunjukkan perubahan yang sebenarnya. Karena alasan ini, kami memiliki beberapa pengguna yang tidak ingin menyinkronkan ketika ada mtime perubahan karena beberapa aplikasi di luar sana, seperti jekyll build , memodifikasi mtime secara tidak baik alasan sama sekali dan memperluas proses sinkronisasi secara drastis.

Anda dipersilakan untuk membuka masalah untuk informasi/dokumentasi yang hilang tentang flag --active-active .
Saya juga akan mengangkat masalah ini dalam pertemuan tim kami.

@dpgarrick ,

Terima kasih atas masukannya.
Satu klarifikasi pada komentar Anda:

Juga jika karena alasan apa pun perintah mc mirror --active-active -a terputus dan dimulai ulang lagi, setiap perubahan saat perintah dihentikan yang terjadi pada file yang menghasilkan ukuran file yang sama tidak akan diambil lagi.

Sebenarnya, ketika proses mc mirror --active-active dimulai kembali setelah beberapa gangguan, proses ini dimulai dengan menyinkronkan semua perubahan yang ditemukan antara sumber daya dan tujuan. Jadi, itu akan mengambil semuanya.

Sayangnya pencadangan/pencerminan manual tidak didukung sejauh perubahan mtime berjalan.

Ya, Anda selalu dapat melakukan daemonisasi proses di shell.

@dpgarrick ,

Terima kasih atas masukannya.
Satu klarifikasi pada komentar Anda:

Juga jika karena alasan apa pun perintah mc mirror --active-active -a terputus dan dimulai ulang lagi, setiap perubahan saat perintah dihentikan yang terjadi pada file yang menghasilkan ukuran file yang sama tidak akan diambil lagi.

Sebenarnya, ketika proses mc mirror --active-active dimulai kembali setelah beberapa gangguan, proses ini dimulai dengan menyinkronkan semua perubahan yang ditemukan antara sumber daya dan tujuan. Jadi, itu akan mengambil semuanya.

Itu tidak terjadi ketika saya mengujinya sebagai berikut:

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

Tunggu 5 detik lalu interupsi mc mirror
mc cat my-minio/tmpdir-mirror/tmp harus menunjukkan 1234
Sekarang lakukan

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

Tunggu 5 detik lalu interupsi mc mirror
mc cat my-minio/tmpdir-mirror/tmp sekarang seharusnya menampilkan 0000 tetapi masih menampilkan "1234"

Versi saya

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

Sayangnya pencadangan/pencerminan manual tidak didukung sejauh perubahan mtime berjalan.

Dalam hal ini, perintah mc apa yang harus digunakan untuk mencadangkan data secara andal ke minio melalui tugas cron malam otomatis misalnya? Saya menjalankan pencadangan manual dan otomatis tetapi semuanya menggunakan mc mirror dengan cara itu dan karena berbagai alasan saya tidak ingin menjalankan mc mirror sebagai daemon untuk mencadangkan

@ebozduman
Baru menyadari masalah ini adalah duplikat dari #3060

Dari semua diskusi di sana-sini, saya mengerti mengapa perilaku default seperti itu tetapi alangkah baiknya jika masalah ini dapat didokumentasikan dalam bantuan untuk mc mirror

Tampaknya satu-satunya solusi pada tahap ini adalah menggunakan rclone

@dpgarrick ,

Kamu benar. Satu-satunya solusi saat ini adalah menggunakan rclone .

Ada dokumen MinIO tentang cara menggunakan rclone : Rclone dengan Server MinIO

Saya masih tidak bisa membuatnya bekerja... Itulah yang saya coba sekarang:

Saya telah memulai cermin dengan:

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

• pada awal awal perbedaan cermin disinkronkan
• setelah perintah mirror dimulai (masih berjalan!) perubahan pada unggahan/mirror tidak disinkronkan ke direktori lokal (menunggu > 5 menit sekarang)

Yang saya butuhkan adalah cara untuk secara berkala atau terus menerus melakukan mirror dari server minio upload.example.com pusat ke beberapa direktori lokal server web...

Mungkin itu karena saya mencoba untuk mirror dari server minio jarak jauh ke fs lokal? Apakah cermin aktif-aktif/jam hanya berfungsi dari fs lokal ke minio jarak jauh? Dalam hal ini itu bukan solusi untuk saya juga dan saya juga perlu checkout rclone.

@xoxys , @aureq , @jnweiger , @i0x71 , @dpgarrick ,

Akhirnya, kami memiliki perbaikan untuk masalah ini, PR#3402 , yang akan tersedia di rilis mc berikutnya.

Saya akan menutup masalah ini untuk saat ini.
Jika mau, Anda dapat mengambil perbaikan dan mencobanya di penyiapan Anda dan beri tahu kami bagaimana kelanjutannya.