rsync utilidad. No ejecute los comandos de este artículo si no está completamente familiarizado con ellos. En todos los casos, asegúrese de haber realizado una copia de seguridad de sus datos antes de seguir los pasos de esta guía. Se aplican cargos de ancho de banda estándar.
Esta guía lo ayuda a acortar los tiempos de migración del servidor. Si las aplicaciones de su servidor coinciden con alguna de las características destacadas en este artículo, siga leyendo; este artículo puede hacer que los tiempos de rsync sean más cortos y más predecibles para usted. También muestra cómo reducir los tiempos de migración tomando medidas preventivas antes de hacerlo.
Acelerar el proceso rsync
El volumen de espacio en disco utilizado en un servidor determina los tiempos de rsync. Es decir, cuantos más datos se copien, más tiempo llevará el trabajo. Por lo general, un rsync de sistema operativo vacío tarda entre 10 y 15 minutos en completarse. Los siguientes casos de uso del servidor pueden extender drásticamente el tiempo de rsync:
- Servidores que contienen muchos archivos pequeños, como archivos de sesión de Ruby, archivos de caché, archivos de mensajes del servidor de correo o miniaturas de imágenes del servidor web . La migración de dichos datos mediante rsync lleva más tiempo de lo esperado. Esto significa que una sincronización inicial lleva más tiempo, pero una segunda pasada en modo de rescate, con el tiempo de inactividad asociado, es más corta.
- Servidores que contienen varios archivos actualizados durante la sincronización en vivo . Por lo general, estos son archivos de tabla MySQL® MyISAM o servidores web que alojan múltiples dominios, cada uno configurado para iniciar sesión en archivos separados. La necesidad de actualizar estos archivos escritos activamente después de la copia de rsync de primer paso extiende el tiempo de inactividad desde un reinicio hasta completar un segundo paso del proceso de rsync.
- Servidores que contienen uno o más archivos grandes actualizados durante la migración . Los ejemplos incluyen bases de datos MySQL que utilizan el formato InnoDB, servidores de correo con grandes registros de correo y servidores web que registran archivos únicos y grandes. La actualización de estos archivos escritos activamente con un segundo rsync después de la copia de rsync del primer paso puede extender en gran medida el tiempo de inactividad asociado.
El secreto para reducir los tiempos de rsync es administrar los datos en su servidor e identificar cualquier aplicación que escriba en el disco durante la migración en vivo.
Problema:sobrecarga de archivos pequeños
Aunque no ocupan mucho espacio en disco individual, los servidores que alojan muchos archivos pequeños obligan al proceso rsync a realizar muchas file-open. , file-copy y file-check procesos.
Por ejemplo, un archivo de datos de un gigabyte requiere un conjunto de procesos de apertura, copia y verificación de archivos. Compare eso con una porción de datos de un gigabyte distribuida en 10,000 archivos individuales que requieren 10,000 conjuntos individuales de procesos de archivos. Eso es mucha más sobrecarga del sistema y de la red.
La siguiente lista muestra aplicaciones que crean muchos archivos pequeños y tienen tiempos de preparación de migración más largos:
- Servidores web que sirven muchas miniaturas pequeñas o archivos de imagen
- Servidores de almacenamiento en caché que almacenan archivos pequeños en disco
- Servidores de correo electrónico con grandes archivos de correo electrónico no eliminado
- Servidores Ruby o Rails, que tienden a crear varios archivos de sesión pequeños y no los eliminan
- repositorios git
- Servidores de aplicaciones personalizados que crean pero no eliminan archivos de sesión para cada visitante
El problema de los archivos pequeños hace que el rsync sea menos predecible y tome más tiempo.
Cómo migrar
Compruebe las aplicaciones de su servidor con la lista anterior. Si sus aplicaciones están en la lista, haga lo que pueda para eliminar los archivos pequeños no deseados antes de ejecutar el rsync real. dominio. Si está ejecutando Ruby o Rails, asuma lo peor y busque en los foros de la comunidad las ubicaciones típicas de los archivos de sesión y caché, así como también cómo identificar cuáles puede eliminar de manera segura. Considere almacenar los datos de la sesión en MySQL con el siguiente comando:
rake db:sessions:create
Truncar archivos de registro en log/ a cero bytes con el siguiente comando:
rake log:clear
Si está ejecutando un servidor de almacenamiento en caché que almacena en caché en el disco en lugar de en la RAM, identifique su directorio de almacenamiento de archivos y elimine agresivamente. Verifique su sistema de archivos en busca de archivos pequeños de sesión y caché creados por aplicaciones personalizadas. De nuevo, pode con vigor. Si migra un servidor de correo electrónico con un Mail DeliveryAgent (MDA) como Dovecot instalado, haga que sus usuarios de correo electrónico limpien primero sus archivos de correo electrónico de correo antiguo.
Problema:Cambio constante de archivos
Debe volver a copiar los archivos que cambian entre el inicio y el final de un rsync con un rsync de seguimiento para una migración completa del servidor. Este proceso amplía el tiempo de finalización de la migración.
Los servidores de bases de datos son los culpables más frecuentes de actualizar archivos de datos de gran tamaño entre el inicio y el final de una migración. Estos cambios obligan al sistema a copiar todo el archivo de la base de datos nuevamente en un segundo proceso rsync que podría realizar en una migración.
Algunas combinaciones de estructura y tipo de base de datos tienden a exacerbar este tipo de problema. Por ejemplo, suponga que tiene una base de datos MySQL de múltiples tablas MyISAM con muchos archivos de tabla actualizados dentro de transacciones SQL individuales. En ese caso, es posible que muchos, si no todos, los archivos de la tabla deban volver a copiarse durante la segunda operación rsync del modo de rescate.
Dado que los archivos de la base de datos pueden ser grandes, las implicaciones de estas actualizaciones para el tiempo de migración quedan claras. Es difícil predecir con precisión cuánto tiempo puede tomar una migración de rsync. Después de todo, ¿cómo podemos predecir qué y cuántas actualizaciones de SQL ocurrirán entre el inicio y el final de la migración?
Cómo migrar
Si su base de datos contiene una gran cantidad de datos obsoletos, considere archivar esos datos y luego eliminarlos de la base de datos activa antes de migrar su servidor. MySQL, por ejemplo, le permite archivar datos usando el mysqldump secuencia de comandos, después de lo cual puede eliminar los datos obsoletos en la base de datos en vivo. El gran mysqldump El archivo de salida que contiene los datos obsoletos no se extiende a un segundo rsync porque no habrá cambiado desde la primera pasada.
Otra opción si tiene aplicaciones que escriben en muchos archivos durante el cambio de tamaño es configurar la aplicación en modo de solo lectura inmediatamente antes de ejecutar rsync dominio. Por lo general, puede configurar las bases de datos en modo temporal de solo lectura. Con otras aplicaciones, su kilometraje puede variar. También puede evitar la escritura en varios archivos desactivando las aplicaciones, pero configurar las aplicaciones en modo de solo lectura suele ser la opción preferida.
Problema:archivos grandes que se actualizan constantemente
Los archivos muy grandes (10 GB o más) actualizados durante un rsync plantean problemas similares para el tiempo de migración que los archivos más pequeños y constantemente actualizados pero con esteroides. Si su servidor aloja archivos en los que se escriben con frecuencia, esta sección es para usted.
Un segundo rsync necesita volver a copiar por completo estos archivos grandes que se actualizan constantemente para capturar cualquier actualización realizada después de que comenzó un proceso de migración o cambio de tamaño. Esto amplía considerablemente el tiempo de migración debido al tamaño de esa segunda copia de rsync.
Los servidores de bases de datos MySQL que usan el formato de archivo de datos InnoDB escriben datos en un solo archivo que crece mucho. De manera similar, MySQL en modo InnoDB registra en un solo archivo de registro grande.
Una actualización de un gran archivo de registro o datos InnoDB MySQL, como /var/lib/mysql/ibdata1 , obliga al proceso rsync a volver a copiar todo el archivo en una segunda pasada. Si estos archivos son grandes, la nueva copia puede llevar algún tiempo, lo que mantiene la base de datos fuera de línea.
Otra fuente de archivos grandes son los registros de aplicaciones, incluidos los registros producidos por servidores de correo y algunos servidores web. Apache® puede producir archivos de registro de 16 Gb o más, por lo que no es seguro asumir que el registro predeterminado de Apache lo ayuda a evitar este problema de archivos grandes.
Los registros de transacciones de MySQL también pueden crecer mucho si ha activado el registro de transacciones. La gente rara vez lo hace, y es aún más raro que activen el registro de transacciones sin quedarse sin espacio en disco después. Aún así, es aconsejable estar atento a esta posibilidad.
Cómo migrar
Como se describió anteriormente, eliminar las bases de datos de cruft podría ayudar a reducir el tiempo total de rsync. Archive y elimine las bases de datos antiguas u obsoletas antes de intentar una migración.
Una vez más, desactivar las escrituras en la base de datos, si es posible, reduce el tiempo de migración. Desactivar el registro también puede ayudar a las bases de datos InnoDB.
Si ha activado el registro de transacciones de MySQL y el archivo de registro de transacciones es grande, vale la pena apagarlo, archivarlo y luego eliminarlo en el segmento antes de iniciar una migración de rsync.
En los servidores de correo, compruebe el tamaño de /var/log/mail.log o /var/log/maillog antes de la migración. Considere apagar el servidor de correo antes de la migración, especialmente si tiene un servidor de correo de respaldo para recoger la carga.
Del mismo modo, verifique cómo se registra Apache. Si está registrando todas las solicitudes en un archivo, verifique el tamaño de ese archivo y considere archivarlo y eliminarlo o apagar Apache antes de iniciar el proceso de migración. El mismo consejo se aplica a cualquier otra aplicación que sepa que está escribiendo en un archivo de registro grande.
Para estas aplicaciones y cualquier otra, revise su logrotate política (si tiene una) para verificar que esté controlando el tamaño de sus archivos de registro. Esto le ahorra tiempo de inactividad durante la migración y facilita la vida con cualquier servidor Linux.
Empaca tu bolsa de herramientas
Por supuesto, es difícil rastrear los archivos creados después de configurar el servidor. Eso es cierto para las aplicaciones que crean archivos de sesión. Vale la pena encontrar y seleccionar estas grandes colecciones de pequeños archivos.
Puede identificar los diez directorios y archivos más grandes emitiendo el siguiente comando como root :
du -a / | sort -n -r | head -n 10
Cambia ese 10 final a cualquier otro número para modificar cuántos archivos y directorios arroja la búsqueda. Este comando es una buena herramienta intermedia para identificar directorios grandes de archivos pequeños y grandes. Si solo desea buscar archivos grandes, pruebe este buscador de archivos grandes (como root ):
find ~/ -mount -type f -ls|sort -rnk7 |head -30|awk '{printf "%10d MB\t%s\n",($7/1024)/1024,$NF}'
Si solo desea buscar directorios grandes, pruebe este buscador de directorios grandes (como root ):
du -x --max-depth=4 ~/|sort -rn|head -n30|awk '{printf "%10d MB\t%s\n",$1/1024,$2}'
Detalles técnicos
Suponga que su servidor no coincide con ninguno de los tipos comunes que hemos examinado anteriormente. En ese caso, puede evaluar cómo sería el tiempo de migración si considera sus aplicaciones con una comprensión de cómo funciona el proceso de migración (rsync).
La primera etapa típica de una migración es un rsync en vivo, que es básicamente una copia de todo el sistema de archivos del servidor. Todas las aplicaciones se dejan ejecutándose durante esta etapa.
Aquí es donde la predicción del tiempo de migración se topa con su primera incertidumbre. Sin un conocimiento detallado del uso que hace del sistema de archivos de su servidor, no puede predecir con precisión cuánto durará la file-copy. la etapa de un rsync tardará en completarse.
Esta imprevisibilidad es cierta para el directorio final en los sistemas de archivos de Linux:/var/ directorio. Se llama var porque el tamaño de los datos que contiene es variable y cambios mientras se ejecutan las aplicaciones del servidor.
La segunda incertidumbre es que la fase final de una migración incluye un componente de modo de rescate (tiempo de inactividad). Durante esta fase, el proceso vuelve a copiar todos los archivos actualizados después de que comenzó la fase de rsyncfirst en vivo. La duración del tiempo de inactividad depende del tamaño y la cantidad de archivos actualizados. Una vez más, el proceso rsync no puede decir con anticipación cuántas aplicaciones de actualización como MySQL están escribiendo en los archivos de datos, por lo que es difícil predecir la duración de este rescate final. modo rsync copiar.
La información anterior se aplica a un proceso de migración manual típico. Nuestra nube cambia el proceso de cambio de tamaño para desactivar el servidor para una sola sincronización, lo que aumenta el tiempo de inactividad y aumenta la confiabilidad de la sincronización.
Resumen
Si sabe cómo sus aplicaciones utilizan el espacio en disco y cómo escriben en los archivos, es posible que pueda juzgar si una migración llevará más tiempo del que desea y hacer los preparativos correspondientes. Como mínimo, puede usar su nuevo conocimiento sobre migración para programar mejor las migraciones para que se ajusten a sus requisitos de tiempo.
Use la pestaña Comentarios para hacer cualquier comentario o hacer preguntas. También puede iniciar una conversación con nosotros.