Mysql
 sql >> Base de données >  >> RDS >> Mysql

Migration de MySQL vers PostgreSQL - Ce que vous devez savoir

Qu'il s'agisse de migrer une base de données ou un projet de MySQL vers PostgreSQL, ou de choisir PostgreSQL pour un nouveau projet avec uniquement des connaissances MySQL, il y a quelques choses à savoir sur PostgreSQL et les différences entre les deux systèmes de base de données.

PostgreSQL est un système de base de données entièrement open source publié sous sa propre licence, la licence PostgreSQL, qui est décrite comme "une licence Open Source libérale, similaire aux licences BSD ou MIT". Cela a permis au PostgreSQL Global Development Group (communément appelé PGDG), qui développe et maintient le projet open source, d'améliorer le projet avec l'aide de personnes du monde entier, le transformant en l'une des solutions de base de données les plus stables et les plus riches en fonctionnalités. Aujourd'hui, PostgreSQL est en concurrence avec les meilleurs systèmes de bases de données propriétaires et open source en termes de fonctionnalités, de performances et de popularité.

PostgreSQL est un système de base de données relationnelle hautement conforme, évolutif, personnalisable et doté d'une communauté dynamique de personnes qui l'améliorent chaque jour.

Ce dont PostgreSQL a besoin

Dans un blog précédent, nous avons discuté de la configuration et de l'optimisation de PostgreSQL pour un nouveau projet. C'est une bonne introduction à la configuration et au comportement de PostgreSQL, et peut être trouvé ici :https://severalnines.com/blog/setting-optimal-environment-postgresql.

Si vous migrez une application de MySQL vers PostgreSQL, le meilleur point de départ serait de l'héberger sur un matériel ou une plate-forme d'hébergement similaire à la base de données MySQL source.

Sur site

Si vous hébergez la base de données sur site, les hôtes bare metal (plutôt que les machines virtuelles) sont généralement la meilleure option pour héberger PostgreSQL. Les machines virtuelles ajoutent parfois des fonctionnalités utiles, mais elles se font au prix d'une perte de puissance et de performances de l'hôte en général, tandis que le métal nu permet au logiciel PostgreSQL d'avoir un accès complet aux performances avec moins de couches entre lui et le matériel. Les hôtes sur site auraient besoin d'un administrateur pour gérer les bases de données, qu'il s'agisse d'un employé à temps plein ou d'un sous-traitant, selon ce qui convient le mieux aux besoins de l'application.

Dans le Cloud

L'hébergement cloud a parcouru un long chemin au cours des dernières années et d'innombrables entreprises à travers le monde hébergent leurs bases de données sur des serveurs basés sur le cloud. Étant donné que les hôtes cloud sont hautement configurables, la bonne taille et la bonne puissance d'hôte peuvent être sélectionnées pour les besoins spécifiques de la base de données, avec un coût qui correspond.

Selon l'option d'hébergement utilisée, de nouveaux hôtes peuvent être provisionnés rapidement, la mémoire / le processeur / le disque peuvent être modifiés rapidement et même des méthodes de sauvegarde supplémentaires peuvent être disponibles. Lorsque vous choisissez un hôte cloud, recherchez si un hôte est dédié ou partagé, le dédié étant préférable pour les bases de données à charge extrêmement élevée. Une autre clé consiste à s'assurer que les IOPS disponibles pour l'hôte cloud sont suffisamment bonnes pour les besoins de l'activité de la base de données. Même avec un grand pool de mémoire pour PostgreSQL, il y aura toujours des opérations de disque pour écrire des données sur le disque ou récupérer des données lorsqu'elles ne sont pas en mémoire.

Services infonuagiques

Étant donné que PostgreSQL gagne en popularité, il est disponible sur de nombreux services d'hébergement de bases de données cloud comme Heroku, Amazon AWS et autres, et rattrape rapidement la popularité de MySQL. Ces services permettent à un tiers d'héberger et de gérer facilement une base de données PostgreSQL, ce qui permet de rester concentré sur l'application.

Concepts / comparaisons de termes

Il y a quelques comparaisons à couvrir lors de la migration de MySQL vers PostgreSQL, des paramètres de configuration courants, des termes ou des concepts qui fonctionnent de manière similaire mais qui ont leurs différences.

Termes de la base de données

Divers termes de base de données peuvent avoir des significations différentes dans différentes implémentations de la technologie. Entre MySQL et PostgreSQL, il y a quelques termes de base qui sont compris légèrement différemment, donc une traduction est parfois nécessaire.

"Groupe"

Dans MySQL, un « cluster » fait généralement référence à plusieurs hôtes de base de données MySQL connectés ensemble pour apparaître comme une seule base de données ou un ensemble de bases de données aux clients.

