主从复制

mysql 主从不一致解决方法

大兔子大兔子 提交于 2021-01-26 07:14:08
方法一:忽略错误,同步 该方法适用于主从库数据相差不大,或者要求数据可以不完全统一的情况,数据要求不严格的情况 解决: stop slave; #表示跳过一步错误,后面的数字可变 set global sql_slave_skip_counter =1; start slave; 之后再用mysql> show slave status\G 查看: Slave_IO_Running: Yes Slave_SQL_Running: Yes ok,现在主从同步状态正常了。。。 方式二:重新做主从,完全同步 该方法适用于主从库数据相差较大,或者要求数据完全统一的情况 1.先进入主库,进行锁表,防止数据写入 使用命令: mysql> flush tables with read lock; 注意:该处是锁定为只读状态,语句不区分大小写 2.进行数据备份 [root@server01 mysql]#mysqldump -uroot -p -hlocalhost > mysql.bak.sql 这里注意一点:数据库备份一定要定期进行,可以用shell脚本或者 python 脚本,都比较方便,确保数据万无一失 3.查看master 状态 mysql> show master status; +-------------------+----------+--------------+------

Redis_主从复制

◇◆丶佛笑我妖孽 提交于 2020-11-21 12:21:06
主从复制 Redis的复制功能没有增量复制,每次重连都会把主库整个内存快照发给从库,所以需要避免向在线服务的压力较大的主库上增加从库。 Redis的复制由于会使用快照持久化方式,所以如果你的Redis持久化方式选择的是日志追加方式(aof), 那么系统有可能在同一时刻既做aof日志文件的同步刷写磁盘,又做快照写磁盘操作,这个时候Redis的响应能力会受到影响。 所以如果选用aof持久化,则加从库需要更加谨慎。 准备工作 cd /am/usr/redis mkdir slave-test cd slave-test mkdir 6000 6001 cd /am/usr/redis/redis-3.0.7 cp src/redis-server /am/usr/redis/slave-test cp src/redis-config /am/usr/redis/slave-test cd /am/usr/redis/slave-test cp redis.config /am/usr/redis/slave-test/redis-6000.config //-- ... 6001 启用主从复制 cd /am/usr/redis/slave-test vim redis-6000.config //-- 修改配置如下: daemonize yes port 6000 logfile "

一步步实现redis+sentinel双机热备

时光总嘲笑我的痴心妄想 提交于 2020-03-01 12:57:29
前言 前些天一直在忙线上环境部署的事情,初步想的是,nginx(keepalive双机热备)+3(tomcat)+2redis( 双机热备 ),但是后来由于阿里云服务器经典网络不提供虚拟IP,无法使用keepalive,nginx双机热备只能暂时先放弃,退而求其次,采用nginx+3tomcat+2redis(双机热备)。nginx+tomcat由于之前配置过,所以重点就落在redis双机热备上,毕竟是线上系统,适当的抗灾能力还是需要的,咱可不能像测试系统那么去玩,否则黑锅就有的背了,毕竟码代码赚点生活费也不容易。 在网上也查了一些资料,redis集群实现大概有以下几种方式: 1.redis-cluster,官方提供的集群搭建方案(过于重量级,比较适合后期数据量较大的时候的使用) 2.redis+keepalive(由于我们使用的阿里云服务器不支持虚拟IP,所以这套方案也就夭折了) 3.redis+zookeeper(需要引入zookeeper,对现有代码变动较大) 4.redis+sentinel(redis自带监控中间件)(代码变动小,配置少,而且能满足双机热备的需求) 基于我们目前的情况以及需求,经过初略对比,我们团队决定选用第四种方案redis+sentinel实现双机热备。 准备工作 1.安装redis-001(主) $ wget http://download

实现Web应用的高并发、负载均衡配置(1)

