[ https://issues.apache.org/jira/browse/SOLR-11003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16073575#comment-16073575 ]
Amrit Sarkar edited comment on SOLR-11003 at 7/4/17 12:27 PM: -------------------------------------------------------------- Backward-compat:: tlogs entries index are definite for each operation: identifier(0) and version(1) common to all. *DELETE:* identifier: delete update version payload if you see UpdateLog: doReplay: 1801 {code} case UpdateLog.DELETE: { recoveryInfo.deletes++; byte[] idBytes = (byte[]) entry.get(2); DeleteUpdateCommand cmd = new DeleteUpdateCommand(req); cmd.setIndexedId(new BytesRef(idBytes)); cmd.setVersion(version); cmd.setFlags(UpdateCommand.REPLAY | UpdateCommand.IGNORE_AUTOCOMMIT); if (debug) log.debug("delete " + cmd); proc.processDelete(cmd); break; } {code} hardcoded, the position of payload(2) is hardcoded. See CdcrReplicator, same. So we can put anything on next index(3). *DELETE_BY_QUERY:* Ditto same!! *ADD:* indentifier: add or inplace version payload *IN_PLACE_ADD:* indentifier: add or inplace version previous pointer previous version payload UpdateLog:: 1916, since our current code handles both adds in one manner, it assumes the last index of the entries is our payload: {code} public static AddUpdateCommand convertTlogEntryToAddUpdateCommand(SolrQueryRequest req, List entry, int operation, long version) { assert operation == UpdateLog.ADD || operation == UpdateLog.UPDATE_INPLACE; SolrInputDocument sdoc = (SolrInputDocument) entry.get(entry.size()-1); AddUpdateCommand cmd = new AddUpdateCommand(req); cmd.solrDoc = sdoc; cmd.setVersion(version); if (operation == UPDATE_INPLACE) { long prevVersion = (Long) entry.get(UpdateLog.PREV_VERSION_IDX); cmd.prevVersion = prevVersion; } return cmd; } {code} So our window of adding something is the index just before the last. entry.size - 2. Please see CdcrReplicator for the same. was (Author: sarkaramr...@gmail.com): Backward-compat:: tlogs entries index are definite for each operation: identifier(0) and version(1) common to all. *DELETE:* identifier: delete update version payload if you see UpdateLog: doReplay: 1801 {code} case UpdateLog.DELETE: { recoveryInfo.deletes++; byte[] idBytes = (byte[]) entry.get(2); DeleteUpdateCommand cmd = new DeleteUpdateCommand(req); cmd.setIndexedId(new BytesRef(idBytes)); cmd.setVersion(version); cmd.setFlags(UpdateCommand.REPLAY | UpdateCommand.IGNORE_AUTOCOMMIT); if (debug) log.debug("delete " + cmd); proc.processDelete(cmd); break; } {code} hardcoded, the position of payload(2) is hardcoded. See CdcrReplicator, same. So we can put anything on next index(3). *DELETE_BY_QUERY:* Ditto same!! *ADD:* indentifier: add or inplace version payload *IN_PLACE_ADD:* indentifier: add or inplace version previous pointer previous version payload UpdateLog:: 1916, since our current code handles both adds in one manner, it assumes the last index of the entries is our payload: {code} public static AddUpdateCommand convertTlogEntryToAddUpdateCommand(SolrQueryRequest req, List entry, int operation, long version) { assert operation == UpdateLog.ADD || operation == UpdateLog.UPDATE_INPLACE; SolrInputDocument sdoc = (SolrInputDocument) entry.get(entry.size()-1); AddUpdateCommand cmd = new AddUpdateCommand(req); cmd.solrDoc = sdoc; cmd.setVersion(version); if (operation == UPDATE_INPLACE) { long prevVersion = (Long) entry.get(UpdateLog.PREV_VERSION_IDX); cmd.prevVersion = prevVersion; } return cmd; } {code} So our window of adding something is the index just before the last. entry.size - 2. Please see CdcrReplictor for the same. > Enabling bi-directional CDCR active-active clusters > --------------------------------------------------- > > Key: SOLR-11003 > URL: https://issues.apache.org/jira/browse/SOLR-11003 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: CDCR > Reporter: Amrit Sarkar > > The latest version of Solr CDCR across collections / clusters is in > active-passive format, where we can index into source collection and the > updates gets forwarded to the passive one and vice-versa is not supported. > https://lucene.apache.org/solr/guide/6_6/cross-data-center-replication-cdcr.html > https://issues.apache.org/jira/browse/SOLR-6273 > We are try to get a design ready to index in both collections and the > updates gets reflected across the collections in real-time. > ClusterACollectionA => ClusterBCollectionB | ClusterBCollectionB => > ClusterACollectionA. > The best use-case would be to we keep indexing in ClusterACollectionA which > forwarded the updates to ClusterBCollectionB. If ClusterACollectionA gets > down, we point the indexer and searcher application to ClusterBCollectionB. > Once ClusterACollectionA is up, depending updates count, they will be > bootstrapped or forwarded to ClusterACollectionA from ClusterBCollectionB. -- This message was sent by Atlassian JIRA (v6.4.14#64029) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org