quarta-feira, 1 de janeiro de 2014

A DBA MySQL olha para PostgreSQL part3 PostgreSQL Para MySQL

Original post: http://anothermysqldba.blogspot.com/2014/01/a-mysql-dba-looks-at-postgresql-part3.html

Então, eu recentemente postou: Um DBA MySQL olha para o PostgreSQL e parte 2: MySQL para PostgreSQL .

Este post vai explorar a migração do PostgreSQL para MySQL . Mais uma vez, o objetivo de longo prazo com essas mensagens devem ser mostrar capaz como os dados funciona dentro das diferentes bases de dados, bem como a forma de resolver problemas semelhantes em cada banco de dados quando deve surgir exemplos.

MySQL empurra o MySQL Workbench a ferramenta de migração de dados. Eu tenho que admitir que eu sou curioso porque o MySQL Utilities não fornece uma opção de linha de comando. O post anterior ( parte 2 ) mostrou como é fácil a migração via linha de comando foi para MySQL para PostgreSQL . Tenha em mente que ao trazer os dados para MySQL ao motor de dados tem de ser considerado.

Para colocá-lo simplesmente, se você estiver indo para trazer dados de volta para MySQL doPostgreSQL uma opção rápida é provável que o MySQL Workbench . Mas isso não é uma solução global, uma vez que muitas vezes preferem ficar dentro de nossas janelas de terminal. Assim, você estará fazendo o seguinte:
  • Despejar o esquema do PostgreSQL em um arquivo
    • Rever e editar o arquivo para MySQL.
  • Por esquema e tabelas desejado exportar como um arquivo CSV.
  • Importação de volta para MySQL

De qualquer forma, primeiro temos ainda os dados em PostgreSQL a partir do banco de dados Mundial exemplo.

world=> \dt
List of relations
Schema | Name | Type | Owner
--------+-----------------+-------+----------
public | city | table | testuser
public | country | table | testuser
public | countrylanguage | table | testuser
(3 rows)

world=> select count(ID) from City;
count
-------
4079
(1 row)

world=> 


Despejar o esquema:

$ pg_dump -s world > world_schema.pgsql 


Usando pg_dump tomar o - somente dados e - Insere simplesmente construir arquivo SQL padrão de dados.

pg_dump --data-only --inserts world > world_data.pgsql 

Você verá mais tarde que fazer um depósito de acordo com a tabela seria melhor, mas isso funciona.

Criando um banco de dados em MySQL para colocar os dados de volta, bem como testar seu novo esquema.

mysql> CREATE DATABASE world_back;
Query OK, 1 row affected (0.01 sec) 


Edite seu arquivo de esquema: vi world_schema.pgsql
Você tem o novo banco de dados MySQL criado para que você possa testá-los como você vai.


CREATE TABLE city (
id integer DEFAULT nextval('city_id_seq'::regclass) NOT NULL,
name character(35) DEFAULT ''::bpchar NOT NULL,
countrycode character(3) DEFAULT ''::bpchar NOT NULL,
district character(20) DEFAULT ''::bpchar NOT NULL,
population integer DEFAULT 0 NOT NULL
);

CREATE TABLE country (
code character(3) DEFAULT ''::bpchar NOT NULL,
name character(52) DEFAULT ''::bpchar NOT NULL,
continent character varying DEFAULT 'Asia'::character varying NOT NULL,
region character(26) DEFAULT ''::bpchar NOT NULL,
surfacearea double precision DEFAULT 0::double precision NOT NULL,
indepyear smallint,
population integer DEFAULT 0 NOT NULL,
lifeexpectancy double precision,
gnp double precision,
gnpold double precision,
localname character(45) DEFAULT ''::bpchar NOT NULL,
governmentform character(45) DEFAULT ''::bpchar NOT NULL,
headofstate character(60) DEFAULT NULL::bpchar,
capital integer,
code2 character(2) DEFAULT ''::bpchar NOT NULL,
CONSTRAINT country_continent_check CHECK (((continent)::text = ANY ((ARRAY['Asia'::character varying, 'Europe'::character varying, 'North America'::character varying, 'Africa'::character varying, 'Oceania'::character varying, 'Antarctica'::character varying, 'South America'::character varying])::text[])))
);
ALTER TABLE ONLY city
ADD CONSTRAINT city_pkey PRIMARY KEY (id);

