Thanks. This is what I meant Indeed row level replication becomes very important with a lot of new features as stored procedures and triggers, as well as with high concurrency transactional engines - I’m not sure Falcon or PBXT could use logical replication at all. It surely has different properties but I hope it will be good replaced in more cases than Innodb Cluster is.

Funny enough back when 4.1 was in beta and 5.0 was in early development (before NDB Cluster) I discussed some guys in MySQL if logical replication is good enough, highlighting new features planned for MySQL 5.0 like Stored Procedures and Triggers can be hard to get with statement based replication. There were discussions to get row level replication at that point but it dropped as there was a way to get it work with logical replication. In MySQL 5.0 a lot of work was done to really make things work with logical replication as it was not easy and still in MySQL 5.1 row level replication was added.

My personal opinion is row-level replication will be better in many ways, but I bet a lot of people are going to be really surprised when they see how it really performs for their specific scenarios! I think people may be looking forward to “this will solve all problems.” Sort of how people think “I’ll just set up NDB cluster, a cluster will solve all my problems”

No indeed it is as simple as you describe but you need to have extreme care which statements do you filter out.

Manually running ALTER TABLE on slave and master separately is actually rather good use.

Generally MySQL Proxy is another way one could possibly filter binary logs, and this way you may be able to implement even more flexible log filtering and do it on the fly instead of spooling copy of logs like blackhole server does. Though as I have not tested it am not writing about it though this would be interesting exercise.

Regarding this statement:
“…using SET SQL_LOG_BIN=0 if you need to skip some statements from binary logging. This command requires SUPER Privilege and extreme care in use…”

Can you detail a lil’ more on the extreme care you’re talking about? What are the hell scenarios that might hit our beloved replication/mysql servers?
I mean, once I know what that sql statement does, I’m pretty much aware that every DML I’m issuing AFTER sql_log_bin = 0 is happening at the session level, on the local box, nothing being written in the binlog.
Thanks.