heartbeat

安装postgresql CentOS7安装并配置PostgreSQL 安装pgpool rpm -ivh http: // www.pgpool.net/yum/rpms/3.7/redhat/rhel-7-x86_64/pgpool-II-release-3.7-1.noarch.rpm yum -y install pgpool-II- pg95 yum -y install pgpool-II-pg95- debuginfo yum -y install pgpool-II-pg95- devel yum -y install pgpool-II-pg95- extensions 开机启动 systemctl enable pgpool 　 添加Pgpool-II运行用户 [root@im110 pgpool- II]# useradd pgpool [root@im110 pgpool - II]# passwd pgpool Changing password for user pgpool. New password: Retype new password: passwd: all authentication tokens updated successfully. [root@im110 pgpool -II]# chown -R pgpool.pgpool

Rebalance 本质上是一种协议，规定了一个 Consumer Group 下的所有 consumer 如何达成一致，来分配订阅 Topic 的每个分区。 例如：某 Group 下有 20 个 consumer 实例，它订阅了一个具有 100 个 partition 的 Topic 。正常情况下，kafka 会为每个 Consumer 平均的分配 5 个分区。这个分配的过程就是 Rebalance。 0 | 1 触发 Rebalance 的时机 Rebalance 的触发条件有3个。 组成员个数发生变化。例如有新的 consumer 实例加入该消费组或者离开组。 订阅的 Topic 个数发生变化。 订阅 Topic 的分区数发生变化。 Rebalance 发生时，Group 下所有 consumer 实例都会协调在一起共同参与，kafka 能够保证尽量达到最公平的分配。但是 Rebalance 过程对 consumer group 会造成比较严重的影响。在 Rebalance 的过程中 consumer group 下的所有消费者实例都会停止工作，等待 Rebalance 过程完成。 0 | 1 Rebalance 过程分析 Rebalance 过程分为两步：Join 和 Sync。 Join 顾名思义就是加入组。这一步中

消费组组（Consumer group）可以说是kafka很有亮点的一个设计。传统的消息引擎处理模型主要有两种， 队列模型 ，和 发布-订阅模型 。 队列模型 ：早期消息处理引擎就是按照队列模型设计的，所谓队列模型，跟队列数据结构类似，生产者产生消息，就是入队，消费者接收消息就是出队，并删除队列中数据，消息只能被消费一次。 但这种模型有一个问题，那就是只能由一个消费者消费，无法直接让多个消费者消费数据。基于这个缺陷，后面又演化出发布-订阅模型 。 发布-订阅模型 ：发布订阅模型中，多了一个主题。消费者会预先订阅主题，生产者写入消息到主题中，只有订阅了该主题的消费者才能获取到消息。这样一来就可以让多个消费者消费数据。 以往的消息处理引擎大多只支持其中一种模型，但借助kafka的消费者组机制，可以同时实现这两种模型。同时还能够对消费组进行动态扩容，让消费变得易于伸缩。 这篇我们先介绍下消费者组，然后主要讨论kafka著名的重平衡机制。 kafka消费者组 所谓消费者组，那自然是由消费者组成的， 组内可以有一个或多个消费者实例 ，而这些消费者实例共享一个id，称为group id。对了，默认创建消费者的group id是在KAFKA_HOME/conf/consumer.properties文件中定义的，打开就能看到。默认的group id值是test-consumer-group。

