Re: un ou plusieurs clusters

William Dode a écrit :
> On 17-10-2008, Guillaume Lelarge wrote:
>> William Dode a écrit :
>>> On 17-10-2008, Guillaume Lelarge wrote:
>>>> William Dode a écrit :
>>>>> [...]
>>>>> J'ai plusieurs (une dizaine) de bases, très modestes, qui concernent des
>>>>> applications (les miennes) complètement indépendantes sur le même
>>>>> serveur. Actuellement toutes sur le même cluster.
>>>>>
>>>>> Récemment j'ai bossé pas mal sur les bases elles-mêmes et pour ça j'ai
>>>>> utilisé plusieurs clusters, j'ai trouvé ça assez pratique.
>>>>>
>>>> Pourquoi pratique ? j'ai quelques clients qui me disent la même chose
>>>> mais aucun n'arrive à expliquer en quoi c'est réellement pratique.
>>> Pratique pour la maintenance, par exemple configurer différemment le
>>> log_shipping, le détail des logs, arrêter un cluster, le déplacer sur un
>>> autre serveur etc.
>>>
>> Mouais. En dehors du logshipping (et encore...), je ne suis pas convaincu.
>
> Par exemple si j'ai un problème sur une base et que je veux logger les
> connexions, les requetes, les stats etc... Si j'ai plusieurs bases qui
> tournent c'est impossible à lire.
>

Avec le bon log_line_prefix (%d pour la base... c'est de tête, ne pas
m'en vouloir si ce n'est pas ça :) ), c'est tout à fait jouable. Par
contre, question perfs, c'est clair que ça devient ravageur pour une
instance qui a plusieurs bases de données.

>>> Ce que je fais déjà c'est que sur chaque serveur et sur ma machine de
>>> dev j'ai en réplication les clusters des autres serveurs. Juste pour
>>> backup ou faire des tests.
>>>
>> Tu répliques tous les clusters de tous les serveurs ? à quoi sert
>> d'avoir une base par instance dans ce cas ?
>
> Justement pour que ce soit plus souple. Par exemple lorsque je travaille
> sur une appli en particulier je n'ai pas besoin de rapatrier toutes les
> bases.
>

OK pour un développeur qui doit tester une base.

>>[...]
>> Tu as eu quelques types de problèmes ? tu crains quoi ? (comme tu le
>> dis, c'est pas forcément la même chose)
>
> J'ai eu des corruptions d'index sur pg7.4 par ex.
> En pratique jamais grave. Je disais "ça sonne" dans le sens où c'est un
> vieux réflexe de séparer les choses.
>

À ce niveau-là, on pourrait mettre un fichier par disque :)

Je comprends tes craintes. D'un autre côté, tu n'es pas protégé d'une
corruption d'index avec du logshipping si la corruption vient de PostgreSQL.

>> [...]
>>>> Inconvénients :
>>>> * partage des ressources (notamment mémoire) entre les différentes
>>>> instances.
>>>> * risque de se trouver avec plusieurs checkpoints survenant en même
>>>> temps (ceci dit, chacun à moins à faire du coup)
>>>> * bien configurer son max_connections si on ne veut pas que son
>>>> work_mem se réduise à peau de chagrin
>>>>
>>>> Bref, principalement, tu devras porter une très grande attention à
>>>> l'utilisation des ressources mémoire et disque. Bon courage.
>>> C'est ce qui me fait peur, surtout que l'intérêt ne serait que très
>>> ponctuel dans mon cas.
>>>
>> Pour moi, les inconvénients l'emportent très largement sur les
>> avantages. Mais bon, ça n'empêche pas certains de le faire, et avec de
>> bonnes perfs.
>
> C'est ce qui me semble aussi au final, je vais regarder au cas par cas.
>

Qu'on soit bien d'accord.

Je prêche pour toutes les bases de données dans une instance pour des
raisons de perfs. Il est beaucoup plus simple de savoir d'où vient le
problème des perfs d'une base s'il n'y a qu'une instance sur le serveur
(physique). De plus, c'est aussi pour cela que je suis pour le fait
d'avoir un serveur de bases de données et un serveur applicatif séparé.
C'est aussi pour cela que je n'aime pas les serveurs virtualisés pour
les serveurs de production.

Par contre, je comprends très bien que des DBA ont confiance dans une
certaine façon de travailler, même si cela implique d'avoir une base par
instance et plusieurs instances par serveur physique. En sachant qu'au
prochain petit problème de performances, il faudra revoir toute la façon
de travailler.

Ce n'est que mon opinion :)

--
Guillaume.
http://www.postgresqlfr.org
http://dalibo.com