Replication and Binary Logging Options and Variables directly involved with Group Replication, such as where a group member also acts as a replica to a source that is outside the group. They cannot be used on the  group_replication_applier  or  group_replication_recovery channels. The precise effect of this replication filter depends on whether statement-based or row-based replication is in use. Statement-based replication.   Tell the replication SQL thread to restrict replication to statements where the default database (that is, the one selected by  USE ) is  db_name . To specify more than one database, use this option multiple times, once for each database; however, doing so does  not  replicate cross-database statements such as  UPDATE  some_db.some_table  SET foo=’bar’  while a different database (or no database) is selected. To specify multiple databases you  must  use multiple instances of this option. Because database names can contain commas, if you supply a comma separated list then the list is treated as the name of a single database. An example of what does not work as you might expect when using statement-based replication: If the replica is started with  --replicate-do-db=sales  and you issue the following statements on the source, the  UPDATE  statement is  not  replicated: USE prices; UPDATE sales.january SET amount=amount+1000; The main reason for this “check just the default database”  behavior is that it is difficult from the statement alone to know whether it should be replicated (for example, if you are using multiple-table  DELETE statements or multiple-table  UPDATE  statements that act across multiple databases). It is also faster to check only the default database rather than all databases if there is no need. Row-based replication.   Tells the replication SQL thread to restrict replication to database  db_name . Only tables belonging to  db_name  are changed; the current database has no effect on this. Suppose that the replica is started with  --replicate-do-db=sales  and row-based replication is in effect, and then the following statements are run on the source: USE prices; UPDATE sales.february SET amount=amount+100; The  february  table in the  sales  database on the replica is changed in accordance with the  UPDATE statement; this occurs whether or not the  USE  statement was issued. However, issuing the following statements on the source has no effect on the replica when using row-based replication and  -- replicate-do-db=sales : USE prices; UPDATE prices.march SET amount=amount-25; Even if the statement  USE prices  were changed to  USE sales , the  UPDATE  statement’s effects would still not be replicated. Another important difference in how  --replicate-do-db  is handled in statement-based replication as opposed to row-based replication occurs with regard to statements that refer to multiple databases. Suppose that the replica is started with  --replicate-do-db=db1 , and the following statements are executed on the source: USE db1; 3508 Warning