ITPub博客

　　1 原理　　关于MySQL数据库的分布式事务XA，分布式事务实现的原理，可见[3];关于MySQL XA的说明，可见[1][2]。　　MySQL XA分为两类，内部XA与外部XA;内部XA用于同一实例下跨多个引擎的事务，由大家熟悉的Binlog作为协调者;外部XA用于跨多MySQL实例的分布式事务，需要应用层介入作为协调者(崩溃时的悬挂事务，全局提交还是回滚，需要由应用层决定，对应用层的实现要

示例SQL:SELECT q.queueid FROM render.queues q WHERE q.queueid in ( SELECT max(queueid) FROM ( SELECT t.queueid FROM queues t WHERE

        在ORACLE 中,我们常常推荐使用exists 来替代in,往往也能取得比较好的优化效果。在ORACLE应用迁往MYSQL的过程中，我们发现部分in 的子查询语句带到MYSQL中，其执行效率变得非常低下，这很让人觉得匪夷所思。于是，我分析了一波。    对两个表

10个并发共插入10万行 总耗时(s)                              &

最近在ORACLE 到MYSQL的使用ＯＧＧ进行数据迁移中遇到了数据在双向同步数据死循环的问题，在正常对oracle的同步上，我们使用以下参数来防止抽取进程对复制进程提交的事务进行抽取：TRANLOGOPTIONS EXCLUDEUSER OGG GETAPPLOPS  IGNOREREPLICATES实际上tranlogoptions excludeuser　Ｏ

本文摘录于https://tech.meituan.com/2017/04/21/mt-leaf.html2017年04月21日 作者: 照东 文章链接业务系统对生成全局唯一ID的要求有哪些呢？全局唯一性：不能出现重复的ID号，这是最基本的要求。趋势递增：主键的选择应该尽量使用有序的主键保证写入性能。单调递增：保证下一个ID一定大于上一个ID，例如事务版本号、IM增量消息、排序

最近与一个前辈讨论起关于oracle实例恢复的问题，其实以前都研究过，无奈近一年没怎么研究原理性东西，基本大部分都忘光了，所以场面极度尴尬，现在只能好好再来梳理实验一把，并且把mysql的实例恢复也梳理一下。从oracle 的一个事务说起：例如当我们发起一个update 语句更改某一行数据，例如更改zabbix.cwdtest 的 table_name='ICOL$' 为'

这是以前的一篇文章，无意间看到，记录到这里吧。12c可插拔数据库的几种克隆迁移方法Oacle多租户环境包含一个容器数据库(CDB)和零个或多个可插拔数据库(PDB)，这种让数据库系统扩展也变得非常的灵活，oracle 12c提供了许多种关于多租户模式下数据库的克隆迁移方式，以下对于几种克隆迁移的方式进行实验介绍。一．通过现有PDB直接创建（CREATE PLUGGABLE DATABASE..FR

发现自己最近已经焦头烂额，每天在各种繁杂的事务中脑袋已经混乱不堪了。凌晨5点30分，失眠，把我在搞的一个SQL 审核的项目理一理，准备新版本更新上线后就不管了。我的大脑容量真的有限了。这是一个基于github上https://github.com/hhyo/Archery 的一个依赖Inception平台SQL审核系统，我比较喜欢他基于bootstrap 前端的简洁风格。以下是它所用到的

Data Mining and Real Application Testing optionsSQL> SQL> exec DBMS_WORKLOAD_REPLAY.START_REPLAY();BEGIN DBMS_WORKLOAD_REPLAY.START_REPLAY(); END;*ERROR at line 1:ORA-15507: cannot start wo

ORA-19909: datafile 1 belongs to an orphan incarnationORA-01110: data file 1: '+DATA/lvdb_yt/datafile/system.434.969694045'Managed Standby Recovery not using Real Time ApplyWed Jun 19 16:37:04

"op_type":"U","op_ts":"2019-04-30 07:04:36.844662","current_ts":"2019-04-30T15:07:36.778001","pos":"00000016630241124960&quot

生产环境是 一主一从一仲裁3分片的集群，现在发现其中一个节点比当前时间大了好几天，后使用NTP将时间往回调整副本集上。 原来时间是5月3日，当前是 4月26日，对此进行了调整。[root@cwdtest1 bin]# dateFri May  3 13:20:31 CST 2019 [root@cwdtest1 bin]# ntpdate -u 10.205.34.1

1.查看mongodb慢日志是否开起use LogDB;db.getProfilingStatus();2.开启慢日志，设置超过100毫秒的操作为慢操作db.setProfilingLevel(1,100); 3.查看慢日志内容db.system.profile.find().sort({$natural:-1})日志，shard3:PRIMARY> db.system.profi

有一个主表left join 同一个小表两次分页语句，因为order by 导致执行时做排序，从执行计划中Using filesort ，以及profile中creating sort index 耗时可以看出。从trace文件可以看出filesort的计算："join_execution": {      &nbs

主要是分析《MYSQL sql执行过程的一些跟踪分析(二.mysql优化器追踪分析)》中案例的原因，以此记录下：再仔细往上回顾。在以上关联对sql进行转换时，可以发现了以下将s表的deptid 转换成utf8mb4 的情况，即是说，两个表在left join时存在关联字段deptid 字符集不同的情况。on((`SSS`.`d`.`Deptid` = convert(`ppp`.`s`.`Dept

以下 left join语句，d表与s表关联，当where条件在d.deptid上时，s表无法走索引。因此通过开启trace方式做一些追踪。 root@(none) 09:20:20>explain SELECT * FROM SSS.DEPARTMENT d LEFT JOIN&n

    与oracle或其他的数据库都差不多，一条sql的执行主要还是要经历了解析、优化、执行这几个过程，稍微具体下总结，MYSQL的主要过程如下：客户端发起连接-----连接器，主要分配线程，验证权限----分析器，对sql语句语法进行分析-----优化器，生成准确的执行计划-----执行器，执行语句，发起读写数据，返回结果--之后对数据读写是io线程与存储引擎的交互在客户端

OGG-01224 error 111:Connection refused - retries exceeded.目标端进程正常启动，端口开启监听，且没有防火墙限制，但源端p进程一致报出Connection refused错误。2019-01-04 02:25:08  WARNING OGG-01221  Connect failed to 10.101.x.xxx:9902

最近没有研究什么，先整理整理以前的故障分析报告吧！主要是关于一个latch: ges resource hash list和library cache: mutex X并发的故障。1.分析主机负载情况 根据监控所看当时故障期间主要是CPU耗尽，因此查询当时CPU相关日志：VMSTAT:zzz ***Mon Mar 5 08:36:18   CST 2018procs &nbsp