I am new in Mysql Replication,
My problem is : When i Give SHOW SLAVE STATUS Command on Slave, Master-bin-log files are not updated, i reset it and update the Master-bin-log file with the command CHANGE MASTER TO MASTER , still master-bin-log files are not updated when i check with the SHOW SLAVE STATUS command.
Addition to that, at the appropriate path Master-bin-log files are generated but not updated.
Please help me get out of this problem...
Thanks in advance!!!!
Riddhi
From what you are saying, I assume that you want binary logging on the slave.
I think the problem stems from something that has bitten me many times.
Please add this to /etc/my.cnf on the slave:
[mysqld]
log-slave-updates
Without this, the data is updated from the relay logs but the transaction is not recorded in the slave's binary logs.
Adding this is crucial, especially if you plan to use the slave as a master someday.
Related
I have two mysql servers one is mater(mysqlone) and another is slave(mysql2) have replication
i want to delete log file automatically in master when slave completes the reading of logs from master, without script is there any options and variables in mysql.
Simple answer - No. You`ll have to make/get something if you want it automated.
Are you aware of PURGE BINARY LOGS?
It is not too difficult to automate this using a script.
I am moving a MySQL slave from one set of HDs to another. The configuration of the machine denies me the ability to have both old and new hard drives on it at the same time. So I rsync'ed the data directory to another machine.
Whe the new hard drives came online, I rsyn'ed the data dir back. This worked fine.
However, I cannot start replication. This is the error I get.
120314 4:23:07 [Warning] Neither --relay-log nor --relay-log-index were used; so replication may break when this MySQL server acts as a slave and has his hostname changed!! Please use '--relay-log=mysqld-relay-bin' to avoid this problem.
120314 4:23:07 [ERROR] Failed to open the relay log '/var/lib/mysqllogs/mysqld-relay-bin.000273' (relay_log_pos 677043943)
120314 4:23:07 [ERROR] Could not find target log during relay log initialization
120314 4:23:07 [ERROR] Failed to initialize the master info structure
I found this comment:
https://serverfault.com/questions/61471/moving-a-mysql-slave-to-a-new-host-failed-to-open-the-relay-log
If it is just complaining about the relay logs, in most cases, they
are disposable if the master still has the binary logs around. You can
just run CHANGE MASTER TO on the slave and it will flush the existing
relay logs and start anew. You don't need to make a new fresh copy.
This seems to suggest that I do not need these log files.
The host name is not changing.
My Questions:
Do I need these log files?
If not, what do I need to do to get replication started? Will it remember where it left off?
If I do need these log files, is there anything else I'm forgetting?
I don't think you need the relay bin loge files to get it to work. It might remember where it left off, did you try the command mysql>RESET SLAVE; ? You should get the position from the SLAVE by SHOW SLAVE STATUS; to see if still rememvers, then check to see if the logfile on the master server still exists, because it only keeps it for as long as you set the max file size. But try RESET SLAVE; if you haven't it does magic. You are probably going to have to start the whole process over by dumping the existing server data right after you lock the tables and do "SHOW MASTER STATUS" I wouldn't recommend trying to save this process if you have the option to start replication from scratch.
I've got a small database, around 50mb. It's a master replicating to a remote server. I noticed that the relay-bin files total to over 5GB. Is it safe to delete them?
I think a better answer is relay logs can be 'deleted' but mysql should manage it automatically.
One way to do this is to check for the value of relay_log_purge.
It should be set to 1 if you want mysql to manage them:
set global relay_log_purge=1;
You would probably need to flush the logs:
flush logs;
This does not affect the binary logs.
Maybe try to resync your master and slave.
If possible, cleanup the slave by running a
reset slave
it will purge all relay binary logs.
Then set the replication again with change master to ...
You may have too much lag between your master and slave.
From the MySQL manual:
The SQL thread automatically deletes each relay log file after it has
executed all events in the file and no longer needs it. There is no
explicit mechanism for deleting relay logs because the SQL thread
takes care of doing so. However, FLUSH LOGS rotates relay logs, which
influences when the SQL thread deletes them.
No, do not delete the relay-bin files manually. What you can do is to purge the binary files using MySQL commands. See the MySQL 5.0 Manual for more on the PURGE BINARY LOGS command.
I have a master and slave database running on different nodes. The master DB is subjected to huge no. of inserts/updates. The master DB size is close to 6 GB, while the log files are now occupying a space of more than 120 GB. I am running out of disk space and need to get rid of the log files.
Will deleting the log files in anyway affect the slave DB ? Presently, the slave is just a couple of seconds behind the master.
Is there someplace where I can see what steps I need to follow to delete those files
eg.
1)Shut down the slave
2)Shut down the master
3)Delete the log files
4)Start the Master
5)Start the Slave
Do I need to inform the slave that the log files have been deleted ?? If yes, what is the way to do it ?
Any help would be appreciated.
Thanks
Yes, you can delete the OLD bin_log files. Make sure they're super old.
Also, I would do mysql flush_logs
You should also set your config file to expire your log files after X days.
This MySql documentation has all the information beautifully laid out
http://dev.mysql.com/doc/refman/4.1/en/purge-binary-logs.html
I'm running a master-slave MySQL binary log replication system (phew!) that, for some data, is not in sync (meaning, the master holds more data than the slave). But the slave stops very frequently on the slightest MySQL error, can this be disabled? (perhaps a my.cnf setting for the replicating slave ignore-replicating-errors or some of the sort ;) )
This is what happens, every now and then, when the slave tries to replicate an item that does not exist, the slave just dies. a quick check at SHOW SLAVE STATUS \G; gives
Slave-IO-Running: Yes
Slave-SQL-Running: No
Replicate-Do-DB:
Last-Errno: 1062
Last-Error: Error 'Duplicate entry '15218' for key 1' on query. Default database: 'db'. Query: 'INSERT INTO db.table ( FIELDS ) VALUES ( VALUES )'
which I promptly fix (once I realize that the slave has been stopped) by doing the following:
STOP SLAVE;
RESET SLAVE;
START SLAVE;
... lately this has been getting kind of tiresome, and before I spit out some sort of PHP which does this for me, i was wondering if there's some my.cnf entry which will not kill the slave on the first error.
Cheers,
/mp
stop slave; set global sql_slave_skip_counter=1; start slave;
You can ignore only the current error and continue the replication process.
Yes, with --slave-skip-errors=xxx in my.cnf, where xxx is 'all' or a comma sep list of error codes.
First, do you really want to ignore errors? If you get an error, it is likely that the data is not in sync any more. Perhaps what you want is to drop the slave database and restart the sync process when you get an error.
Second, I think the error you are getting is not when you replicate an item that does not exist (what would that mean anyway?) - it looks like you are replicating an item that already exists in the slave database.
I suspect the problem mainly arises from not starting at a clean data copy. It seems that the master has been copied to the slave; then replication has been turned off (or failed); and then it has started up again, but without giving the slave the chance to catch up with what it missed.
If you ever have a time when the master can be closed for write access long enough to clone the database and import it into the slave, this might get the problems to go away.
Modern mysqldump commands have a couple options to help with setting up consistent replication. Check out --master-data which will put the binary log file and position in the dump and automatically set when loaded into slave. Also --single-transaction will do the dump inside a transaction so that no write lock is needed to do a consistent dump.
If the slave isn't used for any writes other than the replication, the authors of High Performance MySQL recommend adding read_only on the slave server to prevent users from mistakenly changing data on the slave as this is will also create the same errors you experienced.
i think you are doing replication with out sync the database first sync the database and try for replication and servers are generating same unique ids and try to set auto incerment offset