Wednesday, September 25, 2013

MySQL una Comunidad Global

Original post: http://anothermysqldba.blogspot.com/2013/09/mysql-global-community.html

Me siento alentado por la respuesta a este blog, así que gracias a todos los que lo han leído.

Desde MySQL es una comunidad global. Pensé que me gustaría señalar el interés mundial que he seguido a través de este blog. Esto de ninguna manera se puede determinar el único interés en MySQL general por región. Sin embargo, he encontrado que es interesante ver los diferentes temas que los diferentes países / idiomas se centran en. Los temas en realidad varían. Tal vez también se puede encontrar algo útil y tal vez puede ayudar a apoyo directo más a la comunidad sin fines de Inglés.

No voy a romperlo por países sino por el lenguaje para reflejar los diferentes blogs.


English:






Chinese:




Japanese:





Spanish:




Portuguese:







MySQL YUM Repo (de Oracle, MariaDB y Percona)

Original post: http://anothermysqldba.blogspot.com/2013/09/mysql-yum-repo-oracles-mariadb-and.html

Mucha gente hoy en día prefieren seguir con el gestor de paquetes yum para instalar su software relacionado en vez de bajar el último RPM de MySQL, por ejemplo.

Mientras que usted puede descargar RPMS de un proveedor e instalar con yum (yum install *. Rpm) Usted también puede actualizar su repositorio yum para tirar directamente del proveedor de paquetes MySQL. En el momento de este artículo sólo se conseguirá hasta MySQL 5.5.13, aunque MySQL 5.6 GA fue lanzado 05 de febrero 2013 a través del Oracle repo. Ahora que ha lanzado MariaDB MariaDB-5.5.33 Espero Oracle muévete y actualizar su repositorio público.

Independientemente de lo que elija. Aquí está cómo configurar repos vendedor para que pueda acceder a lo que usted desea.

Todos los casos tienen páginas que he mencionado que son fáciles de seguir y de configurar. Voy a seguir adelante y dar ejemplos también.

Voy a utilizar CentOS 6 64 bits para estos ejemplos.

En todos los casos usted va a trabajar desde el directorio yum.repos.d como root.
cd / etc / yum.repos.d


http://public-yum.oracle.com
wget https://public-yum.oracle.com/public-yum-ol6.repo
# Vi público-yum-ol6.repo
Busque la siguiente y editar permitido 1 de 0 a continuación, guarde el archivo.




[Ol6_MySQL]
name = MySQL para Oracle Linux 6 ($ basearch)
baseurl = http://public-yum.oracle.com/repo/OracleLinux/OL6/MySQL/ $ basearch /
gpgkey = file :/ / / etc / pki / rpm-gpg / RPM-GPG-KEY-oracle
gpgcheck = 1
habilitado = 1

yum list | grep MySQL
mysql.x86_64 5.5.34-1.el6 ol6_MySQL
mysql-devel.x86_64 5.5.34-1.el6 ol6_MySQL
mysql-embedded.x86_64 5.5.34-1.el6 ol6_MySQL
mysql-embedded-devel.x86_64 5.5.34-1.el6 ol6_MySQL
mysql-libs.x86_64 5.5.34-1.el6 ol6_MySQL
mysql-libs-compat.x86_64 5.5.34-1.el6 ol6_MySQL
mysql-server.x86_64 5.5.34-1.el6 ol6_MySQL
mysql-test.x86_64 5.5.34-1.el6 ol6_MySQL


https://downloads.mariadb.org/mariadb/repositories/
vi MariaDB.repo






MariaDB hace le ofrecerá la opción de elegir 5.5 ó 10, solía 5.5 para este ejemplo.


# MariaDB 5.5 CentOS repository list - created 2013-09-24 21:59 UTC
# http://mariadb.org/mariadb/repositories/
[mariadb]
name = MariaDB
baseurl = http://yum.mariadb.org/5.5/centos6-amd64
gpgkey=https://yum.mariadb.org/RPM-GPG-KEY-MariaDB
gpgcheck=1



