数据库不会依赖表中缺点和失误的字段值进行赋

2019-07-14 作者:数据库   |   浏览(148)

下午巡检数据库,开采二个推迟从库的sql_thread中断了。

背景:MySQL5.6.40,库十分的小,row gtid复制遇到,但出于在此以前各样原因,备份还原在从库后,开启复制存在大气1062,1032荒谬,gtid卡在靠前岗位。做复制的时候从不别的从库,每时辰的备份也被运转停了。

背景

第一章:

Last_SQL_Errno: 1755
Last_SQL_Error: Cannot execute the current event group in the parallel mode. Encountered event Gtid, relay-log name ./oracle-relay-bin.000093, position 152912092 which prevents execution of this event group in parallel mode. Reason: The master event is logically timestamped incorrectly..

以前平昔没遭遇过这种场合,相对测量检验处境正式情状相比复杂,何况估算只怕是后边备份还原平昔没用过备份一致性参数导致,並且开掘错误也未曾手工业检查(这一个难题还在研究中,有际遇并知道原因的小同伙应接引导)。

在上一篇《数据库操作类SqlHelper》博文的末段,提到了一个施行应用中相遇的标题,正是数据库表中的自增加字段的赋值不受人为操纵。比如数据库有一个tb_Department表,DeptNO字段为自增加主键。

entity  实体

检查performance_schema下的replication_applier_status_by_worker表,除了GTID之外也不曾更实际的新闻:

为了现在幸免因为复苏比不上时导致的多少遗失,特别总括此次故障进程和豪门研商、分享。

图片 1

relationship  关系

"root@localhost:mysql3308.sock  [(none)]>select * from performance_schema.replication_applier_status_by_worker;
 -------------- ----------- ----------- --------------- ------------------------------------------------ ------------------- -------------------- ---------------------- 
| CHANNEL_NAME | WORKER_ID | THREAD_ID | SERVICE_STATE | LAST_SEEN_TRANSACTION                          | LAST_ERROR_NUMBER | LAST_ERROR_MESSAGE | LAST_ERROR_TIMESTAMP |
 -------------- ----------- ----------- --------------- ------------------------------------------------ ------------------- -------------------- ---------------------- 
|              |         1 |      NULL | OFF           | 0b961fcc-41c2-11e7-84fd-286ed488c7da:156369774 |                 0 |                    | 0000-00-00 00:00:00  |
|              |         2 |      NULL | OFF           |                                                |                 0 |                    | 0000-00-00 00:00:00  |
|              |         3 |      NULL | OFF           |                                                |                 0 |                    | 0000-00-00 00:00:00  |
|              |         4 |      NULL | OFF           |                                                |                 0 |                    | 0000-00-00 00:00:00  |
|              |         5 |      NULL | OFF           |                                                |                 0 |                    | 0000-00-00 00:00:00  |
|              |         6 |      NULL | OFF           |                                                |                 0 |                    | 0000-00-00 00:00:00  |
|              |         7 |      NULL | OFF           |                                                |                 0 |                    | 0000-00-00 00:00:00  |
|              |         8 |      NULL | OFF           |                                                |                 0 |                    | 0000-00-00 00:00:00  |
 -------------- ----------- ----------- --------------- ------------------------------------------------ ------------------- -------------------- ---------------------- 

简化时间轴如下图:

今昔布署一行数据

diagram  图表 

既然relay_log的岗位消息都有了,那就去日志里看看啊:

始发---->备份主库---->复苏从库---->复制error1032,1062---->删除从库再度苏醒---->复制error1032,1062---->reset master从库、主库---->计划删除从库---->误操作删主库----->复苏主库----->跳过大批量1062、1032不当---->找drop db地点复苏从库---->相比较中央数据---->手工补数据---->甘休

图片 2

model 模型

解析Binlog文件:

下边遵照本身的记得描述下立即的现象:

哟!DeptNO字段怎么正是22了吧,不应该是从4发端吧?

normal   规范的

mysqlbinlog -v --base64-output=decode-rows oracle-relay-bin.000093 >1.sql

一、第叁次备份主库、搭建从库

首先次搭建从库,从主库的备份未使用master-data=2 single-transaction(保证专门的学业备份时的一致性)参数迁移后,报多量1062和1032荒唐(家家有本难念的经,非常的少说了)

 

图片 3

缘由:那些表以前举行过非常多安排操作,数据库针对自拉长字段的历次插入都会活动 1,后来剔除了一部分行数据,然后重新插入的时候,数据库不会依赖表中缺点和失误的字段值实行赋值,而是在原先的基本功上接轨 1赋值。

formate  形式

找到152912092地方点周边的日记:

二、第贰次苏醒主库到从库

于是乎第四回重复导入。

一样报错。在导入从库前接纳reset master;将从库binlog清除。

鉴于操作职员不断解reset master含义及实施结果,又在主库做了reset master;

结果产生主库全体binlog日志被破除并且binlog position置为1;

