master

文章目录 一：应用场景 主从的作用： 二：MySQL主从备份原理 Mysql主从复制部署环境： 三：主从同步步骤 1：主服务器mysql-master 的配置： <3>手工编译mysql(这里编译mysql5.7版本) 2：从服务器mysql-slave1 的配置： 3：从服务器mysql-slave2 的配置： 4：同步配置完成，主从同步复制效果验证 一：应用场景 在企业网站中，后端Mysql数据库只有一台时，会有以下问题： <1>：单点故障，mysql数据库一旦宕机 ，服务不可用 <2>：无法处理大量的并发数据请求 <3>：数据一旦丢失 会是一大事故 为了防止这类事故的发生，有了更安全有效的改造办法----设置主从同步。 主从的作用： <1>：增加MySQL数据库服务器，对数据进行备份，形成主备。确保主备MySQL数据库服务器数据是一样的，主服务器宕机了，备份服务器继续工作，数据有保障。 <2>：通过主从复制的方式来同步数据，再通过读写分离来提升数据库的并发负载能力 二：MySQL主从备份原理 master 提供binlog二进制日志 slave    通过 I/O线程从master拿取binlog,并复制到slave的中继日志中 slave    通过 SQL线程从slave的中继日志中读取binlog ,然后解析到slave中 注意：主和从数据库版本必须是一样

在本文中，使用单机上多个实例来搭建一个主从集群。 基于的MySQL版本是5.7.27。 单机多实例的具体安装过程可参考文档 单机安装MySQL多实例 。 将要搭建的集群实例信息如下： 角色 端口 主库 3306 从库1 3307 从库2 3308 1.创建复制账号 在主库上，创建复制用的账号，并赋予相应权限： mysql> CREATE USER 'rep'@'%' IDENTIFIED BY 'replication*001'; mysql> GRANT REPLICATION SLAVE ON *.* TO 'rep'@'%'; 查看用户: mysql> select host, user from mysql.user; +-----------+---------------+ | host | user | +-----------+---------------+ | % | rep | | localhost | mysql.session | | localhost | mysql.sys | | localhost | root | +-----------+---------------+ 4 rows in set (0.00 sec) mysql> show grants for 'rep'@'%'; +---------------------------

前言 前面 Redis Sentinel 架构原理详解(二) 介绍了redis集群中sentinel的三种定时监控任务，还了解了主观下线，客观下线的概念，以及 sentinel is-master-down-by-addr命令的作用。这里再和大家一起学习下Redis Sentinel架构 故障转移前的 Sentinel leader 选举，以及redis新的master如何选择。 故障转移前的 leader 选举 当 sentinel 集群确认 master odown，需要选举出一个 leader 节点来进行故障转移，选举过程如下： 每个在线的 sentinel 节点都有资格成为 leader，当它确认主节点客观下线时候，会向其他 sentinel 节点发送 sentinel is-master-down-by-addr 命令，要求将自己设置为leader，比如 sentinel-0 节点首先发起请求成为 leader 的请求。 每个 sentinel 节点都只能投出一票，于是当 sentinel-0 节点发起成为 leader 的请求后，会得到 sentinel-1 和 sentinel-2 节点的投票，总共得到 2 票，得到的票数和以下公式计算的值作比较： max(quorum, num(sentinels) / 2 + 1) = max(2, 3 / 2 + 1) =

1、启动VS2017，创建新项目： 2、找到你z3-master下的example.cpp所在位置，把它复制粘贴到创建好的项目源文件下： 3、此时会有提示，说存在很多错误，其实是因为还没有为其配环境，那么接下来我们就来配置环境啦： 4、点击"配置管理器"（我自己做的时候是让它们都处于64位环境）： 5、VC++目录---->包含目录（把z3-master/src/api 和 z3-master/src/api/c++ 都添加进去），这两个目录里有要用到的.h头文件 VC++目录---->库目录（把z3-master/build添加进去） 6、调试---->环境（找到libz3.dll所在目录z3-master/build，将z3-master/build添加到环境中）： 7、链接器---->输入---->附加依赖项（将libz3.lib; 添加进去）： 8、最后，把libz3.dll文件粘贴到该项目中： 9、调试代码，可成功运行： 来源： CSDN 作者： 08042在不在 链接： https://blog.csdn.net/weixin_42442802/article/details/104100440

Apache Kafka 概述 在大数据中，使用了大量的数据。 关于数据，我们有两个主要挑战。第一个挑战是如何收集大量的数据，第二个挑战是分析收集的数据。 为了克服这些挑战，您必须需要一个消息系统。 Kafka专为分布式高吞吐量系统而设计。 Kafka往往工作得很好，作为一个更传统的消息代理的替代品。 与其他消息传递系统相比，Kafka具有更好的吞吐量，内置分区，复制和固有的容错能力，这使得它非常适合大规模消息处理应用程序。 什么是消息系统？ 消息系统负责将数据从一个应用程序传输到另一个应用程序，因此应用程序可以专注于数据，但不担心如何共享它。 分布式消息传递基于可靠消息队列的概念。 消息在客户端应用程序和消息传递系统之间异步排队。 有两种类型的消息模式可用 - 一种是点对点，另一种是发布 - 订阅(pub-sub)消息系统。 大多数消息模式遵循 pub-sub kafka官网： http://kafka.apache.org/ 使用安装包版本： kafka_2.11-1.0.0 下载地址 https://mvnrepository.com/artifact/org.apache.kafka/kafka_2.11/1.0.0 已经安装 hadoop-2.6.0.tar ，zookeeper-3.4.5.tar 虚拟机 IP master 192.168.176.41 slave1

