Auditing for Named replicas and Geo replicas of Hyperscale Azure SQL Database

[Guest Sravani Saluru]

In this blog, we will explain how auditing works for some of the latest features for Hyperscale Azure SQL Database I.e. Hyperscale Named replicas and Geo replication & auto failover groups.

 

 

 

Auditing for Named Replicas:

 

 

 

We added auditing support for Hyperscale’s Named replicas. When you create a named replica for a database, the database-level audit configuration of the primary database is copied to the named replica and the configured actions will be audited. Server Level Auditing Policy for the Named Replica is picked up from the server on which the named replica is placed.

 

 

 

Auditing for Hyperscale Geo Replicas

 

 

 

We added auditing support for Hyperscale’s Geo Replicas. Server Level and Database Level Auditing works seamlessly across the entire lifecycle of Geo Replicas and their corresponding primaries at any point of time. When a new Geo Replica is created, it takes the database level auditing policy of its primary, and Server Level Auditing policy is picked up from the server on which the Geo Replica is placed.

 

 

 

Auditing for Hyperscale Databases created using Copy / Restore

 

 

 

Azure portal provides an option to create a copy of your database or perform a Point-In-Time-Restore (PITR) for the database on the same server or different server. For Hyperscale databases, the resulting database takes the database level auditing policy of the original database, and Server Level Auditing policy is picked up from the server on which the resulting database is placed.

 

 

 

To learn more about auditing please refer Auditing Overview

 

Continue reading...