Currently replicate-rewrite-db is explicitly documented as having some limitations such as only working with binlog_format=ROW. In addition, this is what the docs say:

"This option only affects statements that involve tables. This option does not affect statements involving the database itself, such as CREATE DATABASE, ALTER DATABASE, and DROP DATABASE."

While technically correct, there is no mention of the fact that because DDL statements are always statement based, table-level DDL also does not work. While from a technical limitation perspective this is to be expected, from a syntactical point of view it seems like a trap: how would a user be expected to infer from this that CREATE TABLE does not work either?

The feature request is to change replicate-rewrite-db to understand table-level DDL and apply the same rules to it as to DML. Currently this is the behavior as described by a customer:

1. Create a master with a schema1 schema.
2. Create a replica of the master.
3. Create a schema2 schema on the replica.
4. Stop the replica and add the replicate-rewrite-db = schema1->schema2 directive.
5. Restart the replica and try the following.

This works:

CREATE TABLE t1 (mykey INT PRIMARY KEY) ENGINE = INNODB;

INSERT INTO schema1.t1 VALUES(4),(5),(6);

INSERT INTO t1 VALUES(1),(2),(3);

This fails because it forces t2 to be created in schema1 instead of schema2 on the replica:

CREATE TABLE schema1.t2 (mykey INT PRIMARY KEY) ENGINE = INNODB;

INSERT INTO schema1.t2 VALUES(4),(5),(6);

INSERT INTO t2 VALUES(1),(2),(3);

The replica gets this error and you can see that the empty t2 table exists in the schema1 schema

Error executing row event: 'Table 'schema2.t2' doesn't exist'