此处贴以下官方认证,别没事干就在主库上用那条。

 

图片 4

再度导入发掘依然大量报1032,1062荒唐。

是因为可疑是因为备份时没动用--single-transaction参数,希图删除从库,加参数重新备份主库。

结果:在新插入的“哈哈系”数据行从前,其实数据库已经向表里插入过二十五遍了,只是DeptNO字段值大于3的行数据被删除了,今后要新插入行数据以来,就能够在21的根基上 1,也正是第二个表中出现的22了。

hotel  旅馆

图片 5

三、误删除主库

结果误操作删除主库(那些锅一片段原因要甩给mysql naivcat这一个工具,垂直排列库,稍微不留心就便于点错。如故提议我们听吴老师的用合法的workbench),删库照旧几个人核查,在操作系统上实施,删前没把握最棒备份一次。

删库这种操作严慎小心再小心,重要的事情说叁遍!

删库这种操作谨严小心再当心,首要的作业说三回!

删库这种操作稳重小心再严俊,首要的事体说一遍!

drop database;(在naivcat上右键删除库,但binlog日志中照旧会记录DROP DATABASE那条记下)

那时为了保障工作不停顿,立马在主库上经过此前的备份文件复苏了一套库,当然数据肯定遗失了,但足以推算遗失数据的岁月段(从备份完成伊始--->DROP DATABASE)。

PS.请不要问笔者干吗删库,为何删完又重振旗鼓了一套库,因为都不是自身干的。。。。。。

幸而的是误删除主库但平昔不删除从库,况兼从库的io_thread照旧处于yes状态(回想吴先生的教程,也正是说即便库被删除了但其实删库前的数额=备份数据 io_thread已下载的删除主库前的数量),由于sql_thread依然停到gtid靠前的岗位

 

图片 6

期望:

guest  客人

自己争辨了一晃数据库中这几个表ID为14816035的多寡确实是荒诞不经的。

四、跳过多量1032,1062不当

本条时候假使看下备份文件的gtid位置,并purge到该职位(以前备份丢了,随意找了三个备份的截图,驾驭万岁)。

##这里说爱他美下怎么一贯purge到备份的末尾地点,因为书库备份的数量中1032和1062不当太多,且主库已经删除不可能通过脚本相比跳过大量1032,1062谬误(吴老老师和朋友情提供),在能够保险是从主库逻辑备份过来的气象下(主从数据一致),大家挑选火速跳过大批量错误(偷懒加情形急),直接purge到备份最终的职分。

 

图片 7

##上海教室是随意截的二个备份文件最开端的地点,请忽略那些gtid的值,意思掌握就行。

set @@gtid_purged='fb1f83af-1915-11e8-811b-000c29c4d77d:1-500';

注:‘500’代表备份文件最后二个实行的业务的gtid。gtid_purged代表数据库已经在从库上海重机厂放过1-500这段工作。

  1. 在插入新数据的时候,针对自增进字段能够人为操纵;
  2. 实际上运用中,其实用户并不知道数据表中自拉长字段缺点和失误的是哪些值,程序须要活动提供缺点和失误依然缺省值。

promation 提升 推广

除此以外除了那条日志,其余日志的last_committed和sequence_number都为0,last_committed表示事情提交的时候,上次事务提交的号码。last_committed和sequence_number代表的正是所谓的LOGICAL_CLOCK。

五、找到主库DROP DATABASE的GTID地点

purge到该地方然后再明确drop database的岗位上(思路:假若不鲜明dropdatabase的职责就start slave 那么从库会应用主库的binlog也就能够进行主库drop database的操作,为了幸免从库重放主库drop database的操作,大家要想方设法让gtid在从库停到drop database前三个gtid的岗位)

注:可以透过差比相当少删库时间恐怕从从库的show slave statusG上收看主库的binlog地方从后往前找DROP DATABASE的义务,假使删库后做了reset master那就只能从从库的relay-bin-log上找了(切记主库没事别reset master);

mysqlbinlog    -vvv  --base64-output=decode-rows  relay-bin.000017

 

图片 8

设计

state  状态

猜猜即使手动把那条数据插入延迟从库,而且选用流入二个空事务跳过这些GTID的措施重启sql_thread,相信那些漏洞非常多也能被消除。

六、运营从库SQL_THREAD

在从库上进行start slave sql_thread until的下令,这里必要表明,因为主库已经复苏,业务跑起来了,那时候开启io_thread未有啥意思,所以只用让从库的sql_thread线程重放DROP DATABASE此前的职业就行。

root@localhost[{none}]>start slave sql_thread until sql_before_gtid='fb1f83af-1915-11e8-811b-000c29c4d77d:2343';

开发银行slave,并且让从库gtid停在主库drop database操作以前四个gtid就能够,再还原到主库就能够及时投入使用,还不会变成数据错失。

 

图片 9

