Découvrez Rump : synchronisation à chaud de deux bases de données Redis en dumps

Nous sommes ravis d'annoncer notre premier projet open source : [Rump](https://github.com/stickermule/rump) !

Rump est un tout petit outil conçu pour une chose simple : obtenir des données en temps réel à partir d'un cluster AWS ElastiCache Redis.

Nous avons rencontré ce problème lorsque nous avons essayé de synchroniser nos conteneurs de préproduction Redis avec notre cluster de production. Chez Sticker Mule, nous utilisons beaucoup Docker et CoreOS, en nous appuyant sur un cluster ElastiCache pour nos besoins Redis en production.

Dernièrement, nous avons voulu rendre notre environnement de préproduction aussi proche que possible de notre environnement de production, et Redis en fait partie. Voici le cheminement qui a finalement mené à la création de Rump.

## Ne restez pas bloqué

Nous avions une simple exigence : ne pas bloquer la production pendant l'obtention des données. Le caractère single-thread de Redis est un aspect important à prendre en compte.

A notre grande surprise, nous avons découvert qu'[ElastiCache est livré avec certaines commandes désactivées](http://docs.aws.amazon.com/AmazonElastiCache/latest/UserGuide/ClientConfig.RestrictedCommands.html). Pratiquement toutes les commandes que vous pouvez utiliser pour transférer des données en toute sécurité.

![Rump Redis Sync](https://storage.googleapis.com/sm-content/blog/b1b52716565b7122991bd66715fd2d16c65161d6)

### BGSAVE

La méthode standard pour déclencher manuellement une sauvegarde d'une base de données Redis consiste à envoyer un « ```BGSAVE``` » et à attendre qu'il soit terminé en arrière-plan, une opération non-bloquante. Malheureusement, cette fonctionnalité est désactivée, à moins que vous n'utilisiez la fonctionnalité snapshot interne d'AWS.

### SLAVEOF

La mise en place d'esclaves est une autre option intéressante proposée par Redis, et elle aurait été le choix idéal pour nous.

Le plan était de configurer temporairement les conteneurs de préproduction de Redis en tant qu'esclaves de notre pôle de production, afin d'obtenir des données en direct. Malheureusement, la fonction « `SLAVEOF` » est également désactivée, il n'y a donc aucun moyen d'ajouter des esclaves à une instance d'ElastiCache.

### Outils existants

Il existe de nombreux outils Redis extraordinaires qui aident à simplifier l'administration des serveurs Redis, l’envoi vers JSON, etc.

Le problème est que la plupart des outils stables et entretenus utilisent la commande « ```KEYS``` » pour obtenir des clés, puis opèrent sur les clés. La commande « ```KEYS``` » a une complexité O(N), bloquant fortement Redis lorsque N est élevé, jusqu'à ce que toutes les clés soient restituées. Les conteneurs de préproduction sont créés et détruits fréquemment et nous avons un bon nombre de clés, nous ne voulons donc pas inonder notre propre serveur.

![rump-logo-600w`SCAN`](https://storage.googleapis.com/sm-content/blog/6054ad712c1d34e3d9b01881d6e3fdf9c6031bd9)

Il est évident que nous avions besoin d'un outil simple dédié à la synchronisation. Nous avons commencé à jouer avec `SCAN` pour obtenir les clés, et `DUMP/RESTORE` pour obtenir/définir les valeurs.

```SCAN``` est une commande O(1), qui peut être exécutée en toute sécurité sur un serveur de production pour obtenir toutes les clés, et à cause de cela, son implémentation doit être différente de celle de  ```KEYS```. ```SCAN``` renvoie un groupe de clés actuellement présentes dans la base de données, et un curseur sur le groupe suivant.

La fonction ```DUMP/RESTORE``` permet de lire/écrire des valeurs indépendamment du type de clé.

En gardant cela à l'esprit, voici ce que Rump nous apporte :

* Lecture des clés progressives non bloquantes grâce à ```SCAN```.
* Opérations sur des valeurs indépendantes de  ```TYPE``` grâce à  ```DUMP/RESTORE```.
* Opérations ```SCAN```et 
 ```DUMP/RESTORE``` en pipeline.
* La lecture depuis le serveur source et l'écriture sur le serveur de destination sont simultanées. Rump ne stocke pas toutes les clés avant d'écrire sur le serveur de destination.
* Un seul binaire multiplateforme, sans dépendance.
* Empreinte minimale, [philosophie UNIX](https://en.wikipedia.org/wiki/Unix_philosophy), il ne fait qu'une chose avec deux drapeaux.

Nous espérons que l'outil sera utile à ceux qui rencontrent les mêmes problèmes que nous, et pour cela nous remercions [Redis](https://redis.io/) pour la prise en charge d'un si large éventail de commandes !

P.S. Si cela vous intéresse et que vous recherchez une organisation dans laquelle des personnes de talent prennent plaisir à travailler, [nous recrutons](https://www.stickermule.com/careers?ref=blog).

Rump est un tout petit outil conçu pour une chose simple : obtenir des données en temps réel à partir d'un cluster AWS ElastiCache Redis.

Publications de Marco Lisci

Découvrez Rump : synchronisation à chaud de deux bases de données Redis en dumps