Tag Info

Hot answers tagged

3

You find the explanation of your question in the docs: "If the value of auto_increment_offset is greater than that of auto_increment_increment, the value of auto_increment_offset is ignored." For your purpose it would be sufficient to leave auto_increment_increment and auto_increment_offset on their default values and simply run: ALTER TABLE test ...


2

Current (true at least in PostgreSQL 9.4 and older) PostgreSQL releases have single-threaded WAL recovery. This means that replay of the write-ahead log occurs in only one recovery worker, and is thus able to benefit less from I/O concurrency than a normal running master. This can result in WAL replay lagging behind in cases where the replica and master ...


2

You need to be aware of query results and query behavior with replication running. While there are a minimum of two threads for MySQL Replication, it is the SQL thread that can get in the way of SELECT queries. Why? MyISAM Each time an INSERT, an UPDATE, or a DELETE is executed, a full table locked is issued. That can block SELECTs. The only exception is ...


2

The replication filter you have in place Replicate_Wild_Do_Table: zo_dev_matrix.* is actually a little misleading. In the MySQL Documentation, the legal characters for wildcards are %, _ and \_. (If you want to interpret a literal underscore). The asterisk character is not listed. The above filter is actually looking for a table called zo_dev_matrix.*. ...


2

If the master crashes, then it doesn't really matter what you do as far as stopping the slave, as long as you observe the slave once the master is back online, to verify that it has successfully started reading and executing events from the master again. If you don't stop it, the slave should still be fine, and will sit and continually try to reconnect to ...


2

There is an obvious problem with your "delayed backup" model, in that your delayed secondaries will reflect the state of each replica set but not the full state of the sharded cluster at a given point in time. A simple example: there is a chunk migration from shard1 => shard2 in progress documents will exist on both shard1 and shard2 while they are being ...


1

There is no solution for fan-in with traditional MySQL replication. Another option is Tungsten Replicator. Here are a couple of posts on how it supports fan-in replication: http://narmitag.wordpress.com/2012/09/27/setting-up-fan-in-using-tungsten-replicator/ https://code.google.com/p/tungsten-replicator/wiki/TRCMultiMasterInstallation Another option is ...


1

When possible, you should run slave stop on the slave after you have stopped traffic to the master. That said, in most cases the salve will reconnect on its own as long as [a] there isn't an re-attempt limit, [b] the last slave read concluded properly and [c] the binlog on the master side hasn't been corrupted.


1

I like this presentation by Giuseppe Bianchi. Starting on page 5 it contains a desctiption of the TLS protocol - segment size, header size, HMAC overhead. As for the handshake, the impact on replication should be negligible. It will only occur on connection, and there may be a key exchange going on every hour, depending on the configuration. As for the ...


1

On Apri 18, 2012, I addressed a similar question : MySQL : Does 'bytes_sent' and 'bytes_received' include mysqldump data? I mentioned the following Bytes_sent : IO Thread requesting binlog entries from the Master Bytes_received : IO Thread reading binlogs entries from its Master Bytes_received : SQL thread reading its own relay logs You ...


1

Your question already has the key to your answer. It does depend on row based or statement based replication. STATEMENT-BASED REPLICATION If you run DELETE FROM tblname WHERE blahblahblah; and the rows matching blahblahblah do not exist, no big deal. Replication will just carry on. It just take you a lot longer to realize your data draft on the Slave (or ...


1

I am not sure if there is a better way but something simple like this should do it. If you run this query on the Publisher, it will compare the tables and will return you the difference in tables. The Publisher needs to be linked to the Subscriber. -- Publisher select t.name from sys.tables t where is_published = 1 except -- Subscriber select t.name from ...


1

I briefly searched MySQL Documentation I located the Rewrite DB Option embedded in a new mechanism : CHANGE REPLICATION FILTER It allows you to manipulate the Rewrite DB stuff without restarting MySQL. UPDATE 2014-04-02 15:48 EDT After reading the MySQL 5.7 Docs, I can safely say that CHANGE MASTER TO and CHANGE REPLICATION FILTER still cannot help you. ...


1

The only officially supported method is to make a new base backup, or: pg_start_backup() on the new master rsync from new master to old master pg_stop_backup() ensure WAL got copied over and applied create recovery.conf start resynced server The 3rd party tool pg_rewind is intended for that purpose. I haven't worked with it as yet and can't vouch for it ...


1

Actually both configurations are possible. Remarks to your ideas For configuration 1, just set up the first Master->Slave replication. See that you should activate --log-slave-updates on the slave so that the slave creates an appropriate binary log for the propagation of the next slave in the chain. Then set up the new slave with the previous slave as a ...


1

What you want is server1 to binlog not only its own updates, but also those updates he received from server2, so that slave1 will get all updates. You just need to tell server1 to do this, which can be accomplished by setting log-slave-updates to yes. You might want to set this option on server2 too, if the server topology should change someday (as Rolando ...


1

Consider using INSERT ... ON DUPLICATE KEY UPDATE or REPLACE statements on the master server. Just note that: These are unsafe statements for replication, so statement based replication will produce a warning and divergence is possible - consider using MIXED bin log. These only work on tables with a single unique key or primary key If there are ...


1

To reinforce what Jon says - a single DB to which all clients connect all the time, with the schema designed accordingly, will be a much better solution. You only need replication in a few circumstances. One is if a client machine must be able to work while disconnected. Another will be if there are huge latency issues between your various sites. ...



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