El cambio de 26 minutos parecía terminado hasta que un panel escribió en la copia antigua. La lección: controlar escritores, conciliar y recuperar sin perder trabajo.
Autor
Anichur Rahaman
A las 22:59 del 5 de octubre de 2026 terminó la ventana de base de datos. El servicio volvía tras 26 minutos. A las 23:24 apareció un panel administrativo que seguía escribiendo en el servidor anterior. Se había mudado la aplicación, pero no toda su población de escritores.
NovaCommerce es una plataforma de cursos y exámenes anonimizada. Esta parte conserva el registro existente de septiembre–octubre y corrige la orientación técnica. Las cifras históricas no son una auditoría nueva ni benchmarks de StoreConsole.
Antes había un MySQL gestionado de 8 vCPU/32 GB sin standby. El diseño histórico pasó a MySQL 8.4 Standard, 4 vCPU/16 GB por nodo, primario y reserva, con unos 11 GB de datos. Esto aborda el fallo de una máquina; no demuestra pérdida nula, promoción instantánea ni recuperación regional.
Los aproximadamente $389/mes de la pareja son presupuesto histórico. DigitalOcean documenta restricciones Standard Edition desde el 15 de octubre de 2026 para cuentas de nueva aplicación y el 30 de noviembre para todas. Comprueba cuenta, plan y disponibilidad de standby antes de reproducirlo. La reserva replica también borrados accidentales: no sustituye una copia de seguridad.
El registro describe mantenimiento a las 22:33, drenaje de colas, parada del programador, 30 segundos sin escrituras, copia de unos diez minutos, validación e imágenes nuevas antes de las 22:59. Un intervalo tranquilo no bloquea un cliente olvidado. Inventaría web, trabajadores, tareas, callbacks, importaciones y paneles externos; impide escrituras antiguas antes de obtener una copia coherente.
Se reportaron totales coincidentes, comprobaciones posteriores de contenidos y comparación detallada de una tabla de resultados. Conserva qué se comparó, con qué método y en qué instantánea. Igualar recuentos no demuestra contenidos iguales; comparar después del corte exige delimitar conciliación. Revisa roles, esquema, rutinas/eventos utilizados, codificación y guardado/lectura reales. El mysqldump estándar no es un motor de volcado paralelo: una envoltura multistream no documentada no es una receta reproducible de coherencia.
| Observación histórica | Valor registrado | Lo que no demuestra |
|---|---|---|
| Totales copiados | 341 tablas; 18,727,244 filas | Igual recuento ≠ igual estado de negocio |
| Comparación mayor | Unos 2.76 millones de filas | Conservar alcance y método |
| Primeros cuatro minutos | Unas 2,900 peticiones; 0 5xx | No todo flujo o escritor posterior |
| Escrituras antiguas tardías | 48 =44 incorporadas +4 conservadas | No es una política general de mezcla |
| Estimación solo web | 10 ×80 =800 | Excluye lectura/escritura, trabajador y solape |
El panel añadió 48 filas al origen. La reparación histórica incorporó 44 y conservó cuatro versiones más recientes del destino; después se cambió el panel y sus credenciales antiguas. La igualdad 44+4=48 describe ese incidente, no una regla universal de “gana el timestamp mayor”. Relojes, borrados, relaciones y ediciones simultáneas necesitan reglas de negocio y trazabilidad.
Detén escritores omitidos y termina o bloquea las conexiones existentes. Cambiar una contraseña puede no cerrar una sesión ya autenticada. Comprueba que el origen rechaza escrituras. El cluster anterior se mantuvo congelado 48 horas; tras aceptar trabajo nuevo es material de recuperación, no un destino de rollback actualizado. Volver sin conciliar puede perder respuestas aceptadas. La retención debe seguir recuperación probada y obligaciones, no una regla fija de 48 horas.
El caso usaba standby y primario como lectores, primario para escrituras y para el trabajador. Un endpoint de lectura standby admitido puede aprovechar capacidad pagada, pero comparte recursos de recuperación. Revisa soporte, retraso y fallos; un lector dedicado no siempre es desperdicio.
Laravel sticky=true conserva en la conexión de escritura las lecturas posteriores a una escritura dentro de la misma petición. No protege por sí solo la petición siguiente ni toda la sesión. Hace falta un mecanismo probado entre peticiones o leer respuestas autoritativas del primario. Varios hosts no garantizan failover universal de dos segundos ni repetición segura de cualquier consulta. Distingue fallo al conectar de una consulta ya ejecutada.
La estimación 10 nodos ×80 procesos PHP-FPM=800 suponía una conexión por proceso. Con lectura y escritura pueden ser 1,600 antes del trabajador, administración y solapamiento de despliegue, frente al límite histórico de 1,601. Cuenta todas las fuentes y generaciones de nodos. Ese límite no garantiza rendimiento.
Los embeddings estaban en PostgreSQL 17/pgvector separado, históricamente 2 vCPU/4 GB. Se revirtió una prueba con 1 vCPU/2 GB por las necesidades de carga. Separar instancias da presupuestos propios de CPU/memoria; aplicación, red o proveedor compartidos aún acoplan fallos. No significa que todas las ofertas MySQL carezcan de capacidades vectoriales.
En el examen del 7 de octubre se reportaron CPU MySQL máxima 24.5%, media 13.4%, cinco consultas activas como máximo y cero esperas de bloqueo observadas. Eso indica que esos indicadores no se saturaron en esa ventana. No demuestra un techo de 450 requests/s ni seis veces de capacidad; cambian consultas, contención, I/O y failover.
Separa credenciales mínimas de aplicación de permisos de migración, restringe acceso y prueba restauraciones con verificaciones del negocio y objetivos de recuperación medidos. Standby configurado, copia exitosa y restauración probada son evidencias diferentes. La parte 4 continúa con las colas y el trabajador.
Revisión: 6 de noviembre de 2026. Anichur Rahaman, fundador de StoreConsole. Cifras y precios históricos; fuentes primarias actuales para las precisiones técnicas.
Sobre el autor
Anichur Rahaman
Seguir Leyendo
