master

MySQL案例09:Last_IO_Error: Got fatal error 1236 from master when reading data from binary log

我只是一个虾纸丫 提交于 2020-01-01 03:08:20
刚处理完“挖矿”事件,在做最后一个MySQL NBU备份的时候,发现从库有问题,好奇的是怎么主从状态异常没有告警呢?先不管这么多了,处理了这个问题再完善告警内容。 一、错误信息 从库show slave status \G看到的错误信息如下: Slave_IO_Running: No Slave_SQL_Running: Yes Last_IO_Errno: 1236 Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: 'Client requested master to start replication from impossible position; the first event 'mysql-bin.000081' at 480141113, the last event read from './mysql-bin.000081' at 4, the last byte read from './mysql-bin.000081' at 4.' 二、错误原因 这里看到从库的io_thread已经终止,错误编号是1236,具体是由于读取主库的binlog日志位置( the first event 'mysql -bin. 000081 ' at

mysql主从复制配置

本秂侑毒 提交于 2020-01-01 02:56:41
保证主库和从库数据库数据一致 mysql主库MASTER配置(在my.cnf中加入以下配置): log-bin=master-bin binlog-do-db=test #需要同步的数据库名称 server-id=11 进行授权: grant replication slave on *.* to 'repl'@'192.168.1.110' identified by 'repl' with grant option; 重启mysql 查看master状态 show master status; mysql从库配置(在my.cnf中加入配置): server-id=12 master-host=192.168.1.104 master-user=repl master-password=repl master-port=3306 replicate-do-db=test #需要同步的数据库名称 #停止slave stop slave #更改日志同步点 CHANGE MASTER TO MASTER_HOST='192.168.1.104',MASTER_USER='repl', MASTER_PASSWORD='repl',MASTER_LOG_FILE='master-bin.000002',MASTER_POSITION=1134; #启动slave start slave

MySQL8.0 主从复制

谁说我不能喝 提交于 2020-01-01 02:51:28
环境: MySQL8.0 master:Centos7,192.168.5.116 slave:Centos7,192.168.5.194 主库配置: vi /etc/my.cnf log-bin=mysql-bin server-id=1 添加用于同步的数据库账号 use mysql; create user 'repl'@'%' identified by 'Test@1234'; grant replication slave on *.* to 'repl'@'%'; flush privileges; show master status; 从库配置: vi /etc/my.cnf server-id=2 添加用于同步的数据库账号 use mysql; create user 'repl'@'%' identified by 'Test@1234'; grant replication slave on *.* to 'repl'@'%'; flush privileges; 配置主从同步 change master to master_host='192.168.5.116', master_port=3306, master_user='repl', master_password='Test@1234', master_log_file='mysql-bin

mysql主从复制搭建

帅比萌擦擦* 提交于 2020-01-01 02:20:08
MySQL数据库自身提供的主从复制功能可以方便的实现数据的多处自动备份,实现数据库的拓展。多个数据备份不仅可以加强数据的安全性,通过实现读写分离还能进一步提升数据库的负载性能。 下图就描述了一个多个数据库间主从复制与读写分离的模型(来源网络): 在一主多从的数据库体系中,多个从服务器采用异步的方式更新主数据库的变化,业务服务器在执行写或者相关修改数据库的操作是在主服务器上进行的,读操作则是在各从服务器上进行。如果配置了多个从服务器或者多个主服务器又涉及到相应的负载均衡问题,关于负载均衡具体的技术细节还没有研究过,今天就先简单的实现一主一从的主从复制功能。 Mysql主从复制的实现原理图大致如下(来源网络): MySQL之间数据复制的基础是二进制日志文件(binary log file)。一台MySQL数据库一旦启用二进制日志后,其作为master,它的数据库中所有操作都会以“事件”的方式记录在二进制日志中,其他数据库作为slave通过一个I/O线程与主服务器保持通信,并监控master的二进制日志文件的变化,如果发现master二进制日志文件发生变化,则会把变化复制到自己的中继日志中,然后slave的一个SQL线程会把相关的“事件”执行到自己的数据库中,以此实现从数据库和主数据库的一致性,也就实现了主从复制。 实现MySQL主从复制需要进行的配置: 主服务器: 开启二进制日志

Docker Mysql主从同步配置搭建Demo

我与影子孤独终老i 提交于 2020-01-01 02:19:06
 进行Docker操作前,先建立目录,我的路径是d:/docker/mysql,目录结构如下: 1 --mysql 2 --master 3 --data 4 --conf 5 --my.cnf 6 --slaver 7 --data 8 --conf 9 --my.cnf View Code 1、主从配置文件 Master: my.cnf    1 [mysqld] 2 3 server_id = 1 4 5 log-bin= mysql-bin 6 7 read-only=0 8 9 binlog-do-db=blogging 10 11 replicate-ignore-db=mysql 12 13 replicate-ignore-db=sys 14 15 replicate-ignore-db=information_schema 16 17 replicate-ignore-db=performance_schema 18 19 20 21 !includedir /etc/mysql/conf.d/ 22 23 !includedir /etc/mysql/mysql.conf.d/ View Code Slaver: my.cnf 1 [mysqld] 2 3 server_id = 2 4 5 log-bin= mysql-bin 6 7 read-only=1

【Keepalived+MySQL】MySQL双主互备+高可用

痴心易碎 提交于 2020-01-01 02:18:37
一、基本信息说明 【DB1】 IP: 192.168.102.144 hostname: LVS-Real1 【DB2】 IP: 192.168.102.145 hostname: LVS-Real2 【VIP】 IP: 192.168.102.146 二、MySQL配置主主互备 1.配置DB1和DB2的/etc/my.cnf 【DB1】 [root@LVS-Real1 ~]# more /etc/my.cnf [client] port = 3306 socket = /tmp/mysql.sock [mysqld] user=mysql port = 3306 server_id = 1 #需保证唯一性 socket=/tmp/mysql.sock basedir =/usr/local/mysql datadir =/usr/local/mysql/data pid-file=/usr/local/mysql/data/mysqld.pid log-error=/usr/local/mysql/log/mysql-error.log log-bin=mysql-bin #开启二进制日志 relay-log=mysql-relay-bin replicate-wild-ignore-table=mysql.% #忽略复制mysql数据库下的所有对象,以下依次类推

mysql半同步复制实现

那年仲夏 提交于 2020-01-01 02:17:59
mysql半同步复制和异步复制的区别如上述架构图所看到的:在mysql异步复制的情况下。Mysql Master Server将自己的Binary Log通过复制线程传输出去以后,Mysql Master Sever就自己主动返回数据给client。而无论slave上是否接受到了这个二进制日志。在半同步复制的架构下。当master在将自己binlog发给slave上的时候。要确保slave已经接受到了这个二进制日志以后,才会返回数据给client。 对照两种架构:异步复制对于用户来说,能够确保得到高速的响应结构,可是不能确保二进制日志确实到达了slave上。半同步复制对于客户的请求响应略微慢点,可是他能够保证二进制日志的完整性。 以下来配置一个半同步复制实现的主从架构: 192.168.1.141为mysql的主server 192.168.1.142为mysql的从server 1.为mysql主server提供配置 编辑/etc/my.cnf,提供下面的配置 log_bin=index server_id=1 在主server上授权 # mysql> grant replication slave,replication client on user@'192.168.1.142' identified by "123456"; # mysql> flush

keepalived+mysql实现双主高可用

你。 提交于 2020-01-01 02:17:47
环境: DB1:centos6.8、mysql5.5、192.168.2.204 hostname:bogon DB2:centos6.8、mysql5.5、192.168.2.205 hostname:localhost.localdomain vip:192.168.2.33 一、先配置DB1和DB2的双主热备 1、分别在DB1和DB2上安装mysql,我这里是用的ansible自动部署 [root@www ansible]# ansible-playbook lnmp.yml PLAY [new] ********************************************************************* TASK [setup] ******************************************************************* ok: [192.168.2.205] ok: [192.168.2.204] TASK [mysql : Create backup folder] ******************************************** ok: [192.168.2.204] ok: [192.168.2.205] TASK [mysql : create log folder]

MySQL灾备切换

若如初见. 提交于 2020-01-01 02:12:36
1.1 配置mysql主从 主库IP:192.168.8.62 从库IP:192.168.8.65 主库IP:192.168.8.62 操作 mysql -uroot -p mysql> grant replication slave on *.* to tongbu@'192.168.8.65' identified by '123456'; mysql> show master status \G *************************** 1. row *************************** File: mysql-bin.000005 Position: 331 #拿到File 和Position #锁表 flush tables with read lock; 锁表 1.2 从库IP:192.168.8.65 操作 mysql> change master to master_host='192.168.8.62',master_user='tongbu',master_password='123456',master_log_file='mysql-bin.000005',master_log_pos=331; mysql> start slave; mysql> show slave status \G #内容有这两给 YES Slave

Keepalived+MySQL实现高可用

旧城冷巷雨未停 提交于 2020-01-01 02:12:21
MySQL的高可用方案有很多,比如 Cluster , MMM , MHA , DRBD 等,这些都比较复杂,我前面的文章也有介绍。最近Oracle官方也推出了 Fabric 。有时我们不需要这么复杂的环境,这些方案各有优劣。有时简单的且我们能够hold住的方案才是适合我们的。比如MySQL Replication,然后加上各种高可用软件,比如 Keepalived 等,就能实现我们需要的高可用环境。 MySQL架构为master/slave,当master故障时,vip漂移到slave上。提供服务。当然也可以设置为双master,但是不是每个方案都是完美的。这里设置为双master有个问题需要注意,比如,当用户发表文章时,由于此时主机的压力很大时,假设落后2000秒,那么这台主机宕机了,另一台主机接管(vip漂移到从机上)时,因为同步延时大,用户刚才发表的文章还没复制过来,于是用户又发表了一遍文章,当原来的master修复好后,由于I/O和SQL线程还处于开启状态,因此还会继续同步刚才没有同步复制完的数据,这时有可能把用户新发表的文章更改掉。这里所以采用master/slave架构。在这种架构中,故障切换以后,采取手动操作的方式与新的master进行复制。 简单环境如下: master 192.168.0.100 slave 192.168.0.101 VIP 192.168.0