Conmutaciones por error

Si un clúster de Bigtable deja de responder, la replicación hace posible que las solicitudes tráfico a otro clúster de la misma instancia. Las conmutaciones por error pueden ser manuales o automáticas, según el perfil de aplicación que use una aplicación y su configuració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. Si deseas aprender a completar una conmutación por error, consulta Administra 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 app usa el enrutamiento de un solo clúster a fin de dirigir todas las solicitudes a un clúster, debes usar tu propio juicio para decidir cuándo comenzar a conmutar por otro diferente.

Estas son algunas señales que podrían indicar la necesidad de realizar una conmutación por error a otro clúster:

  • El clúster comienza a mostrar una gran cantidad de errores de sistema transitorios.
  • Se agota el tiempo de espera de muchas solicitudes.
  • La latencia de respuesta promedio aumenta a un nivel inaceptable.

Dado que estas señales pueden aparecer por diversos motivos, no se puede garantizar que la conmutación por error resuelva los problemas subyacentes. Supervisa tu instancia antes y después de realizar la conmutación a fin de verificar si las métricas mejoraron.

Si deseas obtener más detalles sobre cómo completar una conmutación por error manual, consulta Cómo completar una conmutación por error manual.

Conmutaciones por error automáticas

Si un perfil de aplicación usa un enrutamiento de varios clústeres, Bigtable controla las conmutaciones por error automáticamente. Cuando un clúster no puede controlar una solicitud, Bigtable enruta el tráfico hacia el clúster más cercano que está disponible.

Las conmutaciones por error automáticas pueden ocurrir incluso cuando un clúster deja de estar disponible por un período muy breve. Por ejemplo, si Bigtable enruta una solicitud a un clúster, y ese clúster es demasiado lento para responder o muestra un error transitorio, Bigtable normalmente vuelve a realizar esa solicitud en otro clúster.

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

Bigtable usa un algoritmo interno de gana la última escritura para controlar los conflictos de datos que pueden ocurrir como resultado de la conmutación por error antes de que se complete la replicación. Consulta Resolución de conflictos para obtener más detalles.

Si usas la replicación con enrutamiento de varios clústeres a fin de lograr una alta disponibilidad (HA) para la aplicación, debes ubicar tus servidores cliente o VM en más de una región de Google Cloud o cerca de estas. Esta recomendación se aplica incluso si tu servidor de aplicaciones no está alojado en Google Cloud porque tus datos ingresan a la red de Google Cloud a través de la región de Google Cloud más cercana a tu servidor de aplicaciones. Al igual que cualquier solicitud, una conmutación por error se completa más rápido en distancias más cortas.

Muchas conmutaciones por error son tan breves que el usuario ni siquiera las nota. Puedes consultar el gráfico de conmutaciones por error automáticas en la consola de Google Cloud para ver la cantidad de solicitudes que se redirigieron de forma automática durante un período determinado: abre la lista de instancias, haz clic en el nombre de la instancia y, luego, en Monitoring.

¿Qué sigue?