I can use the shard manager to easily create shards. How can I easily set up geo-replication for each shard?

Also how can I get the replica's to participate in a read query?

You configure geo-replication for each shard and/or the shard map manager in the same way you would as any Azure SQL Database. Below is a code example to update the server name/database name (shard location) for both the global shard map manager (GSM) and each local shard map (LSM) in the event that all the shards in a shard set are failed over due to a major outage. In case of a geo-failover, ideally this logic would be automated within the failover workflow. Automating such actions enables a frictionless manageability for geo-enabled databases and avoids manual human actions. It also helps with certain 'oops' recovery scenarios where reconstruction of shard maps from database backups or database copies is necessary.

Here is more general information about the Recovery Manager APIs:

The RecoveryManager class provides ADO.Net applications the ability to easily facilitate detecting and addressing any inconsistencies in the ShardMap between the global shard map (GSM) and local shard map (LSM) of each shard in a shard set. An inconsistency between the GSM and LSM can simply be caused by the deletion of a shard whose range is believed to no longer be in use or the rename of a shard. Deleting a shard can cause an orphaned shard mapping and a rename of a database can similarly can an orphaned shard mapping where the shard location for the shard simply needs updating to ensure data-dependent routing continues to work as expected. More complex scenarios which can require updating the server name, database name and/or shard mapping details for any and all shards in a shard map due to a geo-failover event or a restore of a shard or the ShardMapManager database to an earlier point-in time. In case of a geo-failover, ideally this logic would be automated within the failover workflow. Automating such actions enables a frictionless manageability for geo-enabled databases and avoids manual human actions. It also helps with certain 'oops' recovery scenarios where reconstruction of shard maps from database backups or database copies is necessary.

In case of a geo-failover, ideally this logic would be automated within the failover workflow. Automating such actions enables a frictionless manageability for geo-enabled databases and avoids manual human actions. It also helps with certain 'oops' recovery scenarios where reconstruction of shard maps from database backups or database copies is necessary.

This is an example of code that uses the RecoveryManager to perform the removal of shards from the Shard Map which reflects shard locations prior to the failover event, attaching of shards to the Shard Map reflecting the new shard locations (specifically with a new server name but the same database name), retrieval of the recovery tokens from detecting mapping differences between the GSM and the LSM for each shard and finally resolving the inconsistencies by trusting the mapping from the LSM of each shard.

var shards = smm.GetShards();

foreach (shard s in shards)

{

       if (s.Location.Server == Configuration.PrimaryServer)

       {

              ShardLocation slNew = new ShardLocation(Configuration.SecondaryServer, s.Location.Database);

              rm.DetachShard(s.Location);

              rm.AttachShard(slNew);

              var gs = rm.DetectMappingDifferences(slNew);

              foreach (RecoveryToken g in gs)

                     {

                     rm.ResolveMappingDifferences(g, MappingDifferenceResolution.KeepShardMapping);

                     }

              }

}

Resolving Mapping Differences

The method RecoveryManager.ResolveMappingDifferences(RecoveryToken, MappingDifferenceResolution) selects one of the shard maps (either local or global) as the source of truth and brings mappings on both shard maps, specifically, GSM and LSM, in sync.

• The RecoveryToken parameter returned from the method RecoveryManager.DetectMappingDifferences enumerates the differences in the mappings between the GSM and the LSM for the specific shard.