Mysql
 sql >> Base de Dados >  >> RDS >> Mysql

Migrando do MySQL para o PostgreSQL - O que você deve saber


Seja migrando um banco de dados ou projeto do MySQL para o PostgreSQL, ou escolhendo o PostgreSQL para um novo projeto com apenas conhecimento do MySQL, há algumas coisas a saber sobre o PostgreSQL e as diferenças entre os dois sistemas de banco de dados.

O PostgreSQL é um sistema de banco de dados totalmente de código aberto lançado sob sua própria licença, a Licença PostgreSQL, que é descrita como "uma licença liberal de código aberto, semelhante às licenças BSD ou MIT". Isso permitiu que o PostgreSQL Global Development Group (comumente referido como PGDG), que desenvolve e mantém o projeto de código aberto, melhorasse o projeto com a ajuda de pessoas de todo o mundo, transformando-o em uma das soluções de banco de dados mais estáveis ​​e ricas em recursos Hoje, o PostgreSQL compete com os principais sistemas de banco de dados proprietários e de código aberto por recursos, desempenho e popularidade.

O PostgreSQL é um sistema de banco de dados relacional altamente compatível, escalável, personalizável e com uma comunidade próspera de pessoas que o aprimoram todos os dias.

O que o PostgreSQL precisa


Em um blog anterior, discutimos a configuração e otimização do PostgreSQL para um novo projeto. É uma boa introdução à configuração e comportamento do PostgreSQL e pode ser encontrada aqui:https://severalnines.com/blog/setting-optimal-environment-postgresql.

Se estiver migrando um aplicativo do MySQL para o PostgreSQL, o melhor lugar para começar seria hospedá-lo em um hardware ou plataforma de hospedagem semelhante ao banco de dados MySQL de origem.

No Local


Se hospedar o banco de dados no local, os hosts bare metal (em vez de máquinas virtuais) geralmente são a melhor opção para hospedar o PostgreSQL. As máquinas virtuais adicionam alguns recursos úteis às vezes, mas têm o custo de perder energia e desempenho do host em geral, enquanto o bare metal permite que o software PostgreSQL tenha acesso total ao desempenho com menos camadas entre ele e o hardware. Os hosts locais precisariam de um administrador para manter os bancos de dados, seja um funcionário ou contratado em tempo integral, o que fizer mais sentido para as necessidades do aplicativo.

Na nuvem


A hospedagem em nuvem percorreu um longo caminho nos últimos anos, e inúmeras empresas em todo o mundo hospedam seus bancos de dados em servidores baseados em nuvem. Como os hosts em nuvem são altamente configuráveis, o tamanho e a potência corretos do host podem ser selecionados para as necessidades específicas do banco de dados, com um custo compatível.

Dependendo da opção de hospedagem usada, novos hosts podem ser provisionados rapidamente, memória/cpu/disco podem ser ajustados rapidamente e até métodos de backup adicionais podem estar disponíveis. Ao escolher um host de nuvem, verifique se um host é dedicado ou compartilhado, sendo o dedicado melhor para bancos de dados de carga extremamente alta. Outra chave é garantir que o IOPS disponível para o host de nuvem seja bom o suficiente para as necessidades de atividade do banco de dados. Mesmo com um grande pool de memória para o PostgreSQL, sempre haverá operações de disco para gravar dados no disco ou buscar dados quando não estiver na memória.

Serviços em nuvem


Como o PostgreSQL está aumentando em popularidade, ele está disponível em muitos serviços de hospedagem de banco de dados em nuvem, como Heroku, Amazon AWS e outros, e está alcançando rapidamente a popularidade do MySQL. Esses serviços permitem que um terceiro hospede e gerencie um banco de dados PostgreSQL facilmente, permitindo que o foco permaneça no aplicativo.

Conceitos/comparações de termos


Há algumas comparações a serem feitas ao migrar do MySQL para o PostgreSQL, parâmetros de configuração comuns, termos ou conceitos que operam de maneira semelhante, mas têm suas diferenças.

Termos do banco de dados


Vários termos de banco de dados podem ter significados diferentes em diferentes implementações da tecnologia. Entre MySQL e PostgreSQL, existem alguns termos básicos que são entendidos de forma ligeiramente diferente, então uma tradução às vezes é necessária.

“Agrupamento”


No MySQL, um 'cluster' geralmente se refere a vários hosts de banco de dados MySQL conectados juntos para aparecer como um único banco de dados ou conjunto de bancos de dados para clientes.

