II. Etude de
l'Opportunité
II.1. Besoin d'un
système de réplication
La mise à jour de la base de données au niveau
du siège central se fait hebdomadairement c.-à-d. qu'à la
fin de chaque semaine (7 jours), on est obligé de graver des
données sur CD-RW et il y a des personnes habilitées à
ramener les CD-RW gravés au siège central en ville. Il se pose
alors un sérieux problème dans le cas où on ignorait que
la gravure n'a pu réussir ou le CD-RW a été abimé
ou encore lorsqu'il arrive que le support a été perdu et puis le
fichier comportant les mises à jour de la base de données
étant sous PostgreSQL qui est un SGBD libre téléchargeable
par tout le monde sur internet, une personne connaissant que la CENI utilise
comme SGBD PostgreSQL peut le télécharger pour enfin avoir la
possibilité d'ouverture et de faire n'importe quoi. Pour plus
d'efficacité, il faudra donc penser à une nouvelle méthode
pour obtenir les données provenant des sites.
Il convient aussi de prendre en compte la force et la
gravité d'un incident comme critère à intégrer dans
le processus de haute disponibilité. Il n'est pas toujours possible, de
prendre en compte tous les incidents sans tenir compte du coût ou de la
logistique globale de mise en oeuvre de la solution de dépannage.
I. Topologie de la Configuration de la
Réplication
Serveur 2
Serveur 3
Serveur 1
Siège Central
Figure 4.1. Topologie de la Configuration de la
Réplication
Dans notre travail, nous avons choisis de configurer une
réplication symétrique asynchrone des sites locaux vers le
siège central et une réplication symétrique asynchrone
entre les sites locaux suite aux données volumineuses qui seront
stockées dans la base lors des opérations d'identification et
d'enrôlement des électeurs. En fait, l'idée est de placer
entre les sites les plus rapprochés un serveur à partir duquel,
ils vont commencer à y accéder par une application cliente pour
enregistrement et autres opérations dans la base.
| 
