MySQL

Crear un usuario y asignar permisos en MySQL

root — Thu, 06 Sep 2018 17:20:10 +0000

Crear un usuario y asignar permisos en MySQL

Jueves, Septiembre 6, 2018 - 19:20

Normalmente para configurar el acceso de una aplicación web a la base de datos crearemos una cuenta de servicio para esa aplicación, y le daremos permisos según necesitemos, pero solamente a esa base de datos.

Esta es una de esas cosas que uno hace mil veces pero nunca se acuerda de la sintaxis correcta. Aqui lo teneis:

CREATE USER 'nombre_de_usuario'@'localhost' IDENTIFIED BY 'vuestra_password';
GRANT ALL PRIVILEGES ON nombre_de_base_de_datos.* TO 'nombre_de_usuario'@'localhost';
FLUSH PRIVILEGES;

Si queremos asignarle todos los permisos para todas las bases de datos, el GRANT sería así:

GRANT ALL PRIVILEGES ON *.* TO 'nombre_de_usuario'@'localhost';

Normalmente, antes habremos creado la base de datos a mano, o importando los datos de algún archivo. Crear la base de datos en MySQL puede ser tan sencillo como:

CREATE DATABASE nombre_de_base_de_datos;

Suele ser buena idea probar que ha funcionado correctamente. La mejor forma es probar el acceso usando el terminal:

mysql --user=nombre_de_usuario --password=vuestra_password nombre_de_base_de_datos

Si todo está correcto, nos abrirá una sesión de MySQL en el terminal. Si no conecta, es que hemos hecho mal alguno de los pasos anteriores.

Añadir nuevo comentario

Error ERROR 1071 (42000) al importar una base de datos Drupal

root — Sat, 18 Mar 2017 17:28:08 +0000

Error ERROR 1071 (42000) al importar una base de datos Drupal

Sábado, Marzo 18, 2017 - 18:28

Tratando de importar una copia de base de datos que había creado con drush sql-dump en otro servidor, me he encontrado con este error de MySQL:

ERROR 1071 (42000) at line 25: Specified key was too long; max key length is 767 bytes

El comando que estaba usando era bastante normal:

drush sql-cli <  ../backup.sql

Después de intentar varias opciones, también he llegado a ver este otro error:

ERROR 1709 (HY000) at line 25: Index column size too large. The maximum column size is 767 bytes.

La versión de MySQL que estaba usando es 5.6.30-1, como podéis ver aquí:

dpkg -l | grep mysql-server
ii  mysql-server                                  5.6.30-1                               all          MySQL database server (metapackage depending on the latest
version)
ii  mysql-server-5.6                              5.6.30-1                               amd64        MySQL database server binaries and system database setup
ii  mysql-server-core-5.6                         5.6.30-1                               amd64        MySQL database server binaries

El problema venia de la configuración de INNODB en mi servidor, y la solución es bastante sencilla, basta con editar el fichero de configuracion de MySQL (como root o usando sudo), que en Debian está en:

vi /etc/mysql/my.cnf

Si no teneis ese fichero puede que este aquí:

vi /etc/mysql/mysql.conf.d/mysqld.cnf

Tenemos que incluir las siguientes líneas de configuración en la sección de [mysqld]:

innodb_file_format = true
innodb_file_per_table=true
innodb_file_format=barracuda

Después reiniciamos el servidor y listo:

service mysql restart

Ahora si intentamos importar la base de datos de nuevo no deberíamos tener problemas.

EDIT:

Si no podemos tocar la configuración del servidor, podemos ejecutar esto directamente en mysql antes de ejecutar nuestra query:

SET @@global.innodb_large_prefix = 1;

Referencias:

https://dev.mysql.com/doc/refman/5.6/en/innodb-parameters.html#sysvar_innodb_large_prefix

Comments

gracias

Gracias por este articulo, me estaba volviendo loco con esto

Añadir nuevo comentario

Drupal: Actualizar MySQL a utf8mb4

root — Sun, 05 Mar 2017 19:24:40 +0000

Drupal: Actualizar MySQL a utf8mb4

Domingo, Marzo 5, 2017 - 20:24

Drupal

MySQL

utf8mb4