1概述 顶新苏州IDC机房配置了四个Linux HA+ Oracle数据库集群。其配置信息如下： 1.1店会系统&FC-arap系统集群 集群资源组名称 ac_group fc_group 集群资源文件挂载点 /ac-oradata /fc-oradata 集群服务IP地址 fmpracora-vip/ 10.0.101.11 fmprfcora-vip/ 10.0.101.12 集群Listener cvs_lsn arap2_lsn 集群数据库 cvsdb arap2db 优先运行的节点名称 fmpracora-priv fmprfcora-priv 优先运行的节点IP 10.0.101.9 10.0.101.10 集群fence通讯IP 10.0.202.15 10.0.202.19 1.2订购-营收&主档-预算检讨-基盘集群 集群资源组名称 ma_group po_group 集群资源文件挂载点 /ma-oradata /po-oradata 集群服务IP地址 fmprmaora-vip/ 10.0.101.7 fmprpoora-vip/ 10.0.101.8 集群Listener arpdb_lsn yingshou_lsn 集群数据库 master_db, arpdb_db dingoudb, yingshou_db 优先运行的节点名称 fmprmaora-priv

3 月，跳不动了？>>> 1. 理解分布式一致性问题 假设我们的分布式系统只有一个节点，我们可以认为他是一个数据库服务端，存储了一个整型数据 我们还有一个客户端，用于访问系统该数据库的数据（读/写） one-node-system.png 显然，对已只有一个节点的系统，我们写操作很简单的得到满足 multi-node-system.png 这就是分布式系统的一致性问题。 在分布式环境中， 一致性是指数据在多个副本之间是否能够保持一致的特性。在一致性的需求下，当一个系统在数据一致的状态下执行更新操作之后， 应该能够保证系统的数据仍然处于一致的状态。 对于一个将数据副本分别在不同分布式节点上的系统来说，如果对于第一个节点的数据进行了更新操作，并且成功更新之后，却没有使得其他节点上的数据得到相应的更新，于是在对第二个节点的数据进行读操作时，获取的是老数据（脏数据），这就是典型的分布式数据不一致的情况。 在一个分布式系统中，如果能够做到针对一个数据项的更新操作执行成功之后，所有的用户都可以读取到其中的最新值，那么这样的系统就被认为是具有强一致性（严格一致性）。 当然，在有些分布式系统实现中，并不需要实时保证系统数据的强一致性，它允许数据存在中间状态，并认为该中间状态不会影响系统的整体可用性（允许数据在不同节点之间的同步存在延时），在经过一段时间之后，最终能够达到一个一致的状态

3 月，跳不动了？>>> 本文主要分析一下NettyServer，HeaderExchangeServer实现细节。 1、NettyServer NettyServer整个类图如下： 首先从全貌上大概看一下NettyServer对象所持有的属性： AbstractPeer private final ChannelHandler handler 事件处理Handler。 private volatile URL url 该协议的第一个服务提供者的URL， Server只需要用到 URL中的参数，与具体某一个服务没什么关系。 AbstractEndpoint private Codec2 codec 编码解码器。 private int timeout 超时时间 private int connectTimeout 连接超时时间 AbstractServer private InetSocketAddress localAddress ：url host:port地址。 private InetSocketAddress bindAddress：如果是多网卡，并且指定了 bind.ip、bind.port，如果为空，与localAddress相同。 private int accepts ： AbstractServer#accepts未使用到。 private int

MyCat基本知识 一.Mycat基本元素 1.逻辑库，mycat中存在，对应用来说相当于mysql数据库，后端可能对应了多个物理数据库，逻辑库中不保存数据 2.逻辑表，逻辑库中的表，对应用来说相当于mysql的数据表，后端可能对应多个物理数据库中的表，也不保存数据 逻辑表分类 1.分片表，进行了水平切分的表，具有相同表结构但存储在不同数据库中的表，所有分片表的集合才是一张完整的表 2.非分片表，垂直切分的表，一个数据库中就保存了一张完整的表 3.全局表，所有分片数据库中都存在的表，如字典表，数量少，由mycat来进行维护更新 4.ER关系表，mycat独有，子表依赖父表，保证在同一个数据库中 二.安装mycat 1.配置环境变量 export JAVA_HOME=/usr/lib/jdk1.8.0_20 export JRE_HOME=$JAVA_HOME/jre export CLASSPATH=.:$JAVA_HOME/lib:$JER_HOME/lib:$CLASSPATH export PATH=$JAVA_HOME/bin:$JER_HOME/bin:$PATH:/usr/local/mycat/bin export MYCAT_HOME=/usr/local/mycat export ZOOKEEPER_HOME=/usr/ local/zookeeper-3.4

