master

Redis详解（五）——主从复制 面临问题 机器故障。我们部署到一台 Redis 服务器，当发生机器故障时，需要迁移到另外一台服务器并且要保证数据是同步的。而数据是最重要的，如果你不在乎，基本上也就不会使用 Redis 了。 容量瓶颈。当我们有需求需要扩容 Redis 内存时，从 16G 的内存升到 64G，单机肯定是满足不了。当然，你可以重新买个 128G 的新机器。 解决办法 要实现分布式数据库的更大的存储容量和承受高并发访问量，我们会将原来集中式数据库的数据分别存储到其他多个网络节点上。 Redis 为了解决这个单一节点的问题，也会把数据复制多个副本部署到其他节点上进行复制，实现 Redis的高可用，实现对数据的冗余备份，从而保证数据和服务的高可用。 主从复制 什么是主从复制 主从复制，是指将一台Redis服务器的数据，复制到其他的Redis服务器。前者称为主节点(master)，后者称为从节点(slave),数据的复制是单向的，只能由主节点到从节点。 默认情况下，每台Redis服务器都是主节点；且一个主节点可以有多个从节点(或没有从节点)，但一个从节点只能有一个主节点。 主从复制的作用 数据冗余：主从复制实现了数据的热备份，是持久化之外的一种数据冗余方式。 故障恢复：当主节点出现问题时，可以由从节点提供服务，实现快速的故障恢复；实际上是一种服务的冗余。 负载均衡

1 ###################################################################[@wooluwalkerdeMacBook-Pro:wenjian (dev)]$ git dog * db69602 (HEAD -> dev) add test_reset.md * fab7157 dev修改READM.md * 217fef2 (origin/master, origin/HEAD, master) Update README.md,添加日期 * a565481 (origin/dev) Update README.md * 19cfeea 第一次将远程dev分支代码合并到master分支Merge branch 'dev' |\ | * b1777d8 commit merge_excel_utils | * ee37473 manage utils | * 0b6e16c commit files * | 441940f 添加项目说明 |/ * 0f1f9d7 Initial Commit [@wooluwalkerdeMacBook-Pro:wenjian (dev)]$ git reset dev^ #撤销上一次commit [@wooluwalkerdeMacBook-Pro:wenjian (dev)]$

ActiveMQ 10. ActiveMQ多节点集群 10.1. 简介 面试题: 引入消息中间件后如何保证其高可用 实现方式 ：基于 ZooKeeper 和 LevelDB 搭建 ActiveMQ 集群。集群仅提供主备方式的高可用集群功能，避免单点故障。 集群方案 : 基于shareFileSystem共享文件系统（KahaDB） 基于JDBC 基于可复制的LevelDB LevelDB，5.6版本之后推出了LecelDB的持久化引擎，它使用了自定义的索引代替常用的BTree索引，其持久化性能高于KahaDB，虽然默认的持久化方式还是KahaDB，但是LevelDB可能会是趋势。 在5.9版本还提供了基于LevelDB和Zookeeper的数据复制方式，作为Master-Slave方式的首选数据复制方案。 10.2. zookeeper+replicated-leveldb-store的主从集群 10.2.1. 简介 从ActiveMQ5.9开始,ActiveMQ的集群实现方式取消了传统的Masster-Slave方式.，增加了基于Zookeeper+LevelDB的Master-Slave实现方式,从5.9版本后也是官网的推荐。 基于Zookeeper和LevelDB搭建ActiveMQ集群,集群仅提供主备方式的高可用集群功能,避免单点故障. 官网信息 10.2.2. 原理说明

MySQL主从复制简介 Mysql的 主从复制 方案，都是 数据传输 的，只不过MySQL无需借助第三方工具，而是自带的同步 复制功能 ，MySQL的 主从复制 并不是磁盘上文件直接同步，而是将 binlog 日志发送给从库，由从库将 binlog 文件里的内容写入本地数据库。 在生产环境中，MySQL主从复制都是异步方式同步，即不是实时同步数据。 MySQL主从复制原理 1.主从复制中的线程及文件 主库线程： Dump(IO) thread（也成为 IO 线程）：在复制过程中，主库发送二进制日志的线程 从库线程： IO thread：向主库请求binlog日志，并且接受binlog日志的线程 SQL thread：专门用于请求binlog日志的线程，将其内容写入数据库 主库的文件： binlog文件：主库的binlog日志 从库的文件： relaylog：中继日志，存储请求过来的binlog日志 master.info： 从库连接主库的重要参数（user,password,ip,port） 记录最后一次获取过主库的binlog日志的位置点 relay-log.info 存储从库SQL线程已经执行过的relaylog日志位置点 Mysql主从复制图解： 从库 读取 master.info 文件中的信息（连接参数，最后一次请求binlog的位置点），向 主库 请求binlog文件，