No PostgreSQL, ao referenciar um ‘cluster’, é uma única instância em execução do software de banco de dados e todos os seus subprocessos, que contém um ou mais bancos de dados.

"Banco de dados"


No MySQL, as consultas podem acessar tabelas de diferentes bancos de dados ao mesmo tempo (desde que o usuário tenha permissão para acessar cada banco de dados).
SELECT *
FROM customer_database.customer_table t1
JOIN orders_database.order_table t2 ON t1.customer_id = t2.customer_id
WHERE name = ‘Bob’;

No entanto, no PostgreSQL isso não pode acontecer, a menos que seja usado o Foreign Data Wrappers (um tópico para outro momento). Em vez disso, um banco de dados PostgreSQL tem a opção de vários 'esquemas' que operam de maneira semelhante aos bancos de dados no MySQL. Os esquemas contêm as tabelas, índices, etc, e podem ser acessados ​​simultaneamente pela mesma conexão com o banco de dados que os abriga.
SELECT *
FROM customer_schema.customer_table t1
JOIN orders_schema.order_table t2 ON t1.customer_id = t2.customer_id
WHERE name = ‘Bob’;

Interface com o PostgreSQL


No cliente de linha de comando MySQL (mysql), a interface com o banco de dados usa trabalhos de chave como 'DESCRIBE table' ou 'SHOW TABLES'. O cliente de linha de comando do PostgreSQL (psql) usa sua própria forma de ‘comandos de barra invertida’. Por exemplo, ao invés de ‘SHOW TABLES’, o comando do PostgreSQL é ‘\dt’, e ao invés de ‘SHOW DATABASES;’, o comando é ‘\l’.

Uma lista completa de comandos para 'psql' pode ser encontrada pelo comando de barra invertida '\?' dentro do psql.

Suporte a idiomas


Assim como o MySQL, o PostgreSQL possui bibliotecas e plugins para todas as principais linguagens, bem como drivers ODBC nos moldes do MySQL e Oracle. Encontrar uma biblioteca excelente e estável para qualquer linguagem necessária é uma tarefa fácil.

Procedimentos armazenados


Ao contrário do MySQL, o PostgreSQL tem uma ampla variedade de linguagens procedurais suportadas para escolher. Na instalação base do PostgreSQL, as linguagens suportadas são PL/pgSQL (SQL Procedural Language), PL/Tcl (Tcl Procedural Language), PL/Perl (Perl Procedural Language) e PL/Python (Python Procedural Language). Desenvolvedores de terceiros podem ter mais idiomas não suportados oficialmente pelo grupo principal do PostgreSQL.

Configuração


  • Memória

    O MySQL ajusta isso com key_buffer_size ao usar MyISAM, e com innodb_buffer_pool_size ao usar InnoDB.

    O PostgreSQL usa shared_buffers para o bloco de memória principal fornecido ao banco de dados para armazenar dados em cache e geralmente mantém cerca de 1/4 da memória do sistema, a menos que certos cenários exijam que isso seja alterado. As consultas que usam memória para classificação usam o valor work_mem, que deve ser aumentado com cautela.

Ferramentas para migração


Migrar para o PostgreSQL pode dar algum trabalho, mas existem ferramentas que a comunidade desenvolveu para ajudar no processo. Geralmente eles irão converter/migrar os dados do MySQL para o PostgreSQL, e recriar tabelas/índices. Stored Procedures ou funções são uma história diferente e geralmente exigem reescrita manual em parte ou do zero.

Algumas ferramentas de exemplo disponíveis são pgloader e FromMySqlToPostgreSql. Pgloader é uma ferramenta escrita em Common Lisp que importa dados do MySQL para o PostgreSQL usando o comando COPY e carrega dados, índices, chaves estrangeiras e comentários com conversão de dados para representar os dados corretamente no PostgreSQL conforme pretendido. FromMySqlToPostgreSql é uma ferramenta semelhante escrita em PHP e pode converter tipos de dados MySQL para PostgreSQL, bem como chaves e índices estrangeiros. Ambas as ferramentas são gratuitas, porém muitas outras ferramentas (gratuitas e pagas) existem e são desenvolvidas recentemente à medida que novas versões de cada software de banco de dados são lançadas.

A conversão deve sempre incluir uma avaliação detalhada após a migração para garantir que os dados foram convertidos corretamente e que a funcionalidade funcione conforme o esperado. Testes de antemão são sempre incentivados para tempos e validação de dados.

