Tan divertido tuvo que compartir ...

MySQL Bug # 20786 consigue pastel!

http://www.youtube.com/watch?v=oAiVsbXVP6k

La risa al final es la mejor parte.

MySQL Bug #20786 gets cake ! 

http://www.youtube.com/watch?v=oAiVsbXVP6k

The laugh at the end is the best part.
http://bugs.mysql.com/bug.php?id=20786

Copia de seguridad y recuperación de secuencias de comandos de MySQL usando innobackup y Xtrabackup de Percona

Original post: http://anothermysqldba.blogspot.com/2013/06/backup-and-recovery-script-for-mysql.html

Así Percona tiene el ampliamente utilizado herramienta de copia de seguridad Xtrabackup y se dan cuenta que todo el mundo a menudo utiliza esta herramienta en una secuencia de comandos de algún tipo. El disponer de una página que habla de esto:


Desde hace poco me dio un ejemplo de cómo utilizar la copia de seguridad en un anteriormensaje . Pensé que también podría escribir un script que muestra cómo automatizar el proceso de copia de seguridad. Además de que hace años que he escrito en Python, así que quería tener un poco de práctica también.

Así que la introducción del código está abajo, pero he puesto el script en github .
Se necesitan más pruebas pero no dude en consultar la base de código a cabo y actualizar y editar.

Una vez que el código se prueba más que pueda actualizar ejemplos pero quería estar abierta en este proyecto desde el principio.

Dado que es en las primeras etapas Yo recomiendo usar la opción - showcommands = 1 opción para que pueda ver lo que el código tiene previsto hacer y tal vez probar los comandos. Es evidente que no se debe utilizar en un sistema de producción todavía.

En primer lugar una introducción a la misma:


# ./backup_restore.py --help
Usage: backup_restore.py --process=[fullbackup,incremental,prepare,restore] --help --version --showcommands=1

This program enables you to backup full and incremental backups then prepare
and restore them using Percona's Xtrabackup

Options:
--version show program's version number and exit
-h, --help show this help message and exit
--process=PROCESS What would you like to do --process=
[fullbackup,incremental,prepare,restore]
--debug=DEBUG TURN DEBUG ON 1 OR OFF 0 OR VERBOSE 3
--showcommands=SHOWCOMMANDS
Shows the commands instead of executing them except
for the restore section because we go through that
step by step
--backup_root_directory=BACKUP_ROOT_DIRECTORY
THE ROOT DIRECTORY OF ALL YOUR BACKUPS, You can set
DEFAULT at start of the script
--percona_xtrabackup_location=PERCONA_XTRABACKUP_LOCATION
THE LOCATION OF YOUR xtrabackup FILE, You can set
DEFAULT at start of the script
--datadir=DATADIR MYSQL DATA DIR LOCATION, You can set DEFAULT at start
of the script
--username=DB_USERNAME
MySQL Username, You can set DEFAULT at start of the
script
--password=DB_PASSWORD
MySQL Password, You can set DEFAULT at start of the
script
--default_file=DEFAULT_FILE
MySQL my.cnf file location, You can set DEFAULT at
start of the script
--options=PERCONA_OPTIONS
Additional Options for innobackupex 

max_binlog_cache_size

Original post: http://anothermysqldba.blogspot.com/2013/06/maxbinlogcachesize.html

Al evaluar el rendimiento de su base de datos y la estabilidad es muy probable que usted comenzará a revisar sus variables.

A primera vista la típica primera reacción a las siguientes variables es .. ESPERA que algo está mal mi caja no tiene esa cantidad de RAM o incluso el espacio en disco para satisfacer esa MAX límites indicados a continuación ....


MariaDB [(none)]> select @@max_write_lock_count, @@max_binlog_cache_size, @@max_seeks_for_key, @@myisam_max_sort_file_size\G
*************************** 1. row ***************************
@@max_write_lock_count: 4294967295                    -- 4 GB
@@max_binlog_cache_size: 1844674407370954752         --1.6 EB
@@max_seeks_for_key: 429496729                        -- 4 GB
@@myisam_max_sort_file_size: 9223372036853727232       --8 EB 

Usted no está solo en las preocupaciones con estas variables como algunos errores se han enumerado sobre estas variables en los últimos años. A continuación se presentan sólo algunos de algunos legados queridos.

• http://bugs.mysql.com/bug.php?id=31177
• http://bugs.mysql.com/bug.php?id=56408
• http://bugs.mysql.com/bug.php?id=31066

" MySQL actualmente no puede trabajar con binarios Posiciones del registro de más de 4 GB . "
Tenga en cuenta que estos son sólo el defecto y los ajustes MAX. Usted puede ajustarlos para que se sienta más cómodo.


MariaDB [(none)]> SET GLOBAL max_binlog_cache_size = 4294967296;
Query OK, 0 rows affected (0.00 sec)

MariaDB [(none)]> SELECT @@max_binlog_cache_size;
+-------------------------+
| @@max_binlog_cache_size |
+-------------------------+
| 4294967296 | -- 4GB
+-------------------------+
1 row in set (0.00 sec) 

¿Por qué usted quiere ... Ese es un tema completamente diferente. Esto es sólo el límite superior permitido y las transacciones quedan divididos en 4 GB de todos modos. " El valor máximo recomendado es de 4 GB ", por lo que se puede actualizar si así lo desea también.

Lea más acerca de sus opciones con este en la documentación de MySQL: 

http://dev.mysql.com/doc/refman/5.5/en/replication-options-binary-log.html#sysvar_max_binlog_cache_size

MariaDB 10.0.3 Alfa instalación en Fedora 17 x86_64

Original post: http://anothermysqldba.blogspot.com/2013/06/mariadb-1003-alpha-install-on-fedora-17.html

MariaDB 10.0.3 Alfa se acaba de publicar.
Así que para aquellos de ustedes que recuerdan mi anterior MariaDB 5.5 posterior instalación, decidí ver cómo funciona con 10.0.3.

Me gustan algunas de las características que se van a las MariaDB y Percona lanzamientos. Incluso si usted es un gran defensor de MySQL , cuando las características están disponibles en estos comunicados que no están siendo de nuevo portado en MySQL comunicados DBAs tienen que revisar sus opciones y tomar una decisión.

Así que la instalación ....

