Haute disponibilité pour postgresql

Je suis nouveau dans la base de données PostgreSQL. Récemment, notre développeur a dû effectuer certaines mises à niveau de nos systèmes.

Pour cette raison, nous prévoyons d'implémenter une méthode afin d'implémenter le basculement de la base de données.

Sur la base de ma lecture du wiki postgresql ici , nous essayons de mettre en œuvre une redondance d'UC ou une redondance d'UC. Mes questions sont donc:

Quelles sont les principales différences entre eux?
Quel est le meilleur?
Existe-t-il une autre méthode que nous pouvons envisager pour rendre la haute disponibilité dans nos bases de données Postgres?

postgresql linux high-availability

— user119720
source

Une configuration Heartbeat + STONITH appropriée est la clé si vous prévoyez d'utiliser le basculement automatique. Le basculement automatisé avec un déclencheur manuel peut être plus sûr. Voir aussi wiki.postgresql.org/wiki/High_Available

— Craig Ringer

@CraigRinger thanks.i examinerai cela. Mais qu'est-ce que la veille chaude et chaude? Pouvez-vous donner quelques détails?

— user119720

Réponses:

1a. La redondance d'alerte est une sauvegarde incrémentielle "en direct" alimentée par des blocs complets de modifications (segments wal) de 16 Mo chacun, qui sont envoyés au nœud de secours une fois qu'ils sont remplis. Vous ne pouvez pas interroger un nœud de secours immédiat. 16 Mo de modifications (par défaut) peuvent signifier beaucoup de transactions, si le maître échoue, elles seront perdues.

1b. Hot Standby . (également une sauvegarde incrémentielle "en direct"). De petites modifications sont envoyées à l'esclave (enregistrements wal, qui sont de minuscules parties d'un segment wal). Vous pouvez interroger (lecture seule) le nœud de secours automatique. La fenêtre pour les transactions perdues en cas de défaillance du maître est très petite. Il existe des nœuds de secours à chaud synchrones et asynchrones, un nœud synchrone forcera le maître à attendre qu'il confirme l'application des modifications, puis le maître validera la transaction.Dans la réplication asynchrone, le maître envoie les enregistrements wal et n'attend pas la confirmation . Le premier nécessite une liaison très fiable et rapide entre le maître et l'esclave, ajoute également une surcharge au maître mais ne garantit aucune perte de données.

Concernant les sauvegardes incrémentielles: 1. Vous prenez une copie de base de toute votre installation de base de données. 2. Envoyez-le à l'esclave. 3. Configurez-le pour rattraper les changements.

La réplication en streaming (redondance d'UC) est la gagnante ici. Personnellement, je préfère la réplication asynchrone car elle n'impose pas une charge considérable au maître et le retard de réplication est très faible (quelques secondes dans de nombreux cas)

Un complément à cette configuration est pg-pool. Il agit comme un proxy entre l'application et les serveurs participant à une configuration de réplication comme celle décrite ci-dessus, il a des capacités d'équilibrage de charge et de requête parallèle. Il est également capable de fournir un basculement automatique. http://www.pgpool.net/pgpool-web/contrib_docs/simple_sr_setting/index.html

— René Romero Benavides
source

J'apprécie vraiment votre réponse rapide qui est vraiment utile à mes besoins. Pouvez-vous également me recommander les bons liens pour réaliser cette configuration?

— user119720

bien sûr, jetez un œil ici: [lien] pgpool.net/pgpool-web/contrib_docs/simple_sr_setting/index.html

— René Romero Benavides

Vous êtes les bienvenus.La courbe d'apprentissage dans ces domaines est assez abrupte, soyez patient. Bonne nuit (jour ou autre) de Mexico.

— René Romero Benavides

J'ai fait quelques recherches basées sur vos liens et il y a des questions qui me sont venues à l'esprit. 1. La redondance d'UC peut-elle être configurée pour la réplication en streaming? 2. Est-ce que pg-pool peut être configuré pour une mise en veille à chaud? 3. Si nous avons configuré le point de notre serveur d'applications sur notre base de données principale lors du basculement, devons-nous changer la configuration de la base de données du serveur d'applications en base de données esclave ou pg-pool lui-même agira comme proxy pour l'esclave? Désolé pour le problème, j'espère que cela ne vous dérange pas.

— user119720

La réponse que vous avez déjà obtenue est utile mais prête à confusion un peu ici. Toutes les solutions de réplication intégrées utilisent le même mécanisme de base: copier les données du journal à écriture anticipée sur un serveur de secours.

Vous pouvez déplacer ces données WAL pour la réplication soit un fichier de 16 Mo à la fois, en utilisant la fonction archive_command, ou en utilisant Streaming Replication (SR). Si vous utilisez SR, vous devez vraiment configurer l'archivage également, et le serveur basculera entre eux selon les besoins.

Vous pouvez avoir un serveur de secours à chaud, qui ne peut pas répondre aux requêtes. Ou vous pouvez avoir un serveur de secours à chaud, qui peut répondre à ceux en lecture seule. Cela n'est pas lié à la manière dont les données sont mises en veille.

Chacun de ces deux choix se combine avec chacun des autres, et vous pouvez avoir les quatre combinaisons. Vous pouvez avoir un Hot Standby répondant aux requêtes tout en étant alimenté avec un fichier à la fois des segments WAL. Vous pouvez avoir un serveur de réplication en streaming sur lequel la redondance d'UC n'est pas activée, il ne répondra donc pas aux requêtes. C'est juste que le cas le plus courant, de nos jours, est à la fois la réplication en streaming et la redondance d'UC. Voilà l'ensemble complet des fonctionnalités. Encore une fois, n'ignorez pas l'ancien mécanisme archive_command simplement parce qu'il est possible de l'éviter maintenant. Il peut toujours vous sauver des échecs de streaming qui sont autrement difficiles à récupérer.

— Greg Smith
source