ITPub博客

本篇文章介绍Orchestrator raft多节点模式的安装。

之前文章（引用沃趣技术--《当心！使用mysqldump备份可能会让你欲哭无泪》）介绍了当时间字段为timestamp时，使用mysqldump加where条件对时间字段进行过滤导出时，时域问题对导出数据的影响。今天我们就再来讨论一下mysqldump的时域问题。

在这个关于直方图的简短系列中，我们将讨论为什么需要直方图以及Oracle创建它们的方法。我们将评估创建它们的成本以及给我们带来不必要的问题，然后我们将检查它在您的执行计划中给您带来潜在的问题。这篇文章的概述将局限于12c之前的Oracle版本，其中出现了在减少开销和提高稳定性的新型直方图和收集方法。

在这个系列的第5部分，我们看了一些需要额外注意的”第一个子操作先执行”的例子。在第6部分中，我们将继续探讨一个原则—“子查询推入”，其中“第一个子操作先执行”可能会导致错误的结论。

前言上篇文章讲了orchestrator的探测机制。本篇文章翻译自orchestrator官方文档，讲一讲orchestrator的拓扑恢复。拓扑恢复orch能够从一系列故障场景中进行恢复。尤其是，它能够对主库或者中间主库的故障场景进行恢复。自动和手动orch支持：自动恢复（对意外故障采取措施）。优雅地、有计划地主从切换。手动恢复。手动，强制failover。要求要运行任何类型的故障转移，拓扑必须

沃趣科技作为国内领先的数据库云平台解决方案提供商，一直致力于企业级数据库云平台产品的研发，为用户提供高性能、高可用、可扩展的的数据库云环境及不同业务场景需求的数据库平台，满足客户对极致性能、数据安全、容灾备份、业务永续等需求。沃趣科技凭借专业的团队，优质的产品，前沿的技术，贴心的服务赢得了客户的信任与尊重，也获得了市场的认同。————————————————————————————————————

我提出了“子操作按先后顺序执行，递归向下”的解释执行计划的基本策略，但是这并不是一个完美的规则，即使遵循基本的“子操作按先后顺序执行”，也很容易对执行过程中发生的事情产生错误判断。在这部分中，我们将看到几个例子，其中我们仍将在某些情况下使用“子操作按先后顺序执行”，一个BUG的例子使规则看起来是错误的，还有一个示例不适用“子操作按先后顺序执行”。实际上，有几种不同的情况并不适用该规则，但是我们必须

在上一期《复制信息记录表|全方位认识 mysql 系统库》中，我们详细介绍了mysql系统库中的复制信息记录表，本期我们将为大家带来系列第八篇《日志记录等混杂表|全方位认识 mysql 系统库》，下面请跟随我们一起开始 mysql 系统库的系统学习之旅吧！一、日志信息记录表    1.1. 日志信息概述MySQL的日志系统包含：general query log、sl

背   景上篇文章讲了orchestrator单节点的安装。本篇文章我们继续探索orchestrator的旅程，讲一讲orchestrator是如何实现数据库实例复制拓扑的发现。给定实例，如何发现自己这里涉及到两个参数：HostnameResolveMethod、MySQLHostnameResolveMethodHostnameResolveMethod有三个选项：&quot

在第3部分（引用沃趣科技——执行计划-3：解释规则），我们用一个简单的hash join介绍了阅读执行计划最基本的规则---”子操作按先后顺序执行，递归向下“。这让我们了解查询中Oracle生成rowsource的顺序和访问中不同物理对象的顺序（隐式的）。这个系列的开头，我就强调过规则不是适用于所有的场景，下一部分（第5部分）里我们会来看几个我们需要特别注意的场景。但是在这部分中，我们将继续使用更

前两期文章（引用沃趣技术——《prometheus监控多个MySQL实例》、《构建狂拽炫酷屌的MySQL监控平台》）介绍了prometheus、grafana、exporter的安装以及集中监控mysql节点的方法，这篇文章介绍一下prometheus的邮件报警配置。alertmanager下载prometheus报警配置需要用到alertmanager组件，这个组件可以到prometheus官网

