RDS for SQL Server is a stable, reliable and scalable online database service created by Volcano Engine based on the world-class commercial database product Microsoft SQL Server. SQL Server instances are deployed in a cloud-native manner, providing high-performance read and write capabilities by combining extremely fast SSD cloud disks. RDS for SQL Server is fully compatible with various applications under the Microsoft ecosystem, and provides a complete set of solutions for instance management, backup and recovery, log management, monitoring and alerting, data migration, etc., to help enterprises simplify complex database management and operation and maintenance tasks, so that enterprises have more time and resources to focus on their core business.
RDS for SQL Server supports the creation of instances of Basic, High Availability, and Cluster architecture types.
The RDS for SQL Server provides the infrastructure architecture, also known as the stand-alone architecture, which only provides a single-node deployment method and does not promise SLAs. The advantages, disadvantages, and applicable scenarios of the infrastructure are as follows:
- Advantages: Cost-effective.
- Disadvantages: When the stand-alone version malfunctions, there is no guarantee that the business can be restored in a timely manner.
- Applicable scenarios: The infrastructure is suitable for personal learning, microsites, SME development and testing environments, etc.
High Availability Architecture
RDS for SQL Server provides a primary and secondary high availability architecture type that supports high availability across AZs such as primary and secondary availability zones supported in different availability zones (AZs), promising SLAs. The advantages, disadvantages, and applicable scenarios of a high-availability architecture are as follows:
- Advantages: The high-availability architecture supports the automatic handover of the primary and secondary nodes when the primary node fails, achieving high service availability. The high availability architecture promises SLAs.
- Disadvantages: When the primary node fails, the primary and secondary nodes switching will cause a short service interruption of about 30s to 60s. If there is a replication delay, the primary and secondary switch may take a little longer, and you need to ensure that the client side of the database you are using supports reconnection.
- Applicable scenarios: The high-availability architecture is suitable for the production databases of large and medium-sized enterprises, such as the Internet, Internet of Things, retail e-commerce, logistics, gaming, and other industries.
RDS for SQL Server provides a cluster version architecture, which supports one primary, one spare and multiple read-only on the basis of supporting high availability. You can create multiple read-only instances on demand to achieve read-write separation load balancing and commit to SLAs. The advantages, disadvantages, and applicable scenarios of the clustered architecture are as follows:
- Advantages: Higher availability, reliability, and scalability.
- Disadvantages: When the primary node fails, the primary and secondary nodes switching will cause a short service interruption of about 30s to 60s. If there is a replication delay, the primary and secondary switch may take a little longer, and you need to ensure that the client side of the database you are using supports reconnection.
- Applicable scenarios: The cluster version architecture is suitable for industries such as finance, the Internet, hotels, and online education.
Primary node
The Primary node is the basic node for SQL Server instances to provide services to the outside world, and other components rely on the Primary Node to function. In the high availability architecture, the primary node receives all read and write requests of the service; in the read-write separation architecture, the primary node receives all write requests and partial read requests of the service. The primary node records the data modification log and transmits the log to other nodes to achieve data synchronization between nodes.
Secondary node
Secondary node is an important node in SQL Server instance's high availability architecture to ensure the high availability of instances. The secondary node receives the log transmitted by the primary node and replays it to ensure the consistency of data between the primary and secondary nodes; when the primary node fails, the secondary node can quickly switch the primary node and provide services to the outside world to ensure the stable operation of the business.
Read-only node
A Read-only node is an important node in the read-write separation architecture of RDS for SQL Server instances, responsible for processing read-only requests. The read-only node is mainly used to share the reading pressure of the primary node. When there are a large number of read requests in the database, a primary node may not be able to meet the pressure of a large number of read and write requests at the same time. Read-only nodes can help you reduce the read pressure of the primary node and improve the overall processing power of the system.
RDS for SQL Server offers the following product advantages:
- RDS for SQL Server has Microsoft's authentic license, which can be purchased on demand, quickly created and used, and avoids complicated business agreements.
- RDS for SQL Server adopts Hot Backup Architecture, automatic inspection, and second-level switching of failures to effectively ensure application SLA compliance.
- RDS for SQL Server uses Tinder Object Storage (TOS) to achieve low-cost database backup and support recovery to any point in time.
- RDS for SQL Server supports multi-dimensional monitoring, custom resource definition threshold alarms, and provides online query and download capabilities for a variety of logs.
- RDS for SQL Server supports public and private network access. It implements encrypted transmission and secure access control capabilities through allowlists.