heartbeat

聊聊maxwell的Recovery

坚强是说给别人听的谎言 提交于 2020-05-09 21:16:26
序 本文主要研究一下maxwell的Recovery Recovery maxwell-1.25.1/src/main/java/com/zendesk/maxwell/recovery/Recovery.java public class Recovery { static final Logger LOGGER = LoggerFactory.getLogger(Recovery.class); private final ConnectionPool replicationConnectionPool; private final RecoveryInfo recoveryInfo; private final MaxwellMysqlConfig replicationConfig; private final String maxwellDatabaseName; private final RecoverySchemaStore schemaStore; public Recovery(MaxwellMysqlConfig replicationConfig, String maxwellDatabaseName, ConnectionPool replicationConnectionPool, CaseSensitivity caseSensitivity,

NFS+DRBD+HEARTBEAT快速实施方案

南楼画角 提交于 2020-05-08 04:58:53
存储高可用NFS+DRBD+HEARTBEAT快速实施方案 环境: nfs-utils-1.2.3-75.el6_9.x86_64 heartbeat-3.0.4-2.el6.x86_64 drbd84-utils-8.9.8-1.el6.elrepo.x86_64 CentOS release 6.7 (Final) 2.6.32-573.el6.x86_64 x86_64 规划表: 名称 接口 IP 用途 Master eth0 10.0.0.31 管理IP eth1 172.16.1.31 心跳线 Backup eth0 10.0.0.32 管理IP eth1 172.16.1.32 心跳线 VIP eth0 10.0.0.30 提供NFS存储服务IP 以下操作除特殊说明外,均为在两台服务器操作 初始化 关闭selinux,iptables 配置主机名,/etc/hosts,/etc/sysconfig/network,配置网络配置 分区 parted /dev/sdb mklabel gpt parted /dev/sdb mkpart primary 0 1024 parted /dev/sdb mkpart primary 1025 2146 parted /dev/sdb p 主NFS格式化/dev/sdb1,从NFS不需要格式化(特殊说明) mkfs.ext4

聊聊maxwell的BinlogConnectorDiagnostic

只谈情不闲聊 提交于 2020-05-06 22:50:07
序 本文主要研究一下maxwell的BinlogConnectorDiagnostic MaxwellDiagnostic maxwell-1.25.1/src/main/java/com/zendesk/maxwell/monitoring/MaxwellDiagnostic.java public interface MaxwellDiagnostic { String getName(); boolean isMandatory(); String getResource(); CompletableFuture<MaxwellDiagnosticResult.Check> check(); } MaxwellDiagnostic接口定义了getName、isMandatory、getResource、check方法;check方法返回的是MaxwellDiagnosticResult.Check类型的CompletableFuture MaxwellDiagnosticResult maxwell-1.25.1/src/main/java/com/zendesk/maxwell/monitoring/MaxwellDiagnosticResult.java public class MaxwellDiagnosticResult { private final

Linux实战教学笔记30:Nginx反向代理与负载均衡应用实践

醉酒当歌 提交于 2020-05-05 21:49:20
1.1 集群简介 简单地说,集群就是指一组(若干个)相互独立的计算机,利用高速通信网络组成的一个较大的计算机服务系统,每个集群节点(即集群中的每台计算机)都是运行各自服务的独立服务器。这些服务器之间可以彼此通信,协同向用户提供应用程序,系统资源和数据,并以单一系统的模式加以管理。当用户客户机请求集群系统时,集群给用户的感觉就是一个单一独立的服务器,而实际上用户请求的是一组集群服务器。 打开谷歌,百度的页面,看起来好简单,也许你觉得用几分钟就可以制作出相似的网页,而实际上,这个页面的背后是由成千上万台服务器集群协同工作的结果。而这么多的服务器维护和管理,以及相互协调工作也许就是同学们未来的工作职责了。 若要用一句话描述集群,即一堆服务器合作做同一件事,这些机器可能需要整个技术团队架构,设计和统一协调管理,这些机器可以分布在一个机房,也可以分布在全国全球各个地区的多个机房。 1.2 为什么要使用集群 (1)高性能 一些国家重要的计算密集型应用(如天气预报,核试验模拟等),需要计算机有很强的运算处理能力。以全世界现有的技术,即使是大型机,其计算能力也是有限的,很难单独完成此任务。因为计算时间可能会相当长,也许几天,甚至几年或更久。因此,对于这类复杂的计算业务,便使用了计算机集群技术,集中几十上百台,甚至成千上万台计算机进行计算。 假如你配一个LNMP环境,每次只需要服务10个并发请求

聊聊maxwell的PositionStoreThread

坚强是说给别人听的谎言 提交于 2020-05-05 11:26:57
序 本文主要研究一下maxwell的PositionStoreThread PositionStoreThread maxwell-1.25.1/src/main/java/com/zendesk/maxwell/schema/PositionStoreThread.java public class PositionStoreThread extends RunLoopProcess implements Runnable { static final Logger LOGGER = LoggerFactory.getLogger(PositionStoreThread.class); private Position position; // in memory position private Position storedPosition; // position as flushed to storage private final MysqlPositionStore store; private MaxwellContext context; private Exception exception; private Thread thread; private BinlogPosition lastHeartbeatSentFrom; // last position

聊聊maxwell的MysqlPositionStore

走远了吗. 提交于 2020-05-04 10:39:30
序 本文主要研究一下maxwell的MysqlPositionStore MysqlPositionStore maxwell-1.25.1/src/main/java/com/zendesk/maxwell/schema/MysqlPositionStore.java public class MysqlPositionStore { static final Logger LOGGER = LoggerFactory.getLogger(MysqlPositionStore.class); private static final Long DEFAULT_GTID_SERVER_ID = new Long(0); private final Long serverID; private String clientID; private final boolean gtidMode; private final ConnectionPool connectionPool; public MysqlPositionStore(ConnectionPool pool, Long serverID, String clientID, boolean gtidMode) { this.connectionPool = pool; this.clientID = clientID;

keepalived是什么及作用

末鹿安然 提交于 2020-05-04 00:06:42
keepalived是什么 keepalived是集群管理中保证集群高可用的一个服务软件,其功能类似于heartbeat,用来防止单点故障。 keepalived工作原理 keepalived是以VRRP协议为实现基础的,VRRP全称Virtual Router Redundancy Protocol,即虚拟路由冗余协议。 虚拟路由冗余协议,可以认为是实现路由器高可用的协议,即将N台提供相同功能的路由器组成一个路由器组,这个组里面有一个master和多个backup,master上面有一个对外提供服务的vip(该路由器所在局域网内其他机器的默认路由为该vip),master会发组播,当backup收不到vrrp包时就认为master宕掉了,这时就需要根据VRRP的优先级来选举一个backup当master。这样的话就可以保证路由器的高可用了。 keepalived主要有三个模块,分别是core、check和vrrp。core模块为keepalived的核心,负责主进程的启动、维护以及全局配置文件的加载和解析。check负责健康检查,包括常见的各种检查方式。vrrp模块是来实现VRRP协议的。 keepalived的配置文件 keepalived只有一个配置文件keepalived.conf,里面主要包括以下几个配置区域,分别是global_defs、static_ipaddress

Android Healthd电池服务分析

烂漫一生 提交于 2020-05-04 00:01:55
healthd healthd是安卓4.4之后提出来的,监听来自kernel的电池事件,并向上传递电池数据给framework层的BatteryService。BatteryService计算电池电量显示,剩余电量,电量级别以及绘制充电动画等信息,其代码位于/system/core/healthd。 android/system/core/healthd/ Android.mk BatteryMonitor.h BatteryPropertiesRegistrar.h healthd.cpp healthd_mode_android.cpp images BatteryMonitor.cpp BatteryPropertiesRegistrar.cpp healthd_board_default.cpp healthd.h healthd_mode_charger.cpp 下面一张图清晰的表示了Android电池系统框架 healthd服务入口:android/system/core/healthd/healthd.cpp 中main函数。 int main(int argc, char **argv) { int ch; int ret; klog_set_level(KLOG_LEVEL); //healthd_mode_ops是一个关于充电状态的结构体变量, healthd

keepalived是什么及作用?

白昼怎懂夜的黑 提交于 2020-05-03 21:06:14
参考: https://www.cnblogs.com/hqjy/p/7615439.html keepalived介绍 keepalived观察其名可知,保持存活,在网络里面就是保持在线了, 也就是所谓的高可用或热备,它集群管理中保证集群高可用的一个服务软件, 其功能类似于heartbeat,用来防止 单点故障(单点故障是指一旦某一点出现故障就会导致整个系统架构的不可用)的发生 。 说到keepalived就不得不说VRRP协议,可以说这个协议就是keepalived实现的基础,那么首先我们来看看VRRP协议。 VRRP协议介绍 学过网络的朋友都知道,网络在设计的时候必须考虑到冗余容灾,包括线路冗余,设备冗余等,防止网络存在单点故障,那在路由器或三层交换机处实现冗余就显得尤为重要。 在网络里面有个协议就是来做这事的,这个协议就是VRRP协议,Keepalived就是巧用VRRP协议来实现高可用性(HA)的发生。 VRRP全称Virtual Router Redundancy Protocol,即虚拟路由冗余协议。对于VRRP,需要清楚知道的是: 1)VRRP是用来实现路由器冗余的协议。 2)VRRP协议是为了消除在静态缺省路由环境下路由器单点故障引起的网络失效而设计的主备模式的协议, 使得发生故障而进行设计设备功能切换时可以不影响内外数据通信,不需要再修改内部网络的网络参数。 3

Kafka学习总结、Kafka与RabbitMQ的区别

一曲冷凌霜 提交于 2020-05-02 17:44:21
初识Kafka Kafka是一个分布式的发布-订阅消息系统,能够支撑海量数据的数据传递。在离线和实时的消 息处理业务系统中,Kafka都有广泛的应用。Kafka将消息持久化到磁盘中,并对消息创建了备份保证了 数据的安全。Kafka在保证了较高的处理速度的同时,又能保证数据处理的低延迟和数据的零丢失。 特性 高吞吐量、低延迟:kafka每秒可以处理几十万条消息,它的延迟最低只有几毫秒,每个主题可以 分多个分区, 消费组对分区进行消费操作; 可扩展性:kafka集群支持热扩展; 持久性、可靠性:消息被持久化到本地磁盘,并且支持数据备份防止数据丢失; 容错性:允许集群中节点失败(若副本数量为n,则允许n-1个节点失败); 高并发:支持数千个客户端同时读写; 使用场景 日志收集:一个公司可以用Kafka可以收集各种服务的log,通过kafka以统一接口服务的方式开放 给各种consumer,例如Hadoop、Hbase、Solr等; 消息系统:解耦和生产者和消费者、缓存消息等; 用户活动跟踪:Kafka经常被用来记录web用户或者app用户的各种活动,如浏览网页、搜索、点 击等活动,这些活动信息被各个服务器发布到kafka的topic中,然后订阅者通过订阅这些topic来做实时 的监控分析,或者装载到Hadoop、数据仓库中做离线分析和挖掘; 运营指标:Kafka也经常用来记录运营监控数据