Vous n'êtes pas identifié(e).

#1 02/10/2013 12:20:47

ruizsebastien
Membre

[RESOLU] DDL sur tables volumineuses pour application 24/7

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

#2 02/10/2013 21:10:37

gleu
Administrateur

Re : [RESOLU] DDL sur tables volumineuses pour application 24/7

En dehors de la clause CONCURRENTLY pour le CREATE INDEX, je ne vois pas.


Guillaume.

Hors ligne

#3 03/10/2013 11:39:43

ruizsebastien
Membre

Re : [RESOLU] DDL sur tables volumineuses pour application 24/7

Bonjour,

Est-ce qu'un système de réplication est envisageable pour ce cas particulier ?


Cordialement,

Sébastien.

Hors ligne

#4 03/10/2013 20:16:15

gleu
Administrateur

Re : [RESOLU] DDL sur tables volumineuses pour application 24/7

Là, il va falloir être plus précis. Je ne vois vraiment pas le lien entre réplication et DDL bloquante ??


Guillaume.

Hors ligne

#5 04/10/2013 10:23:47

ruizsebastien
Membre

Re : [RESOLU] DDL sur tables volumineuses pour application 24/7

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

#6 04/10/2013 10:57:13

kenrio
Membre

Re : [RESOLU] DDL sur tables volumineuses pour application 24/7

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

#7 04/10/2013 11:20:15

ruizsebastien
Membre

Re : [RESOLU] DDL sur tables volumineuses pour application 24/7

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

#8 04/10/2013 14:21:43

gleu
Administrateur

Re : [RESOLU] DDL sur tables volumineuses pour application 24/7

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

#9 04/10/2013 16:54:07

ruizsebastien
Membre

Re : [RESOLU] DDL sur tables volumineuses pour application 24/7

merci pour ta réponse, ça va m'aider à faire passer le message.


Cordialement,

Sébastien.

Hors ligne

#10 06/10/2013 12:27:17

SQLpro
Membre

Re : [RESOLU] DDL sur tables volumineuses pour application 24/7

ruizsebastien a écrit :

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

#11 06/10/2013 18:35:29

gleu
Administrateur

Re : [RESOLU] DDL sur tables volumineuses pour application 24/7

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

Pied de page des forums