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.
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 having a difficult time in setting Master-Slave configuration.
Master Database runs on Ubuntu( Amazon AWS instance) and successfully set-up master replication.
I have localhost as a Slave Server. (Windows Machine).
Snapshot of Master Database
Master database has record
Binar Log Information
Process List on Master Replication
Status of Master Replication
I debug master replication which works okay I guess.
On the Salve Side:
Status on Slave Side
Even though MASTER_LOG and MASTER_POS are synced but data doesn't.
Currently, I have 0 table on Slave side and 34 tables on Master side.
Tables on Slave side
I am open to any suggestion or any reference do you have.
I spend an entire day and trying to find what I did wrong.
I want to Sync my Local database with a database hosted on remote-server.
Update: Thigs I did to debug the Master-Slave Replication
Checked Master Database is up and running.
Master Status and Connected Slaves. [Which includes unique id for
each server.]
Slave database is up and running [Including Slave IO Thread and
SQL thread is running.]
These three steps ensure that Master-Slave replication is up and running without any problem.
Handling Data Sync Problem
Created/update/delete data in the master database to check
whether data is sync on a server or not.
Checked Binary Log [Specifically I checked the file size. If I
entered data file size will continuously increasing.]
Thanks in advance.
we had similar problem - read more about gotchas in "binlog-do-db" and "replication-do-db" and related parameters. Here is a big problem with crossdatabase references. At the and we had to remove these settings limiting replication.
Why MySQL’s binlog-do-db option is dangerous
Gotchas in MySQL replication
As your show slave status output says you enabled Replicate_DO_DB for the DB "Arihantpos" at the same time you did Binglog_Do_Db for the same db
try to remove Binglog_Do_Db from config file and restart mysql and start replication again
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 need to setup the replication
so for that i took backup from the master and imported into slave and now slave has 20 GB free space,
at the time while i am restoring backup master got 5+ GB of data
after that i enabled replication
Now the problem is while data from the relay log is written to slave many new relay logs are generated and i am left with no space on slave....
The relay-log-purge is enabled but the writing process from relay log to database is very slow...
You may have performance benefits by switching binlog format to 'ROW'. In mixed format mysql is writing binlog statement based (the slave has to reparse and plan the strategy again) and only switches to row format in certain cases (http://dev.mysql.com/doc/refman/5.1/en/binary-log-mixed.html).
It can be done on the fly:
SET GLOBAL binlog_format = 'ROW';
With ROW based replication you can offload the slaves which makes them easier to keep up with the master. The only downside of it is you may have larger log files however from this "got 5+ GB of data" I assume you mainly do inserts so the there will be no difference.
Best is to try it and see how it behaves.
Other option until the replication catches up to change the innodb_flush_log_at_trx_commit to 2 on the slave. Only do this temporary.
SET GLOBAL innodb_flush_log_at_trx_commit = 2;
just turn off the slave io thread when you get less disk space alert (90% reached) as
mysql> stop slave io_thread;
and start it again after some time as
mysql> start slave io_thread;
on production this is the only best possible option......
Try adding this to your config
relay-log-space-limit=5G
I wanted to set up a new replication slave for MySQL 5.6. Just after a CHANGE MASTER and starting the slave, I saw this line in the error log:
[Warning] Slave SQL: If a crash happens this configuration does not guarantee that the relay log info will be consistent, Error_code: 0
If it matters, these settings are included in my.ini:
skip-name-resolve
skip-host-cache
server-id = 111
report-host = myPC
relay-log-recovery
sync_master_info=1
sync_relay_log=1
sync_relay_log_info=1
replicate-do-db = myDB
skip-slave-start
Replication seems working, but this warning is scary. Any idea what makes MySQL issue this warning?
The warning is about crash-safe replication, a feature added to MySQL 5.6. It does not mean anything scary is going on (basically, replication works as in earlier releases) but it is notifying you that you could do better with the new feature set in MySQL 5.6.
A common request is to have replication crash-safe in the sense that the replication progress information always is in sync with what has actually been applied to the database, even in the event of a crash. Although transactions are not lost if the server crashes, it could require some tweaking to bring the slaves up again.
[...]
Crash-safe masters
If the master crashed when a binary log was rotated, it was possible that some orphan binlog files ended up in the binary log index file. This was fixed in 5.1 but is also a piece in the puzzle of having crash-safe replication.
Writing to the binary log is not an atomic operation, and if a crash occured while writing to the binary log, there were a possibility of a partial event at the end of the binary log.
Crash-safe slaves
If the replication information and data is stored in the same storage engine, it will allow both the data and the replication position to be updated as a single transaction, which means that it is crash-safe.
If the replication information and data is stored in different storage engines, but both support XA, they can still be committed as a single transaction.
The replication information is flushed to disk together with the transaction data. Hence writing the replication information directly to the InnoDB redo log does not offer a speed advantage, but does not prevent the user from reading the replication progress information easily.
The tables can be read from a normal session using SQL commands, which also means that it can be incorporated into such things as stored procedures and stored functions.
See the referenced blog post and the MySQL documentation for details of operation and set up instructions.