已索引对 VC 的管理，主要通过 5480 端口来实现，凡是涉及 VC 的管理，都可以优先考虑通过这个来实现。可以使用 root 用户登录，也可以使用 VC 管理用户登录。SSH 服务的开启与关闭在“访问”菜单里。防火墙配置也可以在这个界面里配置。
已索引以删除 $GRID_BASE/diag/rdbms/_mgmtdb/-MGMTDB/incident/ 下的目录为例。11.2 以及之前的版本，需要手工删除这个目录下的内存。11.2 以上的版本，可以用 adrci 来处理。$ su - grid $ adrci ADR base = "/opt/cluster/grid" adrci> HELP [command] adrci> show homes adrci> set homepath diag/rdbms/_mgmtdb/-MGMTDB adrci> purge -age 0 <--- 删除所有 incident adrci> purge -age 30 <--- 删除30分钟之前的 incident adrci> purge -i <incident_id> <--- 删除特定 incident ID 的目录purge 命令可以通过 type 来指定清理的类型：-type {ALERT|INCIDENT|TRACE|CDUMP|HM|UTSCDMP}
已索引中间件概念的引入古代人们自己将钱财从一地传送到另一地时，不得不面对很多困难，例如土匪强盗、饮食住宿、车马挑夫、过关文书等共性问题。镖局这一中间角色的出现，使人们不必处理财物传输时的各种复杂细节。中间件的功能与此类似：中间件，运行于操作系统、数据库与应用软件之间可以简化应用软件的复杂性、克服网络环境多种挑战的一类系统软件。应用软件A <——> 中间件 <——> 底层资源（数据库、操作系统、网络）应用软件A <——> 中间件 <——> 应用软件B通道——保障系统消息的可靠传递桥梁——达成业务系统的互联互通框架——促成业务系统的完整集成平台——实现分布式应用的顺利部署中间件的作用开发效率能够提高开发效率，开发周期缩短25%~50%。软件质量层次明晰，可插拔方式对接，保障软件质量。节约成本据统计，应用系统可节省系统资源75%，运行成本减少50%。运行环境屏蔽底层硬件和软件运行环境带来的差异性，在异构平台间稳定运行。基于不同指令集的CPUARM：鲲鹏，飞腾MIPS：龙芯X86：天津海光（AMD），兆芯（VIA）ALPHA：申威不同数据库国内主流数据库：达梦、人大金仓、神州通用、瀚高、优炫国外主流数据库：Oracle，IBM，Mysql等开源：openGauss，PostgreSQL，MariaDB不同的操作系统发行版本麒麟、统信、Redhat、SUSE……中间件国产化替代必要性基础软硬件是关键核心技术。中间件：基础软件三驾马车之一。网络环境下处于操作系统、数据库等系统软件和应用软件之间的一种起连接作用的分布式软件主要解决异构网络环境下分布式应用软件的互连与互操作问题提供标准接口、协议，屏蔽实现细节，提高应用系统易移植性中间件在整合系统的过程中屏蔽底层技术细节应用中间件 屏蔽底层的技术差异（CPU/OS等）消息中间件消息要求可靠性，实时性，定制化需求高，通过IBM MQ/东方通消息中间件TongLINKQ/Kafka等数据库表交换信息 一般大量结构化数据、实时或非实时需求，通过ETL/CDC/数据交换平台等文件共享非机构化数据，半结构化数据，需要脱耦合等场景，通过FTP/RSYNC/NAS/通用文件传输平台服务接口 实时性要求高，数据量少，数据拥有方对于数据比较敏感等，通过ESB/API网关等其他方式 如线下，邮件等方式大型机构通常有消息交换、库表交换、文件交换、服务接口交换等，经常混合使用！东方通中间件产品及全替代能力东方通中间件产品东方通产品对标/替换国外产品备注应用中间件TongWebWAS、Weblogic、Tomcat、Jboss、Glassfish等XC目录、基础软件，支持容器云版/嵌入版，全行业海量替换案例消息中间件TongLINK/QIBM MQ功能完善、性能优越，国内领先，全行业应用，出货量30万+套交易中间件TongEASYOracle Tuxedo、IBM CICS金融、运营商、社保等行业核心交易系统应用分布式数据缓存TongRDSRedis成功应用在运营商、金融等行业业务系统中高速传输平台TongHTPKafka、RocketMQ、RabbitMQ等支持万级并发的接入与可靠传输、亿级消息堆积能力负载均衡TongTHSApache、Nginx等负载均衡软件，支持万级并发接入服务总线TongESBIBM ESB、Oracle ESB等基于SOA，易用、易管的服务集成框架，政务、电信、企业等领域应用系统集成数据集成TongETLInformatica、IBM DataStage、Oracle Data Integration 等数据集成工具，全行业替换文件传输TongGTP/WTPIBM Sterling Connect:Direct 、开源FTP可管理文件传输平台，金融领域市占率遥遥领先数据交换平台TongDXP国外无相关产品打破数据孤岛，国家级平台、15+省级平台等大量应用东方通应用服务器中间件TongWebTongWeb 属于应用服务器中间件，是东方通的明星产品。同类中间件有weblogic、websphere(WAS)、tomcat、jboss等。应用服务器是现在使用最广的中间件，主要应用于Web系统，它是创建、部署、运行、集成和维护多层分布式企业级应用的平台。Web应用位于客户端(浏览器)和数据库之间把业务逻辑(应用)“暴露”给客户端为业务逻辑(应用)提供运行平台和系统服务管理对数据库的访问应用服务器为Web系统下的应用开发者提供开发工具和运行平台企业级应用服务器通过Web容器和EJB容器为上层应用的运行提供基础平台支撑。TongWeb 版本选择 企业版安全版标准版轻量版容器云版嵌入式版适用场景大型复杂应用环境更高安全级别环境，内置ASDP安全插件中小型应用环境资源占用及启动速度要求较高的应用环境Docker、k8s环境SpringBoot/Cloud环境规范支持Java EE 7Java EE 7Java EE 7Java EE 7(Web)Java EE 8(Web)Java EE 8(Web)后台管理支持支持支持支持(仅命令)不支持不支持硬件集群支持支持支持支持支持支持软件集群(F5、Array等)支持支持支持支持支持支持session复制(TongHttpServer、Apache、Nignx等)支持支持不支持不支持不支持不支持
已索引TongWeb 安装部署要点：安装目录、端口确认、授权详细安装步骤可参考: 002_TongWeb7产品简介及安装指南pdf安装 JDK (前提条件)支持JDK的主流操作系统都可以安装。要求JDK7至JDK17（TongWeb7.0最新版）。一定要配置JAVA_HOME。建议使用普通用户安装。环境变量： export JAVA_HOME=/usr/local/jdk export PATH=$JAVA_HOME/bin:$PATH export CLASSPATH=.:$JAVA_HOME/lib/dt.jar:$JAVA_HOME/lib/tools.jar # java -version java version "1.8.0_201" Java(TM) SE Runtime Environment (build 1.8.0_201-b09) Java HotSpot(TM) 64-Bit Server VM (build 25.201-b09, mixed mode)通用机-绿色版安装（目前生产环境安装绿色版）直接解压缩即完成安装(推荐)。[tongweb@demo1 ~]$ ls license.dat TongWeb7.0.4.9_Enterprise_Linux.tar.gz [tongweb@demo1 ~]$ tar zxvf TongWeb7.0.4.9_Enterprise_Linux.tar.gz [tongweb@demo1 ~]$ ln -s TongWeb7.0.4.9_Enterprise_Linux tongweb [tongweb@demo1 ~]$ mv license.dat tongweb <--- 安装License，将产品光盘中的license.dat文件复制到TongWeb安装根目录下即可通用机- Windows平台直接执行Install_TW7.x.xx Standard_Windows.exe通用机- Unix/Linux平台图形安装命令 ./Install_TW7.x.x.x_Standard.bin字符安装命令 ./Install TW7.x.x.x Standard.bin -i consoleTongWeb安装-专用机-正式签名1、确定操作系统时间确定时间应为当前时间 (root用户)2、登安全用户将签名文件拷贝到桌面(secadm用户)3、导入正式签名g7文件运行“配置管理”，点击“添加”-浏览文件，选中并点击“打开”-最后提示“添加成功"4、登录root用户将对应平台的安装包文件(rpm或者deb文件)拷贝到桌面5、导入正式安装包运行配置管理-点击“添加”，选择安装包，点击“打开等待一段时间后，提示成功则完成导入6、登录root用户7、安装正式安装包配置管理列表页中选择刚添加成功的TongWeb后的“安装”按钮安装过程根据不同硬件平台速度不一样，等待一段时间安装成功后TongWeb会被安装到固定目录/opt (所有通过配置管理安装的软件都安装在这个目录下)，即/opt/TongWeb8、安装授权文件将license.dat (文件名称必须完全一致) 拷贝到/opt/TongWebTongHttpServer 安装部署# mkdir -p /usr/local/TongHttpServer-6.0.1.2 # cd /usr/local/TongHttpServer-6.0.1.2 # 将安装包TongHttpServer_6.0.1.2_*.tar.gz 上传到该目录 # tar zxvf TongHttpServer_6.0.1.2_*.tar.gz # /usr/local # ln -s TongHttpServer-6.0.1.2 TongHttpServer # cd /usr/local/TongHttpServer/THS # 将授权文件license.dat放到该目录 # chown -R user.group /usr/local/TongHttpServer*TongTHS 可以用 root 身份来启动，也可以用普通身份来启动。如果 TongTHS 目录已经修改为普通用户身份，用普通用户身份启动 Console 和服务后，所有相关进程的用户都是普通用户。如果 TongTHS 目录没有修改为普通用户身份，则用 root 身份启动 Console 和服务后，Console 和 master process的用户是 root，worker process 的用户是 nobody。由于多数情况下业务目录都是放在业务用户的家目录下，此时将会出现权限问题，访问业务目录将报错，可以将 conf/httpserver.conf 文件开始的 user 指令来指定 worker process 的运行身份为业务用户。THS 控制台是管理 THS 的 Web 界面。可以开启，也可以不开启。如果不用控制台，就通过脚本 start.sh [start|stop|reload] 来启停 httpserver。如果启用了控制台，在控制台首页可以对 httpserver 服务进行启停等操作。其实质也是调用 bin/httpserver 二进制文件，读取的配置文件是 conf/httpserver.conf。开启 THS 控制台：$ cd /usr/local/TongHttpServer/THS/bin; sh startConsole.sh [stop]访问 THS 控制台：http://ip:8000默认用户名：admin，默认密码：Ths#123.com，登录后修改密码。TongRDS 安装部署控制台安装# mkdir -p /usr/local/TongRDS-2.2.1.6-P1 # cd /usr/local/TongRDS-2.2.1.6-P1 # wget http://192.32.2.17/soft/MIDWARE/TongWeb/RDS2216p1/TongRDS-2.2.1.6_P1.Console.tar.gz # tar zxvf TongRDS-2.2.1.6_P1.Console.tar.gz # cd /usr/local # ln -s TongRDS-2.2.1.6-P1 TongRDS启动控制台：# cd /usr/local/TongRDS/console/bin; sh console.sh start [stop]访问控制台。使用http://ip:8083访问控制台。默认用户名：admin 默认密码：admin123，登录后修改密码。上传授权:控制台首页 > 基础信息 > 授权信息 > 更新授权信息，将授权文件上传。上传版本安装包：进行管理单节点部署配置中心服务：进行管理 > 新增 > 现有条目点击安装包 > 新增，选择包类型和上传相应的文件即可。中心节点：TongRDS-2.2.1.6_P1.MC.tar.gzexporter节点：TongRDS-2.2.1.6_P1.Exporter.tar.gz服务节点：TongRDS-2.2.1.6_P1.Node.tar.gz代理节点：TongRDS-2.2.1.6_P1.Proxy.tar.gz配置节点管理器：进行管理 > 新增，下拉选择InnerManager[x.x.x.x]节点名称：Center_Node节点地址x.x.x.x、服务端口 6300、管理端口 8086保持默认，完成后启动该节点至此，单节点安装完成。哨兵模式如果需要配置哨兵模式，方法如下。RDS 管理 >节点管理器 > 新增，填写IP地址，管理模式选择“SSH联机”，输入连接的用户名和密码，测试连接通过后，点击“保存并安装”。按此方法，将另外两台增加进来。完成后，包括管理节点在内一共3台。哨兵组管理 > 新增，名称 sentinelgrp，在哨兵节点列表，新增，加三个节点加进来。节点管理器，下拉选择, 节点名称格式：st_192_32_30_57RDS 服务 > 新增，哨兵主从服务名称 rdssrv，选择哨兵组服务节点列点，新增，节点名称格式：srv_192_32_30_57目前我们统一用 ID10 做主节点。建议配置认证。
dexp/dimp 工具名称有两种写法 dexp/dimp 和 dexpdp/dimpdp，两者语法完全相同。唯一的区别在于，dexp/dimp 导出/导入的文件必须存放在客户端，dexpdp/dimpdp 导出/导入的文件必须存放在服务器端。为了避免字符集焦虑，建议将操作终端(xshell)和操作系统（$LANG）的字符集均设置成数据库的字符集（通常为UTF8）。逻辑导出和逻辑导入数据库对象分为四种级别：数据库级、用户级、模式级和表级。四种级别独立互斥，不能同时存在。数据库级（full=y）：导出或导入整个数据库中的所有对象。用户级（owner=XXX）：导出或导入一个或多个用户所拥有的所有对象。模式级（schemas=XXX）：导出或导入一个或多个模式下的所有对象。表级（tables=XX）：导出或导入一个或多个指定的表或表分区。$ dexp userid=sysdba/Dameng123:5236 directory=/dmdb/expimp file=full.dmp full=y log=dexp_`date +"%F-%H-%M"`.log $ dimp userid=sysdba/Dameng123:5238 directory=expimp file=full.dmp full=y log=dimp_`date +"%F-%H-%M"`.log老版本使用直接路径，新版已经不支持直接路径了，需要使用目录对象。SQL> create directory expimp as '/orabak';如果密码有特殊字符，可以用如下的写法：userid='sysdba/"特殊密码"':25236也支持 REMAP，示例如下:REMAP_SCHEMA=DMHR:DMTESTremap_tablespace=DEMOTBS:DEMO_TBS如果 exclude 里面要排查多张表，只需要写一下 TABLES 关键字就行，例如 exclude = TABLES:T1,T2,T3....如果只想导表结构，达梦没有 CONTENTS 选项，使用 rows=n （表示不导出行）来实现。也可以使用 manager 来操作，要操作某个对象，就在某个对象上右击即可。
已索引问题描述脱敏平台创建了一个用户 datamask 专门用来跑脱敏任务，该用户拥有 DBA 角色。脱敏系统的思路是从生产备库获取 DDL 语句后，在目标库建表等，然后执行 insert 语句。但使用 datamask 或者 SYS 为业务用户 appuser 创建物化视图时报权限不足的错误。SQL> create materialized view appuser.demot_v as select * from appuser.demot;ORA-01031: insufficient privileges.将 create materialized 权限分配给脱敏用户或者业务用户均可，但无论采用哪种方式，都需要给业务用户显式分配 create table 权限。方法一：将 create materialized 分配给脱敏用户创建业务用户：SQL> create user appuser identified by appuser;SQL> grant connect,resource,create view to appuser;SQL> connect appuser/appuserSQL> create table demot as select * from user_objects;创建脱敏系统用户：SQL> connect / as sysdbaSQL> create user datamask identified by datamask;SQL> grant dba to datamask;尝试创建物化视图（报错）：SQL> connect datamask/datamaskSQL> create materialized view appuser.demot_v as select * from appuser.demot;create materialized view appuser.demot_v as select * from appuser.demot *ERROR at line 1:ORA-01031: insufficient privileges分配 create materialized 权限：SQL> connect / as sysdbaSQL> grant create materialized view to datamask;尝试创建物化视图（报错）：SQL> connect datamask/datamaskSQL> create materialized view appuser.demot_v as select * from appuser.demot;create materialized view appuser.demot_v as select * from appuser.demot *ERROR at line 1:ORA-01031: insufficient privileges给业务用户分配 create table 权限：SQL> connect / as sysdbaSQL> grant create table to appuser;尝试创建物化视图（成功）：SQL> create materialized view appuser.demot_v as select * from appuser.demot;Materialized view created.方法二：将 create materialized 分配给业务用户创建业务用户：SQL> create user appuser identified by appuser;SQL> grant connect,resource,create view to appuser;SQL> connect appuser/appuserSQL> create table demot as select * from user_objects;创建脱敏系统用户：SQL> connect / as sysdbaSQL> create user datamask identified by datamask;SQL> grant dba to datamask;尝试创建物化视图（报错）：SQL> connect datamask/datamaskSQL> create materialized view appuser.demot_v as select * from appuser.demot;create materialized view appuser.demot_v as select * from appuser.demot *ERROR at line 1:ORA-01031: insufficient privileges分配 create materialized 权限：SQL> connect / as sysdbaSQL> grant create materialized view to appuser;尝试创建物化视图（报错）：SQL> connect datamask/datamaskSQL> create materialized view appuser.demot_v as select * from appuser.demot;create materialized view appuser.demot_v as select * from appuser.demot *ERROR at line 1:ORA-01031: insufficient privileges给业务用户分配 create table 权限：SQL> connect / as sysdbaSQL> grant create table to appuser;尝试创建物化视图（成功）：SQL> connect datamask/datamaskSQL> create materialized view appuser.demot_v as select * from appuser.demot;Materialized view created.
主从搭建1.创建主库，my.cnf 模版已经打开了相关关键参数准备主库# rm /opt/database/3306/auto.cnf mysql> create user 'repl'@'主库IP' identified by 'xxx'; mysql> create user 'repl'@'从库IP' identified by 'xxx'; mysql> grant REPLICATION SLAVE ON *.* TO 'repl'@'主库IP'; mysql> grant REPLICATION SLAVE ON *.* TO 'repl'@'从库IP'; alter user 'root'@'localhost' identified by 'xxx'; 3.备份主库如果存储引擎都支持事务：mysqldump -u root -p --single-transaction -A -B --master-data=2 > /opt/database/alldb.sql-- master-data=2 是之前没有使用 GTID 时的方法，可以保留，但实际上不会用到。如果有不支持事务的存储引擎：mysqldump -u root -p -A -B -x --events --master-data=2 > /xxx-x 会在备份过程中锁表如果使用 mydumper 进行备份恢复，其产生的 metadata 文件示例如下：Started dump at: 2019-12-25 09:24:41 SHOW MASTER STATUS: Log: bin.000009 Pos: 453 GTID:0e7c2f36-ca06-11e9-bdf8-000c291ca865:1 Finished dump at: 2019-12-25 09:24:414.准备从库# rm -f /opt/database/3306/auto.cnf # vim /etc/my.cnf server-id = 22 read_only = 1 # /etc/init.d/mysqld start mysql> alter user 'root'@'localhost' identified by 'xxx'; < --- 将备库 root 密码修改为主库一致5.恢复数据库并配置主从关系如果是 mydumper 备份，需要配置跳过 GTID，执行这一步的作用是表明这儿的GTID已经在备份中包含了，不需要在 slave 上重做了。如果是通过 mysqldump 进行的备份，跳过该步骤，在备份文件中会自动包含 SET 命令。mysql> SET @@GLOBAL.GTID_PURGED='0e7c2f36-ca06-11e9-bdf8-000c291ca865:1'; ERROR 1840 (HY000): @@GLOBAL.GTID_PURGED can only be set when @@GLOBAL.GTID_EXECUTED is empty. mysql> reset master; mysql> SET @@GLOBAL.GTID_PURGED='0e7c2f36-ca06-11e9-bdf8-000c291ca865:1';# mysql -uroot -p < alldb.sql ERROR 1840 (HY000) at line 24: @@GLOBAL.GTID_PURGED can only be set when @@GLOBAL.GTID_EXECUTED is empty. mysql> reset master; mysql> reset slave; # mysql -uroot -p < alldb.sql mysql> change master to master_host="主库IP",master_port=3306,master_user='repl',master_password='xxx',master_auto_position=1; 以前都是通过 master_log_file 和 master_log_pos 来定位，引入 GTID 后，使用 master_auto_position 自动定位 mysql> start slave; mysql> show slave status\G查看从库状态：mysql> show slave status\G *************************** 1. row *************************** Slave_IO_State: Master_Host: 192.168.111.128 Master_User: repl Master_Port: 3306 Connect_Retry: 60 Master_Log_File: bin.000001 <-- change master中的filename Read_Master_Log_Pos: 585 <-- change master中的pos Relay_Log_File: object-relay-bin.000001 Relay_Log_Pos: 4 Relay_Master_Log_File: bin.000001 Slave_IO_Running: No <-- 目前slave还未运行，所以是No Slave_SQL_Running: No <-- 目前slave还未运行，所以是No 开启同步mysql> start slave;查看从库状态：mysql> show slave status\G *************************** 1. row *************************** Slave_IO_State: Waiting for master to send event <-- IO 线程的状态 Master_Host: 192.168.111.128 Master_User: repl Master_Port: 3306 Connect_Retry: 60 Master_Log_File: bin.000001 <-- IO线程读取到的文件 [The name of the source binary log file from which the I/O thread is currently reading.] Read_Master_Log_Pos: 585 <-- IO线程读取文件中的位置 Relay_Log_File: object-relay-bin.000003 Relay_Log_Pos: 314 Relay_Master_Log_File: bin.000001 <-- SQL线程执行到的文件 [The name of the source binary log file containing the most recent event executed by the SQL thread.] Slave_IO_Running: Yes <-- IO 线程正在运行 Slave_SQL_Running: Yes <-- SQL 线程正在运行 Replicate_Do_DB: Replicate_Ignore_DB: Replicate_Do_Table: Replicate_Ignore_Table: Replicate_Wild_Do_Table: Replicate_Wild_Ignore_Table: Last_Errno: 0 Last_Error: Skip_Counter: 0 Exec_Master_Log_Pos: 585 <-- SQL线程执行到文件的位置 [The position in the current source binary log file to which the SQL thread has read and executed] Relay_Log_Space: 522 Until_Condition: None Until_Log_File: Until_Log_Pos: 0 Master_SSL_Allowed: No Master_SSL_CA_File: Master_SSL_CA_Path: Master_SSL_Cert: Master_SSL_Cipher: Master_SSL_Key: Seconds_Behind_Master: 0 <-- Slave 落后 Master 的秒数 Master_SSL_Verify_Server_Cert: No Last_IO_Errno: 0 Last_IO_Error: <-- IO 线程相关的错误 Last_SQL_Errno: 0 Last_SQL_Error: <-- SQL 线程相关的错误 Replicate_Ignore_Server_Ids: Master_Server_Id: 128 Master_UUID: 0e7c2f36-ca06-11e9-bdf8-000c291ca865 Master_Info_File: /usr/local/mysql-5.7.23-linux-glibc2.12-x86_64/data/master.info SQL_Delay: 0 SQL_Remaining_Delay: NULL Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates Master_Retry_Count: 86400 Master_Bind: Last_IO_Error_Timestamp: Last_SQL_Error_Timestamp: Master_SSL_Crl: Master_SSL_Crlpath: Retrieved_Gtid_Set: Executed_Gtid_Set: Auto_Position: 0 Replicate_Rewrite_DB: Channel_Name: Master_TLS_Version: 1 row in set (0.00 sec)通过 show processlist 在主库可以看到 "Binlog Dump" 进程，在从库可以看到 IO 进程和 SQL 进程。如果在备库上开启了并行复制， 还可以看到 Coordinator 线程。关于 Seconds_Behind_MasterThis field is an indication of how “late” the replica is:• When the replica is actively processing updates, this field shows the difference between the current timestamp on the replica and the original timestamp logged on the source for the event currently being processed on the replica.• When no event is currently being processed on the replica, this value is 0.In essence, this field measures the time difference in seconds between the replica SQL thread and the replica I/O thread. If the network connection between source and replica is fast, the replica I/O thread is very close to the source, so this field is a good approximation of how late the replica SQL thread is compared to the source.Seconds_Behind_Master 字面意思为 Slave 落后 Master 的秒数，但是实际上并不是十分准确。其计算的方式为：Slave 的 SQL 线程执行时刻的时间减去 event 产生时刻的时间（event_header 中的前4个字节就是 timestamp）。Seconds_Behind_Master 测算主从延时的方式并不准确，因为回放的SQL线程可能落后很多。我们可以使用 Percona ToolKit 中的 pt-heardbeat 工具来计算主从之间的延时时间，其原理是：在 Master 节点上创建一个带有时间戳字段的表，pt-heartbeat --update 每隔一段时间写入时间戳，通过主从复制，将表中的内容（带有时间戳的记录）复制到 Slave 节点，在某台主机上运行 pt-heartbeat --monitor 连接到从服务器，使用本地时间戳减去复制到 Slave 节点的记录的时间戳，就可知道Slave落后Master的时间。主从复制的启停mysql> start slave; mysql> stop slave; mysql> stop slave io_thread; mysql> stop slave sql_thread;查看复制关系mysql> show slave hosts; +-----------+------+------+-----------+--------------------------------------+ | Server_id | Host | Port | Master_id | Slave_UUID | +-----------+------+------+-----------+--------------------------------------+ | 130 | | 3306 | 128 | b6c03287-15af-11ea-a20c-000c29e56203 | +-----------+------+------+-----------+--------------------------------------+ 1 row in set (0.00 sec)看到 HOST 字段为空，如果想能显示是哪一台主机，需要在 slave 的 my.cnf 中增加 report-host 配置，然后重启MySQL实例。[mysqld] report-host=192.168.111.130 <-- 指明 slave 的 IP 地址，这儿写什么，上面的 show 命令就显示什么如果想看到主从关系的拓扑图，可以使用第三方的 mysqlrplshow 工具。查看半同步状态（是否启用半同步复制）mysql> show global status like "%rpl%"; +--------------------------------------------+-------+ | Variable_name | Value | +--------------------------------------------+-------+ | Rpl_semi_sync_master_clients | 1 | <-- 连接的半同步复制的client数量 | Rpl_semi_sync_master_net_avg_wait_time | 0 | <-- master平均等待slave的时间，mysql-5.7.8 后被废弃 | Rpl_semi_sync_master_net_wait_time | 0 | <-- master总的等待slave的时间，mysql-5.7.8 后被废弃 | Rpl_semi_sync_master_net_waits | 1 | <-- master总的等待slave的次数 | Rpl_semi_sync_master_no_times | 1 | <-- 切成异步的次数（no = number of） | Rpl_semi_sync_master_no_tx | 1 | <-- 切成异步后提交的事务数 | Rpl_semi_sync_master_status | ON | <-- 当前半同步复制的状态（是否启用了半同步，如果超时切成了异步，这儿会显示 OFF） | Rpl_semi_sync_master_timefunc_failures | 0 | <-- master调用gettimeofday()函数失败的次数 | Rpl_semi_sync_master_tx_avg_wait_time | 0 | <-- master等待事务的平均时间 | Rpl_semi_sync_master_tx_wait_time | 0 | <-- master等待事务的总的时间 | Rpl_semi_sync_master_tx_waits | 0 | <-- master等待事务的次数 | Rpl_semi_sync_master_wait_pos_backtraverse | 0 | | Rpl_semi_sync_master_wait_sessions | 0 | | Rpl_semi_sync_master_yes_tx | 0 | | Rpl_semi_sync_slave_status | OFF | +--------------------------------------------+-------+ 15 rows in set (0.02 sec)引入 GTID 后的冲突处理场景：先在 slave 上插入一台记录，然后在主库插入一台相同主键的记录，此时，slave 的 SQL 线程会停止，状态信息中会报 1062 错误。开始 GTID 后，不能使用 sql_slave_skip_counter 参数来处理复制错误。下面是接收到的 GTID 和执行了的 GTID 信息： Retrieved_Gtid_Set: 0e7c2f36-ca06-11e9-bdf8-000c291ca865:2-3 Executed_Gtid_Set: 0e7c2f36-ca06-11e9-bdf8-000c291ca865:1-2, b6c03287-15af-11ea-a20c-000c29e56203:1可见，接收到了3，只执行到了2，如果主继续生产一个新的事务，仍会被接收，3会变成4，但2还是保持2。解决办法：将下一下要执行但是不能执行的事务设置为一个空事务，以此跳过该有问题的事务：set gtid_next='0e7c2f36-ca06-11e9-bdf8-000c291ca865:3'; begin; commit; set gtid_next='automatic'; start slave;多源复制要求：将 192.168.111.128 上的 demodb 和 192.168.111.130 上的 cydb 数据库都复制到 192.168.111.131 上面。场景：这种操作可以起到数据聚合的效果。将分库分表后的数据聚合在一起，以供其他应用进行分析（前提是数据不冲突）。思想：还是以前的方法，只是在做最后一步 change master 时要加上 for channel 的语法。1.将两个源库备份并在 slave 上还原。2.设定要复制的数据库名在 slave 上面设置需要复制的库，如果不设置的话，默认会同步系统的库（mysql），这样可能会复制出错（因为两个主库的mysql库中可能有相同的记录）。replicate_do_db=dbn1replicate_do_db=dbn23.配置主库信息mysql> change master to master_host="192.168.111.128", master_port=3306, master_user='rpl', master_password='rpl', master_auto_position=1 for channel 'demodb'; mysql> change master to master_host="192.168.111.130", master_port=3306, master_user='rpl', master_password='rpl', master_auto_position=1 for channel 'cydb';4.启动同步mysql> start slave [for channel 'demodb'];思考：如果192.168.111.130上面也有一个demodb库，会有什么问题？如果从库设置了 slave_skip_errors = ddl_exist_errors，且两个 demodb 没有重复数据，是没有问题的如果从没有设置 slave_skip_errors = ddl_exist_errors，或两个 demodb 有重复数据，就会报错删除复制关系（配置）stop slave; reset slave all;读写分离应用实现读写分离至少有两种方法：应用本身通过代码实现，例如基于动态数据源、AOP的原理来实现写操作时用主数据库，读操作时用从数据库。通过中间件的方式实现，例如通过Mycat，Mycat会“拦截”SQL进行分析，然后选择操作的数据库。SpringBoot整合读写分离（动态切换数据源）1.在项目中创建读数据源和写数据源2.将读数据源和写数据源注册到RoutingDataSource(会给各数据源绑定一个key)3.配置使用AOP技术拦截业务逻辑层方法，判断方法的前缀是否需要做读或者写。如果方法名称中是 get, select, count, list 等，使用读数据源，否则使用写数据源Mycat 实现读写分离官方网址：www.mycat.ioMycat——活跃的、性能好的分库分表开源数据库中间件！Mycat支持MySQL、SQL Server、Oracle、DB2、PostgreSQL 等主流数据库，也支持 MongoDB 这种新型 NoSQL 方式的存储，未来还会支持更多类型的存储。mycat类似于nginx，客户端访问mycat的IP和端口（8066），mycat将其转发给后端的DB服务器。Mycat是阿里的开源框架。其竞争对手是 sharding-jdbc。安装下载软件包，解压即可。export JAVA_HOME=/usr/local/jdk1.8.0_172export JRE_HOME=$JAVA_HOME/jreexport CLASSPATH=$JAVA_HOME/lib:$JAVA_HOME/jre/libexport PATH=$JAVA_HOME/bin:$PATHexport MYCAT_HOME=/usr/local/mycat # 非必须配置文件wrapper.conf：Mycat本身的配置文件server.xml：Mycat定义用户以及系统相关变量，如端口等schema.xml：Mycat虚拟数据库和物理数据库表的关系rule.xnl：Mycat分片(分库分表）规则读写分离配置示例数据库主从复制已经搭建完成，有一个业务用户 app，对数据库 demodb 有完全权限。主：192.168.111.128:3306从：192.168.111.130:33061.配置server.xml <user name="appcat"> <property name="password">appcat</property> <property name="schemas">TESTDB</property> <property name="readOnly">false</property> </user>其它保持默认，按如上所示修改文件最后的内容。这儿配置的用户名和密码是提供给客户端连接使用的，与数据库中真实存在的用户没有关系。这儿配置的数据库名 TESTDB 是虚拟的数据库名，与数据库服务器中的真实存在的数据库没有关系。2.配置schema.xml文件 <?xml version="1.0"?> <mycat:schema xmlns:mycat="http://io.mycat/"> <schema name="TESTDB" checkSQLschema="false" sqlMaxLimit="100" dataNode="cynode" /> <dataNode name="cynode" dataHost="cyhost" database="demodb" /> <dataHost name="cyhost" maxCon="1000" minCon="10" balance="3" writeType="0" dbType="mysql" dbDriver="native"> <heartbeat>select user()</heartbeat> <writeHost host="master" url="192.168.111.128:3306" user="app" password="app"> <readHost host="slave" url="192.168.111.130:3306" user="app" password="app" /> </writeHost> </dataHost> </mycat:schema>3.启动mycat# ./bin/mycat start # mysql -h127.0.0.1 -uappcat -pappcat -P9066 <-- 进入Mycat的管理端 mysql> show @@datasource; +----------+--------+-------+-----------------+------+------+--------+------+------+---------+-----------+------------+ | DATANODE | NAME | TYPE | HOST | PORT | W/R | ACTIVE | IDLE | SIZE | EXECUTE | READ_LOAD | WRITE_LOAD | +----------+--------+-------+-----------------+------+------+--------+------+------+---------+-----------+------------+ | cynode | master | mysql | 192.168.111.128 | 3306 | W | 0 | 1 | 1000 | 5 | 0 | 0 | | cynode | slave | mysql | 192.168.111.130 | 3306 | R | 0 | 4 | 1000 | 13 | 0 | 0 | +----------+--------+-------+-----------------+------+------+--------+------+------+---------+-----------+------------+ 2 rows in set (0.03 sec)4.客户端连接mysql -uappcat -pappcat -h192.168.111.133 -P8066然后进行读操作和写操作，观察上面的 READ_LOAD 与 WRITE_LOAD 值的变化。Sharding-JDBCApache ShardingSphere 是一套开源的分布式数据库中间件解决方案组成的生态圈，它由Sharding-JDBC、Sharding-Proxy和Sharding-Sidecar（规划中）这3款相互独立，却又能够混合部署配合使用的产品组成。它们均提供标准化的数据分片、分布式事务和数据库治理功能，可适用于如Java同构、异构语言、云原生等各种多样化的应用场景。Sharding-JDBC 和 DAO 是在同一个项目，在本地经过分片算法分片后，再发给DB服务器。Sharding-Jdbc是一个Jar形式，在本地应用层重写Jdbc原生的方法，实现数据库分片形式。MyCat属于服务器端数据库中间件，而Sharding-Jdbc是一个本地数据库中间件框架。实现读写分离原理：①需要在配置文件配置读写分离jdbc连接全部交给Sharding ②Sharding-Jdbc会自动判断SQL语句类型，然后获取主的jdbc连接配置或从的jdbc连接发送请求另外，一个小知识点了解一下，在Sharding-JDBC中，自增ID通过雪花算法实现。
已索引License 管理点击 Memu > System Administration > Licensing > Licenses 在 licenses 标签页，点击添加，就可以添加 License添加完成后：ESXi 的 License 显示为：vSphere 7 Enterprise PlusvCenter 的 License 显示为：vCenter Server 7 StandardLicense 添加完成后，还需要将其分配给相应的资产：点击 "Assets(资产)" 标签页，选择 VCENTER SERVER SYSTEMS/HOSTS/VSAN CLUSTER 等点击 "Assign License" 就可为相应的资产分配 Lisence 了SSL 证书管理SSL 证书有过期时间，如果过期，不影响业务，但会导致 VCentor 不能登录。要定期对证书进行续订：系统管理 > 证书 > 证书管理，找到对应的证书，点击“操作” > “续订”即可。修改 VC/VCentor 管理员帐号的密码过期时间系统管理 > Single Sign On > 配置，最长生命周期。默认是 90 天过期，0 表示永不过期。修改 vcsa 虚拟机 root 用户的密码过期时间登录 VC:5480，点击“系统管理” ，修改即可。Tag 管理定义了 tag 后，可以在搜索框中使用 tag 进行搜索。直接输入某个 tag 名后，就会把所有打了该 tag 的资产全部列出来。
已索引当某台 Hypervisor 主机重启时，往往伴随着几十台的虚拟机重启，此时，我们需要通知相关的应用系统运维人员去检查业务运行情况（建议不要统一完后再统一通知，最好边统计边通知），那如何找出 zabbix 告警过的主机呢？zabbix侧边栏 > 监测 > 问题点击“过滤器”，在“问题”栏输入告警标题的关键字，如“主机不可达”，其它根据实际情况选择性填写。点击“过滤器”左边的时间，选择最小化能覆盖告警的时间范围。然后点击“应用”即可。
已索引二进制日志的作用二进制日志(binlog)记录了对 MySQL 数据库执行更改的所有操作，但是不包括 SELECT 和 SHOW 这类操作，因为这类操作对数据库本身并没有修改。如果想记录 select 和 show 操作，只能使用查询日志。如果 UPDATE 操作没有引起数据库的变化，或者 select ... for update 语句是否会记录呢？姜承尧在 《MySQL技术内幕——InnoDB存储引擎》(第2版) P73 的例子里：update t set a = 1 where a = 2;返回该语句影响 0 行，但 binlog 日志里是有记录该语句的。但我在 mysql-5.7.44 和 mysql 8 里做实验时，binlog 日志里均未做记录。对于 mysql 这类特殊的数据库，也会产生二进制日志，但 information_schema 这类没有没有物理实体的库，则不会产生二进制日志。可以通过如下两种途径让特殊操作不产生日志：拥有 super 权限的用户，可以在执行操作前，先执行 set sql_log_bin=0; 命令通过 binlog_do_db 和 binlog_ignore_db 两个选项来控制哪些库产生或者不产生日志。默认都为空，表示都产生日志。总的来说，binlog 主要用来：恢复（recovery）、复制（replication）和审计（audit）。当然，我们还可以通过二进制日志来实现闪回功能（必须 是 ROW 格式），现在有很多基于 binlog 实现闪回功能的开源工具。 mysql 8 自带了闪回功能。二进制日志的开启我们在 my.cnf 模版文件中的配置如下：server-id = 11log_bin = bin.logshow variables 看到的值如下：+--------------------------------------------+------------------------------+ | Variable_name | Value | +--------------------------------------------+------------------------------+ | log_bin | ON | | log_bin_basename | /opt/database/3306/bin | | log_bin_index | /opt/database/3306/bin.index | +--------------------------------------------+------------------------------+生成的 binlog 文件名如下：bin.000001bin.000002可以用 log_bin 来指定 binlog 的路径和文件名，如果 log_bin 参数不指定，则文件名默认为 "主机名-bin.日志序号"，在 datadir 下。bin.index 文件为 binlog 的索引文件，用来存储过往产生的二进制日志序号，在通常情况下，不建议手动修改这个文件。binlog 日志如果不清理，文件编号6位满了后会变成7位。开户 binlog 确实会使数据库性能下降 1%（损失有限），但 binlog 带来了复制和不完全恢复，生产一定要打开。对于多实例环境，开启 binlog 需要同时指定 server-id。例如：环境：mysql-5.7.44-linux-glibc2.12-x86_64(RHEL 7.7)当前环境已经存在一个 3306 端口实例的情况下，下面的极简配置不能启动另外一个实例，且启动实例时 error 日志里没有任何成功或失败的记录。[mysqld] port = 3307 datadir = /opt/database/3307 socket = /tmp/mysql.sock.3307 log_bin = bin.log在上面的配置文件中加入 server-id = 22 后就可以成功启动了。binlog_format线上必须设置为 binlog_format = ROW。.STATEMENTROWMIXED说明记录操作的SQL语句记录操作的每一行数据混合模式优点易于理解数据一致性高、可flashback结合上述两种模式缺点不支持不确定SQL语句每张表一定要有主键之前版本bug较多线上使用不推荐推荐不推荐注意： balckhole 存储引擎不支持 ROW，NDB 存储引擎不支持 STATEMENT。姜：最开始是 STATEMENT，在 MySQL 5.1 之前没有这个参数。对于复制是有一定要求的。如在主服务器运行 rand、uuid 等函数，又或者使用触发器等操作，这些都可能会导致主从服务器上表中数据的不一致(notsync)。另一个影响是，会发现 InnoDB 存储引擎的默认事务隔离级别是REPEATABLEREAD。这其实也是因为二进制日志文件格式的关系，如果使用 READ COMMITTED 的事务隔离级别(大多数数据库，如 Oracle，Microsoft SQL Server 数据库的默认隔离级别)，会出现类似丢失更新的现象，从而出现主从数据库上的数据不一致。从 MySQL 5.1 开始有 3 种格式。5.6 有几个小版本是设置的 MIXED，从 5.7 版本开始，默认都设置为了 ROW。在 ROW 格式下，二进制日志记录的不再是简单的SQL语句了，而是记录表行更改情况。基于 ROW 格式的复制类似于 Oracle 的物理Standby。同时，对上述提及的 Statement 格式下复制的问题子以解决。从 MySQL5.1 版本开始，如果设置了 binlog_format 为 ROW，可以将 InnoDB 的事务隔离基本设为 READ COMMITTED，以获得更好的并发性。在 MIXED 格式下，MySQL 默认采用 STATEMENT 格式进行二进制日志文件的记录，但是在一些情况下会使用 ROW 格式，可能的情况有：1)表的存储引擎为 NDB，这时对表的 DML 操作都会以 ROW 格式记录。2)使用了 UUID()、USER()、CURRENT_USER()、FOUND_ROWS()、ROW_COUNT() 等不确定函数。3)使用了INSERT DELAY 语句。4)使用了用户定义函数(UDF)。5)使用了临时表(tcemporary table)。其实重要相关参数max_binlog_size：1073741824（1G）my.cnf 模版未对该参数进行调整，默认值即是最大值 1073741824（1G）。单个 binlog 文件的最大大小。binlog_cache_size: 32768my.cnf 模版未对该参数进行调整，默认 32K。此参数是基于会话的。The size of the cache to hold changes to the binary log during a transaction.对于非事务表来说，语句执行后就会立即写 binlog，对于事务表来说，未提交事务的 DML 操作日志会被缓存起来，事务提交时再写入 binlog，该缓存的大小由此参数定义，如果事务产生的记录大于缓存空间，则会使用一个临时文件来保存，事务结束后自动删除。如果经常使用大事务，就需要关注此参数是否设置合理，因为该参数是基于会话的，设置太大会消耗过多内存，设置太小又可能造成使用临时文件。最理想的状态是参数值越小越好，但不要使用临时文件。全局状态变量 Binlog_cache_use 和 Binlog_cache_disk use 可以用来判断该参数是否设置合理：mysql> show global status like 'binlog_cache%'; +-----------------------+----------+ | Variable_name | Value | +-----------------------+----------+ | Binlog_cache_disk_use | 560 | | Binlog_cache_use | 92764233 | +-----------------------+----------+ 2 rows in set (0.00 sec)Binlog_cache_use 显示了使用 binlog cache 的事务数，Binlog_cache_disk_use 则显示了使用临时文件的事务数。如果频繁使用到了临时文件，就应该特别引起关注。max_binlog_cache_sizemy.cnf 模版未对该参数进行调整，32位默认即是最大值4G，64位默认即是最大值 16777216PB，可以认为就是没有限制了。如果一个事务产生的 binlog 日志大于该值，事务会报错回滚。If a transaction requires more than this many bytes, the server generates a error：Multi-statement transaction required more than 'max_binlog_cache_size' bytes of storagesync_binlogControls how often the MySQL server synchronizes the binary log to disk.MySQL 写 binlog 就跟我们写文件一样，可能并没有真正落盘，我们有时为了真正落盘，操作系统提供了 sync 命令。sync_binlog 用来定义 binlog 真正落盘的策略。生产中该参数始终配置为1（最安全），5.7.7 及之后默认值也是1，可以不用过多去研究。sync_binlog=0: Disables synchronization of the binary log to disk by the MySQL server.Instead, the MySQL server relies on the operating system to flush the binary log to disk from time to time as it does for any other file. This setting provides the best performance, but in the event of a power failure or operating system crash, it is possible that the server has committed transactions that have not been synchronized to the binary log.sync_binlog=1: Enables synchronization of the binary log to disk before transactions areThis is the safest setting but can have a negative impact on performance due toincreased number of disk writes. In the event of a power failure or operating system crash,transactions that are missing from the binary log are only in a prepared state. This permits theautomatic recovery routine to roll back the transactions, which guarantees that no transaction islost from the binary log. 之前默认值是0，现在已经是1了。sync_binlog=N, where N is a value other than 0 or 1: The binary log is synchronized to diskafter N binary log commit groups have been collected. In the event of a power failure or operating system crash, it is possible that the server has committed transactions that have not been flushed to the binary log. This setting can have a negative impact on performance due to the increased number of disk writes. A higher value improves performance, but with an increased risk of data lossFor the greatest possible durability and consistency in a replication setup that uses InnoDB withtransactions, use these settings: (my.cnf 模版已经照此配置)• sync_binlog=1.• innodb_flush_log_at_trx_commit=1.Caution: Many operating systems and some disk hardware fool the flush-to-disk operation. They may tell mysqld that the flush has taken place, even though it has not. In this case, the durability of transactions is not guaranteed even with the recommended settings, and in the worst case, a power outage can corrupt InnoDB data. Using a battery-backed disk cache in the SCSI diskcontroller or in the disk itself speeds up file flushes, and makes the operation safer. You can also try to disable the caching of disk writes in hardware caches.innodb_support_xa该参数默认开启，从 MySQL 5.7.10 开启，不允许禁用，MySQL 8.0 移除了该参数。可以不用过多去研究。Enables InnoDB support for two-phase commit in XA transactions, causing an extra disk flush for transaction preparation. The XA mechanism is used internally and is essential for any server that has its binary log turned on and is accepting changes to its data from more than one thread. If you disable innodb_support_xa, transactions can be written to the binary log in a different order than the live database is committing them, which can produce different data when the binary log is replayed in disaster recovery or on a replica. Do not disable innodb_support_xa on a replication source server unless you have an unusual setup where only one thread is able to change data.innodb_support_xa is deprecated; expect it to be removed in a future MySQL release. InnoDBsupport for two-phase commit in XA transactions is always enabled as of MySQL 5.7.10. Disabling innodb_support_xa is no longer permitted as it makes replication unsafe and preventsperformance gains associated with binary log group commit.XA Distributed Transaction support is enabled by default. If you are not using this feature, you can disable the innodb_support_xa configuration option, avoiding the performance overhead of an extra fsync for each transaction.As of MySQL 5.7.10, disabling innodb_support_xa is not permitted as it makes replication unsafe and prevents performance gains associated with binary log group commit. The innodb_support_xa configuration option is removed in MySQL 8.0.The innodb_support_xa system variable, which enables InnoDB support for two-phase commitin XA transactions, is deprecated as of MySQL 5.7.10. InnoDB support for two-phase commit in XA transactions is always enabled as of MySQL 5.7.10.姜承尧 《MySQL技术内幕——InnoDB存储引擎》(第2版) P77：但是，即使将 sync_binlog 设为1，还是会有一种情况导致问题的发生。当使用 ImnoDB 存储引擎时，在一个事务发出 COMMIT 动作之前，由于 sync_binlog 为1，因此会将二进制日志立即写人磁盘。如果这时已经写人了二进制日志，但是提交还没有发生，并且此时发生了容机，那么在 MySQL 数据库下次启动时，由于 COMMIT 操作并没有发生，这个事务会被回滚掉。但是二进制日志已经记录了该事务信息，不能被回滚。这个问题可以通过将参数 imnnodb_support_xa 设为 1 来解决，虽然 innodb_support_xa 与 XA 事务有关，但它同时也确保了二进制日志和 InnoDB 存储引擎数据文件的同步。Old Boy：默认情况下，二进制日志不是实时同步到磁盘，因此如果操作系统崩溃或者机器故障，存在数据丢失的可能。要防止这种情况的出现，需要考虑的因素比较多，仅从 MSQL 的二进制日志同步来说，可以设置二进制日志同步到磁盘的频率，MySQL 提供了专用的系统变量 sync_binog。该参数的详细说明颇费幅，这里先简要描述与本节主题相关的内容。sync_binlog 值设为 1 安全级别最高，同时也是最慢的设置，不过即使设置为 1 同样有可能存在丢失数据的可能，只是最坏情况下，仅丢失最后执行的那条语句或事务。举例来说，使用 InnoDB 引擎的表通过事务向表中写数据，操作已经写到二进制日志，但还没来得及将提交语句写入日志，这时系统崩溃，那么当数据库服务重新启动时，InnoDB 引擎肯定会将未提交的事务回滚，那么这种情况下，必然造成数据丢失。要解决这种问题，MySQL 另外又提供了初始化参数 --innodb-support-xa，设置该参数值为 1，启用分布式事务的支持，确保二进制日志与 InnoDB 数据文件的同步。这种选项提供了深度的安全性，MySOL 应被配置为以事务为单位同步二进制日志和 InnoDB 日志到磁盘，InnoDB 日志默认即是同步状态，sync_binlog=1 可以同步二进制日志。这样当 MySQL 服务从崩溃中恢复时，为事务执行回滚后，MySQL 服务中断二进制日志中 InnoDB 事务的回滚，以这种方式确保二进制日志能够考虑 InnoDB 表中的实际数据，同样，Slave端也会保持同步状态(因为没有收到回滚的语句)。当 MSQL 服务执行崩溃恢复时发现，二进制日志比期望中要少，比如 InnoDB 事务缺少 commit (当syncbinlog=l时不可能出现这种情况)，服务器端就会抛出错误消息:The binary log file_name is shorter than itsexpected size，这种情况下，说明二进制日志文件有误，复制环境有必要重建。查看二进制日志我们可以使用 show 命令 或者 mysqlbinlog 工具来查看和分析二进制日志。查看当前正在使用的二进制文件mysql> show master status; <--- 查看当前 binlog，Positon 表示当前文件已经写到的位置，代表了当前日志文件的大小，单位为字节 +------------+----------+--------------+------------------+-------------------+ | File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set | +------------+----------+--------------+------------------+-------------------+ | bin.000007 | 154 | | demodb | | +------------+----------+--------------+------------------+-------------------+ 1 row in set (0.00 sec) mysql> flush binary logs; <--- 刷新 binlog，会生成新的 binlog 日志 Query OK, 0 rows affected (0.01 sec) mysql> show master status; <--- 查看新的 binlog 位置 +------------+----------+--------------+------------------+-------------------+ | File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set | +------------+----------+--------------+------------------+-------------------+ | bin.000008 | 154 | | demodb | | +------------+----------+--------------+------------------+-------------------+ 1 row in set (0.00 sec)除非用命令查看，也可以直接看操作系统上生成的文件，最后一个文件就是当前正在使用的日志文件。show 命令查看二进制文件中的事件官方文档：https://dev.mysql.com/doc/refman/5.7/en/show-binlog-events.htmlmysql> show binlog events in 'bin.000007'; +------------+-----+----------------+-----------+-------------+---------------------------------------+ | Log_name | Pos | Event_type | Server_id | End_log_pos | Info | +------------+-----+----------------+-----------+-------------+---------------------------------------+ | bin.000007 | 4 | Format_desc | 22 | 123 | Server ver: 5.7.44-log, Binlog ver: 4 | | bin.000007 | 123 | Previous_gtids | 22 | 154 | | | bin.000007 | 154 | Rotate | 22 | 195 | bin.000008;pos=4 | +------------+-----+----------------+-----------+-------------+---------------------------------------+ 3 rows in set (0.00 sec) mysql> show binlog events in 'bin.000008'; <--- 查看 binlog 中内容，如果不指定文件，则从第一个文件开始，如果文件不存在，会报错 +------------+-----+----------------+-----------+-------------+---------------------------------------+ | Log_name | Pos | Event_type | Server_id | End_log_pos | Info | +------------+-----+----------------+-----------+-------------+---------------------------------------+ | bin.000008 | 4 | Format_desc | 22 | 123 | Server ver: 5.7.44-log, Binlog ver: 4 | | bin.000008 | 123 | Previous_gtids | 22 | 154 | | +------------+-----+----------------+-----------+-------------+---------------------------------------+ 2 rows in set (0.00 sec) binlog 是由各种类型的 event 组成。每个二进制日志由三个部分的 event 组成：Header + Binary Log Events + Rotate。每个日志文件的开头有个叫 Format_desc 的 event，用来记录 Sever 的版本号和 Binlog 的版本号。5.7 加了一个叫 Previous_gtids 的 event。如果文件结束了，有一个叫 Rotate 的 event，Info 列会指下一个文件的起始位置。中间就是具体的 Binary Log Events。每个 event 由(Log_name,Pos)一起来定义。Pos 是 event 的起始位置，End_log_pos 是结束位置。End_log_pos - Pos 就是该 event 占用的字节数。每一行的记录，但是经过 base64 加密过的，这样方便传输， base64 在 web 中是应用比较广的。下面看一下表的创建、删除与 INSERT, UPDATE, DELETE 在二进制日志是如何记录的：mysql> create table cyt (id int, name varchar(20)); Query OK, 0 rows affected (0.05 sec) mysql> insert cyt values (1,'a'); Query OK, 1 row affected (0.03 sec) mysql> update cyt set id=2 where id=1; Query OK, 1 row affected (0.00 sec) Rows matched: 1 Changed: 1 Warnings: 0 mysql> delete from cyt where id=2; Query OK, 1 row affected (0.00 sec) mysql> commit; Query OK, 0 rows affected (0.01 sec) mysql> drop table cyt; Query OK, 0 rows affected (0.01 sec) mysql> show binlog events in 'bin.000011'; +------------+-----+----------------+-----------+-------------+-----------------------------------------------------------+ | Log_name | Pos | Event_type | Server_id | End_log_pos | Info | +------------+-----+----------------+-----------+-------------+-----------------------------------------------------------+ | bin.000011 | 4 | Format_desc | 22 | 123 | Server ver: 5.7.44-log, Binlog ver: 4 | | bin.000011 | 123 | Previous_gtids | 22 | 154 | | | bin.000011 | 154 | Anonymous_Gtid | 22 | 219 | SET @@SESSION.GTID_NEXT= 'ANONYMOUS' | | bin.000011 | 219 | Query | 22 | 340 | use `demodb`; create table cyt (id int, name varchar(20)) | | bin.000011 | 340 | Anonymous_Gtid | 22 | 405 | SET @@SESSION.GTID_NEXT= 'ANONYMOUS' | | bin.000011 | 405 | Query | 22 | 479 | BEGIN | | bin.000011 | 479 | Table_map | 22 | 530 | table_id: 110 (demodb.cyt) | | bin.000011 | 530 | Write_rows | 22 | 572 | table_id: 110 flags: STMT_END_F | | bin.000011 | 572 | Table_map | 22 | 623 | table_id: 110 (demodb.cyt) | | bin.000011 | 623 | Update_rows | 22 | 673 | table_id: 110 flags: STMT_END_F | | bin.000011 | 673 | Table_map | 22 | 724 | table_id: 110 (demodb.cyt) | | bin.000011 | 724 | Delete_rows | 22 | 766 | table_id: 110 flags: STMT_END_F | | bin.000011 | 766 | Xid | 22 | 797 | COMMIT /* xid=38 */ | | bin.000011 | 797 | Anonymous_Gtid | 22 | 862 | SET @@SESSION.GTID_NEXT= 'ANONYMOUS' | | bin.000011 | 862 | Query | 22 | 982 | use `demodb`; DROP TABLE `cyt` /* generated by server */ | +------------+-----+----------------+-----------+-------------+-----------------------------------------------------------+ 15 rows in set (0.00 sec) Table_map 表示这张表的定义和每个列的类型。Write_rows 表示操作类型是写入一个 rows，但是具体操作是看不到的， 同理有 Update_rows， Delete_rows。默认只能知道每一行的变化，但是不知道变化的操作的 SQL 语句是什么，如果想知道， binlog_rows_query_log_events 设置为 1。(my.cnf 文件中已经新加了该参数)配置后效果如下：mysql> insert into cyt2 values(3); Query OK, 1 row affected (0.00 sec) mysql> mysql> commit; Query OK, 0 rows affected (0.01 sec) mysql> show binlog events in 'bin.000018'; +------------+-----+----------------+-----------+-------------+---------------------------------------+ | Log_name | Pos | Event_type | Server_id | End_log_pos | Info | +------------+-----+----------------+-----------+-------------+---------------------------------------+ | bin.000018 | 4 | Format_desc | 22 | 123 | Server ver: 5.7.44-log, Binlog ver: 4 | | bin.000018 | 123 | Previous_gtids | 22 | 154 | | | bin.000018 | 154 | Anonymous_Gtid | 22 | 219 | SET @@SESSION.GTID_NEXT= 'ANONYMOUS' | | bin.000018 | 219 | Query | 22 | 293 | BEGIN | | bin.000018 | 293 | Rows_query | 22 | 343 | # insert into cyt2 values(3) | | bin.000018 | 343 | Table_map | 22 | 392 | table_id: 111 (demodb.cyt2) | | bin.000018 | 392 | Write_rows | 22 | 432 | table_id: 111 flags: STMT_END_F | | bin.000018 | 432 | Xid | 22 | 463 | COMMIT /* xid=9 */ | +------------+-----+----------------+-----------+-------------+---------------------------------------+ 8 rows in set (0.00 sec) 通过 mysqlbinlog 也能看到记录了语句：# mysqlbinlog -vv --base64-output=decode-rows bin.000018 # at 293 #250717 16:59:25 server id 22 end_log_pos 343 CRC32 0x310a4566 Rows_query # insert into cyt2 values(3)生产上 binlog 日志通常很多，直接查看文件中的所有内容将是一个耗时和耗资源的一个过程。Issuing a SHOW BINLOG EVENTS with no LIMIT clause could start a very time- and resource-consuming process because the server returns to the client the complete contents of the binary log (which includes all statements executed by the server that modify data).此时，我们可以使用 from 定位和 limit 限制。SHOW BINLOG EVENTS [IN 'log_name'] [FROM pos] [LIMIT [offset,] row_count]仅查看前5条 events:mysql> show binlog events in 'bin.000011' limit 5; +------------+-----+----------------+-----------+-------------+-----------------------------------------------------------+ | Log_name | Pos | Event_type | Server_id | End_log_pos | Info | +------------+-----+----------------+-----------+-------------+-----------------------------------------------------------+ | bin.000011 | 4 | Format_desc | 22 | 123 | Server ver: 5.7.44-log, Binlog ver: 4 | | bin.000011 | 123 | Previous_gtids | 22 | 154 | | | bin.000011 | 154 | Anonymous_Gtid | 22 | 219 | SET @@SESSION.GTID_NEXT= 'ANONYMOUS' | | bin.000011 | 219 | Query | 22 | 340 | use `demodb`; create table cyt (id int, name varchar(20)) | | bin.000011 | 340 | Anonymous_Gtid | 22 | 405 | SET @@SESSION.GTID_NEXT= 'ANONYMOUS' | +------------+-----+----------------+-----------+-------------+-----------------------------------------------------------+ 5 rows in set (0.00 sec)查看从 pos 530 开始的所有日志：mysql> show binlog events in 'bin.000011' from 530; +------------+-----+----------------+-----------+-------------+----------------------------------------------------------+ | Log_name | Pos | Event_type | Server_id | End_log_pos | Info | +------------+-----+----------------+-----------+-------------+----------------------------------------------------------+ | bin.000011 | 530 | Write_rows | 22 | 572 | table_id: 110 flags: STMT_END_F | | bin.000011 | 572 | Table_map | 22 | 623 | table_id: 110 (demodb.cyt) | | bin.000011 | 623 | Update_rows | 22 | 673 | table_id: 110 flags: STMT_END_F | | bin.000011 | 673 | Table_map | 22 | 724 | table_id: 110 (demodb.cyt) | | bin.000011 | 724 | Delete_rows | 22 | 766 | table_id: 110 flags: STMT_END_F | | bin.000011 | 766 | Xid | 22 | 797 | COMMIT /* xid=38 */ | | bin.000011 | 797 | Anonymous_Gtid | 22 | 862 | SET @@SESSION.GTID_NEXT= 'ANONYMOUS' | | bin.000011 | 862 | Query | 22 | 982 | use `demodb`; DROP TABLE `cyt` /* generated by server */ | +------------+-----+----------------+-----------+-------------+----------------------------------------------------------+ 8 rows in set (0.00 sec)从 pos 530 开始，仅显示4条 events：mysql> show binlog events in 'bin.000011' from 530 limit 4; +------------+-----+-------------+-----------+-------------+---------------------------------+ | Log_name | Pos | Event_type | Server_id | End_log_pos | Info | +------------+-----+-------------+-----------+-------------+---------------------------------+ | bin.000011 | 530 | Write_rows | 22 | 572 | table_id: 110 flags: STMT_END_F | | bin.000011 | 572 | Table_map | 22 | 623 | table_id: 110 (demodb.cyt) | | bin.000011 | 623 | Update_rows | 22 | 673 | table_id: 110 flags: STMT_END_F | | bin.000011 | 673 | Table_map | 22 | 724 | table_id: 110 (demodb.cyt) | +------------+-----+-------------+-----------+-------------+---------------------------------+ 4 rows in set (0.00 sec)从 pos 530 后面的第 3 条开始，显示5条 events：mysql> show binlog events in 'bin.000011' from 530 limit 3,5; +------------+-----+----------------+-----------+-------------+----------------------------------------------------------+ | Log_name | Pos | Event_type | Server_id | End_log_pos | Info | +------------+-----+----------------+-----------+-------------+----------------------------------------------------------+ | bin.000011 | 673 | Table_map | 22 | 724 | table_id: 110 (demodb.cyt) | | bin.000011 | 724 | Delete_rows | 22 | 766 | table_id: 110 flags: STMT_END_F | | bin.000011 | 766 | Xid | 22 | 797 | COMMIT /* xid=38 */ | | bin.000011 | 797 | Anonymous_Gtid | 22 | 862 | SET @@SESSION.GTID_NEXT= 'ANONYMOUS' | | bin.000011 | 862 | Query | 22 | 982 | use `demodb`; DROP TABLE `cyt` /* generated by server */ | +------------+-----+----------------+-----------+-------------+----------------------------------------------------------+ 5 rows in set (0.00 sec)mysqlbinlog 工具查看二进制文件中的事件使用 mysqlbinlog 命令时，可以跟多个 binlog 文件，也可以使用通配。# mysqlbinlog [-vv] bin.000011 /*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=1*/; /*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/; DELIMITER /*!*/; # at 4 #250717 15:19:04 server id 22 end_log_pos 123 CRC32 0xc3d2ae7d Start: binlog v 4, server v 5.7.44-log created 250717 15:19:04 # Warning: this binlog is either in use or was not closed properly. BINLOG ' 6KN4aA8WAAAAdwAAAHsAAAABAAQANS43LjQ0LWxvZwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAEzgNAAgAEgAEBAQEEgAAXwAEGggAAAAICAgCAAAACgoKKioAEjQA AX2u0sM= '/*!*/; # at 123 #250717 15:19:04 server id 22 end_log_pos 154 CRC32 0xa4f2382e Previous-GTIDs # [empty] # at 154 #250717 15:19:39 server id 22 end_log_pos 219 CRC32 0xbc7e99a9 Anonymous_GTID last_committed=0 sequence_number=1 rbr_only=no SET @@SESSION.GTID_NEXT= 'ANONYMOUS'/*!*/; # at 219 #250717 15:19:39 server id 22 end_log_pos 340 CRC32 0x0aa0e6a7 Query thread_id=2 exec_time=0 error_code=0 use `demodb`/*!*/; SET TIMESTAMP=1752736779/*!*/; SET @@session.pseudo_thread_id=2/*!*/; SET @@session.foreign_key_checks=1, @@session.sql_auto_is_null=0, @@session.unique_checks=1, @@session.autocommit=1/*!*/; SET @@session.sql_mode=1436549152/*!*/; SET @@session.auto_increment_increment=1, @@session.auto_increment_offset=1/*!*/; /*!\C utf8 *//*!*/; SET @@session.character_set_client=33,@@session.collation_connection=33,@@session.collation_server=8/*!*/; SET @@session.lc_time_names=0/*!*/; SET @@session.collation_database=DEFAULT/*!*/; create table cyt (id int, name varchar(20)) /*!*/; # at 340 #250717 15:20:40 server id 22 end_log_pos 405 CRC32 0xac867f22 Anonymous_GTID last_committed=1 sequence_number=2 rbr_only=yes /*!50718 SET TRANSACTION ISOLATION LEVEL READ COMMITTED*//*!*/; SET @@SESSION.GTID_NEXT= 'ANONYMOUS'/*!*/; # at 405 #250717 15:19:56 server id 22 end_log_pos 479 CRC32 0x9bb0a06d Query thread_id=2 exec_time=0 error_code=0 SET TIMESTAMP=1752736796/*!*/; BEGIN /*!*/; # at 479 #250717 15:19:56 server id 22 end_log_pos 530 CRC32 0xe6e2c795 Table_map: `demodb`.`cyt` mapped to number 110 # at 530 #250717 15:19:56 server id 22 end_log_pos 572 CRC32 0xc94ce40c Write_rows: table id 110 flags: STMT_END_F BINLOG ' HKR4aBMWAAAAMwAAABICAAAAAG4AAAAAAAEABmRlbW9kYgADY3l0AAIDDwIUAAOVx+Lm HKR4aB4WAAAAKgAAADwCAAAAAG4AAAAAAAEAAgAC//wBAAAAAWEM5EzJ '/*!*/; ### INSERT INTO `demodb`.`cyt` ### SET ### @1=1 /* INT meta=0 nullable=1 is_null=0 */ ### @2='a' /* VARSTRING(20) meta=20 nullable=1 is_null=0 */ # at 572 #250717 15:20:16 server id 22 end_log_pos 623 CRC32 0x96fc3fb6 Table_map: `demodb`.`cyt` mapped to number 110 # at 623 #250717 15:20:16 server id 22 end_log_pos 673 CRC32 0x83c3949b Update_rows: table id 110 flags: STMT_END_F BINLOG ' MKR4aBMWAAAAMwAAAG8CAAAAAG4AAAAAAAEABmRlbW9kYgADY3l0AAIDDwIUAAO2P/yW MKR4aB8WAAAAMgAAAKECAAAAAG4AAAAAAAEAAgAC///8AQAAAAFh/AIAAAABYZuUw4M= '/*!*/; ### UPDATE `demodb`.`cyt` ### WHERE ### @1=1 /* INT meta=0 nullable=1 is_null=0 */ ### @2='a' /* VARSTRING(20) meta=20 nullable=1 is_null=0 */ ### SET ### @1=2 /* INT meta=0 nullable=1 is_null=0 */ ### @2='a' /* VARSTRING(20) meta=20 nullable=1 is_null=0 */ # at 673 #250717 15:20:28 server id 22 end_log_pos 724 CRC32 0x1fbddede Table_map: `demodb`.`cyt` mapped to number 110 # at 724 #250717 15:20:28 server id 22 end_log_pos 766 CRC32 0x3319b98e Delete_rows: table id 110 flags: STMT_END_F BINLOG ' PKR4aBMWAAAAMwAAANQCAAAAAG4AAAAAAAEABmRlbW9kYgADY3l0AAIDDwIUAAPe3r0f PKR4aCAWAAAAKgAAAP4CAAAAAG4AAAAAAAEAAgAC//wCAAAAAWGOuRkz '/*!*/; ### DELETE FROM `demodb`.`cyt` ### WHERE ### @1=2 /* INT meta=0 nullable=1 is_null=0 */ ### @2='a' /* VARSTRING(20) meta=20 nullable=1 is_null=0 */ # at 766 #250717 15:20:40 server id 22 end_log_pos 797 CRC32 0xa9f4bd1c Xid = 38 COMMIT/*!*/; # at 797 #250717 15:20:43 server id 22 end_log_pos 862 CRC32 0x79d2de35 Anonymous_GTID last_committed=2 sequence_number=3 rbr_only=no SET @@SESSION.GTID_NEXT= 'ANONYMOUS'/*!*/; # at 862 #250717 15:20:43 server id 22 end_log_pos 982 CRC32 0x2d2ee1e9 Query thread_id=2 exec_time=0 error_code=0 SET TIMESTAMP=1752736843/*!*/; DROP TABLE `cyt` /* generated by server */ /*!*/; SET @@SESSION.GTID_NEXT= 'AUTOMATIC' /* added by mysqlbinlog */ /*!*/; DELIMITER ; # End of log file /*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/; /*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=0*/;如果没有 -vv，就不能看到类似 SQL 的语句，可以看到，除了 create table、drop table 外，都是经过 base64 加密的数据。一定要注意，binlog 里面记录的不是 SQL 语句。 @1 表示第1个列，@2表示第2个列insert 和 delete 都是记录整行， update 记录行的前项和后项，所以影响记录数相同的情况下 update 是最消耗日志空间。ROW 格式记录的是每行一操作，所以能确保主从的数据严格一致。缺点是日志数据可能很大，比如 update 全表， delete 全表。如果想看 base64 的编码原文，可以使用 --base64-output=decode-rows 来 decodes row events into commented pseudo-SQL statements。# mysqlbinlog -vv --base64-output=decode-rows bin.000010 /*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=1*/; /*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/; DELIMITER /*!*/; # at 4 #250717 14:29:16 server id 22 end_log_pos 123 CRC32 0x575e6377 Start: binlog v 4, server v 5.7.44-log created 250717 14:29:16 # Warning: this binlog is either in use or was not closed properly. # at 123 #250717 14:29:16 server id 22 end_log_pos 154 CRC32 0x25ab28cd Previous-GTIDs # [empty] # at 154 #250717 14:30:20 server id 22 end_log_pos 219 CRC32 0xe71c29d5 Anonymous_GTID last_committed=0 sequence_number=1 rbr_only=no SET @@SESSION.GTID_NEXT= 'ANONYMOUS'/*!*/; # at 219 #250717 14:30:20 server id 22 end_log_pos 322 CRC32 0x462f7003 Query thread_id=2 exec_time=0 error_code=0 use `demodb`/*!*/; SET TIMESTAMP=1752733820/*!*/; SET @@session.pseudo_thread_id=2/*!*/; SET @@session.foreign_key_checks=1, @@session.sql_auto_is_null=0, @@session.unique_checks=1, @@session.autocommit=1/*!*/; SET @@session.sql_mode=1436549152/*!*/; SET @@session.auto_increment_increment=1, @@session.auto_increment_offset=1/*!*/; /*!\C utf8 *//*!*/; SET @@session.character_set_client=33,@@session.collation_connection=33,@@session.collation_server=8/*!*/; SET @@session.lc_time_names=0/*!*/; SET @@session.collation_database=DEFAULT/*!*/; create table cyt (id int) /*!*/; # at 322 #250717 14:33:06 server id 22 end_log_pos 387 CRC32 0x657e3a57 Anonymous_GTID last_committed=1 sequence_number=2 rbr_only=yes /*!50718 SET TRANSACTION ISOLATION LEVEL READ COMMITTED*//*!*/; SET @@SESSION.GTID_NEXT= 'ANONYMOUS'/*!*/; # at 387 #250717 14:30:29 server id 22 end_log_pos 461 CRC32 0x4364f414 Query thread_id=2 exec_time=0 error_code=0 SET TIMESTAMP=1752733829/*!*/; BEGIN /*!*/; # at 461 #250717 14:30:29 server id 22 end_log_pos 509 CRC32 0x18448aa9 Table_map: `demodb`.`cyt` mapped to number 109 # at 509 #250717 14:30:29 server id 22 end_log_pos 549 CRC32 0xd0ff2fb8 Write_rows: table id 109 flags: STMT_END_F ### INSERT INTO `demodb`.`cyt` ### SET ### @1=1 /* INT meta=0 nullable=1 is_null=0 */ # at 549 #250717 14:30:57 server id 22 end_log_pos 597 CRC32 0xdf967ad3 Table_map: `demodb`.`cyt` mapped to number 109 # at 597 #250717 14:30:57 server id 22 end_log_pos 643 CRC32 0x63a4649c Update_rows: table id 109 flags: STMT_END_F ### UPDATE `demodb`.`cyt` ### WHERE ### @1=1 /* INT meta=0 nullable=1 is_null=0 */ ### SET ### @1=2 /* INT meta=0 nullable=1 is_null=0 */ # at 643 #250717 14:33:03 server id 22 end_log_pos 691 CRC32 0x9ac014cd Table_map: `demodb`.`cyt` mapped to number 109 # at 691 #250717 14:33:03 server id 22 end_log_pos 731 CRC32 0x6760e0eb Delete_rows: table id 109 flags: STMT_END_F ### DELETE FROM `demodb`.`cyt` ### WHERE ### @1=2 /* INT meta=0 nullable=1 is_null=0 */ # at 731 #250717 14:33:06 server id 22 end_log_pos 762 CRC32 0xc085329e Xid = 11 COMMIT/*!*/; # at 762 #250717 14:33:21 server id 22 end_log_pos 827 CRC32 0x9d6f245f Anonymous_GTID last_committed=2 sequence_number=3 rbr_only=no SET @@SESSION.GTID_NEXT= 'ANONYMOUS'/*!*/; # at 827 #250717 14:33:21 server id 22 end_log_pos 947 CRC32 0xda1a6a08 Query thread_id=2 exec_time=0 error_code=0 SET TIMESTAMP=1752734001/*!*/; DROP TABLE `cyt` /* generated by server */ /*!*/; SET @@SESSION.GTID_NEXT= 'AUTOMATIC' /* added by mysqlbinlog */ /*!*/; DELIMITER ; # End of log file /*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/; /*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=0*/; [root@mysqlnode1 3307]# binlog 中会产生 rollback 的信息吗？不会的。在以前的版本里，引擎混用可能会记录 rollback 信息，在 5.7.44 里测试已经不会记录了。mysql> create table cyt1(id int) engine=myisam;mysql> create table cyt2(id int) engine=innodb;仅使用 innodb 引擎，不记录 rollback：mysql> flush binary logs; Query OK, 0 rows affected (0.02 sec) mysql> show master status; +------------+----------+--------------+------------------+-------------------+ | File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set | +------------+----------+--------------+------------------+-------------------+ | bin.000015 | 154 | | | | +------------+----------+--------------+------------------+-------------------+ 1 row in set (0.00 sec) mysql> insert into cyt2 values(1); Query OK, 1 row affected (0.01 sec) mysql> rollback; Query OK, 0 rows affected (0.00 sec)查看 binlog 日志：# mysqlbinlog -vv bin.000015 /*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=1*/; /*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/; DELIMITER /*!*/; # at 4 #250717 16:00:24 server id 22 end_log_pos 123 CRC32 0xa073daaf Start: binlog v 4, server v 5.7.44-log created 250717 16:00:24 # Warning: this binlog is either in use or was not closed properly. BINLOG ' mK14aA8WAAAAdwAAAHsAAAABAAQANS43LjQ0LWxvZwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAEzgNAAgAEgAEBAQEEgAAXwAEGggAAAAICAgCAAAACgoKKioAEjQA Aa/ac6A= '/*!*/; # at 123 #250717 16:00:24 server id 22 end_log_pos 154 CRC32 0x8e3b9ec9 Previous-GTIDs # [empty] SET @@SESSION.GTID_NEXT= 'AUTOMATIC' /* added by mysqlbinlog */ /*!*/; DELIMITER ; # End of log file /*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/; /*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=0*/;引擎混合1：mysql> flush binary logs; Query OK, 0 rows affected (0.01 sec) mysql> show master status; +------------+----------+--------------+------------------+-------------------+ | File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set | +------------+----------+--------------+------------------+-------------------+ | bin.000016 | 154 | | | | +------------+----------+--------------+------------------+-------------------+ 1 row in set (0.00 sec) mysql> mysql> insert into cyt2 values(1); Query OK, 1 row affected (0.00 sec) mysql> insert into cyt1 values(1); Query OK, 1 row affected (0.01 sec) mysql> rollback; Query OK, 0 rows affected, 1 warning (0.00 sec) mysql> # mysqlbinlog -vv bin.000016 /*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=1*/; /*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/; DELIMITER /*!*/; # at 4 #250717 16:07:29 server id 22 end_log_pos 123 CRC32 0xa09cb40d Start: binlog v 4, server v 5.7.44-log created 250717 16:07:29 # Warning: this binlog is either in use or was not closed properly. BINLOG ' Qa94aA8WAAAAdwAAAHsAAAABAAQANS43LjQ0LWxvZwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAEzgNAAgAEgAEBAQEEgAAXwAEGggAAAAICAgCAAAACgoKKioAEjQA AQ20nKA= '/*!*/; # at 123 #250717 16:07:29 server id 22 end_log_pos 154 CRC32 0x559e4846 Previous-GTIDs # [empty] # at 154 #250717 16:10:47 server id 22 end_log_pos 219 CRC32 0xef04ac05 Anonymous_GTID last_committed=0 sequence_number=1 rbr_only=yes /*!50718 SET TRANSACTION ISOLATION LEVEL READ COMMITTED*//*!*/; SET @@SESSION.GTID_NEXT= 'ANONYMOUS'/*!*/; # at 219 #250717 16:10:47 server id 22 end_log_pos 293 CRC32 0xe6526b61 Query thread_id=2 exec_time=0 error_code=0 SET TIMESTAMP=1752739847/*!*/; SET @@session.pseudo_thread_id=2/*!*/; SET @@session.foreign_key_checks=1, @@session.sql_auto_is_null=0, @@session.unique_checks=1, @@session.autocommit=1/*!*/; SET @@session.sql_mode=1436549152/*!*/; SET @@session.auto_increment_increment=1, @@session.auto_increment_offset=1/*!*/; /*!\C utf8 *//*!*/; SET @@session.character_set_client=33,@@session.collation_connection=33,@@session.collation_server=8/*!*/; SET @@session.lc_time_names=0/*!*/; SET @@session.collation_database=DEFAULT/*!*/; BEGIN /*!*/; # at 293 #250717 16:10:47 server id 22 end_log_pos 342 CRC32 0x42575820 Table_map: `demodb`.`cyt1` mapped to number 115 # at 342 #250717 16:10:47 server id 22 end_log_pos 382 CRC32 0x0ef88b68 Write_rows: table id 115 flags: STMT_END_F BINLOG ' B7B4aBMWAAAAMQAAAFYBAAAAAHMAAAAAAAEABmRlbW9kYgAEY3l0MQABAwABIFhXQg== B7B4aB4WAAAAKAAAAH4BAAAAAHMAAAAAAAEAAgAB//4BAAAAaIv4Dg== '/*!*/; ### INSERT INTO `demodb`.`cyt1` ### SET ### @1=1 /* INT meta=0 nullable=1 is_null=0 */ # at 382 #250717 16:10:47 server id 22 end_log_pos 457 CRC32 0xbb41c65f Query thread_id=2 exec_time=0 error_code=0 SET TIMESTAMP=1752739847/*!*/; COMMIT /*!*/; SET @@SESSION.GTID_NEXT= 'AUTOMATIC' /* added by mysqlbinlog */ /*!*/; DELIMITER ; # End of log file /*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/; /*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=0*/; 引擎混用2：mysql> flush binary logs; Query OK, 0 rows affected (0.01 sec) mysql> show master status; +------------+----------+--------------+------------------+-------------------+ | File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set | +------------+----------+--------------+------------------+-------------------+ | bin.000017 | 154 | | | | +------------+----------+--------------+------------------+-------------------+ 1 row in set (0.00 sec) mysql> insert into cyt1 values(2); Query OK, 1 row affected (0.01 sec) mysql> insert into cyt2 values(2); Query OK, 1 row affected (0.00 sec) mysql> rollback; Query OK, 0 rows affected, 1 warning (0.01 sec)/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=1*/; /*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/; DELIMITER /*!*/; # at 4 #250717 16:13:06 server id 22 end_log_pos 123 CRC32 0xc5770629 Start: binlog v 4, server v 5.7.44-log created 250717 16:13:06 # Warning: this binlog is either in use or was not closed properly. BINLOG ' krB4aA8WAAAAdwAAAHsAAAABAAQANS43LjQ0LWxvZwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAEzgNAAgAEgAEBAQEEgAAXwAEGggAAAAICAgCAAAACgoKKioAEjQA ASkGd8U= '/*!*/; # at 123 #250717 16:13:06 server id 22 end_log_pos 154 CRC32 0xa353384c Previous-GTIDs # [empty] # at 154 #250717 16:14:15 server id 22 end_log_pos 219 CRC32 0x7f150385 Anonymous_GTID last_committed=0 sequence_number=1 rbr_only=yes /*!50718 SET TRANSACTION ISOLATION LEVEL READ COMMITTED*//*!*/; SET @@SESSION.GTID_NEXT= 'ANONYMOUS'/*!*/; # at 219 #250717 16:14:15 server id 22 end_log_pos 293 CRC32 0x2fa51f37 Query thread_id=2 exec_time=0 error_code=0 SET TIMESTAMP=1752740055/*!*/; SET @@session.pseudo_thread_id=2/*!*/; SET @@session.foreign_key_checks=1, @@session.sql_auto_is_null=0, @@session.unique_checks=1, @@session.autocommit=1/*!*/; SET @@session.sql_mode=1436549152/*!*/; SET @@session.auto_increment_increment=1, @@session.auto_increment_offset=1/*!*/; /*!\C utf8 *//*!*/; SET @@session.character_set_client=33,@@session.collation_connection=33,@@session.collation_server=8/*!*/; SET @@session.lc_time_names=0/*!*/; SET @@session.collation_database=DEFAULT/*!*/; BEGIN /*!*/; # at 293 #250717 16:14:15 server id 22 end_log_pos 342 CRC32 0x89bd6a67 Table_map: `demodb`.`cyt1` mapped to number 115 # at 342 #250717 16:14:15 server id 22 end_log_pos 382 CRC32 0xa924c8cc Write_rows: table id 115 flags: STMT_END_F BINLOG ' 17B4aBMWAAAAMQAAAFYBAAAAAHMAAAAAAAEABmRlbW9kYgAEY3l0MQABAwABZ2q9iQ== 17B4aB4WAAAAKAAAAH4BAAAAAHMAAAAAAAEAAgAB//4CAAAAzMgkqQ== '/*!*/; ### INSERT INTO `demodb`.`cyt1` ### SET ### @1=2 /* INT meta=0 nullable=1 is_null=0 */ # at 382 #250717 16:14:15 server id 22 end_log_pos 457 CRC32 0x3980c5ea Query thread_id=2 exec_time=0 error_code=0 SET TIMESTAMP=1752740055/*!*/; COMMIT /*!*/; SET @@SESSION.GTID_NEXT= 'AUTOMATIC' /* added by mysqlbinlog */ /*!*/; DELIMITER ; # End of log file /*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/; /*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=0*/; 可见，引擎混用只记录了 MyISAM 的，没有 InonoDB 的。