DIH should run fine from any node. It sends update requests as any other client, and those are routed to the leader, wherever it is. It could be problematic if node 2 gets overloaded by both doing DIH work, Overseer work and perhaps shard leader work, and an overloaded node gets into all kind of problems with Zookeeper etc.
First thing I’d do, while prearing to replace DIH with something else outside your cluster, is to get up to a recent Solr version. Version 4.10 has a lot of known issues wrt SolrCloud stability. Jan > 14. aug. 2020 kl. 03:55 skrev Issei Nishigata <duo.2...@gmail.com>: > > Thank you for your quick reply. > Can I make sure that the indexing isn't conducted on the node where the DIH > executed but conducted on the Leader node, right? > > As far as I have seen a log, there are errors: the failed establishment of > connection occurred from Node2 on the state of Replica on running DIH to > Node9 where on the state of Replica. > Therefore, for my understanding, I thought there would be errors when the > DIH was implemented at the Node2 and trying to forward a tlog to Node9. > > Unless Node9 receives the tlog, if Node1 as Leader receives the tlog, I do > believe there are no worries because Node9 is synchronised with Node1. > But if Node1 as Leader cannot receive the tlog, Replica might be > synchronised to the Leader soon and that makes me a problematic issue. > I want to try to find out the cause as I will check all log files of all > servers through, but could you give me your comment for my understanding of > the indexing architecture on SolrCloud, please? > > > Thanks, > Issei > > 2020年8月14日(金) 0:33 Jörn Franke <jornfra...@gmail.com>: > >> DIH is deprecated in current Solr versions. The general recommendation is >> to do processing outside the Solr server and use the update handler (the >> normal one, not Cell) to add documents to the index. So you should avoid >> using it as it is not future proof . >> >> If you need more Time to migrate to a non-DIH solution: >> I recommend to look at all log files of all servers to find the real error >> behind the issue. If you trigger in Solr cloud mode DIH from node 2 that >> does not mean it is executed there ! >> >> What could to wrong: >> Other nodes do not have access to files/database or there is a parsing >> error or a script error. >> >>> Am 13.08.2020 um 17:21 schrieb Issei Nishigata <duo.2...@gmail.com>: >>> >>> Hi, All >>> >>> I'm using Solr4.10 with SolrCloud mode. >>> I have 10 Nodes. one of Nodes is Leader Node, the others is Replica.(I >> will >>> call this Node1 to Node10 for convenience) >>> -> 1 Shard, 1 Leader(Node1), 9 Replica(Node2-10) >>> Indexing always uses DIH of Node2. Therefore, DIH may be executed when >>> Node2 is Leader or Replica. >>> Node2 is not forcibly set to Leader when DIH is executed. >>> >>> At one point, when Node2 executed DIH in the Replica state, the following >>> error in Node9 occurred. >>> >>> >> [updateExecutor-1-thread-9737][ERROR][org.apache.solr.common.SolrException] >>> - org.apache.solr.client.solrj.SolrServerException: IOException occured >>> when talking to server at: >> http://samplehost:8983/solr/test_shard1_replica9 >>> >>> I think this is the error while sending data from Node2 to Node9. And >> Node9 >>> couldn't respond for some reason. >>> >>> The error occurs sometimes however it is not reproducible so that the >>> investigation is troublesome. >>> Is there any possible cause for this problem? I am worrying about if it >> is >>> doing Solr anti-pattern. >>> The thing is, when running DIH by Node2 as Replica, the above error >> occurs >>> towards Node1 as Leader, >>> then soon after, all the nodes might be returning to the index of the >>> Node1. >>> Do you think my understanding makes sense? >>> >>> If using DIH on SolrCloud is not recommended, please let me know about >> this. >>> >>> Thanks, >>> Issei >>
