Postgres XL实践与经验小结

本文是基于Postgres-XL 9.5r1.3版本的实践小结,应用于公司新手游“monster”的后台数据库服务。 准备主机环境 操作系统:ubuntu-14.04 集群管控 在这之前有过一次简单的尝试,基于9.2版本,集群搭建和管理使用的是pgxc_ctl脚本,虽然存在一些不足,但核心功能都能比较顺利地实现。这次版本升级后pgxc_ctl出现一些新问题,最终导致放弃pgxc_ctl,转为用shell命令实现符合实际需要的管控脚本。源代码 pgxc_ctl的问题: 配置复杂,一些操作如增删节点、故障转移等,会追加内容到配置文件,导致配置文件越来越混乱难读。 pgxc_ctl的init操作十分危险,会不加提示直接重置集群,导致数据丢失。(新版增加了force参数来区分是否强制重置) 新版pgxc_ctl的init在本应判断

Stunnel安装与实践

概念与用途 维基上介绍Stunnel是一个自由的跨平台软件,用于提供全局的TLS/SSL服务。通俗些讲Stunnel是为服务器和客户端之间的通讯连接提供安全加密的工具。其他类似的实现方法还有使用SSH建立安全连接隧道。 应用场景举例:在一个局域网环境中有一台具有公网地址的主机可以被外界访问。当位于本机或其他内网主机上的服务和应用(如Mysql、Mongodb、Hive、Spark、Http、Shell等)需要被外界安全调用时,可以通过在该主机上配置Stunnel服务,将需要被访问的服务和应用的地址和端口映射为本机的一个开放端口,暴露给外界。外界也通过配置自己的Stunnel服务,访问公网地址和对应端口来获取相关服务。 安装与配置 安装: 创建运行用户: 创建用于加密通讯的证书,并复制证书到需要通讯的两个stunnel端:

记一次系统测试实践

背景 其实并不是一次规范的系统测试,而是对一个已经有两年时间的工程的主要逻辑进行补充测试。由于之前一直都是靠开发者和测试者的人力纯手工测试~并没有单元测试和集成测试代码。随着不断迭代新需求,业务功能的回归测试压力也越来越大。于是,为了快速发现新功能的加入对旧逻辑的影响,决定做一个程序运行的测试方法,来补充人工测试。 这个应用程序是一款手机App的服务端程序,基于spring开发,手机端与服务器主要通过json、fb等数据格式交互。服务端有统一的处理方法,首先将前端请求转为RequestObject,然后经过业务逻辑构造ResponseObject,最后将ResponseObject转换后发给前端。 这次系统测试的思路就是使用终端程序发起各种请求,服务端录制RequestObject和ResponseObject,测试时通过

Postgres XL压力测试与性能调优

实验设备 用于部署postgres-xl的设备 主机:8台 CPU:8核Intel(R) Xeon(R) CPU E5-2650 v3 @ 2.30GHz 内存:32G 磁盘:SSD 系统:Linux 3.10.0-229.el7.x86_64 CentOS 7.1 运行环境 集群:使用pgxl-9.5,每台主机一个datanode、一个coordinator和一个gtm_proxy。 准备工作: 关闭透明大页。 增加运行用户的最大进程数。 修改/proc/sys/kernel/sem。 cat /proc/sys/kernel/sem可以看到四个数字,分别是SEMMSL、SEMMNS、SEMOPM、SEMMNI,主要调整第二、四个核心参数,否则在启动datanode时可能会报错,原因是配置的max_connections

Mongodb集群压力测试与性能调优

实验设备 用于mongodb集群节点的设备 主机:8台 CPU:8核Intel(R) Xeon(R) CPU E5-2650 v3 @ 2.30GHz 内存:32G 磁盘:SSD 系统:Linux 3.10.0-229.el7.x86_64 CentOS 7.1 运行环境 集群:使用mongodb-3.2.6,每台主机一个shard组成分片集群,每台主机一个路由(mongos)作为入口。 准备工作,参考官方文档: 关闭透明大页。 关闭atime。 增加mongodb运行用户的最大进程数。 实验数据和方法 数据库和集合开启分片后导入bson格式数据文件。 小文档数据: data : 697.67MiB docs : 17013091 avg obj size :43B 大文档数据: data : 64.33GiB docs

