延时从库应用场景：普通主从正常情况可以应对物理损坏，但无法应用逻辑损坏。例如: drop 和 delete 等操作。 延时从库可以应对这种逻辑损坏场景： 主库做了某项操

备份主库为了节省恢复的时间我们使用 xtrabackup 备份主库，然后拷贝到从库再将数据恢复到从库中 完整备份主库 bash # 备份 xtrabackup --defaults-file=/usr/local/mysql/etc/my.cnf -S /data/mysql/mysql.sock -u root -p --backup --target-dir=/data/backup 恢复主从复制 恢复从库数

环境准备准备两台服务器安装 MySQL 5.7, 参考 安装 MySQL 5.7 服务器列表 master: 10.10.1.11/24 slave1: 10.10.1.12/24 配置 MySQL配置基于 GTID 的主从复制需要启动 gtid 和 binlog 功能，具体配置如下 主库: my.cnf ini [client] port

安装 MySQL 5.7服务器列表 master: 10.10.1.2/24 slave1: 10.10.1.3/24 下载 MySQL bash root@db2:/usr/local/src# wget https://cdn.mysql.com/archives/mysql-5.7/mysql-5.7.28-linux-glibc2.12-x86_64.tar.gz root@db1:/usr/local/src# tar xzf mysql-5.7.28-linux-glibc2.12-x86_64.tar.gz -C /usr/local/ root@db1:/usr/local# ln -s /usr/local/mysql-5.7.28-linux-glibc2.12-x86_64/ /usr/local/mysql 环境准备 bash # 安装依赖 root@db1:/usr/local/mysql# apt-get install libaio1 # 创建程序用户 root@db1:/usr/local/mysql# useradd -r -s /sbin/nologin mysql # 创建数据目录 root@db1:/usr/local/mysql# mkdir -p

GTID 的概述是对一个已提交事务的编号，并且是全局唯一的编号 全局事物标识：global transaction identifieds。 GTID事物是全局唯一性的，且一个

slowlog 慢日志 作用记录 MySQL 运行过程运行过慢的语句，通过一个文本的文件记录下来。 帮助我们进行语句优化工作。 配置慢日志 bash root@db1:~# cat /usr/local/mysql/etc/my.cnf [mysqld] # 慢语句开关 slow_query_log = 1 # 慢日

mysqlbinlog 参数说明 -d, --database 指定截取日志的库名 --start-position 截取日志起始 position 号 --stop-position 截取日志最终 position 号 --start-datetime 截取日志开始时间 --stop-datetime 截取日志结束时间 --skip-gtids 不保留全局事务标识符； 而是让服务器

binlog 作用主要记录数据库变化(DDL,DML,DCL)性质的日志 用于数据恢复：如果你的数据库出问题了，而你之前有过备份，那么可以看日志文件，找出

information_schema 库 统计单表占用物理空间大小查询表: information_schema.tables 计算公式: 方法一: 单表占用空间大小 = AVG_ROW_LENGTH * TABLE_ROWS + INDEX_LENGTH 方法二: 单表占用空间大小 = DATA_LENGTH 示例: 查看 employees 库中 salaries 表的占用空

MyISAM 引擎默认是支持通过拷贝文件方式迁移数据，InnoDB 引擎不支持。 如果需要迁移 InnoDB 引擎数据可以先将数据表的引擎由 InnoDB 更改为 MyISAM。 也可以通