Utilice esta guía para escalar vertical u horizontalmente su instancia de Tair (compatible con Redis OSS). Actualice la instancia para manejar un mayor tráfico o redúzcala para disminuir costos durante los periodos de menor uso.
Facturación
La facturación depende del método de pago:
|
Método de facturación |
Descripción |
|
subscription |
Se paga la diferencia de precio en una actualización o se recibe un reembolso en una reducción. |
|
pay-as-you-go |
La facturación se calcula según las nuevas especificaciones. |
Para conocer los detalles de precios, consulte Configuration changes.
Limitaciones
Compruebe las siguientes restricciones antes de comenzar:
|
Restricción |
Detalles |
|
Límite mínimo de memoria para reducciones |
Después de una reducción, la memoria utilizada no puede superar el 80 % de la nueva capacidad de memoria. Por ejemplo, si su instancia basada en DRAM tiene actualmente 2 GB en uso, no puede reducirla a menos de 2.5 GB. |
|
Instancias distribuidas |
Todas las instancias secundarias dentro de una instancia distribuida deben tener especificaciones idénticas. No se admiten especificaciones mixtas. |
|
Instancias basadas en ESSD |
La capacidad de almacenamiento solo puede aumentar, en incrementos de 10 GB. No se admite la reducción del almacenamiento. |
|
Actualizaciones exclusivas de CPU |
No es posible actualizar la CPU de forma independiente. Para aumentar los núcleos de CPU disponibles, cambie a la arquitectura de clúster, habilite la división de lectura y escritura, agregue nodos de solo lectura o añada fragmentos. |
Cambio de especificaciones de la instancia
Elementos que permanecen sin cambios
Al cambiar las especificaciones, los siguientes elementos permanecen iguales. Por lo tanto, no se requieren modificaciones en el código de la aplicación:
Endpoints
Cuentas y contraseñas de la base de datos
Configuración de la lista blanca
Los datos de la instancia se conservan. En el caso poco frecuente de que el nodo principal falle durante el cambio, se podría perder una pequeña cantidad de datos no sincronizados. Como medida de precaución, cree una copia de seguridad manual antes de cambiar las especificaciones.
El cambio de especificaciones, ya sea para escalar hacia arriba o hacia abajo, no afecta directamente la utilización de la CPU, el número de conexiones de clientes, el rendimiento ni la tasa de aciertos de la caché. Estas métricas dependen de la carga de trabajo real y no del nivel de especificaciones.
Impacto en el servicio
Tanto el escalado vertical (actualizaciones) como el escalado descendente (reducciones, incluidas aquellas que disminuyen únicamente la memoria del nodo) pueden desencadenar una migración de host cuando el host actual no admite las especificaciones de destino. Un cambio con migración no es transparente: provoca entre una y dos interrupciones breves de conexión y aproximadamente un minuto en estado de solo lectura. Únicamente las instancias de clúster nativas de la nube y las instancias estándar nativas de la nube alojadas en hosts con recursos suficientes completan el cambio en el mismo lugar y sin tiempo de inactividad.
|
Escenario |
Interrupción del servicio |
|
Instancia de clúster nativa de la nube, o instancia estándar nativa de la nube en un host con recursos suficientes |
Ninguna. La actualización se aplica en el mismo lugar de forma transparente y sin tiempo de inactividad. |
|
Instancia estándar nativa de la nube en un host con recursos insuficientes, o cualquier instancia Classic |
Una o dos desconexiones transitorias (cada una con una duración inferior a 30 segundos), además de aproximadamente un minuto en estado de solo lectura. Asegúrese de que su aplicación se reconecte automáticamente. |
Cuando ocurre un cambio, la instancia también permanece en modo de solo lectura durante aproximadamente un minuto. Esto garantiza una sincronización rápida de los datos y evita problemas de escritura dual causados por el almacenamiento en caché de DNS. En instancias con altos volúmenes de escritura, este periodo puede ser más largo.
Durante el cambio, la versión secundaria de la instancia se actualiza automáticamente a la más reciente. Las versiones secundarias son compatibles con versiones anteriores.
Duración del cambio de configuración
La duración total de un cambio de configuración consta de dos fases:
Preparación en el backend: el sistema aprovisiona nuevos nodos con la especificación de destino y sincroniza los datos. Este proceso puede tardar desde decenas de minutos hasta varias horas, según el volumen de datos. Durante esta fase, la instancia continúa atendiendo solicitudes con normalidad y el negocio no se ve afectado.
Cambio: una vez finalizada la preparación, el tráfico se dirige a los nuevos nodos. Las instancias de clúster nativas de la nube y las instancias estándar con recursos suficientes realizan el cambio de forma transparente. En otros casos, se producen una o dos desconexiones transitorias de menos de 30 segundos cada una.
Por lo tanto, la duración total del cambio de configuración (de decenas de minutos a varias horas) y la duración del impacto en el negocio (menos de 30 segundos o nulo) son dos conceptos distintos. Puede seguir el progreso en el Task Center de la consola.
Pasos
Inicie sesión en la página Instances. En la barra de navegación superior, seleccione la región donde reside su instancia y luego haga clic en el ID de la instancia.
-
En la esquina superior derecha, haga clic en Specification Adjustment y seleccione la opción correspondiente:
Instancia de subscription: seleccione Specification Upgrade o Specification Downgrade.
Instancia de pay-as-you-go: seleccione Specifications Upgrade/Downgrade.
En la página que aparece, seleccione las especificaciones de destino.
-
Establezca el parámetro Switching Time:
Switch During the Maintenance Window: el sistema aplica el cambio durante la maintenance window configurada (horas de menor actividad). Para ajustar el horario antes del cambio, vaya al Task Center y haga clic en Change Switching Time junto a la tarea.
Switch Immediately After Data Migration: el sistema cambia al nuevo nodo inmediatamente después de que finalice la migración de datos.
Haga clic en Create Now y complete el pago.
Después de enviar la solicitud, el estado de la instancia cambia a Changing Configuration. El sistema comienza a solicitar recursos y a sincronizar datos en segundo plano, por lo que sus servicios no se ven afectados en esta etapa. Las desconexiones transitorias solo ocurren en el momento del cambio al nuevo nodo.
Funcionamiento de los cambios de especificaciones
Comprender el proceso subyacente le permite predecir cuándo podrían ocurrir interrupciones.
Instancia nativa de la nube
La instancia entra en el estado Changing Configuration.
El sistema comprueba si el host actual cuenta con recursos suficientes para las especificaciones de destino.
-
Según los recursos disponibles, el sistema sigue una de estas dos rutas:
Recursos suficientes: el cambio de especificaciones se completa en el mismo lugar y sin interrupciones.
Recursos insuficientes: el sistema aprovisiona un nuevo nodo host, presincroniza los datos de la instancia en él y luego dirige el tráfico al nuevo nodo dentro de la ventana de mantenimiento (o de inmediato). Esto provoca una breve desconexión transitoria.
La instancia vuelve al estado Running.
Instancia Classic
La instancia entra en el estado Changing Configuration.
El sistema aprovisiona un nuevo nodo host y presincroniza los datos de la instancia en él.
El sistema dirige el tráfico al nuevo nodo dentro de la ventana de mantenimiento (o de inmediato). Esto provoca una breve desconexión transitoria.
La instancia vuelve al estado Running.
Preguntas frecuentes
¿Puedo actualizar solo la CPU sin modificar la memoria?
No. Tair (incluida Redis Open-Source Edition) no admite la actualización independiente de la CPU. Para aumentar los núcleos de CPU disponibles, utilice uno de los siguientes métodos:
Cambie de la arquitectura estándar a la de clúster, o bien habilite la división de lectura y escritura.
Agregue nodos de solo lectura (para instancias con la división de lectura y escritura habilitada).
Añada fragmentos (para instancias de clúster).
Para obtener más información, consulte How to upgrade the CPU specifications of an instance y Instance types and FAQ.
¿La actualización de la especificación de memoria aumenta el ancho de banda?
¿Qué significa el error "The direct custins transfer node double target level error"?
¿Qué debo considerar antes de cambiar las especificaciones si el uso de memoria es alto?
Si planea reducir la instancia y el uso actual de memoria es alto, compruebe primero que la especificación de destino cumple con la siguiente restricción: nueva capacidad de memoria × 0.8 > memoria utilizada actualmente. Si no se cumple esta condición, la reducción falla y se conserva la configuración original, por lo que no se pierden datos.
Si planea escalar verticalmente para resolver un uso de memoria persistentemente alto, considere investigar primero la causa raíz. Eliminar datos innecesarios (por ejemplo, al limpiar claves sin uso, establecer políticas de TTL o ajustar la política de desalojo) reduce el consumo de memoria. Esto le permitiría posponer o evitar una actualización. Para consultar un enfoque sistemático de solución de problemas, consulte Troubleshoot high memory usage.