1. 前言   用GitHub管理自己的开源项目有几年了，最近一年更新得比较多，仓库也越来越多越来越大。有时候感觉GitHub太慢，尤其是最近感觉更为明显，于是萌生了再找个国内类似GitHub的代码托管平台的想法，同时我也还想持续更新GitHub上的仓库，于是需要一个本地仓库（我自己的开发机）多个远程仓库（Github、码云、coding）。 2. 一个远程仓库的git config   我的开源项目 Nebula 一个基于事件驱动的高性能TCP网络框架的git配置文件.git/config如下： [core] repositoryformatversion = 0 filemode = true bare = false logallrefupdates = true [remote "origin"] url = https://github.com/Bwar/Nebula.git fetch = +refs/heads/*:refs/remotes/origin/* [branch "master"] remote = origin merge = refs/heads/master 3. 用git命令行添加多个远程仓库   添加一个名为“mirror”的远程仓库： git remote add mirror https://gitee.com/Bwar/Nebula.git

一、概述 什么是哨兵机制 二、环境配置 2.1 虚拟机 2.2 安装Redis 2.3 配置主从复制 2.4 配置哨兵 2.5 测试 2.6 疑惑(待解决) 一、概述 什么是哨兵机制 Redis的哨兵(sentinel) 系统用于管理多个 Redis 服务器,该系统执行以下三个任务: 监控(Monitoring): 哨兵(sentinel) 会不断地检查你的Master和Slave是否运作正常。 提醒(Notification):当被监控的某个 Redis出现问题时, 哨兵(sentinel) 可以通过 API 向管理员或者其他应用程序发送通知。 自动故障迁移(Automatic failover):当一个Master不能正常工作时，哨兵(sentinel) 会开始一次自动故障迁移操作,它会将失效Master的其中一个Slave升级为新的Master, 并让失效Master的其他Slave改为复制新的Master; 当客户端试图连接失效的Master时,集群也会向客户端返回新Master的地址,使得集群可以使用Master代替失效Master。 哨兵(sentinel) 是一个分布式系统,你可以在一个架构中运行多个哨兵(sentinel) 进程,这些进程使用流言协议(gossipprotocols)来接收关于Master是否下线的信息,并使用投票协议(agreement

Kubeadm搭建k8s集群 kubernets架构图 一.kubeadm部署kubernetes v1.17.0 集群 1.环境准备 2.角色 3.初始化（注意：全部的主机） 3.1 关闭防火墙 3.2 关闭selinux 3.2 关闭swap分区 3.3 设置主机名 3.4 配置hosts 3.5 内核调整 4. 安装kubernets和docker 4.1 添加docker的yum源 4.2 添加kubernets的yum源 4.3 安装docker kubelet kubeadm kubelectl 4.3 开启docker 4.4 开启kubelet 5. Master节点(192.168.3.71)启动集群 6. Node节点(192.168.3.72)加入集群 7. 集群检查 7.1 检查集群节点 7.2 检查pod状态 kubernets架构图 一.kubeadm部署kubernetes v1.17.0 集群 1.环境准备 系统版本：Centos7.4 硬件需求：CPU至少2核，内存至少2G 2.角色 ip 角色 安装软件 192.168.3.71 k8s-master kube-apiserver kube-schduler kube-controller-manager docker flannel kubelet 192.168.3.72 k8s-node1

学习视频：https://www.bilibili.com/video/av24441039 学习资料： https://pan.baidu.com/s/18K0J7bclW8HApckKq9FiOw 提取码：bw2n 1、本地库初始化 命令： git init 操作：在文件夹下右键->git bash->git init 效果： Administrator@FKW7JIF862Y1F92 MINGW64 /e/GitRepositories/00.test ( master ) $ git init Reinitialized existing Git repository in E:/GitRepositories/00.test/.git/ Administrator@FKW7JIF862Y1F92 MINGW64 /e/GitRepositories/00.test ( master ) $ ll .git/ total 7 -rw-r--r-- 1 Administrator 197121 130 12月 26 22:10 config -rw-r--r-- 1 Administrator 197121 73 12月 26 22:08 description -rw-r--r-- 1 Administrator 197121 23 12月 26 22:08 HEAD

今天在做git push时出现了如下错误 分析原因，基本上可以确定是因为github上的远程库与本地库版本不一致（我对github上的文件做了编辑操作，且未更新到本地，当然也可能还有其他原因…），通过一番研究，找到了两种解决方案： 温柔型方案： 通过git pull 先将本地库更新到与远程库一致的版本，但要注意本地库后来做的修改可能被覆盖，最好使用git fetch(不会自动合并)，查看更新情况再有选择合并，或者先将本地库修改过的文件备份，git pull后再重新修改； 再运行git push即可成功。 暴力型方案： git提供了一种强制上传的方式：git push -f ，它会忽略版本不一致等问题，强制将本地库上传的远程库，但是一定要谨慎使用，因为-f会用本地库覆盖掉远程库，如果远程库上有重要更新，或者有其他同伴做的修改，也都会被覆盖，所以一定要在确定无严重后果的前提下使用此操作。 来源： CSDN 作者： _SnowMultiflora 链接： https://blog.csdn.net/Xw_Vivian/article/details/103826268