MariaDB-Galera-server.x86_64 5.5.32-1 mariadb
MariaDB-client.x86_64 5.5.33a-1 mariadb
MariaDB-common.x86_64 5.5.33a-1 mariadb
MariaDB-compat.x86_64 5.5.33a-1 mariadb
MariaDB-devel.x86_64 5.5.33a-1 mariadb
MariaDB-server.x86_64 5.5.33a-1 mariadb
MariaDB-shared.x86_64 5.5.33a-1 mariadb
MariaDB-test.x86_64 5.5.33a-1 mariadb
galera.x86_64 23.2.6-1.rhel6 mariadb



http://www.percona.com/doc/percona-server/5.5/installation/yum_repo.html
vi Percona.repo

[percona]
name = CentOS $releasever - Percona
baseurl=http://repo.percona.com/centos/$releasever/os/$basearch/
enabled = 1
gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-percona
gpgcheck = 1


percona-toolkit.noarch 2.2.4-1 @/percona-toolkit-2.2.4-1.noarch
percona-xtrabackup.x86_64 2.1.3-608.rhel6 @/percona-xtrabackup-2.1.3-608.rhel6.x86_64
Percona-SQL-50-debuginfo.x86_64 5.0.92-b23.89.rhel6 percona
Percona-SQL-client-50.x86_64 5.0.92-b23.89.rhel6 percona
Percona-SQL-devel-50.x86_64 5.0.92-b23.89.rhel6 percona
Percona-SQL-server-50.x86_64 5.0.92-b23.89.rhel6 percona
Percona-SQL-shared-50.x86_64 5.0.92-b23.89.rhel6 percona
Percona-SQL-shared-compat.x86_64 5.0.92-b23.89.rhel6 percona
Percona-SQL-test-50.x86_64 5.0.92-b23.89.rhel6 percona
Percona-Server-51-debuginfo.x86_64 5.1.71-rel14.9.589.rhel6 percona
Percona-Server-55-debuginfo.x86_64 5.5.33-rel31.1.566.rhel6 percona
Percona-Server-56-debuginfo.x86_64 5.6.13-rc60.6.427.rhel6 percona
Percona-Server-client-51.x86_64 5.1.71-rel14.9.589.rhel6 percona
Percona-Server-client-55.x86_64 5.5.33-rel31.1.566.rhel6 percona
Percona-Server-client-56.x86_64 5.6.13-rc60.6.427.rhel6 percona
Percona-Server-devel-51.x86_64 5.1.71-rel14.9.589.rhel6 percona
Percona-Server-devel-55.x86_64 5.5.33-rel31.1.566.rhel6 percona
Percona-Server-devel-56.x86_64 5.6.13-rc60.6.427.rhel6 percona
Percona-Server-server-51.x86_64 5.1.71-rel14.9.589.rhel6 percona
Percona-Server-server-55.x86_64 5.5.33-rel31.1.566.rhel6 percona
Percona-Server-server-56.x86_64 5.6.13-rc60.6.427.rhel6 percona
Percona-Server-shared-51.x86_64 5.1.71-rel14.9.589.rhel6 percona
Percona-Server-shared-55.x86_64 5.5.33-rel31.1.566.rhel6 percona
Percona-Server-shared-56.x86_64 5.6.13-rc60.6.427.rhel6 percona
Percona-Server-shared-compat.x86_64 5.5.33-rel31.1.566.rhel6 percona
Percona-Server-shared-compat-51.x86_64 5.1.71-rel14.9.589.rhel6 percona
Percona-Server-test-51.x86_64 5.1.71-rel14.9.589.rhel6 percona
Percona-Server-test-55.x86_64 5.5.33-rel31.1.566.rhel6 percona
Percona-Server-test-56.x86_64 5.6.13-rc60.6.427.rhel6 percona
Percona-XtraDB-Cluster-client.x86_64 1:5.5.33-23.7.6.495.rhel6 percona
Percona-XtraDB-Cluster-debuginfo.x86_64 1:5.5.33-23.7.6.495.rhel6 percona
Percona-XtraDB-Cluster-devel.x86_64 1:5.5.33-23.7.6.495.rhel6 percona
Percona-XtraDB-Cluster-galera.x86_64 2.7-1.157.rhel6 percona
2.7-1.157.rhel6 percona
Percona-XtraDB-Cluster-server.x86_64 1:5.5.33-23.7.6.495.rhel6 percona
Percona-XtraDB-Cluster-shared.x86_64 1:5.5.33-23.7.6.495.rhel6 percona
Percona-XtraDB-Cluster-test.x86_64 1:5.5.33-23.7.6.495.rhel6 percona
jemalloc.x86_64 3.3.1-1.el6 percona
jemalloc-devel.x86_64 3.3.1-1.el6 percona
percona-cacti-templates.noarch 1.0.4-1 percona
percona-nagios-plugins.noarch 1.0.4-1 percona
percona-playback.x86_64 0.6-2.el6 percona
percona-playback-debuginfo.x86_64 0.6-2.el6 percona
percona-playback-devel.x86_64 0.6-2.el6 percona
percona-xtrabackup.x86_64 2.1.5-680.rhel6 percona
percona-xtrabackup-20.x86_64 2.0.8-587.rhel6 percona
percona-xtrabackup-20-debuginfo.x86_64 2.0.8-587.rhel6 percona
percona-xtrabackup-20-test.x86_64 2.0.8-587.rhel6 percona
percona-xtrabackup-test.x86_64 2.1.5-680.rhel6 percona
qpress.x86_64 11-1.el6 percona
qpress-debuginfo.x86_64 11-1.el6 percona

 
Esperamos que esto ayude a todos a ser capaz de recibir información actualizada más allá de lo que podría estar en sus repositorios estándar en este momento.

