DB instance encompasses virtual equipment and installed Microsoft SQL Server, serving as the unit of Microsoft SQL Server provided by RDS for MS-SQL. Direct access to a DB instance is not allowed, but access is enabled only through the port entered when creating the DB instance. DB instances can be identified by user-specified name or automatically assigned 32-bit ID. A DB instance name has the following constraints:
To create a DB instance, user account and password setting is required, considering the following constraints:
RDS for MS-SQL has many availability zones under one system so as to prepare against failure in physical hardware. A failure that occurs within an availability zone does not affect other availability zones, increasing availability of the entire service. DB instances that are dispersed and created in different availability zones can communicate via network, with no charges.
[Caution] You cannot change the availability zone of a DB instance that has already been created.
The following versions are supported.
[Caution] You cannot create a different version when restoring using a backup file since the backup files for each version are incompatible.
Each type of DB instance has different CPU core count and memory volume. To create a DB instance, an appropriate type must be selected depending on the database workload.
|m2||Configures balance between CPU and memory.|
|c2||Has higher performance setting for CPU.|
|r2||Available when memory takes more volume than other resources|
|x1||A type that supports high performance CPUs and memory. Used for services and applications that require high performance.|
You can use the web console to easily change the type of a DB instance that has already been created.
[Caution] When the type of an already created DB instance is changed, the DB instance is terminated, resulting in several minutes of downtime.
DB instance status consists of the following values, and it may change depending on the user's action and current status.
|Available||The DB instance is stable and capable of performing other actions|
|Connection failed||Cannot access the database|
|Force restart||DB instance is being force restarted|
|Not enough storage||DB instance storage does not have enough free space|
|Creating||DB instance is being created|
|Changing||DB instance is being changed|
|Backing up||The backup of DB instance is being made|
|Deleting||DB instance is being deleted|
|Rebooting||DB instance is being rebooted|
|Recovering high availability configuration||Reconfiguring the secondary server and monitoring server of a high availability DB instance|
|Recovering the monitoring server||Reconfiguring the monitoring server of a high availability DB instance|
|Exporting backup||Exporting backup of DB instance to object storage|
|Failing over||Failover is in progress for the DB instance|
|Failed over||The DB instance is successfully failed over and stopped.|
|Migrating||Hypervisor migration is in progress|
|Error||Cannot use the DB instance due to unknown reasons|
DB instances support two storage types: HDD or SSD. Since each storage type provides different performance and pricing, an appropriate storage type must be selected depending on the database workload. A storage type can be created from 20GB up to 2,000 GB. You can use the web console to easily change the size of a storage that has already been created.
[Caution] When the size of an already created storage is changed, the DB instance is terminated, resulting in several minutes of downtime. You cannot change the type of a storage that has already been created.
The time during which a scheduled task is scheduled. A scheduled task can be DB instance modification, or DB instance restart that is registered when a parameter group is changed.
[Caution] The task may not be completed within the set time. If another task is running at the set time, the scheduled task will be retried at the scheduled time the next day.
A high availability DB instance increases availability and data durability, and provides fault-tolerant database. RDS for MS-SQL uses the mirroring function of the Microsoft SQL Server, consisting of a primary server, a secondary server, and an event monitor server, to offer high availability. The primary and secondary servers are created in different availability zones.
A failover automatically takes place when the primary server becomes unavailable due to an unexpected failure. The failed primary server is halted to prevent split brain and the secondary server takes over the role of primary server. Applications do not have to be adjusted for this change, as the A record of the internal and external domains that are used for connection is switched from the primary server to the secondary server. When failover is complete, high availability DB instances will disappear and the rest of DB instances are separated into two groups: the failed DB instances and the DB instances promoted due to the failure. The promoted DB instances inherit all the configurations of existing DB instances except backups. The promoted DB instances do not perform automatic backup immediately after the promotion. This is to prevent any system load due to the failover. The DB instances with failover completed can be restarted by pressing the Restart button.
A high availability DB instance can be failed over manually through restart using failover. When restarting a DB instance using failover, manual failover is performed and the roles of the primary and secondary servers are switched. During failover, both primary and secondary servers will restart their Microsoft SQL Server process and their internal and external domain IPs will be changed. Connection to those servers may fail from several seconds to several minutes until the domain change is completed. Backup is performed automatically when failover is complete.
The high availability auto recovery feature schedules a high availability reconfiguration task that runs one hour after the completion of automatic failover. The created scheduled task can be adjusted to the desired time or deleted in the Scheduled Task tab.