Medianoche: cambie al nuevo PostgreSQL administrado. 00:17, errores de restricción FK: tabla huérfana presente solo en nueva. Regreso anunciado 45 minutos. Causa: migración del esquema sin expansión/contratación, el tráfico cambió antes del recuento de filas de verificación de paridad.
Migrar una base de datos = programar tres flujos: esquema compatible, sincronización de datos, cambio de tráfico. El orden importa más que la ventana de mantenimiento mostrada.
Expandir / contraer
- Agregue columnas/tablas que acepten valores NULL (expandir).
- Implemente una aplicación que lea ambos esquemas si es necesario.
- Rellenar datos.
- Alternar entradas.
- Eliminar el antiguo (contrato): nunca antes de que se demuestre la paridad.
Cambio de última hora, misma liberación que la transición = ticket de incidente garantizado.
Sincronización de datos
| Método | Cuando |
|---|---|
| pg_dump/restaurar | Base de datos pequeña, se acepta mantenimiento |
| Replicación lógica | Gran base de datos, bajo tiempo de inactividad |
| CDC (Debezium) | Casi en tiempo real |
| Instantánea + WAL | PITR gestionado en la nube |
Retraso de prueba y conflictos antes del cambio de minuto. Dimensione el IOPS/RAM de la nueva instancia antes de la sincronización.
Lista de verificación de transición
Congelar cambios de esquema. Comparar la muestra de hash de recuentos de filas. Deja de escribir viejo. Sincronización final. Conexión del grupo Flip (modo de sesión PgBouncer si se preparan declaraciones). Pruebas de humo. Monitorear errores 1 hora.
Base de datos de URL de indicador de función. Instancia antigua de solo lectura, mínimo 7 días después de la transición.
PgBouncer y piscinas
Declaraciones preparadas de casos en modo de transacción: modo de sesión o runbook documentado de conexión directa del día D. Los grupos almacenan en caché el nombre de host anterior: reiniciar aplicaciones explícitamente después de la transición.
Reversión creíble: reversión de DNS/grupo + resincronización inversa probada en clonación; no es una diapositiva sin comandos cronometrados.
Ejecución en seco al clonar
Ejecute la transición completa en un clon idéntico: la producción de medianoche no es el momento para descubrir el pedido. Archivar plan firmado: expandir/contraer, ventanas, propietarios, criterios de reversión cifrados.
Compare hosts de base de datos RDS/administrados a través de comparador en IOPS y soporte de transición.
Semana posterior a la transición
Instancia antigua de solo lectura con un mínimo de 7 días. Supervise los errores de caché ORM que no coinciden con el esquema.
Prueba de emoji Utf8mb4 antes de la transición: truncamiento silencioso.
Los indicadores de funciones dividen el esquema de implementación y cambian el tráfico.
Monitoreo operativo
Archivar el plan de migración firmado: futuro post-mortem sin memoria oral. Incluya contrato de ampliación de orden, ventanas, propietarios y criterios de reversión cifrados. Implementación del viernes del conflicto de suma de comprobación de Liquibase: se documenta la semana de transición de las migraciones congeladas. Documente las brechas entre la promesa del proveedor de hosting y la medición de campo en la revisión trimestral.
Continuación trimestral
Archivar el plan de migración firmado: futuro post-mortem sin memoria oral. Incluya contrato de ampliación de orden, ventanas, propietarios y criterios de reversión cifrados. Implementación del viernes del conflicto de suma de comprobación de Liquibase: se documenta la semana de transición de las migraciones congeladas. Documente las brechas entre la promesa del proveedor de hosting y la medición de campo en la revisión trimestral.
Mantenga un runbook fechado, métricas de antes y después, revisión posterior al incidente: la disciplina acumulativa evita el pánico del viernes por la noche.
Mantenga un runbook fechado, métricas de antes y después, revisión posterior al incidente: la disciplina acumulativa evita el pánico del viernes por la noche.
Mantenga un runbook fechado, métricas de antes y después, revisión posterior al incidente: la disciplina acumulativa evita el pánico del viernes por la noche.
Mantenga un runbook fechado, métricas de antes y después, revisión posterior al incidente: la disciplina acumulativa evita el pánico del viernes por la noche.
Mantenga un runbook fechado, métricas de antes y después, revisión posterior al incidente: la disciplina acumulativa evita el pánico del viernes por la noche.
Mantenga un runbook fechado, métricas de antes y después, revisión posterior al incidente: la disciplina acumulativa evita el pánico del viernes por la noche.
Persecución operativa
Mantenga un runbook actualizado, una revisión trimestral con los equipos comerciales y métricas antes y después de cada cambio. Documente las brechas entre la promesa del host y la medición de campo: latencia, cuotas, restauración, soporte. Para comparar la infraestructura y leer otros comentarios del campo, explore nuestro directorio, el comparador y las guías técnicas del blog: una decisión documentada es mejor que una actualización comprada apresuradamente el viernes por la noche.
Revisión trimestral
Compara medidas de campo y ficha de producto de hosting: latencia, cuotas, restauración, tiempos de soporte. Ajustar el contrato o la arquitectura a la evidencia, no a la sensación.
Cierre de ciclo
Comparta el runbook actualizado con el equipo de soporte y planifique el próximo ejercicio en un calendario compartido: la memoria institucional evita cometer los mismos errores.
Decide y avanza sin puntos ciegos
- Esquema de expansión/contratación: columnas que aceptan valores NULL, lectura dual, reposición, cambio de escritura, eliminación de elementos antiguos después de la paridad.
- Cortación en seco al clonar: comprobaciones de paridad automatizadas, prueba de carga de 1 hora, reversión programada.
- Modo de sesión PgBouncer: durante la migración si los scripts utilizan declaraciones preparadas.
- Partes interesadas en la comunicación: función de congelación, preguntas frecuentes de soporte, costo temporal de doble instancia.
- Ventana de producción solo después del éxito de la clonación: la medianoche no es el momento para descubrir el pedido.
RDS y base de datos gestionada: comparador, directorio, guías migración.
Preguntas frecuentes
¿Big bang o escritura dual?
El big bang concentra el riesgo en un período corto. La escritura dual reduce el tiempo de transición pero complica la aplicación.
¿Esquema antes de los datos?
Primero el esquema compatible con versiones anteriores (expandir), sincronización de datos, cambio de tráfico y luego contracción.
¿PgBouncer durante la migración?
Declaraciones preparadas de casos en modo de transacción: modo de sesión o conexión directa en el runbook documentado del día D.
¿Retroceso creíble?
Revertir DNS/pool + resincronización inversa probada en clonación: no es una diapositiva sin comandos cronometrados.
Ejecute una prueba completa de corte en el clon: la intervención de medianoche no es un buen momento para descubrir el orden.