master

问题原因 想要了解这个问题的原因在于有一次面试的时候，面试官问我一个问题，就是MySQL的双主复制的时候是如何避免回环复制这个问题的，说老实话在基于GTID复制的时候我还是比较了解的，因为GTID复制是MySQL本身是不会执行已经执行过的GTID事务，即使MySQL本身并不会执行已经执行过的GTID事务，但是还是会形成一个回环复制。那么MySQL到底是如何解决回环复制的呢？ 猜想 在我们搭建主从的时候我们可以清楚的知道，要想成功的搭建主从，那么主从的server_id必须不能一模一样的，所以猜想可能是因为server_id的原因。 在MySQL 5.5以及一切，我们搭建一主多从的时候，假如slave使用了相同的server_id就会发现在master和slave上面发现slave会经常的断开重连，这个是因为slave在注册的时候会去比对server_id，假如server_id存在的话则会有一个删除操作，但是MySQL 5.6的版本以后引入了uuid，它会优先去比对uuid，假如不存在的话则会去比对server_id。所以在MySQL5.6以及以后是因为uuid的原因呢。 实验 A. 搭建双主。非gtid模式（具体过程不在描述） master 1 ........ ........ Connect_Retry: 60 Master_Log_File: mysql-bin

一、是什么 官网 行话：也就是我们所说的主从复制，主机数据更新后根据配置和策略，自动同步到备机的master/slaver机制，Master以写为主，Slave以读为主 二、能干嘛 读写分离 容灾恢复 三、怎么玩 1.配从(库)不配主(库) 2.从库配置：slaveof 主库IP 主库端口 说明： 每次与master断开之后，都需要重新连接，除非你配置进redis.conf文件 Info replication 3.修改配置文件细节操作 【1】拷贝多个redis.conf文件 【2】开启daemonize yes 【3】Pid文件名字 【4】指定端口 【5】Log文件名字 【6】Dump.rdb名字 4.常用3招 【1】一主二仆 Init 一个Master两个Slave 日志查看 主机日志 备机日志 info replication 主从问题演示 1 切入点问题？slave1、slave2是从头开始复制还是从切入点开始复制?比如从k4进来，那之前的123是否也可以复制 2 从机是否可以写？set可否？ 3 主机shutdown后情况如何？从机是上位还是原地待命 4 主机又回来了后，主机新增记录，从机还能否顺利复制？ 5 其中一台从机down后情况如何？依照原有它能跟上大部队吗？ 【2】薪火相传 上一个Slave可以是下一个slave的Master

1.1 gitlab安装（192.168.56.12中安装） 　　1、GitLab是什么？ 　　　　　　1. GitLab实现一个自托管的Git项目仓库，可通过Web界面进行访问公开的或者私人项目。 　　　　　　2. GitLab拥有与Github类似的功能，能够浏览源代码，管理缺陷和注释。 　　　　　　3. 可以管理团队对仓库的访问，它非常易于浏览提交过的版本并提供一个文件历史库。 　　　　　　4. 它还提供一个代码片段收集功能可以轻松实现代码复用，便于日后有需要的时候进行查找 　　2、gitlab安装　　 '''1. 初始化环境 ''' [root@linux-node2 ~]# yum install curl policycoreutils openssh-server openssh-clients postfix [root@linux-node2 ~]# systemctl start postfix '''2. 由于网络问题，国内用户，建议使用清华大学的镜像源进行安装''' [root@linux-node2 ~]# vim /etc/yum.repos.d/gitlab-ce.repo ''' [gitlab-ce] name=gitlab-ce baseurl=http://mirrors.tuna.tsinghua.edu.cn/gitlab-ce/yum

