En esta página se ofrece una descripción general de la conmutación por error manual de Memorystore para Redis. Para saber cómo realizar una conmutación por error, consulta Iniciar una conmutación por error manual.
¿Qué es una conmutación por error manual?
Una instancia de Memorystore para Redis de nivel estándar usa un nodo de réplica para crear una copia de seguridad del nodo principal. Una conmutación por error normal se produce cuando el nodo principal deja de estar en buen estado, lo que provoca que la réplica se designe como el nuevo nodo principal. Una conmutación por error manual se diferencia de una normal en que la inicias tú. Para obtener más información sobre cómo funciona la replicación de Memorystore para Redis, consulta la sección Alta disponibilidad.
¿Por qué iniciar una conmutación por error manual?
Iniciar una conmutación por error manual te permite probar cómo responde tu aplicación a una conmutación por error. Esta información puede asegurar 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). force-data-loss.
Para definir 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 la diferencia de datos entre la principal y la réplica sea inferior a 30 MB antes de iniciar la conmutación por error. El desplazamiento de la réplica principal se incrementa por cada byte de datos que se debe sincronizar con sus réplicas. En el modo limited-data-loss, la conmutación por error se cancelará si la diferencia de desplazamiento máxima entre la réplica principal y cada réplica es de 30 MB o más. Si puedes tolerar una mayor pérdida de datos y quieres ejecutar la conmutación por error de forma agresiva, prueba a definir el modo de protección de datos como 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 comprueba la diferencia de desfase entre la principal y las réplicas antes de iniciar la conmutación por error, por lo que es posible que pierdas más de 30 MB de cambios en los datos.
Métrica Bytes pendientes de replicación
La métrica Bytes pendientes de replicación indica cuántos bytes le quedan a la réplica por copiar antes de que se cree una copia de seguridad completa de la principal. Puede observar un aumento de los bytes pendientes a medida que la réplica principal se replica en la réplica durante una conmutación por error. Si la conmutación por error se activa debido a un error de hardware, es posible que observes que no hay bytes de entrada pendientes de replicación, ya que no se puede obtener el valor de desplazamiento hasta que la nueva réplica se haya reparado del error del host.
Puedes acceder a esta métrica en la Google Cloud consola, en la página de detalles de la instancia. Para ver la página de detalles de la instancia, haz clic en el ID de la instancia en la página Lista de instancias de tu proyecto.
También puede acceder al Explorador de métricas de su proyecto y buscar la métrica redis.googlapis.com/replication/offset_diff.
Cuándo ejecutar una conmutación por error manual
Las conmutaciones por error manuales que usan el modo de protección limited-data-loss predeterminado solo se realizan correctamente si la métrica Bytes pendientes de replicación es inferior a 30 MB. Si quieres realizar una conmutación por error manual con bytes pendientes de replicación superiores a 30 MB, usa el modo de protección force-data-loss.
Si quieres conservar la mayor cantidad de datos posible, detén temporalmente la escritura de tu aplicación en la instancia de Redis y espera a ejecutar la conmutación por error manual hasta que la métrica Bytes pendientes de replicación sea lo más baja posible.
Posibles problemas que impiden una conmutación por error manual
No se puede realizar una conmutación por error manual en una instancia de nivel básico porque estas instancias no tienen réplicas a las que pueda conmutar por error la instancia principal.
Si tu instancia de Redis no está en buen estado, se producirá un error en una operación manual de conmutación por error con pérdida de datos limitada porque está bloqueada para minimizar la pérdida de datos.
Si estás ejecutando una secuencia de comandos de Lua que se ejecuta indefinidamente, debes usar
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 pendientes, como escalado o actualización, la operación de conmutación por error manual se bloqueará. Debes esperar a que tu instancia esté en el estado
READYpara ejecutar una conmutación por error manual.
Conexión de aplicación cliente
Cuando tu nodo principal pasa a la réplica, se pierden las conexiones existentes con Memorystore para Redis. Sin embargo, al volver a conectarse, tu aplicación se redirige automáticamente al nuevo nodo principal con la misma cadena de conexión o dirección IP.
Verificar una conmutación por error manual
Puedes verificar si una operación de conmutación por error manual se ha realizado correctamente con laGoogle Cloud consolagcloud.
Google Cloud verificación de la consola
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.
A continuación, en la pestaña Configuración, junto a Ubicación principal, consulta en qué zona se encuentra tu nodo principal. Anota la zona. Vuelve a consultar esta página cuando completes la conmutación por error manual para confirmar que el nodo principal ha cambiado de zona.
Verificación de Cloud Monitoring
Para ver las métricas de un recurso monitorizado con el explorador de métricas, haz lo siguiente:
-
En la Google Cloud consola, ve a la página leaderboard Explorador de métricas:
Si usas la barra de búsqueda para encontrar esta página, selecciona el resultado cuya sección sea Monitorización.
- En la barra de herramientas de la Google Cloud consola, selecciona tu Google Cloud proyecto. En las configuraciones de App Hub, selecciona el proyecto host de App Hub o el proyecto de gestión de la carpeta habilitada para aplicaciones.
- En el elemento Métrica, despliega el menú Seleccionar una métrica,
introduce
Node roleen la barra de filtros y, a continuación, usa los submenús para seleccionar un tipo de recurso y una métrica específicos:- En el menú Recursos activos, selecciona Cloud Memorystore Redis.
- En el menú Categorías de métricas activas, selecciona replicación.
- En el menú Métricas activas, selecciona Rol de nodo.
- Haz clic en Aplicar.
Para añadir filtros que eliminen series temporales de los resultados de la consulta, usa el elemento Filter.
Para combinar series temporales, usa los menús del elemento "Agregación". Por ejemplo, para mostrar el uso de la CPU de tus VMs en función de su zona, define el primer menú como Media y el segundo como zona.
Todas las series temporales se muestran cuando el primer menú del elemento Agregación se define como Sin agregar. Los ajustes predeterminados del elemento Agregación se determinan en función del tipo de métrica que hayas seleccionado.
- En el caso de las cuotas y otras métricas que registran una muestra al día, haga lo siguiente:
- En el panel Visualización, defina el Tipo de widget como Gráfico de barras apiladas.
- Define el periodo en al menos una semana.
El gráfico de Cloud Monitoring representa los nodos principales y de réplica con dos líneas. Cuando la línea de un nodo tiene el valor cero en el gráfico, se trata del nodo de réplica. Cuando la línea de un nodo tiene el valor uno en el gráfico, se trata del 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 de gcloud
Antes de iniciar una conmutación por error manual, usa el siguiente comando para comprobar en qué zona se encuentra tu nodo principal:
gcloud redis instances describe [INSTANCE_ID] --region=[REGION]
Tu nodo principal está en la zona etiquetada como currentLocationId. Anota la zona.
Después de completar una conmutación por error manual, puedes confirmar que tu nodo principal ha cambiado a una nueva zona ejecutando de nuevo el comando gcloud redis instances describe y comprobando que currentLocationId ha cambiado de zona.
Además, la etiqueta locationId indica la zona en la que aprovisionaste originalmente tu nodo principal. La etiqueta alternativeLocationId indica la zona en la que el sistema aprovisionó originalmente tu nodo de réplica. Cada vez que se produce una
conmutación por error, la principal y la réplica cambian entre estas dos zonas. Sin embargo, las zonas asociadas a locationId y alternativeLocationId no cambian.