it seems the binlog doesn't include the new inserts
I'm not sure whether you're saying the binlog actually doesn't include them, and you have confirmed this with mysqlbinlog, or that it "seems" like it doesn't, because they don't replicate.
PXC needs log_slave_updates turned on at the node serving as master to the asynchronous slave, otherwise, not everything will be written to the master's binary log. This is very different than an ordinary MySQL server as master, where log_slave_updates will do nothing at all (unless the master is actually a slave to another master).
If that's not it, remove replicate_do_db and binlog_do_db and all of their related options from your configuration and then remove them from your brain. They should never be added unless you know exactly how they work, in your sleep. The simplest and by far most reliable replication configuration is, and will always be, replicate everything, which is the default.
Forget about binlog_format on the slave. It makes absolutely no difference unless the slave, itself, has other, subtended slaves... and if the master is using ROW format, the slave will still log in ROW format if you do indeed have it configured with subtended slaves. Also, the slave's binlogs (not to be confused with the relay logs) will not log statements received from an upstream master unless log_slave_updates is enabled on the slave.
The same thing goes for innodb_flush_log_at_trx_commit. It does not impact actual replication. It's a setting the determines a tradeoff between ACID compliance and performance.
You cannot just jump back to the old master, as it is said here:
Once failover to the standby occurs, there is only a single server in
operation. This is known as a degenerate state. The former standby is
now the primary, but the former primary is down and might stay down.
To return to normal operation, a standby server must be recreated,
either on the former primary system when it comes up, or on a third,
possibly new, system.
For this, you need a recovery.conf on the old master. This should be nearly the same as the present one, only the connection has to point elsewhere.
Best Answer
I would suggest having the same
wal_levelon all servers, as as it defines the amount of information you will have when WAL is created (on the primary, these files are then streamed to the standbys).The available
wal_levelsettings (with each setting writing more information to each WAL, as well as all that of lower levels) from low to high are:minimalreplica(older valuesarchiveandhot_standbyare mapped to this)logicalIn this case I would set
wal_level = logicalfor all. As WAL is only created in one place this won't hurt, and it has the added benefit of keeping working if you ever promote a standby to a master.You mention
hot_standbyin the diagram, this has now been renamedreplica(although both still work).Other than that this topology should be fine, we use something like this - although you have logical replication from the standby, you'll need to move this to coming from the master. There was a rejected patch to allow this to come from a standby in PostgreSQL 10, hopefully this comes through in PostgreSQL 11.