Comments on How to Setup MySQL Master-Master Replication

Why not open the firewall ports instead of disabling it?

Wait, does this mean that I could put a keepalived with a VIP and not 'care' where the db is active, as in 'there is no active/all are active'?

no. you would need to monitor server ups/downs and replication lag. even with this info you still can't be sure if you can switch "masters" without creating inconsistentncy. its easy to break replication.

You should add a big notice about disabling the firewall and reducing selinux as it is greatly reducing the security of your server,  thus should never be done on a live net accessible server.

I agree with @A, this approach to ignore security is typical for many in IT and thus the problems we see these days with exploits. The right way to do it would be to explain how to set up SELinux to handle the appropriate programs and what ports to open in the firewall.

I appreciate that teaching secure setup was not the purpose of the article but the approach taken is worse than not mentioning it at all.

The security aspects (firewall, SElinux) have already been mentioned, I won't repeat that.

In addition, this tutorial calls for a number of comments on MySQL aspects:

1) On both machines, the configuration needs a setting added:auto-increment-increment = 2

2) To make sure the binlog is complete (needed for point-in-time recovery), also add:log-slave-updates = 1

3) Filtering the binlog is (in general) a no-no, because it prevents point-in-time recovery:Drop the lines with "binlog-do-db", so that every change is binlogged.

4) The article builds on the assumption that only one database (schema) is to be replicated, but does not mention it. Such a design decision must never be taken "by accident", it must be a conscious decision and explicitly mentioned. It must be listed in the assumptions.

5) Filtering replication (by "replicate-do-db") has some issues, for example after creating the database (which gets replicated) a "create table" in this DB will not be replicated via a binlog in row format - see my bug report: https://bugs.mysql.com/bug.php?id=77673Because of this, my general advice is not to filter but to replicate everything. (As always, there are exceptions.)

6) Similar, I doubt that a "create user" or "grant" will be replicated, I expect it to be filtered. So all commands to manage your application users need to be issued on both servers.

7) If you really want to filter replication, the binlog format ("row" vs "statement") will control the semantics. So this setting becomes important in the configuration.

8) If the "create database" is done after the reboot and gets replicated from serverA to serverB, this is a proof that replication is working in this direction. Still, this should be checked on both servers by issuing "show slave status \G". (Note the "\G" rather than the ";", for better readability.)

this is my second tutorial that I did for the master master replication, and it still does not work.

do i have to access the replicator user? or is this tutorial old anyone who can point me to the right direction.

Don't follow such tutorial for production environment. Disabling firewall / grant access to replication for all remote host is definitely not a good practice. Can't understand how such process can be on top search in Google. 

Instead "GRANT REPLICATION SLAVE ON foo.* TO 'replicator'@'%'" should be "GRANT REPLICATION SLAVE ON *.* TO 'replicator'@'%'" otherwise you faced issue: "ERROR 1221 (HY000): Incorrect usage of DB GRANT and GLOBAL PRIVILEGES". 

Hi, why article don't show publish date? Comments too;)