Vous n'êtes pas identifié(e).
Pages : 1
Bonjour tout le monde,
j'ai une replication en streaming entre 2 machines identiques:
PostgreSQL 9.2.6 on x86_64-unknown-linux-gnu, compiled by gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-3), 64-bit
MemTotal: 12198524 kB
cat /proc/cpuinfo | grep model | cut -c14-
Intel(R) Xeon(R) CPU X5670 @ 2.93GHz
Intel(R) Xeon(R) CPU X5670 @ 2.93GHz
Intel(R) Xeon(R) CPU X5670 @ 2.93GHz
Intel(R) Xeon(R) CPU X5670 @ 2.93GHz
FS pg_arch=17Go sur machine esclave.
FS pg_xlog= 17Go
Mon problème est: Pendant le chargement de la base "~12Go" pgloader crée un fichier temporaire puis il commence a faire l’insertion de donner. C'est dans cet étape que je commence à voir mon FS 'pg_arch' gonfler et se remplir puis le "pg_xlog" du maître jusqu’à que la réplication soit corrompu et puis ma base esclave et maître arrêté.
Ce que j'ai fait:
work_mem = 500MB
maintenance_work_mem = 1GB
autocommit = off
checkpoint_completion_target = 0.5
checkpoint_timeout = 15mina
temp_buffers = 100MB
Ces modifications on améliorées un peut la situation mais vers la fin il y a un crash aussi.
Questions:
1-Suis je obliger de couper la replication avant le chargement des données? (chose que je ne devrai pas faire car je suis susceptible de faire un chargement important via un batch la nuit).
2-J'ai eu l'expérience de charger des données plus importantes sans pgloader avec succès. Faut il faire qq chose avec pgloader vu que je ne maîtrise pas son fonctionnement?
3-Que fait mon "pg_archivecleanup" qui est bien renseigné dans "recovery.conf" alors que pg_arch arrive jusqu'a 100% de taux de remplissage (17Go)? peut on le forcer afin d'éviter le crash?
4-Est ce que tout simplement je suis passé à côté d'un paramètre et ou j'ai mal fait qq part?
Merci d'avance pour votre aide
Bonne fête de fin d'année à toutes et à tous
B.LEMJID
Hors ligne
1. Non.
2. Non, il faut juste avoir un système de fichiers suffisamment grand pour les journaux de transactions.
3. Il y a de fortes chances que l'esclave n'arrive pas à rejouer suffisamment vite, ce qui occasionne cette accumulation de journaux. Le forcer ne servira à rien si l'esclave est en retard.
4. La seule chose mal faite est le dimensionnement des partitions de journaux de transactions. Elles sont bien trop petites par rapport aux batchs que vous exécutez.
Guillaume.
Hors ligne
Bonjour Guillaume,
Merci beaucoup pour ta réponse.
Je suis vraiment étonné du fait que la taille du FS 'pg_xlog' et 'pg_arch' soient petits (17Go chacun). C'est juste une interrogation. Si ma base au final fera qq chose comme ~25-30 Go, pour le FS 'pg_data' pas de problème il faut juste prévoir plus que 30Go c.a.d 35 et plus. Mais pour les FS 'pg_xlog' et 'pg_arch' je suis incapable de dire ou d'estimer la taille adéquate.
Pour ne pas faire au (pif o mètre), tu pourras STP me dire ce que je dois mettre comme taille ou comment peut on faire une estimation?
Merci d'avance
Hors ligne
Je ne dis pas que 17 Go est petit en soi. Je dis par contre que 17Go est petit par rapport aux modifications réalisées par votre batch. Que votre base fasse 1 To ou 10 Mo ne change rien. Si vous modifiez 2 milliards de fois la même ligne, cela donnera 2 milliards d'enregistrements dans les journaux de transactions, et si l'esclave est trop lent, les journaux vont s'empiler. Quant à estimer la taille, c'est impossible. Ça dépend de ce que fait votre batch, ça dépend de votre configuration de PostgreSQL, etc.
À propos de configuration, que vaut le paramètre checkpoint_segments ? plus il est petit, plus on écrit dans les journaux. Du coup, il serait bien de l'augmenter (tout en évitant des valeurs trop grosses).
Guillaume.
Hors ligne
Merci encore,
Pour le paramètre checkpoint_segments je l'ai mis à 300. C'est un peut trop oui mais j'ai commencé par 60 et à chaque fois j'ai le message dans le log PostgreSQL me demandant de l'augmenter même à 200 du coup je l'ai mis à 300 et depuis plus de message. Est ce que c'est considéré comme valeur trop grosse?
Bien à toi
Hors ligne
En ayant le checkpoint_segments à 300, vous indiquez à PostgreSQL de conserver 900 journaux de transactions en temps normal. Et qu'il peut aller plus haut si nécessaire. 900 journaux réprésentent 14,4 Go d'espace disque. Je n'ai pas trop de mal à croire que vous remplissiez les 17 Go lors d'un batch avec cette configuration. Personnellement, je baisserais le checkpoint_segments.
Guillaume.
Hors ligne
J'avais indiqué que j'ai augmenté au fur et à mesure ce paramètre même à 200 j'avais un message m'invitant à l'augmenter. C'est la raison pour laquelle je suis arrivé à cette valeur. Je commence à m'inquieter.
Est ce que cette valeure est très haute?
Autour de combien tu me conseil de la mettre?
Merci d'avance
Hors ligne
Quel est ce message ? que vaut checkpoint_segments et checkpoint_warning lors de l'enregistrement de ce message ?
Guillaume.
Hors ligne
checkpoint_warning = 30s par défaut je n'ai pas touché. et checkpoint_segments j'ai commencé à 60, 80, 100, 150, 200 et puis 300. à 300 je n'ai plus le message mais avant oui.
Hors ligne
Ce qui veut dire que vous arrivez à créer 200 journaux en moins de 30 secondes. Plutôt impressionnant, et du coup pas étonnant que l'esclave ne suive pas. J'aimerais bien savoir ce que fait ce batch 
Guillaume.
Hors ligne
En gros c'est l'utilisation de ~6 fichiers '.csv'
1- 22567649 lignes comme ceci "3024820100000012230#9991000000000011176#GROLLIER#NATHALIE#2#24/10/1963#3#1#0182#09144#0#22/12/2001#04/06/2011#18/11/2013#IM"
2- 19146869 lignes comme ceci "3250390100133810089#10494#228#04/12/2013#20/12/2013 11:59:59"
3- 523444 lignes comme ceci "3250390040000617656#9996000000000009719#MULLIE#Roger#1#10/03/1930#3#1#3121#95001#0#28/06/2007#04/01/2011#13/11/2013#IB"
4- 19146869 lignes comme ceci "3250390100040682654#02132#641#03/12/2013#19/12/2013 11:59:59"
5- 2049939 lignes comme ceci "3250390240000002178#9994000000000072660#CARDOSO RAMOS#Monica Isabel#2#02/07/1980#3#1#2829#06301#0#06/06/2005#04/12/2012#13/11/2013#IP"
6- 1837191 lignes comme ceci "3250390260014507988#01820#0#18/07/2012#19/12/2013 11:59:59"
Donc une somme de ~"65271961" lignes.
Hors ligne
Pages : 1