Como he dicho antes de la entrada anterior tengo este instalado. Así que me limitaré a una actualización de primera.


[root@Fedora64 10]# rpm -qa | grep maria
mariadb-5.5.31-1.fc17.x86_64
mariadb-server-5.5.31-1.fc17.x86_64
mariadb-libs-5.5.31-1.fc17.x86_64
mariadb-bench-5.5.31-1.fc17.x86_64
mariadb-devel-5.5.31-1.fc17.x86_64

Paquetes para que entraban en conflicto al comienzo.


MariaDB-10.0.3-fedora17-x86_64-client.rpm
MariaDB-10.0.3-fedora17-x86_64-common.rpm
MariaDB-10.0.3-fedora17-x86_64-compat.rpm
MariaDB-10.0.3-fedora17-x86_64-connect-engine.rpm
MariaDB-10.0.3-fedora17-x86_64-devel.rpm
MariaDB-10.0.3-fedora17-x86_64-server.rpm
MariaDB-10.0.3-fedora17-x86_64-shared.rpm
MariaDB-10.0.3-fedora17-x86_64-test.rpm
[root@Fedora64 10]# rpm -Uhv *.rpm
warning: MariaDB-10.0.3-fedora17-x86_64-client.rpm: Header V3 DSA/SHA1 Signature, key ID 1bb943db: NOKEY
error: Failed dependencies:
libodbc.so.2()(64bit) is needed by MariaDB-connect-engine-10.0.3-1.x86_64
MySQL-devel conflicts with (installed) mariadb-devel-5.5.31-1.fc17.x86_64  

MariaDB-server-10.0.3-1.x86_64 conflicts with file from package mariadb-server-5.5.31-1.fc17.x86_64
[root@Fedora64 10]#

Así que esto es sólo un ejemplo Virtualbox , de demostración y evaluación, por lo que acaba de sacar todo lo que pude y tuve que desinstalar. Yo tenía la esperanza de que una actualización podría funcionar, pero este es el código Alfa todavía.
es decir:


[root@Fedora64 10]# rpm -e mariadb mariadb-server mariadb-bench
[root@Fedora64 10]# rpm -e mariadb-libs perl-DBD-MySQL percona-xtrabackup

Así que ahora que el pasado se borra ...


[root@Fedora64 10]# rpm -ihv *.rpm
Preparing... ########################################### [100%]
1:MariaDB-common ########################################### [ 11%]
2:MariaDB-server ########################################### [ 22%]
3:MariaDB-cassandra-engin########################################### [ 33%]
4:MariaDB-client ########################################### [ 44%]
5:MariaDB-devel ########################################### [ 56%]
6:MariaDB-shared ########################################### [ 67%]
7:MariaDB-test ########################################### [ 78%]
8:MariaDB-compat ########################################### [ 89%]
9:galera ########################################### [100%]

Si recuerdan el pasado después , tuve el guión init.d este momento ..


[root@Fedora64 10]# /etc/init.d/mysql start
Starting MySQL..... SUCCESS!
[root@Fedora64 10]# mysql
Welcome to the MariaDB monitor. Commands end with ; or \g.
Your MariaDB connection id is 2
Server version: 10.0.3-MariaDB MariaDB Server

Si ellos no son terribles en el rendimiento, entonces no veo por qué no se trata de forma predeterminada:


vi /etc/my.cnf
[mysqld]
userstat=1
# http://www.percona.com/doc/percona-server/5.5/diagnostics/user_stats.html?id=percona-server:features:userstatv2
# https://kb.askmonty.org/en/user-statistics/
feedback=ON
# https://kb.askmonty.org/en/user-feedback-plugin/
MariaDB [(none)]> show variables like '%feedback%';
+--------------------------+------------------------------------------+
| Variable_name | Value |
+--------------------------+------------------------------------------+
| feedback_send_retry_wait | 60 |
| feedback_send_timeout | 60 |
...
| feedback_url | https://mariadb.org/feedback_plugin/post |
| feedback_user_info | |
+--------------------------+------------------------------------------+
MariaDB [(none)]> show variables like '%userstat%';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| userstat | ON |
+---------------+-------+


Problemas que encontré 30 segundos después de la instalación ...:


MariaDB [(none)]> show variables;
ERROR 1946 (HY000): Failed to load replication slave GTID position from table mysql.gtid_slave_pos

Eso es todo lo que va ... Lo tengo instalado y puedo revisar ahora ...

ACTUALIZACIÓN: 
He presentado esto como un bug . El equipo MariaDB fue directo hacia mí y señaló que no pude ejecutar mysql_fix_privilege_tables y reiniciar. Eso ha corregido el error que aparece arriba. Todavía se siente como las variables que debe mostrar todo lo que tiene, pero esto es una solución válida y error de mi parte. Gracias a todo el equipo de MariaDB. 

Para obtener más información:

• https://kb.askmonty.org/en/mariadb-1003-release-notes/
• http://www.percona.com/live/mysql-conference-2013/sites/default/files/slides/mariadb10andwhatsnewwiththeproject-130426094744-phpapp01.pdf

MySQL < 5.5 replication to MySQL 5.6

Original post: http://anothermysqldba.blogspot.com/2013/06/mysql-55-replication-to-mysql-56.html

Después de horas de frustración ..... Voy a decirlo de manera simple como no actualizar a MySQL 5.6 si está ejecutando cualquier versión inferior a MySQL 5.5. 

Usted tiene que actualizar a MySQL 5.5 primero para mantener su cordura y datos de contacto. 

Un montón de blogs y la información disponibles sobre los cambios de contraseñas en MySQL 5.6 y los apoyan. Incluso he actualizado las contraseñas de MySQL 5.6 y la caja estaba en marcha y funcionando muy bien. El problema era la replicación. Tuve que repetir desde una versión MySQL menos de MySQL 5.5 y simplemente no corría. He desactivado secure_auth y podía conectar, pero aún no ha habido suerte con la replicación. 

Aunque apoyo la replicación como una ruta de actualización, se toman el tiempo y seguir con MySQL 5.5 por primera vez. 

Terminé degradar a MySQL 5.5 y todo funciona muy bien ahora. Si usted tiene que rebajar su versión de MySQL que tenía que seguir muchos de los mismos pasos que hice en mi mensaje Maria diaster para obtener la caja de nuevo.

