一.错误日志解析: (1) [ERROR]1452:无法在外键的表插入参考主键没有的数据 1452:无法在外键的表插入或更新参考主键没有的数据.由于item_discovery.itemid字段(外键)参考了items.itemid字段(主键),当要在item_discovery表插数据时,如果items表的主键没有对应的数据,则无法插入,报1452错误.此时可以检查参考的表的主键是否有主库对应的数据,如果有,则插入参考的表相应的数据,再开启复制恢复SQL线程. (2) [ERROR]1032:

这里搭建的主从是最简单的单一主从复制(即一个Master和一个slave,没有任何的热机备份和多slave),该主从结构的基本拓扑图如下所示: 建立基本的主从复制可以总结为以下三个基本步骤: 配置master服务器 配置slave服务器 将slave连接到master 在配置完成之后,我们会做一个简单的测试,测试复制是否正常. 本文所涉及的master和slave服务器均位于同一台单机上,使用不同的端口号区分,基本的环境为:Window 7 旗舰版 32位,MySQL的版本为5.6.21 .上一

我上一次遇到MySQL主从服务器数据一致性问题,想想是几年前的事情了,还依稀记得当时惊慌失措的情景,好在最后借助Maatkit解决了问题.几年后,当我再次面对同样的问题时,Maatkit已经不复存在,转而成为了Percona Toolkit的一部分,不变的是我依旧手忙脚乱,所以还是记录一下吧,保不准啥时候又会遇到这个问题. 如果你在MySQL从服务器上遇到类似下面的错误信息,那么恭喜你中招了: mysql> SHOW SLAVE STATUS\G Last_Error: Error 'Dupli

转自:http://www.cnblogs.com/kevingrace/p/6261091.html 在mysql工作中接触最多的就是mysql replication mysql在复制方面还是会有一些常规问题: 比如主库宕机或者从库宕机有可能会导致复制中断,通常需要进行人为修复, 或者很多时候需要把一个从库提升为主库,但对从库和主库的数据一致性不能保证一样. 这种情况下就需要使用percona-toolkit工具的pt-table-checksum组件来检查主从数据的一致性:如果发现不一致的

前面已经提到了mysql主从环境下数据一致性检查:mysql主从同步(3)-percona-toolkit工具(数据一致性监测.延迟监控)使用梳理今天这里再介绍另一种Mysql数据一致性自动检测工具:Maatkit.(不过Maatkit工具现在已经不维护了,推荐还是使用percona-toolkit工具吧!) Maatkit是一个开源的工具包,为mySQL日常管理提供了帮助,它包含很多工具,这里主要说下面两个:1)mk-table-checksum                     用来检

Docker Mysql主从同步配置搭建 建立目录 在虚拟机中建立目录,例如路径/home/mysql/master/data,目录结构如下: Linux中 新建文件夹命令:mkdir 文件夹名 返回上一层: cd ../ 新建/修改文件命令:vi 文件名 例如 配置主从配置文件 Master下: my.cnf 在conf目录下输入:vi my.cnf 打开my.cnf后输入下列代码 完成后,按esc键后输入[ :wq ]保存返回 注意:也可以借助FlashFXP传输配置文件到虚拟机目录,比较方

本章博客我们一起来聊一聊如何监控mysql数据库主从状态? 思路梳理: 1)首先我们都知道,判断Mysql主从是否正常,是通过主从上面的SQL和IO线程都为yes状态判断(通过awk取值,grep过滤和统计yes的个数,如果为2则为正常值),随后我们取值得脚本或者命令写入zabbix-agent端的配置文件中的“Userparamenter”,格式 为:Userparamenter [自定义 键值] ,[脚本或者命令参数] 2)我们zabbix没有监控主从的模板和监控项,所以我们需要自己定义添加

企业面试题1:(生产实战案例):监控MySQL主从同步是否异常,如果异常,则发送短信或者邮件给管理员.提示:如果没主从同步环境,可以用下面文本放到文件里读取来模拟:阶段1:开发一个守护进程脚本每30秒实现检测一次.阶段2:如果同步出现如下错误号(1158,1159,1008,1007,1062),则跳过错误.阶段3:请使用数组技术实现上述脚本(获取主从判断及错误号部分) [root@mysql01 shell]# mysql -uroot -poldboy123 -S /data//mysql.

一.MySQL主从搭建 搭建主从架构的MySQL常用的有两种实现方式: 基于binlog的fileName + postion模式完成主从同步. 基于gtid完成主从同步搭建. 本篇就介绍如何使用第一种方式完成MySQL主从环境的搭建. 基于fileName和position去实现主从复制,所谓的fileName就是bin-log的name,position指的是slave需要从master的binlog的哪个位置开始同步数据. 这种模式同步数据方式麻烦的地方就是需要我们自己通过如下的命令去查找

最近在梳理数据库集群的相关操作,现在花点时间整理一下关于mysql数据库集群的操作总结,恰好你又在看这一块,供一份参考.本次系列终结大概包括以下内容:多数据库安装.mycat部署安装.数据库之读写分离主从复制.数据库之双主多重.数据库分库分表.每一个点,有可能会对应一篇或者多篇文章,由于还要继续上班工作,所以本系列分享预计持续时间需要10天左右,有兴趣的您可以持续关注.我是一个菜鸟,如果写的不好的地方,望多多指点和包涵. 好了,不逼逼了,直接进入本次的主题:mycat的数据集群方式有很多种,比如

