关系型数据库

PostgreSQL 持续在基于fdw的sharding技术上深耕，9.6开始，在符合条件的前提下，支持JOIN和SORT下推到数据节点执行。下面是一个测试创建几个shard库 for subfix in 0 1 2 3 do psql -c "create database db$su

很多业务也行有这样的需求，新的数据会不断的插入，并且可能会有更新。对于更新的数据，需要记录更新前的记录到历史表。 这个需求有点类似于审计需求，即需要对记录变更前后做审计。我以前有写过使用hstore和触发器来满足审计需求的文档，有兴趣的同学可以参考http://blog.163.com/digoa

安装驱动 yum install -y unixODBC.x86_64 yum install -y postgresql-odbc.x86_64 查看驱动配置 cat /etc/odbcinst.ini # Example driver definitions

有一天小编胡乱写SQL, left join了30张表, 结果导致了Mysql server gone away… 我们来看看crash堆栈 <signal handler called> base_list_iterator::next update_ref_and_keys make_

一条SQL在PG中的执行过程是： ----> SQL输入 ----> 解析SQL，获取解析后的语法树 ----> 分析、重写语法树，获取查询树 ----> 根据重写、分析后的查询树计算各路径代价，从而选择一条成本最优的执行树 ----> 根据执行树进行执行 ----> 获取结果并返回

TokuDB日志子系统 MySQL重启后自动加载InnoDB和其他的动态plugin，包括TokuDB。每一plugin在注册的时候指定init和deinit回调函数。TokuDB的init/deinit函数分别是tokudb_init_func和tokudb_done_func。 MySQL重

背景 作为云计算的服务提供者，我们在向用户提供优秀的服务能力时会遇到一个合规的问题。在数据库领域，数据是极其敏感和珍贵的，保护好数据，就如保护好企业的生命线。因此，需要采取一些预防措施来帮助保护数据库的安全，如设计一个安全系统、加密机密资产以及在数据库服务器的周围构建防火墙。但是，如果遇到物理介质

背景 社区 PostgreSQL 和 GreenPlum 都提供了读写外部数据源的方法，它们都提供了一套编程接口，用户可以在这上面做二次开发，建立外部数据源和数据库间的数据通道。 本文介绍 PostgreSQL 和 GreenPlum 这部分编程接口的实现和编程方法。结合 RDS 开发的 oss

背景 innodb buffer pool做为innodb最重要的缓存，其缓存命中率的高低会直接影响数据库的性能。因此在数据库发生变更，比如重启、主备切换实例迁移等等，innodb buffer poll 需要一段时间预热，期间数据库的性能会受到明显影响。 另外mysql 5.7以前innodb

本文旨在帮助用户理解PostgreSQL的逻辑结构和权限体系，帮助用户快速的理解和管理数据库的权限。 逻辑结构 最上层是实例，实例中允许创建多个数据库，每个数据库中可以创建多个schema，每个schema下面可以创建多个对象。 对象包括表、物化视图、操作符、索引、视图、序列、函数、… 等等。

1. 背景 MySQL 5.7在2015-10-21发布了GA版本，即5.7.9，目前小版本已经到了5.7.12。5.7新增了许多新的feature和优化，接下来一个系列，我们就一起来尝尝鲜。首先这次主要是预览feature的变化以及兼容性问题。后面的系列，会针对重要的feature展开来学习。

最近有幸前去美国参加Percona Live 2016会议并分享了我们最近在MySQL复制上所做的工作，也就是基于InnoDB的物理复制。会后很多小伙伴私信我说分享的PPT太内核了，不太容易理解。因此本文主要针对分享的内容进行展开描述，希望能对大家有所帮助。 背景知识 在开始之前，你需要对Inn

问题描述 某TokuDB实例备库发生复制中断,报错信息甚是诡异： Error executing row event: "Can't lock file (errno: 22 - Invalid argument)" 经过gdb core后，大体知道了发生错误的原因： TokuDB在