Percona Xtrabackup / innobackupex copia de seguridad y el proceso de restauración

Original post: http://anothermysqldba.blogspot.com/2013/06/percona-xtrabackupinnobackupex-backup.html

Este es un ejemplo muy simple de cómo utilizar Percona Xtrabackup / innobackupex 

Este MariaDB sólo tiene la base de datos mundial en ella como un ejemplo de datos. 
Todo esto podría ser un guión, pero por ahora es para fines de demostración. 

Crear una copia de seguridad completa: 

MariaDB [(none)]> create database Start_Of_Demo; -- Just here for the demo
Query OK, 1 row affected (0.00 sec)

[root@Fedora64 src]# innobackupex --no-lock --parallel=4 --user=root --extra-lsndir=/usr/local/src/incremental_last_checkpoint/ --no-timestamp /usr/local/src/fullbackup/

xtrabackup: Transaction log of lsn (1597964) to (1597964) was copied.

innobackupex: Backup created in directory '/usr/local/src/fullbackup'
130609 15:41:39 innobackupex: Connection to database server closed
130609 15:41:39 innobackupex: completed OK!

[root@Fedora64 src]# ls -al fullbackup/
total 18472
drwxr-xr-x. 6 root root 4096 Jun 9 15:41 .
drwxr-xr-x. 6 root root 4096 Jun 9 15:49 ..
-rw-r--r--. 1 root root 260 Jun 9 15:41 backup-my.cnf
-rw-r-----. 1 root root 18874368 Jun 9 15:41 ibdata1
drwxr-xr-x. 2 root root 4096 Jun 9 15:41 mysql
drwxr-xr-x. 2 root root 4096 Jun 9 15:41 performance_schema
drwxr-xr-x. 2 root root 4096 Jun 9 15:41 Start_Of_Demo
drwxr-xr-x. 2 root root 4096 Jun 9 15:41 world
-rw-r--r--. 1 root root 13 Jun 9 15:41 xtrabackup_binary
-rw-r-----. 1 root root 89 Jun 9 15:41 xtrabackup_checkpoints
-rw-r-----. 1 root root 2560 Jun 9 15:41 xtrabackup_logfile


Crear una copia de seguridad incremental:

MariaDB [(none)]> create database incremental_1; -- Just here for the demo

Query OK, 1 row affected (0.00 sec)

[root@Fedora64 src]#innobackupex --incremental --no-lock --parallel=4 --no-timestamp --user=root --incremental-basedir=/usr/local/src/incremental_last_checkpoint/ --extra-lsndir=/usr/local/src/incremental_last_checkpoint/ /usr/local/src/incremental/

xtrabackup: Transaction log of lsn (1597964) to (1597964) was copied.

innobackupex: Backup created in directory '/usr/local/src/incremental'
130609 15:47:20 innobackupex: Connection to database server closed
130609 15:47:20 innobackupex: completed OK!

[root@Fedora64 src]# ls -al incremental
total 64
drwxr-xr-x. 7 root root 4096 Jun 9 15:47 .
drwxr-xr-x. 6 root root 4096 Jun 9 15:49 ..
-rw-r--r--. 1 root root 260 Jun 9 15:47 backup-my.cnf
-rw-r-----. 1 root root 16384 Jun 9 15:47 ibdata1.delta
-rw-r-----. 1 root root 44 Jun 9 15:47 ibdata1.meta
drwxr-xr-x. 2 root root 4096 Jun 9 15:47 incremental_1
drwxr-xr-x. 2 root root 4096 Jun 9 15:47 mysql
drwxr-xr-x. 2 root root 4096 Jun 9 15:47 performance_schema
drwxr-xr-x. 2 root root 4096 Jun 9 15:47 Start_Of_Demo
drwxr-xr-x. 2 root root 4096 Jun 9 15:47 world
-rw-r--r--. 1 root root 13 Jun 9 15:47 xtrabackup_binary
-rw-r-----. 1 root root 93 Jun 9 15:47 xtrabackup_checkpoints
-rw-r-----. 1 root root 2560 Jun 9 15:47 xtrabackup_logfile 

Cree otra copia de seguridad incremental:

MariaDB [(none)]> create database incremental_2;-- Just here for the demo

Query OK, 1 row affected (0.00 sec)

[root@Fedora64 src]# innobackupex --incremental --no-lock --parallel=4 --no-timestamp --user=root --incremental-basedir=/usr/local/src/incremental_last_checkpoint/ --extra-lsndir=/usr/local/src/incremental_last_checkpoint/ /usr/local/src/incremental_2/

xtrabackup: Transaction log of lsn (1597964) to (1597964) was copied.

innobackupex: Backup created in directory '/usr/local/src/incremental_2'
130609 15:49:49 innobackupex: Connection to database server closed
130609 15:49:49 innobackupex: completed OK!
[root@Fedora64 src]# ls -al incremental_2
total 68
drwxr-xr-x. 8 root root 4096 Jun 9 15:49 .
drwxr-xr-x. 6 root root 4096 Jun 9 15:49 ..
-rw-r--r--. 1 root root 260 Jun 9 15:49 backup-my.cnf
-rw-r-----. 1 root root 16384 Jun 9 15:49 ibdata1.delta
-rw-r-----. 1 root root 44 Jun 9 15:49 ibdata1.meta
drwxr-xr-x. 2 root root 4096 Jun 9 15:49 incremental_1
drwxr-xr-x. 2 root root 4096 Jun 9 15:49 incremental_2
drwxr-xr-x. 2 root root 4096 Jun 9 15:49 mysql
drwxr-xr-x. 2 root root 4096 Jun 9 15:49 performance_schema
drwxr-xr-x. 2 root root 4096 Jun 9 15:49 Start_Of_Demo
drwxr-xr-x. 2 root root 4096 Jun 9 15:49 world
-rw-r--r--. 1 root root 13 Jun 9 15:49 xtrabackup_binary
-rw-r-----. 1 root root 93 Jun 9 15:49 xtrabackup_checkpoints
-rw-r-----. 1 root root 2560 Jun 9 15:49 xtrabackup_logfile 

Ahora hay que tener esto en cuenta.

• Usted, por supuesto, la base de datos tiene que estar apagado.
• Si usted está haciendo una restauración lo más probable es que se estrelló de todos modos
• El directorio de datos debe estar vacío.

