Riparazioni simultanee causano il blocco della riparazione

Sto eseguendo Cassandra 3.7 in un cluster a 24 nodi con 3 data center e 256 vnode per nodo e ogni nodo utilizza un processo cron per eseguire "nodetool repair -pr" una volta al giorno durante un ora differente del giorno dagli altri nodi.Riparazioni simultanee causano il blocco della riparazione

A volte la riparazione richiede più di un'ora per completare e le riparazioni si sovrappongono. Quando ciò accade, la riparazione inizia a ricevere eccezioni e può bloccarsi in uno stato negativo. Ciò porta a un errore a cascata in cui ogni ora un altro nodo proverà ad avviare una riparazione e si bloccherà anche.

Recuperare da questo è difficile. L'unico modo che ho trovato è quello di riavviare non solo i nodi con una riparazione bloccata, ma tutti i nodi nel cluster.

L'unica idea che ho per affrontare questo è di costruire un tipo di servizio che controlla se qualsiasi altro nodo è in riparazione prima di iniziare una riparazione, magari pubblicando in una tabella Cassandra quando è in corso una riparazione.

Non sono sicuro di come sarà possibile riparare tutti i nodi se il cluster si ingrandisce poiché presto non ci saranno abbastanza ore al giorno per eseguire la riparazione su tutti i nodi uno per uno.

Quindi la mia domanda principale è, sto eseguendo la riparazione in modo errato e qual è il modo consigliato di riparare regolarmente tutti i nodi di un grande cluster?

C'è un modo per riparare più di un nodo alla volta? La documentazione suggerisce che ci sia, ma non è chiaro come farlo. È normale che la riparazione si blocchi e si bruci quando viene eseguita su più di un nodo alla volta? C'è un modo più semplice per uccidere le riparazioni bloccate rispetto al riavvio di tutti i nodi?

Alcune cose che ho provato:

Running "nodetool riparazione" senza -pr, ma questo pende anche se eseguito su più nodi in una sola volta.
In esecuzione "nodetool repair -dcpar" - questo sembra riparare gli intervalli di token di proprietà del nodo su cui viene eseguito in tutti i data center, ma si blocca anche se eseguito su più nodi contemporaneamente.

My keyspace conserva una sola replica per data center, quindi non credo di poter utilizzare l'opzione -local.

Alcune delle eccezioni che vedo quando riparazione si blocca sono:

ERROR [ValidationExecutor:4] 2016-07-07 12:00:31,938 CassandraDaemon.java (line 227) Exception in thread Thread[ValidationExecutor:4,1,main] 
java.lang.NullPointerException: null 
     at org.apache.cassandra.service.ActiveRepairService$ParentRepairSession.getActiveSSTables(ActiveRepairService.java:495) ~[main/:na] 
     at org.apache.cassandra.service.ActiveRepairService$ParentRepairSession.access$300(ActiveRepairService.java:451) ~[main/:na] 
     at org.apache.cassandra.service.ActiveRepairService.currentlyRepairing(ActiveRepairService.java:338) ~[main/:na] 
     at org.apache.cassandra.db.compaction.CompactionManager.getSSTablesToValidate(CompactionManager.java:1320) ~[main/:na] 

ERROR [Repair#6:1] 2016-07-07 12:00:35,221 CassandraDaemon.java (line 227) Exception in thread Thread[Repair#6:1,5,RMI Runtime] 
com.google.common.util.concurrent.UncheckedExecutionException: org.apache.cassandra.exceptions.RepairException: [repair #67bd9b10-... 
]]] Validation failed in /198.18.87.51 
     at com.google.common.util.concurrent.Futures.wrapAndThrowUnchecked(Futures.java:1525) ~[guava-18.0.jar:na] 
     at com.google.common.util.concurrent.Futures.getUnchecked(Futures.java:1511) ~[guava-18.0.jar:na] 
     at org.apache.cassandra.repair.RepairJob.run(RepairJob.java:160) ~[main/:na] 
     at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) ~[na:1.8.0_71] 
     at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) ~[na:1.8.0_71] 
     at java.lang.Thread.run(Thread.java:745) ~[na:1.8.0_71] 
Caused by: org.apache.cassandra.exceptions.RepairException: [repair #67bd9b10... 
]]] Validation failed in /198.18.87.51 
     at org.apache.cassandra.repair.ValidationTask.treesReceived(ValidationTask.java:68) ~[main/:na] 
     at org.apache.cassandra.repair.RepairSession.validationComplete(RepairSession.java:183) ~[main/:na] 
     at org.apache.cassandra.service.ActiveRepairService.handleMessage(ActiveRepairService.java:439) ~[main/:na] 
     at org.apache.cassandra.repair.RepairMessageVerbHandler.doVerb(RepairMessageVerbHandler.java:169) ~[main/:na] 

