En clientes que soportan tuneles SSH se establece una conexión via SSH y sobre ella se conecta al servidor MySQL. Eso supone que la conexión a servidor MySQL se hace “desde” el servidor SSH por lo que los datos de conexión no serán servidor.destino.com sino los que usarias localmente desde el propio servidor. Eso afecta también a los permisos del usuario con se conecta entre otros (localhost en lugar de IP remota) y nos permite conectar de manera segura desde distintos orígenes sin tener que crear usuarios adicionales en el servidor de datos.

Pues bien, no está directamente relacionada con  esta entrada en stackoverflow pero leyéndola descubrimos que MySQL establece las conexiones a localhost en este contexto desde el socket (algo así como el archivo de ejecución directo) en lugar del a través del puerto solicitado. Es decir, en este contexto hay que usar 127.0.0.1 como conexión y no localhost en los datos del server MySQL para que funcione

La entrada 127.0.0.1 no es “siempre” localhost en MySQL aparece primero en premeditado.

Si cuando Sun la adquirió hace algunos años muchos temieron los cambios que se podían avecinar, ahora que el gigante Oracle ha comprado a Sun, el temor es aún mayor pues el olor a monopolio es alto y dependerá sólo de la buena fe de Oracle el mantener la evolución del proyecto.

En lanzan una petición a la Union Europea para que estudie el caso a nivel de competencia, entre otras iniciativas.

La entrada Apoyando la campaña para “salvar MySQL” aparece primero en premeditado.

Un antiguo blog que queríamos actualizar tenía sus tablas en Latin1 y queríamos convertirla a una completamente en UTF8 (es decir BBDD y tablas). Es importante tener en cuenta tanto la codificación de tablas originales como la del propio wordpress (“define(‘DB_CHARSET’, ‘utf8’);”), porque las opciones de conversión varían en cada caso. En este caso concreto es:

BBDD en Latin1

Tablas en Latin1

WordPress DB_CHARSET: UTF8

El objetivo era pasarlo todo a UTF-8 que es como mantenemos todas las tablas que podemos ya. Encontré diversas pistas sobre conversiones , haciendo uso de ICONV para convertir el texto del dump, pero me costó un rato darme cuenta de que nuestros datos NO necesitaban conversión porque estaban ya en UTF-8 (el WP los almacenaba así por su configuración), asi que esa ruta no sirvió. Su la codificación del WP hubiera estado en latin1, probablemente si es el camino correcto. Pensé entonces que sencillamente modificando todos los “DEFAULT CHARSET=latin1;” del dump de MySQL a “utf8” estaría todo listo pero a pesar de ello, nada.

Finalmente, encontré que me dio una pista adicional sobre la que ya sospechaba. Al hacer el dump, el propio MySQL está haciendo una conversión en función al sistema cliente, por lo que si los datos estaban ya codificados y sólo hay que cambiar la creación al importar la tabla, es importante que la exportación se haga también en el formato antiguo:

$ mysqldump —default-character-set=latin1

–databases wordpress > m.sql

Después a modificar la SQL para que al importar la nueva se haga ya en UTF-8.

$ replace “CHARSET=latin1” “CHARSET=utf8”

“SET NAMES latin1” “SET NAMES utf8” < m.sql > m2.sql

Ojo, porque el dump creará la bbdd con el mismo nombre en algunos casos, así que comprobar el dump también esto, sobretodo si pensaís cambiar el nombre a la misma. Comprobar si teneís:

CREATE DATABASE /*!32312 IF NOT EXISTS*/ `cambiarestenombrealdedestino` /*!40100 DEFAULT CHARACTER SET utf8 */;

El resto lo podéis encontrar en alguno de los enlaces.

Cabe mencionar también, aunque no viene al caso, que además del cambio de codificación estaba haciendo un upgrade de WP de la version 2.0 a la 2.8.6, por lo que cada vez que probabá, había que hacer un upgrade, cambiar la tabla options para la copia de pruebas, tema, etc… La actualización de versión de WP sorprendentemente sin problema alguno, aunque desactive los plugins la primera vez, con tanto dump se me olvidó al final, pero la copia nueva funcionó sin problemas. Eso si, si no hay tema en la tabla wp_options tal vez tengáis que setear un par de campos a mano con el nombre de alguno de los nuevos, si es que por si mismo, no se setea en “classic”.

No se si me explicado muy bien… pero de haber encontrado estas pistas antes, me hubiera ahorrado al menos un par de horitas de pruebas.

La entrada Pasando tablas de latin1 a UTF8 aparece primero en premeditado.