master

MHA0.58安装 MHA（Master High Availability）由两部分组成：MHA Manager（管理节点）和MHA Node（数据节点）。 管理节点 mha4mysql-manager-0.58 mha4mysql-manager-0.58 下载地址： wget https://github.com/yoshinorim/mha4mysql-manager/releases/download/v0.58/mha4mysql-manager-0.58.tar.gz wget https://github.com/yoshinorim/mha4mysql-node/releases/download/v0.58/mha4mysql-node-0.58.tar.gz MHA Manager 可以单独部署在一台独立的机器上管理多个master-slave集群，也可以部署在一台slave节点上。MHA Manager会定时探测集群中的master节点，当master出现故障时， 它可以自动将最新数据的slave提升为新的master，然后将所有其他的slave重新指向新的master。整个故障转移过程对应用程序完全透明。 MHA Node 运行在每台MySQL服务器上，定时和 MHA Manager交互信息。 在MHA自动故障切换过程中

mkdir XX：创建一个空目录 XX指目录名 pwd：显示当前目录的路径 git init：吧当前的目录变成可以管理的git仓库，生成隐藏的.git文件 touch xx：新建xx文件文件 git add xx：把xx文件添加到暂存区 git commit -m “xx”a.txt ：提交文件 -m后面的是注释 git status：查看仓库状态 git log：查看历史记录 git reset --hard HEAD^：网上回退一个版本 git reset --hard commit_id 回退到指定版本 commit_id头4位 cat xx：查看xx文件内容 git reflog：查看历史记录的版本号id git checkout -- xx：把xx文件在工作区的修改全部撤销 git rm xx：删除xx文件 之后要commit git remote add origin https://github.com/qiuhaifeng01/a.git 关联一个远程库 git push -u（第一次要用-u以后不用）origin master：把当前master分支推送到远程库 git clone https://github.com/xxxxx 从远程库中克隆 git checkout -b dev：创建dev分支 并切换到dev分支上 git branch：查看当前所有的分支

Redis 哨兵集群实现高可用 哨兵的介绍 sentinel，中文名是哨兵。哨兵是 redis 集群机构中非常重要的一个组件，主要有以下功能： 集群监控：负责监控 redis master 和 slave 进程是否正常工作。 消息通知：如果某个 redis 实例有故障，那么哨兵负责发送消息作为报警通知给管理员。 故障转移：如果 master node 挂掉了，会自动转移到 slave node 上。 配置中心：如果故障转移发生了，通知 client 客户端新的 master 地址。 哨兵用于实现 redis 集群的高可用，本身也是分布式的，作为一个哨兵集群去运行，互相协同工作。 故障转移时，判断一个 master node 是否宕机了，需要大部分的哨兵都同意才行，涉及到了分布式选举的问题。 即使部分哨兵节点挂掉了，哨兵集群还是能正常工作的，因为如果一个作为高可用机制重要组成部分的故障转移系统本身是单点的，那就很坑爹了。 哨兵的核心知识 哨兵至少需要 3 个实例，来保证自己的健壮性。 哨兵 + redis 主从的部署架构，是 不保证数据零丢失 的，只能保证 redis 集群的高可用性。 对于哨兵 + redis 主从这种复杂的部署架构，尽量在测试环境和生产环境，都进行充足的测试和演练。 哨兵集群必须部署 2 个以上节点，如果哨兵集群仅仅部署了 2 个哨兵实例，quorum = 1。

Learn Git Branching 笔记 基础Git命令 高级Git命令 整理提交记录 基础Git命令 1.提交 git commit -m "annotation" 以当前分支（master）的当前节点作为父节点新建一个子节点，其他分支不受影响： 2.新建分支 git branch <new_branch_name> 3.切换分支 git checkout <branch_name> 4.分支新建和切换同时完成 git checkout -b <new_branch_name> 5.分支合并 git merge bugFix 上述命令将bugFix分支合并到master分支上，如图： 当前master分支的C4节点包含了所有代码库的修改，而bugFix分支留待解决： git checkout bugFix git merge master 此时，两个分支均到达最新节点，上溯到C0包括代码库所有的修改记录 6.分支合并的另一种方式 git rebase master 命令将bugFix分支里的工作直接移动master分支上，使得并行开发的工作看起来像线性开发 接着更新master分支： git checkout master git rebase bugFix 高级Git命令 1.分离HEAD HEAD初始一般指向分支名，分支名指向当前提交记录节点，查看HEAD指向： cat

一、Redis Cluster 分布式集群 1.什么是Redis Cluster 1）Redis集群是一个可以在多个Redis节点之间进行数据共享的设施（installation）。 2）Redis集群不支持那些需要同时处理多个键的Redis命令，因为执行这些命令需要在多个Redis节点之间移动数据，并且在高负载的情况下，这些命令将降低Redis集群的性能，并导致不可预测的行为。 3）Redis集群通过分区（partition）来提供一定程度的可用性（availability）：即使集群中有一部分节点失效或者无法进行通讯，集群也可以继续处理命令请求。 4）Redis集群有将数据自动切分（split）到多个节点的能力。 2.Redis Cluster的特点 高性能 1.在多酚片节点中，将16384个槽位，均匀分布到多个分片节点中 2.存数据时，将key做crc16（key），然后和16384进行取模，得出槽位值（0-16384之间） 3.根据计算得出的槽位值，找到相对应的分片节点的主节点，存储到相应槽位上 4.如果客户端当时连接的节点不是将来要存储的分片节点，分片集群会将客户端连接切换至真正存储节点进行数据存储 高可用 在搭建集群时，会为每一个分片的主节点，对应一个从节点，实现slaveof功能，同时当主节点down，实现类似于sentinel的自动failover的功能。 3