老子叫甜甜 提交于 2020-03-01 06:16:07
第一步:查看Linux自带的JDK是否已安装 (卸载CentOS已安装的jdk版本,重新安装sun公司的jdk。此步不是必须的,只是建议,方便后面jdk升级) (1)先查看 # rpm -qa | grep java 显示如下信息: java-1.4.2-gcj-compat-1.4.2.0-40jpp.115 java-1.6.0-openjdk-1.6.0.0-1.7.b09.el5 (2)卸载 # rpm -e --nodeps java-1.4.2-gcj-compat-1.4.2.0-40jpp.115 # rpm -e --nodeps java-1.6.0-openjdk-1.6.0.0-1.7.b09.el5 还有一些其他的命令 # rpm -qa | grep gcj # rpm -qa | grep jdk 如果出现找不到openjdk source的话,那么还可以这样卸载 # yum -y remove java java-1.4.2-gcj-compat-1.4.2.0-40jpp.115 # yum -y remove java java-1.6.0-openjdk-1.6.0.0-1.7.b09.el5 (3)查看jdk的信息或直接执行 # rpm -qa|grep jdk 或 # rpm -q jdk 或 # java -version (4

MySQL5.5 数据库主从复制

匆匆过客 提交于 2020-02-29 12:44:15
今天参照网上的资料进行mysql数据库的主从复制研究,本来网上的资料已经很详细,但是我在实践中还是遇到了很多问题,下面就根据网上的资料以及我遇到的问题进行一个总结。 系统环境:Ubuntu12.04 软件版本:mysql-server-5.5 主机IP:192.168.0.200 从机IP:192.168.0.201 操作: 1、主机操作: 1)、编辑mysql配置文件my.cnf [mysqld] server-id=1 log-bin=mysql-bin 注:网上还有一些其他的配置,但是为了偷懒只配置了这两个重要的,当然这两个也是必须的。 2)、用root登陆mysql执行下面的代码 //建立一个用户dean密码123456,并赋予replication slave权限: mysql>grant replication slave on *.* to 'dean'@'192.189.0.201' identified by '123456'; //让权限立即生效 mysql>flush privileges; //查询二进制文件的文件名和状态(后面要用) mysql>show master status \G File:mysql-bin.000006 Position:107 Binlog_Do_DB: Binlog_Ignore_DB: 2、从机操作: 1)

redis之主从同步简单设置

梦想的初衷 提交于 2019-12-12 14:04:21
【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 1、配置多个redis-conf 首先编辑多个redis-conf文件,将端口、守护进程、rdb、log、aof全部设置为自己的内容,方便观察不同的端口不同的区分内容 这里我配置啦三个端口的redis,分别是:6379 6380 6381,模拟三台redis服务器 2、配从不配主 主从复制,只需要配置从机即可,主机可以不配置; 2.1、查看当前三个redis的状态与主从标识 info replication 图中标的三台redis全部式master,即主机,并且没有任何的从机 2.2、设置从机 分别在80 81的操作端,进行设置自己的主机(现在是本地的不同端口) 127.0.0.1:6380> slaveof 127.0.0.1 6379 127.0.0.1:6381> slaveof 127.0.0.1 6379 设置完毕之后,重新查看主从标识 现在就可以主从复制啦: 2.3、如果三个机器同时操作一个key,结果会怎样? 其实吧,从机是不能写内容,只能读 3、如果master/slave挂掉了 两个slave(80 81)会怎样? 3.1、master挂了,猜测: 3.1.1、重新选老大(当前配置,错误) 2、保持不动(当前配置,正确) 其实是保持不动,老大走了,临走之前啥都没说,谁也不敢上位呀; 3.1.2

MySQL主从同步(1)——同步介绍、复制的原理、复制过程

…衆ロ難τιáo~ 提交于 2019-12-03 20:45:59
由于背景原因,所做的主从同步还是要基于MySQL 5.1的版本,主从同步主要是一个数据库读写访问原来的数据库热度过大,需要做到使用从库对读分压。 MySQL主从同步介绍 MySQL 支持单双向、链式级联、异步复制。在复制过程中,一个服务器充当主服务器(Master),而一个或多个其它的服务器充当从服务器(Slave)。 如果设置了链式级联复制,那么,从(slave)服务器本身除了充当从服务器外,也会同时充当其下面从服务器的主服务器。链式级联复制类似A->B ->C ->D 的复制形式。 当配置好主从复制后,所有对数据库内容的更新就必须在主服务器上进行,以避免用户对主服务器上数据内容的更新与对从服务器上数据库内容的更新之间发生冲突。生产环境中一般会,忽略授权表同步,然后对从服务器上的而用户授权select读权限,或在my.cnf配置文件中加read-only 参数来确保从库只读,当然二者同时操作效果更佳。 MySQL主从复制的原理 MySQL 主从复制是一个异步复制过程(但看起来也是实时的),数据库数据从一个MySQL数据库(我们称为Master)复制到另一个MySQL数据库(我们称之为Slave)。在Master和Slave之间实现整个主从复制的过程有三个线程参与完成。其中两个线程(SQL线程和IO线程)在Slave端,另一个线程(IO线程)在Master端。

