• Filtering based on server ID not supported.  You can filter based on server ID by using the IGNORE_SERVER_IDS  option for the CHANGE REPLICATION SOURCE TO  statement (from MySQL 8.0.23) or CHANGE MASTER TO  statement (before MySQL 8.0.23). This option works with statement- based and row-based logging formats, but is deprecated for use when GTID_MODE=ON  is set. Another method to filter out changes on some replicas is to use a WHERE  clause that includes the relation @@server_id <> id_value  clause with UPDATE  and DELETE  statements. For example, WHERE @@server_id <> 1 . However, this does not work correctly with row-based logging. To use the server_id  system variable for statement filtering, use statement-based logging. 

• RBL, nontransactional tables, and stopped replicas.  When using row-based logging, if the replica server is stopped while a replica thread is updating a nontransactional table, the replica database can reach an inconsistent state. For this reason, it is recommended that you use a transactional storage engine such as InnoDB  for all tables replicated using the row-based format. Use of STOP REPLICA | SLAVE  or STOP REPLICA | SLAVE SQL_THREAD  prior to shutting down the replica MySQL server helps prevent issues from occurring, and is always recommended regardless of the logging format or storage engine you use. 

## 17.2.1.3 Determination of Safe and Unsafe Statements in Binary Logging 

The “safeness”  of a statement in MySQL replication refers to whether the statement and its effects can be replicated correctly using statement-based format. If this is true of the statement, we refer to the statement as safe ; otherwise, we refer to it as unsafe . 

In general, a statement is safe if it deterministic, and unsafe if it is not. However, certain nondeterministic functions are not  considered unsafe (see Nondeterministic functions not considered unsafe, later in this section). In addition, statements using results from floating-point math functions—which are hardware- dependent—are always considered unsafe (see Section 17.5.1.12, “Replication and Floating-Point Values” ). 

Handling of safe and unsafe statements.  A statement is treated differently depending on whether the statement is considered safe, and with respect to the binary logging format (that is, the current value of binlog_format ). 

•When using row-based logging, no distinction is made in the treatment of safe and unsafe statements. 

•When using mixed-format logging, statements flagged as unsafe are logged using the row-based format; statements regarded as safe are logged using the statement-based format. 

•When using statement-based logging, statements flagged as being unsafe generate a warning to this effect. Safe statements are logged normally. 

Each statement flagged as unsafe generates a warning. If a large number of such statements were executed on the source, this could lead to excessively large error log files. To prevent this, MySQL has a warning suppression mechanism. Whenever the 50 most recent ER_BINLOG_UNSAFE_STATEMENT warnings have been generated more than 50 times in any 50-second period, warning suppression is enabled. When activated, this causes such warnings not to be written to the error log; instead, for each 50 warnings of this type, a note The last warning was repeated N  times in last S  seconds is written to the error log. This continues as long as the 50 most recent such warnings were issued in 50 seconds or less; once the rate has decreased below this threshold, the warnings are once again logged normally. Warning suppression has no effect on how the safety of statements for statement-based logging is determined, nor on how warnings are sent to the client. MySQL clients still receive one warning for each such statement. 

For more information, see Section 17.2.1, “Replication Formats” . 

## Statements considered unsafe. 

