master

MHA高可用集群 文章目录 一、MHA 简介： 二、部署 MHA： 第一步：三台主从服务器安装 mysql 第二步：修改 mysql 的主配置文件：/etc/my.cnf ，注意三台服务器的 server-id 不能一样 第三步：三台服务器启动 mysql 服务 第四步：配置 Mysql 主从同步（一主两从） 第五步：安装 MHA 第六步：启动 MHA 一、MHA 简介： MHA（Master High Availability） （1）简介 目前在MySQL高可用方面是一个相对成熟的解决方案，它由日本DeNA公司youshimaton（现就职于Facebook公司）开发，是一套优秀的作为MySQL高可用性环境下故障切换和主从提升的高可用软件。在MySQL故障切换过程中，MHA能做到在0~30秒之内自动完成数据库的故障切换操作，并且在进行故障切换的过程中，MHA能在最大程度上保证数据的一致性，以达到真正意义上的高可用。 （2）该软件由两部分组成： MHA Manager（管理节点）和MHA Node（数据节点）。MHA Manager可以单独部署在一台独立的机器上管理多个master-slave集群，也可以部署在一台slave节点上。MHA Node运行在每台MySQL服务器上，MHA Manager会定时探测集群中的master节点，当master出现故障时

一 问题概述 今天在工作中遇到一个问题,使用很久的一个local git repository,里面只有develop分支,那么现在想将分支切换到master分支,问题来了,在切换到master分支时: git checkout master 提示如下错误: error : pathspec 'master' did not match any file ( s ) known to git 二 问题解决 1.首先我们看一下分支情况: git branch - a * develop remotes / composer / develop remotes / composer / feature / 194 remotes / composer / feature / 198 remotes / composer / feature / 199 remotes / composer / feature / 200 remotes / composer / master remotes / origin / HEAD -> origin / develop remotes / origin / develop remotes / origin / feature / 194 remotes / origin / feature / 198 remotes / origin /

Redis Cluster 需求：1、请求量过大 100w/s 2、数据量大 1、数据分布 哈希分布特点： 数据分散度高 键值分布业务无关 无法顺序访问 支持批量操作 顺序分布特点： 数据分散度易倾斜 键值业务相关 可顺序访问 支持批量操作 2、数据分区 节点取余分区特点： 客户端分片：哈希 + 取余 节点伸缩数据迁移率过大 节点伸缩采用翻倍扩展 一致性哈希特点： 使用token环，顺时针定位节点 节点伸缩时影响临近节点，存在数据迁移 翻倍伸缩，保证最小迁移数据和负债均衡 虚拟哈希分区特点： 预设虚拟槽，每个槽映射一个数据子集，一般比节点数大 良好的哈希函数 服务端管理槽 3、集群架构 多个主节点，从节点 meet：完成节点通信 指派槽： 复制：高可用 4、安装配置 原生安装： 1、配置节点 port ${port} daemonize yes dir "" dbfilename "dump-${port}.rdb" logfile "${port}.log" # 代表当前节点为cluster节点 cluster-enabled yes # 指定当前cluster节点的配置 cluster-config-file nodes-${port}.conf 2、配置开启Redis 3、cluster meet ip port redis-cli -h 127.0.0.1 -p 7000

前言 　　现在大多数开发者都有自己的GitHub账号，很多公司也会以是否有GitHub作为一项筛选简历以及人才的选项了，可见拥有一个GitHub账号的重要性，本文就从最基本的GitHub账号的注册到基本的使用进行学习记录，一方面方便自己，另一方面希望对你有所帮助~ 　　之前写过一篇文章，浅谈使用git 进行版本控制（博客链接： https://www.cnblogs.com/wj-1314/p/7992543.html ） 　　说实话，当时是学习可视化的时候，接触到git ，学了些皮毛，但是自己在实践中并没有真正的用到GitHub这个平台。那时候在大学，还无忧无虑的，但是一年后，也就是今天，我在家里写了代码，但是在公司也想写，才发现了GitHub的好处了，今天迫不及待的使用了这个东西，并且把一些笔记记录下来。 GitHub简介 　　GitHub是用于版本控制和协作的代码托管平台，它可以让您和其他人在任何地方协同工作。GitHub 可以托管各种Git版本库，并提供一个web界面，但与其它像 SourceForge或Google Code这样的服务不同，GitHub的独特卖点在于从另外一个项目进行分支的简易性。 　　为一个项目贡献代码非常简单：首先点击项目站点的“fork”的按钮，然后将代码检出并将修改加入到刚才分出的代码库中，最后通过内建的“pull request

https://www.cnblogs.com/leeSmall/p/9563547.html 一、Zookeeper介绍 1. 介绍Zookeeper之前先来介绍一下分布式 1.1 分布式主要是下面两个方面： 1) 任务拆分 　　任务拆分指的是把传统的单节点服务拆分成多个节点服务部署到不同的机器上对外提供服务。比如一个传统服务有订单+支付+物流等3个模块，拆分成订单系统、支付系统、物流系统3个服务。 2) 节点分工 　　如上面的服务拆分后，订单系统、支付系统、物流系统各司其职 说明： 分布式解决高可用，高并发的。 集群解决的是高可用。 集群从物理上来定义，分布式一种工作方式。 例如：一个工作任务需要10个小时（单节点） 分布式：10台机器，任务只需要1个小时就能够完成 集群：10台机器，任务还是10个小时。 1.2 分布式协作中的难点： 如果让你设计一个分布式系统，你预见到什么问题？ 1) 保证节点高可用（节点故障） 2) 数据的一致性 3) 通讯异常 4) 网络分区 ....... 2. Zookeeper简介 Zookeeper就是用来解决分布式协作中的难点的 zookeeper是google的chubby项目开源实现。最早是hadoop的子项目 Zookeeper的使用场景： 小米米聊、淘宝Taokeeper其实是类zookeeper。 Kafka使用zookeeper

在之前的一篇文章已经介绍了 Redis Cluster及其部署 ，下面说下Redis Cluster日常操作命令： 一、以下命令是Redis Cluster集群所独有的，执行下面命令需要先登录redis： [root@manage redis]# redis-cli -c -p 6382 -h 192.168.10.12 （客户端命令：redis-cli -c -p port -h ip） 192.168.10.12:6382> 登录redis后，在里面可以进行下面命令操作 集群 cluster info ：打印集群的信息 cluster nodes ：列出集群当前已知的所有节点（ node），以及这些节点的相关信息。 节点 cluster meet <ip> <port> ：将 ip 和 port 所指定的节点添加到集群当中，让它成为集群的一份子。 cluster forget <node_id> ：从集群中移除 node_id 指定的节点。 cluster replicate <master_node_id> ：将当前从节点设置为 node_id 指定的master节点的slave节点。只能针对slave节点操作。 cluster saveconfig ：将节点的配置文件保存到硬盘里面。 槽(slot) cluster addslots <slot> [slot ...]