De una temporada a esta parte supongo que habréis visto el aviso en el panel de información de Drupal acerca de actualizar la base de datos para soportar UTF-8 de 4 bytes, con este mensaje:

4 byte UTF-8 for mysql is not activated, but it is supported on your system. It is recommended that you enable this to allow 4-byte UTF-8 input such as emojis, Asian symbols and mathematical symbols to be stored correctly. See the documentation on adding 4 byte UTF-8 support for more information.

Vale, ¿pero de que va todo esto? ¿Para que sirve esta actualización?

Diferencias entre UTF-8 y uft8mb4

UTF-8 es un juego de caracteres, o mejor dicho, un formato de codificación de caracteres, que implementa el estándar Unicode. Unicode está dividido en 17 códigos de área, y cada uno contiene 65,536 caracteres de 16 bits, de los que solamente está en uso alrededor del 10%. La mas importante de estas áreas o planos es el BMP (Basic Multilingual Plane), que contiene los caracteres mas usados. Entre ellos están los de Latín, alfabetos griego y cirílico, y hasta los juegos de caracteres asiáticos como los japoneses Katakana e Hiragana, o ideogramas chinos.

Además, UTF-8 es de longitud variable, y usa hasta 3 bytes como máximo para representar un carácter, por lo que soporta todos los caracteres BPM. Con utf8mb4 se pueden utilizar hasta 4 bytes, con lo que se gana un byte adicional que permite representar caracteres adicionales o suplementarios, y según el manual de MySQL:

Para un carácter BMP, utf8 y utf8mb4 tienen el mismo almacenamiento: mismo código, misma codificación, misma longitud.
Para un carácter suplementario, utf8 no puede almacenarlo, mientras que utf8mb4 necesita cuatro bytes para almacenarlo.

Como utf8 no puede almacenar este tipo de caracteres, no hay problema al realizar la migración desde utf8 a utf8mb4, pero ojo, perderíamos información si queremos volver a pasar de utf8mb4 a utf8, ya que como hemos visto no se podrán almacenar todos los caracteres.

Actualizar a utf8mb4

Como tenia un rato libre me decidí a probar la actualización a utf8mb4, eso si, sabiendo que no hay vuelta atrás, así que seguí las instrucciones de la página que nos enlaza desde Drupal:

documentation on adding 4 byte UTF-8 support

Lo primero es editar el fichero de configuración de MySQL, normalmente en Debian en /etc/mysql/my.conf y añadir las siguientes líneas en el apartado de [mysqld]:

innodb_large_prefix=true
innodb_file_format=barracuda
innodb_file_per_table=true

Y reinicamos el servidor:

service mysql restart

Ahora tenemos que convertir nuestra vieja base de datos a utf8mb4, por lo que lo primero que haremos es hacer una copia de seguridad.

¿Ya la tienes? ¿Seguro? Ok, luego no digas que no te he avisado.

Vamos a utilizar el módulo experimental que nos dicen en la ayuda: utf8mb4_convert. No es exactamente un módulo, es una extensión de Drush, de forma que no tendremos que activarlo. Lo descargamos así:

drush @none dl utf8mb4_convert-7.x
drush cc drush

Ahora, si tenemos alguna base de datos en nuestro archivo settings.php que no queramos convertir, la comentamos o la quitamos del fichero. Podemos nuestro portal en modo de mantenimiento (los programadores de verdad hacen esto a pelazo, pero vosotros veréis):

drush vset maintenance_mode 1

Y ejecutamos este comando de Drush que da un yuyu que te cagas:

drush utf8mb4-convert-databases

¿Tenías una copia de seguridad verdad?

Bueno, pues modificamos la configuración del settings.php para utf8mb4:

$databases['default']['default'] = array(
  'driver' => 'mysql',
  'database' => 'databasename',
  'username' => 'username',
  'password' => 'password',
  'host' => 'localhost',
  'charset' => 'utf8mb4',
  'collation' => 'utf8mb4_general_ci',
);

Y probamos el portal. Si todo funciona, podemos quitar el modo de mantenimiento:

drush vset maintenance_mode 0

Y una cosa mas que hemos aprendido a hacer.

Y si no funciona... bueno... pues déjame un comentario o tira de Stackoverflow...