Asegúrese de que el servidor está apagado entonces claro nuestro directorio de datos.

[root@Fedora64 src]# ps -ef | grep mysql

root 4538 1940 0 15:54 pts/2 00:00:00 grep --color=auto mysql




[root@Fedora64 src]# ls -al /var/lib/mysql/

total 28724

drwxr-xr-x. 8 mysql mysql 4096 Jun 9 15:53 .

drwxr-xr-x. 43 root root 4096 Jun 8 19:41 ..

-rw-rw----. 1 mysql mysql 16384 Jun 9 15:53 aria_log.00000001

-rw-rw----. 1 mysql mysql 52 Jun 9 15:53 aria_log_control

-rw-r--r--. 1 mysql mysql 18874368 Jun 9 15:53 ibdata1

-rw-rw----. 1 mysql mysql 5242880 Jun 9 15:53 ib_logfile0

-rw-rw----. 1 mysql mysql 5242880 Jun 9 15:17 ib_logfile1

drwx------. 2 mysql mysql 4096 Jun 9 15:43 incremental_1

drwx------. 2 mysql mysql 4096 Jun 9 15:48 incremental_2

drwxr-xr-x. 2 mysql mysql 4096 Jun 9 15:16 mysql

drwxr-xr-x. 2 mysql mysql 4096 Jun 9 15:16 performance_schema

drwx------. 2 mysql mysql 4096 Jun 9 15:40 Start_Of_Demo

drwxr-xr-x. 2 mysql mysql 4096 Jun 9 15:16 world




[root@Fedora64 src]# rm -Rf /var/lib/mysql/*

Ahora hay que tener esto en cuenta. Al crear las copias de seguridad y copias de seguridad incrementales después, tendrá que restaurar la copia de seguridad completa y luego aplicar todas las copias de seguridad incrementales. Así que no creo que usted puede hacer una copia de seguridad completa de una tarde sólo restaurar desde la última copia incremental.Siempre tenga en cuenta el número de copias de seguridad incrementales que puede permitirse el lujo de mantener para que se solicite otra copia de seguridad completa.

Para restaurar sólo la copia de seguridad completa:

innobackupex --copy-back /usr/local/src/fullbackup/




innobackupex: Starting to copy InnoDB log files

innobackupex: in '/usr/local/src/fullbackup'

innobackupex: back to original InnoDB log directory '/var/lib/mysql'

innobackupex: Finished copying back files.




130609 15:54:57 innobackupex: completed OK!




[root@Fedora64 src]# ls -al /var/lib/mysql/

total 18456

drwxr-xr-x. 6 mysql mysql 4096 Jun 9 15:54 .

drwxr-xr-x. 43 root root 4096 Jun 8 19:41 ..

-rw-r--r--. 1 root root 18874368 Jun 9 15:54 ibdata1

drwxr-xr-x. 2 root root 4096 Jun 9 15:54 mysql

drwxr-xr-x. 2 root root 4096 Jun 9 15:54 performance_schema

drwxr-xr-x. 2 root root 4096 Jun 9 15:54 Start_Of_Demo

drwxr-xr-x. 2 root root 4096 Jun 9 15:54 world







[root@Fedora64 mysql]# mysql

Welcome to the MariaDB monitor. Commands end with ; or \g.

Your MariaDB connection id is 1

Server version: 5.5.31-MariaDB MariaDB Server

Eso hace la copia de seguridad completa, pero he hecho copias de seguridad incrementales después de eso. Por lo tanto, tendrá que ser apagado y el directorio de datos limpiado. ¿Por qué? Usted tiene que solicitar las copias de seguridad incrementales para el pleno y luego restaurarlo. Se lleva a cabo como en el siguiente ejemplo:

innobackupex --apply-log --redo-only /usr/local/src/fullbackup/

xtrabackup: starting shutdown with innodb_fast_shutdown = 1

130609 15:57:59 InnoDB: Starting shutdown...

130609 15:58:00 InnoDB: Shutdown completed; log sequence number 1597964

130609 15:58:00 innobackupex: completed OK!

Ahora apliquemos el primer directorio incrementales. Se puede ver en el siguiente ejemplo que el directorio incremental_1 se aplica ahora en el directorio fullbackup. Este no era el caso anteriormente.

innobackupex --apply-log --redo-only /usr/local/src/fullbackup/ --incremental-dir=/usr/local/src/incremental/

130609 15:58:42 innobackupex: completed OK!

[Root @ Fedora64 src] # ls-al fullbackup /

total de 20.520

drwxr-xr-x. 7 root root 4096 09 de junio 15:58.

drwxr-xr-x. 6 root root 4096 09 de junio 15:49 ..

-Rw-r - r -. 1 root root 260 09 de junio 15:41 backup-my.cnf

-Rw-r -----. 1 root root 18874368 09 de junio 15:58 ibdata1

drwxr-xr-x. 2 root root 4096 09 de junio 15:58 incremental_1

drwxr-xr-x. 2 root root 4096 09 de junio 15:41 mysql

drwxr-xr-x. 2 root root 4096 09 de junio 15:41 performance_schema

drwxr-xr-x. 2 root root 4096 09 de junio 15:41 Start_Of_Demo

drwxr-xr-x. 2 root root 4096 09 de junio mundo 15:41

-Rw-r - r -. 1 root pie 13 09 de junio 15:41 xtrabackup_binary

-Rw-r -----. 1 root root 89 09 de junio xtrabackup_checkpoints 15:58

-Rw-r -----. 1 root root 2097152 09 de junio 15:58 xtrabackup_logfile

Apliquemos ahora el segundo directorio incrementales. Se puede ver en el siguiente ejemplo que el directorio incremental_2 se aplica ahora en el directorio fullbackup. Este no era el caso anteriormente.

innobackupex --apply-log /usr/local/src/fullbackup/ --incremental-dir=/usr/local/src/incremental_2/

innobackupex: Copiar '/ usr/local/src/incremental_2/Start_Of_Demo/db.opt "a" / usr / local / src / fullbackup / Start_Of_Demo / db.opt'

130609 16:00:09 innobackupex: finalizado OK!

[Root @ Fedora64 src] # ls-al fullbackup /

total de 20.524

drwxr-xr-x. 8 root root 4096 09 de junio 16:00.

