This content has been marked as final. Show 2 replies
No, this is not currently supported. Secondaries must be created on the master as usual and will be replicated to all nodes. However, if secondaries are read frequently on a particular node, they are more likely to stay in cache on that node, or at least more so than on other nodes. So it still may be beneficial to service read requests for secondaries on a subset of nodes. This is a special case of the more general approach where read requests are balanced among nodes according to some form of data partitioning.
The ability to store secondary indexes only on particular nodes would require several new features and is not currently planned:
- ability to have non-replicated databases in a replicated environment
- triggers on the replica so that secondaries can be maintained
- automatic re-creation of indexes when a node is restored from scratch
Thank you, Mark. This is helpful information. My hope was that by keeping the master node schema (as well as all but one of the replica schemas) limited to just the PK index, that this would retain high performance writes at the master node and minimize disk space requirements on all but the to-be-designated 'search' node. (I am using the DPL API, BTW). I would be adding up to 3 secondary indices for quick searching. I guess I would need to run some tests to see the incremental effects/requirement fors:
-additional disk space is required for the extra indices at each node
-extra memory requirements per the DbCacheSize tool
-added inter-node communication overhead and how much, if any, extra permissible lag and consistency timeout should be extended.
-impact on gross throughput of writes at the master node.
Maybe I'm better off using DbBackup to copy to a unique instance, separate of the replica group, add the extra indices there to make this the designated 'search' node. It will naturally lag behind the 'live' data of the replica group but that may be acceptable.