Tag Info

New answers tagged

1

I ended up using a post-initialization script to grant this permission at the subscriber and it worked great.


0

I have since come to learn, from this SO thread, that it is possible to do what I asked in my question. And it prevents rows inserted/updated/deleted on the source from being replicated to the destination.


2

I believe your DBA is referring to Publishing Stored Procedure Execution in Transactional Replication. With Transactional Replication you have the option to published the definition of the stored procedure or the execution of the stored procedure. Publishing stored procedure execution can provide significantly better performance for large batch operations ...


1

1) If we can set up the transactional replication between server A of version 2014 and server B of version 2012. Tried to Google out but could not find the exact documents because may be am looking somewhere wrong. Please suggest if it can be set up? For your replication to work, the PUBLISHER and DISTRIBUTOR should be on same version. The subscriber ...


2

For querying secondary run the following command first. After running this, you can do all regular stuff on secondary. rs.slaveOk() To see the replication status, run the following command on primary. This will show you if the secondaries are up to date or lagging. db.printSlaveReplicationInfo() Hope this helps.


0

Here is one for the ages I wrote an answer to a post on Jan 02, 2015 entitled mysql replication master 5.5 slave 5.1 error on create database. In that post, I learned from my boss about this strange situation when I was replicating from a MySQL 5.5 Master to a MySQL 5.6 Slave. In short, I learned from some additional research that binary log events can ...


0

Two possible reasons seem to stick out, ensure your server_id is different on both the master and the slave. This is to be defined at startup in the cnf file. Another option is you specified a very tiny max_binlog_size or max_relay_log_size, ensure the values are what you want and not off by an order of magnitude (eg. 512k instead of 512M)


0