Tuesday, September 24, 2013

ERROR 1146 (42S02): La tabla no existe

Original post: http://anothermysqldba.blogspot.com/2013/09/error-1146-42s02-table-doesnt-exist.html

Así que algunos de ustedes se han encontrado con los siguientes errores durante la instalación de MySQL 5.6:
  • ERROR 1146 (42S02): no existe 'mysql.innodb_index_stats' Tabla
  • ERROR 1146 (42S02): no existe 'mysql.innodb_table_stats' Tabla
  • ERROR 1146 (42S02): Table 'mysql.slave_master_info' no existe
  • ERROR 1146 (42S02): Table 'mysql.slave_relay_log_info' no existe
  • ERROR 1146 (42S02): Table 'mysql.slave_worker_info' no existe
Usted se sorprenderá de que es probable que vea este error en una instalación de base de datos nueva. Usted no está solo. El problema se puede arreglar sin embargo.

Lo más seguro es volver a instalar la base de datos mysql con el comando siguiente: mysql_install_db
Hace poco tuve que hacer esto en cada nueva instalación (sí sucedió más de una vez) de MySQL 5.6 en un entorno Solaris Sparc.

Usted puede tratar de usar lo siguiente para crear las tablas que faltan, pero me pareció que lo mejor era mantener todo limpio y asegúrese de que todo está configurado con el mysql_install_db.
Algunos recomiendan la revisión launchpad he mencionado anteriormente, pero como he dicho que prefiero el mysql_install_db para asegurar que todo está ligado correctamente instalado.

Tengo otros blogs que incluyen ejemplos sobre el uso de este comando:

Mensajes relacionados sobre este tema:
Si usted se encuentra con esto desde mesas fuera del alcance mysql_install_db ver el blog de Pedro para ayudarle a comenzar:

Wednesday, September 11, 2013

mysqld_multi

Original post: http://anothermysqldba.blogspot.com/2013/09/mysqldmulti.html

Así que yo estaba trabajando recientemente con mysqld_multi y me di cuenta que se trataba de una característica que no veo en muchos blogs en ​​estos días. Ellos existen y yo hemos enumerado algunos en la parte inferior de este post para su referencia.

Sus razones tienden a variar y ser discutible cuando se trata el concepto de: debe ejecutar más de una instancia de MySQL en el mismo hardware.

Para evitar cualquier confusión, si desea instalar otra instancia de MySQL para fines de prueba y no como una instancia de producción, a continuación, sólo debe trabajar con MySQL Sandbox . Si por alguna razón que no funciona, se puede ejecutar otro servidor como muchas personas suelen hacer: crear nuevos archivos my.cnf e iniciar el servidor mysql con los comandos personalizados y mysqld_safe.

