Skip to content
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
Expand Up @@ -49,7 +49,9 @@ Each contained AG has its own `master` and `msdb` system databases, named after
> [!IMPORTANT]
> Contained AGs are a mechanism for keeping execution environment configurations consistent across the replicas of an availability group. They **don't** represent a security boundary. There's no boundary which keeps a connection to a contained AG from accessing databases outside of the AG, for example.

The system databases in a newly created contained AG aren't copies from the instance where the `CREATE AVAILABILITY GROUP` command is run. They are initially empty templates without any data. Immediately after creation, the admin accounts on the instance creating the contained AG are copied into the contained AG `master`. That way, the administrator can log into the contained AG and set up the rest of the configuration. If you create local users or configurations in your instance, they don't automatically appear when you create your contained system databases, and they aren't visible when you connect to the contained AG. You need to manually re-create them in the contained system databases within the context of the contained AG. The exception to this is that all of the logins in the sysadmin role in the parent instance are copied into the new AG specific `master` database.
The system databases in a newly created contained AG aren't copies from the instance where the `CREATE AVAILABILITY GROUP` command is run. They are initially empty templates without any data. Immediately after creation, the admin accounts on the instance creating the contained AG are copied into the contained AG `master`. That way, the administrator can log into the contained AG and set up the rest of the configuration.

If you create local users or configurations in your instance, they don't automatically appear when you create your contained system databases, and they aren't visible when you connect to the contained AG. Once the user database has been joined to a contained AG, it will immediately become inaccessible to these users. You need to manually re-create them in the contained system databases within the context of the contained AG, by connecting directly to the database or by using the listener endpoint. The exception to this is that all of the logins in the sysadmin role in the parent instance are copied into the new AG specific `master` database.

#### Restore a contained system database

Expand Down