1. 复制原理 master将改变记录到二进制日志(binary log)，这个记录过程叫二进制日志事件(binary log events)。 slave将master的binary log events拷贝到它的中继日志(relay log)。 slave重做中继日志中的事件，将改变应用到自己的数据库中，Mysql复制是异步且串行化的。 2. 配置(基于mysql 8.x) 2.1 master配置文件修改 [mysqld] # 设置主机Id server-id=1 # 启用二进制日志 log-bin=E:\\Software\\mysql-8.0.19\\data\\logbin 2.2 slave配置文件修改 [mysqld] # 设置从机Id server-id=2 # 启用二进制日志 log-bin=/var/run/mysqld/logbin 2.3 具体操作 主机IP：192.168.1.104 从机IP：192.168.25.103 主节点创建用户并授权 create user 'repl' @' 192.168 .1 .104 ' identified with mysql_native_password by ' 123456 '; grant replication slave on *.* to ' repl '@' 192.168 .1 .104 ' ;

情景描述 在将项目share到github后（已经push），发现push的文件中含有敏感的信息，所以想回滚状态到之前的版本。但使用log命令可以发现当前仅有一个commit状态： Yitian-MacBook-Pro:springboot-learning yitian$ git log commit f8e6d2455c8f494b860d0bb9a4b103624d75ef2a (HEAD -> master, origin/master) Author: yitian <yitian.z@foxmail.com> Date: Sat Feb 1 20:49:07 2020 +0800 init commit 使用reset命令无法回退到上次的提交状态（因为仅有一次提交，HEAD^状态并不存在），所以该方法不行。 解决方法 执行下面的命令，清除所有提交的版本并清空工作空间，这样就可以再进行第一次提交了： git update-ref -d HEAD 执行之后，将文件中敏感信息去掉之后commit并push，应该会出现如下的问题： Yitian-MacBook-Pro:springboot-learning yitian$ git push To https://github.com/Yitian-Zhang/springboot-learning.git !

引用https://www.cnblogs.com/u-1596086/p/11588957.html 第一步：登录git创建项目 右上角头像按钮，点击your repositories 接着绿色按钮：new 接着就是命名，再点击create respositoory，就在git上创建好了项目。 第二步，关联远程仓库 1，创建成功之后，我们会看到仓库的地址，如下：git@github.com:lenve/test.git，然后我需要将我们之前的本地仓库和这个远程仓库进行关联，使用git remote add命令，如下： $ git remote add origin git@github.com:lenve/test.git 在这条命令中，git会自动将远程仓库的名字设置为origin，方便我们的后续操作。 2，假设我想将本地master分支上的内容推送到远程master分支上，方式如下： $ git push -u origin master 如果想推送到其他分支，还是这条命令，修改一下分支的名字即可，比如我也想把我的fa分支推送到远程仓库中，执行如下命令： $ git checkout fire $ git push -u origin fire 引用https://blog.csdn.net/sinat_36246371/article/details/79738782

延时节点解决方案 删库跑路也是个老梗了，可见在运维数据库的过程中误删除数据，或者开发的代码有bug，造成数据的误删除屡见不鲜。不过现在也有许多用于恢复或预防误删除的方案，例如SQL管理系统，将要执行的SQL先交由管理员审核，然后由管理员备份一个镜像数据库，在镜像上执行该SQL，并在执行后还原镜像。这样经过层层把关就可以大大减小出现误操作的几率。 另外，利用binlog日志也可以恢复误操作的数据，所以线上运行的数据库都会开启binlog日志功能。还有就是本小节要介绍的延时节点：在Replication集群中，可以设置一个延时节点，该节点的数据同步时间要慢于集群中的其他节点，当其他节点出现误操作后，若延时节点的数据还没有被影响就可以从延时节点进行恢复。 但如果现有的数据库组建的都是PXC集群，没有Replication集群可以采用该方案吗？也是可以的，PXC集群与Replication集群并非是互斥的，我们可以将PXC集群中的某个节点设置为Master，然后增加一个延时节点设置为Slave，让这两个节点构成Replication集群进行数据同步即可。如下所示： 本小节就简单演示一下如何搭建这种异构集群下的延时节点，我这里已经事先准备好了一个PXC集群和一个用作延时节点的数据库： 这里使用PXC集群中的 PXC-Node3 作为Master，让其与 DelayNode 组成主从，而

ACM-DIY is a large QQ group where many excellent acmers get together. It is so harmonious that just like a big family. Every day,many “holy cows” like HH, hh, AC, ZT, lcc, BF, Qinz and so on chat on-line to exchange their ideas. When someone has questions, many warm-hearted cows like Lost will come to help. Then the one being helped will call Lost “master”, and Lost will have a nice “prentice”. By and by, there are many pairs of “master and prentice”. But then problem occurs: there are too many masters and too many prentices, how can we know whether it is legal or not? We all know a master can

/*--> */ /*--> */ /*--> */ /*--> */ 新建repository 　　本地目录下，在命令行里新建一个代码仓库（repository） 　　里面只有一个README.md 　　命令如下： touch README.md git init 　　初始化repository git add README.md 　　将README.md加入到缓存区 　　（可以用 git add --a 将所有改动提交到缓存（注意是两个杠）） git commit -m "first commit" 　　提交改变，并且附上提交信息"first commit" Push git remote add origin https://github.com/XXX(username)/YYYY(projectname).git 　　加上一个remote的地址，名叫origin，地址是github上的地址（Create a new repo就会有） 　　因为Git是分布式的，所以可以有多个remote. git push -u origin master 　　将本地内容push到github上的那个地址上去。 　　 参数-u 　　 用了参数-u之后，以后就可以直接用不带参数的git pull从之前push到的分支来pull 。