Replicacion MySql

13.4.2.
7 START SLAVE Syntax

START SLAVE [thread_types]
START SLAVE [SQL_THREAD] UNTIL
MASTER_LOG_FILE = 'log_name', MASTER_LOG_POS = log_pos
START SLAVE [SQL_THREAD] UNTIL
RELAY_LOG_FILE = 'log_name', RELAY_LOG_POS = log_pos
thread_types:
[thread_type [, thread_type] ... ]

thread_type: IO_THREAD | SQL_THREAD
START SLAVE with no thread_type options starts both of the slave threads. The I/O
thread reads events from the master server and stores them in the relay log. The SQL
thread reads events from the relay log and executes them. START SLAVE requires
the SUPER privilege.
If START SLAVE succeeds in starting the slave threads, it returns without any error.
However, even in that case, it might be that the slave threads start and then later stop (for
example, because they do not manage to connect to the master or read its binary log, or
some other problem). START SLAVE does not warn you about this. You must check the
slave's error log for error messages generated by the slave threads, or check that they are
running satisfactorily with SHOW SLAVE STATUS.
START SLAVE sends an acknowledgment to the user after both the I/O thread and the SQL
thread have started. However, the I/O thread may not yet have connected. For this reason,
a successful START SLAVE causes SHOW SLAVE STATUS to
show Slave_SQL_Running=Yes, but this does not guarantee
that Slave_IO_Running=Yes(because Slave_IO_Running=Yes only if the I/O thread is
running and connected). For more information, seeSection 13.7.5.31, SHOW SLAVE
STATUS Syntax, and Section 16.1.3.1, Checking Replication Status.
You can add IO_THREAD and SQL_THREAD options to the statement to name which of the
threads to start.
An UNTIL clause may be added to specify that the slave should start and run until the SQL
thread reaches a given point in the master binary log or in the slave relay log. When the
SQL thread reaches that point, it stops. If the SQL_THREAD option is specified in the
statement, it starts only the SQL thread. Otherwise, it starts both slave threads. If the SQL
thread is running, the UNTIL clause is ignored and a warning is issued.
For an UNTIL clause, you must specify both a log file name and position. Do not mix master
and relay log options.
Any UNTIL condition is reset by a subsequent STOP SLAVE statement, a START
SLAVE statement that includes noUNTIL clause, or a server restart.
The UNTIL clause can be useful for debugging replication, or to cause replication to
proceed until just before the point where you want to avoid having the slave replicate an
event. For example, if an unwise DROP TABLEstatement was executed on the master, you
can use UNTIL to tell the slave to execute up to that point but no farther. To find what the
event is, use mysqlbinlog with the master binary log or slave relay log, or by using aSHOW
BINLOG EVENTS statement.
If you are using UNTIL to have the slave process replicated queries in sections, it is
recommended that you start the slave with the --skip-slave-start option to prevent the
SQL thread from running when the slave server starts. It is probably best to use this option
in an option file rather than on the command line, so that an unexpected server restart does
not cause it to be forgotten.
The SHOW SLAVE STATUS statement includes output fields that display the current values
of the UNTIL condition.
In old versions of MySQL (before 4.0.5), this statement was called SLAVE START. This
usage is still accepted in MySQL 5.0 for backward compatibility, but is deprecated and is
removed in MySQL 5.6.
Previous / Next / Up / Table of Contents
User Comments
Posted by Jim Grill on February 5 2008 2:03pm
[Delete] [Edit]
Useful feature...
Sometimes it's desirable to keep a slave behind the master in the event a bad drop statement
causes chaos.
For example to keep a slave behind the master at all times write a script to:
1) get the current master log file and position and save it in a file
2) use the master log file and position from the *previous* run to START SLAVE UNTIL
MASTER_LOG_FILE='<log file>', MASTER_LOG_POS=<position>
3) run the script once per hour to keep the slave the behind at least an hour at all times... or
every ten minutes to keep it ten minutes behind.
Be sure to add skip-slave-start to your my.cnf

Posted by Kayra Otaner on October 16 2009 10:21pm
[Delete] [Edit]
A gotcha if you're using transactions.

You can't use just any position if you're using transactions on your master. Only position right
after 'commit' can be used to start slave 'until'. If the position specified is not the 'commit'
position for the transaction enclosed in binlog, MySQL replication will stop at the 'commit'
position, not the position you explicitly specified.
MySQL slave I/O thread not running

up
vote1
down
vote
favorite
I have set up replication for MySQL server. I can connect from the slave machine
to the master server using the replication user/password. I have got the slave SQL
thread running, but the slave I/Othread is not running and the slave I/O status
comes as empty when checked using 'show slave status'. What could be the
problem?
How do I solve this? Restarting the slave does not help.
This was my bad: Instead of giving a 'replication slave' privilege to *.*, I was
only giving it for my_db.*.
mysql
replication
slave
shareimprove this question
edited Jun 24 '13 at

11:32
asked
17:59
Peter Mortensen
Champ
8,711105895
323
add a comment
4 Answers
activeoldest
votes
up
vote3
down
vote
Instead of giving a 'replication slave' privilege to ., I was only giving it for

my_db.*.
accepted
Replication slave is only a global privilege (i.e. per-user only), this means that a
command such as
GRANT REPLICATION SLAVE on mydb.* TO 'someuser'@'%';
has no effect as you can't grant it per-database/column/table.
The command you need to run is:

GRANT REPLICATION SLAVE on *.* TO 'someuser'@'%';
Then do a START SLAVE. You might also find it useful to look in the mysql error
log.
I'd suggest a good read of the replication setup documentation, as it explains all
of this in detail.
shareimprove this answer
edited Nov 28 '09 at

12:48
answered
12:20
brian-brazil
4,323
add a comment
up
vote3
down
vote
I have encountered the same problem and I try this steps

First add this code somewhere below [mysqld] in my.cnf or my.ini slave-skiperrors=1046 this will skip all duplicate entry since we will execute the whole
binary log file where the replication stop, you may comment this code after
successful replication.
1.STOP SLAVE;
2.RESET SLAVE;
3.CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000049';
Note: MASTER_LOG_FILE must be the last file where it stop from replicating
4.CHANGE MASTER TO MASTER_LOG_POS=98;

5.START SLAVE;
check if you are successful
answered
9:53
Luxknight007
31
add a comment
up
vote2
down
vote
@Luxknight007 Step 2 is very dangerous and is not required at all.

2.RESET SLAVE (should not run this command)
RESET SLAVE makes the slave forget its replication position in the master's
binary log. This statement is meant to be used for a clean start: It deletes the
master.info and relay-log.info files, all the relay log files, and starts a new relay
log file. Link

12:28
answered
12:22
M Arif
144
add a comment
up
vote1d
own
vote
I faced same issue and fixed using following steps. Complete thread link
ishttp://www.percona.com/forums/questions-discussions/perconaxtrabackup/11842-backup-stopped-working-slave-sql-running-no
Steps are same as mentioned by @Luxknight007 except his step 2. However this
thread contains more detail which is very helpful. Following is solution which i
used and it worked.
"The first issue is that you changed the replication position instead of fixing the
error, and used an incorrect binlog file name format (you likely just used the one
from that post you linked I'd guess). To get back to where you started, you need
to find the binlog file and position that the slave sql_thread stopped at. Based on
your slave status output, it looks like the slave is reading from a new binlog file
(you can see that the Read_Master_Log_Pos value is smaller than the
Exec_Master_Log_Pos value, which means it has to be reading a newer binlog
file than where the slave sql_thread stopped at), so you need to find the binlog
file that the slave sql_thread actually failed on. So look in the error log for
something like the below:
Code:
2013-10-08 12:48:51 37545 [ERROR] Slave SQL: Error 'Table 'testdb.test2'
doesn't exist' on query. Default database: 'testdb'. Query: 'insert into
test1 select * from test2', Error_code: 1146
2013-10-08 12:48:51 37545 [Warning] Slave: Table 'testdb.test2' doesn't
exist Error_code: 1146
2013-10-08 12:48:51 37545 [ERROR] Error running query, slave SQL
thread aborted. Fix the problem, and restart the slave SQL thread with
"SLAVE START". We stopped at log 'mysql-bin.000001' position 3427
This is a sample I re-created, so yours will be a bit different. Note the ERROR is
similar to what you see in your slave status. So find your specific error message
in the error log file, and then locate the end part where is gives you the file name
and position ("We stopped at log 'mysql-bin.000001' position 3427" in my
example). The position should be 315098143 based on your show slave status, as
that is when it the slave sql_thread stopped executing events
(Exec_Master_Log_Pos ) but the io_thread kept reading in new ones
(Read_Master_Log_Pos).
Once you find the correct binlog file name and position, re-run your change
master statement on your slave using the information you located in the error
log. Note that your file name should be something like "newcrmdb1bin.XXXXXX", not mysql-bin.XXXXXX (you can see this naming convention
your show slave status above).
Code:
mysql> change master to MASTER_LOG_FILE='newcrmdb1-bin.XXXXXX',
Master_Log_Pos=315098143;
change master to MASTER_LOG_FILE='mysql-bin.000082' ,
Once you get pointed back to the original replication location where the slave
sql_thread failed, you need to then fix the error that it was complaining about to
start with.
The initial replication error appears to be telling you that the
table asteriskcdr.bpleadcf does not exist on the slave, so the insert statement is
failing when it attempts to select the data from that table. So the problem there is
that your slave appears to be already out of sync with your master. If the table in
question on the master is static or mostly static, you could likely solve this by
exporting the data from just that table on the master using mysqldump and
loading it into the slave. If that is not possible, or you do not care about that data,
you could always just skip the replication statement with
sql_slave_skip_counter, but then the slave would be further out of sync with the
master.
And if all else fails, you can always rebuild the slave from the master as a last
resort as well. =)"
Backup stopped working !! Slave_SQL_Running: No

10-08-2013, 03:49 AM
Hello everyone,
My latest issues are just piling up and i am not able to get them all sorted
To add to my chaos, now my backup server too is giving me issues.
When i run the command :-
Code:
TheSlave|mysql>SHOWSLAVESTATUS\G
...
Slave_IO_Running:Yes
Slave_SQL_Running:No
see that "Slave_SQL_Running" is "NO" !!

i tried to stop and start the replication service, but in vein
My log files are throwing up this error :-
Code:
tailf/var/log/messages
Oct813:32:37DatabackupSRVxinetd[3396]:EXIT:nrpestatus=0pid=3295
duration=0(sec)
Oct813:34:19DatabackupSRVxinetd[3396]:START:nrpepid=3300
from=10.222.32.22
duration=0(sec)
Oct813:34:29DatabackupSRVxinetd[3396]:START:nrpepid=3305
from=10.222.32.22
duration=0(sec)
It was working all this while, But i guess the recent start / stop of mysql services and the
server of the master is causing this issue.
Any suggestions to rectify this would be of great help.

Thank you
Tags: None
systemali
Counsellor
Join Date: Jan 2013
Posts: 118
o
o
o
#2
10-08-2013, 03:58 AM
Thought for a moment and decided why not post the whole output of the command : SHOW
SLAVE STATUS \G
Code:
mysql> SHOW SLAVE STATUS \G
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 10.222.1.218
Master_User: root
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: newcrmdb1-bin.000061
Read_Master_Log_Pos: 315098143
Relay_Log_File: DatabackupSRV-relay-bin.000088
Relay_Log_Pos: 667796113
Relay_Master_Log_File: newcrmdb1-bin.000054
Slave_IO_Running: Yes
Slave_SQL_Running: No
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 1146
Last_Error: Error 'Table 'asteriskcdr.bpleadcf' doesn't exist' on query. Default database: '
newcrmdb'. Query: 'INSERT INTO `newcrmdb`.`bpleadcf` SELECT * FROM àsteriskcdr`.`bpleadcf`'
Skip_Counter: 0
Exec_Master_Log_Pos: 667795964
Relay_Log_Space: 1134162270
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: NULL
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 1146
Last_SQL_Error: Error 'Table 'asteriskcdr.bpleadcf' doesn't exist' on query. Default database: '
newcrmdb'. Query: 'INSERT INTO `newcrmdb`.`bpleadcf` SELECT * FROM àsteriskcdr`.`bpleadcf`'
1 row in set (0.00 sec)
Thank you everyone for your assistance.
systemali
Counsellor
Join Date: Jan 2013
Posts: 118
o
o
o
#3
10-08-2013, 04:35 AM
Ahhh...
With regards to my similar post earlier, I tried to trouble shoot the issue, but in vein...
Now when i run the command :- "show slave status \G"
Code:
mysql> show slave status \G
*************************** 1. row ***************************
Slave_IO_State:
Master_User: root
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.000055
Relay_Log_File: DatabackupSRV-relay-bin.000001
Relay_Log_Pos: 4
Relay_Master_Log_File: mysql-bin.000055
Slave_IO_Running: No
Slave_SQL_Running: Yes
Replicate_Do_DB:
Replicate_Do_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 1236
Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: 'Could not f
ind first log file name in binary log index file'
Last_SQL_Errno: 0
Last_SQL_Error:
I'll let everyone know, what i did :This is the first change i did :-
Code:
mysql>changemastertoMASTER_LOG_FILE='mysqlbin.000055',Master_Log_Pos=4;
Later i changed to this :-
Code:
mysql>changemastertoMASTER_LOG_FILE='mysqlbin.000055',
Those are the 2 chnages i have done and now i get the status as shown above
i hope i have not messed it up too much !!
Thank you