Opções de replicação


Se vier do MySQL onde a replicação foi usada, ou a replicação é necessária por qualquer motivo, o PostgreSQL tem várias opções disponíveis, cada uma com seus próprios prós e contras, dependendo do que é necessário através da replicação.

  • Incorporado:

    Por padrão, o PostgreSQL tem seu próprio modo de replicação integrado para Recuperação Point In Time (PITR). Isso pode ser configurado usando o envio de log baseado em arquivo, em que os arquivos de log de gravação antecipada são enviados para um servidor em espera, onde são lidos e reproduzidos, ou replicação de streaming, em que um servidor em espera somente leitura busca logs de transações em uma conexão de banco de dados para reprodução eles.

    Qualquer uma dessas opções incorporadas pode ser configurada como 'warm standby' ou 'hot standby'. . Um 'hot standby' permite conexões somente leitura para conectar e emitir consultas, além de estar pronto para se tornar um mestre de leitura/gravação a qualquer momento, se necessário.

  • Desleixado:

    Uma das ferramentas de replicação mais antigas do PostgreSQL é o Slony, que é um método de replicação baseado em trigger que permite um alto nível de customização. O Slony permite a configuração de um nó mestre e qualquer número de nós de réplica e a capacidade de alternar o mestre para qualquer nó desejado e permite que o administrador escolha quais tabelas (se não quiser todas as tabelas) replicar. Ele tem sido usado não apenas para replicar dados em caso de falha/balanceamento de carga, mas também para enviar dados específicos para outros serviços, ou até mesmo para atualizações mínimas de tempo de inatividade, pois a replicação pode passar por diferentes versões do PostgreSQL.

    O Slony tem o principal requisito de que cada tabela a ser replicada tenha uma PRIMARY KEY ou um índice UNIQUE sem colunas anuláveis.

  • Bucardo:

    Quando se trata de opções multi-mestre, o Bucardo é um dos poucos para o PostgreSQL. Como o Slony, é um pacote de software de terceiros que fica em cima do PostgreSQL. A Bucardo se autodenomina “um sistema de replicação assíncrona do PostgreSQL, permitindo operações multi-master e multi-slave”. O principal benefício é a replicação multi-mestre, que funciona razoavelmente bem, mas não tem resolução de conflitos, portanto, os aplicativos devem estar cientes dos possíveis problemas e corrigi-los adequadamente.

    Existem muitas outras ferramentas de replicação também, e encontrar aquela que funciona melhor para um aplicativo depende das necessidades específicas.
Baixe o whitepaper hoje PostgreSQL Management &Automation with ClusterControlSaiba o que você precisa saber para implantar, monitorar, gerenciar e dimensionar o PostgreSQLBaixe o whitepaper

Comunidade


O PostgreSQL tem uma comunidade próspera disposta a ajudar com quaisquer problemas/informações que possam ser necessárias.

  • IRC

    Uma sala de bate-papo IRC ativa chamada #postgresql está disponível no freenode, enquanto administradores e desenvolvedores conversam em todo o mundo sobre PostgreSQL e projetos / problemas relacionados. Há salas ainda menores para detalhes como Slony, Bucardo e muito mais.

  • Listas de e-mail

    Há um punhado de listas de discussão do PostgreSQL para 'geral', 'admin', 'desempenho' e até 'novato' (um ótimo lugar para começar se você é novo no PostgreSQL em geral). As listas de discussão são assinadas por muitos ao redor do mundo e fornecem uma riqueza de recursos muito útil para responder a qualquer pergunta que possa precisar de resposta.

    Uma lista completa de listas de discussão do PostgreSQL pode ser encontrada em https://www.postgresql.org/list/

  • Grupos de usuários

    Os grupos de usuários são um ótimo lugar para se envolver e ser ativo na comunidade, e muitas grandes cidades em todo o mundo têm um grupo de usuários do PostgreSQL (PUG) disponível para participar e participar e, se não, considere iniciar um. Esses grupos são ótimos para fazer networking, aprender novas tecnologias e até mesmo fazer perguntas pessoalmente a pessoas de qualquer nível de experiência.

  • Documentação

    Mais importante ainda, o PostgreSQL está muito bem documentado. Qualquer informação para parâmetros de configuração, funções SQL, uso, tudo pode ser facilmente aprendido através da documentação oficial fornecida no site do PostgreSQL. Se alguma coisa não estiver clara, a comunidade ajudará nas opções descritas anteriormente.