SQL 用于控制 Master 服务器的语句
本节讨论用于管理 master 复制服务器的 statements。
PURGE BINARY LOGS 语法
PURGE { BINARY | MASTER } LOGS {
TO 'log_name'
| BEFORE datetime_expr
}
binary log 是一组 files,包含有关 MySQL 服务器进行数据修改的信息。 log 包含一组二进制 log files 和一个索引文件
该PURGE BINARY LOGS
语句删除指定索引文件名或日期之前的日志索引文件中列出的所有二进制日志文件。 BINARY
并且MASTER
是同义词。删除的日志文件也将从记录在索引文件中的列表中删除,以便给定的日志文件成为列表中的第一个。
PURGE BINARY LOGS需要BINLOG_ADMIN特权。如果未使用--log-bin选项启动服务器以启用二进制 logging,则此语句无效。
例子:
PURGE BINARY LOGS TO 'mysql-bin.010';
PURGE BINARY LOGS BEFORE '2019-04-02 22:46:26';
BEFORE
variant 的datetime_expr
参数值应该为一个DATETIME
值('YYYY-MM-DD hh:mm:ss'
格式的 value)。
从站复制时,此语句可以安全运行。您无需停止它们。如果您有一个活动的从服务器,当前正在读取您要删除的日志文件之一,则此语句不会删除正在使用的日志文件或晚于该日志文件的任何日志文件,但会删除任何较早的日志文件。在这种情况下会发出警告消息。但是,如果未连接从属服务器,而您恰巧要清除尚未读取的日志文件之一,则从属服务器在重新连接后将无法复制。
要安全地清除二进制 log files,请遵循以下过程:
- 在每个从属服务器上,使用SHOW SLAVE STATUS检查它正在读取的 log 文件。
- 使用
SHOW BINARY LOGS
获取 master 服务器上的二进制 log files 列表。 - 确定所有从站中最早的日志文件。这是目标文件。如果所有从属服务器都是最新的,则这是列表中的最后一个日志文件。
- 对要删除的所有日志文件进行备份。(此步骤是可选的,但始终建议这样做。)
- 清除所有日志文件,但不包括目标文件。
您还可以将expirelogs_days系统变量设置为在给定天数后自动使二进制 log files 过期(请参阅第 5.1.7 节,“服务器系统变量”)。如果使用复制,则应将变量设置为不小于从属服务器可能落后于主服务器的最大天数。
当.index
文件中列出的二进制 log files 已通过其他方式(例如在 Linux 上使用rm)从系统中删除时,PURGE BINARY LOGS TO
和PURGE BINARY LOGS BEFORE
都会失败并显示错误。 (Bug#18199,Bug#18453)要处理此类错误,请手动编辑.index
文件(这是一个简单的文本文件),以确保它仅列出实际存在的二进制日志文件,然后再次运行失败的PURGE BINARY LOGS语句。
RESET MASTER 语法
RESET MASTER
警告
请谨慎使用此语句,以确保不会丢失任何所需的二进制 log 文件数据和 GTID 执行历史记录。
RESET MASTER
需要RELOAD特权。
对于启用了二进制日志记录(log_bin
is ON
)的服务器,RESET MASTER
删除所有现有的二进制日志文件并重置二进制日志索引文件,将服务器重置为开始二进制日志记录之前的状态。将创建一个新的空二进制日志文件,以便可以重新启动二进制日志记录。
对于正在使用 GTID 的服务器(gtid_mode是ON
),发出RESET MASTER
会重置 GTID 执行历史记录。 gtid_purged系统变量的 value 设置为空 string(''
),gtid_executed系统变量的 global value(但不是 session value)设置为空 string,mysql.gtid_executed
table 被清除(参见mysql.gtid_executed 表)。如果 GTID-enabled 服务器启用了二进制 logging,RESET MASTER
也会重置二进制 log,如上所述。请注意,RESET MASTER
是重置 GTID 执行历史记录的方法,即使 GTID-enabled 服务器是禁用 binary logging 的复制从站也是如此; RESET SLAVE
对 GTID 执行历史没有影响。有关重置 GTID 执行历史记录的更多信息,请参阅重置 GTID 执行历史记录。
RESET MASTER
与PURGE BINARY LOGS
两个方面的影响不同:
RESET MASTER
删除 索引文件中列出的所有二进制日志文件,仅留下一个数字后缀为.000001
的空二进制日志文件,而编号不会被PURGE BINARY LOGS
重置 。- 在任何复制从属程序运行时,不打算使用
RESET MASTER
。从属服务器正在运行时,何时使用RESET MASTER
的行为是不确定的(因此不受支持),PURGE BINARY LOGS
复制从属服务器在运行时可以安全地使用。
首次设置 master 和 slave 时,RESET MASTER
可以证明是有用的,这样您就可以按如下方式验证设置:
- 启动 master 和 slave,然后开始复制
- 在 master 上执行一些测试查询。
- 检查查询是否已复制到从属服务器。
- 当复制正确运行时,在从站上发出
STOP SLAVE
后跟RESET SLAVE
,然后验证从站上是否不再存在任何不需要的数据。 - 在 master 上发出
ESET MASTER
来清理测试查询。
在验证设置,重置主服务器和从服务器并确保没有测试后生成的不需要的数据或二进制日志文件保留在主服务器或从服务器上之后,您可以启动从服务器并开始复制。
SET sqllog_bin 语法
SET sql_log_bin = {OFF|ON}
该sql_log_bin
变量控制是否为当前会话启用到二进制日志的日志记录(假设二进制日志本身已启用)。默认值为ON
。要为当前会话禁用或启用二进制日志记录,请将会话sql_log_bin
变量设置为 OFF
或ON
。
将此变量设置为OFF
以便 session 临时禁用二进制 logging,同时更改 master,您不希望将其复制到从属。
设置此系统变量的 session value 是受限制的操作。 session 用户必须具有足以设置受限 session 变量的权限。
无法在 transaction 或子查询中设置sqllog_bin的 session value。
此变量设置为OFF
可防止将 GTID 分配给二进制 log 中的 transactions。如果您正在使用 GTID 进行复制,这意味着即使稍后再次启用 binary logging,从此处写入 log 的 GTID 也不会考虑同时发生的任何 transactions,因此实际上这些 transactions 都会丢失。
global sqllog_bin变量是只读的,不能修改。 global 范围已弃用,将在未来的 MySQL 版本中删除。
用于控制从服务器的SQL语句
CHANGE MASTER TO Statement
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 = 'master_log_name'
| MASTER_LOG_POS = master_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 REPLICATION FILTER 语法
CHANGE REPLICATION FILTER filter[, filter][, ...]
filter:
REPLICATE_DO_DB = (db_list)
| REPLICATE_IGNORE_DB = (db_list)
| REPLICATE_DO_TABLE = (tbl_list)
| REPLICATE_IGNORE_TABLE = (tbl_list)
| REPLICATE_WILD_DO_TABLE = (wild_tbl_list)
| REPLICATE_WILD_IGNORE_TABLE = (wild_tbl_list)
| REPLICATE_REWRITE_DB = (db_pair_list)
db_list:
db_name[, db_name][, ...]
tbl_list:
db_name.table_name[, db_table_name][, ...]
wild_tbl_list:
'db_pattern.table_pattern'[, 'db_pattern.table_pattern'][, ...]
db_pair_list:
(db_pair)[, (db_pair)][, ...]
db_pair:
from_db, to_db
MASTER_POS_WAIT()语法
SELECT MASTER_POS_WAIT('master_log_file', master_log_pos [, timeout][, channel])
RESET SLAVE 语法
RESET SLAVE [ALL] [channel_option]
channel_option:
FOR CHANNEL channel
SET GLOBAL sql_slave_skip_counter 语法
SET GLOBAL sql_slave_skip_counter = N
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)
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
用于控制 Group 复制的 SQL Statements
START GROUP_REPLICATION 语法
START GROUP_REPLICATION
在此服务器实例上启动 Group Replication。此语句需要超特权。如果super_read_only=ON且成员应作为主要成员加入,一旦 Group Replication 成功启动,super_read_only
设置为OFF
。
STOP GROUP_REPLICATION 语法
STOP GROUP_REPLICATION
警告
请谨慎使用此语句,因为它会从 group 中删除服务器实例,这意味着它不再受 Group Replication 的一致性保证机制的保护。为了完全安全,请确保在发出此语句之前,applications 不再能够连接到实例,以避免任何过时读取的可能性。