[
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
