Percona NUBE HERRAMIENTAS

Original post: http://anothermysqldba.blogspot.com/2014/03/percona-cloud-tools.html

Así que me gusta mucho el hecho de que Percona es llegar y ofrecer soluciones para ayudar a analizar las preocupaciones o problemas con MySQL cloud.percona.com .

Es muy fácil de instalar. La forma más rápida es hacer que el repositorio YUM Percona instalado, tengo otro blog acerca de que si es necesario, por lo que tendrá la pt-agente instalado.

Esto se hace fácilmente, porque yo tenía un archivo my.cnf. Configurar para el usuario root, de lo contrario se tiene que configurar nombre de usuario y contraseña.

Acceda a cloud.percona.com primero y después ir a instalar el agente:


# pt-agent --install
Step 1 of 12: Verify the user is root: OK
Step 2 of 12: Check Perl module dependencies: OK
Step 3 of 12: Check for crontab: OK
Step 4 of 12: Verify pt-agent is not installed: OK
Step 5 of 12: Verify the API key:
Enter your API key: <API KEY HERE provided on the percona website>
Step 5 of 12: Verify the API key: OK
Step 6 of 12: Connect to MySQL: OK
Step 7 of 12: Check if MySQL is a slave: NO
Step 8 of 12: Create a MySQL user for the agent: OK
Step 9 of 12: Initialize /etc/percona/agent/my.cnf: OK
Step 10 of 12: Initialize /root/.pt-agent.conf: OK
Step 11 of 12: Create the agent: OK
Step 12 of 12: Run the agent: pt-agent has daemonized and is running as PID 16333:

--lib /var/lib/pt-agent
--log /var/log/pt-agent.log
--pid /var/run/pt-agent.pid

These values can change if a different configuration is received.
OK
INSTALLATION COMPLETE


Tan simple como eso .. A continuación, sólo tiene que entrar de nuevo en el sitio web Percona https://cloud.percona.com para habilitar y ajustar cualquiera de sus configuraciones de agente por sistema.

Déle unos 15 minutos para recoger la primera cantidad de datos y entonces usted está todo listo para tener datos en la punta de los dedos. Usted sólo haga clic en el botón "Query Analytics" en la página web.

Dependiendo de su rama de MySQL obtendrá diferentes análisis, obviamente Percona preferiría utilizar Percona Servidor 5.5.34 o superior, con sus herramientas, pero funciona con todas MySQL.

Una vez que su agente lo envió datos a Percona, usted será capaz de mostrar gráficos en el Resumen de servidores por cada cargo de consulta, tiempo de consulta, tiempo de bloqueo, filas enviadas, registros examinados, longitud de la consulta, así como la información proporcionada a través del perfil de la consulta.

"Filesort, filesort en el disco, se unen completo, Análisis completo, éxitos de la cache, tablas temporales, tablas temporales en el disco están disponibles sólo para Percona Server. " - cloud.percona.com

MySQL y OS X instalar y quitar

Original post: http://anothermysqldba.blogspot.com/2014/03/mysql-and-os-x-install-and-remove.html

Así que esto es en referencia a este error:

• http://bugs.mysql.com/bug.php?id=67133

Sucede que correr a través de él, así que pensé ¿qué diablos probar hacia fuera con 5.7 también.
También tuve la oportunidad de reproducir este error con la versión más reciente DMR. (En el momento de esta prueba mysql-5.7.3-m13) que estaba usando la proporcionada DMG y el archivo tar.gz.


dyld: Symbol not found: _strnlen
Referenced from: /usr/local/mysql/bin/my_print_defaults
Expected in: /usr/lib/libSystem.B.dylib

La DMG tiene un pequeño instalador y etc bonita, pero como se puede ver que no funcionaba.

Así que para probar la versión 5.5 tiene que quitar MySQL desde OS X


