Migración en vivo
Los servidores se reemplazan: el hardware envejece, los proveedores cambian, las regiones se mueven. rdc repo migrate traslada un repositorio en ejecución a otra máquina con un solo comando, y con --checkpoint hasta la memoria de procesos viaja también. La app de demo, pulse, mantiene un contador en RAM; tras el traslado sigue contando en lugar de empezar desde cero.
Ver el tutorial
Cómo funciona el traslado
La primera fase copia el grueso de los datos mientras la app sigue corriendo. La segunda hace checkpoint de los procesos en ejecución (CRIU, para contenedores etiquetados con rediacc.checkpoint=true), transfiere el delta final más el estado de los procesos, y los reanuda en la nueva máquina. El tiempo de inactividad es el delta, no los datos.
Paso 1: La evidencia, un contador en RAM
rdc term connect --machine <machine-name> --repository pulse --command 'docker logs heartbeat_app --tail 5'La aplicación mantiene un contador en memoria y registra un latido cada cinco segundos. El contador vive solo en RAM: reiniciar el proceso lo resetearía a uno.
memory counter=6 y subiendo, un latido cada cinco segundos. El contador vive solo en la memoria del proceso. Si el proceso se reiniciara, comenzaría de nuevo en uno.
Paso 2: Migrar en vivo
rdc repo migrate --name pulse --from <machine-name> --to <target-machine> --checkpoint --skip-dnsMigra con checkpoint: la fase uno transfiere los 2 GB del grueso mientras el origen permanece en línea, luego un breve corte crea un checkpoint de los procesos en ejecución y transfiere el delta final. La salida muestra cada fase y el tiempo de inactividad real.
La salida narra el traslado: la primera fase transfiere el grueso de 2 GB mientras la fuente sigue en línea; luego la línea de corte imprime el DOWNTIME real: unas pocas decenas de megabytes y aproximadamente veinte segundos, para un repositorio de dos gigabytes.
Paso 3: Verificar el nuevo hogar
rdc repo list --machine <target-machine>Lista los repositorios en la máquina destino: pulse está montado, Docker está en ejecución y sus containers están activos.
En el destino, pulse está montado, Docker activo, contenedores corriendo.
Paso 4: La fuente está detenida
rdc repo list --machine <machine-name>En el origen, el repositorio está detenido y desmontado: sin Docker, cero containers. La imagen se conserva como base para futuras transferencias delta.
La fuente sigue listando el repositorio, pero con honestidad: no montado, sin Docker, cero contenedores. Ya no corre nada ahí. La imagen se conserva intencionalmente como base para la próxima transferencia delta, de modo que un futuro push de vuelta sea barato.
Paso 5: El contador siguió contando
rdc term connect --machine <target-machine> --repository pulse --command 'docker logs heartbeat_app --tail 5'Los registros en la nueva máquina muestran el contador continuando desde donde el checkpoint lo congeló, sin resetear a uno. La memoria del proceso hizo el viaje.
memory counter=17, luego 18, 19, 20… Retomó exactamente donde el checkpoint lo congeló en lugar de reiniciarse en uno. Eso es la memoria de procesos haciendo el viaje; la app nunca notó que cambió de máquina.
Sin
--checkpoint, migrate igual mueve disco y contenedores; se reinician desde cero en el destino en lugar de reanudar a mitad de vuelo.
Siguiente: Transferencia delta.