Dans PostgreSQL, lors du référencement d'un "cluster", il s'agit d'une seule instance en cours d'exécution du logiciel de base de données et de tous ses sous-processus, qui contient alors une ou plusieurs bases de données.

"Base de données"

Dans MySQL, les requêtes peuvent accéder aux tables de différentes bases de données en même temps (à condition que l'utilisateur ait l'autorisation d'accéder à chaque base de données).

SELECT *
FROM customer_database.customer_table t1
JOIN orders_database.order_table t2 ON t1.customer_id = t2.customer_id
WHERE name = ‘Bob’;

Cependant, dans PostgreSQL, cela ne peut se produire que si vous utilisez des wrappers de données étrangères (un sujet pour une autre fois). Au lieu de cela, une base de données PostgreSQL a la possibilité d'utiliser plusieurs "schémas" qui fonctionnent de la même manière que les bases de données dans MySQL. Les schémas contiennent les tables, les index, etc., et sont accessibles simultanément par la même connexion à la base de données qui les héberge.

SELECT *
FROM customer_schema.customer_table t1
JOIN orders_schema.order_table t2 ON t1.customer_id = t2.customer_id
WHERE name = ‘Bob’;

Interfaçage avec PostgreSQL

Dans le client en ligne de commande MySQL (mysql), l'interfaçage avec la base de données utilise des clés telles que 'DESCRIBE table' ou 'SHOW TABLES'. Le client de ligne de commande PostgreSQL (psql) utilise sa propre forme de "commandes antislash". Par exemple, au lieu de « SHOW TABLES », la commande de PostgreSQL est « \dt », et au lieu de « SHOW DATABASES ; », la commande est « \l ».

Une liste complète des commandes pour 'psql' peut être trouvée par la commande antislash '\?' dans psql.

Assistance linguistique

Comme MySQL, PostgreSQL possède des bibliothèques et des plugins pour tous les principaux langages, ainsi que des pilotes ODBC du type MySQL et Oracle. Trouver une bonne bibliothèque stable pour n'importe quelle langue est une tâche facile.

Procédures stockées

Contrairement à MySQL, PostgreSQL propose une large gamme de langages procéduraux pris en charge. Dans l'installation de base de PostgreSQL, les langages pris en charge sont PL/pgSQL (SQL Procedural Language), PL/Tcl (Tcl Procedural Language), PL/Perl (Perl Procedural Language) et PL/Python (Python Procedural Language). Les développeurs tiers peuvent avoir plus de langages non officiellement pris en charge par le groupe PostgreSQL principal.

Configuration

  • Mémoire

    MySQL règle cela avec key_buffer_size lors de l'utilisation de MyISAM, et avec innodb_buffer_pool_size lors de l'utilisation d'InnoDB.

    PostgreSQL utilise shared_buffers pour le bloc de mémoire principal attribué à la base de données pour la mise en cache des données, et conserve généralement environ 1/4 de la mémoire système à moins que certains scénarios ne nécessitent que cela change. Les requêtes utilisant la mémoire pour le tri utilisent la valeur work_mem, qui doit être augmentée avec précaution.

Outils de migration

La migration vers PostgreSQL peut demander du travail, mais la communauté a développé des outils pour faciliter le processus. Généralement ils vont convertir/migrer les données de MySQL vers PostgreSQL, et recréer des tables/index. Les procédures stockées ou les fonctions sont une autre histoire et nécessitent généralement une réécriture manuelle en partie ou à partir de zéro.

Certains exemples d'outils disponibles sont pgloader et FromMySqlToPostgreSql. Pgloader est un outil écrit en Common Lisp qui importe des données de MySQL dans PostgreSQL à l'aide de la commande COPY et charge des données, des index, des clés étrangères et des commentaires avec conversion de données pour représenter correctement les données dans PostgreSQL comme prévu. FromMySqlToPostgreSql est un outil similaire écrit en PHP et peut convertir les types de données MySQL en PostgreSQL ainsi que les clés étrangères et les index. Les deux outils sont gratuits, mais de nombreux autres outils (gratuits et payants) existent et sont nouvellement développés au fur et à mesure que de nouvelles versions de chaque logiciel de base de données sont publiées.

La conversion doit toujours inclure une évaluation approfondie après la migration pour s'assurer que les données ont été correctement converties et que la fonctionnalité fonctionne comme prévu. Les tests préalables sont toujours encouragés pour les délais et la validation des données.

Options de réplication

Si vous venez de MySQL où la réplication a été utilisée, ou si la réplication est nécessaire pour une raison quelconque, PostgreSQL a plusieurs options disponibles, chacune avec ses propres avantages et inconvénients, selon ce qui est nécessaire via la réplication.

  • Intégré :

    Par défaut, PostgreSQL possède son propre mode de réplication intégré pour la récupération ponctuelle (PITR). Cela peut être configuré à l'aide de l'envoi de journaux basé sur des fichiers, où les fichiers de journaux en écriture anticipée sont envoyés à un serveur de secours où ils sont lus et relus, ou de la réplication en continu, où un serveur de secours en lecture seule récupère les journaux de transactions via une connexion à une base de données pour les relire. eux.

    L'une ou l'autre de ces options intégrées peut être configurée en tant que « veille à chaud » ou « veille à chaud ». Une « veille à chaud » n'autorise pas les connexions mais est prête à devenir un maître à tout moment pour remplacer un maître ayant des problèmes. . Un "hot standby" permet aux connexions en lecture seule de se connecter et d'émettre des requêtes, en plus d'être prêt à devenir un maître en lecture/écriture à tout moment également si nécessaire.

  • Slony :

    L'un des plus anciens outils de réplication pour PostgreSQL est Slony, qui est une méthode de réplication basée sur des déclencheurs qui permet un haut niveau de personnalisation. Slony permet la configuration d'un nœud maître et de n'importe quel nombre de nœuds de réplique, et la possibilité de basculer le maître vers n'importe quel nœud souhaité, et permet à l'administrateur de choisir les tables (s'il ne veut pas toutes les tables) à répliquer. Il a été utilisé non seulement pour répliquer des données en cas de panne/d'équilibrage de charge, mais également pour envoyer des données spécifiques à d'autres services, ou même pour des mises à niveau avec des temps d'arrêt minimaux, car la réplication peut passer par différentes versions de PostgreSQL.

    Slony a pour exigence principale que chaque table à répliquer ait soit une CLÉ PRIMAIRE, soit un index UNIQUE sans colonnes nullables.

  • Bucard :

    En ce qui concerne les options multi-maîtres, Bucardo est l'un des rares pour PostgreSQL. Comme Slony, il s'agit d'un progiciel tiers qui repose sur PostgreSQL. Bucardo s'appelle "un système de réplication PostgreSQL asynchrone, permettant à la fois des opérations multi-maîtres et multi-esclaves". Le principal avantage est la réplication multimaître, qui fonctionne assez bien, mais elle manque de résolution de conflits, les applications doivent donc être conscientes des problèmes possibles et les corriger en conséquence.

    Il existe également de nombreux autres outils de réplication, et trouver celui qui convient le mieux à une application dépend des besoins spécifiques.

