master

MySQL 主备数据库切换报错1396处理方法，操作步骤如下： mysql> show slave status \G; *************************** 1. row *************************** Slave_IO_State: Waiting for master to send event Master_Host: 196.55.3.180 Master_User: repl Master_Port: 3311 Connect_Retry: 60 Master_Log_File: mysql-bin.000002 Read_Master_Log_Pos: 1674 Relay_Log_File: relay-log.000002 Relay_Log_Pos: 367 Relay_Master_Log_File: mysql-bin.000001 Slave_IO_Running: Yes Slave_SQL_Running: No Replicate_Do_DB: Replicate_Ignore_DB: Replicate_Do_Table: Replicate_Ignore_Table: Replicate_Wild_Do_Table: Replicate_Wild_Ignore_Table: Last_Errno:

进入slave服务器，运行： mysql> show slave status\G ....... Relay_Log_File: localhost-relay-bin.000535 Relay_Log_Pos: 21795072 Relay_Master_Log_File: localhost-bin.000094 Slave_IO_Running: Yes Slave_SQL_Running: No Replicate_Do_DB: Replicate_Ignore_DB: ...... 解决办法一、 Slave_SQL_Running: No 1.程序可能在slave上进行了写操作 2.也可能是slave机器重起后，事务回滚造成的. 一般是事务回滚造成的： 解决办法： mysql> stop slave ; mysql> set GLOBAL SQL_SLAVE_SKIP_COUNTER=1; mysql> start slave ; 解决办法二、 首先停掉Slave服务：slave stop 到主服务器上查看主机状态： 记录File和Position对应的值 进入master mysql> show master status; +----------------------+----------+--------------+------------------+ |

目录 一.主从复制简介 二.主从复制原理 三、主从复制搭建实战 四.主从复制基本故障处理 五.延时从库 企业案例： 模拟环境 一.主从复制简介 复制是 MySQL 的一项功能，允许服务器将更改从一个实例复制到另一个实例。 1）主服务器将所有数据和结构更改记录到二进制日志中。 2）从属服务器从主服务器请求该二进制日志并在本地应用其内容。 3）IO：请求主库，获取上一次执行过的新的事件，并存放到relaylog 4）SQL：从relaylog中将sql语句翻译给从库执行 二.主从复制原理 主从复制的前提 1）两台或两台以上的数据库实例 2）主库要开启二进制日志 3）主库要有复制用户 4）主库的server_id和从库不同 5）从库需要在开启复制功能前，要获取到主库之前的数据（主库备份，并且记录binlog当时位置） 6）从库在第一次开启主从复制时，时必须获知主库：ip，port，user，password，logfile，pos 7）从库要开启相关线程：IO、SQL 8）从库需要记录复制相关用户信息，还应该记录到上次已经从主库请求到哪个二进制日志 9）从库请求过来的binlog，首先要存下来，并且执行binlog，执行过的信息保存下来 主从复制涉及到的文件和线程 主库： 1）主库binlog：记录主库发生过的修改事件 2）dump thread：给从库传送（TP）二进制日志线程 从库：

目录 一.备份的原因 二.备份的类型 三.备份的方式 四.备份策略 五.备份工具 六、企业故障恢复案例 1.模拟环境 2.模拟恢复数据过程： 一.备份的原因 运维工作的核心简单概括就两件事: 1）第一个是保护公司的数据. 2）第二个是让网站能7*24小时提供服务(用户体验)。 1）备份就是为了恢复。 2）尽量减少数据的丢失（公司的损失） 二.备份的类型 冷备份: 这些备份在用户不能访问数据时进行，因此无法读取或修改数据。这些脱机备份会阻止执行任何使用数据的活动。这些类型的备份不会干扰正常运行的系统的性能。但是，对于某些应用程序，会无法接受必须在一段较长的时间里锁定或完全阻止用户访问数据。 温备份: 这些备份在读取数据时进行，但在多数情况下，在进行备份时不能修改数据本身。这种中途备份类型的优点是不必完全锁定最终用户。但是，其不足之处在于无法在进行备份时修改数据集，这可能使这种类型的备份不适用于某些应用程序。在备份过程中无法修改数据可能产生性能问题。 热备份: 这些动态备份在读取或修改数据的过程中进行，很少中断或者不中断传输或处理数据的功能。使用热备份时，系统仍可供读取和修改数据的操作访问。 三.备份的方式 逻辑备份: 1. 逻辑备份 1）binlog 2）into outfile mysql> select * from world.city into outfile '/tmp