Mysqld_multi hace que sea mucho más fácil para usted para ejecutar múltiples servidores.

Por ejemplo:
Usted tiene un servidor secundario que se ejecuta en el puerto 3306. Es un read_only esclavo y tiene una gran cantidad de hardware en lugar de espera para convertirse en el nuevo servidor primario cuando falla la corriente primaria. También quisiera aprovechar la Percona conjunto de herramientas y tiene un servidor secundario replicado que se ejecuta en un modo diferido. Si se pudiera actualizar a MySQL 5.6 , entonces no sería necesario pt-esclavo-delay pero en la actualidad eso no es una opción.

En cualquier caso, usted tiene unos límites presupuestarios y no se permite otro servidor. Entonces te das por vencido? Usted tiene el espacio en disco para celebrar otra versión del servidor en el cuadro de secundaria ¿por qué no? La idea de tener que iniciar y detener versiones y etc personalizados puede ser desagradable para algunos. Así que en lugar se puede crear una nueva versión del archivo my.cnf, pero primero usted puede hacer lo siguiente.

Recojo editor favorito (es decir: vi)
vi /etc/multi_my.cnf
[mysqld_multi]
mysqld = /usr/local/bin/mysqld_safe
mysqladmin = /usr/local/bin/mysqladmin
user = mysql
log = /var/log/multi_mysql.log

# Port 3306 Server
[mysqld1]
>socket = /tmp/mysql_3306.sock
port = 3306
pid-file = /var/lib/mysql/mysql_3306.pid
datadir = /var/lib/mysql/
user = mysql
Ahora usted puede tomar la sección [mysqld] de su archivo my.cnf y copiarlo en esta ubicación.

cat /etc/my.cnf >> /etc/multi_my.cnf
Si utiliza el comando anterior edición de limpiar lo que sólo tiene la sección [mysqld] copiado.

A continuación, puede crear la sección del puerto 3307.
# Port 3307 Server
[mysqld2]
socket = /tmp/mysql_3307.sock
port = 3307
pid-file = /var/lib/mysql2/mysql_3307.pid
datadir = /var/lib/mysql2/
user = mysql
Y el ejemplo de la configuración se puede encontrar aquí:
http://dev.mysql.com/doc/refman/5.6/en/mysqld-multi.html

Para este ejemplo voy a suponer que va a crear una copia de seguridad del servidor de puerto 3306 con Percona Xtrabackup y colocarla en el nuevo datadir.
innobackupex --defaults-file=/etc/my.cnf --user=root --password=<password> --port=3306 --no-timestamp /var/lib/mysql2/
innobackupex --apply-log /var/lib/mysql2/
Ahora puede probar esto ahora con el binario mysqld_multi (/ usr / bin / mysqld_multi) o la creación de iniciar y detener la secuencia de comandos. Una plantilla viene con su instalación de MySQL: / usr / share / mysql / mysqld_multi.server

Puede copiar este en el directorio init.d o probarlo desde la ubicación actual.
El script por defecto en el archivo / etc / my.cnf. Así que para empezar a probar esto con el - default_file informe = / etc / multi_my.cnf

La opción de informe es el similar al argumento de estado para ver si el servidor está en ejecución. Si opta por ejecutar esto como el proceso por omisión que pueda enlace simbólico o copiar el archivo / etc / multi_my.cnf como el nuevo / etc / my.cnf
/etc/init.d/mysqld_multi.server report 1,2
/etc/init.d/mysqld_multi.server report 1
/etc/init.d/mysqld_multi.server report 2

Lo anterior se dará marcha de estado para cada argumento dan ese curso de referencias a una instancia de MySQL diferente. Usted puede hacer lo mismo la totalidad de las siguientes opciones: {start | stop | Informe | restart}

Si todo ha ido bien se puede "empezar a 2", que se iniciará la instancia en el puerto 3307. A continuación, iniciar sesión y cambiar principal con la información de posición binlog proporcionada en el archivo xtrabackup_binlog_info.
CHANGE MASTER TO
MASTER_HOST='localhost',
MASTER_PORT=3306,
MASTER_LOG_FILE='<log filename>',
MASTER_LOG_POS=<position>;

