Discussions
Categories
- 382.3K All Categories
- 2.1K Data
- 210 Big Data Appliance
- 1.9K Data Science
- 448K Databases
- 221K General Database Discussions
- 3.7K Java and JavaScript in the Database
- 25 Multilingual Engine
- 520 MySQL Community Space
- 467 NoSQL Database
- 7.8K Oracle Database Express Edition (XE)
- 2.9K ORDS, SODA & JSON in the Database
- 492 SQLcl
- 3.9K SQL Developer Data Modeler
- 186.2K SQL & PL/SQL
- 21K SQL Developer
- 293.3K Development
- 7 Developer Projects
- 128 Programming Languages
- 290.1K Development Tools
- 95 DevOps
- 3K QA/Testing
- 645.5K Java
- 24 Java Learning Subscription
- 36.9K Database Connectivity
- 150 Java Community Process
- 104 Java 25
- 22.1K Java APIs
- 137.9K Java Development Tools
- 165.3K Java EE (Java Enterprise Edition)
- 16 Java Essentials
- 144 Java 8 Questions
- 85.9K Java Programming
- 79 Java Puzzle Ball
- 65.1K New To Java
- 1.7K Training / Learning / Certification
- 13.8K Java HotSpot Virtual Machine
- 94.2K Java SE
- 13.8K Java Security
- 198 Java User Groups
- 24 JavaScript - Nashorn
- Programs
- 270 LiveLabs
- 36 Workshops
- 10.2K Software
- 6.7K Berkeley DB Family
- 3.5K JHeadstart
- 5.8K Other Languages
- 2.3K Chinese
- 166 Deutsche Oracle Community
- 1.2K Español
- 1.9K Japanese
- 230 Portuguese
Can a replica node have secondary indexes the master does not?
user6501266
Member Posts: 5
In a JE replication group, is it possible to instantiate a replica (non-master) node that includes additional secondary indices that the master and the other replicas do not have? I would like to have this replica node optimized for performing fast searches on the additional indexes. Previously, all my nodes have had the exact same schema with only a single, primary index. Certainly I could add the secondary indexes on all the nodes, including the master, but the other nodes won't benefit from the add'l indexes as no such searches are expected to be performed on those nodes.
Tagged:
Answers
-
Hi,
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
--mark -
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.
-Ted
This discussion has been closed.