I looked in to the declaration of sp_changemergepublication and found out the way it invalidates the snapshot is a simple query to update the table sysmergepublications if (@property like 'ftp%' OR @property in ('sync_mode', 'snapshot_in_defaultfolder', 'alt_snapshot_folder', 'pre_snapshot_script', ...


0

Replication from MySQL 5.x to 5.6 has a bear trap just waiting for you. In Michael's comment, he stated the politically accept premise : "MySQL supports replication from one major version to the next higher major version.". He also said "this setup isn't guaranteed to work in either direction." I have a very interesting caveat on going from 5.x to 5.6: ...


2

Cringe, gag, etc. 5.1 and 5.6 differ by 2 major versions. Replication is 'guaranteed' to work one direction, not the other. Don't turn on GTIDs in 5.6; 5.1 will not like it. Don't use any features new to 5.5 or 5.6. Simply, don't do it. Get the 5.1 upgraded ASAP.


0

The Slave should be irrelevant, unless you are using (misusing) some form of parallel execution on the Slave. Try other transaction_isolation_modes. GET_LOCK()/RELEASE_LOCK() may provide a sufficient "lock"; but all writers to that table(s) would need to use it. Do not turn on auto-reconnect in your connection. An network glitch will mess with both the ...


0

You have described a common way to make DDL changes. Yes, it should work. But... please describe the datatype change further. If you are ALTERing a COLUMN that is current INT SIGNED to be a SMALLINT SIGNED, and if none of the values are bigger than 32767, there should be no problem. If you are changing from SIGNED to UNSIGNED, and none of the numbers ...


1

slave-skip-errors can hide even serious errors; don't do it. Turn on the "general log" briefly. This should capture a little more info about where the duplicate DELETE is coming from. One of two things will happen: There will be two DELETEs in the general log, too. This will point at the application for issuing the delete twice. There will be one in ...


1

Yeah, what the heck is tmp_user? This smells like an attack. And I suspect it was successful. He probably already got in -- all he had to do was to try different flavors of the INSERT based on different versions. The one successful insert would suffice. Then he RENAMEs tables, does damage, rename tables back, DROPs evidence of his naughtiness, and ...


0

I feel a bit stupid, but the answer to that strange behavior was simple: The old node1 cluster node was trying to connect to the cluster again after a reboot. I forgot to uninstall the mysql installation on that node and instead only stopped the mysql server. That was well as long the system did not restart mysql. To fix the situation I removed the old ...


0

I would also say bang it out in your test environment as well. Make sure you have Ip connectivity as well as name resolution too.


2

Your Snapshot Agent process account does not have sufficient permissions to access the snapshot folder. In the section Permissions That Are Required by Agents in Replication Agent Security Model, the Snapshot Agent process account requires db_owner in the distribution and publication databases and needs read, write, and modify permissions on the snapshot ...


3

Yes, you are correct. This relies on the server ID being set correctly in the standard MySQL configuration. In MySQL 5.6 and above you can configure the server to use GTIDs (Global Transaction IDentifiers) and they are used on all servers to determine if transactions need to be executed or not


1

As mentioned, the slave is set up to do two way replication, and there was actually some advice in the error log: these ids must be different for replication to work (or the --replicate-same-server-id option must be used on slave but this does not always make sense In this case, adding replicate-same-server-id = 1 to the slave my.cfg worked and may be all ...


0

By default, an index key for a single-column index can be up to 767 bytes –MySQL Reference Manual The size of your index is: 191 (characters) * 4 (utf8mb4 max size per character) + 4 (length) + 1 (NULL) = 769 The calculation may not be 100% exact, I am not fully sure about the length requirements, but I will assume it is not a bug. The reason ...


1

You didn't setup the server-id variable, or you didn't restart after doing it (it is not a dynamic variable, changes will not be effective until you restart). It may be showing you a good id on both servers, but it will not really work until both servers are restarted, both master and slave. It could be a bug, but the above has happened too many times on ...


0

Yes, you are correct. You can often get bitten from the fact that the triggers are missing on the slave and thus the trigger effects are not there. Also if the triggers use any routines (PROCEDUREs and FUNCTIONs) you have to make sure they are present on the slave too. The latter might bite you if you provision your slaves from a mysqldump, since by default ...


0

Each connection eats up about 1MB of RAM on the server side. That includes the connections to the config servers and the replica set members. Please keep in mind that those communicate with each other. So, let's say you want to use 1/3 of the RAM of your shards for connections, that'd be 5GB or 5000MB. Then, each server connects to two members of it's ...


1

When doing this: $ psql -h $MASTER_PORT_5432_TCP_ADDR -U replication psql: FATAL: no pg_hba.conf entry for host "$SLAVE_PORT_5432_TCP_ADDR", user "replication", database "replication", SSL off Since there's no explicit database indicated with -d (for example -d postgres ), it takes replication as the database, the same as the user name. However that's ...


0

This appears to be client error 2005, which is "unknown host." If you've configured the target master by hostname, it suggests a DNS resolution issue on that hostname by the slave host. The hostname is resolved using the slave machine's OS's DNS resolver, so the fact that you can connect to it, if you're trying from elsewhere, doesn't necessarily mean much ...


0

Once you change the master_host, you have to redo everything else It says so in the MySQL Documentation on CHANGE MASTER TO If you specify the MASTER_HOST or MASTER_PORT option, the slave assumes that the master server is different from before (even if the option value is the same as its current value.) In this case, the old values for the master binary ...


2

I assume GTID has been already enabled on the master: Stop the master server Copy your data directory to the slave host Start the master. Technically it is not needed, but if you do not feel safe with what you do and want to be 100% sure everything is correct before continuing with replication- you can start it in read-only mode. Once you see that it is ...


2

OBSERVATION #1 The slave needs log-slave-updates in my.ini OBSERVATION #2 Both Master and Slave need binlog_gtid_simple_recovery in my.ini MySQL Restart is required on both Master and Slave to include new options SUGGESTION Since DB is 5GB, just mysqldump the database on the Master. No need for raw copying STEP 01 : On the Master, run this RESET ...


0

For RDS to have binlogs, there are a couple non-obvious tricks. First, you need to set the "backup retention period" to at least 1 day. This turns on binlogging. Then, in order to prevent a ridiculous rollover rate in the logs: call mysql.rds_set_configuration('binlog retention hours', 24); Here's some documentation that Amazon provides for dumping ...



Top 50 recent answers are included