GNU/Linux Magazine 132

Vous avez déjà goûté du spam ? Je veux dire, du vrai spam. Celui qui est servi en boîtes rectangulaires et a vaguement la couleur du jambon. On m’en a servi, une fois, lors d’un réveillon, et je peux vous assurer que ce n’est vraiment pas bon ! Mais le spam dont on va parler ici est différent, plus électronique, mais tout aussi dégoûtant.Combattre le spam est probablement la tâche la plus complexe du postmaster. Les techniques sont nombreuses et il est indispensable de les cumuler pour obtenir un résultat pertinent.

Lors du précédent article, nous avons vu comment mettre en place un serveur maître et son serveur esclave. Nous allons aller un peu plus loin dans cet article, en proposant maintenant une réplication beaucoup plus synchronisée (mais toujours pas synchrone).Nous allons aussi passer en revue un certain nombre de points importants à connaître pour administrer au mieux ses serveurs en réplication. Tout d'abord, le problème posé par les requêtes en lecture seule. Ces dernières posent des verrous et, aussi peu gênants soient-ils dans une utilisation normale, ils peuvent poser quelques soucis majeurs pour un serveur esclave. Nous verrons aussi comment effectuer une bascule dans deux cas : la bascule volontaire (« switchover ») et la bascule forcée (« failover »). Enfin, nous verrons comment surveiller l'état de la réplication et des deux serveurs concernés.

La visite du code de la montre continue avec ce second article, bref mais intense, dédié à une toute petite unité de conception : « increment_vector_4 ». Petite par la taille mais d'une grande utilité.