drwxr-xr-x. 6 root root 4096 09 de junio 15:49 ..

-Rw-r - r -. 1 root root 260 09 de junio 15:41 backup-my.cnf

-Rw-r -----. 1 root root 18874368 09 de junio 16:00 ibdata1

drwxr-xr-x. 2 root root 4096 09 de junio 15:58 incremental_1

drwxr-xr-x. 2 root root 4096 09 de junio 16:00 incremental_2

drwxr-xr-x. 2 root root 4096 09 de junio 15:41 mysql

drwxr-xr-x. 2 root root 4096 09 de junio 15:41 performance_schema

drwxr-xr-x. 2 root root 4096 09 de junio 15:41 Start_Of_Demo

drwxr-xr-x. 2 root root 4096 09 de junio mundo 15:41

-Rw-r - r -. 1 root pie 13 09 de junio 15:41 xtrabackup_binary

-Rw-r -----. 1 root root 89 09 de junio 16:00 xtrabackup_checkpoints

-Rw-r -----. 1 root root 2097152 09 de junio 15:58 xtrabackup_logfile

Apliquemos ahora el directorio de copia de seguridad completa. Se puede ver en el siguiente ejemplo que el directorio incremental_2 se aplica ahora en el directorio fullbackup. Este no era el caso anteriormente.

[root@Fedora64 src]# rm -Rf /var/lib/mysql/*

[Root @ Fedora64 src] # innobackupex - copy-back / usr / local / src / fullbackup /

[Root @ Fedora64 src] # chown-R mysql: mysql / var / lib / mysql

Todo ha sido restaurado y disponible:

[root@Fedora64 mysql]# mysql

Welcome to the MariaDB monitor. Commands end with ; or \g.

Your MariaDB connection id is 1

Server version: 5.5.31-MariaDB MariaDB Server




Copyright (c) 2000, 2013, Oracle, Monty Program Ab and others.




Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.




MariaDB [(none)]> show databases;

+--------------------+

| Database |

+--------------------+

| information_schema |

| Start_Of_Demo |

| incremental_1 |

| incremental_2 |

| mysql |

| performance_schema |

| world |

+--------------------+

Enlaces disponibles para referencia.

• http://dev.mysql.com/doc/index-other.html
• http://www.percona.com/doc/percona-xtrabackup/2.1/innobackupex/creating_a_backup_ibk.html
• http://www.percona.com/doc/percona-xtrabackup/2.1/innobackupex/preparing_a_backup_ibk.html
• http://www.percona.com/doc/percona-xtrabackup/2.1/innobackupex/incremental_backups_innobackupex.html
• http://www.percona.com/doc/percona-xtrabackup/2.1/innobackupex/partial_backups_innobackupex.html
• http://www.percona.com/doc/percona-xtrabackup/2.1/innobackupex/restoring_a_backup_ibk.html

Desastres yum install MariaDB / MySQL, pero fija

Original post: http://anothermysqldba.blogspot.com/2013/06/yum-install-mariadbmysql-disaster-but.html

Así que esto debe ser una instalación fácil de MariaDB / MySQL. Yo no creo que esto era una cuestión Maria pero sólo un fallo general. Esto es lo que sucedió y cómo lo arreglé.

yum install MariaDB-servidor
Entonces añadí el resto a tener lo que aparece a continuación.

[root@Fedora64 log]# rpm -qa | grep maria
mariadb-5.5.31-1.fc17.x86_64
mariadb-server-5.5.31-1.fc17.x86_64
mariadb-libs-5.5.31-1.fc17.x86_64
mariadb-devel-5.5.31-1.fc17.x86_64


Pensé que era extraño que no he tenido un fichero / etc / init.d / mysql pero me fui con él, quería ver qué pasaba.

[root@Fedora64 log]# mysqld_safe
130608 19:54:36 mysqld_safe Logging to '/var/log/mysqld.log'.
130608 19:54:37 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
130608 19:54:39 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended

130608 19:54:37 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
130608 19:54:37 InnoDB: The InnoDB memory heap is disabled
130608 19:54:37 InnoDB: Mutexes and rw_locks use GCC atomic builtins
130608 19:54:37 InnoDB: Compressed tables use zlib 1.2.5
130608 19:54:37 InnoDB: Using Linux native AIO
130608 19:54:37 InnoDB: Initializing buffer pool, size = 128.0M
130608 19:54:37 InnoDB: Completed initialization of buffer pool
130608 19:54:37 InnoDB: highest supported file format is Barracuda.
130608 19:54:38 InnoDB: Waiting for the background threads to start
130608 19:54:39 Percona XtraDB (http://www.percona.com) 5.5.31-MariaDB-30.2 started; log sequence number 1597945
130608 19:54:39 [Note] Plugin 'FEEDBACK' is disabled.
130608 19:54:39 [ERROR] Can't open the mysql.plugin table. Please run mysql_upgrade to create it.
130608 19:54:39 [Note] Server socket created on IP: '0.0.0.0'.
130608 19:54:39 [ERROR] Fatal error: Can't open and lock privilege tables: Table 'mysql.host' doesn't exist
130608 19:54:39 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended


Wow ... La primera carrera y el fracaso no es una buena señal. Este es un directorio mysql nueva instalación debería haber sido instalado. Así que empecé con - skip-grant-tables para poder entrar en la caja y mirar a su alrededor.

[root@Fedora64 mysql]# ls -la
total 28700
drwxr-xr-x. 2 mysql mysql 4096 Jun 8 19:58 .
drwxr-xr-x. 43 root root 4096 Jun 8 19:41 ..
-rw-rw----. 1 mysql mysql 16384 Jun 8 19:50 aria_log.00000001
-rw-rw----. 1 mysql mysql 52 Jun 8 19:50 aria_log_control
-rw-rw----. 1 mysql mysql 18874368 Jun 8 19:50 ibdata1
-rw-rw----. 1 mysql mysql 5242880 Jun 8 19:58 ib_logfile0
-rw-rw----. 1 mysql mysql 5242880 Jun 8 19:45 ib_logfile1
[root@Fedora64 mysql]#

[root@Fedora64 mysql]# mysqld_safe --skip-grant-tables
130608 20:02:45 mysqld_safe Logging to '/var/log/mysqld.log'.
130608 20:02:45 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql


Aceptar lo que empezó ... y lo hace correr, pero sigue siendo un problema importante aún ninguna mesa MYSQL!

[root@Fedora64 /]# mysql_upgrade
Phase 1/3: Fixing table and database names
Phase 2/3: Checking and upgrading tables
Processing databases
information_schema
Phase 3/3: Running 'mysql_fix_privilege_tables'...
ERROR 1049 (42000): Unknown database 'mysql'
FATAL ERROR: Upgrade failed


Esto todavía puede ser fijado ....

[root@Fedora64 /]# mysql
Welcome to the MariaDB monitor. Commands end with ; or \g.
Your MariaDB connection id is 10
Server version: 5.5.31-MariaDB MariaDB Server

Copyright (c) 2000, 2013, Oracle, Monty Program Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MariaDB [(none)]> show databases;
+--------------------+
| Database |
+--------------------+
| information_schema |
+--------------------+
1 row in set (0.01 sec)

MariaDB [(none)]> create database mysql ;
Query OK, 1 row affected (0.13 sec)

MariaDB [(none)]> exit
Bye

Aceptar ahora tiene una tabla mysql debería ser capaz de actualizarlo

[root@Fedora64 /]# mysql_upgrade
Phase 1/3: Fixing table and database names
Phase 2/3: Checking and upgrading tables
Processing databases
information_schema
mysql
Phase 3/3: Running 'mysql_fix_privilege_tables'...
OK
[root@Fedora64 /]#

Ok, así que dejé de mysqld y empecé sin - skip-subvenciones después de todo lo que acaba de instalar y aún no he establecido una contraseña.

[root@Fedora64 mysql]# mysqld_safe
[root@Fedora64 /]# mysql
ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: NO)


