Postgres

PostgreSQL 10 et la réplication logique – Restrictions

Cet article est la suite d’une série d’articles sur la réplication logique dans la version 10 de PostgreSQL Celui-ci va porter sur les restrictions de la réplication logique.

PostgreSQL 10 et la réplication logique – Mise en oeuvre

Cet article est la suite d’une série d’articles sur la réplication logique dans la version 10 de PostgreSQL Celui-ci va porter sur la mise en œuvre de la réplication logique.

PostgreSQL 10 et la réplication logique – Fonctionnement

Certains d’entre vous sont déjà au courant, la nouvelle version majeure de PostgreSQL approche à grands pas. Elle devrait sortir dans le courant du mois de septembre. Comme chaque nouvelle version la liste de nouveautés est assez impressionnante : partitionnement amélioration des performances sur les tris et fonctions d’agrégation extension du parallélisme : parcours d’index parallélisé, jointure parallélisée, parallélisation des sous-requêtes… statistiques étendues support des collations ICU : va permettre d’exploiter les « abbreviated keys » qui avaient dû être désactivées en 9.5 à cause d’un bug dans la libc. Les « abbreviated keys » permettaient un gain de l’ordre de 20-30% sur les tris et créations d’index. et je m’arrête là, vous pouvez avoir un aperçu des nouveautés sur la page wiki ou dans les releases notes. Une grande nouveauté de la version 10 que je vais présenter dans une série d’articles est la réplication logique.

PostgreSQL : Retarder la vérification des contraintes

Retarder la vérification des contraintes Remarque : Cet article a été rédigé durant le cadre de mon activité chez Dalibo] Postgres respecte le modèle ACID, ainsi il garantie la cohérence de la base : une transaction amène la base d’un état stable à un autre. Les données dans les différentes tables ne sont pas indépendantes mais obéissent à des règles sémantiques mises en place au moment de la conception du modèle conceptuel des données. Les contraintes d’intégrité ont pour principal objectif de garantir la cohérence des données entre elles, et donc de veiller à ce qu’elles respectent ces règles sémantiques. Si une insertion, une mise à jour ou une suppression viole ces règles, l’opération est purement et simplement annulée. Le moteur effectue la vérification des contraintes à chaque modification (lorsque des contraintes ont été définies). Il est également possible de retarder la vérification des contraintes à la fin de la transaction, au moment du commit. Ainsi, les vérifications ne seront produites que sur les changements effectifs entre les opérations de delete, update et insert de la transaction.

Index BRIN – Performances

La version 9.5 de PostgreSQL sortie en Janvier 2016 propose un nouveau type d’index : les Index BRIN pour Bloc Range INdex. Ces derniers sont recommandés pour les tables volumineuses et corrélées avec leur emplacement. J’ai décidé de consacrer une série d’article sur ces index : Index BRIN - Principe Index BRIN - Fonctionnement Index BRIN - Corrélation Index BRIN - Performances Pour information, je serai présent au PGDay France à Lille le mardi 31 mai pour présenter cet index. Il y aura également plein d’autres conférences intéressantes! Cet article est la dernier de la série, il sera consacré aux performances (maintenance, lecture, insertion…)

Index BRIN – Corrélation

La version 9.5 de PostgreSQL sortie en Janvier 2016 propose un nouveau type d’index : les Index BRIN pour Bloc Range INdex. Ces derniers sont recommandés pour les tables volumineuses et corrélées avec leur emplacement. J’ai décidé de consacrer une série d’article sur ces index : Index BRIN - Principe Index BRIN - Fonctionnement Index BRIN - Corrélation Index BRIN - Performances Pour information, je serai présent au PGDay France à Lille le mardi 31 mai pour présenter cet index. Il y aura également plein d’autres conférences intéressantes! Dans ce troisième article nous verrons pourquoi la corrélation des données avec leur emplacement est importante pour les index BRIN.

Index BRIN – Fonctionnement

La version 9.5 de PostgreSQL sortie en Janvier 2016 propose un nouveau type d’index : les Index BRIN pour Bloc Range INdex. Ces derniers sont recommandés pour les tables volumineuses et corrélées avec leur emplacement. J’ai décidé de consacrer une série d’article sur ces index : Index BRIN - Principe Index BRIN - Fonctionnement Index BRIN - Corrélation Index BRIN - Performances Pour information, je serai présent au PGDay France à Lille le mardi 31 mai pour présenter cet index. Il y aura également plein d’autres conférences intéressantes! Dans ce 2eme volet nous allons voir en détail le fonctionnement d’un index BRIN.

Index BRIN – Principe

La version 9.5 de PostgreSQL sortie en Janvier 2016 propose un nouveau type d’index : les Index BRIN pour Bloc Range INdex. Ces derniers sont recommandés pour les tables volumineuses et corrélées avec leur emplacement. J’ai décidé de consacrer une série d’article sur ces index : Index BRIN - Principe Index BRIN - Fonctionnement Index BRIN - Corrélation Index BRIN - Performances Pour information, je serai présent au PGDay France à Lille le mardi 31 mai pour présenter cet index. Il y aura également plein d’autres conférences intéressantes!

Partition xlogs pleine

Cette semaine j’ai été confronté à un incident sur une instance postgres. La partition xlogs était pleine : PANIC: could not write to file "pg_xlog/xlogtemp.12352": No space left on device LOG: startup process (PID 12352) was terminated by signal 6: Aborted LOG: aborting startup due to startup process failure Cette instance est répliquée sur un autre serveur et archive ses journaux de transaction sur un troisième serveur. Ce dernier était plein, Postgres est intelligent et a conservé ses journaux de transaction en attendant de pouvoir les archiver… Jusqu’à ce que la partition des journaux se retrouve pleine entraînant l’arrêt de Postgres.

Restauration PITR – Part 7

Je profite d’un week end de mauvais temps (m’empêchant de retourner en falaise 🙁 ) pour poursuivre mes articles sur Postgres. Dans le précédent article : Backup, restauration - Part 6 J’ai évoqué la restauration PITR pour Point In Time Recovery. Je vous encourage vivement à mettre en place ce qui va suivre afin de réduire la perte de données en cas de modification accidentelle sur des enregistrements : Un drop table par exemple.