Le mar. 11 juin 2019 à 11:25, adrien nayrat adrien.nayrat.axess@gmail.com a écrit :
A/ on met à jour le master PG de façon classique, tous les slaves sont
pétés et il faut ensuite les reconfigurer. Problèmes: le temps de l'upgrade toute la charge se retrouve sur le master seul, et le temps de coupure correspond au pg_upgrade, soit plusieurs heures pour un serveur d'1To, et il faut disposer du double de l'espace disque (soit 2To mini) sur ce master, ce qui n'est plus le cas.
Non, vous pouvez faire un upgrade avec des hardlink. L'upgrade est bien plus rapide (mais pas de rollback possible sur l'ancienne instance une fois que la nouvelle instance a été démarrée). (J'ai un peu l'impression que c'est ce que fait MySQL : https://dev.mysql.com/doc/refman/8.0/en/upgrading-what-is-upgraded.html)
Certes, mais je ne me risquerai pas à mettre à jour un serveur sans rollback RAPIDE possible.
Tout ça manque de précision:
- Les DDL ne sont pas répliqués oui, après, de manière générale, on ne
change pas le schéma tous les jours non plus. Il suffit de les appliquer sur l'instance répliqué. Le TRUNCATE n'est supporté qu'à partir de la version 11 donc dans votre cas oui ça peut poser problème.
ça pose problème dans ce cas précis avec les TRUNCATE TABLE.
- La réplication des séquences, ça pose problème dans le cas où vous
faite une bascule sur le secondaire en réplication logique. Il faut prévoir de les synchroniser lors de la bascule, il doit traîner des scripts qui font ça, c'est l'affaire de quelques minutes.
- Les tables sans PK...comment dire... vous connaissez la
normalisation...
Il y a certain cas où les PK ne sont pas nécessaire, sachant qu'une PK "coûte" un index et donc de la mémoire.
Ca dépend des installations :
- Petite base avec downtime accepté, un simple dump/restore et au
passage on recrée les index qui ne seront plus fragmentés.
Clairement on n'est pas dans ce cas là.
- Grosses instances avec downtime réduit : pg_upgrade avec hardlink.
Il faut suivre scrupuleusement la doc pour faire les opérations dans le bon ordre. Mais ça consiste grosso modo à une mise à jour du catalogue qui ne prendre que quelques minutes, sauf si vous avez un catalogue vraiment monstrueux.
pg_upgrade est très risqué avec les hardlinks.
- Grosses instances avec downtime très réduit : slony ou réplication
logique avec synchro des séquences.
pose les problèmes précédemment évoqués.
Il y a eu plusieurs articles sur le sujet ces dernières années, ça devrait vous aider.
Y'en a à la pèle, aucun dans des conditions réelles avec tout ce qu'on peut trouver comme cas.
Le mar. 11 juin 2019 à 11:41, Greg greg-frsag@duchatelet.net a écrit :
Le mar. 11 juin 2019 à 11:25, adrien nayrat adrien.nayrat.axess@gmail.com a écrit :
A/ on met à jour le master PG de façon classique, tous les slaves sont
pétés et il faut ensuite les reconfigurer. Problèmes: le temps de l'upgrade toute la charge se retrouve sur le master seul, et le temps de coupure correspond au pg_upgrade, soit plusieurs heures pour un serveur d'1To, et il faut disposer du double de l'espace disque (soit 2To mini) sur ce master, ce qui n'est plus le cas.
Non, vous pouvez faire un upgrade avec des hardlink. L'upgrade est bien plus rapide (mais pas de rollback possible sur l'ancienne instance une fois que la nouvelle instance a été démarrée). (J'ai un peu l'impression que c'est ce que fait MySQL : https://dev.mysql.com/doc/refman/8.0/en/upgrading-what-is-upgraded.html)
Certes, mais je ne me risquerai pas à mettre à jour un serveur sans rollback RAPIDE possible.
Simple question par pure curiosité, dans le premier mail tu disais que les upgrade MySQL se faisait plutôt facilement en décrivant le process. Est-ce qu'il est possilbe de faire un rollback après avoir démarré MySQL?
Si la réponse est non, ça correspond grosso modo au pg_upgrade + hardlink. La seule différence que je vois est que MySQL supporte la réplication entre versions majeures différente, là où la réplication pg est plus bas niveau et ne permet pas ce genre de réplication.
Simple question par pure curiosité, dans le premier mail tu disais que les upgrade MySQL se faisait plutôt facilement en décrivant le process. Est-ce qu'il est possilbe de faire un rollback après avoir démarré MySQL?
Si la réponse est non, ça correspond grosso modo au pg_upgrade + hardlink. La seule différence que je vois est que MySQL supporte la réplication entre versions majeures différente, là où la réplication pg est plus bas niveau et ne permet pas ce genre de réplication.
Disons qu'après l'upgrade de 10 slaves MySQL, l'upgrade du master ne devrait pas poser de problèmes, la procédure d'upgrade étant validée. Les très rares cas où j'ai rencontré des problèmes, ils étaient soit inclus dans la procédures d'upgrade, soit (mieux) corrigés sur le master avant upgrade des slaves suivants.
Salut, j'ai pas vraiment les billes pour aider sur ce cas, mais je tique sur le bas niveau de réplication Connais tu l'infra de stockage sur laquelle tu repose ? Si il y a de la virtualisation du stockage en jeu, tu peux peut-être utiliser la fonctionnalité de snapchot de Lun pour un retour arrière rapide. Je saurais a peu près le faire sur du Datacore, mais d'autres doivent le faire aussi.
Le mar. 11 juin 2019 à 11:59, Greg greg-frsag@duchatelet.net a écrit :
Simple question par pure curiosité, dans le premier mail tu disais que
les upgrade MySQL se faisait plutôt facilement en décrivant le process. Est-ce qu'il est possilbe de faire un rollback après avoir démarré MySQL?
Si la réponse est non, ça correspond grosso modo au pg_upgrade + hardlink. La seule différence que je vois est que MySQL supporte la réplication entre versions majeures différente, là où la réplication pg est plus bas niveau et ne permet pas ce genre de réplication.
Disons qu'après l'upgrade de 10 slaves MySQL, l'upgrade du master ne devrait pas poser de problèmes, la procédure d'upgrade étant validée. Les très rares cas où j'ai rencontré des problèmes, ils étaient soit inclus dans la procédures d'upgrade, soit (mieux) corrigés sur le master avant upgrade des slaves suivants.
-- Greg _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Au final, voici ce que j'ai fais :
Phase A: vérification de la faisabilité et tests 1/ sortir un slave de la prod 2/ promouvoir ce slave via la commande "pg_ctlcluster promote". Ceci ne provoque pas de bascule avec le vrai master, et même si ça peut paraître logique pour certains, ce n'est indiqué nulle part dans la doc et cette info est importante sur un environnement de production. Avec repmgr, un promote fait une bascule. 3/ tester l'upgrade en 11 en mode upgrade et avec hardlinks, avec la commande: "time pg_upgradecluster -m upgrade -j 8 --link 10 main /var/local/postgresql/11/main" 4/ ... qui plante ! Principalement à cause des extensions: une manquante (repack) et surtout postgis qui est bien foireux à mettre à jour: il faut installer postgis 2.5, copier les libs 2.5 en les nommant 2.4 (cd /usr/lib/postgresql/11/lib && cp postgis-2.5.so postgis-2.4.so) 5/ refaire l'upgrade 2x : le 1er plante parce que l'instance met trop de temps à s'arrêter, le 2ème lance l'instance qui s'était arrêtée, la stop de nouveau puis procède à l'upgrade, temps total <2min 6/ faire les ALTER EXTENSION mon_extension UPDATE de toutes les extensions utilisées, dans tous les db/schéma
Phase B: en prod 1/ répéter les étapes de la phase A mais sur le master et sans les erreurs (extensions...) 7/ setup des slaves: installer pg11, les extensions, et faire les clone standby.
Pour la petite histoire, les clones mettront 7h à se faire pour une db d'1To sur un RAID10 6 disques SAS 15krpm, pendant ce temps toute la charge se trouve sur le master. Le temps de coupure de l'app aura été inférieur à 5min ce qui est bien plus acceptable.
Bonne aprem ! Greg
Le mar. 11 juin 2019 à 23:29, SERRUT Arnaud qqqrno@gmail.com a écrit :
Salut, j'ai pas vraiment les billes pour aider sur ce cas, mais je tique sur le bas niveau de réplication Connais tu l'infra de stockage sur laquelle tu repose ? Si il y a de la virtualisation du stockage en jeu, tu peux peut-être utiliser la fonctionnalité de snapchot de Lun pour un retour arrière rapide. Je saurais a peu près le faire sur du Datacore, mais d'autres doivent le faire aussi.
Le mar. 11 juin 2019 à 11:59, Greg greg-frsag@duchatelet.net a écrit :
Simple question par pure curiosité, dans le premier mail tu disais que
les upgrade MySQL se faisait plutôt facilement en décrivant le process. Est-ce qu'il est possilbe de faire un rollback après avoir démarré MySQL?
Si la réponse est non, ça correspond grosso modo au pg_upgrade + hardlink. La seule différence que je vois est que MySQL supporte la réplication entre versions majeures différente, là où la réplication pg est plus bas niveau et ne permet pas ce genre de réplication.
Disons qu'après l'upgrade de 10 slaves MySQL, l'upgrade du master ne devrait pas poser de problèmes, la procédure d'upgrade étant validée. Les très rares cas où j'ai rencontré des problèmes, ils étaient soit inclus dans la procédures d'upgrade, soit (mieux) corrigés sur le master avant upgrade des slaves suivants.
-- Greg _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Liste de diffusion du FRsAG http://www.frsag.org/
-
adrien nayrat -
Greg -
SERRUT Arnaud