背景介绍 TokuDB采用的是Fractal Tree作为索引的数据组织方式。它是一种面向磁盘I/O优化的数据结构，采用“分期偿还”策略减少在数据插入过程中从root节点到leaf节点的搜索过程。这种搜索过程可以简称为locate_position，就是寻找要插入key在Tree中位置的过程。

前言 只读实例是目前 RDS 用户实现数据读写分离的一种常见架构，用户只需要将业务中的读请求分担到只读节点上，就可以缓解主库查询压力，同时也可以把一些 OLAP 的分析查询放到另外的只读节点上，减小复杂统计查询对主库的冲击，RDS只读节点架构图如下： 由于RDS只读节点采用原生的MySQL

背景 在分布式K-V存储系统中，对某个key进行读写时，会根据该key的hash计算出一台固定的server来存取该K-V，如果集群不发生服务器数量变化，那么这一映射关系就不会变化。 云数据库 memcached 就是这样一种K-V缓存系统。在实际应用中的某些高峰时段，有的云数据库 memcac

背景 本文主要介绍PostgreSQL 在中高端x86服务器上的数据插入速度（目标表包含一个时间字段的索引），帮助企业用户了解PostgreSQL在这类场景下的性能表现。 这类场景常见于运营商网关数据和金融行业数据，产生量大，并且要求快速插入大数据库中持久化保存。另外, 用户如果需要流式实时

背景 并行复制可以大大提高备库的 binlog 应用速度，内核月报也多次对并行复制特性进行介绍，感兴趣的朋友可以回顾下：5.6 并行复制实现分析、5.6 并行复制恢复实现 和 5.6并行复制事件分发机制。 在早期的内核月报，有一篇 并行复制外建约束问题，介绍阿里在 5.5 版本中自己实现并行复制

问题背景 GPDB是中央控制节点式的架构，在一个 GreenPlum 集群中，有一个 Master 节点和多个 Segment 节点。Master 是中央控制节点，Segment 是数据存放节点。所有的Segment节点平等，均由Master管理。架构如下图： GreenPlum架构图

事务一致性 这篇月报Primary和Mirror同步机制讲了Primary和Mirror之间各种数据和文件的同步过程。这些数据和文件的同步，看似彼此独立。那么如何保证某个时间点Mirror的所有数据是一致的，即任何时间点发生HA切换，Mirror都能达到一致性状态并对外提供服务？正如我们前面提到的

参数简介 innodb_additional_mem_pool_size 是 InnoDB 用来保存数据字典信息和其他内部数据结构的内存池的大小，单位是 byte，参数默认值为8M。数据库中的表数量越多，参数值应该越大，如果 InnoDB 用完了内存池中的内存，就会从操作系统中分配内存，同时在 e

前言 最近一段时间处理了较多锁的问题，包括锁等待导致业务连接堆积或超时，死锁导致业务失败等，这类问题对业务可能会造成严重的影响，没有处理经验的用户往往无从下手。下面将从整个数据库设计，开发，运维阶段介绍如何避免锁问题的发生，提供一些最佳实践供RDS的用户参考。 设计阶段 在数据库设计阶段，引擎

背景 在mysql主备环境下，主备同步过程如下，主库更新产生binlog, 备库io线程拉取主库binlog生成relay log。备库sql线程执行relay log从而保持和主库同步。 理论上主库有更新时，备库都存在延迟，且延迟时间为备库执行时间+网络传输时间即t4-t2。 那

前言 FTS(Fault Tolerance Serve)是GreenPlum中的故障检测服务，是保证GP高可用的核心功能。GreenPlum的Segment的健康检测及HA是由GP Master实现的，GP Master上面有个专门的进程–FTS进程，它可以快速检测到Primary或者Mirro

前言 Percona XtraBackup（简称PXB）是 Percona 公司开发的一个用于 MySQL 数据库物理热备的备份工具，支持 MySQl（Oracle）、Percona Server 和 MariaDB，并且全部开源，真可谓是业界良心。我们 RDS MySQL 的物理备份就是基于这个