CREATE INDEX city_countrycode_idx ON city USING btree (countrycode); 


Você terá que analisar o arquivo para todas as chaves relacionadas para que você possa criar declarações válidas.
Você precisa entender MySQL, assim você pode criar instruções CREATE TABLE válidas.


CREATE TABLE city (
`id` int(11) NOT NULL AUTO_INCREMENT,
`name` char(35) NOT NULL DEFAULT '',
`countrycode` char(3) NOT NULL DEFAULT '',
`district` char(20) NOT NULL DEFAULT '',
`population` int(11) NOT NULL DEFAULT '0',
PRIMARY KEY (`id`)
);

CREATE TABLE `country` (
`code` char(3) NOT NULL DEFAULT '',
`name` char(52) NOT NULL DEFAULT '',
`continent` char(5) NOT NULL DEFAULT '',
`region` char(26) NOT NULL DEFAULT '',
`surfaceArea` float(10,2) NOT NULL DEFAULT '0.00',
`indepyear` smallint(6) DEFAULT NULL,
`population` int(11) NOT NULL DEFAULT '0',
`lifeexpectancy` float(3,1) DEFAULT NULL,
`gnp` float(10,2) DEFAULT NULL,
`gnpold` float(10,2) DEFAULT NULL,
`localname` char(45) NOT NULL DEFAULT '',
`governmentform` char(45) NOT NULL DEFAULT '',
`headofstate` char(60) DEFAULT NULL,
`capital` int(11) DEFAULT NULL,
`code2` char(2) NOT NULL DEFAULT '',
PRIMARY KEY (`code`)
); 

É claro que é até você. mas uma vez que você trabalha fora da chave primária por tabela, eu iria criar instruções alter para atualizar os novos esquemas para que você possa garantir que você pegar tudo. Enquanto eles podem ser adicionados diretamente para a primeira declaração Criar em sua maior parte como você processar o arquivo de despejo Postgresql fazer altera pode mantê-lo sob controle.

Alguns exemplos das declarações Alter necessários:

ALTER TABLE city ENGINE=InnoDB;
ALTER TABLE country ENGINE=InnoDB;
ALTER TABLE countrylanguage ENGINE=InnoDB;

ALTER TABLE country DROP continent;
ALTER TABLE country ADD continent enum('Asia','Europe','North America','Africa','Oceania','Antarctica','South America') NOT NULL DEFAULT 'Asia' AFTER name;

ALTER TABLE city ADD KEY `countrycode` (`countrycode`),
ALTER TABLE city ADD CONSTRAINT `city_ibfk_1` FOREIGN KEY (`countrycode`) REFERENCES `country` (`code`) 


Uma vez que todo o esquema é atualizado e válido. você pode colocar os dados salvos de volta.

vi world_data.pgsql to remove the SET statements at the top.
--
-- PostgreSQL database dump
--

SET statement_timeout = 0;
SET lock_timeout = 0;
SET client_encoding = 'UTF8';
SET standard_conforming_strings = on;
SET check_function_bodies = false;
SET client_min_messages = warning;

SET search_path = public, pg_catalog; 

Copie os arquivos para fora por tabela, neste caso, por causa das restrições. Editar em conformidade para cada arquivo só tem os dados por tabela. Eu deveria ter despejado assim ou simplesmente despejar novamente por tabela.

$ cp world_data.pgsql world_data_city.pgsql
$ cp world_data.pgsql world_data_countrylanguage.pgsql
$ cp world_data.pgsql world_data_country.pgsql

$ mysql -u root -p world_back < world_data_country.pgsql
Enter password:
$ mysql -u root -p world_back < world_data_countrylanguage.pgsql
Enter password:
$ mysql -u root -p world_back < world_data_city.pgsql 


Então, basta colocá-lo não é tão fácil, eu diria automatizada, a migrar para o MySQL via linha de comando por causa das mudanças de esquema que vai exigir sua atenção, mas isso pode ser feito. 

mysql> select count(id) from city;
+-----------+
| count(id) |
+-----------+
| 4079 |
+-----------+
1 row in set (0.14 sec)

MySQL Workbench banco de dados de migração, claro, pode fazer o mesmo processo e você pode aprender mais sobre essa ferramenta aqui -http://www.mysql.com/products/workbench/migrate/