master

003.MySQL高可用主从复制新增slave

◇◆丶佛笑我妖孽 提交于 2019-12-17 05:33:52
原文: 003.MySQL高可用主从复制新增slave 一 基础环境 主机名 系统版本 MySQL版本 主机IP master CentOS 6.8 MySQL 5.6 172.24.8.10 slave01 CentOS 6.8 MySQL 5.6 172.24.8.11 slave02 CentOS 6.8 MySQL 5.6 172.24.8.20 二 新增slave2方案 2.1 方案1:-复制主库 复制主库要步骤: 将内存中的数据同步到表中; 锁定表,不让出现新数据; 备份; 解锁; 将备份传送到slave02,在slave02上同步数据; slave2上设置相应的master_log_file和master-log_pos。 2.2 方案2:复制从库 停止从库slave01:mysql> stop slave; 看当前从库的状态,mysql> show slave status;记下 Relay_Master_Log_file 和 Exec_Master_Log_Pos; 备份从库数据 将备份传送到slave02,在slave2上同步数据; slave02上设置相应的master_log_file和master-log_pos。 注意:此方案中master_log_file和master-log_pos也和slave中一样,指向主库。 2.3 方案对比

基于heartbeat的单播方式实现tomcat高可用

可紊 提交于 2019-12-17 05:31:44
1、节点规划 在master、backup节点上添加eth0、eth1两网卡,具体添加过程,参考“ 基于VMware为CentOS 6.5配置两个网卡 ” 2、IP规划 master backup eth0 192.168.46.128 192.168.46.130 eth1 192.168.46.129 192.168.46.131 上面这个表格说明master节点中的eth0网卡的IP是192.168.46.128,eth1网卡的IP是192.168.46.129;backup节点中eth0网卡的IP是192.168.46.130,eth1网卡的IP是192.168.46.131 3、VIP规划(虚拟IP规划) IP地址 子网掩码 说明 192.168.46.150 255.255.255.0 192.168.46.150/24 192.168.46.150/24就等同于IP是192.168.46.150,子网掩码是255.255.255.0 3、网卡规划 master backup eth0 数据网卡 数据网卡 eth1 心跳网卡 心跳网卡 4、软件规划 软件 版本 说明 heartbeat 3.0.4 使用yum自动安装的 tomcat 7.0.70 需要手动配置 5、目录规划 软件 目录 tomcat-7.0.70 /etc/server 6、安装tomcat

探究 Nginx 中 reload 流程的真相

混江龙づ霸主 提交于 2019-12-17 03:42:32
今天这篇文章主要来介绍下 Nginx 的 reload 流程。实际上在之前文章中,在更改了 nginx 配置文件时,我们都会执行 nginx -s reload 命令,我们执行这条命令的原因是希望 nginx 不停止服务始终在处理新的请求的同时把 nginx 的配置文件平滑的把旧的 nginx.conf 配置更新为新的 nginx.conf 配置。 这样一个功能对于 nginx 非常有必要,但是有时候我们会发现在执行 nginx -s reload 命令后,worker 子进程的数量会变多了,这是因为老的配置运行的 worker 进程长时间没有退出,当使用 stream 做四层反向代理的时候,可能这种场景会更多。 那么下面我们通过分析 nginx 的 reload 流程,来探究下 nginx 到底做了些什么?所谓优雅的退出和立即退出有什么区别? 1 | 0 reload 流程 第一步在修改好 nginx 的配置文件 nginx.conf 后,向 master 进程发送 HUP 信号,这实际上和我们在命令行执行 nginx -s reload 命令效果是一样的。 那么 master 进程在收到 HUP 信号以后,会在第二步检查我们的配置文件语法是否正确,也就是说我们并不一定非要在 nginx -s reload 前执行 nginx -t 检验下语法是否正确,因为在第二步 nginx

Redis Cluster集群配置与管理