rm -rf /usr/local/mysql*
rm -rf /Library/StartupItems/MySQLCOM
rm -Rf /private/var/db/receipts/*mysql*

Yo sólo necesitaba esos pero este sitio tiene una lista de otras referencias, si lo necesita.

Tuve la oportunidad de confirmar que 5.5.36 Qué instalar y ejecutar. Por lo que son sólo de suerte por el momento si quieres una versión superior de MySQL.

Una nota .. Lea la pantalla de información o el archivo readme.txt. Proporciona información útil.


mysql> select @@hostname;
+----------------------+
| @@hostname |
+----------------------+
| MacBook-Pro-15.local |
+----------------------+
1 row in set (0.01 sec)

mysql> select VERSION();
+-----------+
| VERSION() |
+-----------+
| 5.5.36 |
+-----------+
1 row in set (0.00 sec)

Planificar el tiempo de inactividad de MySQL y de otras variables de estado para la crítica

Original post: http://anothermysqldba.blogspot.com/2014/03/planning-mysql-downtime-and-other.html

Todos sabemos que, si bien MySQL es estable y puede funcionar durante mucho tiempo sin que se reinicie. De vez en cuando tenemos que reiniciar para que ajustar algunas variables o para actualizar sin embargo. Algunos podrían suponer que durante la noche es el mejor momento para hacer esto debido a que sus usuarios están dormidos. Sin embargo, a menudo la noche a la mañana también incluye copias de seguridad y otras secuencias de comandos crontab relacionados que podrían estar haciendo diferentes minería de datos y etc

Entonces, ¿cómo se puede obtener una guía sobre cuando se tiene la menor actividad en el servidor? Ahora cada aplicación y la base de datos son diferentes, por lo que deben tener en cuenta lo que la actividad relacionada se está ejecutando, en los distintos marcos temporales. Si usted comienza a registrar la variable de estado "Threads_connected" cada minuto de 5 a 10 minutos, de nuevo esto depende de la carga del sistema es una vez por hora podría estar bien, no tardará en reunir la cantidad de diferentes conexiones de MySQL a través de su tiempo conectado marco.

Esto se puede hacer una numerosa maneras. Ya se proporciona en muchas herramientas a nivel de empresa y se puede escribir scripts y etc, pero sólo para mantenerlo en MySQL. Voy a utilizar un evento y de rutina para este sencillo ejemplo.

Crear una tabla simple:

CREATE TABLE `threads_count` (
`threads_count_id` int(11) NOT NULL AUTO_INCREMENT,
`variable_value` varchar(255) DEFAULT NULL,
`time_recorded` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
PRIMARY KEY (`threads_count_id`)
) ENGINE=InnoDB;

Crear una rutina simple:

delimiter //
CREATE PROCEDURE threads_tally()
BEGIN
INSERT INTO threads_count SELECT NULL , VARIABLE_VALUE , NOW() FROM information_schema.GLOBAL_STATUS WHERE VARIABLE_NAME IN ('Threads_connected');
END//
delimiter ;

Crear un evento simple:

SET GLOBAL event_scheduler = ON;
CREATE EVENT `threads_tally`
ON SCHEDULE EVERY 5 MINUTE
DISABLE ON SLAVE
COMMENT 'keeps a count of Threads_connected'
DO
CALL threads_tally();
DELIMITER ;

Ahora, pero la ejecución del ejemplo anterior, usted tendrá una tabla en la que se pueden seleccionar los valores de (probablemente poner en un gráfico o simplemente para su revisión) para que pueda ver cuando el menor número de conexiones existente en el servidor. Dependiendo de la aplicación y el tráfico que pueda mantener esta funcionando el tiempo suficiente para obtener una perspectiva válida y luego desactivar el evento.

select variable_value , time_recorded FROM threads_count;

Ahora usted puede tomar este curso un paso más allá, si usted no tiene las herramientas de la empresa, y mantener un registro de todas sus variables de estado para la revisión:

Tabla de valores:

CREATE TABLE `status_review` (
`status_review_id` int(11) NOT NULL AUTO_INCREMENT,
`variable_name` varchar(255) DEFAULT NULL,
`variable_value` varchar(255) DEFAULT NULL,
`time_recorded` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
PRIMARY KEY (`status_review_id`)
) ENGINE=InnoDB;

Rutina para recopilar valores:

delimiter //
CREATE PROCEDURE status_reviews()
BEGIN
INSERT INTO status_review SELECT NULL , VARIABLE_NAME, VARIABLE_VALUE , NOW() FROM information_schema.GLOBAL_STATUS;
END//
delimiter ;

Evento para ejecutar la rutina:

SET GLOBAL event_scheduler = ON;
CREATE EVENT `status_reviews`
ON SCHEDULE EVERY 1 HOUR
DISABLE ON SLAVE
COMMENT 'keeps a eye on status values'
DO
CALL status_reviews();
DELIMITER ;

Es posible que sólo quieren ciertos nombres de variables y valores para su revisión y se puede ajustar la consulta en la rutina en consecuencia. El tiempo de ejecución depende de sus necesidades, he usado una hora en este ejemplo.

Esto, por supuesto, va a generar una gran cantidad de información en el tiempo por lo que si podría ser necesaria una limpieza relevante de estas tablas con el tiempo. Todo depende de la frecuencia con que se conecte y revise la información proporcionada.

Mientras que usted verá un aumento constante de muchos de los valores debido a su crecimiento de los datos y el sistema de usar que también será capaz de identificar los picos de datos en los datos mientras que y correlacionar que a la aplicación y uso del sistema.

La empresa MySQL por ejemplo ya se graficará todos este tipo de información para usted, pero esta es una manera también puede hacerlo usted mismo con un poco de tiempo y la revisión de los datos.

Utilice el índice incluso con un varchar | | caracteres

Original post: http://anothermysqldba.blogspot.com/2014/01/use-your-index-even-with-varchar-char.html

Hace poco me di cuenta de un post en el forums.mysql.com sitio: Cómo búsqueda rápida en 3 millones de registro? 
El ejemplo que utiliza un LIKE '% eed' 

Eso no será aprovechado de un índice y hará un escaneo completo de tabla. 
A continuación se muestra un ejemplo que utiliza la base de datos mundial, por lo que no de 3 millones de discos, pero tratando de mostrar cómo funciona. 

> explain select * from City where Name LIKE '%dam' \G
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: City
type: ALL
possible_keys: NULL
key: NULL
key_len: NULL
ref: NULL
rows: 4188
Extra: Using where
1 row in set (0.01 sec)

[world]> select count(*) FROM City;
+----------+
| count(*) |
+----------+
| 4079 |
+----------+

> select * from City where Name LIKE '%dam';
+------+------------------------+-------------+----------------+------------+
| ID | Name | CountryCode | District | Population
+------+------------------------+-------------+----------------+------------+
| 5 | Amsterdam | NLD | Noord-Holland | 731200 |
| 6 | Rotterdam | NLD | Zuid-Holland | 593321 |
| 1146 | Ramagundam | IND | Andhra Pradesh | 214384 |
| 1318 | Haldwani-cum-Kathgodam | IND | Uttaranchal | 104195 |
| 2867 | Tando Adam | PAK | Sind | 103400 |
| 3122 | Potsdam | DEU | Brandenburg | 128983 |
+------+------------------------+-------------+----------------+------------+

Para mostrar el punto más 

> explain select * from City where Name LIKE '%dam%' \G
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: City
type: ALL
possible_keys: NULL
key: NULL
key_len: NULL
ref: NULL
rows: 4188
Extra: Using where
1 row in set (0.00 sec)

> select * from City where Name LIKE '%dam%';
+------+------------------------+-------------+----------------+------------+
| ID | Name | CountryCode | District | Population |
+------+------------------------+-------------+----------------+------------+<
| 5 | Amsterdam | NLD | Noord-Holland | 731200 |
| 6 | Rotterdam | NLD | Zuid-Holland | 593321 |
| 380 | Pindamonhangaba | BRA | São Paulo | 121904 |<
| 625 | Damanhur | EGY | al-Buhayra | 212203 |
| 1146 | Ramagundam | IND | Andhra Pradesh | 214384 |
| 1318 | Haldwani-cum-Kathgodam | IND | Uttaranchal | 104195 |
| 1347 | Damoh | IND | Madhya Pradesh | 95661 |
| 2867 | Tando Adam | PAK | Sind | 103400 |
| 2912 | Adamstown | PCN | – | 42 |
| 3122 | Potsdam | DEU | Brandenburg | 128983 |
| 3177 | al-Dammam | SAU | al-Sharqiya | 482300 |
| 3250 | Damascus | SYR | Damascus | 1347000 |
+------+------------------------+-------------+----------------+------------+<
12 rows in set (0.00 sec) 

La salida de explicación anterior muestra que no se utilizan índices. 

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`),
KEY `CountryCode` (`CountryCode`),
CONSTRAINT `city_ibfk_1` FOREIGN KEY (`CountryCode`) REFERENCES `Country` (`Code`)
) ENGINE=InnoDB
<

Así que para las muecas pongamos una tecla en el campo varchar. Note que no pongo una tecla en todo el rango de sólo los primeros caracteres. Esto es, por supuesto, depende de sus datos. 

> ALTER TABLE City ADD KEY name_key(`Name`(5));
Query OK, 0 rows affected (0.54 sec)

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`),
KEY `CountryCode` (`CountryCode`),
KEY `name_key` (`Name`(5)),
CONSTRAINT `city_ibfk_1` FOREIGN KEY (`CountryCode`) REFERENCES `Country` (`Code`)
) ENGINE=InnoDB

Lo mismo ocurrirá con esta siquiera importa? 

> explain select * from City where Name LIKE '%dam' \G
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: City
type: ALL
possible_keys: NULL
key: NULL
key_len: NULL
ref: NULL
rows: 4188
Extra: Using where
1 row in set (0.00 sec) 

No, no importa, porque el LIKE '% presa' obligará a un análisis completo de todos modos. 

> EXPLAIN select * from City where Name LIKE '%dam' AND CountryCode = 'IND' \G
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: City
type: ref
possible_keys: CountryCode
key: CountryCode
key_len: 3
ref: const
rows: 341
Extra: Using index condition; Using where
1 row in set (0.00 sec) 

Note la diferencia en el resultado de explicar anteriormente. Esta consulta utiliza un índice.No está utilizando el nombre que el índice pero que está utilizando un índice. Entonces, ¿cómo puede usted tomar ventaja del índice varchar? 

> EXPLAIN select * from City where Name LIKE 'Ra%' \G
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: City
type: range
possible_keys: name_key
key: name_key
key_len: 5
ref: NULL
rows: 35
Extra: Using where
1 row in set (0.00 sec) 

La consulta anterior se utilizará el índice name_key. 

El punto es que usted tiene que tener cuidado de la forma de escribir la consulta SQL y asegurarse de que se ejecuta explica a encontrar el mejor índice de elección para su búsqueda.

Puede replicación MySQL ponerse al día

Original post: http://anothermysqldba.blogspot.com/2014/01/can-mysql-replication-catch-up.html

Así que la replicación se ha mejorado recientemente en MySQL 5.6. Sin embargo, la gente sigue utilizando 5.1 y 5.5 por lo que algunas de estas mejoras tendrán que esperar para golpear el mundo real.

Recientemente ayudé a paso en esta dirección con una solución de replicación de geo-localizada. Una parte del país tenía un servidor MySQL 5.1 y la otra parte del país tuvo un nuevo servidor MySQL 5.6 instalado.

Después de lidiar con los problemas de obtener la copia de seguridad inicial de los datos desde el primario al servidor secundario (tardó varias horas para decir lo menos), tuve que decidir podría replicación ponerse al día y mantener el ritmo. El servidor principal tenía algunos grandes consultas y optimización es siempre un buen lugar para empezar. Tuve que hacer el servidor secundario tirando y aplicar lo más rápido que pude primero sin embargo.

Así que aquí hay algunas cosas que debe revisar y tener en cuenta cuando se trata de la réplica. He añadido algunos enlaces de abajo que ayudan a apoyar mis pensamientos mientras trabajaba en esto.

La replicación puede ser muy de E / S pesada. Dependiendo de su aplicación. Un sitio blog no tiene que muchas escrituras por lo que la replicación de E / S es la luz, pero un servidor primario en gran medida por escrito y actualizado va a conducir a un servidor de replicación escribir mucho relay_logs y binary_logs si están habilitadas. Los logs binarios pueden ser activados en la secundaria que le permite ejecutar copias de seguridad o usted puede ser que este servidor sea un primario a otros.

Dividí los registros en una partición de datos diferente del directorio de datos.
Esto se establece en el archivo my.cnf - relay-log

El buffer de InnoDB ya se estableció en un valor de más de 10 GB. Esto fue suficiente para este servidor.
El camarero fue más de 90.000 segundos por detrás todavía.

Así que empecé a hacer algunos ajustes en el servidor y terminamos con estos ajustes en el final. Concedido cada servidor es diferente.

mysql> select @ @ sync_relay_log_info \ G
*************************** 1. fila ***************************
@ @ Sync_relay_log_info: 0
1 row in set (0.08 sec)

mysql> select @ @ innodb_flush_log_at_trx_commit \ G
*************************** 1. fila ***************************
@ @ Innodb_flush_log_at_trx_commit: 2
1 row in set (0.00 sec)

mysql> select @ @ log_slave_updates \ G
*************************** 1. fila ***************************
@ @ Log_slave_updates: 0

mysql> select @ @ sync_binlog \ G
*************************** 1. fila ***************************
@ @ Sync_binlog: 0
1 row in set (0.00 sec)

mysql> select @ @ max_relay_log_size \ G
*************************** 1. fila ***************************
@ @ Max_relay_log_size: 268435456

Me volví el registro binario fuera como yo supervisé diferentes configuraciones y opciones para ayudar a la replicación de ponerse al día. Me tomó un tiempo. Algunos de los ajustes que ves arriba puede o no se han aplicado a medida que trabajaba dentro de este marco de tiempo. Sin embargo, no ponerse al día en 0 segundos atrás. Ahora usted puede notar que muchos de estos ajustes anteriores se relacionan en y alrededor del registro binario. Así que me encontré una pequeña prueba. Por lo tanto, he reiniciado y permitió a los registros de basura. Me registré en el servidor más tarde y encontró que 10,000 + segundos atrás. Así que una vez más, reinicié y desactivado los registros de basura. Se alcanzó (0 segundos detrás) con el servidor principal en menos de 15 minutos. Solía ​​Aurimas ' herramienta mientras veía a ponerse al día también. Si aún no lo use antes, es una herramienta muy agradable y práctico.

Lo que todo esto significa es que el servidor principal debe ser conforme a ACID. Con esta configuración también está en función del sistema operativo para el caché y limpiar. Este es el servidor se puede utilizar como un servidor de lectura principalmente para alimentar a la información a los demás. También quiere decir que sí, la replicación geo-localizada puede mantenerse al día con un servidor primario.

¿Qué pasa si usted necesita parar el esclavo, se sigue ponerse al día rápidamente?

¿Cómo y por qué te detienes el esclavo es mi primera respuesta. Usted debe entrar en el hábito de usar SLAVE STOP SQL_THREAD , en lugar de SLAVE STOP ; Esto permite que los logs retardados continúen para recopilar datos y no aplicarlo a su servidor principal. Así que si usted puede tomar ventaja de que va a ayudar a reducir el tiempo que toma para que usted pueda rellenar los logs retardados después.

Algunos de lectura adicional para usted:

• http://www.mysqlperformanceblog.com/2011/07/29/reasons-for-mysql-replication-lag/
• http://www.mysqlperformanceblog.com/2007/05/24/predicting-how-long-data-load-would-take/
• http://www.mysqlperformanceblog.com/2012/08/29/heres-a-quick-way-to-foresee-if-replication-slave-is-ever-going-to-catch-up-and-when/

El trabajo duro que pasa desapercibido ....

Originally posted: http://anothermysqldba.blogspot.com/2014/01/hard-work-that-goes-unnoticed.html

Me tomé un momento hoy y ser informado uno de mis distribuciones de Linux. En esta distribución resulta que tengo Percona 5.6 instalado como la base de datos MySQL. He mencionado antes cómo puede configurar su elección de MySQL a través de un repositorio Yum .

Mi punto aquí es, sin embargo, ¿cómo alguna vez las gracias a estas personas por todo el trabajo que hacen?

Muchos de estos repositorios están a cargo de las empresas y estas personas se les paga por lo que hacen. Sin embargo, a través de la observación y en general / preguntas de la encuesta de la Linux (incluyendo Debian / Ubuntu) de la comunidad, la mayoría de la gente no actualizar hasta que esté disponible en su distribución. Sucede que soy una persona que quiera estar al tanto de los arreglos de seguridad y errores, así que tengo el rico repositorio de actualización de la fuente de la mayor frecuencia posible.

Mi punto es, mucho trabajo entra en el envasado de estos archivos para su distribución y en su mayor parte se ve como un trabajo bastante ingrato. Recuerdo los más viejos (no de edad, pero mayores) día de tar y gzip, cuando había que cavar y encontrar las dependencias a ti mismo. -. / Configure .. nop necesitará algo más ir descargue e instale de que vuelva a intentarlo .....

Acabo de actualizar 25 paquetes diferentes en algunos momentos, lo que habría tenido algún tiempo antes. Mientras Yum y Get Apt están lejos de ser nueva, y me suenan como un viejo contador de tiempo aquí, sólo pensé que sería bueno para dar las gracias, a todas las personas que trabajan entre bastidores para hacer que todas nuestras experiencias de Linux, y mucho menos MySQL relacionados instala, más fácil y más suave.

Quiero señalar que Oracle tiene 5,6 paquetes ahora disponibles.

• http://public-yum.oracle.com/repo/OracleLinux/OL6/MySQL56/

Recuerdo que mi post anterior mencionó que de no haber sido.

Un DBA MySQL mira PostgreSQL PostgreSQL part3 Para MySQL

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

Así que recientemente he publicado: Un DBA MySQL mira PostgreSQL y parte 2: MySQL a PostgreSQL .

Este post va a explorar la migración de PostgreSQL a MySQL . Una vez más, el objetivo a largo plazo con estos mensajes han de ser capaces de mostrar cómo funciona la información dentro de las diferentes bases de datos, así como la forma de resolver problemas similares en cada base de datos cuando surgieran ejemplos.

MySQL empuja el MySQL Workbench la herramienta de migración de base de datos. Tengo que admitir que tengo curiosidad por qué la Utilidades MySQL no proporciona una opción de línea de comandos. La entrada en el blog anterior ( parte 2 ) mostró lo fácil la migración a través de línea de comandos para MySQL a PostgreSQL . Tenga en mente que cuando armonización de datos a MySQL Data Engine tiene que ser considerado.

En pocas palabras, si usted va a llevar los datos de nuevo en MySQL desde PostgreSQL una opción rápida es probable que el MySQL Workbench . Pero eso no es una solución global ya que a menudo preferimos quedarnos en nuestras ventanas de terminal. Así que va a hacer lo siguiente:

• Volcar el esquema de PostgreSQL en un archivo
• Revisar y editar el archivo de MySQL.
• Per esquema y las tablas que desee exportar como un archivo csv.
• Importar de nuevo en MySQL

De todos modos, primero tenemos todavía los datos en PostgreSQL desde la base de datos Mundial ejemplo.


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=> 

Vacíe el esquema:


$ pg_dump -s world > world_schema.pgsql 

Usando pg_dump tomar el - de sólo los datos y - inserta simplemente crear archivos estándar SQL de datos.


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

Usted verá más adelante que hacer un volcado por mesa sería mejor, pero esto funciona.

Creación de una base de datos en MySQL para colocar los datos de nuevo, así como poner a prueba su nuevo esquema.


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

Edite su archivo de esquema: vi world_schema.pgsql
Usted tiene la nueva base de datos MySQL creada para que pueda probarlos a medida que avanza.



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); 

Usted tendrá que revisar el archivo para todas las claves relacionadas para que pueda crear afirmaciones válidas.
Usted tendrá que entender MySQL para que pueda crear afirmaciones válidas CREATE TABLE.


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`)
); 

Es, por supuesto, depende de usted. pero una vez que se resuelve la PRIMARY KEY por tabla, me gustaría crear declaraciones alter para actualizar los nuevos esquemas para que pueda asegurarse de que captura todo. Si bien todos ellos pueden ser añadidos directamente a la primera sentencia CREATE para la mayor parte como se procesa el archivo haciendo Postgresql altera puede mantener a raya volcado.

Algunos ejemplos de las sentencias ALTER necesarios:


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`) 

Una vez que todo el esquema es actualizada y válida. usted puede poner los datos guardados.


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 los archivos a cabo por mesa en este caso debido a las restricciones. Editar en consecuencia para cada archivo sólo contiene los datos por mesa. Debería haber tirado así o simplemente volcar de nuevo por tabla.


$ 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 

Así que en pocas palabras, no es tan fácil, debo decir automatizado, para migrar a MySQL a través de la línea de comandos debido a los cambios de esquema que requerirán su atención, pero se puede hacer. 


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

MySQL Workbench de migración de base de datos, por supuesto, puede hacer el mismo proceso y se puede aprender más sobre esta herramienta aquí -http://www.mysql.com/products/workbench/migrate/