No replies
1485 Posts

Pinned topic Failure recovery for Map with write-behind configuration

‏2013-02-06T23:45:05Z |

In section "Replication and loaders" on page 106-107 of the v8.6 product overview document, it states that when the primary shard fails before or after committing to database, a protocol (on page 107) ensures that the database is at the same level as the new primary (synchronized replica takes over as primary) state.

The document is here,

However, from what I've read from these two pages, it seems that this consistency among primary, replica shards , and the database only works for the write-through loader configuration.

My questions are, in the write-bebind mode, when WXS transaction has successfully committed, does the consistency still hold on primary shard failure? The new committed data that has yet to be updated to the database is stored in a queue map in the primary shard. Does replica shards (synchronized replica) also have a copy of the same queue map as primary, so that one of the replicas can take over as primary that kick off the loader instance on the new primary shard and update the data from the queue map to the database?