Vous n'êtes pas identifié(e).
Bonjour, alors ça c'est très intéressant. Est-ce que quelqu'un sait si Patroni fait ce genre de comparaison au moment d'une promotion/élection ?
malheureusement je ne vois pas d'autres alternatives.
pas de sauvegardes, pas de restaurations.
donc vous avez perdu un disque que vous avez remplacé.
Pourquoi ne pas appliquer le snapshot ovh "en entier" ce qui permettrait d'avoir tous les fichiers qui seraient remis aux bons endroits par l'application du snapshot ?
et ensuite relancer l'instance (restart pour être sûr)
et par défaut le PGDATA est situé à un seul endroit.
Si ce que vous semblez dire est exact, vous avez éclaté vos fichiers sur plusieurs disques distincts, donc vous devez avoir utilisé des tablespaces ?
exact ?
Bonjour,
oulala ! beaucoup d'information à droite et à gauche.
déjà on ne peut pas restaurer un PGDATA linux sur une machine windows.
comment avez vous sauvegarder votre instance linux avant d'avoir le problème de disque ?
Le principe de la sauvegarde physique c'est que vous ne pouvez pas restaurer qu'une partie seulement des fichiers car les autres fichiers seront en décallage.
En fait nos réponses dépendront de la manière dont vous avez sauvegarder votre instance avant le problème.
est-ce que vous êtes en mode archive_mode=on ?
avez vous au pire une sauvegarde logique (type pg_dump) ?
et surtout avez des traces du moteur postgres lorsque vous tenter de redémarrer l'instance ?
wal_level permet d'ajouter plus ou moins d'information dans les wal et cela permet (selon le niveau choisi) de faire de la replication physique, logique, etc...
Si vous mettez wal_level à minimal vous aurez moins d'informations dans les wal donc au final moins de wal au total pour une même période de temps qu'avec wal_level à logical.
archive_mode permet d'activer ou de désactiver l'archivage des wal à des fins de restauration PITR, c'est dire que selon la quantité de wal que vous archivé vous pourrez revenir jusqu'à un point dans le temps plus ou moins éloigné.
Bonjour,
vous ne pourrez jamais empêcher la génération des fichiers WAL car ce sont des éléments vitaux pour le fonctionnement de postgresql.
On ne va pas faire un cours ici mais pour faire vite : il ne faut jamais rien toucher du contenu du répertoire des wal sinon vous risquez de perdre définitivement votre instance et vos données.
https://docs.postgresql.fr/16/wal-intro.html
Bonjour,
Dans ce cas pourquoi ne pas utiliser la réplication physique plutôt que logique ?
avec la réplication physique, tout ce qui est fait sur le noeud leader est automatiquement envoyé sur le ou les noeuds replicas.
Ce n'est pas le cas avec la réplication logique qui n'envoie que les ordres DML de modification.
Bonjour,
L'autovacuum et le vacuum full sont 2 opérations différentes.
La vacuum full va réorganiser tous les blocs des tables, rendant l'espace disque, un peu comme si vous faisiez un export/import. Ce qui explique que la table passe de 3GB à 20MB.
L'autovacuum ne fait pas ça, à la place il va "flaguer" les lignes mortes pour qu'elles puissent être réutilisées par de nouvelles lignes. Donc dans ce cas la table ne devient pas plus petite, l'espace n'est pas rendu. Au mieux la table ne grossit pas ou moins vite que sans l'autovacuum.
Vous pouvez checker les actions autovacuum et autoanalyze dans cette vue : pg_stat_all_tables.
Bonjour,
avec la réplication physique, toutes les opérations sur le leader sont effectuées automatiquement sur le ou les replicas.
Mais contrairement à la replication logique, les réplicas en réplication physique sont en read-only.
Bonjour,
et vos tables sont liés par quoi ?
dans le lien que j'avais donné, la doc explique la technique de la FK avec l'option "on update cascade" ce qui semble correspondre à votre besoin.
Mais je me trompe peut être.
Bonjour, peut être voulez vous parler de foreign key (FK) ?
si oui alors la doc est ici :
https://docs.postgresql.fr/16/ddl-const … TRAINTS-FK
en relisant votre post, je comprend mieux.
Vous voulez fusionner les instances v10 et v11 dans une instance v12, c'est bien ça ?
Donc pour répondre à votre question : non ce n'est pas possible.
Pour la deuxième phase il faudra faire un pg_dump, pg_restore car l'instance v12 n'est plus vide à ce moment là (elle contient des données de la v10)
Bonjour,
avant de lancer pg_upgrade, il faut faire un initdb pour créer une instance vide dans la version postgresql cible.
Donc cette instance doit être vide.
s'il y a des objets dans votre instance c'est que d'une manière ou d'une autre vous pointez vers l'instance à migrer, pas la nouvelle.
Bonjour,
Oui je confirme les propos de ioguix : si vous vous lancez dans le HA, quelque soit la solution choisie il faut avoir dans la maison quelqu'un qui connait bien le sujet car ça peut rapidement devenir complexe.
Au passage pour vos tests sur Patroni : vous pouvez toujours mettre le cluster en mode maintenance (patronictl pause) : cela va empêcher les bascules et donc l'élection d'un nouveau leader si vous arrêtez volontairement le leader actuel.
si vous voulez des VIP et du load balancing il faut se tourner vers des produits type HA Proxy ou F5 (par exemple, il y en a d'autres) qui font ça très bien.
Le target_session_attrs c'est bien mais ce n'est pas suffisant.
Par exemple, les produits que je cite sont capable d'interroger l'API patroni pour savoir qui est leader et qui est replica pour faire de la redirection automatique vers le bon noeud.
et puis etcd ne "considère" rien du tout. Il ne fait que stocker des informations cruciales pour patroni (dont l'unicité du lock leader).
Patroni interroge etcd pour savoir notamment qui est qui dans le cluster patroni car etcd est le garant de cette information.
en fait le seul cas (à ma connaissance) où patroni est en read-only de son propre fait (c'est à dire quand il y a un problème) c'est quand les etcd ne sont plus disponibles.
On peut très bien avoir un seul noeud patroni en ligne et donc en leader.
C'est dangereux mais ça marche.
Avec mes maigres connaissances, je pense qu'avoir un seul noeud n'a plus de sens au niveau quorum, car à quoi sert le quorum sinon à provoquer une élection avec choix majoritaire ?
Et quand on est plus qu'un dans le quorum, l'élection est vite vue.
Je me demande même si vous n'auriez pas intérêt à sortir de patroni pour avoir un système en streaming sans couche HA.
Ainsi vous pourriez "maitriser"/"décider" qui est le leader
et bien oui c'est normal que le leader soit présent sur le dernier noeud disponible.
C'est bien le but de patroni, heureusement ;-)
Bonjour,
ça me semble normal puisque dans votre chaine de connection il y a "target_session_attrs=read-write"
https://docs.postgresql.fr/14/libpq-connect.html
target_session_attrs
Cette option détermine si la session doit avoir certaines propriétés pour être acceptable. C'est typiquement utilisé en combinaison avec plusieurs noms d'hôte pour sélectionner la première alternative acceptable parmi différents hôtes. Il existe six modes :
any (default)
toute connexion réussie est acceptable
read-writela session doit accepter les transactions en lecture/écriture par défaut (c'est-à-dire que le serveur ne doit pas être en mode hot standby et le paramètre default_transaction_read_only doit être à off)
read-onlyla session ne doit pas accepter les transactions en lecture/écriture par défaut (l'inverse)
primaryle serveur ne doit pas être en mode hot standby
standbyle serveur doit être en mode hot standby
prefer-standbyessaie tout d'abord de trouver un serveur secondaire, mais aucun des hôtes listés n'est un serveur secondaire, alors tente de nouveau dans le mode any
ah ok , vous ne faites pas un switchover mais un stop du service patroni du leader seulement.
Par contre pourquoi vous faites comme ça ?
Car ça casse le principe du HA patroni (toujours 3 noeuds en ligne dans votre cas avec bascule des rôles de chacun)
Bonjour,
ça m'étonne un peu que votre connexion persiste ?
En effet lors d'une bascule avec patroni, les noeuds sont redémarrés et une nouvelle timeline est créée, donc votre connexion devrait être perdue et votre update rollbacké.
quelqu'un pour infirmer ou confirmer ?
non ce n'est pas possible, il va falloir d'abord démarrer avec la version 14 et ensuite faire une migration vers 15.
par export/import ou pg_upgrade.
Bonjour,
Normalement, si :
- c'est le même OS
- c'est la même version de postgresql
- vous avez tous les fichiers de l'instance (conf, fichiers de données, WAL, tout le PGDATA)
Alors en recopiant tous ces fichiers dans l'arborescence et éventuellement en supprimant le fichier postmaster.pid (si l'instances a été violemment crashée) vous devriez pouvoir relancer l'instance et les bases de données avec pg_ctl (ou systemctl si vous avez un service, ou autre méthode selon l'OS).
