Mc: Minio no refleja el archivo después de los cambios si el tamaño del archivo coincide

@xoxys, ¿ puede compartir su línea de comando mc mirror ?

@harshavardhana seguro:

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

Hola,

También confirmo que tengo exactamente el mismo problema. Usar --md5 no hace nada (por cierto, esta opción no se encuentra en la guía del cliente minIO).

También eliminé el archivo localmente, creé uno nuevo con el mismo nombre y puse contenido aleatorio con exactamente el mismo tamaño, pero el archivo no se cargó.

Estoy ejecutando las últimas versiones de minIO ( RELEASE.2020-07-31T03-39-05Z ) y mc( RELEASE.2020-07-31T23-34-13Z ).

Como "solución alternativa", la única forma es mc rm --recursive --force y luego mc cp --recursive pero esto no es nada eficiente.

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

¿Hay alguna actualización sobre esto, por favor?

Esto es realmente increíblemente fácil de reproducir.

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

Hola @aureq ,
Me ocuparé de esto tan pronto como haya terminado con el problema en el que estoy trabajando actualmente.

Probado con el reproductor de @aureq :

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

¡Estupendo!
Información muy útil.
Gracias.

@ebozduman Entiendo que hay una lógica que verifica si el "mismo archivo" ya existe en el destino y luego omite el archivo para acelerar todo el proceso. En nuestro caso de uso, estaría perfectamente bien duplicar siempre todos los archivos sin dicha optimización, ya que rara vez tenemos archivos 100% idénticos. Es decir, me gustaría errar por el lado seguro: ser un poco menos eficiente, pero sin posibilidad de "olvidar" un archivo.
Una forma de desactivar la lógica sería genial. Por ejemplo, un efecto --force o --force-overwrite.

@jnweiger en este caso, esperará mucho más entre sincronizaciones... Personalmente, no quiero un indicador de ignorar global o lo que sea... Me gustaría tener una sincronización funcional Y eficiente

Otra forma puede ser comparar las últimas marcas de tiempo modificadas en el archivo.

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

Una última pregunta: alguno de ustedes no estaba usando una configuración multisitio, ¿verdad?
Es decir; hay un solo servidor minio ejecutándose en su configuración, ¿correcto?

@ebozduman correcta, configuración de servidor único aquí

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

Una última pregunta: alguno de ustedes no estaba usando una configuración multisitio, ¿verdad?
Es decir; hay un solo servidor minio ejecutándose en su configuración, ¿correcto?

También he tenido este mismo problema y estoy usando una sola configuración de servidor minio, si ayuda.

@ebozduman Lo mismo aquí, también es una configuración de sitio único. Entonces, un solo servidor minio se está ejecutando.

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

Como explicó @harshavardhana en su comentario en PR#3353 , para responder a mi pregunta:

Yo pregunté:

@harshavardhana , consulte PR#3226: "diff: deshabilite la comparación de tiempos de modificación cuando no se encuentra el contexto multimaestro" y sus comentarios allí. Parece que lo que se intenta arreglar aquí con este PR, en realidad se eliminó deliberadamente en ese momento. Entonces, el número 3331 no parece una regresión.

@harshavardhana respondió:

La razón de esto es que no tenemos forma de saber cuál es el último @ebozduman porque la última modificación no es la forma correcta de saberlo; es por eso que es necesario activo/activo si se requiere una duplicación basada en "mtime".

Por lo tanto, aquí hay un ejemplo de cómo se puede utilizar mc mirror 's --active-active marcar como una solución:

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

Espero que el indicador --active-active y el ejemplo anterior ayuden a resolver el problema en sus escenarios.
Háganos saber lo que piensa, ya que nuestra intención es cerrar este problema.

@ebozduman Gracias por los detalles y el ejemplo. ¿Qué está haciendo exactamente --active-active ? Realmente no lo entiendo y parece que esta función no está documentada.

@ebozduman Gracias por la información.

Desde la ayuda en el comando mc mirror dice --active-active - enable active-active multi-site setup . Mi caso de uso es hacer una copia de seguridad de un directorio local en una implementación minio de un solo sitio, por lo que estoy de acuerdo con @xoxys en que tal vez la documentación deba actualizarse.

A partir de una prueba rápida, mc mirror --active-active parece funcionar de manera similar a mc mirror --watch . Si el comando mc mirror --active-active -a ./tmp my-minio/tmp-bak se deja ejecutándose en todo momento en una terminal, entonces podrá capturar con éxito mis cambios en los archivos en el directorio ./tmp, incluidos los cambios en los que el tamaño del archivo es el mismo.

Pero mi caso de uso es que quiero (manualmente) hacer una copia de seguridad periódica de un directorio en minio ejecutando el comando mc mirror -a /path/to/mydir my-minio/path/to/backup-of-mydir , es decir, sin algo como mc mirror --watch o mc mirror --active-active ejecutándose continuamente en el antecedentes. Para ese caso de uso, el comportamiento original "real" frente a "esperado" descrito en este problema aún existe. Además, si por alguna razón el comando mc mirror --active-active -a se interrumpe y se reinicia nuevamente, cualquier cambio que haya ocurrido en los archivos mientras se detuvo el comando y que resulte en el mismo tamaño de archivo no se volverá a capturar.