1.1 常见版本管理工具介绍 及 版本工具作用 　　1. 为什么要使用版本控制 　　　　1、 举例说明： 　　　　　　1）假设你在的公司要上线一个新功能，你们开发团队为实现这个新功能，写了大约5000行代码，上线没2 　　　　　　 天，就发现这个功能用户并不喜欢，你老板让你去掉这个功能，你怎么办？ 　　　　　　2）你说简单，直接把5000行代码去掉就行了，但是我的亲，说的简单，你的这个功能写了3周时间，但你 　　　　　　 还能记得你是新增加了哪5000行代码么？ 　　　　　　3）所以你急需要一个工具，能帮你记录每次对代码做了哪些修改，并且可以轻易的把代码回滚到历史上的 　　　　　　 某个状态。 这个神奇的工具就叫做版本控制 　　　　2 、版本控制工具主要实现 2 个功能 　　　　　　1 ）版本管理 　　　　　　　　　　在开发中，这是刚需，必须允许可以很容易对产品的版本进行任意回滚，版本控制工具实现这个功能的 　　　　　　　　　　原理简单来讲，就是你每修改一次代码，它就帮你做一次快照 　　　　　　2 ）协作开发 　　　　　　　　　　a. 一个复杂点的软件，往往不是一个开发人员可以搞定的，公司为加快产品开发速度，会招聘一堆跟 　　　　　　　　　　 你一样的开发人员开发这个产品 　　　　　　　　　　b. 拿微信来举例，现在假设3个人一起开发微信，A开发联系人功能，B开发发文字、图片

转载自公众号 原文链接： https://mp.weixin.qq.com/s/tqP9MoxhyzqGSpsTYA1J0A Redis Cluster 是 Redis 3.0 版本推出的 Redis 集群方案，它将数据分布在不同的服务区上，以此来降低系统对单主节点的依赖，并且可以大大的提高 Redis 服务的读写性能。 Redis 将所有的数据分为 16384 个 slots(槽)，每个节点负责其中的一部分槽位，当有 Redis 客户端连接集群时，会得到一份集群的槽位配置信息，这样它就可以直接把请求命令发送给对应的节点进行处理。 Redis Cluster 是无代理模式去中心化的运行模式，客户端发送的绝大数命令会直接交给相关节点执行，这样大部分情况请求命令无需转发，或仅转发一次的情况下就能完成请求与响应，所以集群单个节点的性能与单机 Redis 服务器的性能是非常接近的，因此在理论情况下，当水平扩展一倍的主节点就相当于请求处理的性能也提高了一倍，所以 Redis Cluster 的性能是非常高的。 Redis Cluster 架构图如下所示： 秒建Redis集群 Redis Cluster 的搭建方式有两种，一种是使用 Redis 源码中提供的 create-cluster 工具快速的搭建 Redis 集群环境，另一种是配置文件的方式手动创建 Redis 集群环境。 一

一、Broker 介绍 Broker 是 RocketMQ 的核心,大部分 "重量级" 工作都是由 Broker 完成的，如： * 接收 Producer 发送的消息 * 处理 Consumer的消费消息请求 * 消息的持久化存储 * 消息的 HA 机制 * 服务器过滤功能 ...... 二、消息的存储结构 RocketMQ 的消息存储由 ConsumeQueue 和 CommitLog 配合完成。 2.1 ConsumeQueue * ConsumeQueue 是消息的逻辑队列，类似数据库的索引文件，存储着指向物理存储的地址。每个 Topic 下的每个 MessageQueue 都有一个对应的 ConsumeQueue 文件。 * 文件所在路径： ${$storeRoot}\consumequeue\${topicName}\${queueId}\${fileName}。 2.2 CommitLog * CommitLog 是物理存储文件,每个 Broker 上的 CommitLog 被本机器所有的　ConsumeQueue 共享。 * 文件所在路径：${user.homt}\store\${commitlog}\${fileName}。 2.3 存储顺序 RocketMQ 通过一些机制来保证，尽量向 CommitLog 中顺序写入，但是可以随机读取。 三、高可用机制

生产环境对数据库要求很高的，为了避免数据库的突发情况，给他做个保险--用keepalived做高可用 环境（此处ip，密码均是乱造的）： 主：192.1.31.161 端口：3306 用户：vnum 密码：vnum@123 从：192.1.31.162 端口：3306 方案介绍 两台mysql互为主从，但只有master写，slave只负责读。主从通过keepalive做成高可用，当master出问题， 由slave接替master工作，即读写都在slave操作。当master恢复正常，master自动同步故障时间段数据，接替slave的写工作。 一：配置主主同步 、配置文件 master my.cnf 主要参数 log_slave_updates log-bin = mysql-bin server-id = 1 binlog-ignore-db=mysql #auto_increment_increment = 2 #auto_increment_offset = 2 slave my.cnf 主要参数 log_slave_updates log-bin = mysql-bin server-id = 2 binlog-ignore-db=mysql #auto_increment_increment = 2 #auto_increment_offset = 1 注: log

