Migrar Minecraft sin cambiar de dirección: DNS y reapertura
Para migrar un servidor de Minecraft manteniendo su dirección habitual, prepara el destino, detén las escrituras en el origen, transfiere un conjunto final coherente de datos y cambia después la ruta de conexión. El mundo antiguo debe permanecer cerrado a los jugadores. Actualizar DNS cambia a dónde apunta un nombre; no sincroniza dos copias del mundo que siguen funcionando.
Esta guía está pensada para comunidades establecidas que cambian de alojamiento con un servidor Java. Presupone que controlas el nombre público y puedes acordar una ventana de mantenimiento. Es un procedimiento operativo propuesto, no una migración probada en tu infraestructura. El acceso Bedrock, el crossplay y los servicios adicionales necesitan sus propias comprobaciones.
Identifica la dirección que utilizan los jugadores
Empieza por la entrada guardada de un participante habitual. Anota el nombre, el puerto si aparece explícitamente, el punto de entrada público y la máquina que guarda el mundo. Si hay un proxy, distingue su dirección pública de los destinos privados a los que envía las conexiones. Trasladar un backend manteniendo el proxy puede no requerir cambios en el DNS público.
Revisa la cadena DNS completa. Los registros A y AAAA proporcionan direcciones IPv4 e IPv6; un CNAME introduce otro nombre. Comprueba ambas familias para no dejar una ruta IPv6 antigua mientras actualizas IPv4. La referencia de tipos de registro DNS explica estas diferencias.
Si la entrada actual utiliza un registro SRV, anota su destino y puerto, además de los registros de dirección del destino. SRV tiene su propio registro de servicio y su destino debe disponer de registros de dirección, no ser un alias, según RFC 2782. Conserva el diseño de conexión existente salvo que modificarlo forme parte del alcance ensayado.
Asigna quién cambia DNS y quién confirma qué servidor recibe la conexión de prueba. Guarda los valores anteriores en la ficha de cambio. Evita juntar el traslado con un cambio de registrador, de autenticación o de versión de Minecraft.
Prepara las cachés antes del mantenimiento
El TTL controla cuánto tiempo puede almacenarse una respuesta DNS en caché. Reducirlo en el momento del traslado no sustituye respuestas que ya se guardaron con el TTL anterior. RFC 1034 describe este funcionamiento.
Como ejemplo de planificación, imagina que los registros que vas a modificar tienen un TTL de 3.600 segundos. Reduce los TTL correspondientes a 300 segundos al menos una hora antes de cambiar los destinos, con margen operativo adicional. Incluye en la revisión cualquier destino SRV o alias que vaya a cambiar. Son cifras ilustrativas: no prometen que todos los jugadores lleguen al nuevo servidor en cinco minutos. La documentación de TTL de Cloudflare también advierte de que las cachés locales pueden retrasar los cambios visibles.
Crea con antelación cualquier nombre de destino nuevo y compruébalo antes de la ventana. Añadir un nombre y editar un registro existente son situaciones distintas; también puede haberse almacenado una respuesta negativa anterior. No decidas la reapertura únicamente porque haya terminado una cuenta atrás.
Si utilizas Cloudflare para DNS, comprueba que el punto de conexión del juego tenga la configuración DNS-only adecuada. Su proxy HTTP habitual no transporta Minecraft de forma general; un servicio de transporte contratado y configurado expresamente es otro caso. Consulta las limitaciones del proxy.
Ensaya el destino sin abrir un segundo mundo en producción
Prepara el destino con el mismo software y los mismos ajustes de identidad. Utiliza una copia aislada para el ensayo, separa las bases de datos copiadas de producción y desactiva allí las integraciones reales. La guía para ensayar una restauración desarrolla los conjuntos coherentes de recuperación y la comprobación de datos de jugadores.
Prueba por una ruta controlada que atraviese el punto de entrada previsto. Una conexión directa por IP puede saltarse el proxy o comportamientos dependientes del nombre. Anota cómo repetirás la comprobación tras la transferencia final, con evidencias en los registros del destino. Si tu red utiliza Velocity, mantén los límites de acceso descritos en la revisión del acceso a los backends.
Descarta los cambios del ensayo antes de transferir los datos finales. Que un probador entre correctamente en una copia de hace una semana no demuestra que la migración final conserve los inventarios actuales.
Establece un único relevo de las escrituras
Durante la ventana acordada:
- Cierra el acceso de jugadores y termina las sesiones de juego existentes. Pausa bots, tareas programadas y otros sistemas que modifiquen datos relacionados.
- Detén limpiamente el servidor de origen. Obtén los mundos, la configuración necesaria y los datos externos mediante los métodos de copia admitidos, como un conjunto de recuperación documentado.
- Transfiere ese conjunto final al destino. Confirma que sustituye los datos del ensayo y utiliza las dependencias de producción previstas.
- Mantén ambos entornos restringidos mientras el equipo comprueba dimensiones, inventarios, permisos y datos representativos de plugins. Registra la evidencia de cada conexión en el destino.
- Cambia la ruta de conexión preparada y verifícala desde las redes previstas para la aceptación. Abre el juego al público solo cuando el responsable designado acepte el resultado.
Es una propuesta conservadora para un traslado planificado. La sincronización específica de una base de datos o una arquitectura con proxy pueden necesitar otro procedimiento. No supongas que copiar la carpeta del mundo incluye saldos, protecciones o datos de una integración.
Deja el proceso de juego antiguo detenido o sin posibilidad de aceptar partidas. Un servicio que muestre el mantenimiento no debe montar una copia escribible del mundo antiguo. Algunos jugadores aún pueden llegar a la dirección anterior durante la transición; permitir que construyan allí generaría historiales incompatibles.
Distingue volver al origen de cambiar DNS
Antes de reabrir el juego público, el origen sigue siendo el último estado de producción aceptado. Si falla la revisión del destino, mantenlo cerrado, revierte la ruta si hace falta y abre el origen solo después de confirmar su estado y sus dependencias. Ten en cuenta las cachés también durante esa vuelta.
En cuanto jugadores o integraciones escriben en el destino, el origen queda desactualizado. Cambiar DNS hacia atrás no le transfiere las construcciones, los inventarios ni las transacciones nuevas. Detén las escrituras y decide si reparar el destino, trasladar su estado actual al origen o recuperar un punto acordado. Documenta cualquier pérdida prevista antes de reabrir. No prometas una vuelta inmediata sin un procedimiento de datos demostrado.
Incluye esta tabla de aceptación en la entrega:
| Comprobación | Evidencia necesaria |
|---|---|
| Dirección habitual | Una entrada real alcanza el acceso previsto y aparece en los registros del destino |
| Datos de jugadores | Inventarios, ubicaciones y registros de plugins seleccionados coinciden con la transferencia final |
| Acceso antiguo | El origen no permite escrituras de juego |
| Decisión ante fallos | Constan responsable, criterios de reapertura y tratamiento de las escrituras del destino |
Conserva el conjunto antiguo de recuperación hasta el plazo acordado, observa errores de conexión y arranque y restablece los TTL habituales tras aceptar la transición. Una respuesta DNS correcta, por sí sola, no completa la aceptación.
La infraestructura Minecraft gestionada de Mineando puede incluir arquitectura, despliegue y procedimientos de recuperación en un proyecto de pago con alcance individual. Comparte las rutas de entrada, las dependencias y las limitaciones de mantenimiento; los horarios y las responsabilidades de soporte se acuerdan por separado.