痞子三分冷 提交于 2019-12-17 02:58:52
Redis Cluster介绍 Redis Cluster集群是redis集群的一种方式,由官方提供,由多个节点组成的分布式网络集群,每个节点可以是主,也可以是从,但每个主节点都需要有对应的从节点,保证高可用,主节点提供数据读写,不支持同时处理多个键(如mset/mget命令),因为redis需要把键均匀分布在各个节点上,并发量很高的情况下同时创建键值会降低性能并导致不可预测的行为。支持在线增加、删除节点,客户端可以连任何一个主节点进行读写。 Redis Cluster采用了分布式系统的分片(分区)的思路,每个主节点为一个分片,这样也就意味着 存储的数据是分散在所有分片中的。当增加节点或删除主节点时,原存储在某个主节点中的数据 会自动再次分配到其他主节点。 如图,各节点间是相互通信的,通信端口为各节点Redis服务端口+10000,这个端口是固定的,所以注意防火墙设置, 节点之间通过二进制协议通信,这样的目的是减少带宽消耗。 在Redis Cluster中有一个概念slot,我们翻译为槽。Slot数量是固定的,为16384个。这些slot会均匀地分布到各个节点上,另外Redis的键和值会根据hash算法存储在对应的slot中。简单讲,对于一个键值对,存的时候在哪里是通过 hash算法算出来的,那么取得时候也会算一下,知道值在哪个slot上。根据slot编号再到对应的节点上去取。

mysql主备配置方法

给你一囗甜甜゛ 提交于 2019-12-17 02:57:47
1. 选择两台机器(这里选的centos6.5 final),安装相同版本的mysql yum install mysql ; yum install mysql-server; 2. 启动mysql service mysqld start 3. 登录两个mysql,执行如下命令 GRANT REPLICATION SLAVE,REPLICATION CLIENT on *.* to repl@'mysql机器IP' identified by 'password'; 复制用户并授权 4. 配置主mysql的/etc/my.cnf [client] port = 3306 socket = /dev/shm/mysql/mysql.sock default-character-set = utf8 [mysqld_safe] socket = /dev/shm/mysql/mysql.sock nice = 0 [mysqld] user = mysql socket = /dev/shm/mysql/mysql.sock port = 3306 basedir = /usr datadir = /mysql/data log-bin = mysql-bin tmpdir = /tmp skip-external-locking bind-address = 172.16.1.1

NoSQL之Redis——Redis群集

跟風遠走 提交于 2019-12-17 01:48:32
实验环境 用两台服务器模拟6台服务器(添加网卡) 主服务器M1 192.168.13.128 主服务器M2 192.168.13.135 主服务器M3 192.168.13.136 从服务器S1 192.168.13.129 从服务器S2 192.168.13.137 从服务器S3 192.168.13.138 1,在两台服务器上都安装Redis [root@localhost ~]# yum install gcc gcc-c++ make -y ##安装环境组件 [root@localhost ~]# mount.cifs //192.168.100.3/LNMP-C7 /mnt/ ##挂载 Password for root@//192.168.100.3/LNMP-C7: [root@localhost ~]# cd /mnt/ [root@localhost mnt]# tar zxvf redis-5.0.7.tar.gz -C /opt/ ##解压 [root@localhost mnt]# cd /opt/redis-5.0.7/ [root@localhost redis-5.0.7]# make ##编译 [root@localhost redis-5.0.7]# make PREFIX=/usr/local/redis/ install ##安装 [root

Redis的简介

£可爱£侵袭症+ 提交于 2019-12-17 00:06:23
Redis 简介 Redis 是一个高性能的key-value数据库。支持 复杂的数据结构 ,支持 持久化 ,支持 主从集群 ,支持 高可用 ,支持 较大的value存储 ... Redis是一个nosql,非关系型数据库。 Redis 与其他 key - value 缓存产品有以下几个特点: Reids是基于内存读写的。 Redis支持数据的持久化,可以将内存中的数据保存在磁盘中,重启的时候可以再次加载进行使用。 Redis不仅仅支持简单的key-value类型的数据,同时还提供list,set,zset,hash等数据结构的存储。 Redis支持数据的备份,即master-slave模式的数据备份。 何时使用Redis? 1.业务数据常用吗?命中率如何?如果命中率很低,就没有必要写入缓存。 2.业务数据是读操作多,还是写操作多?如果写操作多的话,需要频繁写入数据库,也没有必要使用缓存。 3.业务数据大小?如果业务数据是近G的文件,会给缓存带来很大压力。 Redis 优势 性能极高 – Redis能读的速度是110000次/s,写的速度是81000次/s 。 丰富的数据类型 – Redis支持二进制案例的 Strings, Lists, Hashes, Sets 及 Ordered Sets 数据类型操作。 原子 – Redis的所有操作都是原子性的

