ITPub博客

https://docs.pingcap.com/zh/tidb-data-migration/v1.0/skip-or-replace-abnormal-sql-statements被动跳过 SQL 语句假设业务上可以接受下游 TiDB 不执行此 DDL 语句（即继续保持原有的表结构），则可以通过使用 sql-skip 命令跳过该 DDL 语句以恢复迁移任务。操作步骤如下：一：使用 query-

一：环境介绍：因公司t采用dm 1.0版本，故本过程基于DM集群1.0版本，官方建议使用dm 2.0;  tidb集群版本4.0，上游mysql 社区版5.7.281）上游mysql：SIM:root:[(none)]>select version(); +------------+ | version()  | +------------+ | 5.7.28-l

问题表现：周期性出现connect timeout:  具体如下：redis.clients.jedis.exceptions.JedisConnectionExceptionjava.net.SocketExceptionjava.net.SocketTimeoutException: connect timed out问题原因分析：redis 参数tcp-backlog默认设置过小（

xid是mysql server层维护的，通过一个全局变量global_query_id来生成，trx_id是innodb内部维护的，InnoDB 内部维护了一个 max_trx_id 全局变量，每次需要申请一个新的 trx_id 时，就获得 max_trx_id 的当前值，然后并将 max_trx_id 加 1，如果当前语句是这个事务执行的第一条语句，那么 MySQL 还会同时把 Query_i

关于mysql load语句在binlog中的记录方式：整理自 实战45讲+自己的一些理解一：binlog_format=statement这个 load 语句记录到 binlog 里以后，怎么在备库重放呢？由于 /server_tmp/t.csv 文件只保存在主库所在的主机上，如果只是把这条语句原文写到 binlog 中，在备库执行的时候，备库的本地机器上没有这个文件，就会导致主备同步停止。所以

现象：1.zabbix提示连接不上mysql机器上的agent，无法获取服务器消息；2.尝试ssh到这台机器，报错：[root@dba-salt-manager ~]#  ssh  ops@10.12.32.93 -o StrictHostKeyChecking=nokex_exchange_identification:&nb

关于mysql 5.7的并行复制策略，mysql 5.7.22开始支持的 基于writeset的并行复制策略；mysql多线程复制，需要遵循两个基本原则：1.不能造成更新覆盖，这就要求更新同一行的两个事务，必须被分发到同一个worker中，2.同一个事务不能被拆开，必须放到同一worker中！一：5.7.22之前的COMMIT_ORDER并行复制方式，借助mysql的

编写一个脚本，实现如下的2个功能:1. 运行脚本时随机生成一个关卡返回:  8⾏字符串表⽰关卡初始布局，对应棋盘中的 8⾏，每⾏包括 8 个字符。每个字符表⽰一种糖果，对应关系为: (B 普通糖果，H 横炸糖果，V 竖炸糖果，S方炸糖果)2. 一次消除操作/move.sh <row0> <col0> <row1> <

GTID 的全称是 Global Transaction Identifier，也就是全局事务 ID，是一个事务在提交的时候生成的，是这个事务的唯一标识。它由两部分组成，格式是：GTID=server_uuid:gno其中：server_uuid 是一个实例第一次启动时自动生成的，是一个全局唯一的值；gno 是一个整数，初始值是 1，每次提交事务的时候分配给这个事务，并加 1。这里我需要和你说明一

一：该方法失败了！使用rman 备份某个pdb，来实现迁移某个pdb的目的：针对19c制定备份任务，可以选择只备份特定的pdb，这样有个好处是，如果需要恢复，不用恢复重置文件和参数文件，直接恢复某个pdb即可，具体得做个试验记录下，这只是我的猜测！恢复某个或者多个pdb的时候，不需要停止其他的pdb； 然后再做一个试验，是不是可以从新起名来恢复某个pdb，例如liu_pdb恢复成he_pdb；首先

首先我们知道pxc集群为了获得全局一致性gtid，当你执行ddl操作的时候，他会上全局锁，会阻塞后面整个实例所有的dml或者ddl操作；然后不产生全局gtid，是不是就不会上全局锁了呢？一.查看pxc集群当前节点最新提交的事务号；他是最新的galera GTID的后半部分，前半部分是状态变量wsrep_local_state_uuid的值，每次事务提交、ddl完成或apply完成之后都会更新这个值

一:load 的过程相当于是：先start transaction，然后再insert数据，最后commitmysql 区别于oracle sqlldr,没有后者的rows的参数来控制每次提交的数据行但是mysql 是自己通过估算出一个值，来批量读取 ，他不是 一条一条的 insert的二：load 如果数据存在（主键或者唯一键），默认是跳过的，可以选择replace存在就替换！三：load 没有

首先我们知道pxc集群为了获得全局一致性gtid，当你执行ddl操作的时候，他会上全局锁，会阻塞后面整个实例所有的dml或者ddl操作；然后不产生全局gtid，是不是就不会上全局锁了呢？一.查看pxc集群当前节点最新提交的事务号；他是最新的galera GTID的后半部分，前半部分是状态变量wsrep_local_state_uuid的值，每次事务提交、ddl完成或apply完成之后都会更新这个值

mysql RR隔离级别下事务特性小结：通过学习了林晓斌的实战45讲的一些理解：我们知道如果是可重复读隔离级别，事务 T 启动的时候会创建一个视图 read-view（其实就是一批trx_id号），之后事务 T 执行期间，即使有其他事务修改了数据，事务 T 看到的仍然跟在启动时看到的一样。也就是说，一个在可重复读隔离级别下执行的事务，好像与世无争，不受外界影响。但是，我在上一篇文章中，和你分享行锁

错误日志中关于此次死锁的记录如下，显示的是两个update语句产生了死锁！LATEST DETECTED DEADLOCK------------------------2021-01-15 18:12:40 7f9c01daf700*** (1) TRANSACTION:TRANSACTION 16175364313, ACTIVE 0 sec starting index readmysql