scott.nemes
Mod Squad
Join Date: Jan 2012
Posts: 313
o
o
o
#4
10-08-2013, 03:09 PM
Yeah you stuck it to yourself on this one.

The first issue is that you changed the replication position instead of fixing the error, and
used an incorrect binlog file name format (you likely just used the one from that post you
linked I'd guess). To get back to where you started, you need to find the binlog file and
position that the slave sql_thread stopped at. Based on your slave status output, it looks
like the slave is reading from a new binlog file (you can see that the
Read_Master_Log_Pos value is smaller than the Exec_Master_Log_Pos value, which
means it has to be reading a newer binlog file than where the slave sql_thread stopped at),
so you need to find the binlog file that the slave sql_thread actually failed on. So look in the
error log for something like the below:
Code:
2013100812:48:5137545[ERROR]SlaveSQL:Error'Table'testdb.test2'
doesn'texist'onquery.Defaultdatabase:'testdb'.Query:'insertintotest1
select*fromtest2',Error_code:1146
2013100812:48:5137545[Warning]Slave:Table'testdb.test2'doesn'texist
Error_code:1146
2013100812:48:5137545[ERROR]Errorrunningquery,slaveSQLthread
aborted.Fixtheproblem,andrestarttheslaveSQLthreadwith"SLAVESTART".
Westoppedatlog'mysqlbin.000001'position3427
This is a sample I re-created, so yours will be a bit different. Note the ERROR is similar to
what you see in your slave status. So find your specific error message in the error log file,
and then locate the end part where is gives you the file name and position ("We stopped at
log 'mysql-bin.000001' position 3427" in my example). The position should be 315098143
based on your show slave status, as that is when it the slave sql_thread stopped executing
events (Exec_Master_Log_Pos ) but the io_thread kept reading in new ones
Once you find the correct binlog file name and position, re-run your change master
statement on your slave using the information you located in the error log. Note that your
file name should be something like "newcrmdb1-bin.XXXXXX", not mysql-bin.XXXXXX (you
can see this naming convention your show slave status above).
Code:
mysql>changemastertoMASTER_LOG_FILE='newcrmdb1bin.XXXXXX',
Once you get pointed back to the original replication location where the slave sql_thread
failed, you need to then fix the error that it was complaining about to start with.
The initial replication error appears to be telling you that the table àsteriskcdr`.`bpleadcf`
does not exist on the slave, so the insert statement is failing when it attempts to select the
data from that table. So the problem there is that your slave appears to be already out of
sync with your master. If the table in question on the master is static or mostly static, you
could likely solve this by exporting the data from just that table on the master using
mysqldump and loading it into the slave. If that is not possible, or you do not care about
that data, you could always just skip the replication statement with sql_slave_skip_counter,
but then the slave would be further out of sync with the master.
And if all else fails, you can always rebuild the slave from the master as a last resort as
well. =)
systemali
Counsellor
Join Date: Jan 2013
Posts: 118
o
o
o
#5
10-09-2013, 10:09 AM
Hello Scott,
Phewww.....My apologies for causing you such a pain
, but none the less the above
explanation was very very useful and i did learn a few things extra
But, I could not salvage the data from its last position and hence i had to redo the whole
replication stuff once again, which i have just completed
All thanks to your guidance ...

Keep it up !!!
Gnite
scott.nemes
Mod Squad
Join Date: Jan 2012
Posts: 313
o
o
o
#6
10-09-2013, 10:22 AM
Glad you got it going again anyway!

If you want some practice, I'd recommend downloading MySQL Sandbox and setting up a
quick replication environment on a test server. You can easily test situations like this, and
practice recovering from them.
I.e. in your test environment:
1. Drop a table on the slave (not the master)
2. Do a "insert into ... select from" statement on the master that uses the table you dropped
on the slave in the FROM part (like your actual issue above)
3. Use mysqldump to dump the missing table from the master and insert it on the slave
4. Restart replication, which should then work now that the correct table exists again on the
slave
MySQL Sandbox:
https://launchpad.net/mysql-sandbox/...-3.0.42.tar.gz
Guide for installation / setup:
http://search.cpan.org/~gmax/MySQL-S...box/Recipes.pm
Last edited by scott.nemes; 10-10-2013, 10:09 AM.

systemali
Counsellor
Join Date: Jan 2013
Posts: 118
o
o
o
#7
10-09-2013, 11:53 PM
Thank you so much for the head'sup Scott..

You have been a life saver !!
REPLICAR BASES DE DATOS

Mysql permite replicar bases de datos, dentro de un mismo servidor mysql (en la misma
mquina), o entre B.D. localizadas en diferentes servidores en red local o remota. Para poder
conseguir replicar uno de los servidores (Servidor M) tiene que ser el maestro y el otro servidor
el esclavo (Servidor E).
Servidor M (Servidor principal, sera el maestro)
Servidor E (Servidor secundario, sera el servidor esclavo).
Cuando indiquemos en el manual Mysql> es porque tenemos que introducir los comandos
dentro de la consola de Mysql.
Para entrar en la consola introducir el comando : mysql -u root -p
Ejemplo del comando en un servidor linux :
# /usr/local/mysql/bin/mysql -u root -p (Puede ser diferente la ruta en tu PC)
En ese momento el servidor mysql pide el password de root , lo introducimos y se accede a la
consola.
La replicacin de Base de Datos en mysql tiene varias caractersticas a considerar y son:
Podemos replicar Bases de Datos en el mismo servidor (Diferentes servicios MySql),

en Servidores diferentes en LAN (Red Local) o WAN (Servidores Remotos).
Se puede configurar (etc/my.cnf), la replicacin parcial o total de las tablas de la Base

de Datos a replicar del Servidor Maestro al Servidor Esclavo/s.
La replicacin es UNIDIRECCIONAL, los datos se copian de una base de datos a otra

en un solo sentido, eso quiere decir que solo en una base de datos se deben actualizar
los datos (sentencias INSERT, UPDATE, DELETE), que es la base de datos maestra, y
la base de datos esclava nunca debe recibir sentencias de actualizacin de las tablas
que se replican, solo consultas (SELECT).
De las tablas de la Base de Datos que no se replican, entre el Servidor Maestro y el

Esclavo, se pueden realizar las sentencias (INSERT, UPDATE y DELETE), en la base
de datos del Servidor Esclavo.
Podemos tener sendos servidores esclavos para cada maestro, pero no varios
maestros para un esclavo.
La replicacin copia exactamente todos los cambios que se van haciendo desde que se
activa el sistema de replicacin, es decir, antes de replicar hay que hacer un backup
definitivo de la base de datos principal a la esclava, para que las 2 bases de datos
tengan exactamente la misma informacin.
Cada servidor esclavo debe tener permiso para conectar con el maestro y solicitar las
actualizaciones.
El servidor esclavo necesita una cuenta en el servidor maestro para que pueda
conectarse. En el servidor maestro, configure una cuenta como sta :
Mysql> GRANT REPLICATION SLAVE ON *.* TO usuario_esclavo@host_esclavo

IDENTIFIED BY contrasea_esclavo;
El servidor maestro crea un hilo de proceso para manejar cada esclavo. En el lado del
servidor esclavo se crean 2 hilos para manejar las tareas de rplica. El primer hilo es
de Entrada/Salida recibe los eventos para procesar del servidor maestro y los escribe
en los registros de reenvo del esclavo. El segundo hilo el SQL lee los eventos de los
registros de reenvo y los ejecuta.
Es aconsejable que las rplicas de las Bases de Datos MySql sean de la misma
versin y si es posible de la 5.x y activos los mismos motores en las 2 B.D.
La actualizacin de la informacin de la Base de datos Mysql Master (total o parcial de sus

tablas), automticamente Mysql actualiza unos ficheros de datos mysql-bin.XXXXXX. Una
vez actualizados estos ficheros se enva un evento al servidor con la base de datos Esclava y
sta se comunica con el Servidor Esclavo para recibir la porcin del fichero de mysqlbin.XXXXXX que le falta; no todo el fichero sino la porcin que le falta por tratar solamente
(esto se sabe por posiciones tratadas dentro del fichero, n linea).
COMANDOS IMPORTANTES PARA VER Y CONTROLAR LA REPLICACIN
1.- Utilidades del Servidor Maestro
Estando dentro del servidor Maestro (M) :
Mysql>SHOW MASTER STATUS;
El master por cada cambio realizado en la Mysql principal (insert, update, delete) trabaja
creando lneas de cambios en un fichero bin.
La sentencia SHOW MASTER STATUS : Indica el fichero .bin que est utilizando el master
para guardar los cambios actualmente y por que posicin va actualmente (lnea dentro del
fichero).
Ejemplo de resultado de SHOW MASTER STATUS/
File = mysql-bin.000122
[Fichero bin actual ]
Position = 269
BinLog_Do_DB = empresa [Base de datos que trata nicamente]
BinLog_Ignore_Db = [BD ignoradas, si BinLog_Do_Db <> el resto]
[ltima posicin insertada]
Estando dentro del servidor Maestro (M) :

Mysql> SHOW PROCESSLISTG;
Muestra el estado del flujo del servidor que se encarga de enviar al esclavo los ficheros de
mensajes actualizaciones en la base de datos del maestro.
*************************** 10. row ***************************
Id: 97
User: replica
Host: 192.168.5.130:48647
db: NULL
Command: Binlog Dump
Time: 1262
State: Has sent all binlog to slave; waiting for binlog to be updated
Info: NULL
2.- Utilidades del Servidor Esclavo

Estando dentro del servidor Esclavo (E) :
Mysql> SHOW SLAVE STATUS;
Master_Host: 192.168.5.130 [Ip master]
Master_User: replica [Usuario master para conectarse]
Master_Port: 3306 [Puerto mysql]
Connect_Retry: 60 [60 Timeout para conectar los 2 servers]
Master_Log_File: mysql-bin.000122 [ltimo Fichero master]
Read_Master_Log_Pos: 269 [ltima posicin en el fichero master]
Relay_Log_File: server-relay-bin.000011 [ltimo log en el esclavo]
Relay_Log_Pos: 406 [ltima posicin en el log del esclavo]
Relay_Master_Log_File: mysql-bin.000122 [ltimo fichero master]
[Muy importante, debe ser yes]
[Muy importante, debe ser yes]
Replicate_Do_DB: empresa [B.D se replica nicamente]
Si los campos Slave_IO_Running : No y Slave_SQL_Running : No.

Por estar el servicio parado en el Servidor Esclavo (E), activar con el mandato :
Mysql> START SLAVE;
Estando an dentro del Servidor Esclavo (E) :
Mysql> SHOW PROCESSLISTG;
El comando ensea para el esclavo los 2 flujos que hay trabajando, en concreto siempre habr
2, el primero que lee del servidor master (flujo entre mquinas), y el segundo, que coge los
datos recibidos y actualiza la base de datos (flujo interno de actualizacin).
El master guarda los cambios en la base de datos en un fichero log, en ciertas posiciones.
Cuando hace esto manda un evento al proceso del esclavo. El esclavo recibe el evento y se
conecta con el flujo 1 al servidor para recibir el log, una vez recibido el flujo 2 mete la
informacin nueva al mysql propio.
*************************** 1. row ***************************
Id: 1
User: system user
Host:
db: NULL
Command: Connect
Time: 2752 (tiempo desde la ltima lectura del master, en segundos)
State: Waiting for master to send event
Info: NULL
*************************** 2. row ***************************
Id: 2
User: system user
Host:
db: NULL
Command: Connect
Time: 12
State: Has read all relay log; waiting for the slave I/O thread to update it
Info: NULL
RESETEAR o PURGAR LOS LOGS EN EN SERVIDOR MAESTRO

Para inicializa los contadores y borra todos los mysql-bin temporales, el mandato es :
Mysql> RESET MASTER;
Para expirar los registros binarios. Podemos utilizar dicha sentencia despus de ejecutar la
sentecia :
Mysql> PURGE MASTER;
En cada uno de los esclavos para determinar qu registros binarios ya no son necesarios.
Mysql> SHOW SLAVE STATUS;
Diagnstico De Problemas De Replicacin De

Mysql
Preguntado el 10 de Julio, 2009
3514 visitas
5 Respuestas
resuelta
Tenemos una replicacin mysql cliente que se ejecuta en nuestro servidor de copia de
seguridad. Desde un fallo de alimentacin, la semana pasada se detiene la replicacin.
Antes de que esto se estaba ejecutando de forma ininterrumpida durante varios meses.
He intentado reiniciar tanto el maestro y el esclavo, pero esto no ha ayudado. Puedo
acceder al servidor maestro del esclavo, por lo que la red no es el problema.
Hay algo ms que pueda hacer para tratar de diagnosticar cul es el problema?
mysql> show slave status\G;
*************************** 1. row ***************************
Slave_IO_State:
Master_Host: master
Master_User: username
Master_Port: 3306
Connect_Retry: 60
Relay_Log_File: mysqld-relay-bin.000348
Relay_Log_Pos: 98
Slave_IO_Running: No
Replicate_Do_DB:
Replicate_Do_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Relay_Log_Space: 98
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
ERROR:
No query specified
mysql> show master status\G;

*************************** 1. row ***************************
File: mysql-bin.000069
Position: 851796
Binlog_Do_DB:
Binlog_Ignore_DB:
ERROR:
No query specified
Actualizacin: Los errores iban a la demonio.de registro, no de mysql.err, lo cual explicara

por qu no poda encontrar. El problema parece ser que el maestro est diciendo que el
registro no est disponible, lo que no tiene mucho sentido, ya que log (y el anterior) estn
todava disponibles en el maestro.
090710 9:17:35 [Note] Slave SQL thread initialized, starting replication in log
'mysql-bin.000060' at position 46277494, relay log './mysqld-relay-bin.000350'
position: 98
090710 9:17:35 [Note] Slave I/O thread: connected to master
'username@master:3306', replication started in log 'mysql-bin.000060' at position
46277494
090710 9:17:35 [ERROR] Error reading packet from server: Client requested master
to start replication from impossible position ( server_errno=1236)
090710 9:17:35 [ERROR] Got fatal error 1236: 'Client requested master to start
replication from impossible position' from master when reading data from
binary log
090710 9:17:35 [Note] Slave I/O thread exiting, read up to log 'mysqlbin.000060', position 46277494
Preguntado el 10 de Julio, 2009 por ExCaliburTR
Ver la pregunta original Server Fault
Mejorar Traduccin
5 Respuestas
Demasiados anuncios?
6
Mejor Respuesta
Ryan SampsonPuntos2898
Bienvenido al maravilloso mundo de la replicacin MySQL. Yo no he golpeado tu

problema en particular a m mismo, pero me he encontrado un montn de otros
problemas extraos y el proceso de solucin es volver a sincronizar desde el
maestro, como si es un nuevo esclavo y hacer con ella.
Respondido el 10 de Julio, 2009 por Ryan Sampson (2898 puntos)
Mejorar Traduccin
MarkRPuntos2323
Usted debe examinar la esclava del error de registro - suele ser muy explcito
acerca de cul es el problema.
Usted debe tener la base de los registros de error ligado a su sistema de
supervisin, de lo contrario tus esclavos son potencialmente intil.
Adems, usted debe tener un monitor en el cual se comprueba el estado de los
esclavos.
Y para ser de cualquier uso en todos, usted tambin desear comprobar la
sincronizacin de los esclavos a partir de tiempo al tiempo, tal vez por el uso de
algo como mk-tabla de suma de comprobacin; lo ideal sera que el empate los
resultados de que en su sistema de monitoreo as.
Respondido el 10 de Julio, 2009 por MarkR (2323 puntos)
Mejorar Traduccin
kashaniPuntos3273
Muchas personas set skip-esclavo-de inicio para que puedan asegurarse de que
todo est bien si un esclavo deja de replicar antes de la puesta en marcha. Intente
ejecutar 'start slave" y ver si algo cambia o si algo se registra. Adems es extrao
que el SlaveSQL proceso se est ejecutando y el SlaveIO no lo es. Es posible que
el rel local de los registros en el esclavo ha sido daado a pesar de que debe ser
reportado en los registros. Usted puede tratar de llevar Mysql hacia abajo y, a
continuacin, eliminar el rel de registros.
Respondido el 10 de Julio, 2009 por kashani (3273 puntos)
Mejorar Traduccin
user49957Puntos121
Como womble ha mencionado, olvdate de solucin de problemas errores de

replicacin. La cosa que me preocupa ms acerca de este enfoque es que usted
puede tener xito en conseguir la replicacin para reiniciar de nuevo y pensar que
todo est bien, pero lo que si algunas partes de tu db todava estn fuera de
sincronizacin?
Mejor es nuclear el esclavo de la base de datos y reiniciar la replicacin a partir de
una instantnea de la maestra. No debera ser tan perjudicial como usted podra
pensar:
http://www.neotitans.com/resources/mysql/quick-replication-error-recovery-viasnapshots.html
Respondido el 2 de Agosto, 2010 por user49957 (121 puntos)
Mejorar Traduccin
BakshuPuntos1
Desde el informe anterior que he encontrado el problema, este fieled debe ser
ajustado a (Slave_IO_Running): s, pero en el informe anterior se muestra
Slave_IO_Running: No.
Eso es la causa del problema, Si esta variable se lee 'No', entonces la IO hilo se ha
causado a parar. as que no hay replicacin. Usted tendr que comprobar la
Last_SQL_Errno y Last_SQL_Err para obtener ms informacin sobre la causa. Un
nmero de error de 0 y el mensaje de la cadena vaca significa que "no hay error".
El Last_SQL_Error aparece en el esclavo del registro de errores.
Para solucionar este problema, detenga el esclavo
A continuacin, establezca:
mysql> SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1;
Esto le dice al esclavo que saltarse una consulta (que es el invlido que caus la
replicacin a parar). Si usted desea saltar dos consultas, tendra que utilizar SET
GLOBAL SQL_SLAVE_SKIP_COUNTER = 2; en su lugar y as sucesivamente.
A continuacin, reinicie el esclavo y la verificacin de los registros, con la
Esperanza de que esto va a solucionar el problema...
MySQL slave I/O thread not running

up
vote1
down
vote
favorite
I have set up replication for MySQL server. I can connect from the slave machine
to the master server using the replication user/password. I have got the slave SQL
thread running, but the slave I/Othread is not running and the slave I/O status
comes as empty when checked using 'show slave status'. What could be the
problem?
How do I solve this? Restarting the slave does not help.
This was my bad: Instead of giving a 'replication slave' privilege to *.*, I was
only giving it for my_db.*.
mysql
replication
slave
shareimprove this question

11:32
asked
17:59
Peter Mortensen
Champ
8,711105895
323
add a comment
4 Answers
activeoldest
votes
up
vote3
down
vote
Instead of giving a 'replication slave' privilege to ., I was only giving it for

my_db.*.
accepted
Replication slave is only a global privilege (i.e. per-user only), this means that a
command such as
GRANT REPLICATION SLAVE on mydb.* TO 'someuser'@'%';
has no effect as you can't grant it per-database/column/table.
The command you need to run is:

GRANT REPLICATION SLAVE on *.* TO 'someuser'@'%';
Then do a START SLAVE. You might also find it useful to look in the mysql error
log.
I'd suggest a good read of the replication setup documentation, as it explains all
of this in detail.
edited Nov 28 '09 at

12:48
answered
12:20
brian-brazil
4,323
add a comment
up
vote3
down
vote
I have encountered the same problem and I try this steps

First add this code somewhere below [mysqld] in my.cnf or my.ini slave-skiperrors=1046 this will skip all duplicate entry since we will execute the whole
binary log file where the replication stop, you may comment this code after
successful replication.
1.STOP SLAVE;
2.RESET SLAVE;
3.CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000049';
Note: MASTER_LOG_FILE must be the last file where it stop from replicating
4.CHANGE MASTER TO MASTER_LOG_POS=98;

5.START SLAVE;
check if you are successful
answered
9:53
Luxknight007
31
add a comment
up
vote2
down
vote
@Luxknight007 Step 2 is very dangerous and is not required at all.

2.RESET SLAVE (should not run this command)
RESET SLAVE makes the slave forget its replication position in the master's
binary log. This statement is meant to be used for a clean start: It deletes the
master.info and relay-log.info files, all the relay log files, and starts a new relay
log file. Link

12:28
answered
12:22
M Arif
144
add a comment
up
vote1d
own
vote
I faced same issue and fixed using following steps. Complete thread link
ishttp://www.percona.com/forums/questions-discussions/perconaxtrabackup/11842-backup-stopped-working-slave-sql-running-no
Steps are same as mentioned by @Luxknight007 except his step 2. However this
thread contains more detail which is very helpful. Following is solution which i
used and it worked.
"The first issue is that you changed the replication position instead of fixing the
error, and used an incorrect binlog file name format (you likely just used the one
from that post you linked I'd guess). To get back to where you started, you need
to find the binlog file and position that the slave sql_thread stopped at. Based on
your slave status output, it looks like the slave is reading from a new binlog file
(you can see that the Read_Master_Log_Pos value is smaller than the
Exec_Master_Log_Pos value, which means it has to be reading a newer binlog
file than where the slave sql_thread stopped at), so you need to find the binlog
file that the slave sql_thread actually failed on. So look in the error log for
something like the below:
Code:
2013-10-08 12:48:51 37545 [ERROR] Slave SQL: Error 'Table 'testdb.test2'
doesn't exist' on query. Default database: 'testdb'. Query: 'insert into
test1 select * from test2', Error_code: 1146
2013-10-08 12:48:51 37545 [Warning] Slave: Table 'testdb.test2' doesn't
exist Error_code: 1146
2013-10-08 12:48:51 37545 [ERROR] Error running query, slave SQL
thread aborted. Fix the problem, and restart the slave SQL thread with
"SLAVE START". We stopped at log 'mysql-bin.000001' position 3427
This is a sample I re-created, so yours will be a bit different. Note the ERROR is
similar to what you see in your slave status. So find your specific error message
in the error log file, and then locate the end part where is gives you the file name
and position ("We stopped at log 'mysql-bin.000001' position 3427" in my
example). The position should be 315098143 based on your show slave status, as
that is when it the slave sql_thread stopped executing events
(Exec_Master_Log_Pos ) but the io_thread kept reading in new ones
Once you find the correct binlog file name and position, re-run your change
master statement on your slave using the information you located in the error
log. Note that your file name should be something like "newcrmdb1bin.XXXXXX", not mysql-bin.XXXXXX (you can see this naming convention
your show slave status above).
Code:
mysql> change master to MASTER_LOG_FILE='newcrmdb1-bin.XXXXXX',
change master to MASTER_LOG_FILE='mysql-bin.000082' ,
Once you get pointed back to the original replication location where the slave
sql_thread failed, you need to then fix the error that it was complaining about to
start with.
The initial replication error appears to be telling you that the
table asteriskcdr.bpleadcf does not exist on the slave, so the insert statement is
failing when it attempts to select the data from that table. So the problem there is
that your slave appears to be already out of sync with your master. If the table in
question on the master is static or mostly static, you could likely solve this by
exporting the data from just that table on the master using mysqldump and
loading it into the slave. If that is not possible, or you do not care about that data,
you could always just skip the replication statement with
sql_slave_skip_counter, but then the slave would be further out of sync with the
master.
And if all else fails, you can always rebuild the slave from the master as a last
resort as well. =)"
Microsoft - helping keep SitePoint free
In my last article, I took you through Phase 1 of setting up the MySQL

Master-Slave relationship.
Now, we have the Master SQL Server running and serving our clients,
which connect using remote IPs. Also, the Master has a replication
server id (e.g. 100) and waits for the Slave connections with a user
that is allowed replication (e.g. repl).
We also have Slave SQL Node almost ready to start.
What we are going to do now is the following:
1.
a.
b.
c.
On Master,
get the Replication Master Binary Log Coordinates
create a data snapshot using mysqldump
transfer the data on Slave
a.
b.
On Slave,
Restore the data snapshot
Set the Slave to start replication.
2.
Detailed Actions
On Master
During steps 1 and 2 below, your Master database will be set to readonly mode.
1.
a.
Get Master Coordinates

Open a MySQL shell and give:
mysql> FLUSH TABLES WITH READ LOCK;

b.
IMPORTANT. Leave this shell open and create another mysql

client shell, i.e. another session:
c.
Hence, on another session, type in the following mysql

command:
mysql> SHOW MASTER STATUS;

Write down the values for the column FILE and POSITION. You will
need them later when setting up the Slave to start replication
2.
On a command prompt, get a data snapshot:
os-shell> mysqldump --all-databases --master-data > dbdump.db

If you have a big database, this might take quite some time. In our
case, for a 25Gb database, it took something like 15 minutes.
3.
Release lock and allow your Master to play
When your data dump finishes, just close the connection you opened
on step 1 and your Master database server will resume serving
transactions.
Now, you have a database file you can use on Slave to restore the
database. You have to transfer this file to your Slave node.It might be
a good idea to tar and gzip this file before transferring it and then
untar and unzip it at the Slave node.
On Slave
Assuming that you have transferred your database dump file to Slave,
you move on to work on this node as follows:
1.
Start MySQL server with --skip-slave-start option so that replication

does not start. Here is the suggested way:
On your operating system command prompt:

os-shell> mysqld_safe -skip-slave-start
2.
Import the dump file:

On another operating system command prompt:
os-shell> mysql u root p < dbdump.db

This will start the import. It will take quite some time if your dump file is
big.
Important gotcha:: Before you start the import, make sure that you
have enough space both on the datadir of MySQL and on the binary log
directory too.
3.
Stop MySQL Server

Assuming that import has finished successfully, and assuming that on
step 1 above you started the MySQL Server skipping slave start, you
need to stop this and make sure that MySQL server is not running.
Some Problems that you might have now on Slave
The problem that you have now is that you restored the system
databases as well. These are coming from your Master server,
which has a different IP. This will mean that root user might not
have any access to MySQL server now from the local Slave
machine.
Also, root might have different password. In Debian machine this
is encrypted in the filedebian.cnf in your MySQL installation
directory.
You can bring the debian.cnf file from your Master to your Slave
machine. Or you can change/reset the root password on your
Slave machine.
Hint: You can change/reset the root password on MySQL server as
follows:
o
Start MySQL so that it will not ask for password. Also, make
sure it does not start replication:
os-shell> mysqld_safe -skip-slave-start skip-grant-tables

Then connect with mysql u root and issue a command to
update root password as follows:
mysql> use mysql;

mysql> update user set password=PASSWORD(new-password)
WHERE User = root;
mysql> flush privileges;
o
4.
Stop MySQL Server that you started with skipping slave start
and grant tables.
Start MySQL Server with skipping Slave Start
os-shell> mysqld_safe -skip-slave-start

5.
Set Master configuration on the Slave

Execute the following command on a MySQL prompt:
mysql > CHANGE MASTER TO MASTER_HOST=10.100.10.80,

MASTER_USER=repl, MASTER_PASSWORD=slavepassword,
MASTER_LOG_FILE=mysql-bin.000003, MASTER_LOG_POS=106;
6.
This is how you tell Slave how to connect to Master in order to replicate.
Note the log coordinates. These are the coordinates you got from step 1
above.
7.
Stop MySQL that you have started on step 4 above.
8.
Start MySQL normally, e.g. on an OS shell:
os-shell> /etc/ini.d/mysql start
Checking out that everything is OK

Having started the slave MySQL node, you can log in and issue some
commands to make sure that Slave is running OK.
1.
On mysql prompt, give the following command:
mysql> show processlist;

The output should be something similar to the following:
2.
+----+-------------+-----------+-------+--------+-----+----------------------------------------------------------------------+------------------+
3.
4.
| Id | User
Time | State
| Host
| db
| Info
| Command |
|
5.
6.
+----+-------------+-----------+-------+--------+------
+----------------------------------------------------------------------+------------------+
7.
8.
| 1 | system user |
| NULL | Connect |
232 | Has read all relay log; waiting for the slave I/O
thread to update it | NULL
|
9.
10. | 2 | system user |
| NULL
232 | Waiting for master to send
event
NULL
|
| Connect |
|
11.
12. | 39 | root
| localhost | mysql | Query
0 |
NULL
| show processlist |
13.
14. +----+-------------+-----------+-------+--------+-----+----------------------------------------------------------------------+------------------+
15.
16.
3 rows in set (0.00 sec)
You can see the SQL thread that gets data from Master (in the
above output is the thread with Id 2) and the SQL thread that
executes the statements on Slave (in the output is the thread
with Id 1).
17.
On mysql prompt, give the following command
mysql> show slave status;

This will display the current status on slave. Pay attention to
the *_Errno and *_Error columns. Normally, you shouldnt see anything
that indicates existence of errors there.
18.
On mysql prompt, give the following command
mysql> show status like Slave%;

You should see an output like the following:
19.
+----------------------------+-------+
20.
21.
| Variable_name
| Value |
22.
23.
+----------------------------+-------+
24.
25.
| Slave_open_temp_tables
| 0
| Slave_retried_transactions | 0
| Slave_running
26.
27.
28.
29.
| ON
30.
31.
+----------------------------+-------+
32.
3 rows in set (0.00 sec)
Pay attention to Slave_running being with value ON.
Important note on binary log time to

live
As we have said before, you can have Slave down and resynchronize
as soon as you bring it up again. But do not put it out of service for
quite long because, then it will be impossible to synchronize its
content with Master. This is because the binary logs on Master do not
leave forever.
There is the variable with name expire_logs_days that determines the
number of days for automatic binary log file removal. Check this out.
This should be 10, meaning that if you ever have your Slave down for
10 days or more, it will not be able to do replication as soon as you
bring it up, and you will have to everything from the beginning.
Conclusion
That was our story on how, more or less, we have implemented
MySQL replication for our Fraudpointer application. The steps may not
apply exactly to your particular case, but they can still give you a kick
start and show you the way to implement replication the way it should
work on your configuration.
Your comments are more than welcome. We want them. We need to
improve this process and your feedback is absolutely valuable to us.
How To Repair MySQL Replication

Version 1.0
Author: Falko Timme
If you have set up MySQL replication, you probably know this problem:
sometimes there are invalid MySQL queries which cause the replication to not
work anymore. In this short guide I explain how you can repair the replication on
the MySQL slave without the need to set it up from scratch again.
I do not issue any guarantee that this will work for you!
1 Identifying The Problem

To find out whether replication is/is not working and what has caused to stop it,
you can take a look at the logs. On Debian, for example, MySQL logs
to/var/log/syslog:
grep mysql /var/log/syslog
server1:/home/admin# grep mysql /var/log/syslog

May 29 09:56:08 http2 mysqld[1380]: 080529 9:56:08 [ERROR] Slave:
Error 'Table 'mydb.taggregate_temp_1212047760' doesn't exist' on
query. Default database: 'mydb'. Query: 'UPDATE thread AS
thread,taggregate_temp_1212047760 AS aggregate
May 29 09:56:08 http2 mysqld[1380]: ÎSET thread.views =
thread.views + aggregate.views
May 29 09:56:08 http2 mysqld[1380]: ÎWHERE thread.threadid =
aggregate.threadid', Error_code: 1146
May 29 09:56:08 http2 mysqld[1380]: 080529 9:56:08 [ERROR] Error
running query, slave SQL thread aborted. Fix the problem, and
restart the slave SQL thread with "SLAVE START". We stopped at log
'mysql-bin.001079' position 203015142
server1:/home/admin#
You can see what query caused the error, and at what log position the
replication stopped.
To verify that the replication is really not working, log in to MySQL:
mysql -u root -p
On the MySQL shell, run:
If one of Slave_IO_Running or Slave_SQL_Running is set to No, then the

replication is broken:
*************************** 1. row ***************************
Master_User: slave_user
Master_Port: 3306
Connect_Retry: 60
Relay_Log_File: slave-relay.000130
Slave_SQL_Running: No
Replicate_Do_DB: mydb
Replicate_Do_Table:
Last_Errno: 1146
Last_Error: Error 'Table 'mydb.taggregate_temp_121
2047760' doesn't exist' on query. Default database: 'mydb'.
Query: 'UPDATE thread AS thread,taggregate_temp_1212047760 AS aggre
gate
SET thread.views = thread.views + aggregate.views
WHERE thread.threadid = aggregate.threadid'
Skip_Counter: 0
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
mysql>
2 Repairing The Replication

Just to go sure, we stop the slave:
mysql> STOP SLAVE;
Fixing the problem is actually quite easy. We tell the slave to simply skip the
invalid SQL query:
mysql> SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1;
This tells the slave to skip one query (which is the invalid one that caused the
replication to stop). If you'd like to skip two queries, you'd use SET GLOBAL
SQL_SLAVE_SKIP_COUNTER = 2; instead and so on.
That's it already. Now we can start the slave again...
mysql> START SLAVE;
... and check if replication is working again:

*************************** 1. row ***************************
Master_User: slave_user
Master_Port: 3306
Connect_Retry: 60
Relay_Log_File: slave-relay.000130
Replicate_Do_DB: mydb
Replicate_Do_Table:
Last_Errno:
Last_Error:
Skip_Counter:
Exec_Master_Log_Pos:
Relay_Log_Space:
Until_Condition:
Until_Log_File:
Until_Log_Pos:
Master_SSL_Allowed:
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master:
0
0
447560366
225644062
None
0
No
mysql>
As you see, both Slave_IO_Running and Slave_SQL_Running are set
to Yes now.
Now leave the MySQL shell...
mysql> quit;
... and check the log again:
grep mysql /var/log/syslog
server1:/home/admin# grep mysql /var/log/syslog

May 29 09:56:08 http2 mysqld[1380]: 080529 9:56:08 [ERROR] Slave:
Error 'Table 'mydb.taggregate_temp_1212047760' doesn't exist' on
query. Default database: 'mydb'. Query: 'UPDATE thread AS
thread,taggregate_temp_1212047760 AS aggregate
May 29 09:56:08 http2 mysqld[1380]: ÎSET thread.views =
thread.views + aggregate.views
May 29 09:56:08 http2 mysqld[1380]: ÎWHERE thread.threadid =
aggregate.threadid', Error_code: 1146
May 29 09:56:08 http2 mysqld[1380]: 080529 9:56:08 [ERROR] Error
running query, slave SQL thread aborted. Fix the problem, and
restart the slave SQL thread with "SLAVE START". We stopped at log
'mysql-bin.001079' position 203015142
May 29 11:42:13 http2 mysqld[1380]: 080529 11:42:13 [Note] Slave
SQL thread initialized, starting replication in log 'mysqlbin.001079' at position 203015142, relay log '/var/lib/mysql/slaverelay.000130' position: 100125935
server1:/home/admin#
The last line says that replication has started again, and if you see no errors
after that line, everything is ok.
3 Links
MySQL: http://www.mysql.com
view as pdf |
print
Share this page:
12 Comment(s)
Add comment
Name *
Email *
p
Submit comment
Comments
From: Perry Whelan
Reply
I'm managing an infrastructure with a number of databases who (for codified
reasons that I cannot influence) suffer from this situation often. So, I've written
a cron script to manage the situation.
Does anyone see any foreseeable issues with this logic (see below)?
#!/bin/bash
## Tool to unstick MySQL Replicators.
## Set to run from cron once a minute.
# */1 * * * * /usr/local/bin/whipSlave.mysql.sh > /dev/null 2>&1

# Last updated: MM/DD/YYYY
COMMANDS="mysql grep awk logger"
export PATH='/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin'
for i in $COMMANDS
do
X=ècho $i | tr '[a-z]' '[A-Z]'`
export $X=`type -p $i`
done
# Define variables
USERNAME=dbuser
PASSWORD=password
# Define Functions
## Obtain MwSQL slave server status
function SLAVE()
{
STATUS=`$MYSQL -u $USERNAME -p$PASSWORD -e \
"SHOW SLAVE STATUS \G" |
$GREP Seconds_Behind_Master |
$AWK '{print $2}'`
}
## Skip errors
function UNSTICK()
{
$MYSQL -u $USERNAME -p$PASSWORD -e \
"STOP SLAVE; SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1; START
SLAVE;"
sleep 5
# Check everything again
CHECK
}
## Decide what to do...
function CHECK()
{
# Obtain status
SLAVE
if [ $STATUS = NULL ]
then
# I think the replicator is broken

echo "MySQL Slave database is not replicating. Fixing..." |
$LOGGER
UNSTICK
else
# Everything should be fine
echo "MySQL Slave is $STATUS seconds behind its Master." |
$LOGGER
fi
}
## Are we running?
function ALIVE()
{
UP=`$MYSQL -u $USERNAME -p$PASSWORD -e \
"SHOW SLAVE STATUS \G" |
$GREP Slave_IO_Running |
$AWK '{print $2}'`
if [ $UP = Yes ]
then
# Let's check if everything is good, then...
CHECK
else
# Uh oh...let's not do anything.
echo "MySQL Slave IO is not running!" | $LOGGER
exit 1
fi
}
# How is everything?
ALIVE
#EoF
exit 0
From: Jeff Buchbinder
Reply
This might be a little bit simpler (works with MySQL 5.0+, I believe):
#!/bin/bash done=0 while [ $done -eq 0 ]; do # get status done=$
( mysql -Be 'show slave status;' | tail -1 | cut -f12 | grep Yes | wc
-l ) if [ $done -eq 0 ]; then echo "Advancing position past [$(mysql
-Be 'show slave status;' | tail -1 | cut -f20)]... " mysql -uroot -Be
"SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1; start slave;" sleep 1 fi done
From: Anonymous
Reply
while [ ! "`mysql -uroot -Be 'SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1;
start slave;'`" ]
do
echo "Skipped one Error"
sleep 1
done ; echo "All set"
From: Anonymous
Reply
True, but, sometimes the slave will try to execute things that don't apply like a
"drop trigger" statement for a trigger that doesn't ever exist because the slave
is only replicating specific tables.
From: Richard
Reply
Bear in mind that any time you have a query which *did* successfully execute
on the master and is skipped on the slave and you use a
SQL_SLAVE_SKIP_COUNTER method to "fix" the problem, your master and
slave are now no longer in sync. Yes, this is sometimes necessary, but if it is
a recurring issue, then the problems go much deeper than merely broken
replication.
From: Anonymous
Reply
Indeed. And if you skip a query to 'fix' the replication, you run the very serious
risk that the replication will become even more out of sync further down the
line. This isn't fixing, it's just brushing the problem under the carpet and hoping
it goes away. If you must skip a query, look at the query first, and be sure its
absence won't cause future queries to fail
From: Anonymous
Reply
noted that this is not the proper "fix" for the problem, but we are missing your
proposed solution
From: sureshkumar
Reply
Thanks.......... Good work ...
From: Farshid
Reply
Thank you. I got replication working without having to rebuild in middle of night
remotely!
From: Ramanath
Reply
What i have to do if Slave_IO_Running: No and Seconds_Behind_Master: NULL.
Please help me.I am waiting for your response.
http://www.howtoforge.com/how-to-repair-mysql-replication.. In this link you
have mentioned the solution for Slave_SQL_Running: No.Please suggest me for
Slave_IO_Running: No and Seconds_Behind_Master: NULL
From: Some Guy
Reply
Thanks man, saved me today :)
From: Eternal
Reply
Thanks, pretty useful article.
Replication Slave Options and Variables

