There is no information here at all that would us to say anything meaningful. You might review: http://wiki.apache.org/solr/UsingMailingLists
What do the logs say? Are there any exceptions? What happens on your system that's unusual if anything? In short, what have you tried to do to diagnose the cause and what have you learned? But here's a random guess. You didn't configure your log4j properties and your logs, particularly your console log have grown to huge sizes and occasionally you encounter disk full issues. Or your ZK nodes have the same problem, they accumulate snapshots (see the Zookeeper admin page). Best, Erick On Thu, Oct 6, 2016 at 2:23 AM, Gerald Reinhart <gerald.reinh...@kelkoo.com> wrote: > > Hello everyone, > > Our Solr Cloud works very well for several months without any > significant changes: the traffic to serve is stable, no major release > deployed... > > But randomly, the Solr Cloud leader puts all the replicas in recovery > at the same time for no obvious reason. > > Hence, we can not serve the queries any more and the leader is > overloaded while replicating all the indexes on the replicas at the same > time which eventually implies a downtime of approximately 30 minutes. > > Is there a way to prevent it ? Ideally, a configuration saying a > percentage of replicas to be put in recovery at the same time? > > Thanks, > > Gérald, Elodie and Ludovic > > > -- > [image: Kelkoo] > > *Gérald Reinhart *Software Engineer > > *E* <gerald.reinh...@kelkoo.com> <gerald.reinh...@kelkoo.com> > gerald.reinh...@kelkoo.com *Y!Messenger* gerald.reinhart > *T* +33 (0)4 56 09 07 41 > *A* Parc Sud Galaxie - Le Calypso, 6 rue des Méridiens, 38130 Echirolles > > > > ------------------------------ > Kelkoo SAS > Société par Actions Simplifiée > Au capital de € 4.168.964,30 > Siège social : 158 Ter Rue du Temple 75003 Paris > 425 093 069 RCS Paris > > Ce message et les pièces jointes sont confidentiels et établis à > l'attention exclusive de leurs destinataires. Si vous n'êtes pas le > destinataire de ce message, merci de le détruire et d'en avertir > l'expéditeur. >