背景 InnoDB buffer pool中的page管理牵涉到两个链表，一个是lru链表，一个是flush 脏块链表，由于数据库的特性： 脏块的刷新，是异步操作； page存在两个版本，一个是ibd文件的持久化版本，和buffer pool内存中的当前版本。 所以在对table对象进行dd

背景 SQLServer Agent作为Windows服务提供给用户定期执行管理任务，这些任务被称为Job；考虑应用镜像的场景如何解决Job同步问题，AWS RDS的做法是不予理会，由用户维护Job，假如发生切换用户需要在新的Principal端创建Job；另一种做法是镜像端保持同步Job，切换后

背景知识 数据库优化器需要具备逻辑推理能力，而且越强越好，为什么呢？ 举一些例子， 通过已知的一个人讲的是真话，推理另一个人讲的一定是真话或一定是假话。 例子1： 假设预先提供了 a > 10 是真话 可以推理出 a < 1 一定是假话 例子2： 假设预先提供了 a > 10 是真话

前言 之前有篇月报是关于innodb事务子系统的《MySQL · 引擎特性 · InnoDB 事务子系统介绍》 里面较详细的讲述了 MySQL 如何开启一个事务，感兴趣的同学可以先阅读那篇温习一下。 TokuDB 引擎也支持事务，保证一个事务内的所有操作都执行成功或者都未被执行。TokuDB

背景 用户在使用mysqldump导数据上云的时候碰到两个“诡异”的问题，简单分析分享下。 TIP 1 --port端口无效? 本地有3306和3307两个端口的实例，执行命令为: mysqldump --host=localhost --port=300x -Ddb1 db1 -r out

概述 MySQL 原有线程调度方式有每个连接一个线程(one-thread-per-connection)和所有连接一个线程（no-threads）。 no-threads一般用于调试，生产环境一般用one-thread-per-connection方式。one-thread-per-conne

简介 简单来说，MariaDB（MySQL）的复制机制是这样的： 在Master端所有数据库的变更（包括DML和DDL）都会以 Binlog Event 的方式写入Binlog中。Slave会连上Master然后读取 Binlog Event，再重放这些操作到自身的数据中。一个实例可以既是Mas

简介 本文以工业界测试模型TPC-C为测试模型，介绍PostgreSQL数据库从系统层面的优化到数据库层面的优化方法。 TPmC从 256195.32 提升到 606466.31 是如何做到的。 测试环境介绍 16核开HT共32线程 256G 1600MHz 内存 万兆网卡 3 块 6

TokuDB之黑科技工具 刚过完年，美女程序员静静想学习下 TokuDB 相关技术，从何处入手呢？TokuDB的技术资料可是出了名的少！ 本篇就给大家介绍下两个“黑科技”工具，来帮助我们更深入的了解TokuDB。 黑科技之tokuftdump 此工具用来dump一个Fractal-Tree结

背景 随着PG9.5 项目的release，属于PG9.6的代码也陆续进入代码主干，其中最让人激动的特性并行查询终于进入了核心代码。pger们对这个新特性期待了太久的时间,代码刚提交我们就迫不及待的拿到，从设计到性能进行一番探究，并通过本文介绍给大家。 并行技术的过去和未来 这是个很困难的工作

大会概况 2月3号到5号，受邀去莫斯科参加了PgConf.Russia大会，这里介绍一下大会的一些见闻。 此次大会的新闻报道见此链接。此次会议有多达600多人参加，聚集了俄罗斯地区的PG相关厂商、DBA和开发者。大会邀请了20多位来自俄罗斯之外的国际演讲者，包括PG核心开发团队的大佬Bruce

背景 在写压力负载比较重的MySQL实例上，InnoDB可能积累了较长的没有被purge掉的transaction history，导致实例性能的衰减，或者空闲空间被耗尽，下面就来看看它是怎么产生的，或者有没有什么方法来减轻，避免这样的问题出现。 InnoDB purge 概要 InnoDB是

综述 在前一篇我们介绍了InnoDB文件系统的物理结构，本篇我们继续介绍InnoDB文件系统的IO接口和内存管理。 为了管理磁盘文件的读写操作，InnoDB设计了一套文件IO操作接口，提供了同步IO和异步IO两种文件读写方式。针对异步IO，支持两种方式：一种是Native AIO，这需要你在编译

