Polémique sur une présentation trop sexiste

Matt Aimonetti est le responsable du projet couchDB. Le gros du travail d'un responsable de projet libre n'est pas de développer mais de communiquer sur le projet. Ainsi à chaque conférence se pose la lancinante question : Qu'est ce que je pourrais bien leur raconter pour les intéresser et pour qu'ils regardent mon projet. Pour ma part j'essaye de réaliser des présentations humoristiques, ainsi j'avais titrer une conférence : Les 10 bonnes raisons de ne pas utiliser mon projet. Matt est allé beaucoup plus loin , il a fait un parallèle entre son projet et une star du porno. Cette présentation qui est pleine d'humour (suivre ce lien pour la voir), a suscité une polémique sur l'utilisation racoleuse du porno (pron pour éviter la censure des pare-feux) pour une présentation informatique. Certains commentaires relevaient (à juste titre) le renvoie du rôle de la femme à un 'faire vendre' (même si le produit est gratuit). Je profite du sujet pour signaler que l'éditeur d'un célèbre générateur d'application qui porte un nom qui mélange window et developpement (c'est une devinette) use et abuse d'images de femme potiche dans ses encarts publicitaires (suivre ce lien pour savoir de quoi je parle) .


Je n'ai pas trouvé la présentation de Matt terrible mais il a atteint son objectif :je suis allé faire un tour sur le site de couchDB et j'ai préféré cette illustration :



A celle ci:

Test de replication d'un serveur memcached

Pour mettre en place la réplication d'un serveur memcached ,il faut :
- Le source de memcached
- Le patch repcached à appliquer


Sur le site du projet repcached on trouve à la fois le patch mais aussi le source memcached patché.

Pour appliquer le patch :

Aller dans le répertoire supérieur de memcache et lancer la commande :
patch -p0 < 'le_nom_du_fichier_patche'

Puis aller dans le répertoire des sources memcached et taper :
./configure --enable-replication
make && make install

Dans le répertoire source se trouve l'executable memcached et la commande :

./memcached -v -u root

donne la ligne :
replication: listen

Confirmé par un netstat -a|grep LIST

tcp 0 0 *:11211 *:* LISTEN
tcp 0 0 *:11212 *:* LISTEN

Le port 11212 sera utilisé par la réplication

Si on relance memcached en très verbeux on peut suivre les connexions :
./memcached -vv -u root

<6 server listening (replication)
replication: listen
<7 server listening
<8 send buffer was 109568, now 268435456
<8 server listening (udp)

Je lance une deuxième instance de memcached sur un port différent :
./memcached -u root -p 11310 -x localhost -vv
Les lignes en sortie donnent :

replication: connect (peer=127.0.0.1:11212)
<6 new client connection
<7 new client connection
<8 new client connection
replication: marugoto copying
<6 marugoto_end
<9 server listening
<10 send buffer was 109568, now 268435456
<10 server listening (udp)
replication: start


Dans la première console s'ajoute les lignes :

replication: accept
<6 connection closed.
<9 new client connection
<6 new client connection
<10 new client connection

Ainsi le premier serveur est en relation avec le deuxième
L'ajout d'une session sur le deuxième serveur est répercuté sur la premier serveur
(deuxième serveur)
<11 new client connection
<11 set fac097f7fb944ea33b7fb2f31b45b9b4 1 0 56
>11 STORED
<11 set fac097f7fb944ea33b7fb2f31b45b9b4 1 0 94
>11 STORED

(premier serveur)
<9 rep fac097f7fb944ea33b7fb2f31b45b9b4 1 0 56 1
REP>9 STORED
<9 rep fac097f7fb944ea33b7fb2f31b45b9b4 1 0 94 2
REP>9 STORED

Le seul mode disponible est donc le mode master/master

Si on coupe un serveur et qu'on ajoute des entrées sur l'autre , au redémarrage du serveur stoppé , les lignes suivantes vont s'afficher :
replication: marugoto start
replication: marugoto 7
replication: marugoto owari

(l'auteur est japonais et aime le manga !! )

Le serveur qui est resté en marche envoie les données que le serveur stoppé n'a pas enregistrées.

Ainsi se dispositif réalise à la fin la synchronisation ET la restauration des sessions .
Les nouvelles options de réplications ne sont fournies qu'a la deuxieme instance par les paramètres : -x host_de_l_autre_serveur -X port de réplication (defaut 11212) comme l'indique l'option -h (help)
-x hostname or IP address of peer repcached
-X TCP port number for replication (default: 11212)

L'avantage de ce dispositif est qu'il est intégré à memcached et qu'il propose un système de resynchronisation.