2019年8月30日

谁都会走 提交于 2019-12-16 21:03:24
ftp:客户端服务器软件,用于存放公用资料和软件等; svn:代码管理,存放的是av3协议和DB数据; xwiki:静态网页,用于存放环境搭建和源码链接等的说明性网页; ------ 协议规范了写作框架, ---------------- 更新base库: 如果有一些文件夹没有权限,则不能全局更新,只能去相应有权限的子文件夹去更新, 切换到具体文件夹中,然后git checkout master,然后LL,例如: Administrator@cdq MINGW64 /e/nena/funit/adas (master) $ git checkout master Already on 'master' Your branch is up to date with 'origin/master'. Administrator@cdq MINGW64 /e/nena/funit/adas (master) $ ll total 17 -rw-r--r-- 1 Administrator 197121 2393 Aug 29 10:51 CMakeLists.txt -rw-r--r-- 1 Administrator 197121 375 Aug 29 10:51 gitversion.hpp.in drwxr-xr-x 1 Administrator 197121 0 Aug 29

slave_master_info和slave_relay_log_info中的Master_log_pos不一致

跟風遠走 提交于 2019-12-16 19:36:54
最近在研究mysql的主从,发现一个问题,我在主库做任何修改时,在从库中只有slave_relay_log_info中的Master_log_pos在变化,而slave_master_info中的Master_log_pos竟然不发生变化 1. 首先看参数 (root@localhost)[mysql]> show variables like '%repository%'; +---------------------------+-------+ | Variable_name | Value | +---------------------------+-------+ | master_info_repository | TABLE | | relay_log_info_repository | TABLE | +---------------------------+-------+ 2. 通过官方文档看这两张表的定义 3. 看从库的同步情况 4. 查看这两张表的内容 5. 问题 可以看到slave_master_info中的Master_log_pos一直是154,而按照官方文档的说明,它应该也是1051才对,这是什么原因呢。通过询问摩天轮的大神,原来是这个参数sync_master_info搞的鬼。这个参数控制从库多久更新一次slave_master_info

探究 Nginx 中 reload 流程的真相

风格不统一 提交于 2019-12-16 16:33:19
今天这篇文章主要来介绍下 Nginx 的 reload 流程。实际上在之前文章中,在更改了 nginx 配置文件时,我们都会执行 nginx -s reload 命令,我们执行这条命令的原因是希望 nginx 不停止服务始终在处理新的请求的同时把 nginx 的配置文件平滑的把旧的 nginx.conf 配置更新为新的 nginx.conf 配置。 这样一个功能对于 nginx 非常有必要,但是有时候我们会发现在执行 nginx -s reload 命令后,worker 子进程的数量会变多了,这是因为老的配置运行的 worker 进程长时间没有退出,当使用 stream 做四层反向代理的时候,可能这种场景会更多。 那么下面我们通过分析 nginx 的 reload 流程,来探究下 nginx 到底做了些什么?所谓优雅的退出和立即退出有什么区别? reload 流程 第一步在修改好 nginx 的配置文件 nginx.conf 后,向 master 进程发送 HUP 信号,这实际上和我们在命令行执行 nginx -s reload 命令效果是一样的。 那么 master 进程在收到 HUP 信号以后,会在第二步检查我们的配置文件语法是否正确,也就是说我们并不一定非要在 nginx -s reload 前执行 nginx -t 检验下语法是否正确,因为在第二步 nginx 的