Tag Info

Hot answers tagged

4

What you're experiencing can easily occur in a low traffic situation, particularly if the two servers are separated by a firewall or other device that implements stateful packet inspection. (This is a situation that can occur, for example, within Amazon EC2/VPC). The intermediate networking hardware can "forget" about the TCP connection between the ...


3

The standard streaming replication on PostgreSQL is single threaded and there is no way to change this. However the question is why would you want to? PostgreSQL's streaming replication works through the write ahead log which is kinda of like a set of instructions "change block 3525 to this", "change block 2424 to this", etc. This makes the replication ...


2

repmgr 2.0 supports automatic failover. However, I strongly advise you not to use automatic failover. It's generally a much better idea to use manually triggered automated failover, where the failover process is scripted/automated, but a human has to say "Yup, master's dead, do it". If you do use automatic failover you need to make it a routine part of ...


2

What you have seems fine. I would add the following Run this on the Master. SET GLOBAL innodb_fast_shutdown = 0; SET GLOBAL sync_binlog = 1; SET GLOBAL sync_master_info = 1; This will cause everything that has been uncommitted to be committed on shutdown. Then, it flushes the binlogs to disk. On the Slaves, run this SET GLOBAL innodb_fast_shutdown = ...


2

If you are using Transactional Replication then yes, this configuration is supported. This is covered in Using Multiple Versions of SQL Server in a Replication Topology: For all types of replication, the Distributor version must be no earlier than the Publisher version. (Frequently, the Distributor is the same instance as the Publisher.) Since ...


2

We want to handle schema changes Transactional Replication would be hard to maintain. If you do frequent schema changes, then you have to drop replication and recreate it, which is time consuming and on the top of it, you have to maintain distribution database as well. Network latency also plays a big role if you are replicating your entire database. ...


2

Can we generate the logs for the few hour gap? Or are they gone? They are gone. You cannot do a sync with that gap. However, it should not matter. You need to setup replication from scratch on DB1. During off-hours, run this on DB2 MYSQL_USER=root MYSQL_PASS=rootpassword MYSQL_CONN="-u${MYSQL_USER} -p${MYSQL_PASS}" MYSQLDUMP_OPTIONS="" ...


2

Assuming you have run innobackupex --apply-log successfully you either have a configuration problem (probably innodb_log_files_in_group is 1 in the original and 2 -or not set- in the restored server) or you lost ib_logfile1 somewhere in the process. InnoDB is ok, it is normal for it to fail when it detects a different configuration on disk than on the file. ...


1

There are multiple reason why you wouldn't want to do multimaster replication in a circular fashion, but most of them can be summarized in one: You will have 3 different single points of failure. Check this article (which is exactly what you asked for, but probably not what you want). Standard replication is very prone to drifts in data, as it is ...


1

You be able to delete it without issues. Why ? Look for the file relay-log.index and display it # cat relay-log.index You will see a list of relay logs MySQL Replication needs and rotates. If relay.000724 is not in relay.index, you can delete relay.000724 without breaking anything. Why is is still around ? It could be anything. Between setting up ...


1

Edit: After my first assumptions, my next bet was on network problems. Use Michael advice, they have my bet and vote. Probably your problems is the combination of wsrep_on = OFF + DDL. Strange things may happen in that case with the binlog (a.k.a. they may not be logged correctly). Make sure to enable it even if you only have one node or you isolate it ...


1

There is better way to check whether the master and it's slaves are in sync. Run pt-table-checksum on the master. Then if it shows some tables are different use this script to see where exactly the difference is. http://bazaar.launchpad.net/~akuzminsky/+junk/stats-scripts/view/head:/compare_tables.sh ./compare_tables.sh master_ip slave_ip database ...


1

Don't you dare kill that process. Why ? Run this query SELECT COUNT(1) FROM information_schema.processlist WHERE user='system user'; The answer has to be two. Why ? Standard MySQL Replication functions on 2 threads: 1) IO Thread, 2) SQL Thread. In my old post Does MySQL support replicating all databases?, I explain the symbiosis between the two threads. ...


1

Things I'd check: Are any changes happening? Binary log doesn't include SELECT queries, only changes. Compare the timestamp on files like ib_logfile*. Are replication filters excluding changes being made? Are sessions making changes while SQL_LOG_BIN=0 is suppressing binary logging, either globally as @RolandoMySQLDBA suggests, or else per session? Disk is ...


1

This looks interesting and might (just might) be a solution to your issue. It shows how a 4.1 server can simulate Stored Procedures (SPs - not available till version 5 of the MySQL server) using the Federated storage engine. Basically, it shows that a 5.x server can access data on a 4.x server and even update that data. It also shows that you can use 5.x to ...


1

Since all the data is MyISAM, you should expect table locks rather frequently since INSERT , UPDATE, and DELETE command issues a full table lock. If you have a lot of tables that use auto increment keys, you should add the following Server1 [mysqld] auto_increment_increment = 5 auto_increment_offset = 1 Server2 [mysqld] auto_increment_increment = 5 ...



Only top voted, non community-wiki answers of a minimum length are eligible