docker容器编排工具 k8s，messos，swarm（目前几乎只有k8s一家独大） k8s最主要的4大功能： #https://kubernetes.io/zh 1：故障自愈 重新启动失败的容器。 2：服务发现和负载均衡 3：灰度发布，一键回滚 4：自动伸缩（自动扩容和自动缩容） 使用简单的命令或者UI,或者根据CPU使用情况，自动调整应用程序副本数 ===================================================================== 创建第一个k8s容器 k8s的容器 叫 Pod : (最小的单位是Pod，一个Pod就是一个容器) 1：编写一个pod文件 [root@k8s-master ~]# vim k8s_pod.yml apiVersion: v1 #定义k8s api的版本v1 kind: Pod #kind资源 Pod metadata: #属性，名字叫nginx,标签叫app : web(键值对) name: nginx labels: app: web spec: #详细 containers: #容器信息 - name: nginx #容器叫nginx image: 192.168.6.129:5000/nginx:latest #使用的镜像 ports: #容器开放的端口 -

本文简单介绍了MySQL的高可用实现方式之一的MHA MHA：Master High Availability，对主节点进行监控，可实现自动故障转移至其它从节点；通过提升某一从节点为新的主节点，基于主从复制实现，还需要客户端配合实现，目前MHA主要支持一主多从的架构，要搭建MHA,要求一个复制集群中必须最少有三台数据库服务器，一主二从，即一台充当master，一台充当备用master，另外一台充当从库。官网:https://code.google.com/archive/p/mysql-master-ha/ MHA工作原理： 　　1、 从宕机崩溃的master保存二进制日志事件（binlog events） 　　2 、识别含有最新更新的slave 3、 应用差异的中继日志（relay log）到其他的slave 4 、应用从master保存的二进制日志事件（binlog events） 5、 提升一个slave为新的master 6 、使其他的slave连接新的master进行复制 MHA配置方法 1、准备安装环境 　　- MHA服务器1台，CentOS7 　　- 主库1台，CentOS7，192.168.1.100 　　- 从库1台，CentOS7，192.168.1.101 　　- 从库1台，CentOS7，192.168.1.102 　　从官网下载安装包 　　　　1

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的本地使用 Git是什么？ Git是世界上最先进的分布式版本控制系统。 那么什么是版本控制系统？ 我们来举个例子，假设我创建了一个项目Project.1，里面写了一个README.txt文档、一个code1.cs和一个code2.cs，第二天我突然想改进一下版本，但是我们不能直接在这个项目里改，因为如果直接在这里面改，我们要是想要退回去的话就会很麻烦，因为我们可能记不住上一个版本里面的代码是什么样子的，而且改代码这个东西经常是改一个地方就要将许多地方一同改掉。所以，我就想了一个办法，就是将这个项目拷贝一份，然后将他重命名为Project.2。这就是我们最朴素的一个版本管理的方法。 但是随着代码量的增加，这种方法无疑是不太靠谱的，如果你的程序是多人合作开发的，那问题会更大，因为如果一联网，大家的版本互相覆盖，到底哪个版本是谁的，该用哪个版本就会出问题了。 Linus在开发Linux系统的时候就遇到了这个问题，而为了解决这个问题，Linus最终花费两周的时间用C语言写出了Git。 分布式又是什么？ 先说说集中式版本控制系统，集中式版本控制系统的版本库是集中存放在中央服务器的，但是我们干活的时候都是用的自己的电脑，所以要先从中央服务器中取得最新的版本，然后开始干活，再把自己干好的活推送到中央服务器。这个集中式版本控制系统最大的毛病就是联网才能干活

新手白帽子注意：参考资料教学的效果不一定是最佳的，随意观看以后放进来的，什么是好的教程由各位以后去定义了。 还有更棒的教学，人变懒了没去整理它们。如果您留意本博客的所有文章的话一定会发现：） web靶机：bwapp pikachu-master DVWA-master phpcms 数据库文件环境直接百度搜导入导出命令 其他靶机直接github搜 内网渗透：这个不需要明示靶机环境了吧：） 参考资料 老男孩网络安全： https://www.bilibili.com/video/av56912491?p=14 提权与内网渗透： https://www.bilibili.com/video/av73708474?p=2 来源： https://www.cnblogs.com/sec875/p/11874954.html

k8s集群解决的问题 k8s的节点类型 master节点所用到的组件 node节点所用到的组件 命名空间 resource quotas lable replication controller（RC） Deployment service volume 网络通信场景 k8s集群解决的问题 Docker之间跨节点的通讯 动态管理集群负载，使集群工作在期望的状态 集群之间资源的调度 集群的运行方式 k8s的节点类型 master节点负责整个集群的控制和管理 node节点是负载节点，运行pod。 master节点所用到的组件 kube-apiserver提供整个集群资源的操作入口（增删改查），也是集群的控制入口，提供http rest接口。 etcd保存整个集群的状态，也即是资源信息。KEY/VALUE模式的存储系统 kube-schedule负载pod（资源）的调度，根据设置策略调度pod到指定的node上运行。 kube-controller-manager维护集群，所有资源的自动化控制中心。当整个集群的状态与期望不符合的时候，组件会努力让集群恢复期望状态，比如：当一个pod死亡，组件新建一个pod恢复对应replicas set期望的状态。 node节点所用到的组件 kubelet负责pod的生命周期管理，同时与master密切协作，实现集群管理的基本功能 kube