git提交代码到gerrit失败 一、前言 tips：如果我们想在gerrit上管理代码。那么你的每次提交都要带上一个commit_id，这样才能保证你能push到远端的rfes/for/master上。(注意是这个Change_id) 要每次提交代码的时候都带上一个这样的唯一标识： 怎么生成唯一标识可自行查找 二、背景： 提交代码的正确姿势： 1:提交代码 git add . git commit --amend (注意这里一定是amend,因为要保证每次的patchset是同一次提交) 2:拉取远端最新的变化 git fetch --all 3:rebase主干分支(master)的代码变化 git rebase origin/master -i 4:提交代码到主干分支 git push origin HEAD:refs/for/master 错误复现： 提交代码没有问题，在拉取远端最新的分支变化的时候我执行的是 git catch (起的git命令别名。这里我以为执行的是 git fetch --all 其实是 git remote update origin --prune )前者是拉取远程分支的变动，后者是更新分支的变动。所以实际上并没有更新远程分支的代码。这时候我push到远程分支被拒绝。所以我就reset到master的上一次提交，然后再add, commit -

1. 创建 MasterPage，后缀名 .master, 如 x.master. 其中用 <asp:ContentPlaceHolder /> 定义空位。如： <asp:ContentPlaceHolder ID="ContentPlaceHolder1" Runat="Server"> </asp:ContentPlaceHolder> 　　 2. 创建内容页面。 在 NewItem 对话框里选择 "select master page", 选择上一步创建的 MasterPage. 产生的代码里， MasterPageFile 属性指定了 MasterPage 的位置： <%@ Page Language="VB" MasterPageFile="~/x.master" Title="无标题页面" %> 页面里用 <asp:Content /> 来添加内容到对应的空位： <asp:Content ID="Content1" ContentPlaceHolderId="ContentPlaceHolder1" Runat="Server"> 内容 </asp:Content/> 内容页面没有 <form id="form1" runat="server"> 3. 利用 MasterPage 可以使用多种语言来编写一个页面的各个部分。 4. 除了在 <%@ Page %> 里面指定

基于Redis的三种分布式爬虫策略 前言： 爬虫是偏IO型的任务，分布式爬虫的实现难度比分布式计算和分布式存储简单得多。 个人以为分布式爬虫需要考虑的点主要有以下几个： ? 爬虫任务的统一调度 ? 爬虫任务的统一去重 ? 存储问题 ? 速度问题 ? 足够“健壮”的情况下实现起来越简单/方便越好 ? 最好支持“断点续爬”功能 Python分布式爬虫比较常用的应该是scrapy框架加上Redis内存数据库，中间的调度任务等用scrapy-redis模块实现。 此处简单介绍一下基于Redis的三种分布式策略，其实它们之间还是很相似的，只是为适应不同的网络或爬虫环境作了一些调整而已（如有错误欢迎留言拍砖）。 【策略一】 Slaver端从Master端拿任务（Request/url/ID）进行数据抓取，在抓取数据的同时也生成新任务，并将任务抛给Master。Master端只有一个Redis数据库，负责对Slaver提交的任务进行去重、加入待爬队列。 优点： scrapy-redis默认使用的就是这种策略，我们实现起来很简单，因为任务调度等工作scrapy-redis都已经帮我们做好了，我们只需要继承RedisSpider、指定redis_key就行了。 缺点： scrapy-redis调度的任务是Request对象，里面信息量比较大（不仅包含url，还有callback函数

K8S集群一套 [root@k8s-master ~]# cat /etc/hosts 51.0.1.213 k8s-master 51.0.1.214 k8s-node1 51.0.1.215 k8s-node2 [root@k8s-master ~]# kubectl version Client Version: version.Info{Major:"1", Minor:"14", GitVersion:"v1.14.1", GitCommit:"b7394102d6ef778017f2ca4046abbaa23b88c290", GitTreeState:"clean", BuildDate:"2019-04-08T17:11:31Z", GoVersion:"go1.12.1", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"14", GitVersion:"v1.14.1", GitCommit:"b7394102d6ef778017f2ca4046abbaa23b88c290", GitTreeState:"clean", BuildDate:"2019-04-08T17:02:58Z", GoVersion:"go1.12.1",

我不小心犯了错误的分支。 如何删除该提交？ #1楼 删除最近的提交，并保留已完成的工作： git reset --soft HEAD~1 删除最近的提交， 破坏 您已完成的工作： git reset --hard HEAD~1 #2楼 进行 git rebase -i FAR_ENOUGH_BACK 并删除不需要的提交行。 #3楼 如果要将该提交移至另一个分支，请获取有问题的提交的SHA git rev-parse HEAD 然后切换当前分支 git checkout other-branch 然后 cherry-pick other-branch git cherry-pick <sha-of-the-commit> #4楼 不要删除它：仅执行一次 git cherry-pick 就足够了。 但是，如果您在错误的分支上进行了 几次 提交，那么 git rebase --onto ： 假设您有： x--x--x--x <-- master \ -y--y--m--m <- y branch, with commits which should have been on master ，然后可以标记 master 并将其移动到您想要的位置： git checkout master git branch tmp git checkout y git branch -f master x