Startup Options for Replication Slaves
Obsolete Replication Slave Options
System Variables Used on Replication Slaves
This section describes the server options and system variables that apply to slave
replication servers. You can specify the options either on the command line or in an option
file. Many of the options can be set while the server is running by using the CHANGE
MASTER TO statement. You can specify system variable values using SET.
Server ID. On the master and each slave, you must use the server-id option to establish
a unique replication ID in the range from 1 to 232 1. Unique means that each ID must
be different from every other ID in use by any other replication master or slave.
Example my.cnf file:
[mysqld]
server-id=3
Startup Options for Replication Slaves

The following list describes startup options for controlling replication slave servers. Many of
these options can be set while the server is running by using the CHANGE MASTER
TO statement. Others, such as the --replicate-*options, can be set only when the slave
server starts. Replication-related system variables are discussed later in this section.
--abort-slave-event-count
Command-Line Format
Permitted Values
--abort-slave-event-count=#
Type
integer
Default
Min Value
When this option is set to some positive integer value other than 0 (the default) it
affects replication behavior as follows: After the slave SQL thread has
started, value log events are permitted to be executed; after that, the slave SQL
thread does not receive any more events, just as if the network connection from the
master were cut. The slave thread continues to run, and the output from SHOW
SLAVE STATUS displays Yes in both theSlave_IO_Running and
the Slave_SQL_Running columns, but no further events are read from the relay
log.
This option is used internally by the MySQL test suite for replication testing and
debugging. It is not intended for use in a production setting.
--disconnect-slave-event-count
Command-Line Format
Permitted Values
--disconnect-slave-event-count=#
Type
integer
Default
This option is used internally by the MySQL test suite for replication testing and
debugging.
--log-slave-updates
Command-Line Format
System Variable
Permitted Values
--log-slave-updates
Name
log_slave_updates
Variable Scope
Global
Dynamic Variable
No
Type
boolean
Default
OFF
Normally, a slave does not log to its own binary log any updates that are received
from a master server. This option tells the slave to log the updates performed by its
SQL thread to its own binary log. For this option to have any effect, the slave must
also be started with the --log-bin option to enable binary logging. Prior to
MySQL 5.5, the server would not start when using the --log-slaveupdates option without also starting the server with the --log-bin option, and
would fail with an error; in MySQL 5.5, only a warning is generated. (Bug
#44663) --log-slave-updates is used when you want to chain replication

servers. For example, you might want to set up replication servers using this
arrangement:
A -> B -> C
Here, A serves as the master for the slave B, and B serves as the master for the
slave C. For this to work, B must be both a master and a slave. You must start
both A and B with --log-bin to enable binary logging, and B with the --logslave-updates option so that updates received from A are logged by B to its
binary log.
--log-slow-slave-statements
Command-Line Format
Permitted Values
--log-slow-slave-statements
Type
boolean
Default
OFF
When the slow query log is enabled, this option enables logging for queries that
have taken more thanlong_query_time seconds to execute on the slave.
--log-warnings[=level]
Command-Line Format
System Variable
Permitted Values (32-bit platforms)
--log-warnings[=#]
Name
log_warnings
Variable Scope
Global, Session
Dynamic Variable Yes

Type
integer
Default
Min Value
Max Value
4294967295
Permitted Values (64-bit platforms, <= 5.5.2) Type
integer
Default
Min Value
Max Value
18446744073709547520
Type
integer
Default
Min Value
Permitted Values (64-bit platforms, >= 5.5.3) Max Value
18446744073709551615
This option causes a server to print more messages to the error log about what it is
doing. With respect to replication, the server generates warnings that it succeeded
in reconnecting after a network/connection failure, and informs you as to how each
slave thread started. This option is enabled (1) by default; to disable it, use --logwarnings=0. If the value is greater than 1, aborted connections are written to the
error log, and access-denied errors for new connection attempts are written.
See Section B.5.2.11, Communication Errors and Aborted Connections.
Note that the effects of this option are not limited to replication. It produces
warnings across a spectrum of server activities.
--master-info-file=file_name
Command-Line Format
Permitted Values
--master-info-file=file_name
Type
file name
Default
master.info
The name to use for the file in which the slave records information about the
master. The default name ismaster.info in the data directory. For information
about the format of this file, see Section 17.2.2.2, Slave Status Logs.
--master-retry-count=count
Command-Line Format
--master-retry-count=#
Type
integer
Default
86400
Min Value
Max Value
4294967295
Type
integer
Default
86400
Min Value
Max Value
18446744073709551615
The number of times that the slave tries to connect to the master before giving up.
Reconnects are attempted at intervals set by the MASTER_CONNECT_RETRY option
of the CHANGE MASTER TO statement (default 60). Reconnects are triggered when
data reads by the slave time out according to the --slave-net-timeout option.
The default value is 86400. A value of 0 means infinite; the slave attempts to
connect forever.
slave-max-allowed-packet=bytes
Introduced
5.5.26
Command-Line Format
--slave-max-allowed-packet=#
Permitted Values
Type
integer
Default
1073741824
Min Value
1024
Max Value
1073741824
In MySQL 5.5.26 and later, this option sets the maximum packet size in bytes for
the slave SQL and I/O threads, so that large updates using row-based replication
do not cause replication to fail because an update
exceededmax_allowed_packet. (Bug #12400221, Bug #60926)
The corresponding server variable slave_max_allowed_packet always has a

value that is a positive integer multiple of 1024; if you set it to some value that is
not such a multiple, the value is automatically rounded down to the next highest
multiple of 1024. (For example, if you start the server with --slave-maxallowed-packet=10000, the value used is 9216; setting 0 as the value causes
1024 to be used.) A truncation warning is issued in such cases.
The maximum (and default) value is 1073741824 (1 GB); the minimum is 1024.
--max-relay-log-size=size
Command-Line Format
System Variable
Permitted Values
--max_relay_log_size=#
Name
max_relay_log_size
Variable Scope
Global
Dynamic Variable
Yes
Type
integer
Default
Min Value
Max Value
1073741824
The size at which the server rotates relay log files automatically. If this value is
nonzero, the relay log is rotated automatically when its size exceeds this value. If
this value is zero (the default), the size at which relay log rotation occurs is
determined by the value of max_binlog_size. For more information,
see Section 17.2.2.1, The Slave Relay Log.
--relay-log=file_name
Command-Line Format
System Variable
Name
relay_log
Variable Scope
Global
Dynamic Variable
No
Permitted Values
Type
file name
The base name for the relay log. The default base name is host_name-relaybin. The server writes the file in the data directory unless the base name is given
with a leading absolute path name to specify a different directory. The server
creates relay log files in sequence by adding a numeric suffix to the base name.
Due to the manner in which MySQL parses server options, if you specify this
option, you must supply a value; the default base name is used only if the option is
not actually specified. If you use the --relay-log option without specifying a
value, unexpected behavior is likely to result; this behavior depends on the other
options used, the order in which they are specified, and whether they are specified
on the command line or in an option file. For more information about how MySQL
handles server options, see Section 4.2.3, Specifying Program Options.
If you specify this option, the value specified is also used as the base name for the
relay log index file. You can override this behavior by specifying a different relay log
index file base name using the --relay-log-indexoption.
Starting with MySQL 5.5.20, when the server reads an entry from the index file, it
checks whether the entry contains a relative path. If it does, the relative part of the
path in replaced with the absolute path set using the --relay-log option. An
absolute path remains unchanged; in such a case, the index must be edited
manually to enable the new path or paths to be used. Prior to MySQL 5.5.20,
manual intervention was required whenever relocating the binary log or relay log
files. (Bug #11745230, Bug #12133)
You may find the --relay-log option useful in performing the following tasks:
o
Creating relay logs whose names are independent of host names.
If you need to put the relay logs in some area other than the data directory
because your relay logs tend to be very large and you do not want to
decrease max_relay_log_size.
To increase speed by using load-balancing between disks.
--relay-log-index=file_name
Command-Line Format
--relay-log-index=file_name
Name
relay_log_index
Variable Scope
Global
System Variable
Dynamic Variable
No
Permitted Values
Type
file name
The name to use for the relay log index file. The default name
is host_name-relay-bin.index in the data directory,
where host_name is the name of the slave server.
Due to the manner in which MySQL parses server options, if you specify
this option, you must supply a value; the default base name is used only if
the option is not actually specified. If you use the --relay-logindex option without specifying a value, unexpected behavior is likely to
result; this behavior depends on the other options used, the order in which
they are specified, and whether they are specified on the command line or
in an option file. For more information about how MySQL handles server
options, see Section 4.2.3, Specifying Program Options.
If you specify this option, the value specified is also used as the base name
for the relay logs. You can override this behavior by specifying a different
relay log file base name using the --relay-log option.
--relay-log-info-file=file_name
Command-Line Format
Permitted Values
Type
file name
Default
relay-log.info
The name to use for the file in which the slave records information about
the relay logs. The default name isrelay-log.info in the data directory.
For information about the format of this file, see Section 17.2.2.2, Slave
Status Logs.
--relay-log-purge={0|1}
Command-Line Format
System Variable
Permitted Values
--relay_log_purge
Name
relay_log_purge
Variable Scope
Global
Dynamic Variable
Yes
Type
boolean
Default
TRUE
Disable or enable automatic purging of relay logs as soon as they are no

longer needed. The default value is 1 (enabled). This is a global variable
that can be changed dynamically with SET GLOBAL relay_log_purge
= N.
--relay-log-recovery={0|1}
Command-Line Format
Permitted Values
--relay-log-recovery
Type
boolean
Default
FALSE
Enables automatic relay log recovery immediately following server startup,

which means that the replication slave discards all unprocessed relay logs
and retrieves them from the replication master. This should be used
following a crash on the replication slave to ensure that no possibly
corrupted relay logs are processed. The default value is 0 (disabled).
--relay-log-space-limit=size
Command-Line Format
--relay_log_space_limit=#
System Variable
Name
relay_log_space_limit
Variable Scope
Global
Dynamic
No
Variable
Permitted Values (64-bit platforms, <=

5.5.2)
Permitted Values (64-bit platforms, >=

5.5.3)
Type
integer
Default
Min Value
Max Value
4294967295
Type
integer
Default
Min Value
Max Value
18446744073709547520
Type
integer
Default
Min Value
Max Value
18446744073709551615
This option places an upper limit on the total size in bytes of all relay logs
on the slave. A value of 0 means no limit. This is useful for a slave
server host that has limited disk space. When the limit is reached, the I/O
thread stops reading binary log events from the master server until the SQL
thread has caught up and deleted some unused relay logs. Note that this
limit is not absolute: There are cases where the SQL thread needs more
events before it can delete relay logs. In that case, the I/O thread exceeds
the limit until it becomes possible for the SQL thread to delete some relay
logs because not doing so would cause a deadlock. You should not set -relay-log-space-limit to less than twice the value of --max-relaylog-size (or --max-binlog-size if --max-relay-log-size is 0). In
that case, there is a chance that the I/O thread waits for free space
because --relay-log-space-limit is exceeded, but the SQL thread
has no relay log to purge and is unable to satisfy the I/O thread. This forces
the I/O thread to ignore --relay-log-space-limit temporarily.
--replicate-do-db=db_name
Command-Line Format
--replicate-do-db=name
Permitted Values
Type
string
The effects of this option depend on whether statement-based or rowbased replication is in use.
Statement-based replication. Tell the slave SQL thread to restrict

replication to statements where the default database (that is, the one
selected by USE) is db_name. To specify more than one database, use this
option multiple times, once for each database; however, doing so
does not replicate cross-database statements such
asUPDATE some_db.some_table SET foo='bar' while a different
database (or no database) is selected.
Warning
To specify multiple databases you must use multiple instances of this

option. Because database names can contain commas, if you supply a
comma separated list then the list will be treated as the name of a single
database.
An example of what does not work as you might expect when using
statement-based replication: If the slave is started with --replicate-dodb=sales and you issue the following statements on the master,
the UPDATEstatement is not replicated:
USE prices;
UPDATE sales.january SET amount=amount+1000;
The main reason for this check just the default database behavior is
that it is difficult from the statement alone to know whether it should be
replicated (for example, if you are using multiple-table DELETE statements
or multiple-table UPDATE statements that act across multiple databases). It
is also faster to check only the default database rather than all databases if
there is no need.
Row-based replication. Tells the slave SQL thread to restrict replication

to database db_name. Only tables belonging to db_name are changed; the
current database has no effect on this. Suppose that the slave is started
with --replicate-do-db=sales and row-based replication is in effect,
and then the following statements are run on the master:
USE prices;
UPDATE sales.february SET amount=amount+100;
The february table in the sales database on the slave is changed in

accordance with the UPDATE statement; this occurs whether or not
the USE statement was issued. However, issuing the following statements
on the master has no effect on the slave when using row-based replication
and --replicate-do-db=sales:
USE prices;
UPDATE prices.march SET amount=amount-25;
Even if the statement USE prices were changed to USE sales,

the UPDATE statement's effects would still not be replicated.
Another important difference in how --replicate-do-db is handled in

statement-based replication as opposed to row-based replication occurs
with regard to statements that refer to multiple databases. Suppose that the
slave is started with --replicate-do-db=db1, and the following
statements are executed on the master:
USE db1;
UPDATE db1.table1 SET col1 = 10, db2.table2 SET col2 = 20;
If you are using statement-based replication, then both tables are updated
on the slave. However, when using row-based replication, only table1 is
affected on the slave; since table2 is in a different database, table2 on
the slave is not changed by the UPDATE. Now suppose that, instead of
the USE db1 statement, a USE db4statement had been used:
USE db4;
UPDATE db1.table1 SET col1 = 10, db2.table2 SET col2 = 20;
In this case, the UPDATE statement would have no effect on the slave when
using statement-based replication. However, if you are using row-based
replication, the UPDATE would change table1 on the slave, but not table2
in other words, only tables in the database named by --replicate-do-
db are changed, and the choice of default database has no effect on this
behavior.
If you need cross-database updates to work, use --replicate-wild-dotable=db_name.% instead. SeeSection 17.2.3, How Servers Evaluate
Replication Filtering Rules.
Note
This option affects replication in the same manner that --binlog-dodb affects binary logging, and the effects of the replication format on
how --replicate-do-db affects replication behavior are the same as

those of the logging format on the behavior of --binlog-do-db.
This option has no effect on BEGIN, COMMIT, or ROLLBACK statements.
--replicate-ignore-db=db_name
Command-Line Format
--replicate-ignore-db=name
Permitted Values
Type
string
As with --replicate-do-db, the effects of this option depend on whether

statement-based or row-based replication is in use.
Statement-based replication. Tells the slave SQL thread not to replicate

any statement where the default database (that is, the one selected by USE)
is db_name.
Row-based replication. Tells the slave SQL thread not to update any
tables in the database db_name. The default database has no effect.
When using statement-based replication, the following example does not

work as you might expect. Suppose that the slave is started with -replicate-ignore-db=sales and you issue the following statements on
the master:
USE prices;
UPDATE sales.january SET amount=amount+1000;
The UPDATE statement is replicated in such a case because -replicate-ignore-db applies only to the default database (determined
by the USE statement). Because the sales database was specified

explicitly in the statement, the statement has not been filtered. However,
when using row-based replication, the UPDATEstatement's effects
are not propagated to the slave, and the slave's copy of
the sales.january table is unchanged; in this instance, --replicateignore-db=sales causes all changes made to tables in the master's copy
of the sales database to be ignored by the slave.
To specify more than one database to ignore, use this option multiple
times, once for each database. Because database names can contain
commas, if you supply a comma separated list then the list will be treated
as the name of a single database.
You should not use this option if you are using cross-database updates and
you do not want these updates to be replicated. See Section 17.2.3, How
Servers Evaluate Replication Filtering Rules.
If you need cross-database updates to work, use --replicate-wildignore-table=db_name.% instead. SeeSection 17.2.3, How Servers
Evaluate Replication Filtering Rules.
Note
This option affects replication in the same manner that --binlogignore-db affects binary logging, and the effects of the replication format
on how --replicate-ignore-db affects replication behavior are the

same as those of the logging format on the behavior of --binlogignore-db.
This option has no effect on BEGIN, COMMIT, or ROLLBACK statements.
--replicate-do-table=db_name.tbl_name
Command-Line Format
--replicate-do-table=name
Permitted Values
Type
string
Tells the slave SQL thread to restrict replication to the specified table. To
specify more than one table, use this option multiple times, once for each
table. This works for both cross-database updates and default database
updates, in contrast to --replicate-do-db. See Section 17.2.3, How
Servers Evaluate Replication Filtering Rules.
This option affects only statements that apply to tables. It does not affect
statements that apply only to other database objects, such as stored
routines. To filter statements operating on stored routines, use one or more
of the --replicate-*-db options.
--replicate-ignore-table=db_name.tbl_name
Command-Line Format
--replicate-ignore-table=name
Permitted Values
Type
string
Tells the slave SQL thread not to replicate any statement that updates the
specified table, even if any other tables might be updated by the same
statement. To specify more than one table to ignore, use this option
multiple times, once for each table. This works for cross-database updates,
in contrast to --replicate-ignore-db. SeeSection 17.2.3, How Servers
This option affects only statements that apply to tables. It does not affect
statements that apply only to other database objects, such as stored
routines. To filter statements operating on stored routines, use one or more
of the --replicate-*-db options.
--replicate-rewrite-db=from_name->to_name
Command-Line Format
--replicate-rewrite-db=old_name->new_name
Permitted Values
Type
string
Tells the slave to translate the default database (that is, the one selected
by USE) to to_name if it was from_nameon the master. Only statements
involving tables are affected (not statements such as CREATE
DATABASE, DROP DATABASE, and ALTER DATABASE), and only
if from_name is the default database on the master. To specify multiple

rewrites, use this option multiple times. The server uses the first one with
a from_name value that matches. The database name translation is
done before the --replicate-* rules are tested.
Statements in which table names are qualified with database names when
using this option do not work with table-level replication filtering options
such as --replicate-do-table. Suppose we have a database
named aon the master, one named b on the slave, each containing a
table t, and have started the master with --replicate-rewrite-db='a>b'. At a later point in time, we execute DELETE FROM a.t. In this case,
no relevant filtering rule works, for the reasons shown here:

o
--replicate-do-table=a.t does not work because the slave has
table t in database b.
o
--replicate-do-table=b.t does not match the original statement and
so is ignored.
o
--replicate-do-table=*.t is handled identically to --replicatedo-table=a.t, and thus does not work, either.
Similarly, the --replication-rewrite-db option does not work with cross-database

updates.
If you use this option on the command line and the > character is special to your
command interpreter, quote the option value. For example:
shell> mysqld --replicate-rewrite-db="olddb->newdb"
b.
--replicate-same-server-id
Command-Line Format
Permitted Values
--replicate-same-server-id
Type
boolean
Default
FALSE
c. To be used on slave servers. Usually you should use the default setting of
0, to prevent infinite loops caused by circular replication. If set to 1, the
slave does not skip events having its own server ID. Normally, this is useful
only in rare configurations. Cannot be set to 1 if --log-slave-updates is
used. By default, the slave I/O thread does not write binary log events to
the relay log if they have the slave's server ID (this optimization helps save
disk usage). If you want to use --replicate-same-server-id, be sure
to start the slave with this option before you make the slave read its own
events that you want the slave SQL thread to execute.
d.
--replicate-wild-do-table=db_name.tbl_name
Command-Line Format
--replicate-wild-do-table=name
Permitted Values
Type
string
e. Tells the slave thread to restrict replication to statements where any of the
updated tables match the specified database and table name patterns.
Patterns can contain the % and _ wildcard characters, which have the
same meaning as for the LIKE pattern-matching operator. To specify more
than one table, use this option multiple times, once for each table. This
works for cross-database updates. See Section 17.2.3, How Servers
f.
This option applies to tables, views, and triggers. It does not apply to stored
procedures and functions, or events. To filter statements operating on the
latter objects, use one or more of the --replicate-*-db options.
g. Example: --replicate-wild-do-table=foo%.bar% replicates only

updates that use a table where the database name starts with foo and the
table name starts with bar.
h. If the table name pattern is %, it matches any table name and the option
also applies to database-level statements (CREATE DATABASE, DROP
DATABASE, and ALTER DATABASE). For example, if you use -replicate-wild-do-table=foo%.%, database-level statements are
replicated if the database name matches the pattern foo%.
i.
To include literal wildcard characters in the database or table name

patterns, escape them with a backslash. For example, to replicate all tables
of a database that is named my_own%db, but not replicate tables from
themy1ownAABCdb database, you should escape
the _ and % characters like this: --replicate-wild-dotable=my\_own\%db. If you use the option on the command line, you
might need to double the backslashes or quote the option value, depending
on your command interpreter. For example, with the bash shell, you would
need to type --replicate-wild-do-table=my\\_own\\%db.
j.
--replicate-wild-ignore-table=db_name.tbl_name
Command-Line Format
--replicate-wild-ignore-table=name
Permitted Values
Type
string
k. Tells the slave thread not to replicate a statement where any table matches
the given wildcard pattern. To specify more than one table to ignore, use
this option multiple times, once for each table. This works for crossdatabase updates. See Section 17.2.3, How Servers Evaluate Replication
Filtering Rules.
l.
Example: --replicate-wild-ignore-table=foo%.bar% does not

replicate updates that use a table where the database name starts
with foo and the table name starts with bar.
m. For information about how matching works, see the description of the -replicate-wild-do-table option. The rules for including literal wildcard
characters in the option value are the same as for --replicate-wildignore-table as well.
n.
--report-host=host_name
Command-Line Format
--report-host=host_name
System Variable
Name
report_host
Variable Scope
Global
Dynamic Variable
No
Permitted Values
Type
string
o. The host name or IP address of the slave to be reported to the master

during slave registration. This value appears in the output of SHOW SLAVE
HOSTS on the master server. Leave the value unset if you do not want the
slave to register itself with the master. Note that it is not sufficient for the
master to simply read the IP address of the slave from the TCP/IP socket
after the slave connects. Due to NAT and other routing issues, that IP may
not be valid for connecting to the slave from the master or other hosts.
p.
--report-password=password
Command-Line Format
--report-password=name
Name
report_password
Variable Scope
Global
System Variable
Dynamic Variable
No
Permitted Values
Type
string
q. The account password of the slave to be reported to the master during

slave registration. This value appears in the output of SHOW SLAVE
HOSTS on the master server if the --show-slave-auth-info option is
given.
r.
Although the name of this option might imply otherwise, --reportpassword is not connected to the MySQL user privilege system and so is
not necessarily (or even likely to be) the same as the password for the
MySQL replication user account.
s.
--report-port=slave_port_num
Command-Line Format
--report-port=#
System Variable
Name
report_port
Variable Scope
Global
Permitted Values (<= 5.5.22)
Permitted Values (>= 5.5.23)
t.
Dynamic Variable
No
Type
integer
Default
3306
Min Value
Max Value
65535
Type
integer
Default
Min Value
Max Value
65535
The TCP/IP port number for connecting to the slave, to be reported to the
master during slave registration. Set this only if the slave is listening on a
nondefault port or if you have a special tunnel from the master or other
clients to the slave. If you are not sure, do not use this option.
u. Prior to MySQL 5.5.23, the default value for this option was 3306. In
MySQL 5.5.23 and later, the value shown is the port number actually used
by the slave (Bug #13333431). This change also affects the default value
displayed by SHOW SLAVE HOSTS.
v.
--report-user=user_name
Command-Line Format
--report-user=name
Name
report_user
Variable Scope
Global
System Variable
Dynamic Variable
No
Permitted Values
Type
string
w. The account user name of the slave to be reported to the master during
slave registration. This value appears in the output of SHOW SLAVE
HOSTS on the master server if the --show-slave-auth-info option is
given.
x. Although the name of this option might imply otherwise, --report-user is
not connected to the MySQL user privilege system and so is not
necessarily (or even likely to be) the same as the name of the MySQL
replication user account.
y.
--show-slave-auth-info
Command-Line Format
--show-slave-auth-info
Permitted Values
Type
boolean
Default
FALSE
z. Display slave user names and passwords in the output of SHOW SLAVE
HOSTS on the master server for slaves started with the --reportuser and --report-password options.
aa. --skip-slave-start
Command-Line Format
--skip-slave-start
Permitted Values
Type
boolean
Default
FALSE
ab. Tells the slave server not to start the slave threads when the server starts.
To start the threads later, use a START SLAVE statement.
ac. --slave_compressed_protocol={0|1}
Command-Line Format
--slave_compressed_protocol
System Variable
Name
slave_compressed_protocol
Variable Scope
Global
Permitted Values
Dynamic Variable
Yes
Type
boolean
Default
OFF
ad. If this option is set to 1, use compression for the slave/master protocol if
both the slave and the master support it. The default is 0 (no compression).
ae. --slave-load-tmpdir=dir_name
Command-Line Format
System Variable
Permitted Values
--slave-load-tmpdir=dir_name
Name
slave_load_tmpdir
Variable Scope
Global
Dynamic Variable
No
Type
directory name
Default
/tmp
af. The name of the directory where the slave creates temporary files. This
option is by default equal to the value of the tmpdir system variable. When
the slave SQL thread replicates a LOAD DATA INFILE statement, it
extracts the file to be loaded from the relay log into temporary files, and
then loads these into the table. If the file loaded on the master is huge, the
temporary files on the slave are huge, too. Therefore, it might be advisable
to use this option to tell the slave to put temporary files in a directory
located in some file system that has a lot of available space. In that case,
the relay logs are huge as well, so you might also want to use the -relay-log option to place the relay logs in that file system.
ag. The directory specified by this option should be located in a disk-based file
system (not a memory-based file system) because the temporary files used
to replicate LOAD DATA INFILE must survive machine restarts. The
directory also should not be one that is cleared by the operating system
during the system startup process.
ah. --slave-net-timeout=seconds
Command-Line Format
System Variable
Permitted Values
--slave-net-timeout=#
Name
slave_net_timeout
Variable Scope
Global
Dynamic Variable
Yes
Type
integer
Default
3600
Min Value
ai. The number of seconds to wait for more data from the master before the
slave considers the connection broken, aborts the read, and tries to
reconnect. The first retry occurs immediately after the timeout. The interval
between retries is controlled by the MASTER_CONNECT_RETRY option for
the CHANGE MASTER TO statement, and the number of reconnection
attempts is limited by the --master-retry-count option. The default is
3600 seconds (one hour).
aj. --slave-skip-errors=[err_code1,err_code2,...|all]
(MySQL Cluster NDB 7.2.6 and later:) --slave-skiperrors=[err_code1,err_code2,...|all|ddl_exist_errors]
Command-Line Format
--slave-skip-errors=name
Name
slave_skip_errors
Variable Scope
Global
System Variable
Dynamic Variable
No
Permitted Values
Type
string
Default
OFF
Valid Values
OFF
[list of error codes]
all
Type
string
Default
OFF
OFF
all
Permitted Values
Valid Values
ddl_exist_errors
Type
string
Default
OFF
OFF
all
Permitted Values (>= 5.5.22-ndb-7.2.6)
Valid Values
ddl_exist_errors
Normally, replication stops when an error occurs on the slave. This gives you the
opportunity to resolve the inconsistency in the data manually. This option tells the slave
SQL thread to continue replication when a statement returns any of the errors listed in
the option value.
Do not use this option unless you fully understand why you are getting errors. If there
are no bugs in your replication setup and client programs, and no bugs in MySQL itself,
an error that stops replication should never occur. Indiscriminate use of this option
results in slaves becoming hopelessly out of synchrony with the master, with you having
no idea why this has occurred.
For error codes, you should use the numbers provided by the error message in your
slave error log and in the output of SHOW SLAVE STATUS. Appendix B, Errors, Error
Codes, and Common Problems, lists server error codes.
You can also (but should not) use the very nonrecommended value of all to cause the
slave to ignore all error messages and keeps going regardless of what happens.
Needless to say, if you use all, there are no guarantees regarding the integrity of your
data. Please do not complain (or file bug reports) in this case if the slave's data is not
anywhere close to what it is on the master. You have been warned.
MySQL Cluster NDB 7.2.6 and later support an additional shorthand
value ddl_exist_errors for use with the enhanced failover mechanism which is
implemented beginning with that version of MySQL Cluster. This value is equivalent to
the error code list 1007,1008,1050,1051,1054,1060,1061,1068,1094,1146. This
value is not supported by the mysqld binary included with the MySQL Server 5.5
distribution. (Bug #11762277, Bug #54854) For more information, see Section 18.6.8,
Implementing Failover with MySQL Cluster Replication.
Examples:
--slave-skip-errors=1062,1053
--slave-skip-errors=all
--slave-skip-errors=ddl_exist_errors
Obsolete Replication Slave Options
The following options are removed in MySQL 5.5. If you attempt to start mysqld with any of
these options in MySQL 5.5, the server aborts with an unknown variable error. To set
the replication parameters formerly associated with these options, you must use
the CHANGE MASTER TO ... statement (see Section 13.4.2.1, CHANGE MASTER TO
Syntax).
The options affected are shown in this list:
--master-host
--master-user
--master-password
--master-port
--master-connect-retry
--master-ssl
--master-ssl-ca
--master-ssl-capath
--master-ssl-cert
--master-ssl-cipher
--master-ssl-key
System Variables Used on Replication Slaves

The following list describes system variables for controlling replication slave servers. They
can be set at server startup and some of them can be changed at runtime using SET.
Server options used with replication slaves are listed earlier in this section.
init_slave
Command-Line Format
--init-slave=name
Name
init_slave
Variable Scope
Global
System Variable
Dynamic Variable
Yes
Permitted Values
Type
string
This variable is similar to init_connect, but is a string to be executed by a slave

server each time the SQL thread starts. The format of the string is the same as for
the init_connect variable.
Note
The SQL thread sends an acknowledgment to the client before it

executes init_slave. Therefore, it is not guaranteed that init_slave has been
executed when START SLAVE returns. See Section 13.4.2.5, START SLAVE
Syntax, for more information.
relay_log
Command-Line Format
System Variable
Name
relay_log
Variable Scope
Global
Permitted Values
The name of the relay log file.
relay_log_index
Command-Line Format
System Variable
Permitted Values
Dynamic Variable
No
Type
file name
--relay-log-index
Name
relay_log_index
Variable Scope
Global
Dynamic Variable
No
Type
file name
Default
*host_name*-relay-bin.index
The name of the relay log index file. The default name is host_name-relaybin.index in the data directory, where host_name is the name of the slave
server.
relay_log_info_file
Command-Line Format
System Variable
Permitted Values
Name
relay_log_info_file
Variable Scope
Global
Dynamic Variable
No
Type
file name
Default
relay-log.info
The name of the file in which the slave records information about the relay logs.
The default name is relay-log.info in the data directory.
relay_log_recovery
Command-Line Format
System Variable
Permitted Values
--relay-log-recovery
Name
relay_log_recovery
Variable Scope
Global
Dynamic Variable
Yes
Type
boolean
Default
FALSE
Enables automatic relay log recovery immediately following server startup, which
means that the replication slave discards all unprocessed relay logs and retrieves
them from the replication master. This should be used following a crash on the
replication slave to ensure that no possibly corrupted relay logs are processed. The
default value is 0 (disabled). This global variable can be changed dynamically, or
by starting the slave with the --relay-log-recovery option.
rpl_recovery_rank
This variable is unused, and is removed in MySQL 5.6.
Command-Line Format
System Variable
Permitted Values
--slave_compressed_protocol
Name
Variable Scope
Global
Dynamic Variable
Yes
Type
boolean
Default
OFF
Whether to use compression of the slave/master protocol if both the slave and the
master support it.
slave_exec_mode
Command-Line Format
System Variable
--slave-exec-mode=mode
Name
slave_exec_mode
Variable Scope
Global
Dynamic Variable
Yes
Type
enumeration
Default
STRICT (ALL)
Default
IDEMPOTENT (NDB)
IDEMPOTENT
Permitted Values
Valid Values
STRICT
Controls whether IDEMPOTENT or STRICT mode is used in replication conflict

resolution and error checking.IDEMPOTENT mode causes suppression of duplicatekey and no-key-found errors.
This mode is needed for multi-master replication, circular replication, and some
other special replication scenarios for MySQL Cluster Replication.
(See Section 18.6.10, MySQL Cluster Replication: Multi-Master and Circular
Replication, and Section 18.6.11, MySQL Cluster Replication Conflict
Resolution, for more information.) Themysqld supplied with MySQL Cluster
ignores any value explicitly set for slave_exec_mode, and always treats it
as IDEMPOTENT.
In MySQL Server 5.5, STRICT mode is the default value. This should not be
changed; currently, IDEMPOTENTmode is supported only by NDB.
slave_load_tmpdir
Command-Line Format
--slave-load-tmpdir=dir_name
System Variable
Name
slave_load_tmpdir
Variable Scope
Global
Permitted Values
Dynamic Variable
No
Type
directory name
Default
/tmp
The name of the directory where the slave creates temporary files for
replicating LOAD DATA INFILE statements.
slave_max_allowed_packet
Introduced
System Variable
Permitted Values
5.5.26
Name
slave_max_allowed_packet
Variable Scope
Global
Dynamic Variable
Yes
Type
integer
Default
1073741824
Min Value
1024
Max Value
1073741824
In MySQL 5.5.26 and later, this variable sets the maximum packet size for the slave
SQL and I/O threads, so that large updates using row-based replication do not
cause replication to fail because an update exceededmax_allowed_packet.
This global variable always has a value that is a positive integer multiple of 1024; if
you set it to some value that is not, the value is rounded down to the next highest
multiple of 1024 for it is stored or used; settingslave_max_allowed_packet to 0
causes 1024 to be used. (A truncation warning is issued in all such cases.) The
default and maximum value is 1073741824 (1 GB); the minimum is 1024.
slave_max_allowed_packet can also be set at startup, using the --slavemax-allowed-packet option.
slave_net_timeout
Command-Line Format
System Variable
Permitted Values
--slave-net-timeout=#
Name
slave_net_timeout
Variable Scope
Global
Dynamic Variable
Yes
Type
integer
Default
3600
Min Value
The number of seconds to wait for more data from a master/slave connection
before aborting the read.
slave_skip_errors
Command-Line Format
System Variable
--slave-skip-errors=name
Name
slave_skip_errors
Variable Scope
Global
Dynamic Variable
No
Type
string
Default
OFF
OFF
Permitted Values
Valid Values
all
Type
string
Default
OFF
OFF
all
Permitted Values
Valid Values
ddl_exist_errors
Type
string
Default
OFF
OFF
all
Permitted Values (>= 5.5.22-ndb-7.2.6)
Valid Values
ddl_exist_errors
Normally, replication stops when an error occurs on the slave. This gives you the
opportunity to resolve the inconsistency in the data manually. This variable tells the
slave SQL thread to continue replication when a statement returns any of the errors
listed in the variable value.
slave_transaction_retries
Command-Line Format
--slave_transaction_retries=#
Name
slave_transaction_retries
Variable Scope
Global
Dynamic
System Variable
Variable
Yes
Type
integer
Default
10
Min Value
Max Value
4294967295
Type
integer
Default
10
Min Value
5.5.2)
Max Value
18446744073709547520
Permitted Values (64-bit platforms, >=
Type
integer
Default
10
Permitted Values (64-bit platforms, <=
5.5.3)
Min Value
Max Value
18446744073709551615
If a replication slave SQL thread fails to execute a transaction because of

an InnoDB deadlock or because the transaction's execution time
exceeded InnoDB's innodb_lock_wait_timeout or NDBCLUSTER'sTransactio
nDeadlockDetectionTimeout or TransactionInactiveTimeout, it
automatically retriesslave_transaction_retries times before stopping with an

error. The default value is 10.
slave_type_conversions
Introduced
5.5.3
Command-Line Format
--slave_type_conversions=set
System Variable
Name
slave_type_conversions
Variable Scope
Global
Dynamic Variable
No
Type
set
Default
ALL_LOSSY
Permitted Values
Valid Values
ALL_NON_LOSSY
Controls the type conversion mode in effect on the slave when using row-based
replication, including MySQL Cluster Replication. Its value is a comma-delimited
set of zero or more elements from the list: ALL_LOSSY,ALL_NON_LOSSY. Set this
variable to an empty string to disallow type conversions between the master and
the slave. Changes require a restart of the slave to take effect.
For additional information on type conversion modes applicable to attribute

promotion and demotion in row-based replication, see Row-based replication:
attribute promotion and demotion.
This variable was added in MySQL 5.5.3.
sql_slave_skip_counter
Name
sql_slave_skip_counter
Variable Scope
Global
System Variable
Dynamic Variable
Yes
Permitted Values
Type
integer
The number of events from the master that a slave server should skip.
Important
If skipping the number of events specified by setting this variable would cause the
slave to begin in the middle of an event group, the slave continues to skip until it
finds the beginning of the next event group and begins from that point. For more
information, see Section 13.4.2.4, SET GLOBAL sql_slave_skip_counter Syntax.
sync_master_info
Command-Line Format
System Variable
--sync-master-info=#
Name
sync_master_info
Variable Scope
Global

Type
integer
Default
Min Value
Max Value
4294967295
Permitted Values (64-bit platforms, <= 5.5.2) Type
integer
Default
Min Value
Max Value
18446744073709547520
Type
integer
Default
Min Value
18446744073709551615
If the value of this variable is greater than 0, a replication slave synchronizes

its master.info file to disk (usingfdatasync()) after
every sync_master_info events. The default value is 0 (recommended in most
situations), which does not force any synchronization to disk by the MySQL server;
in this case, the server relies on the operating system to flush
the master.info file's contents from time to time as for any other file.
sync_relay_log
Command-Line Format
System Variable
--sync-relay-log=#
Name
sync_relay_log
Variable Scope
Global

Type
integer
Default
Min Value
Max Value
4294967295
Type
integer
Default
Min Value
Permitted Values (64-bit platforms, <= 5.5.2) Max Value
18446744073709547520
Permitted Values (64-bit platforms, >= 5.5.3) Type
integer
Default
Min Value
Max Value
18446744073709551615
If the value of this variable is greater than 0, the MySQL server synchronizes its
relay log to disk (usingfdatasync()) after every sync_relay_log events are
written to the relay log.
The default value of sync_relay_log is 0, which does no synchronizing to disk; in

this case, the server relies on the operating system to flush the relay log's contents
from time to time as for any other file.
A value of 1 is the safest choice because in the event of a crash you lose at most
one event from the relay log. However, it is also the slowest choice (unless the disk
has a battery-backed cache, which makes synchronization very fast).
sync_relay_log_info
Command-Line Format
System Variable
--sync-relay-log-info=#
Name
sync_relay_log_info
Variable Scope
Global

Type
integer
Default
Min Value
Max Value
4294967295
Type
integer
Default
Min Value
Permitted Values (64-bit platforms, <= 5.5.2) Max Value
18446744073709547520
Type
integer
Default
Min Value
18446744073709551615
If the value of this variable is greater than 0, a replication slave synchronizes

its relay-log.info file to disk (using fdatasync()) after
every sync_relay_log_info transactions. A value of 1 is the generally the best
choice. The default value of sync_relay_log_info is 0, which does not force any
synchronization to disk by the MySQL serverin this case, the server relies on the
operating system to flush the relay-log.info file's contents from time to time as
for any other file.
Previous / Next / Up / Table of Contents
User Comments
Posted by Charles Darwin on February 17 2012 3:50pm
[Delete] [Edit]
I had a problem when I just changed the server name. I got the known error:
[ERROR] Failed to open the relay log './zeus-relay-bin.000009' (relay_log_pos 251)
120216 17:11:31 [ERROR] Could not find target log during relay log initialization
When I changed the name from zeus to perseo.
My solution was to delete the files with old server name, I mean zeus-relay-* and delete relaylog.info.
It just worked for me.
Posted by andrew lorien on April 28 2014 1:04am
[Delete] [Edit]
MySQL Enterprise Monitor (supported by a few tech blogs) has an "Slave Detection Of Network
Outages Too High" advisor, which suggests that you "decrease slave_net_timeout so the
outages -- and associated connection retries -- are detected and resolved faster. The default for
this parameter is 3600 seconds (1 hour), which is too high for many environments."
However, in our reasonably high traffic environment (each master has three slaves on a very
low-latency network, a 1G compressed binlog takes about a week to rotate), setting this value to
30 seconds caused recurring replication problems. The slaves started and stopped replicating
with the message "Waiting to reconnect after a failed master event read." stop slave - start slave
did not fix them (in fact we believe it made the problem worse). Removing the slave_net_timeout
value from mysql.ini fixed replication immediately.
Add your ow n comment

Replicacion MySql

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Replicacion MySql

Uploaded by

Copyright:

Available Formats

13.4.2.

7 START SLAVE Syntax

[thread_type [, thread_type] ... ]

Be sure to add skip-slave-start to your my.cnf

A gotcha if you're using transactions.

MySQL slave I/O thread not running

shareimprove this question

edited Jun 24 '13 at

Instead of giving a 'replication slave' privilege to ., I was only giving it for

has no effect as you can't grant it per-database/column/table.

The command you need to run is:

edited Nov 28 '09 at

I have encountered the same problem and I try this steps

4.CHANGE MASTER TO MASTER_LOG_POS=98;

shareimprove this answer

@Luxknight007 Step 2 is very dangerous and is not required at all.

edited Jun 19 '14 at

Backup stopped working !! Slave_SQL_Running: No

see that "Slave_SQL_Running" is "NO" !!

Any suggestions to rectify this would be of great help.

Thank you everyone for your assistance.

Later i changed to this :-

Yeah you stuck it to yourself on this one.

, but none the less the above

All thanks to your guidance ...

Glad you got it going again anyway!

Thank you so much for the head'sup Scott..

REPLICAR BASES DE DATOS

Servidor M (Servidor principal, sera el maestro)

Servidor E (Servidor secundario, sera el servidor esclavo).

Podemos replicar Bases de Datos en el mismo servidor (Diferentes servicios MySql),

Se puede configurar (etc/my.cnf), la replicacin parcial o total de las tablas de la Base

La replicacin es UNIDIRECCIONAL, los datos se copian de una base de datos a otra

De las tablas de la Base de Datos que no se replican, entre el Servidor Maestro y el

Mysql> GRANT REPLICATION SLAVE ON *.* TO usuario_esclavo@host_esclavo

La actualizacin de la informacin de la Base de datos Mysql Master (total o parcial de sus

[Fichero bin actual ]

BinLog_Do_DB = empresa [Base de datos que trata nicamente]

BinLog_Ignore_Db = [BD ignoradas, si BinLog_Do_Db <> el resto]

[ltima posicin insertada]

Estando dentro del servidor Maestro (M) :

Command: Binlog Dump

2.- Utilidades del Servidor Esclavo

Slave_IO_State: Waiting for master to send event

Master_Host: 192.168.5.130 [Ip master]

Master_User: replica [Usuario master para conectarse]

Master_Port: 3306 [Puerto mysql]

Connect_Retry: 60 [60 Timeout para conectar los 2 servers]

Master_Log_File: mysql-bin.000122 [ltimo Fichero master]

Read_Master_Log_Pos: 269 [ltima posicin en el fichero master]

Relay_Log_File: server-relay-bin.000011 [ltimo log en el esclavo]

Relay_Log_Pos: 406 [ltima posicin en el log del esclavo]

Relay_Master_Log_File: mysql-bin.000122 [ltimo fichero master]

[Muy importante, debe ser yes]

[Muy importante, debe ser yes]

Replicate_Do_DB: empresa [B.D se replica nicamente]

Si los campos Slave_IO_Running : No y Slave_SQL_Running : No.

User: system user

Time: 2752 (tiempo desde la ltima lectura del master, en segundos)

State: Waiting for master to send event

*************************** 2. row ***************************

User: system user

RESETEAR o PURGAR LOS LOGS EN EN SERVIDOR MAESTRO

Mysql> GRANT REPLICATION SLAVE ON . TO usuario_esclavo@host_esclavo

* 2. row *