Ok, así que voy a tratar de nuevo ...

[root@Fedora64 mysql]# mysqld_safe --skip-grant-tables

MariaDB [mysql]> show tables;
+---------------------------+
| Tables_in_mysql |
+---------------------------+
| columns_priv |
| db |
| event |
| func |
| general_log |
| help_category |
| help_keyword |
| help_relation |
| help_topic |
| host |
| ndb_binlog_index |
| plugin |
| proc |
| procs_priv |
| proxies_priv |
| servers |
| slow_log |
| tables_priv |
| time_zone |
| time_zone_leap_second |
| time_zone_name |
| time_zone_transition |
| time_zone_transition_type |
| user |
+---------------------------+
24 rows in set (0.01 sec)

MariaDB [mysql]> select * from user;
Empty set (0.00 sec)

MariaDB [(none)]> create user root ;


No puedo utilizar el siguiente comando porque - skip-grant-tables en habilitados.
crear el usuario root identificado por'';

Así que ahora tengo un usuario root sólo por su nombre porque tiene cero privilegios.

MariaDB [(none)]> show databases;
+--------------------+
| Database |
+--------------------+
| information_schema |
+--------------------+
1 row in set (0.00 sec)


Así que tengo que ir a la caja de nuevo con - skip-grant-tables habilitado y actualizo la cuenta de root

UPDATE user
SET Select_priv = 'Y',
Insert_priv='Y',
Update_priv='Y',
Delete_priv='Y',
Create_priv='Y',
Drop_priv='Y',
Reload_priv='Y',
Shutdown_priv='Y',
Process_priv='Y',
File_priv='Y',
Grant_priv='Y',
References_priv='Y',
Index_priv='Y',
Alter_priv='Y',
Show_db_priv='Y',
Super_priv='Y',
Create_tmp_table_priv='Y',
Lock_tables_priv='Y',
Execute_priv='Y',
Repl_slave_priv='Y',
Repl_client_priv='Y',
Create_view_priv='Y',
Show_view_priv='Y',
Create_routine_priv='Y',
Alter_routine_priv='Y',
Create_user_priv='Y',
Event_priv='Y',
Trigger_priv='Y',
Create_tablespace_priv='Y'
WHERE user = 'root';

Ahora un reinicio sin - skip-grant-tables habilitadas y estoy como root!

[root@Fedora64 /]# ps -ef | grep mysql
root 4522 1513 0 20:26 pts/0 00:00:00 /bin/sh /bin/mysqld_safe
mysql 4650 4522 0 20:27 pts/0 00:00:03 /usr/libexec/mysqld --basedir=/usr --datadir=/var/lib/mysql --plugin-dir=/usr/lib64/mysql/plugin --user=mysql --log-error=/var/log/mysqld.log --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/lib/mysql/mysql.sock
root 8348 3178 0 20:47 pts/1 00:00:00 grep --color=auto mysql
[root@Fedora64 /]# mysql
Welcome to the MariaDB monitor. Commands end with ; or \g.
Your MariaDB connection id is 2
Server version: 5.5.31-MariaDB MariaDB Server

Copyright (c) 2000, 2013, Oracle, Monty Program Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MariaDB [(none)]>


Menos mal. Esto es más de un ejemplo de cómo solucionarlo cuando las cosas van mal, pero todavía querían el archivo / etc / init.d / mysql

Pivot mesa o no Tabla Pivot

Original post: http://anothermysqldba.blogspot.com/2013/06/piviot-table-or-no-pivot-table.html

Este tema hace poco apareció en la forums.mysql.com sitio.

La opinión expresada fue que las tablas dinámicas son muy difíciles de escalar y mantener valdría la pena un rediseño del esquema en lugar de una tabla dinámica. Esta es una opinión válida con puntos válidos.

Me gustaría agregar el tema para ayudar a expresar mi punto de vista y que esté disponible para los demás.

Todo depende de los datos que se reunieron en si debe usar una tabla dinámica o no. El ejemplo que se da en un post anterior por mí era sólo un ejemplo de cómo funcionan.

Si usted está recogiendo información de usuario conocida (Nombre y Apellido, información de la dirección, teléfono), entonces sí una tabla dinámica es más compleja que lo que se necesita. Si sólo tiene un par de puntos de datos para atarlos a las afueras de esa información básica, entonces sí otra tabla es una solución y atado con una combinación simple.

El concepto de tabla dinámica es válido cuando se trata de cantidades dinámicas de datos por entidad está recopilando.
Es posible que tenga 10 puntos de datos para 100 usuarios. Es posible que tenga 500 puntos de datos en los próximos 100 usuarios. ¿Puede el esquema manejarlo con facilidad?

