I have a database that uses the InnoDB engine on all his tables, running on a Windows Server 2008 r2 64bit in a VM farm. The policies of my organization promotes that every server has to have a replication that can run in the case of disaster in the primary (a DRP). So, in order to achieve that, I tried to activate the log-bin, (to deploy a slave server), I checked the CPU and Memory usage and everything seemed to be normal, but the log file wasn't created, also the DB started reject lots of connections and the app started to act odd. As soon as I deactivated the log-bin everything went back to normal (immediately).
The next time I try to activate the log;
What can I do to ensure the log-bin is activated, besides uncomment the Log-bin= line?
What parameters from the Data Base can be monitored to see what is wrong or need tuning?
Seems like I have a very busy database, I still don't know exactly why but these settings made the log bin work
log-bin=
binlog-format = ROW
transaction-isolation = READ-UNCOMMITTED
Related
I put the percona toolkit onto my DB hosts so I could try and deal with a problem with mysql going silently out of sync. That is replication seems fine on all nodes. Slave IO running / Slave SQL running and 0 seconds behind master.
I have 4 dbs setup in master/master on the first two, and two slaves, I'm using MariaDB-server-10.0.21 for the MySQL database on each node.
Yet the content of the wiki I run on them seems to go out of sync even with those positive indicators. For instance, you'll create a page, save it, get the thumbs up from the wiki. Then reload the page and the content will be gone! Then you point the wiki config to look at each db one at a time, reload the page. Until you find the db that saved the changes you made.
Then dump that db, stop the slaves on each host one at time and then import that version of the database. It's a real pain!
So I installed the percona toolkit after reading an article on how to solve this problem.
And when I run the pt-table-checksum command I get this error, saying Replication filters are set on these hosts:
[root#db1:~] #pt-table-checksum --replicate=test.checksum --databases=sean --ignore-tables=semaphore localhost
10-17T00:31:11 Replication filters are set on these hosts:
db3
binlog_do_db = jfwiki,jokefire,bacula,mysql
db2
binlog_do_db = jfwiki,jokefire,bacula,mysql
db4
binlog_do_db = jfwiki,jokefire,bacula,mysql
Please read the --check-replication-filters documentation to learn how to solve this problem. at /bin/pt-table-checksum line 9644.
But that EC2 host it claims that it's having trouble contacting equates to my 4th database host. I found out by ssh'ing in as my user to that DNS address. And I have no trouble at all logging into that host on the command line using mysql:
Can someone please explain what does this error mean, and how can I fix the issue? Is there any general advice you can give for mysql replication falling silently out of sync?
Thanks
Some of the pt tools need to create their own database and have it replicated. Your binlog_do_db prevents the extra db from being replicated, hence preventing that tool from working.
While you have the binlog_do removed, see what db it being built. Then add it.
I have remote host (centos6) with mariadb (10.0.17-MariaDB-log - MariaDB Server) as master:
server-id = 1
log-bin=mysql-bin
binlog_do_db = mydatabase
and local (win8.1) with mariadb (10.0.16-MariaDB-log - mariadb.org binary distribution) as a slave:
server-id = 2
As initial procedure I've dumped database on remote host, imported it on local host, then executed SHOW MASTER STATUS, get filename and offset and run:
CHANGE MASTER TO MASTER_HOST='$host', MASTER_USER='$user', MASTER_PORT = $port, MASTER_PASSWORD='$pass', MASTER_LOG_FILE='$fname', MASTER_LOG_POS=$pos
STOP SLAVE
START SLAVE
Replication starts. Everything I do with table on master is reflected to slave.
But if slave goes down, after it is up no changes (made on master) while slave was offline reflected to slave! So it looks like my slave should always be online, but it's a laptop!
However after slave is up realtime replication still works - it doesn't remember all changes from offline, but if I change database on master when slave is online and started all changes are perfectly reflected to slave. Of course I know that replication is statement based, so I get not data diff but instructions. But I thought master remembers what it sent and what did not. So on next operation it just sends all non-delivered changes. Am I wrong?
My replication scenario: master server interacts with clients (mobile devices) and they change the database. From time to time I launch my laptop, start replication, get updated database and do some heavy analysis (it's too hard for my 2-core cheap server).
Maybe there is a better method? Is there a way to get "offline changes" like in ICQ messenger? :)
For now I can see only one solution - full db dump, but it is inconvenient, takes too much time and loads master heavily.
While the Slave is not connected to the Master, the Master is writing to its binlog(s). The Slave has remembered where it left off in reading from those binlogs. When the Slave reconnects, it picks up "where it left off", copies the changes from the Master's binlog(s) to the Slaves relay-log(s) and performs them. This "catchup" process will take a little time, how long depends on a lot of factors.
Do SHOW SLAVE STATUS; on the Slave to verify that it is connected and running ("Yes").
Normally, the version of the Slave should be no older than that of the Master. (I doubt if there is any issue between 10.0.17 vs 16. Nothing in the changelog for 10.0.17 jumps out at me.)
Are you using "parallel replication"? See bug fixed in 10.0.18.
i have two servers (one mysql db server, one client server) with direct ethernet link. The "remote" access used to be lighting fast (neglectable latency for query), no matter using IP addr or DNS.
to fine tune the performance, i modified my.cnf (redhat, /etc/my.cnf) [mysqld] category on the db server (by changing the key and innodb buffer related size). since the test result was not good enough, i changed my.cnf back to its default status.
however since then, it became extremely slow to establish the connection to the db server from remote (local access seems fine). any idea what's the reason behind?
ps:
once connected, remote query seems working as fast as before. it's just slow to establish the connection.
the common DNS issue seems not valid here, given it cannot explain (a) why the connection through DNS was fast; (b) why [mysqld] changes in key/innodb buffer size would affect the DNS, even with my.cnf changed back to its default status; (c) connection establishment became slow through either IP or DSN after the change/change-back of my.cnf
UPDATE:
After hours of struggling, i restarted the db server and now it seems my.cnf functions as expected...
I have a setup in which there is database replication from 1 machine X to another machine Y.
The problem is that MySql replication logs i.e.
master-bin.xyz and slave-relay.xyz
becomes too large and endup taking entire diskspace.
How to disable this logs?
Without binary logs, replication is not possible.
However, you can set a size limit for each log with...
max_binlog_size=50M
You can also set the logs to expire to save drive space with...
expire_logs_days=7
Of course these are settings for my server. You'll have to figure out what is best for your server.
I have mysql replication master-slave of slave i make backups.
I use mysql-relay-bin to restore mysql database on crash. The problem is that in every restart mysql-relay-bin is deleted and create a new.
How to stop the creation of new mysql-relay-bin file.
Usually a new log file is created whenever slave I/O thread starts, if your old relay logs get deleted, this means usually that the slave is in sync with master (all events are applied to the slave db). This means your setup works as intended.
If you need persistant log files on the slave, you should activate binary logging on the slave host (as you did on master for replication setup). Also you want the updates which are coming from replication itself, this is archieved using the log-slave-updates parameter. Here is an example of the mysqld conf on the slave:
expire_logs_days = 5
log-slave-updates = 1
log_bin = /var/lib/mysql/mysql-bin.log
For further information on the parameters refer to MySQL docs on replication options
Keep also in mind that this will cost you additional disk space and also requires a different backup strategy in order to perform point in time recovery of your db.