1.主从复制的主库
2.主从复制的从库
3.组复制
- 1.START GROUP REPLICATION
- 2.STOP GROUP REPLICATION

1.主从复制的主库

1.purge binary logs

PURGE { BINARY | MASTER } LOGS {
    TO 'log_name'
  | BEFORE datetime_expr
}

purge binary logs 删除指定binlog日志 BINARY跟MASTER是同义词。清楚binary log需要BINLOG ADMIN权限。如果没有开启binlog，那么purge语句将无效。
常用的例子：

PURGE BINARY LOGS TO 'mysql-bin.010';
PURGE BINARY LOGS BEFORE '2019-04-02 22:46:26';

如果有一个活跃的从库，上面两个语句不会删除那些正在应用的binlog，也不会删除正在应用之后的binlog。只会删除已经应用了的binlog。但是如果从库没有连接到主库，然后删除了binlog，那么之后从库连上了也不会进行复制。
在有主从复制中为了安全的删除binlog，可以遵循以下规则：
1/在每个从库上，SHOW SLAVE STATUS;
2/在主库上执行show binary logs;
3/选择要删除的时间点或者文件
4/备份要删除的binlog
5/执行语句删除

使用expire_logs_days可以自动删除binlog，但是如果有延迟复制，那么这个值应该大于延迟的天数。

如果在删除的时候报错了，可能是index文件被删除了，可以把所有的binlog写进去就可以删除了。

2.reset master

reset master 需要RELOAD权限。
当binlog开启时(log-bin=on)，使用reset master 语句将会删除所有的binlog，清空binlog index文件。
当gtid开启时(gtid_mode=on),使用reset master语句将会清空gtid执行记录。gtid_purged的值会是空字符串，全局gtid_executed的值是空字符串，会话端gtid_executed的值未知。mysql.gtid_executed表会被清空。

reset master 与purge binary log 的区别：
1/reset master 会删除所有记录在index文件的binlog，会留一个空的binlog以000001结尾的binlog，但是purge binary log不会留。
2/reset master 不能在从库运行时执行，但是purge binary log可以。

reset master 的作用：
一般建立好主从时，会建两条测试数据，来验证主从是否同步。
在那之后，stop slave，然后reset slave，然后在主库reset master，就是一个新的环境。

3.sql_log_bin

SET sql_log_bin = {OFF|ON}

sql_log_bin控制了是否将当前会话记录到binlog(假设log-bin=on).
如果针对当前会话，不想将变化复制到从库，可以将sql_log_bin设置为off。
当这个值设为off时，将会阻止gtid分配事务id，如果使用了gtids的主从，那么这段时间内的事务将会丢失。
全局sql_log_bin变量只读，不能修改，将在以后的版本删除。

2.主从复制的从库

1.change master to

CHANGE MASTER TO option [, option] ... [ channel_option ]

option: {
    MASTER_BIND = 'interface_name'
  | MASTER_HOST = 'host_name'
  | MASTER_USER = 'user_name'
  | MASTER_PASSWORD = 'password'
  | MASTER_PORT = port_num
  | MASTER_CONNECT_RETRY = interval
  | MASTER_RETRY_COUNT = count
  | MASTER_DELAY = interval
  | MASTER_HEARTBEAT_PERIOD = interval
  | MASTER_LOG_FILE = 'source_log_name'
  | MASTER_LOG_POS = source_log_pos
  | MASTER_AUTO_POSITION = {0|1}
  | RELAY_LOG_FILE = 'relay_log_name'
  | RELAY_LOG_POS = relay_log_pos
  | MASTER_SSL = {0|1}
  | MASTER_SSL_CA = 'ca_file_name'
  | MASTER_SSL_CAPATH = 'ca_directory_name'
  | MASTER_SSL_CERT = 'cert_file_name'
  | MASTER_SSL_CRL = 'crl_file_name'
  | MASTER_SSL_CRLPATH = 'crl_directory_name'
  | MASTER_SSL_KEY = 'key_file_name'
  | MASTER_SSL_CIPHER = 'cipher_list'
  | MASTER_SSL_VERIFY_SERVER_CERT = {0|1}
  | MASTER_TLS_VERSION = 'protocol_list'
  | IGNORE_SERVER_IDS = (server_id_list)
}

channel_option:
    FOR CHANNEL channel

server_id_list:
    [server_id [, server_id] ... ]

change master to 语句需要super 权限。
change master to 语句用来修改连接到主从复制的主库的信息。
在5.7.4之前执行change master to语句时需要stop slave，5.7.4之后，可以在主从复制的时候使用该语句。当使用多线程复制时(slave parallel worker大于0)，停止复制可能在relay log执行事务时产生间隙，这会导致change master to语句失败，start salve until sql after mts gaps可以确保gaps都关闭。

FOR CHANNEL channel子句允许命名复制时使用哪个通道，如果有多个源，change master to时没有指定的话，会报错。

