Our Master MySQL server disk filled and caused the server to crash, after resolving that the replication to the Slave was failing so we started the replication again.
After running 'FLUSH TABLES WITH READ LOCK;' and 'SHOW MASTER STATUS;' we noted the bin file and position.
On the Slave we set the correct bin file and position but MySQL errors with 'binlog truncated in the middle of event; consider out of disk space on master
The bin file we are using is the last one created on the Master and no news ones appear to be being created.
Can anyone advise how I can resolve this and have new bin files created.
Thanks
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 am trying to replicate a cloudsql MYSQL database to a GCE VM and I am following this guide.
https://cloud.google.com/sql/docs/mysql/replication/configure-external-replica
The error that I face is that is once I restore the dump and start my slave, the slave tries to execute the DDL commands that have already been dumped. In other words, the GTID based replication starts from 0.
What I expect is that it starts from the point where the dump has been taken.
What I am doing wrong here ?
I can see that I am getting the latest GTID set from the master. (left side is slave and right side is master).
So I have found out the issue.
The issue was that my dump file did not contain information about GTID from the source server. Because of this the destination has no idea about what GTID has been executed at the source.
So I must set gtid_purged to off when creating a mysql dump.
This will set the gtid_executed at the destination when restoring and ensure that there is not reexecution
I did a backup of the data folder from mysql server to keep all databases information.
C:\ProgramData\MySQL\MySQL Server 5.7\Data
I uninstalled MySQL server in Control Panel. I copied the data folder and pasted it back where it should be.
I am then trying to reinstall the service using MySQL installer. However, it is stuck on Starting Server... forever and sometimes will pop a message saying it is taking too long than expected. I tried this solution but it does not work for me.
When I remove the ibdata1, Mysql server installs, starts and runs. However, whenever I try to run a query on a table I get database_name.table does not exist.
Clearly to me the problem is ibdata1... So what should I do, if I really need to restore all the databases?
Do you still keep ibdata1 ? Reclean and copy back your ibdata1 and your data
For starting mysql, you should config Innodb force recovery (increase this value from 1 to 6). This will give you detail information https://dev.mysql.com/doc/refman/5.7/en/forcing-innodb-recovery.html
Remember, in recovery mode you can read data only and cannot update, insert or delete
Update:
Find your my.ini (on linux my.cnf) add this line to your [mysql]
innodb_force_recovery = 1
Try to increase it from 1 -> 6 until you can start your mysql server. Then you can perform dump to backup your server remember you cannot update/insert/delete in recovery mode
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'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.