Confirma que la nueva principal está realmente promovida y aceptando escrituras, y luego comprueba si las aplicaciones se reconectaron. Los pools de conexiones obsoletos y el DNS cacheado son la razón habitual de que los errores continúen tras un failover sano. Verifica el retraso de replicación y si se perdió alguna escritura confirmada frente a tu RPO. Restaura el tráfico de escritura, descarta el split brain asegurándote de que la principal antigua está aislada, y luego lleva a la autopsia la pregunta de por qué el failover no fue transparente.
Por qué lo preguntan los entrevistadores
Los entrevistadores quieren ver que no te quedas en que la base de datos se ve bien. La capa de aplicación es donde viven de verdad la mayoría de los incidentes de failover, por pools de conexiones que retienen sockets muertos, TTL de DNS y drivers que nunca vuelven a resolver. También comprueban si piensas en pérdida de datos y en fencing y no solo en disponibilidad.
Cómo estructurar tu respuesta
- Verifica la promoción y la aceptación de escrituras directamente en la nueva principal.
- Pasa a la capa cliente: pools, caché de DNS, comportamiento del driver.
- Cuantifica la pérdida de datos y el retraso frente al RPO declarado.
- Aísla la principal antigua para descartar escrituras dobles.
- Restaura el tráfico y luego recoge el hueco de transparencia para la autopsia.
Ejemplo de respuesta
El paso uno es confirmar la realidad: conectarme directamente a la nueva principal y comprobar que ha salido de recuperación y acepta escrituras. Si la base de datos está sana y las aplicaciones siguen dando error, el problema es nuestro, y en mi experiencia ahí es donde suele estar. Los pools de conexiones retienen sockets hacia una dirección que ya no sirve escrituras, o la JVM cacheó la entrada DNS para siempre, así que el arreglo es un reinicio progresivo o un pool con validación decente. Tuvimos uno donde el driver respetaba un TTL de 30 segundos pero el pool nunca revalidaba las conexiones ociosas, así que la recuperación tardó veinte minutos más de lo debido. Después miro el retraso de replicación en el momento de la promoción para ver si perdimos escrituras confirmadas, porque eso cambia a quién tengo que avisar. También quiero confirmación de que la principal antigua está aislada y no puede aceptar una escritura si vuelve. Una vez fluyen las escrituras, la pregunta para la autopsia es por qué esto no fue automático.
¿Tienes esta entrevista a la vuelta de la esquina? GhostPilot escucha tu llamada en vivo, detecta la pregunta en cuanto la hacen y pone una respuesta estructurada en tu pantalla en tiempo real. Pruébalo en tu próxima entrevista de práctica, o coge un Session Pass de $29, sin suscripción, para la de verdad.
Mira cómo funcionaPreguntas de seguimiento que puedes esperar
- ¿Cómo harías que el failover fuera transparente para la aplicación la próxima vez?
- ¿Cómo detectas que se perdieron escrituras durante la promoción?
- ¿Cuál es el riesgo del failover automático y cuándo lo evitarías?
Más preguntas para Site Reliability Engineer
Tu entrevistador hará su propia versión de esta. Pega la descripción real del puesto en el Question Predictor gratuito y obtén las 20 preguntas que ese puesto tiene más probabilidades de hacerte, con lo que cada una busca en realidad.
Predecir mis preguntas