Oracle Database Performance Tuning GuideOracle数据库中我们分析一个会话或SQL执行时间效率或者分析解释导致会话等待的原因的一个很重要的方法是分析它花费的时间构成。在Oracle RAC中，Oracle使用不同的等待事件时间来表示不同的请求结果及时间消耗。例如，当一个会话上实例正在寻找全局缓存中的块，它不知道它是否

     背  景MySQL高可用方案有很多种，常见的有：keepalived、MHA、Galera、MGR、Orchestrator、replication-manager等。本系列将介绍在GitHub被使用的Orchestrator方案。本篇文章先介绍最基础的单节点模式的安装。     环  境orchestrat

根据前面系列的文章的解释，我们知道PCM资源的Master节点是通过hash算法得出。那么在一个多节点的RAC集群中，数据块请求节点和存放它的相关锁元素信息节点有很大概率是不相同的。这就意味着用户对资源的请求会存在很多的2或3次回路，从而造成很多的消息通信增加私网的负载进而影响影响数据库的性能。为了缓解这种性能影响，Oracle使用资源的remaster来减少资源的跨节点请求。针对某一个数据库对象

在上一期《时区信息记录表|全方位认识 mysql 系统库》中，我们详细介绍了mysql系统库中的时区信息记录表，本期我们将为大家带来系列第七篇《复制信息记录表|全方位认识 mysql 系统库》，下面请跟随我们一起开始 mysql 系统库的系统学习之旅吧！1、复制信息表概述复制信息表用于在从库在复制主库的数据期间，用于保存从主库转发到从库的二进制日志事件、记录有关中继日志当前状态和位置的信息。一共有

PCM锁资源存储方式有两种，1.如果PCM锁属于本地实例，那么它会被存储在本地实例的LE结构中。2.如果PCM锁属于远程实例那么它将会被分配存储在本地实例的共享池中。kclle结构：    kcllerls表示release;     kcllelnm表示 name（id1，id2）;    kcllemode表示 hold-m

在上一期《优化器成本记录表|全方位认识 mysql 系统库》中，我们详细介绍了mysql 系统库中的优化器成本记录表，本期我们将为大家带来系列第六篇《时区信息记录表|全方位认识 mysql 系统库》，下面请跟随我们一起开始 mysql 系统库的系统学习之旅吧！01 时区信息概述MySQL服务器维护几个时区设置：系统时区：当Server启动时，尝试确定主机的时区并使用它来设置Server的syste

在这系列的前两个部分中，我们列举了一些生成或者找回执行计划的方法，也学习了一些额外的步骤可以帮助我们模拟真实的环境来判断执行计划是否存在问题。这部分我们会熟悉整体解释执行计划的基本准则。在第四部分前，我们不用考虑使用谓词的部分。The Shape of a plan我们会从一个简单的例子开始-创建几张表，连接它们，在我们检查执行计划的时候需要回答提出的问题。这里是数据

上一期《统计信息记录表|全方位认识 mysql 系统库》中，我们详细介绍了mysql系统库中的统计信息记录表，本期我们将为大家带来系列第五篇《优化器成本记录表|全方位认识 mysql 系统库》，下面请跟随我们一起开始 mysql 系统库的系统学习之旅吧！01 优化器成本模型概述为了生成执行计划，优化器使用了基于成本的模型来对各种操作成本进行估算。优化器具有一组可编辑的默认“成本常量”（这些值存储在

一致性读请求  ktrget请求调用流程，调用kcbgtcr获取最佳缓存区域用以构建CR缓冲区，然后调用ktrgcm应用undo构建可用的CR缓存。kcbgtcr计算扫描hash桶，调用ktrexf查找最佳缓存区。如果在缓存区域在本地则结束，如果不在本地则调用kcbzib获得缓存区域。kcbzib请求调用kcbzgb获得一个buffer并且设置buffer的状态为Reading