管教从库executed_gtid_set到了我们before的前四个值就能够备份了,然后dump那份数据恢复生机主库,当然假如从库品质不错的话能够虚构应用端改变连接,那样速度越来越快一些。

但正如麻烦的便是,要确认保证生产的实时性,删库后旋即在主库上还原了后边用来平复从库的备份文件,那就必将会导致中间数据遗失。

1.在插入新数据的时候,针对自拉长字段可以人为调整

type  类型

但既然带了LOGICAL_CLOCK的事情就能出错,跳过业务的法子很难保障现在不会出错。

七、数据比较还原

那儿不得不利用用事先用于搭建从库的备份再恢复生机四个库,再用pt-table-checksum相比较主库和卷土而来库,从库和余烬复起库不均等的数目,用pt-table-sync生成对应语句。然后手工业把数量补进系统中。

对比1:主库:备份数据苏醒的库---->指标:找到主库在删库之后选择又写入了怎么样数据。

对比2:从库:备份数据恢复生机的库---->指标:找到备份数据之后,删库以前运用在主Curry写了什么样数据。

因为量不是非常大,手工业相比一下就行,当然数据苏醒的坑也是有众多,但是基本上都被研究开发填了。

数据库中针对自增加字段在插入时,不得以钦命显式值的。

 

只顾到那条日志的last_committed是多少个老大大的值,且错误消息中有关联The master event is logically timestamped incorrectly。小编匪夷所思是否互相配置的主题材料。

总结:

首轮境遇删库境况照旧有一点蒙,万幸主库用的是GTID找binlog日志中的地方相对轻便一点。这一次苏醒最幸运的正是万幸从库卡在靠前的职位,要不然正是有了从库,数据也会被删了,苏醒起来相对更麻烦些。

对于gtid的复原,课上吴炳锡先生都讲过,不过一上手依旧慢了几拍,依旧要由此实战多演练加深手感幸免在真实意况下懵逼。

末段非常谢谢:知数堂叶金荣先生和吴炳锡先生在故障产生时给予的提携和支撑。

转载请表明出处

insert into tb_Department(DeptNO,DeptName) values(4,N'嘿嘿系')

第二章:

从库配置:

如此那般插入数据会报错的,提醒您“当Identity_Insert设置为off时,无法为表’tb_Department’中的标记列插入显式值”。很肯定,第叁个期待的消除方案就是将Identity_Insert设置on,然后实践显式值插入,最终关闭标志列插入按钮。

networking 网络

"root@localhost:mysql3308.sock  [(none)]>show variables like '%para%';
 ------------------------ --------------- 
| Variable_name          | Value         |
 ------------------------ --------------- 
| slave_parallel_type    | LOGICAL_CLOCK |
| slave_parallel_workers | 8             |
 ------------------------ --------------- 
set identity_insert tb_Department on
insert into tb_Department(DeptNO,DeptName) values(4,N'嘿嘿系')
set identity_insert tb_Department off

option 选择的

 再检查主库配置:

实践看看能否插入,哇哦,成功了,棒棒哒。

port   端口号

(root@localhost:mysql.sock) [(none)]>show variables like '%para%';
 ------------------------ ------- 
| Variable_name          | Value |
 ------------------------ ------- 
| slave_parallel_workers | 0     |
 ------------------------ ------- 

图片 10

firewall  防火墙

 开采主库根本就从未slave_parallel_type那项安顿。想起来主库是mysql5.6了。

2.实际上采取中,用户并不知道数据表中自增进字段未利用有何样值,程序供给活动提供缺点和失误依旧缺省值

engine   引擎

(root@localhost:mysql.sock) [(none)]>select version();
 ------------ 
| version()  |
 ------------ 
| 5.6.35-log |
 ------------ 

自增加字段的值分为缺点和失误值和缺省值(那几个术语是自己要好定的,为了便于描述)

standard  标准

 那么难题基本上就明白了,主库5.6只帮助基于DATABASE的并行复制,而5.7的从库配置成LOGICAL_CLOCK导致了老大。

缺点和失误值:举个例子数据表中自增进字段的值为(1,2,3,5),则缺点和失误值为4。要想让程序自动物检疫索到缺点和失误值,必要对数据表进行完善扫描,逐行推断自拉长字段的值是还是不是三番五次递增,只要检索到不一连的值就将对应种类的值重返,并呈现在窗体上,不必要用户自身输入。

character  字符

接头了难题所在,那就好消除了,把从库的slave_parallel_type改为DATABASE,再起sql_thread难点应当就缓慢解决了:

缺省值:比方数据表中自拉长字段的值为(1,2,3,4),则缺省值为5。若是原先有10行数据,然后将超越4的行删除后,自增进字段自身依旧一连递增的,只需求找到缺省值,重回给用户。

collation  校对

本文由小鱼儿玄机30码发布于数据库,转载请注明出处:数据库不会依赖表中缺点和失误的字段值进行赋

关键词: 小鱼儿玄机30码

  • 上一篇:没有了
  • 下一篇:没有了
数据库推荐