Presentazione di Rump: sincronizzazione a caldo di due database Redis tramite dump

Siamo entusiasti di annunciare il nostro primo progetto open source: Rump!

Rump è un piccolo strumento che si concentra su un unico obiettivo: raccogliere dati in tempo reale da un cluster Redis AWS ElastiCache.

Abbiamo affrontato questo problema quando abbiamo cercato di sincronizzare i container Redis di staging con il cluster di produzione. In Sticker Mule utilizziamo moltissimo Docker e CoreOS, facendo affidamento su un cluster ElastiCache per le nostre esigenze Redis in produzione.

Di recente avevamo deciso di rendere l'ambiente di staging quanto più prossimo possibile all'ambiente di produzione e Redis ne è un aspetto. Ecco il percorso che alla fine ci ha portati a Rump.

Evitare blocchi

Avevamo un unico, semplice requisito: non bloccare la produzione durante il recupero dei dati. Il fatto che Redis funzioni a thread singolo è un aspetto importante da tenere in considerazione.

Siamo rimasti sorpresi nello scoprire che ElastiCache viene fornito con alcuni comandi disabilitati. Essenzialmente, si tratta di tutti i comandi che puoi utilizzare per il trasferimento sicuro dei dati.

BGSAVE

Il metodo standard per attivare manualmente un backup di un database Redis è immettere il comando "BGSAVE" e attendere il completamento in background, un'operazione che non provoca blocchi. Purtroppo questa funzionalità è disabilitata, a meno che non si scelga di adottare l'implementazione interna della funzionalità di snapshot di AWS.

SLAVEOF

L'impostazione di slave è un'altra opzione interessante di Redis e per noi sarebbe stata la scelta ideale.

Il piano era impostare temporaneamente i container di staging Redis come slave del nostro cluster di produzione e ottenere così i dati in tempo reale. Purtroppo, anche lo strumento "SLAVEOF" è disabilitato e non c'è modo di aggiungere slave a un'istanza ElastiCache.

Strumenti esistenti

Esistono molti eccellenti strumenti per Redis che tentano di semplificare l'amministrazione dei server Redis, il dump su JSON, ecc.

Il problema è che gli strumenti più stabili e meglio gestiti utilizzano il comando "KEYS" per recuperare le chiavi per poi operare su tali chiavi. Il comando "KEYS" ha una complessità O(N) che blocca in modo serio Redis quando N è alto, fino a che non vengono restituite tutte le chiavi. I container di staging vengono creati ed eliminati di frequente e abbiamo un buon numero di chiavi: non vogliamo sferrare un attacco DoS contro il nostro stesso server!

Era chiaro che avevamo bisogno di uno strumento semplice che eseguisse la sola sincronizzazione. Abbiamo cominciato a sperimentare con "SCAN" per recuperare le chiavi e "DUMP/RESTORE" per recuperare/impostare i valori.

"SCAN" è un comando O(1), sicuro da eseguire su un server di produzione per ottenere tutte le chiavi, e per questo motivo la sua implementazione deve essere diversa rispetto a "KEYS". "SCAN" restituisce un gruppo di chiavi attualmente presente nel DB e un cursore al gruppo successivo.

"DUMP/RESTORE" rende indipendente la lettura/scrittura dei valori rispetto al tipo di chiave.

Tenendo a mente tutto questo, ecco cosa offre Rump:

• Lettura progressiva delle chiavi senza provocare blocchi tramite "SCAN".

• Operazioni sui valori indipendenti da "TYPE" tramite "DUMP/RESTORE".

• Operazioni "SCAN" e "DUMP/RESTORE" in pipeline.

• Lettura dal server di origine e scrittura sul server di destinazione simultanee. Rump non archivia tutte le chiavi prima di scriverle sul server di destinazione.

• Unico file binario compatibile con più piattaforme, senza dipendenze.

• Ingombro minimo, filosofia UNIX, esegue un'unica funzione con due flag.

Speriamo che lo strumento sarà utile a quanti sperimentano i nostri stessi problemi e un ringraziamento di cuore a Redis per il supporto di una tale varietà di comandi!

P.S. Se l'argomento ti interessa e sei alla ricerca di un'organizzazione in cui è un piacere lavorare per le persone di talento, stiamo assumendo.