ITPub博客

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

oracle 19c搭建过程过程中，执行duplicate报错 RMAN-03009: failure of backup command on ORA_DISK_1 channel at 06/26/2020 16:12:35 ORA-17628: Oracle error 19505 returned by remote Oracle server ORA-19505: failed to identify file ""

一：MySQL 5.7并行复制初理解我们知道MySQL 5.7并行复制引入了两个值last_committed和sequence_number。last_committed表示事务提交的时候，上次事务提交的编号，在主库上同时提交的事务设置成相同的last_committed。如果事务具有相同的last_committed，表示这些事务都在一组内，可以进行并行的回放。查看组提交的事务个数,其中989

首先：正常insert的时候，也是首先要判断哪个物理页（包括数据页和索引页）可以insert，然后把这个物理块读取到buffer pool，然后再在内存执行insert 操作，然后再刷新到磁盘;接下来介绍下我对change buffer的认识，知识来自于网络文章+innodb 存储引擎书籍+官方文档0）Change Buffer为何提高性能它缓存的是一个索引页的 dml的操作，而不是具体的数据页，

一：一定先创建监听，然后建库，否则报错：[oracle@tvy-mysql-cdsp-01 database]$ dbca -silent  -createDatabase  -responseFile    /media/database/response/dbca.rsp[WARNING] [DBT-06801] Specified Fast Recov

mysql 5.7.27 pxc 三个节点全部异常和正常关闭的启动顺序：1、正常关闭所有节点的时候因为不能生成gvwstate.dat，所以一定要保证第一个启动的是包含最新数据的节点！mysqld_safe --defaults-file=/etc/my.cnf   --wsrep-recover来查看最新的节点！2、Server version: 5.7.27-30-57-log 这个

1.如果需要从一个实例把数据倒进另一个生产的实例，那么需要注意：使用一下语句dump出来！mysqldump  -uroot  -p -t  --single-transaction=true  --skip-disable-keys=false  --add-locks=false --set-gtid-purged=off   &nb

xtrabackup的官方下载地址为 http://www.percona.com/software/percona-xtrabackup。 xtrabackup包含两个主要的工具，即xtrabackup和innobackupex，二者区别如下：1 xtrabackup只能备份innodb和xtradb两种引擎的表，而不能备份myisam引擎的表； 2 innobackupe

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

前面介绍了两种方法来添加secondary节点,直接rs.add()和一致性备份的方式来实现，接下来介绍第三种方式，具体如下：方法三：采用secondary的冷备份的方式找到另外一个secondary数据节点的快照，关闭写操作（冷备份）这里我采用了设置延迟节点的方法来实现关闭写操作的目的。在数据不变化的情况下，获得一致性的备份快照，拷贝至故障节点中，启动MongoDB服务，应用oplog日志！需要

1.创建数据库，直接use 即可，没有的话，如果你创建集合了，他就自动创建了!use liuwenhe2.插入数据，如果hezi集合不存在，则自动创建for (var i = 0; i < 100; i++) { db.hezi.insert({name: i}); }3.为hezi集合的name列添加索引,因为如果要以name列作为分片键，需要有索引;如果集合是空的，可以不创建索引直接进行

环境介绍：10.9.21.17810.9.21.17910.9.21.114MongoDB sharding简介三种角色介绍：1.数据分片（Shards）用来保存数据，保证数据的高可用性和一致性。可以是一个单独的mongod实例，也可以是一个副本集。在生产环境下Shard一般是一个Replica Set，以防止该数据片的单点故障。可以将所有shard的副本集放在一个服务器多个mongodb实例中。

一致性备份+oplogs如果采用直接rs.add的方法添加新节点，需要保证oplog不被覆盖并且需要评估同步oplog的流量影响问题，所以（一致性备份+oplogs）是我们通常进行横向复制集添加secondary节点的方法，当数据量大的时候，需要采用下面的方法：环境描述主节点 10.9.21.114：27017两个从节点10.9.21.178：2701710.9.21.179：27017目标：用一

环境介绍：三个节点的mongodb 副本集10.9.21.114:  27017 主节点10.9.21.178:  27017 secondary10.9.21.179:  27017 secondary需要给副本集添加个新的节点10.9.21.115: 27017方法一：rs.add("10.9.21.115:27017")直接添加首先介绍下命令