Esta página ofrece una descripción general de la conmutación por error manual para Memorystore para Redis. Para aprender a realizar una conmutación por error, consulta Inicia una conmutación por error manual.
¿Qué es una conmutación por error manual?
Una instancia de nivel estándar de Memorystore para Redis usa un nodo de réplica para crear una copia de seguridad del nodo principal. Una conmutación por error normal ocurre cuando el nodo principal se encuentra en mal estado, lo que hace que la réplica se designe como la instancia principal nueva. Una conmutación por error manual difiere de una conmutación por error normal porque la inicias tú mismo. Para obtener más información acerca de cómo funciona la replicación de Memorystore para Redis, consulta Alta disponibilidad.
¿Por qué debería iniciar una conmutación por error manual?
Iniciar una conmutación por error manual te permite probar cómo responde tu aplicación ante una conmutación por error. Este conocimiento puede garantizar un proceso de conmutación por error más fluido si se produce una conmutación por error inesperada más adelante.
Modo de protección de datos opcional
Los dos modos de protección de datos disponibles son los siguientes:
- Modo
limited-data-loss(predeterminado). - Modo
force-data-loss
Para configurar el modo de protección de datos, usa uno de los siguientes comandos:
gcloud redis instances failover INSTANCE_NAME --data-protection-mode=limited-data-loss
o
gcloud redis instances failover INSTANCE_NAME --data-protection-mode=force-data-loss
Cómo funcionan los modos de protección de datos
El modo limited-data-loss minimiza la pérdida de datos verificando que el elemento
la diferencia en los datos entre la instancia principal y la réplica es inferior a 30 MB antes
iniciar la conmutación por error. El desplazamiento en la instancia principal aumenta para cada byte
de datos que deben sincronizarse con sus réplicas. En limited-data-loss
la conmutación por error se anulará si el valor de delta más alto entre
y cada réplica es de 30 MB o más. Si puedes tolerar más pérdida de datos y quieres
para ejecutar la conmutación por error de forma agresiva, intenta configurar el modo de protección de datos en
force-data-loss
El modo force-data-loss emplea una cadena de estrategias de conmutación por error para
ejecutar la conmutación por error de forma agresiva. No verifica la delta de compensación entre la réplica principal y las réplicas antes de iniciar la conmutación por error. Es posible que pierdas más de 30 MB de cambios de datos.
Métrica de bytes con replicación pendiente
La métrica Bytes con replicación pendiente indica cuántos bytes restantes necesita copiar la réplica antes de que se cree una copia de seguridad completa. Es posible que observes un aumento en bytes pendiente porque la instancia principal se replica en la réplica durante una conmutación por error. Si la conmutación por error se activa por un error de hardware, es posible que observes el valor vacío en bytes con espera de replicación, ya que el valor de desplazamiento no se pudo obtener hasta que la nueva réplica se repare a partir de un error de host.
Puedes acceder a esta métrica en la página de detalles de la instancia de la consola de Google Cloud. Para ver de detalles de la instancia, haz clic en el ID de la instancia en la lista de instancias de tu proyecto. .
De manera alternativa, accede al Explorador de métricas de tu proyecto y busca la métrica redis.googlapis.com/replication/offset_diff.
Cuándo ejecutar una conmutación por error manual
La conmutación por error manual con el modo de protección limited-data-loss predeterminado solo funciona si la métrica de bytes con replicación pendiente es inferior a 30 MB. Si deseas ejecutar una conmutación por error manual con bytes con replicación pendiente superiores a 30 MB, usa el modo de protección force-data-loss.
Si intentas conservar la mayor cantidad de datos posible, evita temporalmente que tu aplicación escriba en la instancia de Redis y espera a ejecutar la conmutación por error manual hasta que la métrica de bytes con replicación pendiente sea lo más baja posible. .
Posibles problemas que bloquean una conmutación por error manual
Ejecutar una conmutación por error manual en una instancia de nivel básico no funciona porque las instancias de nivel básico no tienen réplicas a las que pueda conmutarse por error la instancia principal.
Si tu instancia de Redis no está en buen estado, una conmutación por error manual de pérdida limitada de datos falla porque está bloqueada para la minimización de pérdida de datos.
Si ejecutas una secuencia de comandos de Lua que se ejecuta de forma indefinida, debes usa
force-data-losspara iniciar una conmutación por error. En esta situación, una operación de conmutación por error con pérdida de datos limitada no se completará correctamente.Si tu instancia tiene operaciones incompletas, como escalamientos o actualizaciones, la operación de conmutación por error manual se bloquea. Debes esperar hasta que tu instancia esté en estado
READYpara ejecutar una conmutación por error manual.
Conexión de la aplicación cliente
Cuando el nodo principal se conmuta por error a la réplica, las conexiones existentes con Memorystore para Redis se descartan. Sin embargo, cuando se vuelve a conectar, tu aplicación se redirecciona automáticamente al nuevo nodo principal mediante la misma string de conexión o dirección IP.
Verifica una conmutación por error manual
Puedes verificar el éxito de una operación manual de conmutación por error con el
Consola de Google Cloud o gcloud.
Verificación de la consola de Google Cloud
Antes de iniciar una conmutación por error manual, ve a la página de lista de instancias de Memorystore para Redis y haz clic en el nombre de tu instancia.
Luego, en la pestaña Configuration, junto a Primary Location, observa en qué zona se encuentra el nodo principal. Toma nota de la zona. Vuelve a consultar esta página cuando completar la conmutación por error manual para confirmar que el nodo principal haya cambiado de zona.
Verificación de Cloud Monitoring
Para consultar las métricas de un recurso supervisado usando el Explorador de métricas, haz lo siguiente:
-
En la consola de Google Cloud, ve a la página leaderboardExplorador de métricas:
Si usas la barra de búsqueda para encontrar esta página, selecciona el resultado cuyo subtítulo es Monitoring.
- En el elemento Métrica, expande el menú Seleccionar una métrica,
ingresa
Node roleen la barra de filtros y, luego, usa los submenús para seleccionar un métrica y tipo de recurso específicos:- En el menú Recursos activos, selecciona Redis para Cloud Memorystore.
- En el menú Categorías de métricas activas, selecciona replicación.
- En el menú Métricas activas, selecciona Rol del nodo.
- Haz clic en Aplicar.
Para quitar series temporales de la pantalla, usa el elemento Filtro.
Para combinar series temporales, usa los menús del elemento Agregación. Por ejemplo, para mostrar el uso de CPU de tus VM, en función de su zona, configura el primer menú como Mean y el segundo menú como zona.
Todas las series temporales se muestran cuando el primer menú del elemento Agregación se establece en Sin agregar. La configuración predeterminada para el elemento Agregación está determinada por el tipo de métrica que elegiste.
- Para obtener cuotas y otras métricas que informen una muestra por día, haz lo siguiente:
- En el panel Mostrar, establece el Tipo de widget en Gráfico de barras apiladas.
- Establece el período en al menos una semana.
El gráfico de Cloud Monitoring representa el nodo principal y el de réplica con dos líneas. Si la línea de un nodo tiene un valor de cero en el gráfico, es el nodo de réplica. Si la línea de un nodo tiene un valor de uno en el gráfico, es el nodo principal. El gráfico representa una conmutación por error mostrando cómo las líneas cambian de uno a cero, y de cero a uno, respectivamente.
Verificación gcloud
Antes de iniciar una conmutación por error manual, usa el siguiente comando para verificar en qué zona se encuentra tu nodo principal:
gcloud redis instances describe [INSTANCE_ID] --region=[REGION]
Tu nodo principal se encuentra en la zona con la etiqueta currentLocationId. Anota la zona.
Después de completar una conmutación por error manual, puedes confirmar que tu nodo principal haya cambiado a una nueva zona mediante la ejecución del comando gcloud redis instances describe y verifica que currentLocationId haya cambiado la zona.
Además, la etiqueta locationId te indica la zona en la que aprovisionaste originalmente tu nodo principal. La etiqueta alternativeLocationId te indica la zona en la que el sistema aprovisionó originalmente tu nodo de réplica. Cada vez que ocurre una conmutación por error, el nodo principal y el de réplica se cambian entre estas dos zonas. Sin embargo, las zonas asociadas con locationId y alternativeLocationId no cambian.