Téléchargez le livre blanc aujourd'hui PostgreSQL Management &Automation with ClusterControlDécouvrez ce que vous devez savoir pour déployer, surveiller, gérer et faire évoluer PostgreSQLTélécharger le livre blanc

Communauté

PostgreSQL a une communauté florissante prête à aider avec tous les problèmes / informations qui pourraient être nécessaires.

  • IRC

    Une salle de discussion IRC active nommée #postgresql est disponible sur freenode, car les administrateurs et les développeurs du monde entier discutent de PostgreSQL et des projets/problèmes associés. Il existe des salles encore plus petites pour des spécificités telles que Slony, Bucardo, etc.

  • Listes de diffusion

    Il existe une poignée de listes de diffusion PostgreSQL pour "général", "admin", "performance" et même "novice" (un excellent point de départ si vous êtes nouveau sur PostgreSQL en général). Les listes de diffusion sont abonnées à de nombreuses personnes dans le monde et fournissent une multitude de ressources très utiles pour répondre à toute question qui pourrait nécessiter une réponse.

    Une liste complète des listes de diffusion PostgreSQL est disponible sur https://www.postgresql.org/list/

  • Groupes d'utilisateurs

    Les groupes d'utilisateurs sont un endroit idéal pour s'impliquer et être actifs dans la communauté, et de nombreuses grandes villes du monde ont un groupe d'utilisateurs PostgreSQL (PUG) disponible pour rejoindre et participer, et si ce n'est pas le cas, envisagez d'en créer un. Ces groupes sont parfaits pour le réseautage, l'apprentissage de nouvelles technologies et même simplement pour poser des questions en personne à des personnes de tous niveaux d'expérience.

  • Documents

    Plus important encore, PostgreSQL est très bien documenté. Toutes les informations sur les paramètres de configuration, les fonctions SQL, l'utilisation, tout peut être facilement appris grâce à la documentation officielle fournie sur le site Web de PostgreSQL. Si quelque chose n'est pas clair, la communauté vous aidera dans les options décrites précédemment.