El ejemplo dado en la entrada anterior estoy de acuerdo no requiere una tabla dinámica. Pero acabo de utilizar el concepto que me han dado en el foro para responder a la pregunta planteada.

Lo ideal es que usted puede usar las dos soluciones en el esquema. Puntos de datos básicos, tenga en columnas. Los datos dinámicos mantienen en tablas dinámicas.

Si se construye correctamente, es muy escalable, los miles de millones y miles de millones de datos que almacena en la tabla dinámica demostró esto a mí fácilmente. Eso no quiere decir que no requeriría algún trabajo. Usted puede muy bien ser que encuentre que la creación de algunos puntos de vista o las tablas de resumen que se ven en la tabla dinámica sería más fácil para que otros puedan recopilar datos. Esto plantea la pregunta ¿por qué no fue a los datos almacenados de esta manera en el primer lugar? Una vez más, depende de la naturaleza dinámica de los datos y las aplicaciones que utilizan los datos.

MEMORIA y tablas temporales

Original post: http://anothermysqldba.blogspot.com/2013/06/memory-and-temporary-tables.html

Desde que he recibido una petición para ayudar a responder preguntas forum.mysql.com con el blog voy a seguir para publicar algunos ejemplos extendidos aquí.

Me di cuenta de este post: http://forums.mysql.com/read.php?10, 588192,588192 # msg-588192 y pensé por primera vez de un modo diferente de manejar la situación.

Si usted necesita las tablas para manejar la información temporal que puede ir sobre ella de dos maneras. Uno si es por cada sesión de tratamiento, entonces debería crear una tabla temporal sólo:

CREATE TEMPORARY TABLE `temporary_table` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`date_updated` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
PRIMARY KEY (`id`)
) ;

Esto dará lugar a NO frm. Y desaparecerá y cierre de la sesión.
Si usted lo necesita más tiempo disponible y lo necesita para ser rápido se puede utilizar una tabla MEMORY. Esta permanecerá hasta que se reinicie la base de datos, eliminar la tabla, etc ..

CREATE TABLE `memory_table` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`date_updated` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
PRIMARY KEY (`id`)
) ENGINE=MEMORY;

Esto significa que una vez más no hay ningún archivo. Frm.

Así que si quieres ir a limpiar las tablas de memoria de hasta porque tiene tantos o algo que usted puede encontrar una lista con la siguiente ...

SELECT TABLE_SCHEMA, ENGINE, COUNT(*) AS count_tables,
SUM(DATA_LENGTH+INDEX_LENGTH) AS size,
SUM(INDEX_LENGTH) AS index_size FROM INFORMATION_SCHEMA.TABLES
WHERE TABLE_SCHEMA NOT IN ('mysql', 'INFORMATION_SCHEMA')
AND ENGINE = "MEMORY" GROUP BY TABLE_SCHEMA, ENGINE;

Como siempre ... revisar sus necesidades y de referencia lo que funciona mejor para usted y su aplicación.

Las tablas pivote ejemplo en MySQL

Original post: http://anothermysqldba.blogspot.com/2013/06/pivot-tables-example-in-mysql.html

Me preguntaron sobre la forums.mysql.com sitio cómo construir una tabla de suscripción para seguir los cursos y etc

Era más fácil para publicar el ejemplo completo aquí, es un ejemplo breve resumen, pero usted consigue la idea.

El concepto es simple.
Nosotros guardamos la información en filas que podemos tirar de vuelta en diferentes columnas cuando sea necesario.

La solicitud era para una suscripción de estudiantes y cursos ....

Primero construí algunas tablas y datos ...


CREATE TABLE `details` (
`details_id` int(11) NOT NULL AUTO_INCREMENT,
`details_label` varchar(100) DEFAULT NULL,
PRIMARY KEY (`details_id`)
) ENGINE=InnoDB;
INSERT INTO details VALUES (1,'First Name') , (2, 'Last Name') ;

CREATE TABLE `subjects` (
`subject_id` int(11) NOT NULL AUTO_INCREMENT,
`subject` enum('History','English','Geography','Mathematics','Science','Social Studies','Foreign Languages','Visual and Performing Arts') DEFAULT NULL,
`subject_detail` varchar(255) DEFAULT NULL,
PRIMARY KEY (`subject_id`)
) ENGINE=InnoDB;
INSERT INTO subjects VALUES (1,'Mathematics', 'Algebra') , (2,'History', '1826-1926') , (3,'Geography', ' Africa Studies') ;

CREATE TABLE `student` (
`student_id` int(11) NOT NULL AUTO_INCREMENT,
`email` varchar(150) DEFAULT NULL,
`student_key` varchar(20) DEFAULT NULL,
`date_updated` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
PRIMARY KEY (`student_id`)
) ENGINE=InnoDB;
INSERT INTO student (`student_id` ,`email`,`student_key`) VALUES (1,'foobar@gmail.com','iasdjf');

CREATE TABLE `student_details` (
`student_details_id` int(11) NOT NULL AUTO_INCREMENT,
`student_id` int(11) DEFAULT 0,
`details_id` int(11) DEFAULT 0,
`details_value` varchar(255) DEFAULT NULL,
`date_updated` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
PRIMARY KEY (`student_details_id`)
) ENGINE=InnoDB;
INSERT INTO student_details VALUES (NULL,1,1,'John',NOW()) , (NULL,1,2,'Smith',NOW()) ;

CREATE TABLE `courselist` (
`courselist_id` int(11) NOT NULL AUTO_INCREMENT,
`student_id` int(11) DEFAULT 0,
`subject_id` int(11) DEFAULT NULL,
`status` enum('Waitlisted','Subscribed','Denied') DEFAULT NULL,
`date_updated` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
PRIMARY KEY (`courselist_id`)
) ENGINE=InnoDB;
INSERT INTO courselist VALUES ( NULL,1, 1 , 'Waitlisted' , NOW() ) , ( NULL,1, 2 , 'Subscribed' , NOW() ) , ( NULL,1, 3 , 'Denied' , NOW() ) ;

Primero simplemente sacar información sobre el estudiante:


