[mysqld]

skip-slave-start

Tells the replica server not to start the replication threads when the server starts. To start the threads later, use a START SLAVE statement.

看样子应该是启动从服务器时不启动从服务器的复制线程吧

skip-external-locking

This is OFF if mysqld uses external locking (system locking), ON if external locking is disabled. This affects only MyISAM table access.
看样子应该和单机和集群模式有关，并且还是多进程的。

server-id

这个就不看官方文档了，相当于服务ID，要保证主从服务器的id不同，一般可以使用服务器ip的部分作为唯一标识

binlog_format

二进制日志格式，一共有三种
STATEMENT，ROW，MIXED

STATEMENT 日志记录基于语句。

ROW日志记录基于行。这是默认设置。

MIXED 日志记录使用混合格式。
详见：官方文档--binary-log-setting

log_bin_trust_function_creators

This variable applies when binary logging is enabled. It controls whether stored function creators can be trusted not to create stored functions that may cause unsafe events to be written to the binary log. If set to 0 (the default), users are not permitted to create or alter stored functions unless they have the SUPER privilege in addition to the CREATE ROUTINE or ALTER ROUTINE privilege. A setting of 0 also enforces the restriction that a function must be declared with the DETERMINISTIC characteristic, or with the READS SQL DATA or NO SQL characteristic. If the variable is set to 1, MySQL does not enforce these restrictions on stored function creation. This variable also applies to trigger creation. See Section 25.7, “Stored Program Binary Logging”.

应该与创建存储过程和触发器有关，如果对数据有修改，并且不是基于行或者混合时就没有警告，如果基于语句的话，会有警告。

Specifies the number of days before automatic removal of binary log files. expire_logs_days is deprecated, and you should expect it to be removed in a future release. Instead, use binlog_expire_logs_seconds, which sets the binary log expiration period in seconds. If you do not set a value for either system variable, the default expiration period is 30 days. Possible removals happen at startup and when the binary log is flushed. Log flushing occurs as indicated in Section 5.4, “MySQL Server Logs”.

Any non-zero value that you specify for expire_logs_days is ignored if binlog_expire_logs_seconds is also specified, and the value of binlog_expire_logs_seconds is used instead as the binary log expiration period. A warning message is issued in this situation. A non-zero value for expire_logs_days is only applied as the binary log expiration period if binlog_expire_logs_seconds is not specified or is specified as 0.

expire_logs_days

To disable automatic purging of the binary log, specify a value of 0 explicitly for binlog_expire_logs_seconds, and do not specify a value for expire_logs_days. For compatibility with earlier releases, automatic purging is also disabled if you specify a value of 0 explicitly for expire_logs_days and do not specify a value for binlog_expire_logs_seconds. In that case, the default for binlog_expire_logs_seconds is not applied.
二进制日志文件过期时间(天)

relay-log

The base name for relay log files. For the default replication channel, the default base name for relay logs is <code>host_name</code>-relay-bin. For non-default replication channels, the default base name for relay logs is <code>host_name</code>-relay-bin-<code>channel</code>, where channel is the name of the replication channel recorded in this relay log.

中转日志的位置和名称，如果值为空，则默认位置在数据文件的目录

log_slave_updates

From MySQL 8.0.26, use log_replica_updates in place of log_slave_updates, which is deprecated from that release. In releases before MySQL 8.0.26, use log_slave_updates.

log_replica_updates specifies whether updates received by a replica server from a replication source server should be logged to the replica's own binary log.
从机在复制主机时，记录到从机的二进制日志

gtid_mode

Controls whether GTID based logging is enabled and what type of transactions the logs can contain. You must have privileges sufficient to set global system variables. See Section 5.1.9.1, “System Variable Privileges”. enforce_gtid_consistency must be set to ON before you can set gtid_mode=ON. Before modifying this variable, see Section 17.1.4, “Changing GTID Mode on Online Servers”.

Logged transactions can be either anonymous or use GTIDs. Anonymous transactions rely on binary log file and position to identify specific transactions. GTID transactions have a unique identifier that is used to refer to transactions. The different modes are:

OFF: Both new and replicated transactions must be anonymous.
OFF_PERMISSIVE: New transactions are anonymous. Replicated transactions can be either anonymous or GTID transactions.
ON_PERMISSIVE: New transactions are GTID transactions. Replicated transactions can be either anonymous or GTID transactions.
ON: Both new and replicated transactions must be GTID transactions.

Changes from one value to another can only be one step at a time. For example, if gtid_mode is currently set to OFF_PERMISSIVE, it is possible to change to OFF or ON_PERMISSIVE but not to ON.

The values of gtid_purged and gtid_executed are persistent regardless of the value of gtid_mode. Therefore even after changing the value of gtid_mode, these variables contain the correct values.

控制是否启用基于GTID的日志记录

enforce_gtid_consistency

Depending on the value of this variable, the server enforces GTID consistency by allowing execution of
only statements that can be safely logged using a GTID. You must set this variable to ON before enabling
GTID based replication.
The values that enforce_gtid_consistency can be configured to are:
• OFF: all transactions are allowed to violate GTID consistency.
• ON: no transaction is allowed to violate GTID consistency.
• WARN: all transactions are allowed to violate GTID consistency, but a warning is generated in this case.
强制GTID一致性

slave-parallel-type

From MySQL 8.0.26, slave_parallel_type is deprecated and the alias replica_parallel_type
should be used instead. In releases before MySQL 8.0.26, use slave_parallel_type.
For multithreaded replicas (replicas on which replica_parallel_workers or
slave_parallel_workers is set to a value greater than 0), slave_parallel_type specifies the
policy used to decide which transactions are allowed to execute in parallel on the replica. The variable
has no effect on replicas for which multithreading is not enabled. The possible values are:
• LOGICAL_CLOCK: Transactions that are part of the same binary log group commit on a source
are applied in parallel on a replica. The dependencies between transactions are tracked based on
their timestamps to provide additional parallelization where possible. When this value is set, the
binlog_transaction_dependency_tracking system variable can be used on the source to
specify that write sets are used for parallelization in place of timestamps, if a write set is available for
the transaction and gives improved results compared to timestamps.
• DATABASE: Transactions that update different databases are applied in parallel. This value is only
appropriate if data is partitioned into multiple databases which are being updated independently and
concurrently on the source. There must be no cross-database constraints, as such constraints may be
violated on the replica.
When replica_preserve_commit_order=1 or slave_preserve_commit_order=1 is set, you
can only use LOGICAL_CLOCK.

用于决定允许哪些事务在副本上并行执行的策略，逻辑时钟：基于组提交的并行复制方式，DATABASE 为默认值，意为基于库的并行复制方式，不同库的事务，没有锁冲突，但是效率慢，因为粒度粗。而LOGICAL_CLOCK只要事务之间没有锁冲突就可以并发。

relay_log_recovery

Whether automatic recovery of relay log files from source at startup is enabled;must be enabled for crash-safe replica.
是否启用了在启动时从源自动恢复中继日志文件;必须启用崩溃安全复制。

[mysqldump]

quick

This option is useful for dumping large tables. It forces mysqldump to retrieve rows for a table from the server a row at a time rather than retrieving the entire row set and buffering it in memory before writing it out.

该选项用于转储大的表。它强制mysqldump 从服务器一次一行地检索表中的行而不是检索所有行并在输出前将它缓存到内存中。