Are you ready to accept the challenge? Really?
Can you prove that you have got what it takes to be an effective DBA?
Go grab the tests from https://github.com/dbadojo/test-mysql-restore and see if you do…
These tests are designed to test your ability to do basic restores and recoveries of a MySQL database.
Each restore gets progressively more complex.
The key feature is, once you are successfully restored the MySQL database you will get the encryption key/passphrase
to do the next test.
Use: ccrypt -d <filename>.cpt to decrypt the file.
Virtualbox and vagrant if using a virtual machine for running the MySQL instance.
ccrypt or equivalent that can read ccrypt encrypted files.
A vagrantfile is provided as an example to spawn a simple virtualbox VM with 1Gig of memory to run the small MySQL database required for the tests.
Once you have proved you are awesome…
Once you have completed all the current tests, email email@example.com and we will keep you informed when the next set becomes ready.
For the uber awesome DBAs, if you have ideas for more tests, email them to firstname.lastname@example.org or comment here or send a merge request.
P.S. There are more and harder restores to come… stay tuned.
Slave I/O thread: error reconnecting to master
Last_IO_Error: error connecting to master
Check that the slave can connect to the master instance, using the following steps:
- Use ping to check the master is reachable. eg ping master.yourdomain.com
- Use ping with ip address to check that DNS isn’t broken. eg. ping 192.168.1.2
- Use mysql client to connect from slave to master. eg mysql -u repluser -pREPLPASS –host=master.yourdomain.com –port=3306 (substitute whatever port you are connecting to the master on)
- If all steps work, then check that the repluser (the SLAVE replication user has the REPLICATION SLAVE privilege). eg. show grants for ‘repl’@’slave.yourdomain.com’;
- If step 1 and 2 fail, you have a network or firewall issue. Check with a network/firewall administrator or check the logs if you wear those hats.
- If Step 1 fails but Step 2 works, you have a DNS or names resolution issue. Check that the slave can connect and resolves names using mysql client or ssh/telnet/remote desktop.
- If Step 3 fails, you need to check the error reported, it will either be a authentication issue (login failed/denied) or an issue with the TCP port the master is listening on. A good way to verify that port is open is to use: telnet master.yourdomain.com 3306 (or the port the master is listening on) if that fails then there is a firewall(s) in the network which are blocking that port.
- If you get to step 4 and everything looks fine and the slave does reconnect fine on retrying. Then you have probably had either temporary, network failure, names resolution failure, firewall failure or any of the prior together.
Continuing Sporadic issues:
Get hold of the network and firewall logs.
If this is not possible, setup a script to periodically ping, connect, mysql connect and log that over
time to prove to your friendly network admin that there is an problem with the network.
How MySQL deals with it:
MySQL will try and reconnect by itself after a network failure or query timeout.
The process is governed by a few variables:
In a nutshell, a MySQL slave will try to reconnect after getting a timeout (slave-net-timeout) after waiting the number of seconds in master-connect-retry but only for the number of times
specified in master-retry-count.
By default, a MySQL slave waits one hour before retry, and will then retry every 60 seconds for 86,400 times. That is every minute for 60 days.
If the one hour slave-net-timeout is too long for your DR/Slave read strategy you will need to adjust it accordingly.
Thanks to leBolide. He discovered that there is a 32 character limit on the password for replication.
P.S. If you liked this post you might be good enough to try these challenges