Entonces, ¿mi caso de uso de copia de seguridad manual no es compatible o solo es posible ejecutando continuamente mc mirror --active-active como un demonio?

Algunas opciones más configurables para obligar a mc mirror a operar en archivos al verificar el tamaño + modtime (incluso si solo permite modtime cuando se usa el indicador -a ) o usar sumas de verificación md5 sería útil para mí al menos, similar a cómo se comporta rclone, por ejemplo, consulte https://rclone.org/commands/rclone_sync/ y la marca --checksum aquí https://rclone.org/flags/

@xoxys ,

--active-active sincroniza por completo y este cuidado especial es necesario especialmente para escenarios más complejos, como configuraciones de múltiples sitios, como lo dice la página mc mirror --help :

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

Dado que --active-active realiza una sincronización completa, también respeta los cambios de mtime .

Otra razón por la que hemos dejado de comprobar los cambios de mtime durante la duplicación normal es que, a veces, el cambio de mtime no indica necesariamente un cambio real. Por esta razón, tenemos algunos usuarios que no quieren sincronizar cuando hay cambios de mtime , ya que algunas aplicaciones, como jekyll build , modifican mtime para nada. razón en absoluto y extiende el proceso de sincronización drásticamente.

Le invitamos a abrir un problema por falta de información/documentación sobre la marca --active-active .
También plantearé el tema en nuestra reunión de equipo.

@dpgarrick ,

Gracias por su aporte.
Una aclaración a tu comentario:

Además, si por alguna razón el comando mc mirror --active-active -a se interrumpe y se reinicia nuevamente, cualquier cambio que haya ocurrido en los archivos mientras se detuvo el comando y que resulte en el mismo tamaño de archivo no se volverá a capturar.

En realidad, cuando el proceso mc mirror --active-active se reinicia después de alguna interrupción, comienza sincronizando todos los cambios encontrados entre el recurso y el destino. Entonces, recogerá todo.

Desafortunadamente, la copia de seguridad/duplicación manual no es compatible con los cambios de mtime.

Sí, siempre puedes demonizar un proceso en shell.

@dpgarrick ,

Gracias por su aporte.
Una aclaración a tu comentario:

Además, si por alguna razón el comando mc mirror --active-active -a se interrumpe y se reinicia nuevamente, cualquier cambio que haya ocurrido en los archivos mientras se detuvo el comando y que resulte en el mismo tamaño de archivo no se volverá a capturar.

En realidad, cuando el proceso mc mirror --active-active se reinicia después de alguna interrupción, comienza sincronizando todos los cambios encontrados entre el recurso y el destino. Entonces, recogerá todo.

Eso no sucedió cuando lo probé de la siguiente manera:

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

Espere 5 segundos y luego interrumpa el mc mirror
mc cat my-minio/tmpdir-mirror/tmp debería mostrar 1234
Ahora haz

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

Espere 5 segundos y luego interrumpa el mc mirror
mc cat my-minio/tmpdir-mirror/tmp ahora debería mostrar 0000 pero en su lugar todavía muestra "1234"

mis versiones

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

Desafortunadamente, la copia de seguridad/duplicación manual no es compatible con los cambios de mtime.

En ese caso, ¿qué comandos mc deberían usarse para hacer una copia de seguridad confiable de los datos en minio a través de un trabajo cron nocturno automatizado, por ejemplo? Ejecuto copias de seguridad manuales y automáticas, pero todas usan mc mirror de esa manera y, por varias razones, no quiero ejecutar mc mirror como un demonio para la copia de seguridad.

@ebozduman
Me acabo de dar cuenta de que este problema es un duplicado de #3060

De toda la discusión aquí y allá, entiendo por qué el comportamiento predeterminado es el que es, pero sería bueno si este problema pudiera documentarse en la ayuda para mc mirror

Parece que la única solución en esta etapa es usar rclone

@dpgarrick ,

Tienes razón. La única solución en este momento es usar rclone .

Hay un documento de MinIO sobre cómo usar rclone : Rclone con MinIO Server

Todavía no puedo hacer que funcione ... Eso es lo que he intentado ahora:

He comenzado el espejo con:

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

• en el inicio inicial del espejo, las diferencias se sincronizan
• después de que se inició el comando espejo (¡todavía en ejecución!) los cambios en la carga/espejo no se sincronizan con el directorio local (esperando> 5 minutos ahora)

Lo que necesito es una forma de duplicar periódica o continuamente desde un servidor central upload.example.com minio a un directorio local de varios servidores web...

¿Tal vez sea porque trato de duplicar desde un servidor minio remoto a fs local? ¿El espejo activo-activo/reloj solo funciona desde el fs local al minio remoto? En este caso, esa tampoco es una solución para mí y también tendría que pagar rclone.

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

Finalmente, tenemos una solución para este problema, PR#3402 , que estará disponible en la próxima versión de mc.

Cierro este tema por ahora.
Si lo desea, puede elegir la solución y probarla en sus configuraciones y decirnos cómo le va.