La edición Basic de RDS es una edición de base de datos de nodo único con cómputo y almacenamiento desacoplados. No cuenta con instancia secundaria, lo que elimina la sobrecarga de replicación y reduce el costo en un 50 % respecto a la edición High-availability de RDS, aunque tampoco dispone de failover automático.
Dado que la edición Basic de RDS no tiene instancia en espera, las fallas inesperadas, los cambios de especificaciones de la instancia y las actualizaciones del motor de base de datos pueden provocar tiempos de inactividad prolongados (de más de 30 minutos). Para cargas de trabajo de producción que requieren alta disponibilidad, utilice la edición High-availability de RDS. Puede actualizarla en cualquier momento; consulte Upgrade the edition.

Elegir una edición
Utilice esta tabla para determinar si la edición Basic de RDS se ajusta a sus requisitos.
|
Edición Basic de RDS |
Edición High-availability de RDS |
|
|
Arquitectura |
Independiente (nodo único) |
Instancia principal + secundaria |
|
Failover automático |
No |
Sí |
|
Conmutación principal/secundaria |
No compatible |
Compatible |
|
Instancias de solo lectura |
No compatible |
Compatible |
|
Gestión de registros |
No compatible |
Compatible |
|
Lista de permitidos de direcciones IP |
Compatible |
Compatible |
|
Monitoreo y alertas |
Compatible |
Compatible |
|
Copia de seguridad y restauración |
Compatible |
Compatible |
|
Tiempo de inactividad durante actualización del motor o cambio de especificaciones |
Hasta más de 30 minutos |
Mínimo |
|
Precio |
50 % menos que la edición High-availability |
Base |
Para consultar la lista completa de funciones, véase Features of ApsaraDB RDS for SQL Server .
Funcionamiento
La edición Basic de RDS separa el cómputo y el almacenamiento en capas independientes:
Capa de cómputo: El motor de base de datos se ejecuta en un solo nodo de cómputo. No se replica ningún dato a una instancia secundaria, por lo que no existe sobrecarga de replicación. Por ello, la edición Basic de RDS ofrece mayor throughput que la edición High-availability de RDS con la misma configuración.
Capa de almacenamiento: Los archivos de la base de datos residen en discos en la nube administrados por el sistema distribuido Apsara de Alibaba Cloud, el cual mantiene varias copias de sus datos. Los recursos de cómputo están desacoplados de los recursos de almacenamiento, lo que evita la pérdida de datos cuando fallan los nodos de cómputo.
El sistema operativo distribuido Apsara de gran escala de Alibaba Cloud garantiza la confiabilidad de su servicio de base de datos mediante la conservación de varios copias de sus datos.
Casos de uso
La edición Basic de RDS es adecuada para entornos que no son de producción y cargas de trabajo sensibles al costo:
Desarrollo y pruebas: Aprovisione instancias rápidamente y escálelas según su carga de trabajo. El aprovisionamiento rápido acorta los ciclos de investigación y desarrollo (R&D).
Aprendizaje y evaluación: Si comienza a utilizar ApsaraDB RDS, la edición Basic le permite explorar el servicio a un menor costo.
Sitios web y aplicaciones pequeñas: Delegue las tareas rutinarias de operación y mantenimiento a Alibaba Cloud y concéntrese en su aplicación. La edición Basic de RDS funciona bien cuando el tráfico es predecible y un breve tiempo de inactividad resulta aceptable.
Funciones
La edición Basic admite funciones básicas como listas de permitidos de direcciones IP, monitoreo y alertas, así como copia de seguridad y recuperación. No es compatible con a continuación funciones:
Para obtener una lista de las funciones compatibles, consulte SQL Server feature overview.
Limitaciones
La edición Basic de RDS se ejecuta en un solo nodo. Las funciones que dependen de una arquitectura principal-secundaria no están disponibles:
Sin failover automático: Si el nodo de cómputo falla, el sistema migra el motor de base de datos a un nuevo nodo. Su instancia no estará disponible durante la migración; en casos extremos, esto puede durar más de 30 minutos.
Sin conmutación principal/secundaria: Al no existir una instancia secundaria, no hay ninguna instancia en espera a la cual cambiar.
Sin instancias de solo lectura: Las réplicas de lectura requieren una configuración principal-secundaria y no son compatibles.
Sin gestión de registros: Las funciones de gestión de registros disponibles en otras ediciones no son compatibles.
Tiempo de inactividad prolongado durante el mantenimiento: Cuando cambia las especificaciones de la instancia o actualiza el motor de base de datos, el sistema comprueba si el servidor físico actual tiene recursos suficientes. De no ser así, migra sus datos a un nuevo servidor, lo que podría interrumpir la conectividad por más de 30 minutos.
Configurar la log backup frequency en Every 30 Minutes le permite restaurar datos a un punto en el tiempo dentro de los últimos 30 minutos si ocurre una falla en el disco en la nube o un problema similar. Para más detalles, consulte Back up an ApsaraDB RDS for SQL Server instance .
Crear una instancia
Para crear una instancia de la edición Basic de RDS y conectarse a una base de datos SQL Server, consulte Create an ApsaraDB RDS for SQL Server instance.
Actualizar la edición
Puede actualizar una instancia de la edición Basic de RDS a la edición High-availability de RDS en cualquier momento. Consulte Upgrade an ApsaraDB RDS for SQL Server instance from Basic Edition to High-availability Edition.
No se admite la reducción de la edición High-availability de RDS a la edición Basic de RDS. Para lograr un resultado equivalente, cree una nueva instancia de la edición Basic de RDS, migre sus datos desde la instancia existente de la edición High-availability y luego libere la instancia original. Consulte Migrate data between ApsaraDB RDS for SQL Server instances y Liberar o cancelar suscripción de una instancia de RDS .
Preguntas frecuentes
¿Por qué las actualizaciones del motor y los cambios de especificaciones de la instancia tardan tanto en la edición Basic de RDS?
La edición Basic de RDS utiliza una arquitectura independiente con un solo nodo de cómputo. Cuando actualiza el motor de base de datos o cambia las especificaciones de la instancia, el sistema comprueba si el servidor físico actual cumple con los nuevos requisitos de recursos. De no ser así, migra todos los datos a un nuevo servidor físico antes de efectuar la conmutación, lo que podría interrumpir la conectividad por más de 30 minutos.
Se recomienda seleccionar la edición Enterprise de RDS o la edición Cluster de RDS. Estas ediciones se basan en la arquitectura de alta disponibilidad, que permite replicar datos desde la instancia secundaria de RDS sin afectar sus cargas de trabajo y mantener el tiempo de inactividad al mínimo. Consulte RDS High-availability Edition y RDS Cluster Edition para más detalles.
¿Por qué la edición Basic de RDS admite menos funciones que otras ediciones?
Funciones como la conmutación principal/secundaria, las instancias de solo lectura y la gestión de registros requieren una instancia secundaria para operar. Dado que la edición Basic de RDS tiene una arquitectura de nodo único, esas funciones no son posibles por diseño. Para ver una comparación completa de funciones, consulte Features of ApsaraDB RDS for SQL Server.