系统开发中，数据库是非常重要的一个点。除了程序的本身的优化，如：SQL语句优化、代码优化，数据库的处理本身优化也是非常重要的。主从、热备、分表分库等都是系统发展迟早会遇到的技术问题问题。Mycat是一个广受好评的数据库中间件，已经在很多产品上进行使用了。希望通过这篇文章的介绍，能学会Mycat的使用。 安装 Mycat官网： http://www.mycat.io/ 可以了解下Mycat的背景和应用情况，这样使用起来比较有信心。 Mycat下载地址： http://dl.mycat.io/ 官网有个文档，属于详细的介绍，初次入门，看起来比较花时间。 下载： 建议大家选择 1.6-RELEASE 版本，毕竟是比较稳定的版本。 安装： 根据不同的系统选择不同的版本。包括linux、windows、mac,作者考虑还是非常周全的，当然，也有源码版的。（ps:源码版的下载后，只要配置正确，就可以正常运行调试，这个赞一下。） Mycat的安装其实只要解压下载的目录就可以了，非常简单。 安装完成后，目录如下： 目录 说明 bin mycat命令，启动、重启、停止等 catlet catlet为Mycat的一个扩展功能 conf Mycat 配置信息,重点关注 lib Mycat引用的jar包，Mycat是java开发的 logs 日志文件，包括Mycat启动的日志和运行的日志。 配置

多图文，详细介绍mysql各个集群方案 集群的好处 高可用性：故障检测及迁移，多节点备份。 可伸缩性：新增数据库节点便利，方便扩容。 负载均衡：切换某服务访问某节点，分摊单个节点的数据库压力。 集群要考虑的风险 网络分裂：群集还可能由于网络故障而拆分为多个部分，每部分内的节点相互连接，但各部分之间的节点失去连接。 脑裂：导致数据库节点彼此独立运行的集群故障称为“脑裂”。这种情况可能导致数据不一致，并且无法修复，例如当两个数据库节点独立更新同一表上的同一行时。 @[toc] 一，mysql原厂出品 1，MySQL Replication mysql复制（MySQL Replication），是mysql自带的功能。 原理简介： 主从复制是通过重放binlog实现主库数据的异步复制。即当主库执行了一条sql命令，那么在从库同样的执行一遍，从而达到主从复制的效果。在这个过程中，master对数据的写操作记入二进制日志文件中(binlog)，生成一个 log dump 线程，用来给从库的 i/o线程传binlog。而从库的i/o线程去请求主库的binlog，并将得到的binlog日志写到中继日志（relaylog）中，从库的sql线程，会读取relaylog文件中的日志，并解析成具体操作，通过主从的操作一致，而达到最终数据一致。 MySQL Replication一主多从的结构

实现web高可用 [root@data-1-2 ha.d]# yum install httpd -y [root@data-1-1 ha.d]# yum install httpd -y root@data-1-1 ha.d]# /etc/init.d/httpd start root@data-1-2 ha.d]# /etc/init.d/httpd start [root@data-1-1 ha.d]# cd /var/www/html [root@data-1-1 html]# echo data-1-1 >index.html访问测试 输入虚拟ip http://192.168.0.7/ [root@data-1-2 ha.d]# cd /var/www/html [root@data-1-2 html]# echo data-1-2 >index.html访问测试 /usr/share/heartbeat/hb_standby data1 /usr/lib64/heartbeat/hb_standby 高可用 [root@data-1-2 ha.d]# vi haresources data-1-1 IPaddr::192.168.0.7/24/eth0 httpd控制程序启动 data-1-2 IPaddr::192.168.0.8/24/eth0 httpd