半个PostgreSQL DBA,热衷于数据库及分布式技术。 - https://github.com/ChenHuajun - https://pan.baidu.com/s/1eRQsdAa
作为以下文章的补充,说明MHA GTID based failover的处理流程。http://blog.chinaunix.net/uid-20726500-id-5700631.html MHA判断是GTID based failover需要满足下面3个条件(参考函数get_g...
iptables防火墙设置示例 CentOS 6.3 iptables的默认设置: 默认只开了ssh的22端口,其它端口上服务监听一律禁止。
初步理解MySQL的gap锁 初识MySQL的gap,觉得这个设计比较独特,和其他数据库的做法不太一样,所以整理一个简单的memo(虽然关于gap锁,相关资料已经很多了) 1. 什么是gap A place in an InnoDB index data structure where new values could be inserted. 说白了gap就是索引树中插入新记录的空隙。
CentOS 7防火墙设置示例 假设需要在CentOS 7上开放postgres,pcsd和corosync(这些是一个PostgreSQL HA集群的组成部分)的防火墙端口。
测试发现PostgreSQL在bitmap index scan时,如果要读入大量堆page,读IO的速度会远低于正常的顺序读,影响性能。 下面用一个例子说明这个问题。
磁盘预读可以改善顺序读的性能,并且测试发现每个读请求的大小也受预读大小的影响,也就是发生了IO合并。 在每次8K的顺序读中,关闭预读时,每个IO是8个扇区(4K); 增大预读,每个IO大概等于预读大小,但最大是设备的单个IO大小的上限(这里是1024)。
现象 1主2从同步复制环境下,在主库上执行了一个vacuum full,结果发现一直无法结束。 [root@db01 data]# ps -ef|grep postgres postgres 26268 1 0 Jun17 ? 00:00:12 /usr/pgsql-9.
前言 full_page_writes用于防范宕机时数据的部分写入导致无法恢复的问题,还有一个好处是加速replay速度,可以避免随机读。但是,full_page_writes对性能的影响也非常大。
关于PostgreSQL的IO 如果数据库的IO出现瓶颈,通常可以通过PG的参数进行调优。为了更好的优化IO应该了解PG的IO。 哪些地方会产生IO? PG产生的IO可以归结到下面这几个地方。
1. https://www.owasp.org 开源web应用安全项目(OWASP)是一个开放的社区,致力于帮助各企业组织开发、购买和维护可信任的应用程序。 2. https://www.
简介 在众多的PostgreSQL HA方案中,流复制HA方案是性能,可靠性,部署成本等方面都比较好的,也是目前被普遍采用的方案。而用于管理流复制集群的工具中,Pacemaker+Corosync又是比较成熟可靠的。
1. 从官网下载mysql5.7的安装包 http://dev.mysql.com/downloads/mysql/ 下载下面几个即可,其它的可选 mysql-community-client-5.
PostgreSQL 9.4.4中文手册1.0版发布说明 ChenHuajun released this 2 days ago 发布说明 《PostgreSQL 9.4.4中文手册》在《PostgreSQL9.3.1中文手册》的基础上翻译而成,山东瀚高的韩悦悦和另一名同事完成了绝大部分的翻译工作。
前段时间我的同事沈龙星整理了一下MHA故障切换和在线切换的代码流程,在征得其同意后,在此转发。以下是正文 本文是以MySQL5.5为基础的,因此没有涉及到gtid相关内容。
Pacemaker中CIB有一个由admin_epoch, epoch, num_updates组合而成的版本,当有节点加入集群时,根据版本号的大小,取其中版本最大的作为整个集群的统一配置。
PostgreSQL的流复制按是否等待slave的反馈分为同步流复制和异步流复制。理所当然,等待slave反馈的就是同步流复制,可以保障在主宕机的情况下安全的切到备机而不发生数据丢失。
关于PostgreSQL的性能调优可以参考《PostgreSQL 9.0 High Performance》,以及朱贤文在2014 PostgreSQL中国用户大会上分享的《高性能Postgres 最佳实践》。
分布式锁和普通锁的主要区别在于参与主体跨不同节点,因此需要考虑到节点失效和网络故障的问题。搞清楚问题要点,可以用各种不同的东西去实现,比如Redis,ZooKeeper等。但是其实用SQL实现也是非常容易的,下面以PostgreSQL为例进行说明。
Pacemaker + Cronsync可以说是目前为止搭建PostgreSQL HA集群最简单靠谱的方式。而完成这一任务的主要是PostgreSQL的RA脚本文件pgsql。关于pgsql的使用说明请参考:http://clusterlabs.org/wiki/PgSQL_Replicated_Cluster 本文探讨一下pgsql的实现逻辑。
CTE是SQL标准定义的语法,很多主流的数据库都支持,但不包括MySQL。 CTE的作用应该主要有两个,下面用PostgreSQL的例子进行演示。 1. 简化查询的写法,相同的语义用子查询会由于嵌套太深而不易理解。
今天发现按照标准SQL写法在MySQL建表时创建的外键都没有生效 ,调查发现MySQL居然没有创建外键(使用的是最新的MySQL 5.7)。 mysql> create table tbp(id int,pid int REFERENCES tb(id) on del...
1.背景 部署基于MySQL原生复制的HA系统时,发现在半同步模式下,半同步复制降级为异步复制的超时时间如果设得很长,会严重影响性能高,这是个很奇怪的现象。 2.现象 组合不同参数,用sysbench做压力测试。
1. 引言 曾经有篇流传较广的文章Don’t Assume PostgreSQL is Slow 展示了PostgreSQL生成序列的速度不亚于redis的INCRs。而在此之前我就曾做过相关的测试(参考PostgreSQL的序列的性能验证),发现PG生成序列的速度远高于同类的关系数据库。根
在我们下定决心将企业核心应用从企业级数据库迁移到开源数据库产品、使用本地磁盘代替共享存储之前。我觉得我们必须要面对并回答以下几个问题之后才能真正的将开源进行到底,将想法付诸于实践。下面我们来看一下我们在将OLTP应用迁移到MySQL数据库之上之前,我们必须要回答的几个问题:(1) ...
1.前言 Pacemaker通过调用各个resource agent提供的操作(比如start,stop)实现对资源的控制,当这个方法执行出错时,Pacemaker会根据执行的操作和错误类型进行不同的错误处理。
1. 背景 LVS是一种非常高效的负载均衡软件实现,尤其是DR模式。但实际部署需要考虑real server的健康状况,并应该根据real server的健康状况或扩容缩容需求及时更新LVS的配置。
1. 问题 执行Mysql的explain extended的输出会比单纯的explain多一列filtered(MySQL 5.7缺省就会输出filtered),它指返回结果的行占需要读到的行(rows列的值)的百分比。
1. 引言 在PostgreSQL中可以用generate_series()函数来快速生成大量测试数据,在MySQL中没有提供类似的东西。那么在做测试的时候,要往表中插入大量数据库该怎么办?可以写一个循环执行INSERT语句的存储过程,但这种方式还是太慢,我试了下,1秒钟居然只能插500条记录。
背景 MySQL 5.7对半同步复制做了一个增强,增加了一个rpl_semi_sync_master_wait_point参数控制master什么时候等待slave的应答。
前段时间在搞MySQL的读负载均衡,最后在LVS和haproxy两个方案之间纠结。本来很倾向于haproxy,因为在我们的KVM虚机环境里LVS老是出一些稀奇古怪的问题(和物理机的设置有关),所以想尽量不用LVS。
1. 引言 脑裂(split-brain),指在一个高可用(HA)系统中,当联系着的两个节点断开联系时,本来为一个整体的系统,分裂为两个独立节点,这时两个节点开始争抢共享资源,结果会导致系统混乱,数据损坏。
用sysbench 0.4.12对PostgreSQL进行压测时遇到了主键约束违反的错误。然后发现原因在于PostgreSQL在并发执行依次更新删除插入同一条记录的事务时(比如就像下面的事务),就可能会报主键约束违反的错误。
MySQL有各种HA方案,其中很多是基于复制的,复制是MySQL原生的数据冗余技术,很容易使用,但要做到无数据丢失却不容易。 异步的复制 默认的复制是异步的,即master commit时不等更新被slave接受就向客户端回话应答成功。
PostgreSQL 9.5中文手册翻译目前已经开始进行,通过github进行翻译的管理,相关流程和说明请参考https://github.com/postgres-cn/pgdoc-cn/wiki/pg9.5 本文介绍如何使用git工具提交翻译后的文档(在参与翻译工作前,请务必仔细阅读上面的wiki页面)。
问题 MySQL的复制存在一个回放延迟的问题,即备机回放的速度赶不上主机SQL执行的速度,导致延迟越来越厉害。原因在于MySQL的binlog回放是单线程,主机的SQL执行是多线程,单线程的回放速度跟不上。
之前在青云的云主机上做过pgbench测试,这次在阿里云上再测一下,数据仅供参考 1. ECS 1.1 环境 CPU: 1核 内存: 1024 MB 带宽:1Mbps(峰值) OS:CentOS 6.
1. full_page_writes的作用 PostgreSQL中的full_page_writes参数用来防止部分页面写入导致崩溃后无法恢复的问题。手册中的相关描述如下: http://postgres.cn/docs/9.3/runtime-config-wal.html#GUC-FULL-PAGE-WRITES full_page_writes (boolean) 打开这个选项的时候,PostgreSQL服务器在检查点之后对页面的第一次写入时将整个页面写到 WAL 里面。
PGConf.EU-2013的一篇名叫《Next generation of GIN》的PPT(作者Alexander Korotkov和Oleg Bartunov)中提到了GIN的几个优化,对GIN的性能都有很大提升。
1. 现象 之前做多字段索引测试的时候发现一个奇怪的现象,btree-gin提供的gin索引在处理1个比较操作的范围查询时性能还行,但处理有2个比较操作的范围查询时性能就很糟糕了。
1. gin索引的部分匹配实现 gin除了可以做某个Key的精确匹配查询,但也能支持匹配一个Key范围的查询。 手册的说明如下: http://www.
前两篇讲的btree和gist的多字段索引,本篇顺理成章地讲一下gin的多字段索引。 前两篇请参考这里:http://blog.chinaunix.net/uid-20726500-id-5088527.htmlhttp://blog.chinaunix.net/uid-20726500-id-5090166.html 1. gin多字段索引的特征 不像gist和btree,gin天生就适合做多字段索引,不管查询条件覆盖所有索引字段还是仅仅覆盖一个子集,它都可以胜任。
1. 问题 有时候查询中会带有多个字段的查询条件,但是其中任何单个字段的选择率都不高,但是多个字段组合起来却有比较好的选择率。这种场景是bitmap索引大显身手的地方,但是bitmap索引对更新性能的影响相当大,不适合OLTP场景。
PostgreSQL的手册中有一段讲可串行化的,大意是可串行化事务读到的数据未必是可靠的,除非它提交成功了。 http://postgres.cn/docs/9.3/transaction-iso.html#XACT-SERIALIZABLE -----------------------------------------------------------------------------------------当依赖于可串行化事务阻止异常现象时,来自永久用户表读取的任何数据,直到读取它的事务成功提交为止,都不被认为是有效的。
目前PostgreSQL 9.3的中文手册虽然已经接近翻译完成,但校对工作严重滞后,文档中有很多地方的翻译还不太理想。有兴趣的童鞋可以参与校对工作,进一步完善PG中文手册。(PG新手也可以把PG的学习和校对工作结合起来做) 详见:https://github.
PostgreSQL9.3中文手册已经在PG中国社区的官网上正式发布了,下面是网址: http://www.postgres.cn/docs/9.3 然而翻译中难免会有一些小错误。所以我们在在线手册的右上角做了个“纠错本页面”的链接,可以跳转到Github对应的文件编辑页面上进行在线纠错。
之前的测试,发现MongoDB的插入操作在使用PHP驱动时比使用mongo控制台更快。测试发现查询也是类似的情况(以下测试都使用WT引擎)。http://blog.chinaunix.net/uid-20726500-id-4998173.
对于我之前的关于Mongodb的插入速度的问题,有网友jasbling2提出了质疑。 http://blog.chinaunix.net/xmlrpc.php?r=blog/article&uid=20726500&id=4981629 这么导入...
之前两篇测试中发现:单点索引查询中PostgreSQL的速度是MongoDB(WiredTiger引擎)的4倍。 http://blog.chinaunix.net/xmlrpc.php?r=blog/article&uid=20726500&id=4960138 http://blog.chinaunix.net/xmlrpc.php?r=blog/article&uid=20726500&id=4981629虽然本人很偏好PG,但也对这个结果表示不能理解。
今年的DTCC大会上,MongoDB中国的唐总带来了《如何在3.0实现7-10倍性能提升》。演讲时顺便倒了点苦水:一些其它数据库喜欢拿MongoDB进行性能PK,但MongoDB之前的开发一直没有怎么关注性能这块,以前也没有发布过官方的性能测试数据,所以结果可想而知。
PostgreSQL9.4带来了全新的NoSQL特性,并且根据EnterpriseDB的测试,其加载,插入和查询的性能都已经几倍于MongoDB了。 虽然我是PG的铁杆粉丝,但是关系数据库背负了ACID的重型装甲,在性能上居然能打败轻装上阵的NoSQL数据库总觉得有点离谱。