How does replication work in MySQL?

It doesn't work as you describe in the question. Below I will explain, without going into technical details, how it is done.

The operation of the replication is based on the binary or transaction log generated by the MySQL server.

Any modification made to the database is written in said registry, and this registry is sent in the form of a stream of data at the request of the connected secondary servers, which will replicate the changes that are reflected in it.

In the official documentation you can find the following:

The binary log contains “events” that describe database changes such as table creation operations or changes to table data. It also contains events for statements that potentially could have made changes (for example, a DELETE which matched no rows), unless row-based logging is used. The binary log also contains information about how long each statement took that updated data. The binary log has two important purposes:

• For replication, the binary log on a replication source server provides a record of the data changes to be sent to replicas. The source sends the information contained in its binary log to its replicas, which reproduces those transactions to make the same data changes that were made on the source. See Section 17.2, “Replication Implementation”.

• Certain data recovery operations require use of the binary log. After a backup has been restored, the events in the binary log that were recorded after the backup was made are re-executed. These events bring databases up to date from the point of the backup. See Section 7.5, “Point-in-Time (Incremental) Recovery”.

The binary log is not used for statements such as SELECT or SHOW that do not modify data. To log all statements (for example, to identify a problem query), use the general query log. See Section 5.4.3, “The General Query Log”.

In Spanish:

The binary log contains "events" that describe changes to the database such as the creation of tables or changes to data in a table. It also contains events events for statements that might have made changes (for example, a DELETEthat did not match any record), unless row-based logging is used. The binary log also contains information about how long each statement took to update that data. The binary log has two important purposes:

• For replication, the replication source server binary log provides a record of data changes being sent to replicas. The origin sends the information contained in its binary log to its replicas, which replay those transactions to make the same data changes that were made on the origin. See section 17.2, “Implementing Replication”.

• Certain data recovery operations require the use of binary logging. After a backup has been restored, events in the binary log that were logged after the time the backup was taken are replayed. These events will update the databases from the time of the backup. See Section 7.5, “Point-in-Time (Incremental) Recovery”.

The binary log is not used for statements like SELECTor SHOWbecause they do not modify data. To log all statements (for example, to identify a potentially troublesome query), use normal query logging. See Section 5.4.3, “The query log”.

In Section 17.2 Replication Implementation you also have the following:

Replication is based on the source server keeping track of all changes to its databases (updates, deletes, and so on) in its binary log. The binary log serves as a written record of all events that modify database structure or content (data) from the moment the server was started. Typically, SELECT statements are not recorded because they modify neither database structure nor content.

In Spanish:

Replication relies on a source server keeping track of all changes to its databases (updates, deletes, etc) in its binary log. The binary log serves as a history of all events that modify the structure or content (data) of the database from the time the server was started. Normally the statements SELECTare not logged because they do not modify the structure or the content of the database.

In addition, you must understand that if modifications are made to the replicas (let's use the terminology "primary/replica" instead of "master/slave") that may collide with the process of replicating the changes of the primary, the replication will stop with an error message and will have to be corrected manually before it can continue:

If a statement produces different errors on the source and the replica, the replication SQL thread terminates, and the replica writes a message to its error log and waits for the database administrator to decide what to do about the error.

In Spanish:

If a statement produces different errors on the primary and the replica, the replication process ends and the replica writes a message to its error log waiting for the database administrator to decide what to do with the error.

This behavior is not unique or exclusive to MySQL or its replication, but it is a very common component in the vast majority of database managers (to be used in replication tasks or not):

• MS SQL Server Documentation .
• PostgreSQL documentation .
• Oracle Documentation v12 .