An Azure relational database service.
Not exactly. When you use a Bicep script to manage a SQL database with createMode set to Secondary and sourceDatabaseId set to the primary database, the behavior during deployment depends on the specific changes being made:
Initial Deployment:
The script will create a secondary replica of the primary database, which will be continuously synchronized with the primary database.
Subsequent Deployments:
If there are no changes to createMode or sourceDatabaseId, the secondary database should continue to synchronize with the primary database without being reinitialized.
If createMode or sourceDatabaseId are changed, it may trigger a reinitialization of the secondary database from the primary database. This reinitialization can be seen as "seeding" the database again.
The 'what if' analysis tool can show you the changes that will be applied during the deployment. If it indicates that createMode and sourceDatabaseId are being added or changed, it suggests that these properties are being dynamically managed and might trigger a reinitialization.
To avoid unnecessary re-seeding, make sure that your Bicep template consistently defines these properties.
Below is the example of how you might define them:
resource sqlDatabase 'Microsoft.Sql/servers/databases@2024-05-01-preview' = {
name: 'your-database-name'
properties: {
createMode: 'Secondary'
sourceDatabaseId: 'your-source-database-id'
// other properties
}
}
By explicitly defining createMode and sourceDatabaseId in your Bicep template, you can help ensure that the deployment behavior remains consistent and avoid unintended reinitializations.
I hope this information helps. Please do let us know if you have any further queries.