Start slave;
Por ahora usted tiene una copia duplicada de su servidor esclavo secundario. Si utiliza pt-esclavo-delay puede ejecutar el siguiente comando, el valor predeterminado es una hora de retraso.
pt-slave-delay --port=3307 --socket=/tmp/mysql_3307.sock --host=localhost

Espero que esto al menos puede empezar.

Saturday, September 7, 2013

Acceso y replicación MySQL bloqueado por secure_auth

Original post: http://anothermysqldba.blogspot.com/2013/09/mysql-access-and-replication-blocked-by.html

ERROR 2049 (HY000): Connection using old (pre-4.1.1) authentication protocol refused (client option 'secure_auth' enabled)

Si ha intentado conectarse a una base de datos MySQL y nos vemos este error, entonces usted necesita para tener hash de contraseña 41byte válida. Si no está seguro de que usted tiene ejecutar el SQL a continuación. Si usted tiene 16 contraseñas de caracteres que son contraseñas antiguas.

select Password from mysql.user;

Lo que sigue es cómo resolví esto como parte de una migración de MySQL 5.0 a MySQL 5.6.

El servidor MySQL 5.0 tiene una mezcla de los mayores pre 4.1 passwords y contraseñas 41byte válidos. Dado que el servidor MySQL 5.0 tenía algunas cuentas con las contraseñas de más edad, decidí no volcar la tabla MySQL como parte de la configuración de replicación. Hice volcar todas las bases de datos, excepto la base de datos mysql. Esto permite aseguré que iba a mantener las mejoras de la tabla de MySQL 5.6 válidos.

El servidor MySQL 5.6 instala fácilmente y se había levantado y he cargado los datos de volcado. Parte de la migración era utilizar la replicación mientras evaluaban la nueva base de datos. Mientras que en el servidor de MySQL 5.6 probé la cuenta de usuario de replicación. La respuesta que obtuve fue el error en la parte superior de esta página. Replicación no funciona, por supuesto, sin una cuenta de usuario válida. Por ello, los registros de error me estaba dando este error:
[ERROR] Slave I/O: error connecting to master '<user>@<hostname>:3306' - retry-time: 10 retries: 68, Error_code: 2049

Una rápida revisión de la cuenta en el servidor de MySQL 5.0 muestra que la nueva cuenta se estableció con el 4.1 pre contraseña. Así que tenía que actualizar la cuenta a un 41 byte contraseña válida.

La siguiente consulta demostró que, efectivamente, tienen contraseñas antiguas habilitados. Así que tengo que desactivar eso y actualizar la cuenta de usuario de nuevo para establecer la contraseña como válidos 41 bytes hash.

>SELECT @@session.old_passwords, @@global.old_passwords;
+-------------------------+------------------------+
| @@session.old_passwords | @@global.old_passwords |
+-------------------------+------------------------+
| 1 | 1 |
+-------------------------+------------------------+
1 row in set (0.00 sec)


>SET @@session.old_passwords = 0;
Query OK, 0 rows affected (0.00 sec)

>GRANT REPLICATION SLAVE ON *.* TO '<user>'@'<ip_address>' IDENTIFIED BY '<Password>';
Query OK, 0 rows affected (0.00 sec)

Una verificación de la contraseña mostró la contraseña como la contraseña 41byte ahora. Esto me podía conectar al servidor principal desde el servidor secundario y evitar el error secure_auth. replicación muy sencillo conectar problema estaba resuelto.

De cara al futuro que necesitaba para conseguir las cuentas de usuario de MySQL 5.0 en el servidor de MySQL 5.6. (Ya que ellos salté como parte de la construcción del servidor secundario.)

El cliente necesitaba para establecer las subvenciones de nuevo para cada usuario independientemente de una contraseña válidos o no.
Así que le di instrucciones a ejecutar el siguiente sql. Yo podría haber hecho esto, pero yo tendría que saber todas sus contraseñas y que no era necesario.

Para cada usuario en su sistema. Usted no tiene que hacer el usuario root, porque ya tiene una cuenta de administrador válida en el sistema 5.6.