前面我们讲了 《Redis 性能优化的 13 条军规！》 ，其中最重要的一条就是使用 Redis 的集群功能，那么本文我们就来看看，如何用 1s 钟的时间来创建一个 Redis 集群。 Redis Cluster 是 Redis 3.0 版本推出的 Redis 集群方案，它将数据分布在不同的服务区上，以此来降低系统对单主节点的依赖，并且可以大大的提高 Redis 服务的读写性能。 Redis 将所有的数据分为 16384 个 slots(槽)，每个节点负责其中的一部分槽位，当有 Redis 客户端连接集群时，会得到一份集群的槽位配置信息，这样它就可以直接把请求命令发送给对应的节点进行处理。 Redis Cluster 是无代理模式去中心化的运行模式，客户端发送的绝大数命令会直接交给相关节点执行，这样大部分情况请求命令无需转发，或仅转发一次的情况下就能完成请求与响应，所以集群单个节点的性能与单机 Redis 服务器的性能是非常接近的，因此在理论情况下，当水平扩展一倍的主节点就相当于请求处理的性能也提高了一倍，所以 Redis Cluster 的性能是非常高的。 Redis Cluster 架构图如下所示： 搭建 Redis Cluster Redis Cluster 的搭建方式有两种，一种是使用 Redis 源码中提供的 create-cluster 工具快速的搭建 Redis

51.1、kubernetes介绍： 1、什么是kubernetes： （1）Kubernetes是容器集群管理系统，是一个开源的平台，可以实现容器集群的自动化部署、自动扩缩容、维护等功能。 （2）使用Kubernetes可以： 1）自动化容器的部署和复制 2）随时扩展或收缩容器规模 3）将容器组织成组，并且提供容器间的负载均衡 4）很容易地升级应用程序容器的新版本 5）节省资源，优化硬件资源的使用 6）提供容器弹性，如果容器失效就替换它 2、kubernetes的特点： （1）便携性：支持公有云、私有云、混合云、多重云(multi-cloud) （2）可扩展：模块化、插件化、可组合、可挂载 （3）自修复：自动部署，自动重启，自动复制，自动伸缩扩展 3、kubernetes特性： Kubernetes是一种用于在一组主机上运行和协同容器化应用程序的系统，旨在提供可预测性、可扩展性与高可用的性的方法来完全管理容器化应用程序和服务的生命周期的平台。 （1）自动装箱：构建于容器之上，基于资源依赖及其他约束自动完成容器部署且不影响其可用性，并通过调度机制混合关键型应用和非关键型应用的工作负载于同一节点以提升 资源利用率。 （2）自我修复：支持容器故障后自动重启、节点故障后重行调度容器，以及其他可用节点、健康状态检查失败后关闭容器并重新创建等自我修复机制。 （3）水平扩展

3 月，跳不动了？>>> Redis提供了一种能监控多台Redis服务器，并且能完成主从切换的特殊模式----Redis哨兵模式 我们能用Redis主从实现读取分流，但是如果某个时间点写入数据如果太大，给master造成太大压力造成宕机，如果没有哨兵模式的情况下我们就需要人工处监控理，这样就造成了某个时间段Redis不能提供服务，然而使用哨兵模式，我们就能解决某个时间段Redis不能提供服务的问题，Redis哨兵模式主要的两个功能： 监控服务 和 主从切换 一、主从切换原理 哨兵(Sentinel)不仅要监控所有的Redis服务，也要监控其他的Sentinel。原理就是Sentinel向Redis或者其他Sentinel发送ping命令，其他服务则响应。 主观下线：例如Sentinel向Redis发送命令后，有台Redis服务没响应则认为该服务器为主观下线 客观下线：如果多个Sentinel都对同一个服务做出了主观下线的判断，并且通过交流之后会认定该服务器为客观下线 它们的区别可以这样理解：主观下线是“只有我认为它宕机了”，而客观下线是“大部分人都认为它宕机了”，当一台服务器被认定客观下线之后，Sentinel有可能会进行一次选举。为什么说有可能，因为选举的目的是选择一个新的 master ,如果宕机的是 slave 则不影响系统使用，假如宕机的是 master 这时