master

一、集群高可用概述 单纯的lvs/nginx反向代理模型做负载集群应用时，DR（director）存在单点故障隐患，故需要有机制来保证DR的高可用性。常用的高可用性方案有Keepalived、corosync，Keepalived主要是由VRRP协议实现了VIPfloating，比较适用于前端DR的高可用性，Corosync一般用于更专业的集群模型实现Service的高可用。Keepalived起初就是为了实现LVS集群director高可用而开发的，本处仅做Keepalived+LVS-DR模型实验。 二、Keepalived原理简介 Keepalived中优先级高的节点为MASTER。MASTER其中一个职责就是响应VIP的arp包，将VIP和mac地址映射关系告诉局域网内其 他主机，同时，它还会以多播的形式向局域网中发送VRRP通告，告知BACKUP组自己的优先级。网络中的所有BACKUP节点只负责 处理MASTER发出的多播包，当发现MASTER的优先级没自己高（脚本检测故障触发自我降级），或者没收到MASTER的VRRP通告（网络故障/MASTER宕机）时，BACKUP将自己切换到MASTER状 态，然后做MASTER该做的事：1.响应arp包，2.发送VRRP通告。 三、实验环境 1.网络拓补图 2.软件环境 CentOS7.4 keepalived.x86_64 1

1.1 Keepalived 高可用软件 Keepalived 起初是专为 LVS 设计的， 专门用来监控 LVS 集群系统中各个服务节点的状态 ，后来又加入了 VRRP 的功能，因此除了配合 LVS 服务外，也可以作为其他服务（ Nginx,Haproxy ）的高可用软件， VRRP 是 Virtual Router Redundancy Protocol （虚拟路由器冗余协议）的缩写， VRRP 出现的目的就是为了解决 静态路由 出现的单点故障问题，它能够保证网络的不间断、稳定的运行。所以， keepalived 以方面具有 LVS Cluster nodes healthchecks 功能，另一方面也具有 LVS directors failover 功能。 1.1.1 LVS Directors failover 功能 Ha failover 功能：实现 LB Master 主机和 Backup 主机之间故障转义和自动切换。 这是针对有两个负载均衡器 Director 同时工作而采取的故障转移措施。当主负载均衡器（ MASTER ）失效或出现故障时，备份负载均衡器（ BACKUP ）将自动接管主负载均衡的所有工作（ vip 资源及相应服务）一旦主负载均衡器（ MASTER ）故障修复， MASTER 又会接管回它原来处理的工作，而备份负载均衡器（ BACKUP ）会释放

一、首先读写分离呢 一般的结构（1主(master) 2从(slave)） 数据库的读写分离结构 读写分离的原理：就是主服务器每当新增数据或者删除数据，都会有二进制日志去记录这些操作，然后从数据库就根据日志来自动执行相同的动作，这样就达到从数据会自动同步主数据库的数据。 二、读写分离配置(1主2从)---说明:我是先做好，后面才补上博客的 1、首先，先去服务里面停止掉mysql57(3306端口)（在服务上右键停止就可以了）.mysql3307 mysql3308暂时忽略（后面讲到） 服务列表 2.接下来找到你的mysql57（3306端口）安装目录 例图 我自己的安装目录 mysql的安装目录 3.将上面的文件夹复制2份到其它地方去，改名后面加上 3307 3308(命名只是为了区分) 复制2份到其它地方 4、接下来进入到3307的文件夹，将my-default.ini这个文件 重命名为my.ini 重命名为my.ini 5、接下来我们要在当前文件夹新增data文件夹，进行任何操作最好先停止掉mysql的服务 新增data文件夹 6、然后我们去找到mysql57(3306端口)的data文件，将里面的东西可以全部拷贝到3307 data文件夹里面去 3306端口的数据库 三、开始文件里面的配置 1、首先我们找到mysql57(3306端口)的文件配置 3306端口的my

Docker 镜像和容器的导入导出 一、镜像的导出和导入 1.镜像的保存 [root@k8s-master ~]# docker images REPOSITORY TAG IMAGE ID CREATED SIZE nginx latest ae513a47849c 2 months ago 109MB debian jessie 4eb8376dc2a3 2 months ago 127MB rabbitmq 3.6.8 8cdcbee37f62 15 months ago 179MB [root@k8s-master tmp]# docker save ae513a47849c > nginx-save.tar [root@k8s-master tmp]# ls -lh total 108M -rw-r--r-- 1 root root 108M Jul 4 09:32 nginx-save.tar 2.镜像的导入 可以将导出的nginx-save.tar包传到需要的docker主机上面，然后执行导入命令. [root@k8s-master tmp]# ls -lh total 108M -rw-r--r-- 1 root root 108M Jul 4 09:32 nginx-save.tar [root@k8s-master tmp]# docker load <

