Plataforma Educativa Universidad del SABES
Materia: Base de Datos II
3.1.3. Bitcoras
Visin general de la Redo Log Online.
La estructura ms importante para la recuperacin es el registro log (redo log) en
lnea, que consiste en dos o ms archivos preasignados que almacenan los cambios
en la base de datos a medida que ocurren. Redo log registra los cambios en los
archivos de datos.
El uso del Redo Log Online.
La base de datos mantiene en los archivos redo log un registro para protegerla
contra la prdida de datos. Especficamente, despus que una instancia falla, los
archivos del registro redo log en lnea de Oracle Database permiten recuperar los
datos committed an si estos no han sido escritos en los archivos de datos.
Oracle Database escribe cada transaccin sincronizndola con el buffer de redo log,
los cuales son escritos en los registros log en lnea. El contenido del registro incluye
transacciones no confirmadas, deshacer datos, y el esquema y los estados de
gestin de objetos.
Oracle Database utiliza el redo log en lnea slo para la recuperacin. Sin embargo,
los administradores pueden consultar los archivos redo log en lnea a travs de una
interfaz de SQL, la utilidad Oracle LogMiner. Los archivos de registro redo log son
una fuente til de informacin histrica sobre la actividad de la base de datos.
Cmo Oracle Database escribe a los Redo Log Online.
El redolog en lnea para una instancia de la base de datos se denomina un hilo redo.
En las configuraciones de instancia nica, una sola instancia tiene acceso a una
base de datos, por lo que slo un hilo redo est presente. En una configuracin
Oracle Real Application Clusters (Oracle RAC), sin embargo, cuando dos o ms
instancias concurren en el acceso a una base de datos al mismo tiempo, cada
instancia tiene su propio hilo redo. Un hilo redo separado para cada instancia evita
el conflicto por un simple acceso a los archivos redo log en lnea.
Un redo log en lnea consiste en dos o ms archivos redo log en lnea. Oracle
Database requiere un mnimo de dos archivos para garantizar que uno este siempre
disponible para la escritura, mientras que el otro est siendo utilizado para
archivados (si la base de datos est en modo ARCHIVELOG).
Pgina 1 de 16
Plataforma Educativa Universidad del SABES
Materia: Base de Datos II
Cambio del redo log en lnea.
Oracle Database utiliza solo un archivo redo log en lnea a la vez para almacenar
los registros escritos del bfer redo log. El archivo redo log en lnea para el proceso
de registro del escritor (LGWR), cuando est escribiendo activamente se llama el
archivo redo log en lnea actual.
Una interrupcin de registro se produce cuando la base de datos deja de escribir en
un archivo redo log en lnea y comienza a escribir a otro. Normalmente, se produce
un cambio en el archivo redo log en lnea cuando el actual est lleno y la escritura
debe continuar. Sin embargo, se puede configurar switches de registro, para que
estos se produzcan a intervalos regulares, con independencia de que el archivo
redo log en lnea actual est lleno, y el registro de la fuerza cambia manualmente.
El log writer escribe en los registros en lnea redolog circularmente. Cuando el
escritor de registro se llena con el ltimo archivo redo log en lnea disponible, el
proceso escribe en el primer archivo de registro, reiniciando el ciclo.
La figura 11-6 ilustra la escritura circular del redo log.
Figura 11-6 La reutilizacin de los archivos redo log en lnea
Los nmeros en la Figura 11-6 muestra la secuencia en la que LGWR escribe a
cada archivo redo log en lnea. La base de datos asigna a cada archivo un nuevo
nmero de secuencia de registro cuando un registro de interruptores y escritores de
registro comienza a escribir a la misma. Cuando la base de datos vuelve a utilizar
un archivo redo log en lnea, el archivo recibe el siguiente nmero de secuencia de
registros disponibles.
Los Archivos redo log en lnea de relleno estn disponibles para su reutilizacin en
funcin del modo de archivo:
Si el archivo est desactivado, lo que significa que la base de datos est en modo
NOARCHIVELOG, entonces a continuacin, un archivo redo log en lnea lleno
estar disponible despus de que los cambios sean registrados en el mismo, y esto
ha sido el punto de control (escrito) al disco por la database writer (DBWn).
Si est activado el archivo, lo que significa que la base de datos est en modo
ARCHIVELOG, entonces a continuacin, despus que un archivo redo log en lnea
est lleno, estar disponible para iniciar la escritura despus de que los cambios
se han escrito en los archivos de datos y el archivo se ha archivado.
En algunas circunstancias, el registro de escritura puede ser impedido de volver a
utilizar un archivo redo log en lnea existente. Por ejemplo, un archivo redo log en
lnea puede ser activo (necesario para la recuperacin de la instancia) en lugar de
inactivos (no es necesario para la recuperacin).
Adems, un archivo redo log en lnea puede estar en el proceso de borrado.
Pgina 2 de 16
Plataforma Educativa Universidad del SABES
Materia: Base de Datos II
Varias copias de los archivos redo log en lnea.
Oracle Database puede mantener automticamente dos o ms copias idnticas del
redo log en lnea en lugares separados. Un grupo de redo log en lnea consiste en
un archivo redo log en lnea y sus copias redundantes. Cada copia idntica de un
miembro del grupo redo log en lnea. Cada grupo est definido por un nmero, tal
como el grupo 1, grupo 2, y as sucesivamente.
El mantenimiento de varios miembros de un grupo de redo log en lnea protege
contra la prdida del redo log. Lo ideal sera que la ubicacin de los miembros
deberan estar en discos diferentes para que el fallo de un disco no causa la prdida
de la totalidad del redo log en lnea.
En la Figura 11-7, A_LOG1 y B_LOG1 son miembros iguales del grupo 1, mientras
que A_LOG2 y B_LOG2 son miembros iguales del grupo 2. Cada miembro de un
grupo debe ser del mismo tamao. LGWR escribe al mismo tiempo al grupo 1
(miembros A_LOG1 y B_LOG1), a continuacin, escribe simultneamente al grupo
2 (miembros A_LOG2 y B_LOG2), a continuacin, se escribe en el grupo 1, y as
sucesivamente. LGWR nunca escribe al mismo tiempo a los miembros de los
diferentes grupos.
Figura 11-7 varias copias de los archivos redo log en lnea
Oracle recomienda multiplex el redo log en lnea. La prdida de archivos de registro
puede ser catastrfico si se requiere la recuperacin. Cuando multiplex el redo log
en lnea, la base de datos debe aumentar la cantidad de E / S que realiza. En funcin
del sistema, esta I / O adicional puede afectar el rendimiento general de bases de
datos.
Archivos redo log archivados
Un archivo redo log archivado es una copia de un miembro de lleno de un grupo de
redo log en lnea. Este archivo no se considera parte de la base de datos, pero es
una copia sin conexin de un archivo redo log en lnea creado por la base de datos
y se escriben en una ubicacin especificada por el usuario.
Los archivos redo log archivados son una parte fundamental de una estrategia de
backup y recuperacin. Usted puede utilizar archivados rehacer los archivos de
registro a:
Recuperar una copia de seguridad de base de datos
Actualizacin de una base de datos en espera
Obtener informacin sobre la historia de una base de datos mediante la
Pgina 3 de 16
Plataforma Educativa Universidad del SABES
Materia: Base de Datos II
utilidad LogMiner
Archivar es la operacin de generar un archivo redo log archivados.
El almacenamiento automtico o manual y slo es posible cuando la base de datos
est en modo ARCHIVELOG.
Un archivo redo log archivados redo incluye las entradas y el nmero de secuencia
de registro de la pieza idntica del grupo redo log en lnea. En la Figura 11-7,
archivos A_LOG1 y B_LOG1 son miembros idnticos de Grupo 1. Si la base de
datos est en modo ARCHIVELOG, y si est habilitado el archivado automtico,
entonces el proceso archivador (ARCn) archivar uno de estos archivos. Si A_LOG1
est daado, entonces el proceso puede archivar B_LOG1. El redo log archivados
contiene una copia de todos los grupos creados desde que habilit el archivado.
Vea tambin:
"La recuperacin del archivo de datos"
Gua del administrador de base de datos Oracle para aprender a manejar el redo
log archivados
Estructura del Redo Log Online
Los archivos redo log en lnea contienen registros de rehacer. Un redo log se
compone de un grupo de vectores de cambio, cada una de las cuales describe un
cambio a un bloque de datos. Por ejemplo, una actualizacin de un salario en la
tabla de empleados genera un registro redo que describe los cambios en el
segmento de bloque de datos de la tabla, el bloque de datos de deshacer segmento,
y la mesa de operaciones de los segmentos de deshacer.
Los registros de rehacer tienen todos los metadatos relevantes para el cambio,
incluyendo las siguientes:
SCN y hora del cambio
Identificacin de la transaccin de la transaccin que ha generado el cambio
sello SCN y la hora cuando se cometa la transaccin (si el compromiso)
El tipo de operacin que se realiz el cambio
Nombre y tipo del segmento de datos modificado
Pgina 4 de 16
Plataforma Educativa Universidad del SABES
Materia: Base de Datos II
Los ficheros de registro (log) de MySQL
MySQL tiene varios archivos de registro diferentes que pueden ayudarle a encontrar lo que est
ocurriendo en mysqld:
Por defecto, todos los registros son creados en el directorio de datos de mysqld. Puede forzar a
mysqld a que cierre y reabra los archivos de registro (o en algunos casos, cambiar a un nuevo
registro) mediante el volcado de registros. El volcado de registros ocurre cuando ejecuta la sentencia
FLUSH LOGS o el comando mysqladmin flush-logs or mysqladmin refresh.
______________
Sintaxis de FLUSH
FLUSH [LOCAL | NO_WRITE_TO_BINLOG] flush_option [, flush_option] ...
Debe usar el comando FLUSH si quiere limpiar algunas de las cachs internas que usa MySQL . Para
ejecutar FLUSH, debe tener el permiso RELOAD .
flush_option puede ser cualquiera de los siguientes valores:
HOSTS
Vaca las tablas de la cach de equipos. Debe volcar las tablas de equipos si algunos de sus equipos
cambia el nmero IP o si obtiene el mensaje de error Host ... is blocked. Cuando ocurren
sucesivamente ms de max_connect_errors errores para un equipo dado mientras conecta con el
servidor MySQL , MySQL asume que hay algo incorrecto y bloquea el equipo de ms peticiones de
conexin. Volcar las tablas de equipos le permite al equipo intentar conectar de nuevo. Puede
arrancar mysqld con --max_connect_errors=999999999 para evitar este mensaje de error.
DES_KEY_FILE
Recarga las claves DES del fichero que se especifica con la opcin --des-key-file en tiempo de
arranque del servidor.
Pgina 5 de 16
Plataforma Educativa Universidad del SABES
Materia: Base de Datos II
LOGS
Cierra y reabre todos los ficheros de log. Si ha especificado un fichero de log de actualizaciones o un
fichero de log binario sin una extensin, el nmero de extensin del fichero de log se incrementa en
uno respecto al fichero anterior. Si ha usado una extensin del nombre de fichero, MySQL cierra y
reabre el fichero de log. En Unix, esto es lo mismo que enviar una seal SIGHUP al servidor mysqld
(excepto en algunas versiones Mac OS X 10.3 donde mysqld ignora SIGHUP y SIGQUIT).
PRIVILEGES
Recarga los permisos de las tablas de permisos en la base de datos mysql .
QUERY CACHE
Defragmenta cach de consulta para utilizar mejor su memoria. Este comando no borra ninguna
consulta de la cach, no como RESET QUERY CACHE.
STATUS
Resetea la mayora de variables de estado a cero. Esto es algo que debe usar slo al debugar una
consulta.
{TABLE | TABLES} [tbl_name [, tbl_name] ...]
Cuando no se nombran tablas, cierra todas las tablas abiertas y fuerza a todas las tablas en uso a
que se cierren. Esto tambin vuelca la cach de consultas. Con uno o ms nombres de tabla, vuelca
slo las tablas dadas. FLUSH TABLES tambin borra todos los resultados de consultas de la cach de
consultas, como el comando RESET QUERY CACHE.
TABLES WITH READ LOCK
Cierra todas las tablas abiertas y bloquea todas las tablas para todas las bases de datos con una
bloqueo de lectura hasta que ejecute UNLOCK TABLES. Esto es una forma muy conveniente de
obtener copias de seguridad si tiene un sistema de ficheros como Veritas que puede tomas muestras
en puntos de tiempo concretos.
USER_RESOURCES
Resetea todos los recursos por hora de usuario a cero. Esto le permite a los clientes que hayan
alcanzado el lmite de su conexin de hora, de consulta o de actualizacin para reanudar las
actividades inmediatamente. FLUSH USER_RESOURCES no se aplica al lmite en conexiones mximas
simultneas.
En MySQL 5.0, los comandos FLUSH se escriben en el lob binario a no ser que la plabra
NO_WRITE_TO_BINLOG (o su alias LOCAL) se use. Nota: FLUSH LOGS, FLUSH MASTER, FLUSH SLAVE,
y FLUSH TABLES WITH READ LOCK no se loguean en ningn caso porque causaran problemas si se
replicasen en un esclavo.
Pgina 6 de 16
Plataforma Educativa Universidad del SABES
Materia: Base de Datos II
Puede acceder a algunos de estos comandos con la utilidad mysqladmin usando los comandos flush-
hosts, flush-logs, flush-privileges, flush-status, o flush-tables .
Si est utilizando las capacidades de replicacin de MySQL, los servidores esclavos de replicacin
mantienen unos registros adicionales llamados registros relay.
5.10.1. El registro de errroes (Error Log)
El archivo de registro de errores contiene informacin que indica cuando se ha iniciado y parado
mysqld y tambin si ha ocurrido algn error crtico mientras el servidor se estaba ejecutando.
Si mysqld termina inesperadamente y mysqld_safe necesita reiniciarlo, mysqld_safe escribe un
mensaje restarted mysqld en el registro de errores. Si mysqld se da cuenta de que hay una tabla que
necesita ser automticamente comprobada o reparada, escribe un mensaje al registro de errores.
En algunos sistemas operativos, el registro de errores contiene un volcado de la pila si mysqld
muere. El volcado puede ser utilizado para determinar cuando mysqld muri.
En MySQL 5.0, puede especificar dnde quiere que mysqld almacene el registro de errores con la
opcin --log-error[=file_name]. Si no se proporciona ningn valor para file_name, mysqld utiliza el
nombre host_name.err y escribe el archivo en el directorio de datos. Si ejecuta FLUSH LOGS, el
registro de errores es renombrado con el sufijo -old y mysqld crea un nuevo archivo de registro.
Si no especifica --log-error, o (en Windows) no utiliza la opcin --console, los errores se escriben en
stderr, la salida estndar de erroes. Usualmente esto es su terminal.
En Windows, la salida de errores es siempre escrita al archivo .err si no se especifica la opcin --
console.
5.10.2. El registro general de consultas
Si quiere saber qu pasa en mysqld, debe iniciarlo con la opcin --log[=file_name] o -l [file_name].
Si no se da un valor para file_name, el nombre por defecto es host_name.log. Esto registra todas las
conexiones y sentencias a un archivo. Este registro puede ser muy til cuando sospeche que hay un
error en un cliente y quiera saber exactamente qu envi el cliente a mysqld.
mysqld escribe las sentencias al registro de consultas en el orden en que las recibe. Este orden puede
ser diferente del de ejecucin. Esto es aqu diferente que en el registro de actualizaciones o el
registro binario, que son escritos tras la ejecucin de la sentencia, pero antes de que se libere
cualquier bloqueo. (El registro de consultas tambin contiene todas las sentencias, mientras que el
registro binario no contiene sentencias que solo seleccionen datos.)
Pgina 7 de 16
Plataforma Educativa Universidad del SABES
Materia: Base de Datos II
Los reinicios del servidor y volcado de registros no provocan que se genere un nuevo archivo de
registro de consultas general (aunque el volcado lo cierra y lo reabre). En Unix, puede renombrar el
archivo y crear uno nuevo utilizando los siguientes comandos:
shell> mv [Link] [Link]
shell> mysqladmin flush-logs
shell> cp [Link] to-backup-directory
shell> rm [Link]
En Windows, no puede renombrar el archivo de registro mientras el servidor lo tiene abierto. Debe
parar el servidor y renombrar el registro. Despus, reinicie el servidor para crear el nuevo registro.
5.10.3. El registro binario (Binary Log)
El registro binario contiene toda la informacin que est disponible en el registro de actualizaciones,
en un formato ms eficiente y de una manera que es segura para las transacciones.
El registro binario contiene todas las sentencias que han actualizado datos o podran haberlo hecho
(por ejemplo, un DELETE que no encontr filas concordantes). Las sentencias se almacenan en la
forma de eventos que describen las modificaciones.
Atencin: El registro binario ha reemplazado al antiguo registro de actualizaciones, que ya no est
disponible a partir de MySQL 5.0.
El registro binario tambin contiene informacin sobre cuanto ha tardado cada sentencia que
actualiz la base de datos. No contiene sentencias que no hayan modificado datos. Si quiere
registrar todas las sentencias (por ejemplo, para identificar una sentencia problemtica) debera
utilizar el registro de consultas general.
El propsito principal del registro binario es el de actualizar la base de datos durante una operacin
de recuperacin tan completamente como sea posible, porque el registro binario contiene todas las
actualizaciones hechas tras la copia de seguridad.
El registro binario tambin se utiliza en los servidores maestros de replicacin como recordatorio
de las sentencias que deben ser enviadas a los servidores esclavos.
Ejecutar el servidor con el registro binario activado hace que el rendimiento baje un 1%. An as, los
beneficios del registro binario para las operaciones de restauracin y el hecho de permitirnos poder
establecer replicacin generalmente son superiores a este decremento de rendimiento.
Cuando se ha iniciado con la opcin --log-bin[=file_name] mysqld escribe un archivo de registro que
contiene todos los comandos SQL que actualizan datos. Si no se da ningn valor para file_name, el
Pgina 8 de 16
Plataforma Educativa Universidad del SABES
Materia: Base de Datos II
valor por defecto es el nombre de la muqina host seguido por -bin. Si se da el nombre del archivo,
pero ninguna ruta, el archivo se escribe en el directorio de datos. Se recomienda especificar un
nombre de archivo
Si usted proporciona una extensin en el nombre del registro (por ejemplo, --log-
bin=file_name.extension), la extensin se ignora y elimina sin aviso.
mysqld agraga una extensin numrica a el nombre del registro binario. Este nmero se incrementa
cada vez que se inicia el servidor o se vuelcan los registros. Tambin se crea un nuevo registro binario
cuando el actual llega al tamao especificado en max_binlog_size. Un registro binario puede llegar
a ser ms grande de max_binlog_size si est utilizando transacciones grandes: Una transaccin se
escribe en el registro de una sola pieza, nunca se parte entre diferentes registros.
Para poder averiguar qu archivos de registro binario diferentes han sido utilizados, mysqld tambin
crea un archivo de ndice de los registros binarios que contiene los nombres de todos los archivos
de registro binario utilizados. Por defecto ste tiene el mismo nombre que el archivo de registro
binario, con la extensin '.index'. Puede cambiar el nombre del archivo de ndice con la opcin --log-
bin-index[=file_name]. No debera editar este archivo manualmente mientras mysqld se est
ejecutando; hacerlo podra confundir a mysqld.
Puede borrar todos los archivos de registro binario con la sentencia RESET MASTER, o slo algunos
de ellos con PURGE MASTER LOGS.
El formato del registro binario tiene algunas limitaciones conocidas que pueden afectar a la
recuperacin de copias de seguridad.
El registro binario de procedimientos almacenados y disparadores se hace tal como se explica en
Seccin 19.3, Registro binario de procedimientos almacenados y disparadores.
Puede utilizar las siguientes opciones de mysqld para determinar lo que se registra en el registro
binario. Vea tambin la explicacin que sigue a esta lista de opciones.
--binlog-do-db=db_name
Le dice al maestro que debera registrar los cambios en el registro binario si la base de datos actual
(es decir, la que est seleccionada mediante USE) es db_name. Todos las otras bases de datos que
no sean mencionadas explcitamente son ignoradas. Si utiliza esto, debera asegurarse de que slo
hace cambios en la base de datos actual.
Tenga en cuenta que hay una excepcin a esto en lo que respecta a las sentencias CREATE
DATABASE, ALTER DATABASE, y DROP DATABASE, que utilizan la base de datos manipulada en vez
de la actual para decidir si deberan registrar la sentencia.
Un ejemplo de algo que no funciona como podra esperarse: Si el servidor se inici con binlog-do-
db=sales, y usted ejecuta USE prices; UPDATE [Link] SET amount=amount+1000;, esta
sentencia no llega a escribirse en el registro binario.
Pgina 9 de 16
Plataforma Educativa Universidad del SABES
Materia: Base de Datos II
--binlog-ignore-db=db_name
Le dice al maestro que las actualizaciones donde la base de datos actual (es decir, la que ha sido
seleccionada mediante USE) es db_name no deberan ser almacenadas en el registro binario. Si
utiliza esto, debera asegurarse de que solo hace actualizaciones en la base de datos actual.
Un ejemplo de algo que no funciona como podra esperarse: Si el servidor se inici con binlog-
ignore-db=sales, y ejecuta USE prices; UPDATE [Link] SET amount=amount+1000;, esta
sentencia no se escribe en el registro binario.
De la misma forma que en el caso de --binlog-do-db, hay una excepcin para las sentencias CREATE
DATABASE, ALTER DATABASE, y DROP DATABASE, que utilizan la base de datos manipulada para
decidir si deben registrar la sentencia, en vez de la base de datos actual.
Para registrar o ignorar mltiples bases de datos, utilice mltiples opciones, especificando la opcin
apropiada una vez para cada base de datos.
Las reglas para registrar o ignorar actualizaciones en el registro binario son evaluadas de acuerdo a
las siguientes normas. Tenga en cuenta que hay una excepcin para las sentencias CREATE
DATABASE, ALTER DATABASE, y DROP DATABASE. En esos casos, la base de datos que est siendo
creada, alterada, o eliminada reemplaza a la base de datos actual en las reglas siguientes.
1. Hay alguna regla binlog-do-db o binlog-ignore-db?
No: Escribir la sentencia al registro binario y salir.
S: Proceder al siguiente paso.
2. Hay algunas reglas (binlog-do-db o binlog-ignore-db o ambas). Hay una base de datos
actual (ha sido seleccionada alguna base de datos mediante USE?)?
No: No escribir la sentencia, y salir.
S: Proceder al siguiente paso.
2. Hay una base de datos actual. Hay alguna regla binlog-do-db?
S: Concuerda la base de datos con alguna de las reglas binlog-do-db?
o S: Escribir la sentencia y salir.
o No: No escribir la sentencia, y salir.
No: Proceder al siguiente paso.
2. Hay alguna regla binlog-ignore-db. Concuerda la base de datos con alguna de las reglas
binlog-ignore-db?
Pgina 10 de 16
Plataforma Educativa Universidad del SABES
Materia: Base de Datos II
S: No escribir la sentencia, y salir.
No: Escribir la sentencia y salir.
Por ejemplo, un esclavo ejecutndose con slo binlog-do-db=sales no escribe en el registro binario
ninguna sentencia en la que la base de datos actual sea diferente de sales (es decir, a veces binlog-
do-db puede significar ``ignora otras bases de datos'').
Si est utilizando replicacin, debera no borrar los archivos de registros binarios viejos hasta que
est seguro de que ningn esclavo los necesita. Una manera de averiguarlo es hacer mysqladmin
flush-logs una vez al da y borrar cualquier registro que tenga ms de tres das de antigedad. Puede
borrarlos manualmente, o mejor an mediante PURGE MASTER LOGS que adems tambin actualiza
de manera segura el archivo de ndice de registros binarios (y que puede recibir parmetros de
fecha).
Un cliente con el privilegio SUPER puede desactivar el registro binario de sus propias sentencias
utilizando una sentencia SET SQL_LOG_BIN=0..
Puede examinar el archivo de registro binario con la utilidad mysqlbinlog. Esto podra ser til cuando
usted quiera reprocesar sentencias almacenadas en el registro. Por ejemplo, puede actualizar un
servidor MySQL desde el registro binario de la siguiente manera:
shell> mysqlbinlog log-file | mysql -h server_name
Si usted est utilizando transacciones, debera utilizar el registro binario de MySQL para hacer las
copias de seguridad, en vez del antiguo registro de actualizaciones.
El registro binario se hace inmediatamente despus de que se completa una consulta, pero antes
de que se libere cualquier bloqueo o se haga ningn commit. Esto asegura que el registro est
almacenado en el orden de ejecucin.
Las actualizaciones a las tablas no-transaccionales se almacenan en el registro binario
inmediatamente despus de su ejecucin. Para las tablas transaccionales como las tablas BDB o
InnoDB, todas las actualizaciones (UPDATE, DELETE, o INSERT) que cambian alguna tabla son
almacenadas en cache hasta que se recibe una sentencia COMMIT en el servidor. En ese momento
mysqld escribe la transaccin completa al registro binario antes de que se ejecute el COMMIT.
Cuando el flujo de ejecucin que gestiona la transaccin comienza, reserva un buffer de tamao
binlog_cache_size para almacenar consultas. Si una sentencia es ms grande de esto, el flujo abre
un archivo temporal para almacenar la transaccin. El archivo temporal se borra cuando acaba el
flujo.
Pgina 11 de 16
Plataforma Educativa Universidad del SABES
Materia: Base de Datos II
La variable de estado Binlog_cache_use muestra el nmero de transacciones que han utilizado este
buffer (y posiblemente un archivo temporal) para almacenar sentencias. La variable de estado
Binlog_cache_disk_use muestra cuantas de esas transacciones llegaron realmente a utilizar un
archivo temporal. Estas dos variables pueden utilizarse para establecer el valor de binlog_cache_size
y evitar el uso de archivos temporales.
El tamao max_binlog_cache_size (por defecto 4GB) se puede utilizar para restringir el tamao total
utilizado para almacenar una transaccin con mltiples sentencias. Si una transaccin es ms grande
que esto, falla y se hace un rollback.
Si usted est utilizando el registro de actualizaciones o el binario, las inserciones concurrentes se
convierten a inserciones normales cuando se utiliza CREATE ... SELECT o INSERT ... SELECT. Esto se
hace as para asegurarse de que se puede reconstruir una copia exacta de sus tablas aplicando los
registros a una copia de seguridad.
Tenga en cuenta que el formato del registro binario es diferente en MySQL 5.0 al de versiones
anteriores de MySQL, debido a mejoras en la replicacin.
Por defecto, el registro binario no se sincroniza con el disco en cada escritura. As que si el sistema
operativo o la mquina (no nicamente el servidor MySQL) falla, existe la posibilidad de que las
ltimas sentencias del registro binario se pierdan. Para prevenir esto, puede hacer que el registro
binario se sincronice con el disco tras cada N escrituras, con la variable global sync_binlog (siendo 1
el valor ms seguro, pero tambin el ms lento).. An con el valor de sync_binlog establecido en 1,
existe una posibilidad de que haya una inconsistencia entre las tablas y el registro binario en el caso
de fallo.
Por ejemplo, si est utilizando tablas InnoDB, y el servidor MySQL procesa una sentencia COMMIT,
escribe la transaccin completa al registro binario, y despus la enva a InnoDB. Si el fallo se produce
entre estas dos operaciones, al reiniciar la transaccin es rechazada por InnoDB, pero todava existe
en el registro binario. Este problema puede resolverse con la opcin --innodb-safe-binlog, que aade
consistencia entre el contenido de las tablas InnoDB y el registro binario.
Para que esta opcin proporcione un grado mayor de seguridad, el servidor MySQL debe estar
tambin configurado para sincronizar a disco, en cada transaccin, el registro binario
(sync_binlog=1) y (lo que es cierto por defecto) los registros InnoDB. El efecto de esta opcin es que
al reiniciar tras un fallo, o tras hacer un rollback de transacciones, el servidor MySQL elimina las
transacciones InnoDB que han sufrido una cancelacin del registro binario. Esto asegura que el
registro binario refleje los datos exactos que hay en las tablas InnoDB y, as, el esclavo permanece
sincronizado con el maestro (no recibe una sentencia que ha sido cancelada).
Tenga en cuenta que --innodb-safe-binlog se puede utilizar an cuando el servidor MySQL actualice
otros motores de almacenamiento que no sean InnoDB. Slo las sentencia/transacciones que
afecten a tablas InnoDB son candidatas a ser eliminadas del registro binario durante la recuperacin
de un fallo de InnoDB.
Pgina 12 de 16
Plataforma Educativa Universidad del SABES
Materia: Base de Datos II
Si durante la recuperacin el servidor MySQL descubre que el registro binario es ms corto de lo
que debera ser (es decir, le falta al menos una transaccin InnoDB realizada con xito), lo que no
debera ocurrir con sync_binlog=1 y el disco/sistema de archivos hace una sincronizacin real
cuando se le pide (algunos no lo hacen), muestra un mensaje de error ("The binary log <name> is
shorter than its expected size"). En este caso el registro binario no es correcto, y la replicacin
debera reiniciarse desde una nueva imagen de los datos del maestro.
La escrituras al archivo del registro binario y al de ndice de registros son gestionados de la misma
manera que las escrituras a las tablas MyISAM.
5.10.4. El registro de consultas lentas (Slow Query Log)
Cuando se inicia con la opcin --log-slow-queries[=file_name], mysqld escribe un archivo de registro
que contiene todos las sentencias SQL que llevaron ms de long_query_time segundos para
ejecutarse completamente. El tiempo para adquirir los bloqueos de tabla iniciales no se cuenta
como tiempo de ejecucin.
Si no se da ningn valor a file_name, el nombre por defecto es el nombre de la mquina host con el
sufijo -[Link]. Si se da un nombre de archivo, pero no como ruta absoluta, el archivo se escribe en
el directorio de datos.
Una sentencia se registra en el registro de consultas lentas despus de que haya sido ejecutada y
todos los bloqueos liberados. El orden de registro puede diferir del de ejecucin.
El registro de consultas lentas se puede utilizar para encontrar consultas que tomen excesivo tiempo
y sean por tanto candidatos a optimizacin. De cualquier modo, examinar un registro de consultas
lentas puede convertirse en una tarea difcil. Para hacerlo ms simple, puede procesar el registro de
consultas lentas utilizando el comando mysqldumpslow que le ofrecer un resumen de las
sentencias que aparecen en el registro.
En el registro de consultas lentas de MySQL 5.0, las consultas lentas que no utilizan ndices se
registran igual que las que s utilizan. Para prevenir que las consultas que no utilizan ndices sean
registradas en el registro de consultas lentas, utilice la opcin --log-short-format.
En MySQL 5.0, la opcin --log-slow-admin-statements del servidor le permite demandar el registro
de sentencias administrativas lentas como OPTIMIZE TABLE, ANALYZE TABLE, y ALTER TABLE sean
escritas en el registro de consultas lentas.
Las consultas gestionadas por la cache de consultas no son aadidas al registro de consultas lentas,
ni tampoco las consultas que no se beneficien de la presencia de un ndice porque la tabla tenga
cero o una filas.
Pgina 13 de 16
Plataforma Educativa Universidad del SABES
Materia: Base de Datos II
Mantenimiento de ficheros de registro (log)
El servidor MySQL puede crear un nmero de archivos de registro diferente que faciliten el ver que
est pasando.. De cualquier modo, debe limpiar estos archivos regularmente para asegurarse de
que no ocupan demasiado espacio.
Cuando se utiliza MySQL con el registro activado, debera hacer copias de seguridad y eliminar los
registros viejos de vez en cuando, y decirle a MySQL que comience a registrar en archivos nuevos.
En una instalacin Linux (Red Hat), puede utilizar el script mysql-log-rotate para esto. Si instal
MySQL desde una distribucin RPM, el script debera haber sido instalado automticamente.
Debera tener cuidado con este script si est utilizando el registro binario para replicacin; no
elimine los registros binarios hasta que tenga la certeza de que sus contenidos han sido procesados
por todos los esclavos.
En otros sistemas, debe instalar un script corto usted mismo desde cron o algo equivalente para
gestionar los archivos de registros.
Puede forzar a MySQL para que comience a utilizar archivos de registro nuevos usando mysqladmin
flush-logs o con la sentencia SQL FLUSH LOGS.
Una operacin de volcado de registros hace lo siguiente:
Si se est utilizando registro (--log) o registro de consultas lentas (--log-slow-queries), cierra
y reabre el archivo de registro ([Link] y `hostname`-[Link] por defecto).
Si se est utilizando registro de actualizaciones (--log-update) o registro binario (--log-bin)
cierra el registro, y abre un nuevo archivo de registro con un nmero de secuencia superior.
Si est utilizando tan solo el registro de actualizaciones, tan solo tiene que renombrar el archivo de
registro y posteriormente volcar los registros antes de hacer una copia de seguridad. Por ejemplo,
puede hacer algo como esto:
shell> cd mysql-data-directory
shell> mv [Link] [Link]
shell> mysqladmin flush-logs
Luego, haga una copia de seguridad y elimine [Link].
Copias de seguridad de bases de datos
Debido a que las tablas de MySQL se almacenan como archivos, es fcil hacer una copia de
seguridad. Para hacer una copia consistente haga un LOCK TABLES en las tablas relevantes, seguido
de un FLUSH TABLES para las tablas.
Pgina 14 de 16
Plataforma Educativa Universidad del SABES
Materia: Base de Datos II
Solo necesita obtener un bloqueo de lectura; esto permite a otros clientes continuar consultando la
tabla mientras usted est haciendo una copia de los archivos del directorio de la base de datos. La
sentencia FLUSH TABLES es necesaria para asegurarse de que todas las pginas de ndice activas se
escriben al disco antes de que comience la copia.
Si quiere hacer una copia de una tabla a un nivel SQL, puede utilizar SELECT INTO ... OUTFILE o
BACKUP TABLE. Para SELECT INTO ... OUTFILE, el archivo de salida no debe existir previamente. Esto
tambin es cierto para BACKUP TABLE, ya que permitir que archivos externos sean sobreescritos
sera un riesgo de seguridad
Otra tcnica para hacer copias de seguridad de una base de datos es utilizar el programa mysqldump
o el script mysqlhotcopy script.
1. Hacer una copia completa de su base de datos:
2. shell> mysqldump --tab=/path/to/some/dir --opt db_name
O:
shell> mysqlhotcopy db_name /path/to/some/dir
Tambin puede simplemente copiar todos los archivos de tablas (*.frm, *.MYD, y *.MYI) siempre
que el servidor no est actualizando nada. El script mysqlhotcopy utiliza este mtodo. (Pero tenga
en cuenta que estos mtodos no funcionan si su base de datos contiene tablas InnoDB. InnoDB no
almacena los contenidos de las tablas en directorios de base de datos, y mysqlhotcopy funciona solo
para tablas MyISAM e ISAM.)
3. Pare mysqld si se est ejecutando, y despus reinicielo con la opcin --log-bin[=file_name].
Los archivos binarios de registro le dan la informacin que necesita para replicar los cambios que se
han producido en la base de datos tras el punto en que usted ejecut mysqldump.
Para las tablas InnoDB es posible realizar una copia de seguridad en lnea que no requiere bloqueos
en las tablas;
MySQL tiene soporte para copias de seguridad incrementales: Usted necesita iniciar el servidor con
la opcin --log-bin para activar el registro binario; En el momento en que usted quiera realizar una
copia de seguridad incremental (que contenga todos los cambios que han ocurrido desde la ltima
copia de seguridad, completa o incremental), usted debe rotar el registro binario utilizando FLUSH
LOGS. Hecho esto, necesita copiar a la localizacin de seguridad todos los registros binarios que
daten desde el momento de la ltima copia de seguridad hasta el ltimo. Estos logs binarios son la
copia de seguridad incremental; cuando necesite restaurar la copia, los puede aplicar tal como se
explica ms adelante. La prxima vez que haga una copia de seguridad compelta, tambin debe
rotar el registro binario haciendo FLUSH LOGS, mysqldump --flush-logs, o mysqlhotcopy --flushlogs.
Pgina 15 de 16
Plataforma Educativa Universidad del SABES
Materia: Base de Datos II
Si su servidor MySQL es un servidor esclavo de replicacin, entonces independientemente del
mtodo de copia de seguridad que elija, tambin debe copiar los archivos [Link] y relay-
[Link] cuando copie los datos de su esclavo. Estos archivos son siempre necesarios para continuar
la replicacin despus de una restauracin de los datos del esclavo. Si su esclavo est replicando
comandos LOAD DATA INFILE, debera tambin copiar cualquier archivo SQL_LOAD-* que pueda
existir en el directorio especificado por la opcin --slave-load-tmpdir. (Esta localizacin es por
defecto el valor de la variable tmpdir, si no se especifica.) El esclavo necesita estos archivos para
reiniciar la replicacin de cualquier operacin LOAD DATA INFILE interrumpida.
Si tiene que restaurar tablas MyISAM, intente recuperarlas utilizando REPAIR TABLE o myisamchk -
r primero. Esto debera funcionar en el 99.9% de los casos. Si myisamchk falla, intente el siguiente
procedimiento. Tenga en cuenta que solo funciona si tiene activado el registro binario iniciando el
servidor MySQL con la opcin --log-bin;
1. Restaure la copia de seguridad original de mysqldump, o la copia de seguridad binaria.
2. Ejecute el siguiente comando para ejecutar de nuevo las actualizaciones de los registros binarios:
shell> mysqlbinlog hostname-bin.[0-9]* | mysql
En algunos casos, quiz quiera reejecutar solo ciertos registros binarios, desde ciertas posiciones (lo
usual es querer reejecutar todos los registros binarios desde el punto de restauracin, excepto,
posiblemente, algunas sentencias incorrectas).
Tambin puede hacer copias de seguridad selectivas de archivos individuales:
Para volcar la tabla, utilice SELECT * INTO OUTFILE 'file_name' FROM tbl_name.
Para recargar la tabla, restaurela con LOAD DATA INFILE 'file_name' REPLACE ... Para evitar
registros duplicados, la tabla tiene que tener un ndice PRIMARY KEY o UNIQUE. La palabra clave
REPLACE hace que los viejos registros sean reemplazados con los nuevos cuando un nuevo registro
tiene la misma clave que uno antiguo.
Si tiene problema de rendimientos con su servidor mientras realiza copias de seguridad, una
estrategia que puede ayudarle es crear replicacin y hacer las copias de seguridad en el esclavo en
vez de en el maestro.
Si est utilizando un sistema de ficheros Veritas, puede hacer una copia de seguridad as:
Desde un programa cliente, ejecute FLUSH TABLES WITH READ LOCK.
2. Desde otra lnea de comandos, ejecute mount vxfs snapshot.
3. Desde el primer cliente, ejecute UNLOCK TABLES.
4. Copie los archivos de la captura (snapshot).
5. Desmonte la captura.
Pgina 16 de 16