搭建高可用mongodb集群(一)——配置mongodb

别等时光非礼了梦想. 提交于 2019-12-02 22:33:17
在大数据的时代,传统的关系型数据库要能更高的服务必须要解决高并发读写、海量数据高效存储、高可扩展性和高可用性这些难题。不过就是因为这些问题Nosql诞生了。 NOSQL有这些优势: 大数据量 ,可以通过廉价服务器存储大量的数据,轻松摆脱传统mysql单表存储量级限制。 高扩展性 ,Nosql去掉了关系数据库的关系型特性,很容易横向扩展,摆脱了以往老是纵向扩展的诟病。 高性能 ,Nosql通过简单的key-value方式获取数据,非常快速。还有NoSQL的Cache是记录级的,是一种细粒度的Cache,所以NoSQL在这个层面上来说就要性能高很多。 灵活的数据模型 ,NoSQL无需事先为要存储的数据建立字段,随时可以存储自定义的数据格式。而在关系数据库里,增删字段是一件非常麻烦的事情。如果是非常大数据量的表,增加字段简直就是一个噩梦。 高可用 ,NoSQL在不太影响性能的情况,就可以方便的实现高可用的架构。比如mongodb通过mongos、mongo分片就可以快速配置出高可用配置。 在nosql数据库里,大部分的查询都是键值对(key、value)的方式。MongoDB是一个介于关系数据库和非关系数据库之间的产品,是非关系数据库当中最像关系数据库的。支持类似于面向对象的查询语言,几乎可以实现类似关系数据库单表查询的绝大部分功能,而且还支持对数据建立索引。所以这个非常方便

MySQL多实例,主从同步(3)—— 主从复制配置

江枫思渺然 提交于 2019-11-27 04:08:10
主从复制配置 主库,称为Master 从库称为Slave。 1. 主库上执行操作 (1) 设置server-id 值并开启binlog设置 根据前文MySQL的同步原理,我们知道复制的关键因素就是binlog日志。 执行 vi /data/3306/my.cnf 编辑my.cnf配置文件,按如下两个参数内容修改: [mysqld] server-id =1 log-bin=/data/3306/mysql-bin 检查配置后的结果 grep -E "server-id|log-bin" /data/3306/my.cnf log-bin=/data/3306/mysql-bin server-id=1 (2) 建立用于同步的账号rep mysql -uroot -p'' -S /data/3306/mysql.sock grant replication slave on *.* to 'rep'@'10.0.0.%' identified by 'password'; (3) 锁表只读(当前窗口不要关闭) 生产环境时,操作主从复制,需要申请停机事件,锁表会影响业务。 flush tables with read lock; interactive_timeout=60 wait_timeout=60 (4) 查看主库状态 查看主库状态,即当前日志文件名和二进制偏移量 show

MySQL MHA: 一种master高可用的主从复制解决方案

这一生的挚爱 提交于 2019-11-26 19:50:30
大纲 前言 MHA的架构 环境部署 实验步骤 总结 前言 上篇文章我们实现了 MySQL 的主从复制, 但是我们之前就说过, 主从复制是有很多问题的 , 我们这篇文章为大家介绍一如何使用 MHA 来实现 MySQL 复制集群的高可用 MHA的架构 MHA (Master HA) 实现 MySQL主从复制主节点高可用 , 主要实现了 Automated master monitoring and failover 自主监控和故障转移 Interactive (manual) Master Failover 手动故障转移 Non-interactive master failover 非交互式故障转移 Online switching master to a different host 在线切换到新主机 项目地址 Google Code MHA 服务有两种角色, 完成相应的功能 MHA Manager(管理节点): 通常单独部署在单台主机上, 用来管理多个 Master/Slave 集群, 每个集群通常被称为 Application MHA Slave(数据节点): 通常部署在单台 MySQL 服务器上, 通过监控和具有解析和清理log功能的脚本来加快故障转移 MySQL主节点故障时 , 按下面的步骤进行转移 MHA的各组件 Manager 节点的组件 masterha_check