Conmutaciones por error

Si un clúster de Bigtable deja de responder, la replicación permite que el tráfico entrante se redirija a otro clúster de la misma instancia. Las conmutaciones por error pueden ser manuales o automáticas, en función del perfil de aplicación que utilice una aplicación y de cómo esté configurado el perfil de aplicación.

En esta página se explica cómo funcionan las conmutaciones por error manuales y automáticas en una instancia que usa la replicación. Para saber cómo completar una conmutación por error, consulta Gestionar conmutaciones por error.

Antes de leer esta página, debes familiarizarte con la descripción general de la replicación de Bigtable. También debes conocer las opciones de enrutamiento disponibles.

Conmutaciones por error manuales

Si un perfil de aplicación usa el enrutamiento de un solo clúster para dirigir todas las solicitudes a un clúster, debes decidir cuándo empezar a conmutar a otro clúster.

Estas son algunas señales que pueden indicar que sería útil cambiar a otro clúster:

  • El clúster empieza a devolver un gran número de errores transitorios del sistema.
  • Un gran número de solicitudes empiezan a agotar el tiempo de espera.
  • La latencia media de respuesta aumenta hasta un nivel inaceptable.

Dado que estas señales pueden aparecer por muchos motivos diferentes, no se garantiza que el cambio a otro clúster resuelva el problema subyacente. Monitoriza tu instancia antes y después de la conmutación por error para verificar que las métricas han mejorado.

Para obtener información sobre cómo completar una conmutación por error manual, consulta el artículo Completar una conmutación por error manual.

Conmutaciones por error automáticas

Si un perfil de aplicación usa el enrutamiento a varios clústeres, Bigtable gestiona las conmutaciones por error automáticamente. Cuando el clúster más cercano no puede gestionar una solicitud, Bigtable dirige el tráfico al clúster disponible más cercano.

Las conmutaciones por error automáticas pueden producirse aunque un clúster no esté disponible durante un periodo muy breve. Por ejemplo, si Bigtable enruta una solicitud a un clúster y este tarda demasiado en responder o devuelve un error transitorio, Bigtable suele volver a intentar esa solicitud en otro clúster.

Si usas el enrutamiento a varios clústeres y envías una solicitud con una fecha límite, Bigtable realizará automáticamente una conmutación por error cuando sea necesario para cumplir la fecha límite. Si se acerca la fecha límite de la solicitud, pero el clúster inicial no ha enviado una respuesta, Bigtable redirige la solicitud al siguiente clúster más cercano.

Bigtable usa un algoritmo interno de prevalece la última escritura para gestionar los conflictos de datos que puedan producirse como resultado de una conmutación por error antes de que se haya completado la replicación. Consulta más información sobre la resolución de conflictos.

Si utilizas la replicación con enrutamiento de varios clústeres para conseguir una alta disponibilidad en tu aplicación, debes ubicar tus servidores cliente o tus máquinas virtuales en más de una región o cerca de ellas Google Cloud . Esta recomendación se aplica aunque tu servidor de aplicaciones no esté alojado en Google Cloud, ya que tus datos entran en la red de Google Cloud a través de la región de Google Cloudmás cercana a tu servidor de aplicaciones. Al igual que cualquier otra solicitud, una conmutación por error se completa más rápido si las distancias son más cortas.

Muchas conmutaciones por error automáticas son tan breves que no las notarás. Puedes consultar el gráfico Conmutaciones por error automáticas en la consola Google Cloud para ver el número de solicitudes que se han redirigido automáticamente durante un periodo determinado. Para ello, abre la lista de instancias, haz clic en el nombre de la instancia y, a continuación, en Estadísticas del sistema.

Siguientes pasos