So I was moving my NSB setup off of SQL server and onto azure service bus and figured I might as well use azure storage for persistence as well. I'm unclear on how to set this up because I'm also using outbox and I can't use azure storage with it. I'm using the web.config for connections strings, and it sort of only lets me set NServiceBus/Persistence once, so ... I'm a bit lost
Unfortunately, due to various reasons the outbox is only supported on SQL-Server and RavenDb. Read more about it here : https://docs.particular.net/nservicebus/outbox/
At the bottom of the document there's a note that only those two persisters support the outbox feature.
Add to what Dennis said - you cannot use Storage Persistence with the Outbox feature. Outbox feature requires business data and outgoing transaction to participate in the same transaction. This is only possible with Azure SQL server. With Azure Storage persistence this is not an option. Storage supports table batched operations, but not transactions.
Related
Im trying to figure out how exactly outbox is suppose to work with NServicebus but I'm not quite sure I get it. Here is the current scenario that we have:
Service1
Service2
Service3
ServiceN
Each of the services has its own database where it holds business data and servicebus shared database used for queue/message broker.
This means that each of these services is using the same connection string for servicebus and has different connection string for business database.
The problem we are facing is that saving into business database and publishing is technically saving into 2 databases, so this will create distributed transaction if wrapped into transaction.
Now, Im considering implementing outbox pattern to solve this problem, but NServiceBus documentation doesnt really give us an idea regarding this question:
Where should Outbox table be stored? Is it suppose to be stored in a same database as bussiness data? Where will the subsciption data be stored in this case for given service? Is it possible to configure NServicebus to create outbox table into bussiness database while the rest of the tables are created in service bus database?
By enabling outbox NServiceBus indeed creates new table for holding messages servicename_Outbox table, but should it be stored into Servicebus database or business data database? If its stored in servicebus database then, technically to save data into it it still needs distributed transaction?
How does servicebus know which table to pool for Outbox pattern and to dispatch messages? Can this be explicitly configured?
Where should Outbox table be stored? Is it suppose to be stored in a same database as bussiness data?
Yes
Where will the subsciption data be stored in this case for given service?
If you use message driven pubsub instead of native pubsub then yes.
Is it possible to configure NServicebus to create outbox table into bussiness database while the rest of the tables are created in service bus database?
Yes, that is expected.
but should it be stored into Servicebus database or business data database? If its stored in servicebus database then, technically to save data into it it still needs distributed transaction?
Outbox data is stored in the business database and share the same storage connection/transaction so does not require a distributed transaction.
How does servicebus know which table to pool for Outbox pattern and to dispatch messages?
Each endpoint has its own entity.
Can this be explicitly configured?
Please check the outbox configuration for the persister that you are using to see if the table name van be configured:
https://docs.particular.net/persistence/
I would like to know what is the difference between Active Geo Replication and Auto Failover groups in Azure SQL DB ? I read that in Auto Failover groups, the secondary database is always created on a secondary region, but active geo-replication can happen between same region also. So when one should use compared to the other?
According to MSFT documentation - the Auto-failover groups "is a declarative abstraction on top of the existing active geo-replication feature, designed to simplify deployment and management of geo-replicated databases at scale". BCDR is the biggest use case - manual or automatic failover of SQL data to another region.
The auto-failover group feature imposes some limitations while adding convenience -
A listener concept enables your apps to take advantage of the same endpoint to your SQL, while with geo-replication your app is responsible for connection strings manipulation to target required SQL instance
On another hand, geo-replication supports multiple RO targets including in the same region, while failover group supports only two SQL instances in different regions, in which one is RW and another is RO
As validly pointed in another answer, SQL managed instances only support failover groups via vNet peering
There is little difference between Active Geo Replication and Auto Failover groups.
Active geo-replication is not supported by Azure SQL Managed Instance but Auto Failover groups is supported.
Active geo-replication replicates changes by streaming database transaction log. It is unrelated to transactional replication, which replicates changes by executing DML (INSERT, UPDATE, DELETE) commands. It seems that Active geo-replication is more lightweight and efficient.
Active-geo-replication document
Auto-failover-group document
Good morning,
I am using an asp.net framework with an azure client database.
I am now creating another server on Azure to host databases. On this server, for each customer registering on the website (for which 1 entry is created in my first database), I need to create a database with 8 tables - identical for each customer.
What would be the best thing to map the ASP.NET ID to a new database? Which framework would you recommend?
Thanks
Rather than running a VM where you're going to have to manage a SQL Server installation and write a bunch of code to handle a database per tenant scenario, I highly, highly, highly recommend taking a look at Azure SQL's multi-tenant sharding support. All of this code is already written for you. And it's not that you're paying for one DB per client - check out elastic pooling.
You can read the docs here.
Also note, this option will scale very well.
I have done this three different ways: a database per client where I wrote my own code to manage sharding, a single database with a separate schema per client (a huge pain in the rear), and using Azure SQL sharding support. It's not just the issue of correctly separating client data. You also need to think about querying for reporting across all client databases, and managing schema changes. Under the first two options, if you change a schema, you get to modify N client databases. Azure SQL's sharding tools will manage this for you.
The use case is Distributed deployment of Web Application on Azure using PaaS. I read the Azure documentation on SQL Azure database geo-replication, and it seems none of the services tiers best fit this need. The other option is SQL Sync, which is in preview and cannot be used in production.It seems Microsoft Azure does not have any way for a redundant database centric application using PaaS model.
Please help how to resolve the issue or any alternate solution.
Akanksha
Both SQL Data Sync and Geo-replication are for database redundant using. But we need to know you detailed scenarios, so that we can say which one is more fit. Basically Geo-replication is DB level data synchronization used for DR. SQL Data Sync is Table level data synchronization used for reference data replication for both Azure DB and On-prem DB.
I read in a few places that SQL Azure data is automatically replicated and the Azure platform provides redundant copies of the data, Therefore SQL Server high availability features such as database mirroring and failover cluster aren't needed.
Has anyone got a chance to investigate deeper into this? Are all those availability enhancements really not needed in Azure? Thanks!
To clarify, I'm talking about SQL as a service and not a VM hosted SQL.
The SQL Database service (database-as-a-service) is a multi-tenant database service, and your databases are triple-replicated within the data center, providing durable storage. The service itself, being large-scale, provides high availability (since there are many VMs running the service itself, along with replicated data). Nothing is needed in terms of mirroring or failover clusters. Having said that: If, say, your particular database became unavailable for a period of time, you'll need to consider how you'll handle that situation (perhaps sync'ing to another SQL Database, maybe even in another data center).
If you go with SQL Database (DBaaS), you'll still need to work out your backup strategy, and possibly syncing with another DC (or on-premises database server) for DR purposes.
More info on SQL Database fault tolerance is here.
Your desired detail is probably contained in this MSDN article of Business Continuity and Azure SQL Database (see: http://msdn.microsoft.com/en-us/library/windowsazure/hh852669.aspx). At the most basic level Azure SQL Database will keep three replicas of your database - one primary and two secondary.
While this helps with BCP / DR scenarios you may also wish to investigate ways to backup your database so you have point-in-time restore capabilities. More information on backup / restore can be found here: http://msdn.microsoft.com/en-us/library/windowsazure/jj650016.aspx