>SET @@session.old_passwords = 0;
>show grants for '<User>'@'<Host>';
Para recopilar la sql necesaria para cada usuario ejecute el siguiente:
SELECT CONCAT("SHOW GRANTS FOR '",User,"'@'",Host,"';") as sql_command from mysql.user;

Para cada resultado dado ejecutar la sentencia "mostrar subvenciones" y luego ejecutar la instrucción dada.
Los estados deben ser similar a la siguiente:

GRANT USAGE ON *.* TO 'bob'@'%.example.org' IDENTIFIED BY 'cleartext password';

Replicación y luego crea y se rellena la tabla de MySQL en el servidor de MySQL 5.6.

Más se puede encontrar aquí:
http://dev.mysql.com/doc/refman/5.6/en/password-hashing.html

Tuesday, September 3, 2013

MySQL Optimización Sugerencia - thread_cache_size

Original post: http://anothermysqldba.blogspot.com/2013/09/mysql-optimization-tip-threadcachesize.html

Recientemente me encontré con una base de datos MySQL que fácilmente se ejecuta con 300 a 600 filas de la processlist. Las conexiones Max se estableció fácilmente más del doble de esta cantidad también. Este era un montaje que yo no estoy de acuerdo con. Me llamaron porque también demostró ser no estar funcionando muy bien. Así que aquí están algunos de mis pensamientos sobre el proceso he descubierto.

En mi opinión la mayoría de bases de datos MySQL en uso no se necesita una conexión Max o 1500 o más. Cuantas más conexiones que permiten la mayor carga de traer a su servidor. Utilice las conexiones de manera eficiente.
En segundo lugar, entender el% de Threads_created frente a las conexiones utilizadas. Usted podría considerar esto los hilos creados tasa de éxito. BTW .. Esta información no es nueva, esta es la información que se ha entendido en la comunidad desde hace algún tiempo. No pretendo presentar esto en ninguna otra manera de tratar de ayudar a otros. Así que haga lo siguiente para entender su actual%
estado como "Threads_created 'mostrará;
set @ Threads_created = <resultan de consulta anterior>;
mostrar el estado como "Conexiones";
@ configurar conexiones = <resultan de consulta anterior>;
seleccionar 100 - ((@ Threads_created / @ Conexiones) * 100) como "Threads_created% de las conexiones" \ G



Así que si su ejecutar el proceso anterior ¿cuál es su porcentaje? ¿Quieres que esto es lo más cercano a 100 como sea posible. Así, por ejemplo, el servidor que encontré hace poco tenía un% inferior al 10%. Entonces, ¿cómo se puede arreglar esto y aumentar su%?


La variable thread_cache_size tiene un valor predeterminado de 0. Si usted comienza a notar que su proceso de crecer y pero las consultas no son bloqueados por bloqueos y un largo etc, entonces usted debe comprobar su "Threads_created% de las conexiones", como se mencionó anteriormente. Es probable que el% será baja. Puede aumentar el% y mejorar drásticamente el rendimiento de su base de datos mediante la búsqueda del punto óptimo que se adapte a su entorno de servidor. El thread_cache_size se puede cambiar en un entorno real. Así que esto le permite establecer la variable luego monitorear el valor de estado de la "Threads_created" (ver más arriba para obtener el valor). Si esto sigue aumentando en valor, entonces seguirá planteando la thread_cache_size . Normalmente prefiero para elevar el valor por 25 a la vez por unos pocos y luego baje a 500 a la vez. A menudo la casilla "Threads_created% de las conexiones" y la "Threads_created '. Una vez que te acercas al punto dulce se dará cuenta de los% que ganar y el processlist para comenzar a disminuir en filas. Típicamente un ajuste más del thread_cache_size le conseguirá en el punto dulce.

Todos los servidores y el entorno es diferente.
Algunos servidores pueden ser un 98% con un thread_cache_size de 50, mientras que otros tienen un 98% con el thread_cache_size establecido en 15.000. El máximo es de 16384.

Así que si nada más ... averiguar lo que su porcentaje es primero y luego mirar a hacer ajustes.