master

ProGit这本书讲的挺不错。循序渐进。有几个命令书中语焉不详，卡住了挺长时间。记录一下。 remote branch 每一个remote branch都会在本地表现为一个不可改变的静态branch。使用git branch -a可以看到。红色的就是remote branch。不能够对这些branch进行改动，但是可以创建一个这些remote branch的tracking branch： git checkout -b b1 origin/b1 # or git checkout --tracking origin/b1 这时候，创建出来的local branch就会被git看作是对应的remote branch的tracking branch。在执行git push的时候，local branch的内容就会自动被push到它的tracking branch。 缺省的master就是origin/master的tracking branch。 本地的branch只能够通过向remote branch推送（push）数据的方式来和remote branch交互。如果想创建一个remote branch，就需要创建一个branch，然后 git branch b2 git push origin b2 这两条命令创建一个本地branch b2，然后将它增加到remote branch

saltstack介绍 1、 saltstack是使用python语言开发的； 2、 轻量级的管理工具，批量执行命令； 3、常用模块：pkg（包）、file（文件）、cmd（执行命令或脚本）、user、 service、cron 4、saltstack数据系统 Grains （静态数据） pillar （动态数据） saltstack三大功能，远程执行，配置管理，云管理 SaltStack是一个服务器基础架构集中化管理平台，具备配置管理、远程执行、监控等功能，基于Python语言实现，结合轻量级消息队列（ZeroMQ）与Python第三方模块（Pyzmq、PyCrypto、Pyjinjia2、python-msgpack和PyYAML等）构建。 通过部署SaltStack，我们可以在成千万台服务器上做到批量执行命令，根据不同业务进行配置集中化管理、分发文件、采集服务器数据、操作系统基础及软件包管理等，SaltStack是运维人员提高工作效率、规范业务配置与操作的利器。 salt基本原理 SaltStack 采用 C/S模式，server端就是salt的master，client端就是minion，minion与master之间通过ZeroMQ消息队列通信 minion上线后先与master端联系，把自己的pub key发过去，这时master端通过salt-key

一、演示课题说明： 单台物理机利用xtrabackup工具在线备份63G的mysql数据，来新建slave库。 演示的目的主要是记录下在单台物理服务器上利用63G的测试库数据，然后在本机上快速新建一个slave库，大概需要多久完成。以及在新增的slave的过程中对master库锁表影响多大？ 二、设备和系统环境说明: 设备环境： x86_64位最小化安装 [root@localhost scripts]# cat /etc/redhat-release CentOS Linux release 7.5.1804 (Core) 设备和硬盘型号： 双硬盘：SSD盘-intel 单盘raid0 +--------------------------------------------------------------+ | This Machine's Hyper-Threading is Enabled(recommend disable) | +--------------------------------------------------------------+ Systembit : 64 MEM info : 6*16384 MB Disk_totle : Pro_SN_name : Product Name: PowerEdge R630 Serial Number:

前言 想象一种情况，你在分支上开发多个功能，现在要将第一个功能推到另一个分支上 master 1_2 | dev \__3_4_5 例如上面的，先基于master创建了分支dev， 然后提交了3个commit， 如何只将提交3 合到master 上去呢？　　 这就用到git的cheery-pick 先创建一个临时分支tmp，基于master git checkout -b tmp maser 将dev 的提交3 pick到tmp分支,这里commit_id 模拟就是3，当然实际的commit id是一个不可能重复的hash值 git cherry-pick <commit id> 最后push 然后提mr 效果就是 master 1_2_3 | dev \__3_4_5 来源： https://www.cnblogs.com/hustcpp/p/12361437.html

目录 MySQL高可用之MHA MHA简介 MHA工作流程 HMA架构 MHA工具介绍 部署MHA MySQL环境准备 配置GTID主从复制 配置关闭relaylog自动删除 安装MHA Node 安装MHA Manager 测试故障切换 修复主从和MHA 配置VIP漂移 配置binlog-server 故障排错 MySQL高可用之MHA MHA简介 MHA（Master High Availability）目前在 MySQL高可用 方面是一个 相对成熟 的 解决方案 ，它由日本DeNA公司youshimaton（现就职于Facebook公司）开发，是一套优秀的作为MySQL高可用性环境下 故障切换 和 主从提升 的 高可用软件 。在MySQL 故障切换 过程中，MHA能做到在 10~30秒 之内自动完成数据库的 故障切换 操作，并且在进行 故障切换 的过程中，MHA能在最大程度上 保证数据的一致性 ，以达到真正意义上的 高可用 。 使用MySQL 5.6以上的 半同步复制 ，可以大大 降低数据丢失 的风险。 MHA 可以与 半同步复制 结合起来。如果只有一个slave已经收到了最新的 二进制日志 ，MHA可以将最新的 二进制日志 应用于其他所有的slave服务器上，因此可以保证所有节点的 数据一致性 。 目前MHA主要支持 一主多从 的架构，要搭建MHA

通过Git座版本管理，开发之前需要在master分支下面切一个新的分支，之后的开发全部都在这个分支上进行。假设开发过程需要一个月，一个月过后，master分支整合了好多其他同事们提交的代码。如何把他们的代码整合到我们自己的开发分支上面呢。这就会用到git rebase。 操作步骤 1. 先保证本地的开发分支和master分支都是最新的code 2. 切换到你现在开发的分支，在git命令中输入：git rebase origin/master 3. 这样就会把你现在正在开发的分支中已经写好的代码与最新的master分支的代码合并在一起 4. 合并的过程中可能会涉及很多冲突需要解决。 输入 git status 显示冲突的文件，然后找到那个文件解决冲突。git status如果不显示冲突文件，但又处于rebase状态，输入git rebase --skip 输入git add [文件名]，这样才算解决一个冲突， 输入 git rebase --continue ，继续git status ....... 直到所有的冲突全部解决 5：解决完冲突后，推送到远程库。 6：完成 如何终止rebase操作： 输入 git rebase --abort ，回到最初的状态，前面解决的所有冲突都会恢复到以前的状态 如何查看rebase完成了呢？ git branch看看自己是否在开发分支

