I've got a replication set up on pair of servers. One is a master and second is a slave.
Recently on master the binlog files were purged too early (by filename so mysql haven't prevented too early removal of file).
Now the SLAVE has status:
Got fatal error 1236 from master when reading data from binary log: 'Could not find first log file name in binary log index file'
I wan't to restore the missing binlog files so the slave will restart reading from the point it finished.
The files are already in place but how can I force master to 'unpurge' it's log list (so they are visible in SHOW BINARY LOGS)?
Ok I made it. However this solution isn't perfect/100% safe.
I've entered all filenames to my mysql-bin.index
find /var/log/mysql/ -wholename '/var/log/mysql/mysql-bin.0*' | sort > mysql-bin.index
(if you will use it check the filename format in mysql-bin.index file first and adjust to your needs)
Then restart mysql and mysql reloads that file on start.
the MASTER is ready.
Now it's enough to do
SLAVE STOP;
and
SLAVE START;
on SLAVE and it will continue his job.
Related
I am trying to set up a replication slave.
I was hoping if I set the binlog position to 0 on the slave it would just start reading from 0 and replicate everything from scratch until it matched the master, but the slave's not doing anything, and not giving errors either.
So I first need a current database snapshot. Can I do this without dumping the database into a file if both servers can talk to each other on the local network? I tried this command but it just spits out the usage help:
slave ~$ sudo mysqlimport --host='[master-server-ip]' --user='repl' -pC
To reiterate, I want to transfer all databases (except the mysql built in databases) over the network without having to manually transfer files.
You can use 0 as binlog position but you also have to specify the log file.
You can see the name of the first binlog file in your MySQL data directory (usually /var/lib/mysql on unix).
Then try something like this on the slave server:
STOP SLAVE;
CHANGE MASTER TO
MASTER_HOST='...',
MASTER_PORT=3306,
MASTER_USER='...',
MASTER_PASSWORD='...',
MASTER_LOG_FILE='<your first binlog file>',
MASTER_LOG_POS=0;
START SLAVE;
Of course that will work if all binlogs are still present on the master server since it has been created which might be not your case since binlogs are automatically cleaned after some time.
I´ve seen this question in another post, but I have one diference:
I´m triyng to follow the instructions in https://www.telepieza.com/wordpress/2008/03/13/replicar-bases-de-datos-mysql-en-servidores-locales-o-remotos/
But my in my server originally the line: #log-bin=mysql-bin is commented (#)
If I let the line without the # and restarts the MySql the service doesn´t start and shows the error:
ERROR! MySQL server PID file could not be found!
Starting MySQL.. ERROR! The server quit without updating PID file (/var/lib/mysql/xxxxxx.pid).
Thanks for your help
-----------------
Added for the coments:
2017 Log
In your error log, I see the error that it can't find the binary log file it expects to find. So some or all of your binary log files expired or got deleted or something. But there's still some reference to mysql-bin.000019 in mysql-bin.index.
I checked your screenshot you had posted previously and I see your mysql-bin.index is dated 2017-05-18. So it's three months out of date anyway. I would guess someone deleted the old binary logs to save space, but didn't think to delete the binlog index file.
If you want to start over with a clean slate of binary log files, just remove all your mysql-bin.* files (including mysql-bin.index), and then start mysqld. The startup will automatically create new binary logs, starting with mysql-bin.000001.
Note that if you have any replication slaves depending on this instance as their master, you'll have to reinitialize them with a new backup and the new binlog filename.
I have a Master - Slave setup with MySql v5.1.39 running ~10 db's on 12 core Linux machine. I had to move the bin-log files to a separate disk for performance issues. So I followed these steps:
Stop everything that's using the db
Stop Slave
Stop master
Change paths in /my.cfg to /mysql/log/* to /mysql/newlog/* on master and slave
Copy /mysql/log/* to /mysql/newlog/. on master and slave
Start Slave
All Ok!
Start Master
First problem! on the slave:
150113 12:21:22 [ERROR] Got fatal error 1236: 'Could not find first log file name in binary log index file' from master when reading data from binary log
150113 12:21:22 [Note] Slave I/O thread exiting, read up to log 'bin-log.005523', position 716864371
Now a quick Google didn't resolve anything and since downtime is an issue. I stopped the Master, changed the configuration back and restarted. Now the second "problem"!
...
150113 13:02:22 InnoDB: Error: page 182380 log sequence number 3407 300161079
InnoDB: is in the future! Current system log sequence number 3407 299353326.
InnoDB: Your database may be corrupt or you may have copied the InnoDB
InnoDB: tablespace but not the InnoDB log files. See
InnoDB: http://dev.mysql.com/doc/refman/5.1/en/forcing-recovery.html
InnoDB: for more information.
...
I quote problem because everything works fine. Replication to the slave restarted and worked. I started the applications and those work fine. But when start MySql on the Master, I get the errors above, about 50 of them with different page- and sequence numbers.
How does moving files affect page- and sequence numbers and where do they come from? How big is my problem? everything seems to work fine.
Please ask if you need anymore information and thanks for your help.
First problem was caused by the file /mysql/log/bin-log.index. I forgot to change the contents of this file to point to the new directory of the log files:
/mysql/log/bin-log.000028 -> /mysql/newlog/bin-log.000028
/mysql/log/bin-log.000029 -> /mysql/newlog/bin-log.000029
/mysql/log/bin-log.000030 -> /mysql/newlog/bin-log.000030
/mysql/log/bin-log.000031 -> /mysql/newlog/bin-log.000031
The second problem was caused by the timestamps of some files. I should have preserved the timestamps with cp -p log/* newlog/. or rsync -avrx log/* newlog/..
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 have tried several commands (FLUSH LOGS, PURGE MASTER) but none deletes the log files (when previously activated) or the log tables (mysql/slow_log.CSV and mysql/general_log.CSV and their .frm and .CSM counterparts).
SHOW BINARY LOGS returns "You are not using binary logging".
Edit: I found this simple solution to clear the table logs (but not yet the file logs using a mysql command):
TRUNCATE mysql.general_log;
TRUNCATE mysql.slow_log;
FLUSH LOGS just closes and reopens log files. If the log files are large, it won't reduce them. If you're on Linux, you can use mv to rename log files while they're in use, and then after FLUSH LOGS, you know that MySQL is writing to a new, small file, and you can remove the old big files.
Binary logs are different. To eliminate old binlogs, use PURGE BINARY LOGS. Make sure your slaves (if any) aren't still using the binary logs. That is, run SHOW SLAVE STATUS to see what binlog file they're working on, and don't purge that file or later files.
Also keep in mind that binlogs are useful for point-in-time recovery in case you need to restore from backups and then reapply binlogs to bring the database up to date. If you need to use binlogs in this manner, don't purge the binlogs that have been written since your last backup.
If you are on amazon RDS, executing this twice will do the trick:
PROMPT> CALL mysql.rds_rotate_slow_log;
PROMPT> CALL mysql.rds_rotate_general_log;
Source: http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_LogAccess.Concepts.MySQL.html
It seems binary logging is not enabled in your server .And i guess you want to delete the old log files which were used/created at the time of binary logging is enabled . you can delete them manually using 'rm' command if you want . if you want to enable the binary logging you can do the same by updating the configuaration file ( but it needs restart of the server if it is already running) . You can refer below links.
http://dev.mysql.com/doc/refman/5.0/en/replication-options-binary-log.html#option_mysqld_log-bin
http://dev.mysql.com/doc/refman/5.0/en/replication-options-binary-log.html#sysvar_log_bin