ERROR [ValidationExecutor:3] 2016-07-07 12:42:01,298 CassandraDaemon.java (line 227) Exception in thread Thread[ValidationExecutor:3,1,main] 
java.lang.RuntimeException: Cannot start multiple repair sessions over the same sstables 
     at org.apache.cassandra.db.compaction.CompactionManager.getSSTablesToValidate(CompactionManager.java:1325) ~[main/:na] 
     at org.apache.cassandra.db.compaction.CompactionManager.doValidationCompaction(CompactionManager.java:1215) ~[main/:na] 
     at org.apache.cassandra.db.compaction.CompactionManager.access$700(CompactionManager.java:81) ~[main/:na] 
     at org.apache.cassandra.db.compaction.CompactionManager$11.call(CompactionManager.java:844) ~[main/:na]

fonte

2016-07-07 Jim Meyer

Posso chiederti perché "riparazione" sono continuamente necessari? Mi sembra superficialmente che si tratti di patching su alcuni problemi di fondo. –

Poiché la nostra rete spesso richiede il riavvio delle macchine, questo fa sì che i nodi di Cassandra perdano dati e diventino incoerenti. A volte abbiamo anche interruzioni di rete ai nodi. –

Ah, capisco. I riavvii sono sempre un bugaboo. –

A seconda della dimensione dei dati e in che modo lo schema diffonde i dati di spazio delle chiavi e tavolo, e il numero di gettoni per nodo, è possibile eseguire più riparazioni rivolte a queste dimensioni. Per gli spazi chiavi e le tabelle di grandi dimensioni, è anche possibile utilizzare le opzioni del token di inizio/fine durante la riparazione. È possibile trovare i token per nodo eseguendo il comando nodetool ring. Un altro modo per mantenere le riparazioni di dimensioni minori è eseguire riparazioni incrementali e parallele, controllare le opzioni nella riparazione di nodetool.

fonte

2016-07-08 06:55:24 viorel

Non capisco cosa stai suggerendo come soluzione. Stai dicendo che dovrei creare un controller di riparazione centrale che analizzi in qualche modo l'uscita dell'anello nodetool e che esegua alcune riparazioni in parallelo? Come si fa a farlo? Il valore predefinito in 3.7 è per le riparazioni incrementali e parallele, quindi sto già utilizzando queste impostazioni. Ciò non impedisce la riparazione da sospensione se la riparazione viene eseguita su più di un nodo alla volta. –

Penso che @viorel suggerisse la riparazione di sottofondo. Here's the datastax doc per cassandra 3.0 dove lo descrivono come riparazione rapida. E here's an explanation del motivo per cui potrebbe essere più veloce. Fondamentalmente, invece di calcolare l'albero di Merkle per un intero intervallo, suddividere l'intervallo di partizione in sotto-intervalli e quindi confrontarli. Here's an explanation del motivo per cui funziona.

fonte

2016-07-14 19:00:48 LHWizard

La velocità della riparazione non mi interessa davvero, voglio solo evitare di riparare le eccezioni e di impiccare. Se potessi sistemare Cassandra in modo che la riparazione si chiudesse con grazia se rilevasse un'altra riparazione era già in corso, allora almeno non avrei bisogno di un operatore per riavviare manualmente i nodi per ripulire le riparazioni bloccate. –

Stavo pensando di evitare le riparazioni sovrapposte facendole completare più velocemente. Suppongo che alla fine il carico sarà abbastanza grande da rendere questa solo una soluzione temporanea. – LHWizard

Sì, è stata la mia esperienza. Per prima cosa mi sono imbattuto in questo problema quando uno dei nodi stava pagando molto la memoria (a causa di un'applicazione non Cassandra in esecuzione sulla stessa macchina), e questo sembrava rallentare considerevolmente la riparazione, causandone la sovrapposizione con un altro nodo. Quindi una sorta di meccanismo di coordinamento o pianificatore centrale sembra essere necessario poiché i nodi non si proteggono da riparazioni simultanee. –

Si può provare cassandra-Reaper: software per eseguire le riparazioni automatizzati di Cassandra https://github.com/spotify/cassandra-reaper

fonte

2016-07-15 03:12:11

Non sembra che lo strumento sia mantenuto più, e uno dei problemi aperti è che non funziona con le versioni più recenti come 3.x. Preferirei non utilizzare uno scheduler di riparazione centralizzato poiché sarebbe un singolo punto di errore. La documentazione parla di "esecuzione opportunistica di più riparazioni parallele contemporaneamente su nodi diversi", ma non sono chiaro su cosa può essere riparato in parallelo rispetto a cosa causerà la riparazione per generare eccezioni e blocco. Sembra che la riparazione non si protegga da tentativi di riparare la stessa tabella da più nodi. –

Nessuna delle risposte era proprio ciò che stavo cercando, ma la tua risposta è stata la più utile, quindi ti assegnerò la generosità. Grazie per l'informazione. –

Gestisco un cluster di nodi 50+ con 2 DC. Installa le attività di riparazione su un nodo e riparo diversi spazi chiavi ogni giorno per assicurarmi che ogni spazio tasti venga riparato una volta alla settimana. Non uso -pr flag e tutto funziona correttamente. Spero che questo possa essere utile. –

Riparazioni simultanee causano il blocco della riparazione

risposta

Problemi correlati