master

git config --global user.name "你的名字" git config --global user.email "你的Email" git clone 在git clone的时候，所有本地分支默认与远程主机的同名分支，建立追踪关系，也就是说，本地的master分支自动"追踪"origin/master分支。 1、从远程主机克隆一个版本库，到本地生成的同名目录 git clone <版本库的网址> 2、从远程主机克隆一个版本库，到本地指定的目录 git clone <版本库的网址> <本地目录名> 3、git clone支持HTTP(s)、SSH、Git、本地文件协议等多种协议 $ git clone http[s]://example.com/path/to/repo.git/ $ git clone ssh://example.com/path/to/repo.git/ $ git clone [user@]example.com:path/to/repo.git/ $ git clone git://example.com/path/to/repo.git/ $ git clone /opt/git/project.git $ git clone file:///opt/git/project.git $ git clone ftp[s]:/

Git配置 git config --global user.name "robbin" git config --global user.email "fankai@gmail.com" git config --global color.ui true git config --global alias.co checkout git config --global alias.ci commit git config --global alias.st status git config --global alias.br branch git config --global core.editor "mate -w" # 设置Editor使用textmate git config -l # 列举所有配置 用户的git配置文件 ~/.gitconfig Git常用命令 查看、添加、提交、删除、找回，重置修改文件 git help <command> # 显示command的help git show # 显示某次提交的内容 git show $id git co -- <file> # 抛弃工作区修改 git co . # 抛弃工作区修改 git add <file> # 将工作文件修改提交到本地暂存区 git add . # 将所有修改过的工作文件提交暂存区 git rm

一、读写分离（主从复制） 主从复制： 当主服务器有写入（insert/update/delete）语句时候，从服务器自动获取 读写分离： insert/update/delete语句操作一台服务器，select操作另一个服务器 从库生成两个线程，一个I/O线程，一个SQL线程； i/o线程去请求主库 的binlog，并将得到的binlog日志写到relay log（中继日志） 文件中； 主库会生成一个 log dump 线程，用来给从库 i/o线程传binlog； SQL 线程，会读取relay log文件中的日志，并解析成具体操作，来实现主从的操作一致，而最终数据一致 二、bin-log日志 概念：binlog即二进制日志，它记录了数据库上的所有改变并以二进制的形式保存在磁盘中，它可以用来查看数据库的变更历史、数据库增量备份和恢复、Mysql的复制（主从数据库的复制）。 简单概括：binlog日志就是记录MySQL数据库增/删/改SQL语句 作用：实现主从复制、灾难恢复 1、开启binlog日志 步骤1：打开MySQL配置文件vi /etc/my.cnf并修改 步骤2：重启服务 步骤3：登录MySQL查看bin-log日志是否开启 2、查看binlog日志里面的内容 列表： show master logs 清空： reset master 刷新： flush logs

什么是集群缩容 ？ 说白了就是下线节点，判断该节点上是否有slot，有的进行迁移后并使集群忘记该节点，否则直接忘记该节点。 2、步骤如下 1、找到需要下线的节点 2、判断该节点是否有slot，有的进行slot迁移 3、下线节点 3、做法？ [root@hadoop05 bin]# ./redis-cli -p 8000 cluster nodes 8c2846698b49aed95674ad2e4eef5d501563f874 127.0.0.1:8005@18005 slave 30309728ad48df61e40d6f476740579e66398b02 0 1576589597238 6 connected a1021b42a93d35dbf75b5b515ea50e20515e92b6 127.0.0.1:8003@18003 slave ba807182f5cc573fc100d4d64ef9a4b1ecf0419f 0 1576589598000 4 connected 5623991f7d23e0dc09f17e19688d3a65b91002f0 127.0.0.1:8007@18007 master - 0 1576589600261 8 connected 0-1364 5461-6826 10923-12287

HBase 的物理存储 HBase 表中的所有行都是按照行键的字典序排列的。因为一张表中包含的行的数量非常多，有时候会高达几亿行，所以需要分布存储到多台服务器上。 因此，当一张表的行太多的时候，HBase 就会根据行键的值对表中的行进行分区，每个行区间构成一个“分区（Region）”，包含了位于某个值域区间内的所有数据，如图 1 所示。 图 1 HBase的Region存储模式图 Region 是按大小分割的，每个表一开始只有二个 Region，随着数据不断插入到表中，Region 不断增大，当增大到一个阈值的时候，Region 就会等分为两个新的 Region。当表中的行不断增多时，就会有越来越多的 Region，如图 2 所示。 图 2 HBase的Region分裂示意 Region 是 HBase 中数据分发和负载均衡的最小单元，默认大小是 100MB 到 200MB。不同的 Region 可以分布在不同的 Region Server 上，但一个 Region 不会拆分到多个 Region Server 上。每个 Region Server 负责管理一个 Region 集合。如图 3 所示。 图 3 HBase的Region分布模式 Region 是 HBase 在 Region Server 上数据分发的最小单元，但并不是存储的最小单元。事实上，每个 Region

