Vous n'êtes pas identifié(e).
Bonjour,
Nous utilisons avec bonheur PostgreSQL dans un environnement WEB depuis 7 ans.
Nos applications et le volume de données hébergé a fortement augmenté depuis le début. Aujourd'hui, nous gérons environ 20 millions de requêtes WEB par jour (mais pas autant de requêtes SQL bien sûr).
Nous utilisons notamment de plus en plus le moteur Tsearch, mais les performances de notre infrastructure (une ferme de serveurs WEB, mais un seul serveur PostgreSQL) commencent à s'en ressentir. J'aimerais donc répartir la charge sur plusieurs serveurs (modifications -nombreuses- et lectures).
Je m'intéresse pour cela à Bucardo qui semble assez simple à mettre en place, avec des contraintes assez faibles, et qui semble répondre à nos besoins. Je me pose cependant une question à laquelle je n'ai pas trouvé de réponses sur Internet: une fois la réplication configurée et active, comment se passent les modifications de schéma (ajout/modification de tables, de vues, d'index...). Peut-on les répliquer automatiquement, ou doit-t-on les appliquer manuellement sur les 2 instances.
J'ajoute une autre question. Lorsqu'une instance s'arrête (par exemple pour une maintenance serveur), la synchronisation peut-elle ensuite reprendre automatiquement (ie la mise à jour des données du serveur "vivant" vers l'autre)
Par avance, merci pour vos points de vue
Jérôme
Hors ligne
Peut-on les répliquer automatiquement, ou doit-t-on les appliquer manuellement sur les 2 instances.
Il faut les appliquer sur les deux.
Lorsqu'une instance s'arrête (par exemple pour une maintenance serveur), la synchronisation peut-elle ensuite reprendre automatiquement (ie la mise à jour des données du serveur "vivant" vers l'autre)
À ma connaissance, oui.
Pour aller un peu plus loin... Si vous utilisez Bucardo en maître/maître, vous vous bloquez à deux serveurs maximum. Par contre, en maître/esclave, vous pouvez en avoir plus. Mon seul réel soucis actuellement avec Bucardo, c'est qu'il est dans une phase de développement intense actuellement. Comprenez-moi bien, c'est très bon signe sur l'implication des (du ?) développeurs et sur leur volonté d'améliorer leur outil. Par contre, ça laisse supposer que la solution est loin d'être finale.
Guillaume.
Hors ligne
Bonjour,
Merci beaucoup pour votre réponse. Je constate en effet le développement rapide de Bucardo. Par exemple, dans vos news du 18/10, vous citez la mise à disposition de la version 4.3 de cet outil, mais, quand on suit le lien, le site parle de la version 4.4.
Je poursuis donc ma réflexion en m'orientant désormais vers une réplication maitre/esclaves qui permet effectivement une plus grande scalabilité (plusieurs esclaves). Dans votre excellente série d'articles parue dans le HS de Linux Mag, vous en évoquez plusieurs. Par contre, vous ne parlez pas de Rubyrep. Cette solution, évoquée dans le wiki PostgreSQL (http://wiki.postgresql.org/wiki/Replica … on_Pooling) semble particulièrement facile à mettre en oeuvre et il y est indiqué qu'elle peut automatiquement prendre en compte les tables nouvellement crées. Si tel est réellement le cas, cela me semble un avantage certain. En effet, devoir manuellement effectuer les changement de schéma sur l'ensemble des serveurs présente une faiblesse de la plupart des outils existants; il est en effet "facile" d'omettre une modification, ce qui aura pour conséquence évidente la non total réplication des données.
Quelqu'un aurait-il des retours sur la solution rubyrep ?
Hors ligne
La 4.3 apparaît le 08/10/2009 18:06 et la 4.4 le 14/10/2009 19:06. Six jours. C'est peu 
Par contre, vous ne parlez pas de Rubyrep.
Je voulais en parler mais le gros soucis a été le manque de place. Un HS linux mag (comme un numéro normal) a un nombre de page max fixe (80, + ou - 2 ou 3, je pense). Mais il est possible que j'écrive un article sur cet outil plus ou moins rapidement.
Quelqu'un aurait-il des retours sur la solution rubyrep ?
Peu de retours sur rubyrep. Il est à mon avis peu utilisé. Le choix du langage (ruby) y est certainement pour quelque chose. Mais en effet, sa détection automatique des ajouts de table est intéressant. Cependant, c'est assez simple à faire, même pour d'autres outils de réplication. Il suffit d'un démon qui compare les structures des deux bases, et fait la synchronisation (ceci dit, il est toujours mieux d'utiliser une fonctionnalité déjà développée).
Guillaume.
Hors ligne
Mais en effet, sa détection automatique des ajouts de table est intéressant. Cependant, c'est assez simple à faire, même pour d'autres outils de réplication. Il suffit d'un démon qui compare les structures des deux bases, et fait la synchronisation (ceci dit, il est toujours mieux d'utiliser une fonctionnalité déjà développée).
Votre article sur Londiste m'a donné des idées à ce sujet. Vous expliquez comment recopier le schéma de la base maitre vers la base esclave (je n'ai pas l'article sous les yeux, mais je me souviens que le principe global s'appuie sur pg_dump -s). En sauvegardant le résultat dans un fichier d'une fois sur l'autre, il est facile de détecter tout changement de schéma. En cas d'ajout de tables, si ma mémoire est bonne, on peut rappeler la commande de réplication pour toutes les tables. Dans ce cas, si j'ai bien compris, l'outil va ignorer cette requête pour les tables déjà répliquées. Le tour est donc joué, simplement !
Mais, bien entendu, un changement de schéma ne se résume pas à un ajout de tables. Et pour tous les autres cas, je n'ai pas vraiment d'idées.
Hors ligne
check_postgres permet d'en savoir beaucoup plus. Il dispose d'une action qui compare les schémas des deux bases et indique les différences pour tous les objets.
Guillaume.
Hors ligne
check_postgres permet d'en savoir beaucoup plus. Il dispose d'une action qui compare les schémas des deux bases et indique les différences pour tous les objets
Merci beaucoup !
Je ne connaissais pas cet outil. Dommage qu'il ne réalise pas lui-même les opérations nécessaires sur les esclaves pour resynchroniser les schémas. Cela devrait cependant m'être d'une aide précieuse.
Encore merci !
Hors ligne
C'est un outil de récupération d'informations. Donc c'est logique qu'il n'aille pas plus loin. Par contre, à partir de son code source, il devrait être possible de faire ce que vous indiquer. Ce serait même un projet (libre ) très intéressant.
Guillaume.
Hors ligne
