1

I have managed to get the C# and db setup using ListMappings. However, when I try to deploy the split/merge tool to Azure cloud classic the service it states 'The requested VM tier is currently not available in East US for this subscription. Please try another tier or deploy to a different location.' We tried a few other regions with the same result. Do you know if there is a workaround or updated version? Is the split / merge service even still relevant? Has anyone got this service to run on Azure lately?

https://learn.microsoft.com/en-us/azure/azure-sql/database/elastic-scale-overview-split-and-merge

Jeremy
  • 41
  • 6
  • I think "Azure cloud classic" things are really retired. Its not an answer or anything. Just an educated guess. – Jay Sep 24 '20 at 17:46
  • Seems to be older for sure. The issue I am having is the source code is not open source and we are stuck using the .cspkg that Microsoft provides. I really do not want to have to write T-SQL to move tenants between shards if this tool is already written. It is just frustrating it doesn't work. I followed the instructions step by step. – Jeremy Sep 24 '20 at 17:54
  • tough luck is all i can say. perhaps, someone will post an answer. wait it out. – Jay Sep 24 '20 at 18:13
  • 1
    Please refer to https://learn.microsoft.com/en-us/azure/virtual-machines/classic-vm-deprecation – Jim Xu Sep 25 '20 at 01:08
  • 1
    Split-merge is only relevant if you plan to move keys between shard db's. Since the introduction of elastic pools several years ago, it has become better practice to create one shard db for each key, and therefore you never need to move data (just drop the db or move it in/out of elastic pool in order to control scale). – Jared Moore Sep 28 '20 at 17:45
  • Thank you @JaredMoore Your response was very helpful. – Jeremy Sep 29 '20 at 21:29

2 Answers2

3

The answer to the question on whether it is still relevant, in my opinion is ...no. Split\merge is no longer relevant with the maturation of elastic pools. Elastic pools with one data base per tenant seem the sustainable way to implement multi tenancy with legacy code. The initial plan was to add keys to each of our tables to have multiple tenants per database. Elastic pools give us the same flexibility without having to make breaking changes our existing code.

Jeremy
  • 41
  • 6
0

Late post here, but we are implementing ElasticScale for a client to split ~50 clients into a database-per-tenant model. I don't think the SplitMerge tool will be used over the long term, just for the initial data migration from one db to many shards, but it has been handy for that purpose. We are using the ElasticScale SDK to allow a single API to route queries to the appropriate shard(s) based on sharding key. Happy to compare notes with you if you are still working on this.

John Reiner
  • 15
  • 6