背景： Redis-Sentinel是Redis官方推荐的高可用性(HA)解决方案，当用Redis做Master-slave的高可用方案时，假如master宕机了，Redis本身(包括它的很多客户端)都没有实现自动进行主备切换，而Redis-sentinel本身也是一个独立运行的进程，它能监控多个master-slave集群，发现master宕机后能进行自动切换，更多的信息见 前一篇 说明。它的主要功能有以下几点： 1，不时地监控redis是否按照预期良好地运行; 2，如果发现某个redis节点运行出现状况，能够通知另外一个进程(例如它的客户端); 3，能够进行自动切换。当一个master节点不可用时，能够选举出master的多个slave(如果有超过一个slave的话)中的一个来作为新的master,其它的slave节点会将它所追随的master的地址改为被提升为master的slave的新地址。 Redis-Replication 1）搭建 复制的配置很简单，就一个参数： slaveof <主数据库IP> <端口> 可以添加在配置文件里，也可以在命令行中执行。如主数据库IP是192.168.200.25 端口是6379：(配置多台从数据库的方法也一样) slaveof 192.168.200.25 6379 注意： 通过命令行进行的复制，在主从断开或则主从重启之后复制信息会丢失

问题一:项目中缓存是如何使用的？缓存如果使用不当会造成什么结果？ 1.用缓存，主要有俩用途， 高性能 和 高并发 ，一般的中小型项目考虑 高并发 2.常见的缓存问题有以下三个： 缓存与数据库数据不一致 缓存雪崩 缓存穿透 缓存并发竞争 问题二：redis和memacached 有什么区别？Redis的线程模型是什么，为什么单线程的Redis比多线程的memacached效率要高得多？ redis 和 memacached的区别？ Redis支持的服务端的数据操作：Redis相比memacached来说，拥有更多的数据结构并支持更丰富的操作，通常在memacached中，你需要将数据拿到客户端来进行类似的修改在set回去，这大大增加了网络IO的次数和数据体积。在Redis中，这些复杂的操作通常和一般的get/set 一样高效。所以如果需要缓存能够支持更复杂的结构和操作，那么Redis会是不错的选择。 内存使用对比：使用简单的key -value 存储的话，memacached的内存利用率高；而Redis采用哈希结构来做key -value 存储，由于其组合式的压缩，其内村利用率要更高； 性能对比：由于redis是单核的，而memacached可以使用多核，所以平均每一个核上Redis在存储大量小数据时比memcached性能更高。而在100K以上数据

在工作中接触最多的就是mysql replication，由于现在公司也还在使用mysql 5.1.x版本，在复制方面还是比较多的问题，比如主库宕机或者从库宕机都会导致复制中断，通常我们需要进行人为修复（mysql 5.5版本解决大部分问题），或者很多时候需要把一个从库提升为主库，但对从库和主库的数据一致性不能保证一样，所以就利用 pt-table-checksum 工作来检查主从的一致性，以及通过 pt-table-sync 如何修复这些不一致的数据。当然如果你数据量小，slave只是当做一个备份使用，那么出现数据不一致完全可以重做，或者通过其他方法解决。如果数据量非常大，重做就是非常蛋碎的一件事情了。^_^ 工具安装： 1.软件下载： [root@MySQL-01 ~]# wget http://www.percona.com/downloads/percona-toolkit/LATEST/RPM/percona-toolkit-2.2.7-1.noarch.rpm 2.安装该工具依赖的软件包： [root@MySQL-01 ~]# yum install perl-IO-Socket-SSL perl-DBD-MySQL perl-Time-HiRes -y 3.软件安装： [root@MySQL-01 ~]# rpm -ivh percona-toolkit-2.2.7

不要用SECONDS_BEHIND_MASTER 来衡量MYSQL 主备的延迟时间， 原因如下： A：备库 Seconds_behand_master值是通过将服务器当前的时间戳与二进制日志中的事件的时间戳对比得到的，所以只有在执行事件时才能报告延迟 B：如果备库复制线程没有运行，就会报延迟为 null C：一些错误，如主备的 max_allowed_packet不匹配或者网络不稳定时，可能中断复制或者停止复制线程，但 Seconds_behand_master将显示为 0而不是显示错误 D：即使备库线程正在运行，备库有时候可能无法计算延迟时，如果发生这种情况，备库会报 0或者 null E：一个较大的事务可能导致延迟波动，如：有一个事务更新数据长达一个小时，最后提交，这条更新将比它实际发生时间要晚一个小时才记录到二进制日志中，当备库执行这条语句时，会临时地报告备库延迟一个小时，然后很快又变回 0 F：如果分发主库落后了，并且其本身也有已经追赶上它的备库，备库的延迟将显示为 0，而事实上备库和源主库之间此时是有延迟的。 解决这些问题的办法是忽略这个值，并使用一些可以直接观察和衡量的方式来监控备库延迟，最好的解决办法是使用 heartbeat record，这是一个在主库上每秒更新一次的时间戳，为了计算延迟，可以直接用备库当前的时间戳减去心跳记录的值