每次提交，Git都会把它们串成一条时间线，这条时间线就是一个分支。目前，只有master分支。实际上：master指向最新的提交，再用HEAD指向master，确定当前分支以及当前分支的提交点。 ① 创建并切换到dev分支 git checkout -b dev git branch 查看所有分支 当前分支前面会标一个“ * ” 经过对readme.txt修改后，在add, commit后 切回master分支 git checkout master 合并 git merge dev 用于合并指定分支到当前分支 PS： Fast-forward , 快速模式，直接把master 指向dev当前提交，所以很快。 ⑤ 删除分支 git branch -d dev Git鼓励使用分支完成某个任务，合并后再删除，虽与直接在master分支上工作效果一样，但过程更安全。 来源： CSDN 作者： 爱喝水的qdy 链接： https://blog.csdn.net/qq_32617703/article/details/103586311

1：masterha_check_repl 副本集方面报错 replicates is not defined in the configuration file! 具体信息如下： # /usr/local/bin/masterha_check_repl --conf=/etc/mha/app1.cnf Thu Nov 21 15:33:15 2018 - [warning] Global configuration file /etc/masterha_default.cnf not found. Skipping. Thu Nov 21 15:33:15 2018 - [info] Reading application default configuration from /etc/mha/app1.cnf.. Thu Nov 21 15:33:15 2018 - [info] Reading server configuration from /etc/mha/app1.cnf.. Thu Nov 21 15:33:15 2018 - [info] MHA::MasterMonitor version 0.56. Thu Nov 21 15:33:16 2018- [error][/usr/local/share/perl5/MHA/ServerManager.pm,

查看、添加、提交、删除、找回，重置修改文件 git help # 显示command的help git show # 显示某次提交的内容 git show $id git co – # 抛弃工作区修改 git co . # 抛弃工作区修改 git add # 将工作文件修改提交到本地暂存区 git add . # 将所有修改过的工作文件提交暂存区 git rm # 从版本库中删除文件 git rm --cached # 从版本库中删除文件，但不删除文件 git reset # 从暂存区恢复到工作文件 git reset – . # 从暂存区恢复到工作文件 git reset --hard # 恢复最近一次提交过的状态，即放弃上次提交后的所有本次修改 git ci git ci . git ci -a # 将git add, git rm和git ci等操作都合并在一起做　git ci -am “some comments” git ci --amend # 修改最后一次提交记录 git revert <$id> # 恢复某次提交的状态，恢复动作本身也创建次提交对象 git revert HEAD # 恢复最后一次提交的状态 查看文件diff git diff # 比较当前文件和暂存区文件差异 git diff git diff # 比较两次提交之间的差异 git diff … #

1.是什么 数据库中间件，前身是阿里的cobar 2.干什么的 读写分离 数据分片（水平+垂直拆分） 多数据源整合 Mycat的配置文件 schema.xml：定义逻辑库，表、分片节点等内容 rule.xml：定义分片规则 server.xml：定义用户以及系统相关变量，如端口等. 原理 Mycat 的原理中最重要的一个动词是“拦截”，它拦截了用户发送过来的 SQL 语句，首先对 SQL 语句做了 一些特定的分析：如分片分析、路由分析、读写分离分析、缓存分析等，然后将此 SQL 发往后端的真实数据库， 并将返回的结果做适当的处理，最终再返回给用户 PS：这种方式把数据库的分布式从代码中解耦出来，程序员察觉不出来后台使用Mycat还是mysql 读写分离 mysql主从复制（要配置读写分离必须配置主从复制） 原理：slave会从master读取binlog来进行数据同步 MySQL复制过程分成三步： master将改变记录到二进制日志（binary log）。这些记录过程叫做二进制日志事件，binary log events； slave将master的binary log events拷贝到它的中继日志（relay log）； slave重做中继日志中的事件，将改变应用到自己的数据库中。 MySQL复制是异步的且串行化的 复制基本原则： 每一个slave只有一个master

一、MHA原理 1、简介： MHA（Master High Availability）目前在MySQL高可用方面是一个相对成熟的解决方案，它由日本DeNA公司youshimaton（现就职于Facebook公司）开发，是一套优秀的作为MySQL高可用性环境下故障切换和主从提升的高可用软件。在MySQL故障切换过程中，MHA能做到在0~30秒之内自动完成数据库的故障切换操作，并且在进行故障切换的过程中，MHA能在最大程度上保证数据的一致性，以达到真正意义上的高可用。 该软件由两部分组成：MHA Manager（管理节点）和MHA Node（数据节点）。MHA Manager可以单独部署在一台独立的机器上管理多个master-slave集群，也可以部署在一台slave节点上。MHA Node运行在每台MySQL服务器上，MHA Manager会定时探测集群中的master节点，当master出现故障时，它可以自动将最新数据的slave提升为新的master，然后将所有其他的slave重新指向新的master。整个故障转移过程对应用程序完全透明。 在MHA自动故障切换过程中，MHA试图从宕机的主服务器上保存二进制日志，最大程度的保证数据的不丢失，但这并不总是可行的。例如，如果主服务器硬件故障或无法通过ssh访问，MHA没法保存二进制日志，只进行故障转移而丢失了最新的数据。使用MySQL