温习<高性能MySQL>的复制篇. 1 复制概述 Mysql内建的复制功能是构建大型,高性能应用程序的基础.将Mysql的数据分布到多个系统上去,这种分布的机制,是通过将Mysql的某一台主机的数据复制到其它主机(slaves)上,并重新执行一遍来实现的.复制过程中一个服务器充当主服务器,而一个或多个其它服务器充当从服务器.主服务器将更新写入二进制日志文件,并维护文件的一个索引以跟踪日志循环.这些日志可以记录发送到从服务器的更新.当一个从服务器连接主服务器时,它通知主服务器从服务器在日志中读取

脚本 [root@test scripts]# cat ss.sh #!/bin/bash . /etc/init.d/functions MYUSER=root MYPASS=c565f972 SOCKET="/data/3307/mysql.sock" MYCMD="/application/mysql/bin/mysql -u$MYUSER -p$MYPASS -S $SOCKET" STATUS=($($MYCMD -e "show slave s

今日上午,同事告知,MySQL主从数据库的数据不一致,猜测备库在同步过程中出现了问题,于是,登上备库,使用 mysql> show slave status\G查看,果然,备库在insert语句中因违反主键约束,导致备库停止了同步.现在的问题很明确,就是如何恢复主从库数据的一致性. 可选方案如下: 一.查看Master最新的Position,将其作为Slave复制的起点. 这种思路体现的是过去的不一致既往不咎,现在保持同步即可.看起来,这个思路和恢复主从库数据的一致性的初衷有所违背,但这种方法,

zabbix3.0.4监控mysql主从同步 1.监控mysql主从同步原理: 执行一个命令 mysql -u zabbix -pzabbix -e 'show slave status\G' 我们在输出的信息中选择 Slave_IO_Running: Yes Slave_SQL_Running: Yes 这两项来监控 当操作的数据出现异常的时候,Slave_SQL_Running就会变成No 当执行slave  stop的时候,两个都会变成No 2.添加一个具有权限的用户zabbix,只需要赋

在MySQL主从环境下,通常会根据Seconds_Behind_Master的值来判断slave的延迟状态,这么做在大部分情况下尚可接受,但其实是并不够准确的.对于Slave延迟状态的监控,应该考虑多种因素: 首先,我们先看下slave的状态:mysql> show slave status\G;*************************** 1. row ***************************slave_IO_State: Waiting for master to s

1 复制概述 Mysql内建的复制功能是构建大型,高性能应用程序的基础.将Mysql的数据分布到多个系统上去,这种分布的机制,是通过将Mysql的某一台主机的数据复制到其它主机(slaves)上,并重新执行一遍来实现的.复制过程中一个服务器充当主服务器,而一个或多个其它服务器充当从服务器.主服务器将更新写入二进制日志文件,并维护文件的一个索引以跟踪日志循环.这些日志可以记录发送到从服务器的更新.当一个从服务器连接主服务器时,它通知主服务器从服务器在日志中读取的最后一次成功更新的位置.从服务器接收

数据库版本:5.6.16 测试环境MySQL 主从,数据库被人重启,忘记开启start slave,导致主从失效,停了一天的数据没有追上. 查看从库的数据库状态:show   slave   status\G提示Client requested master to start replication from position > file size;  还有最后一次执行的日志点,26519749,二进制日志位置mysql-bin.000002 解决办法:在主库的日志目录下,执行:mysqlbi

MySQL主从故障修复 测试库:192.168.1.2 主192.168.1.3 从 192.168.1.4 主 4又是2的从库192.168.1.5 从 有人修改了192.168.1.2和192.168.1.3的数据库参数后,重启数据库.忘记了192.168.1.4又是192.168.1.2的从库,导致192.168.1.2和192.168.1.4的主从断掉.并且在192.168.1.2上创建了新库还原数据删除等操作,导致192.168.1.4提示错误. 模拟如下:通过从库查看主从状态:mys

温习<高性能MySQL>的复制篇. 1 复制概述 Mysql内建的复制功能是构建大型,高性能应用程序的基础.将Mysql的数据分布到多个系统上去,这种分布的机制,是通过将Mysql的某一台主机的数据复制到其它主机(slaves)上,并重新执行一遍来实现的.复制过程中一个服务器充当主服务器,而一个或多个其它服务器充当从服务器.主服务器将更新写入二进制日志文件,并维护文件的一个索引以跟踪日志循环.这些日志可以记录发送到从服务器的更新.当一个从服务器连接主服务器时,它通知主服务器从服务器在日志中读取

无论是哪一种数据库,数据的安全都是至关重要的,因此熟练掌握数据库的安全备份功能,是作为开发人员,特别是后端开发人员的一项必备技能.MySQL 数据库内建的复制功能,可以帮助我们对数据进行异地备份,读写分离,在较大程度上避免数据丢失.数据库服务器压力过大甚至宕机带来的损失. 使用MySQL 主从架构一年多了,想起当年学习这些东西的时候,苦于完整的中文资料比较少,当时英文又不太好,遇到不少问题.刚好最近也有一段时间没更新博客了,心血来潮,决定翻译一下 MySQL 官网的英文文档,官网文档讲解的非常详

Mysql主从配置+读写分离     MySQL从5.5版本开始,通过./configure进行编译配置方式已经被取消,取而代之的是cmake工具.因此,我们首先要在系统中源码编译安装cmake工具. 注:安装前须查看是否已经安装了如下依赖包,如果没有请安装. apt-get -y install gcc g++ libncurses5-dev ncurses-devel openssl   一．主库安装及配置 1.源码安装cmake # tar xf cmake-3.0.0.tar.gz #