~/Desktop/work/movies/movie(apps) $ git status //先查看是否有需要提交的东西 # On branch apps nothing to commit (working directory clean) ~/Desktop/work/movies/movie(apps) $ git checkout master //切换到主干 Switched to branch 'master' ~/Desktop/work/movies/movie(master) $ git status //查看主干是否有需要提交的东西 # On branch master nothing to commit (working directory clean) ~/Desktop/work/movies/movie(master) $ git pull //再次确认是否需要更新代码查看主干是否有需要提交的东西 Already up-to-date. ~/Desktop/work/movies/movie(master) $ git checkout apps //切换到分支 Switched to branch 'apps' ~/Desktop/work/movies/movie(apps) $ git rebase master//拷贝主干最新内容

➜ fekit-extension-yo git:(dev) git push origin :master remote: error: By default, deleting the current branch is denied, because the next remote: error: ' git clone ' won ' t result in any file checked out, causing confusion. remote: error: remote: error: You can set ' receive.denyDeleteCurrent ' configuration variable to remote: error: ' warn ' or ' ignore ' in the remote repository to allow deleting the remote: error: current branch, with or without a warning message. remote: error: remote: error: To squelch this message, you can set it to ' refuse ' . remote: error: refusing to delete the

在开发中，通常会保持两个分支master分支和develop分支，但是如果因为develop上面迭代太多而没有及时维护master，最后想丢弃master而直接将测试确认过的develop强推到master，该怎么操作呢？ 网上搜了一下，但是真正自己使用起来却又暴露出各种问题。因此，做如下总结分享，希望对遇到同样问题的人用帮助。 场景一：master下有a.txt文件，develop下有a.txt（和master保持一致），b.txt文件（追加文件），c/c.txt文件（追加文件夹和文件）。 场景二：master下有a.txt文件，develop下有a.txt（追加自己内容），b.txt文件（追加文件），c/c.txt文件（追加文件夹和文件）。 场景三：master下有a.txt文件（追加自己内容），develop下有a.txt（追加自己内容），b.txt文件（追加文件），c/c.txt文件（追加文件夹和文件）。其中master的a.txt和develop的a.txt不存在竞合。 场景四：master下有a.txt文件（追加自己内容），develop下有a.txt（追加自己内容），b.txt文件（追加文件），c/c.txt文件（追加文件夹和文件）。其中master的a.txt和develop的a.txt存在竞合。 网上查找了一个操作步骤，如下： 切换到develop分支下

git支持很多种工作流程，我们采用的一般是这样，远程创建一个主分支，本地每人创建功能分支，日常工作流程如下： 去自己的工作分支 $ git checkout work 工作 .... 提交工作分支的修改 $ git commit -a 回到主分支 $ git checkout master 获取远程最新的修改，此时不会产生冲突 $ git pull 回到工作分支 $ git checkout work 用rebase合并主干的修改，如果有冲突在此时解决 $ git rebase master 回到主分支 $ git checkout master 合并工作分支的修改，此时不会产生冲突。 $ git merge work 提交到远程主干 $ git push 这样做的好处是，远程主干上的历史永远是线性的。每个人在本地分支解决冲突，不会在主干上产生冲突。 来源： https://www.cnblogs.com/lbblog/p/4970771.html

我在本地创建了dev分支，项目也push到远程的dev分支，今天在远程分支进行合并时，将dev合并到master，结果公司的gitlab始终不响应，我不知道是公司的网络不行还是我操作错误，就只能另想办法。 看了网上的一篇博客，参考着做了： 现在要把远程的dev合并到远程master上面，思路如下： 1.clone项目到本地，此时默认会把master分支clone一份到本地。 2.本地分支上新建一个dev分支，名字和远程的dev一样，复制一份远程dev上面的代码，切换到本地master，合并本地dev。 3.解决合并过程中的冲突，之后Push到远程master，效果就是远程的dev合并到了远程的master上面。 测试步骤： 1.clone 　　　　git clone git@gith ub.com:bx_reader/bx-reader-api.git 克隆成功： 2.把远程dev“复制”到本地 cd bx-reader-api git checkout -b dev origin/dev 可见，此时本地仓库中的master分支和dev分支已经对应上了远程仓库中的master以及dev。 3.master合并dev分支 git checkout master git merge dev 之后文件夹下，看到master分支也可以看到dev这个文件了。 4. push到远程仓库 git

MySQL设置项 下面一张表格是我从国外的一个博客里边摘抄下来的MySQL的一些默认配置项和最低设置参数。 设置项 默认 最低 innodb_buffer_pool_size 128M 5M innodb_log_buffer_size 1M 256K query_cache_size 1M 0 max_connections 151 1 (推荐最低设置为10) key_buffer_size 8388608 8 thread_cache_size (自动配置) 0 host_cache_size (自动配置) 0 innodb_ft_cache_size 8000000 1600000 innodb_ft_total_cache_size 640000000 32000000 thread_stack 262144 131072 sort_buffer_size 262144 32K read_buffer_size 131072 8200 read_rnd_buffer_size 262144 8200 max_heap_table_size 16777216 16K tmp_table_size 16777216 1K bulk_insert_buffer_size 8388608 0 join_buffer_size 262144 128 net_buffer_length