[
https://issues.apache.org/jira/browse/SOLR-10108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15863953#comment-15863953
]
Erick Erickson commented on SOLR-10108:
---------------------------------------
Jan:
Thanks for looking. I'm trying to go the other way (which I should have
specified, just tried on 6x since I have it handy):
bin/solr zk cp -r zk:/ ~/eoezk -z localhost:2181
Fails with: ERROR: Invalid path string "//configs" caused by empty node name
specified [[email protected]]
where
bin/solr zk cp -r zk:/whatever ~/eoezk -z localhost:2181
works.
The context here was a client who'd accidentally removed the zoo_data directory
on all ZKs but still had them running. We hit on the bright idea "hey, we can
just dump all of the ZK data since the data is still available until we restart
the ZK nodes" but ran into this when trying to copy stuff down.
So I worked out the issues with the path and got the two-way copy to work, but
also noticed another issue. Since ZK nodes can have data whether leaf nodes or
not, the current process is lossy since non-leaf nodes don't get their data
restored.
This makes it impossible to backup the collection node and restore it since the
collection can have a configset name as data. My take is that copying back and
forth _should_ restore intermediate node's data, do you (and others) concur?
My first-attempt PoC is to create a _very special file name_ something like
node_zookeeper_solr.data to put any information associated with non-leaf nodes
when the data is not empty as a PoC. That feels like a hack though as there's
the possibility of collisions. Hmmm, maybe {generated_guid}.znode.solr.data?
Still possibly a collision if someone, somehow managed to have a znode with a
GUID followed by .znode.solr.data I suppose, but that's seems unlikely enough
that I'm not willing to worry about it. How about
"erick.erickson.was.here.data"? Maybe not.
WDYT
> bin/solr script recursive copy broken
> -------------------------------------
>
> Key: SOLR-10108
> URL: https://issues.apache.org/jira/browse/SOLR-10108
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Erick Erickson
> Assignee: Erick Erickson
>
> cp /r zk:/ fails with "cannot create //whatever".
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
