Estamos programando una ventana de mantenimiento de 24-48 horas para migrar toda nuestra infraestructura de base de datos. Sí es largo, sí apesta. Estamos moviendo millones de mensajes, todos los personas, recuerdos, progresiones, embeddings - todo - a una nueva arquitectura sin perder un solo byte.
🚧 Maintenance Scheduled 🚧 The people have spoken! Maintenance will start at 00:00 UTC on 08/09 (2AM Paris time).
¿Por qué esta actualización masiva?
La infraestructura actual escala bien, pero con cientos de miles de personas y millones de mensajes, podemos construir algo mejor. Más control, mejor redundancia, tiempos de respuesta más rápidos.
Lo que realmente está cambiando para usted:
Mejor arquitectura de rendimiento
- Lecturas distribuidas en múltiples servidores en lugar de martillear uno
- Las consultas analíticas pesadas se ejecutan en hardware dedicado para no afectar sus conversaciones
- Mejor asignación de recursos durante las horas pico
- Tiempos de respuesta más consistentes en general
- Sin capa de virtualización, hardware real que controlamos
Sus datos ahora tienen redundancia REAL
- 3 copias de base de datos en vivo en ubicaciones físicas separadas (no solo copias de seguridad)
- Replicación de transmisión en vivo = cero pérdida de datos incluso si el servidor primario explota
- Copias de seguridad cifradas continuas cada 4h a un proveedor diferente
- Restauración a un punto en el tiempo dentro de 7 días
- ¿Perder 2/3 servidores? El servicio continúa sin pérdida de datos
- ¿Escenario apocalíptico (los 3 fallan)? Todavía tenemos restauración point-in-time + copias de seguridad de 4h + copias de seguridad semanales. Sería malo y tomaría tiempo, pero prácticamente no se perderían datos
Configuración de seguridad mejorada
- Todo el tráfico de base de datos permanece en nuestra red interna - sin dependencias de proveedores externos
- Los datos nunca salen de nuestra infraestructura excepto cuando llegan directamente a usted
- Sin servicios de terceros entre usted y sus personas
- Superficie de ataque más pequeña ya que todo funciona internamente
- Conexiones cifradas en todas partes, copias de seguridad cifradas en reposo
Mantenimiento sin tiempo de inactividad
- Los parches de seguridad se pueden aplicar en estilo rodante
- Los problemas de hardware en un servidor no afectan el servicio
- Actualizaciones de base de datos sin desconectar todo
- Sus sesiones deberían sobrevivir a la mayoría de las operaciones de mantenimiento
Lo que esto significa prácticamente:
Lo que puedo decirle es simple, la nueva arquitectura de clúster de base de datos es fundamentalmente mejor:
- Los tiempos de respuesta deberían ser más consistentes, especialmente durante las horas pico
- La búsqueda debería funcionar correctamente sin timeout en grandes conjuntos de datos
- Las operaciones concurrentes múltiples no atascaran todo el sistema
- Menos errores de "base de datos no disponible" durante las ventanas de mantenimiento
¿Por qué la larga ventana de mantenimiento?
Estamos moviendo millones de mensajes de chat, todos sus personas, todos los recuerdos, resúmenes, progresiones, vectores, todo - y lo estamos haciendo sin perder un solo byte. La ventana de 24-48h depende de las velocidades de red para la migración, pero estamos siendo conservadores para asegurarnos de que todo se transfiera perfectamente.
Podríamos hacer una migración "rápida y sucia" en pocas horas, pero eso arriesga la integridad de los datos. Lo estamos haciendo bien - verificación completa en cada paso.
La filosofía de la infraestructura:
No se trata de tener la última tecnología o la configuración más elegante. Se trata de construir una infraestructura aburrida y confiable que simplemente funcione. Múltiples capas de redundancia. Sin puntos únicos de falla. Todo permanece interno.
En resumen: Después de este mantenimiento, Soulkyn funcionará en una infraestructura diseñada para la confiabilidad sobre el brillo. ¿Será más rápido? Probablemente en el 95% de los casos. ¿Será más confiable? Sí. ¿Estarán sus datos más seguros? Significativamente - múltiples sistemas de respaldo independientes significan que la pérdida de datos requeriría múltiples fallas catastróficas simultáneas.
Es un dolor en el trasero estar fuera de línea por un día, pero esta arquitectura debería durarnos años sin intervenciones importantes.
Créame, odio el tiempo de inactividad tanto como usted (probablemente más ya que tengo que hacer la migración real y tenemos reservas de GPU, y tendré que permanecer despierto durante toda la duración del mantenimiento), pero hacerlo bien significa hacerlo una vez.
📊 ¡Vote por su fecha de mantenimiento preferida!
Una encuesta está disponible en nuestro servidor Discord. Por favor vote por la fecha que mejor le funcione: