Setting Up Binary Log File Position Based Replication innodb_flush_log_at_trx_commit=1  and  sync_binlog=1  in the source’s my.cnf  file. •Ensure that the  skip_networking  system variable is not enabled on the source. If networking has been disabled, the replica cannot communicate with the source and replication fails. 17.1.2.2 Setting the Replica Configuration Each replica must have a unique server ID, as specified by the  server_id  system variable. If you are setting up multiple replicas, each one must have a unique  server_id  value that differs from that of the source and from any of the other replicas. If the replica’s server ID is not already set, or the current value conflicts with the value that you have chosen for the source or another replica, you must change it. The default  server_id  value is 1. You can change the  server_id  value dynamically by issuing a statement like this: SET GLOBAL server_id = 21; Note that a value of 0 for the server ID prevents a replica from connecting to a source. If that server ID value (which was the default in earlier releases) was set previously, you must restart the server to initialize the replica with your new nonzero server ID. Otherwise, a server restart is not needed when you change the server ID, unless you make other configuration changes that require it. For example, if binary logging was disabled on the server and you want it enabled for your replica, a server restart is required to enable this. If you are shutting down the replica server, you can edit the  [mysqld]  section of the configuration file to specify a unique server ID. For example: [mysqld] server-id=21 Binary logging is enabled by default on all servers. A replica is not required to have binary logging enabled for replication to take place. However, binary logging on a replica means that the replica’s binary log can be used for data backups and crash recovery. Replicas that have binary logging enabled can also be used as part of a more complex replication topology. For example, you might want to set up replication servers using this chained arrangement: A -> B -> C Here,  A  serves as the source for the replica  B , and  B  serves as the source for the replica  C . For this to work,  B  must be both a source  and  a replica. Updates received from  A  must be logged by  B  to its binary log, in order to be passed on to  C . In addition to binary logging, this replication topology requires the log_slave_updates  system variable to be enabled. With replica updates enabled, the replica writes updates that are received from a source and performed by the replica’s SQL thread to the replica’s own binary log. The  log_slave_updates  system variable is enabled by default. If you need to disable binary logging or replica update logging on a replica, you can do this by specifying the  --skip-log-bin  and  --log-slave-updates=OFF  options for the replica. If you decide to re- enable these features on the replica, remove the relevant options and restart the server. Each replica connects to the source using a MySQL user name and password, so there must be a user account on the source that the replica can use to connect. The user name is specified by the SOURCE_USER  |  MASTER_USER  option of the  CHANGE REPLICATION SOURCE TO  statement (from MySQL 8.0.23) or  CHANGE MASTER TO  statement (before MySQL 8.0.23) when you set up a replica. Any 17.1.2.3 Creating a User for Replication 3440