Putty使用方法记录

PuTTY是一个Telnet、SSH、rlogin、纯TCP以及串行接口连接软件,相似工具还有XShell、SecureCRT等。 下载 从这里下载putty.zip,解压到E:\workspace\tools\putty目录下,可以看到几个exe文件,双击执行PUTTY.EXE可打开PuTTY Configuration界面。 第一个Session 在PuTTY Configuration界面配置以下必要项即可Open一个Session。 Session模板 可以根据自己的习惯和偏好在PuTTY Configuration界面里设置Terminal、Window、Connection等,然后在Session菜单Save为My Template。以后配置新的Session时,首先Load这个My Template,再修改特

Mongodb集群环境下的数据备份与恢复

当mongodb在生产环境运行时,我们除了要保障运行稳定(高可用),还要尽最大可能保障数据安全。通常会思考各种可能出现问题的因素,比如: 配置服务器(configdb)数据没了 分片(shard)数据没了 集合被drop了,数据库被drop了 configdb和shard由于在集群环境下,通常会做多个副本,运行在不同的主机上。一方面提高了可用性,另一方面避免了因为某些磁盘损坏导致的数据丢失。 但是如果有人登入db,有意或无意批量删除了不该删除数据;或者十分不巧,同一shard的所有副本都同时坏的找不回数据,这时我们还需要其他措施进行补救。以下是几个常用的方案和思路。 增加延时同步的副本节点 参考官方文档-延时同步的副本节点 延时同步的副本节点在拿到oplog后不会立即执行,而是等待一段时间后才执行。在一定程度上可以避免因为

Mongodb经验小结

本篇使用Mongodb版本为3.2.6。 在mongodb里执行某些操作时,可能因为输出内容太多而难以查看。办法是先输出到文件再打开查看。 oplog保存在local库的oplog.rs表中,它是个capped collection,默认5%的可用磁盘空间。如果设置过小,且在数据更新操作繁忙的时候创建新副本,会导致新副本集变secondary失败,查看日志会看到相关内容。 mongos进程占用的内存在某些情况下可能会持续增长直到触发oom-killer,导致mongod躺枪,见/var/log/messages。 各项配置中建议使用hostname代替ip,方便组件迁移。 查看shard日志中执行时间大于1000毫秒的操作。 如果日志中提示存在大量jumbo块且需要手动切割执行以下命令。如果目标collection有chu

Mongodb集群搭建与应用

本文基于3.2.3版本搭建最小规模的mongodb分片集群,将简单介绍基本概念和搭建过程,并总结一些使用经验。 基本概念 路由(mongos) 请求的入口,所有请求都经过mongos协调和分发。通常部署多个实例,以便当一个mongos失败时,应用层驱动可以切换到其他正常的实例上。此外也可以通过一组mongos实例实现“池”的概念,在与应用层之间增加一层用于负载均衡的代理,将请求分配到“池”中的mongos实例上。mongos实例本身并不需要磁盘空间存储数据,它启动时会加载config server中的配置数据到内存,当config变化时会被通知更新。 配置服务器(mongod. config server) 存储整个集群的元数据配置信息(路由、分片),mongos通过这些配置作为导向,将读写请求分发到不同的shard上。

在阿里云上构建模拟生产环境的测试环境

为了进行更能反映真实情况的压力和性能测试,我们需要构建更加接近生产环境的测试环境,供QA们使用。由于公司的线上服务都部署在阿里云上,所以产生了租用阿里云服务器,复制生产环境服务器,构建测试环境的想法。 建立拓扑环境 由于生产环境的某些主机或集群的配置对内网ip敏感,如果内网ip变化相应的解析也要调整。所以为了避免ip发生变化,简化构建过程,我们需要创建专有网络环境(VPC),在VPC下通过源机的快照和镜像创建新主机。 阿里云的VPC具有以下特点(摘抄自https://help.aliyun.com/product/8315065_vpc.html): 网段划分。可以将专有网络的私有 IP 地址范围分割成一个或多个虚拟交换机, 根据需要将应用程序和其他服务部署在对应的虚拟交换机下。 自定义路由规则。根据业务需求配置虚拟路由器