Vous n'êtes pas identifié(e).
Bonjour,
Si nous avons une application qui doit tourner sans interruption (24/7) et que nous devons faire du DDL (alter table, changement de contrainte, etc...) sur des tables volumineuses (disons plusieurs centaines de millions de lignes), quelle est la meilleure solution pour ne pas provoquer d'interruption de service à cause des locks générés.
Je pense au dbms_redefinition d'Oracle qui permet de gérer ce genre de situations. Quelles sont les solutions offertes par postgresql ?
Merci par avance.
Dernière modification par ruizsebastien (04/10/2013 17:01:02)
Cordialement,
Sébastien.
Hors ligne
En dehors de la clause CONCURRENTLY pour le CREATE INDEX, je ne vois pas.
Guillaume.
Hors ligne
Bonjour,
Est-ce qu'un système de réplication est envisageable pour ce cas particulier ?
Cordialement,
Sébastien.
Hors ligne
Là, il va falloir être plus précis. Je ne vois vraiment pas le lien entre réplication et DDL bloquante ??
Guillaume.
Hors ligne
Bonjour,
Je ne connais pas en détail toutes les possibilités offerte en matière de haute disponibilité, mais les solutions que propose pg_pool par exemple pourrait correspondre à ce que je cherche. Par exemple si on a deux clusters gérés par pg_pool, on peut imaginer que l'on peut passer du ddl sur un cluster puis ensuite sur l'autre (du coup sans interruption de service) ? Je me trompe ?
Sinon je me demande comment font les autres entreprises qui font du 24/7 pour faire évoluer leur modèle de données (je pense en particulier au site leboncoin qui est sous postgresql).
Cordialement.
Cordialement,
Sébastien.
Hors ligne
la réplication implique une structure de table identique, si vous faites des ddls ils seront envoyés de l'autre coté.
même avec slony vous vous retrouveriez dans un état étrange.
Les locks n'impliquent que l'écriture non ?
Hors ligne
En cas d'alter table en demande un verrou exclusif :
ACCESS EXCLUSIVE
Entre en conflit avec tous les modes (ACCESS SHARE, ROW SHARE, ROW EXCLUSIVE, SHARE UPDATE EXCLUSIVE, SHARE, SHARE ROW EXCLUSIVE, EXCLUSIVE et ACCESS EXCLUSIVE). Ce mode garantit que le détenteur est la seule transaction à accéder à la table de quelque façon que ce soit.
Acquis par les commandes ALTER TABLE, DROP TABLE, TRUNCATE, REINDEX, CLUSTER et VACUUM FULL. C'est aussi le mode de verrou par défaut des instructions LOCK TABLE qui ne spécifient pas explicitement de mode de verrouillage.
Avec Slony ok ce n'est pas possible, mais avec pg_pool ?
C'est le pourquoi de ma question d'origine : comment minimiser au maximum les impacts d'un changement DDL pour une application 24/7 ?
Cordialement,
Sébastien.
Hors ligne
Ce n'est pas plus possible avec slony qu'avec pgpool. Il faut évidemment que les structures soient identiques de chaque côté. De toute façon, il n'est pas sérieux d'envisager pgpool pour de la réplication.
Toute application, même 24/7, a des fenêtres de tir pour des opérations de maintenance. Il faut donc utiliser ces fenêtres de tir pour les faire. C'est ce que tous nos clients font, même si cela ne veut pas dire que trouver ces fenêtres de tir est facile.
Guillaume.
Hors ligne
merci pour ta réponse, ça va m'aider à faire passer le message.
Cordialement,
Sébastien.
Hors ligne
Bonjour,
Je ne connais pas en détail toutes les possibilités offerte en matière de haute disponibilité, mais les solutions que propose pg_pool par exemple pourrait correspondre à ce que je cherche. Par exemple si on a deux clusters gérés par pg_pool, on peut imaginer que l'on peut passer du ddl sur un cluster puis ensuite sur l'autre (du coup sans interruption de service) ? Je me trompe ?
Sinon je me demande comment font les autres entreprises qui font du 24/7 pour faire évoluer leur modèle de données (je pense en particulier au site leboncoin qui est sous postgresql).Cordialement.
Le bon coin est indisponible la nuit justement pour assurer ces traitements là (reindexation, vacuum, DDL...)
Seule la lecture est possible, mais pas l'joute de nouvelles annonces. C'est son point faible.
Effectivement Oracle ou SQL Server permettent de faire du DDL et de la réindexation non bloquante sur des bases en prod 24/24 7/7.
A +
Frédéric Brouard, alias SQLpro, ARCHITECTE DE DONNÉES, Expert langage SQL
Le site sur les SGBD relationnel et langage SQL : http://sqlpro.developpez.com/
Modélisation de données, conseil, expertise, audit, optimisation, tuning, formation
* * * * * Enseignant CNAM PACA, ISEN Toulon, CESI Aix en Provence * * * * *
Hors ligne
Ce qui n'empêche pas Le Bon Coin d'être suffisamment heureux avec PostgreSQL et Slony pour ne pas avoir enfin d'en changer... soit le coup de DDL n'est pas si gênant, soit il y a d'autres avantages majeurs par rapport aux autres SGBD. De plus, je n'ai trouvé nul part d'informations sur la raison de l'indisponibilité de ce site la nuit... rien ne dit que c'est dû à PostgreSQL.
Guillaume.
Hors ligne