> SELECT s.student_id , d.details_label , sd.details_value
-> FROM student s
-> INNER JOIN student_details sd ON s.student_id = sd.student_id
-> INNER JOIN details d ON sd.details_id = d.details_id;
+------------+---------------+---------------+
| student_id | details_label | details_value |
+------------+---------------+---------------+
| 1 | First Name | John |
| 1 | Last Name | Smith |
+------------+---------------+---------------+
2 rows in set (0.00 sec)

Podemos profundizar más y seguir sumando información ...


> SELECT s.student_id , d.details_label , sd.details_value , c.status, j.subject, j.subject_detail
-> FROM student s
-> INNER JOIN student_details sd ON s.student_id = sd.student_id
-> INNER JOIN details d ON sd.details_id = d.details_id
-> INNER JOIN courselist c ON s.student_id = c.student_id
-> INNER JOIN subjects j ON j.subject_id = c.subject_id
-> ;
+------------+---------------+---------------+------------+-------------+-----------------+
| student_id | details_label | details_value | status | subject | subject_detail |
+------------+---------------+---------------+------------+-------------+-----------------+
| 1 | First Name | John | Waitlisted | Mathematics | Algebra |
| 1 | Last Name | Smith | Waitlisted | Mathematics | Algebra |
| 1 | First Name | John | Subscribed | History | 1826-1926 |
| 1 | Last Name | Smith | Subscribed | History | 1826-1926 |
| 1 | First Name | John | Denied | Geography | Africa Studies |
| 1 | Last Name | Smith | Denied | Geography | Africa Studies |
+------------+---------------+---------------+------------+-------------+-----------------+
6 rows in set (0.00 sec)

Eso no es muy útil o limpia, aunque ...
Así que de nuevo esta para tirar exactamente lo que queremos ...


> SELECT s.student_id ,sd1.details_value as FIRST_NAME, sd2.details_value as LAST_NAME, c.status, j.subject, j.subject_detail
-> FROM student s
-> INNER JOIN student_details sd1 ON s.student_id = sd1.student_id AND sd1.details_id = 1
-> INNER JOIN student_details sd2 ON s.student_id = sd2.student_id AND sd2.details_id = 2
-> INNER JOIN courselist c ON s.student_id = c.student_id
-> INNER JOIN subjects j ON j.subject_id = c.subject_id
-> ;
+------------+------------+-----------+------------+-------------+-----------------+
| student_id | FIRST_NAME | LAST_NAME | status | subject | subject_detail |
+------------+------------+-----------+------------+-------------+-----------------+
| 1 | John | Smith | Waitlisted | Mathematics | Algebra |
| 1 | John | Smith | Subscribed | History | 1826-1926 |
| 1 | John | Smith | Denied | Geography | Africa Studies |
+------------+------------+-----------+------------+-------------+-----------------+
3 rows in set (0.00 sec)

MySQL Tabla de comprobación

Original post: http://anothermysqldba.blogspot.com/2013/06/mysql-check-table.html

El comando Check tablas MySQL es muy útil para cualquier persona que quiera hacer lo siguiente:

• Comprobación de compatibilidad de versiones
• Comprobación de coherencia de datos
• Actualizaciones
• Errores de la tabla general

El proceso es bastante simple:

> show tables;
+-----------------+
| Tables_in_world |
+-----------------+
| City |
| Country |
| CountryLanguage |
+-----------------+

> check table City\G
*************************** 1. row ***************************
Table: world.City
Op: check
Msg_type: status
Msg_text: OK

Esta es una buena tarea para mantenerte actualizado sobre lo que son conscientes de los posibles errores. Un posible problema es que esta herramienta realmente se centra en MyISAM y InnoDB no. Si lo usa para InnoDB, el comando "mesa Check" en realidad sólo se aplica cuando se agrega la opción RÁPIDA (o sin opciones). Las opciones de FAST, cambiado, mediana y larga están ignorados por InnoDB. Ahora, si usted se está preguntando, ¿qué pasa con InnoDB? ¿Por qué ignorar MySQL consistencia de datos en el motor InnoDB? Tome una respiración profunda y relajarse, InnoDB se queja ACID , ACID es " un pie acrónimo de atomicidad, coherencia, aislamiento y durabilidad. " Así que no ignore comprobar tablas InnoDB porque todavía puede proporcionar alguna información o la confirmación en sus mesas. Tenga en cuenta que si una tabla InnoDB era estar dañado el servidor se apagará para proteger los datos. Usted acaba de obtener más por tu dinero con tablas MyISAM y esta herramienta.

Esperemos que se obtiene una respuesta de "OK" o "tabla ya está al día" en caso contrario es necesario ejecutar una mesa de reparación para arreglar la mesa.

¿Cuáles son las opciones disponibles para nosotros, así que usted puede hacer esto a menudo y fácilmente.
El enlace siguiente documentación también le proporcionará con varias comunidades impulsada opciones automáticas. Usted puede crear un script que el proceso y mostrar fácilmente las tablas a continuación, realizar controles mediante tablas de todos los resultados. Simplemente parece más fácil para mí, aunque para utilizar las herramientas proporcionadas para usted.


$ mysqlcheck -u root -p --databases world --fast
Enter password:
world.City OK
world.Country OK
world.CountryLanguage OK

$mysqlcheck -u root -p --databases world --fast --check-only-changed
Enter password:
world.City OK
world.Country OK
world.CountryLanguage OK

Ahora bien, esto es simple y directo, pero también se presta a otra pregunta, ¿Qué pasa con la contraseña?

En caso de que crear un usuario sin contraseña que se le permite comprobar las tablas sólo para que usted no tiene que poner una contraseña en su script o tarea programada? Usted quiere evitar tener la contraseña sentados en los archivos. Mysql_history también. Así que una vez más tomar ventaja de las herramientas disponibles para usted. MySQL 5.6 introduce la Utilidad de configuración de MySQL . Tengo un ejemplo de cómo configurarlo en un blog anterior:
http://anothermysqldba.blogspot.com/2013/05/mysql-users-grants-mysqlconfigeditor.html

mysqlcheck --login-path=local --databases world --fast --check-only-changed
world.City OK
world.Country OK
world.CountryLanguage OK

$ Mysqlcheck - help proporcionará una lista completa de opciones disponibles para usted.
Ahora, usted puede comprobar todas las tablas, mantener sus contraseñas del archivo crontab y / o scripts.

Documentación:

• http://dev.mysql.com/doc/refman/5.5/en/check-table.html