综述 从上层的角度来看，InnoDB层的文件，除了redo日志外，基本上具有相当统一的结构，都是固定block大小，普遍使用的btree结构来管理数据。只是针对不同的block的应用场景会分配不同的页类型。通常默认情况下，每个block的大小为 UNIV_PAGE_SIZE，在不做任何配置时值为1

bloom filter是一个有损过滤器，使用有限的比特位存储一些唯一值集合所产生的bits。通过这些bits可以满足这样的场景需求，给定一个值，判断这个值是否属于这个集合。例如 create table test(c1 int); insert into test select trunc

背景 上一期月报MariaDB on Power8我介绍了下 MariaDB 为 Power 处理器所做的一些优化，但是并没有给出实际测试的效果，这次月报我们借到了一台Power8的机器，有机会亲自试一把 MariaDB 在 Power 上的表现。 环境 一切不交代测试场景的Benchmark

背景 有一个功能，是社区官方版”永远”不考虑引入的(参见PG TODO，查找”Oracle-style”)，即类似Oracle的Plan Hint。社区开发者的理念是，引入Hint功能，会掩盖优化器本身的问题，导致缺陷不被暴露出来。但对于我们的使用者来讲，遇到某些SQL的查询计划不好，性能出了问题

背景 server A,B 为双主结构，对于 server A 当gtid_next设置为AUTOMATIC时，A上执行的事务在binlog刷盘时递增获取事务的gtid，从而保证了在binlog中属于A的gtid是连续递增的。 A的binlog在B应用时，B会通过 Executed_Gtid_S

背景 系统为了加速对象的访问，通常都会增加一层缓存，以缓解下一层IO的瓶颈，OS的page cache和数据库的buffer pool都基于此。 但对象的删除，如果同步清理对象的缓存的话，不仅大大增加了延时，同时可能因为缓存过大导致IO blooding。所以针对缓存的清理，都会采用lazy d

介绍 TokuDB也有类似InnoDB的buffer pool叫做cachetable，存储数据节点（包括叶节点和中间节点）和rollback段，本文中为了表达简单，叶节点，中间节点和rollback段统称数据节点。Cachetable是全局唯一的，它与MySQL实例存在一一对应的关系。TokuD

背景 本文对 5.6 主备场景下，在备库做物理备份遇到死锁的case进行分析，希望对大家有所帮助。 这里用的的物理备份工具是 Percona-XtraBackup(PXB)，有的同学可能不清楚其备份流程，所以这里先简单说下，PXB的备份步骤是这样的： 拷贝 InnoDB redo log，这是

上一篇文章咱们对 ICP 进行了一次全面的分析，本篇文章小编继续为大家分析优化器的另外两个选项: MRR & batched_key_access(BKA) ，分析一下他们的作用、原理、相互关系、源码实现以及使用范围。 什么是 MRR MRR 的全称是 Multi-Range Read Opti

介绍 本文将介绍 MySQL 5.7 中如何实现非结构化（JSON）数据的存储，在介绍 MySQL 5.7 的非结构化数据存储之前，首先介绍在之前的 MySQL 的版本中，用户如何通过 BLOB 实现 JSON 对象的存储，以及这样处理的缺点是什么，这些缺点也就是 MySQL 5.7 支持 JSO

PostgreSQL 主备同步机制是通过流复制实现，其原理见之前的月报PG主备流复制机制。 Greenplum 是基于PostgreSQL开发的，它的主备也是通过流复制实现，但是Segment节点中的Primary和Mirror之间的数据同步是基于文件级别的同步实现的。为什么Primary和Mir

前言 本文的目的是对 InnoDB 的事务锁模块做个简单的介绍，使读者对这块有初步的认识。本文先介绍行级锁和表级锁的相关概念，再介绍其内部的一些实现；最后以两个有趣的案例结束本文。 本文所有的代码和示例都是基于当前最新的 MySQL5.7.10 版本。 行级锁 InnoDB 支持到行级别