I have a Premium P2 SQL Azure Database for my Production App, and for security reasons I've created DB Specific Schemas/Views/Roles and a specific DB User account for reading the Data from SSRS Queries.
Lets just call the server PRIMARY
and my database MyApp
The setup script for this is below.
-- On Primary Master
CREATE LOGIN ssrsuser WITH password='******'
-- On Primary MyApp
CREATE USER ssrsuser FOR LOGIN ssrsuser
CREATE ROLE [ssrsreader] AUTHORIZATION [db_owner]
GRANT SELECT ON SCHEMA :: [App] TO [ssrsreader]
GRANT SELECT ON SCHEMA :: [Reports] TO [ssrsreader]
EXEC sp_addrolemember 'ssrsreader', 'ssrsuser'
So our users were putting a LOT of load on the Prod DB and we decided it was time to move the reporting functions off to a secondary sync'd slave database.
Since we're using the SQL Azure Premium Tier, we can enable Active Geo-Replication with a read-only secondary copy. In fact MS even say that it's suitable for read-only workloads such as reporting.
So I've setup the SECONDARY
server, enabled the seeding, it's now complete and I can access the readonly copy using the SECONDARY
admin user and password.
But the SECONDARY
server doesn't have a login for ssrsuser
and I while I can create one in SECONDARY.master
, I can't DROP RECREATE
the user since the SECONDARY.MyApp
database is in readonly mode.
Is there any otherway to get around this. I really don't want to have to put the SECONDARY
server admin user & password into SSRS connection strings.
Up to four geo-secondaries can be created for a primary.
Replication can be configured by using SQL Server Management Studio or by executing Transact-SQL statements on the publisher. You cannot configure replication by using the Azure portal. Replication can only use SQL Server authentication logins to connect to Azure SQL Database. Replicated tables must have a primary key.
In the Azure portal, browse to the primary database in the geo-replication partnership. Scroll to Data management, and then select Replicas. In the Geo replicas list, select the database you want to become the new primary, select the ellipsis, and then select Forced failover. Select Yes to begin the failover.
There is no need to regenerate SID for ssruser in the user database. It is already there as a result of replication. All you need to do is associate that SID with a LOGIN in the master in the secondary server. This article provides the details. https://azure.microsoft.com/en-us/documentation/articles/sql-database-geo-replication-security-config/
I hope this helps.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With