MASTER_HOST, MASTER_USER, MASTER_PASSWORD, MASTER_PORT提供了从库如何连接到主库的信息。
host可以时主机名，也可以是ip地址。5.5版本之后，如果host不给值，将会报错。
如果指定了password，那么也需要指定user，密码的长度需要小于32。5.7.5之前超过32位会隐式截取，5.7.5之后会报错。

MASTER_HEARTBEAT_PERIOD，MASTER_CONNECT_RETRY，MASTER_RETRY_COUNT这几个参数控制了从库怎样意识到自己已经断开与主库的连接以及重新连接。
slave_net_timeout系统变量指定了从库没有接收到数据或者心跳信息后多少秒后重新连接，默认是60s，5.7.7之前是3600s。默认情况下MASTER_HEARTBEAT_PERIOD的值是slave_net_timeout的一半。MASTER_CONNECT_RETRY表示重连的间隔时间，MASTER_RETRY_COUNT表示重连多少次。默认情况下MASTER_CONNECT_RETRY=60s，MASTER_RETRY_COUNT=86400，这两参数表明60天之内每隔60s重连一次。

MASTER_DELAY表示延迟多少秒应用relaylog，设置这个参数时需要停止SQL线程。
MASTER_BIND，如果服务器有多个网络接口，指定哪个接口去连接主库。
MASTER_LOG_FILE跟MASTER_LOG_POS表示从库应该从主库的哪个文件，哪个位置开始读取事件。如果指定了这两个当中的一个就不能指定MASTER_AUTO_POSITION参数了。如果不指定master_log_file,master_log_pos，那么默认值是master_log_file=’ ‘,master_log_pos=4;
MASTER_AUTO_POSITION=1，这个参数是在启用GTID的复制时才使用的，启用了这个参数就不能设置MASTER_LOG_FILE与MASTER_LOG_POS参数了。
IGNORE_SERVER_IDS表明了忽略的服务器ip，这个列表里的ip都不会复制到从库。

change master to 语句会隐式的执行commit语句。

2.MASTER_POS_WAIT

SELECT MASTER_POS_WAIT('source_log_file', source_log_pos [, timeout][, channel])

这是一个函数，用来判断给定的binlog有没有执行。

3.RESET SLAVE

RESET SLAVE [ALL] [channel_option]

channel_option:
    FOR CHANNEL channel

reset slave 用来重置从库，需要RELOAD权限，执行该语句之前需要停止从库的线程(stop slave)。会清空复制元数据库，清空所有的relay-log，开启一个新的relay-log。如果之前设置了延迟复制，也会将MASTER_DELAY设置为0。
reset slave 并不会清空gtid的执行历史，如果需要清空gtid的执行历史，需要reset master语句。
在组复制中，如果需要执行reset slave语句，当前的成员需要是OFFLINE状态，可以使用stop group replication语句来将组成员置为OFFLINE。
reset slave 并不会清空连接到主库的相关信息，例如host ，user，password等。如果master_info_repository=file，连接主库的信息会被保存在内存中，如果重启了，那么这些数据将会丢失。如果想要清空所有的信息包括连接信息，可以使用reset slave all语句。

4.START SLAVE

START SLAVE [thread_types] [until_option] [connection_options] [channel_option]

thread_types:
    [thread_type [, thread_type] ... ]

thread_type:
    IO_THREAD | SQL_THREAD

until_option:
    UNTIL {   {SQL_BEFORE_GTIDS | SQL_AFTER_GTIDS} = gtid_set
          |   MASTER_LOG_FILE = 'log_name', MASTER_LOG_POS = log_pos
          |   RELAY_LOG_FILE = 'log_name', RELAY_LOG_POS = log_pos
          |   SQL_AFTER_MTS_GAPS  }

connection_options:
    [USER='user_name'] [PASSWORD='user_pass'] [DEFAULT_AUTH='plugin_name'] [PLUGIN_DIR='plugin_dir']


channel_option:
    FOR CHANNEL channel

gtid_set:
    uuid_set [, uuid_set] ...
    | ''

uuid_set:
    uuid:interval[:interval]...

uuid:
    hhhhhhhh-hhhh-hhhh-hhhh-hhhhhhhhhhhh

h:
    [0-9,A-F]

interval:
    n[-n]

    (n >= 1)

START SLAVE 需要SUPER 权限，会隐式提交，如果不加任何其他参数，会开启IO跟SQL线程。

5.STOP SLAVE

STOP SLAVE [thread_types] [channel_option]

thread_types:
    [thread_type [, thread_type] ... ]

thread_type: IO_THREAD | SQL_THREAD

channel_option:
    FOR CHANNEL channel

3.组复制

1.START GROUP REPLICATION

开启组复制，需要SUPER权限，如果super_read_only=on，启动的成员如果是主，那么super_read_only将设置为off。

2.STOP GROUP REPLICATION

需要SUPER或者group_replication_admin权限，一旦关闭组复制，那么super_read_only将会被设置为on，防止数据写入。

Mysql

Replication Statement