-
Notifications
You must be signed in to change notification settings - Fork 12
/
Copy path31讲误删数据后除了跑路，还能怎么办.html
506 lines (423 loc) · 65 KB
/
31讲误删数据后除了跑路，还能怎么办.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
<html>
<head>
<meta charset="utf-8">
<meta http-equiv="X-UA-Compatible" content="IE=edge,chrome=1">
<meta name="viewport"
content="width=device-width,initial-scale=1,maximum-scale=1,minimum-scale=1,user-scalable=no,viewport-fit=cover">
<meta name="format-detection" content="telephone=no">
<style type="text/css">
#watermark {
position: relative;
overflow: hidden;
}
#watermark .x {
position: absolute;
top: 800;
left: 400;
color: #3300ff;
font-size: 50px;
pointer-events: none;
opacity:0.3;
filter:Alpha(opacity=50);
-webkit-transform: rotate(45deg);
-moz-transform: rotate(45deg);
}
</style>
<style type="text/css">
html{color:#333;-webkit-text-size-adjust:100%;-ms-text-size-adjust:100%;text-rendering:optimizelegibility;font-family:Helvetica Neue,PingFang SC,Verdana,Microsoft Yahei,Hiragino Sans GB,Microsoft Sans Serif,WenQuanYi Micro Hei,sans-serif}html.borderbox *,html.borderbox :after,html.borderbox :before{box-sizing:border-box}article,aside,blockquote,body,button,code,dd,details,dl,dt,fieldset,figcaption,figure,footer,form,h1,h2,h3,h4,h5,h6,header,hr,input,legend,li,menu,nav,ol,p,pre,section,td,textarea,th,ul{margin:0;padding:0}article,aside,details,figcaption,figure,footer,header,menu,nav,section{display:block}audio,canvas,video{display:inline-block}body,button,input,select,textarea{font:300 1em/1.8 PingFang SC,Lantinghei SC,Microsoft Yahei,Hiragino Sans GB,Microsoft Sans Serif,WenQuanYi Micro Hei,Helvetica,sans-serif}button::-moz-focus-inner,input::-moz-focus-inner{padding:0;border:0}table{border-collapse:collapse;border-spacing:0}fieldset,img{border:0}blockquote{position:relative;color:#999;font-weight:400;border-left:1px solid #1abc9c;padding-left:1em;margin:1em 3em 1em 2em}@media only screen and (max-width:640px){blockquote{margin:1em 0}}abbr,acronym{border-bottom:1px dotted;font-variant:normal}abbr{cursor:help}del{text-decoration:line-through}address,caption,cite,code,dfn,em,th,var{font-style:normal;font-weight:400}ol,ul{list-style:none}caption,th{text-align:left}q:after,q:before{content:""}sub,sup{font-size:75%;line-height:0;position:relative}:root sub,:root sup{vertical-align:baseline}sup{top:-.5em}sub{bottom:-.25em}a{color:#1abc9c}a:hover{text-decoration:underline}.typo a{border-bottom:1px solid #1abc9c}.typo a:hover{border-bottom-color:#555;color:#555}.typo a:hover,a,ins{text-decoration:none}.typo-u,u{text-decoration:underline}mark{background:#fffdd1;border-bottom:1px solid #ffedce;padding:2px;margin:0 5px}code,pre,pre tt{font-family:Courier,Courier New,monospace}pre{background:hsla(0,0%,97%,.7);border:1px solid #ddd;padding:1em 1.5em;display:block;-webkit-overflow-scrolling:touch}hr{border:none;border-bottom:1px solid #cfcfcf;margin-bottom:.8em;height:10px}.typo-small,figcaption,small{font-size:.9em;color:#888}b,strong{font-weight:700;color:#000}[draggable]{cursor:move}.clearfix:after,.clearfix:before{content:"";display:table}.clearfix:after{clear:both}.clearfix{zoom:1}.textwrap,.textwrap td,.textwrap th{word-wrap:break-word;word-break:break-all}.textwrap-table{table-layout:fixed}.serif{font-family:Palatino,Optima,Georgia,serif}.typo-dl,.typo-form,.typo-hr,.typo-ol,.typo-p,.typo-pre,.typo-table,.typo-ul,.typo dl,.typo form,.typo hr,.typo ol,.typo p,.typo pre,.typo table,.typo ul,blockquote{margin-bottom:1rem}h1,h2,h3,h4,h5,h6{font-family:PingFang SC,Helvetica Neue,Verdana,Microsoft Yahei,Hiragino Sans GB,Microsoft Sans Serif,WenQuanYi Micro Hei,sans-serif;color:#000;line-height:1.35}.typo-h1,.typo-h2,.typo-h3,.typo-h4,.typo-h5,.typo-h6,.typo h1,.typo h2,.typo h3,.typo h4,.typo h5,.typo h6{margin-top:1.2em;margin-bottom:.6em;line-height:1.35}.typo-h1,.typo h1{font-size:2em}.typo-h2,.typo h2{font-size:1.8em}.typo-h3,.typo h3{font-size:1.6em}.typo-h4,.typo h4{font-size:1.4em}.typo-h5,.typo-h6,.typo h5,.typo h6{font-size:1.2em}.typo-ul,.typo ul{margin-left:1.3em;list-style:disc}.typo-ol,.typo ol{list-style:decimal;margin-left:1.9em}.typo-ol ol,.typo-ol ul,.typo-ul ol,.typo-ul ul,.typo li ol,.typo li ul{margin-bottom:.8em;margin-left:2em}.typo-ol ul,.typo-ul ul,.typo li ul{list-style:circle}.typo-table td,.typo-table th,.typo table caption,.typo table td,.typo table th{border:1px solid #ddd;padding:.5em 1em;color:#666}.typo-table th,.typo table th{background:#fbfbfb}.typo-table thead th,.typo table thead th{background:hsla(0,0%,95%,.7)}.typo table caption{border-bottom:none}.typo-input,.typo-textarea{-webkit-appearance:none;border-radius:0}.typo-em,.typo em,caption,legend{color:#000;font-weight:inherit}.typo-em{position:relative}.typo-em:after{position:absolute;top:.65em;left:0;width:100%;overflow:hidden;white-space:nowrap;content:"\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB\30FB"}.typo img{max-width:100%}.common-content{font-weight:400;color:#353535;line-height:1.75rem;white-space:normal;word-break:normal;font-size:1rem}.common-content img{display:block;max-width:100%;background-color:#eee}.common-content audio,.common-content video{width:100%;background-color:#eee}.common-content center,.common-content font{margin-top:1rem;display:inline-block}.common-content center{width:100%}.common-content pre{margin-top:1rem;padding-left:0;padding-right:0;position:relative;overflow:hidden}.common-content pre code{font-size:.8rem;font-family:Consolas,Liberation Mono,Menlo,monospace,Courier;display:block;width:100%;box-sizing:border-box;padding-left:1rem;padding-right:1rem;overflow-x:auto}.common-content hr{border:none;margin-top:1.5rem;margin-bottom:1.5rem;border-top:1px solid #f5f5f5;height:1px;background:none}.common-content b,.common-content h1,.common-content h2,.common-content h3,.common-content h4,.common-content h5,.common-content strong{font-weight:700}.common-content h1,.common-content h2{font-size:1.125rem;margin-bottom:.45rem}.common-content h3,.common-content h4,.common-content h5{font-size:1rem;margin-bottom:.45rem}.common-content p{font-weight:400;color:#353535;margin-top:.15rem}.common-content .orange{color:#ff5a05}.common-content .reference{font-size:1rem;color:#888}.custom-rich-content h1{margin-top:0;font-weight:400;font-size:15.25px;border-bottom:1px solid #eee;line-height:2.8}.custom-rich-content li,.custom-rich-content p{font-size:14px;color:#888;line-height:1.6}table.hljs-ln{margin-bottom:0;border-spacing:0;border-collapse:collapse}table.hljs-ln,table.hljs-ln tbody,table.hljs-ln td,table.hljs-ln tr{box-sizing:border-box}table.hljs-ln td{padding:0;border:0}table.hljs-ln td.hljs-ln-numbers{min-width:15px;color:rgba(27,31,35,.3);text-align:right;white-space:nowrap;cursor:pointer;user-select:none}table.hljs-ln td.hljs-ln-code,table.hljs-ln td.hljs-ln-numbers{font-family:SFMono-Regular,Consolas,Liberation Mono,Menlo,Courier,monospace;font-size:12px;line-height:20px;vertical-align:top}table.hljs-ln td.hljs-ln-code{position:relative;padding-right:10px;padding-left:10px;overflow:visible;color:#24292e;word-wrap:normal;white-space:pre}video::-webkit-media-controls{overflow:hidden!important}video::-webkit-media-controls-enclosure{width:calc(100% + 32px);margin-left:auto}.button-cancel{color:#888;border:1px solid #888;border-radius:3px;margin-right:12px}.button-cancel,.button-primary{-ms-flex-positive:1;flex-grow:1;height:35px;display:inline-block;font-size:15px;text-align:center;line-height:36px}.button-primary{color:#fff;background-color:#ff5a05;border-radius:3px}@font-face{font-family:iconfont;src:url(//at.alicdn.com/t/font_372689_bwwwtosxtzp.eot);src:url(//at.alicdn.com/t/font_372689_bwwwtosxtzp.eot#iefix) format("embedded-opentype"),url(//at.alicdn.com/t/font_372689_bwwwtosxtzp.woff) format("woff"),url(//at.alicdn.com/t/font_372689_bwwwtosxtzp.ttf) format("truetype"),url(//at.alicdn.com/t/font_372689_bwwwtosxtzp.svg#iconfont) format("svg")}@font-face{font-family:player-font;src:url(//at.alicdn.com/t/font_509397_1cyjv4o90qiod2t9.eot);src:url(//at.alicdn.com/t/font_509397_1cyjv4o90qiod2t9.eot#iefix) format("embedded-opentype"),url(//at.alicdn.com/t/font_509397_1cyjv4o90qiod2t9.woff) format("woff"),url(//at.alicdn.com/t/font_509397_1cyjv4o90qiod2t9.ttf) format("truetype"),url(//at.alicdn.com/t/font_509397_1cyjv4o90qiod2t9.svg#player-font) format("svg")}.iconfont{font-family:iconfont!important;font-size:16px;font-style:normal;-webkit-font-smoothing:antialiased;-webkit-text-stroke-width:.2px;-moz-osx-font-smoothing:grayscale}html{background:#fff;min-height:100%;-webkit-tap-highlight-color:rgba(0,0,0,0)}body{width:100%}body.fixed{overflow:hidden;position:fixed;width:100vw;height:100vh}i{font-style:normal}a{word-wrap:break-word;-webkit-tap-highlight-color:rgba(0,0,0,0)}a:hover{text-decoration:none}.fade-enter-active,.fade-leave-active{transition:opacity .3s}.fade-enter,.fade-leave-to{opacity:0}.MathJax,.MathJax_CHTML,.MathJax_MathContainer,.MathJax_MathML,.MathJax_PHTML,.MathJax_PlainSource,.MathJax_SVG{outline:0}.ios-app-switch .js-audit{display:none}._loading_wrap_{position:fixed;width:100vw;height:100vh;top:50%;left:50%;transform:translate(-50%,-50%);z-index:999}._loading_div_class_,._loading_wrap_{display:-ms-flexbox;display:flex;-ms-flex-pack:center;justify-content:center;-ms-flex-align:center;align-items:center}._loading_div_class_{word-wrap:break-word;padding:.5rem .75rem;text-align:center;z-index:9999;font-size:.6rem;max-width:60%;color:#fff;border-radius:.25rem;-ms-flex-direction:column;flex-direction:column}._loading_div_class_ .message{color:#353535;font-size:16px;line-height:3}.spinner{animation:circle-rotator 1.4s linear infinite}.spinner *{line-height:0;box-sizing:border-box}@keyframes circle-rotator{0%{transform:rotate(0deg)}to{transform:rotate(270deg)}}.path{stroke-dasharray:187;stroke-dashoffset:0;transform-origin:center;animation:circle-dash 1.4s ease-in-out infinite,circle-colors 5.6s ease-in-out infinite}@keyframes circle-colors{0%{stroke:#ff5a05}to{stroke:#ff5a05}}@keyframes circle-dash{0%{stroke-dashoffset:187}50%{stroke-dashoffset:46.75;transform:rotate(135deg)}to{stroke-dashoffset:187;transform:rotate(450deg)}}.confirm-box-wrapper,.confirm-box-wrapper .mask{position:absolute;top:0;left:0;right:0;bottom:0}.confirm-box-wrapper .mask{background:rgba(0,0,0,.6)}.confirm-box-wrapper .confirm-box{position:fixed;top:50%;left:50%;width:267px;background:#fff;transform:translate(-50%,-50%);border-radius:7px}.confirm-box-wrapper .confirm-box .head{margin:0 18px;font-size:18px;text-align:center;line-height:65px;border-bottom:1px solid #d9d9d9}.confirm-box-wrapper .confirm-box .body{padding:18px;padding-bottom:0;color:#353535;font-size:12.5px;max-height:150px;overflow:auto}.confirm-box-wrapper .confirm-box .foot{display:-ms-flexbox;display:flex;-ms-flex-direction:row;flex-direction:row;padding:18px}.confirm-box-wrapper .confirm-box .foot .button-cancel{border:1px solid #d9d9d9}.hljs{display:block;overflow-x:auto;padding:.5em;color:#333;background:#f8f8f8}.hljs-comment,.hljs-quote{color:#998;font-style:italic}.hljs-keyword,.hljs-selector-tag,.hljs-subst{color:#333;font-weight:700}.hljs-literal,.hljs-number,.hljs-tag .hljs-attr,.hljs-template-variable,.hljs-variable{color:teal}.hljs-doctag,.hljs-string{color:#d14}.hljs-section,.hljs-selector-id,.hljs-title{color:#900;font-weight:700}.hljs-subst{font-weight:400}.hljs-class .hljs-title,.hljs-type{color:#458;font-weight:700}.hljs-attribute,.hljs-name,.hljs-tag{color:navy;font-weight:400}.hljs-link,.hljs-regexp{color:#009926}.hljs-bullet,.hljs-symbol{color:#990073}.hljs-built_in,.hljs-builtin-name{color:#0086b3}.hljs-meta{color:#999;font-weight:700}.hljs-deletion{background:#fdd}.hljs-addition{background:#dfd}.hljs-emphasis{font-style:italic}.hljs-strong{font-weight:700}
</style>
<style type="text/css">
.button-cancel[data-v-87ffcada]{color:#888;border:1px solid #888;border-radius:3px;margin-right:12px}.button-cancel[data-v-87ffcada],.button-primary[data-v-87ffcada]{-webkit-box-flex:1;-ms-flex-positive:1;flex-grow:1;height:35px;display:inline-block;font-size:15px;text-align:center;line-height:36px}.button-primary[data-v-87ffcada]{color:#fff;background-color:#ff5a05;border-radius:3px}.pd[data-v-87ffcada]{padding-left:1.375rem;padding-right:1.375rem}.article[data-v-87ffcada]{max-width:70rem;margin:0 auto}.article .article-unavailable[data-v-87ffcada]{color:#fa8919;font-size:15px;font-weight:600;line-height:24px;border-radius:5px;padding:12px;background-color:#f6f7fb;margin-top:20px}.article .article-unavailable .iconfont[data-v-87ffcada]{font-size:12px}.article .main[data-v-87ffcada]{padding:1.25rem 0;margin-bottom:52px}.article-title[data-v-87ffcada]{color:#353535;font-weight:400;line-height:1.65rem;font-size:1.34375rem}.article-info[data-v-87ffcada]{color:#888;font-size:.9375rem;margin-top:1.0625rem}.article-content[data-v-87ffcada]{margin-top:1.0625rem}.article-content.android video[data-v-87ffcada]::-webkit-media-controls-fullscreen-button{display:none}.copyright[data-v-87ffcada]{color:#b2b2b2;padding-bottom:20px;margin-top:20px;font-size:13px}.audio-player[data-v-87ffcada]{width:100%;margin:20px 0}.to-comment[data-v-87ffcada]{overflow:hidden;padding-top:10px;margin-bottom:-30px}.to-comment a.button-primary[data-v-87ffcada]{float:right;height:20px;font-size:12px;line-height:20px;padding:4px 8px;cursor:pointer}.article-comments[data-v-87ffcada]{margin-top:2rem}.article-comments h2[data-v-87ffcada]{text-align:center;color:#888;position:relative;z-index:1;margin-bottom:1rem}.article-comments h2[data-v-87ffcada]:before{border-top:1px dotted #888;content:"";position:absolute;top:56%;left:0;width:100%;z-index:-1}.article-comments h2 span[data-v-87ffcada]{font-size:15.25px;font-weight:400;padding:0 1rem;background:#fff;display:inline-block}.article-sub-bottom[data-v-87ffcada]{z-index:10;cursor:pointer}.switch-btns[data-v-87ffcada]{height:76px;cursor:pointer;padding-top:24px;padding-bottom:24px;border-bottom:10px solid #f6f7fb;position:relative}.switch-btns[data-v-87ffcada]:before{content:" ";height:1px;background:#e8e8e8;position:absolute;top:0;left:0;-webkit-box-sizing:border-box;box-sizing:border-box;left:1.375rem;right:1.375rem}.switch-btns .btn[data-v-87ffcada]{height:38px;display:-webkit-box;display:-ms-flexbox;display:flex;-webkit-box-align:center;-ms-flex-align:center;align-items:center}.switch-btns .btn .tag[data-v-87ffcada]{-webkit-box-flex:0;-ms-flex:0 0 62px;flex:0 0 62px;text-align:center;color:#888;font-size:14px;border-radius:10px;height:22px;line-height:22px;background:#f6f7fb;font-weight:400}.switch-btns .btn .txt[data-v-87ffcada]{margin-left:10px;-webkit-box-flex:1;-ms-flex:1 1 auto;flex:1 1 auto;color:#888;font-size:15px;height:22px;line-height:22px;overflow:hidden;text-overflow:ellipsis;white-space:nowrap;font-weight:400}@media (max-width:769px){.article .breadcrumb[data-v-87ffcada]{padding-top:10px;padding-bottom:10px}}
</style>
<style type="text/css">
.comment-item{list-style-position:inside;width:100%;display:-webkit-box;display:-ms-flexbox;display:flex;-webkit-box-orient:horizontal;-webkit-box-direction:normal;-ms-flex-direction:row;flex-direction:row;margin-bottom:1rem}.comment-item a{border-bottom:none}.comment-item .avatar{width:2.625rem;height:2.625rem;-ms-flex-negative:0;flex-shrink:0;border-radius:50%}.comment-item .info{margin-left:.5rem;-webkit-box-flex:1;-ms-flex-positive:1;flex-grow:1}.comment-item .info .hd{width:100%;display:-webkit-box;display:-ms-flexbox;display:flex;-webkit-box-orient:horizontal;-webkit-box-direction:normal;-ms-flex-direction:row;flex-direction:row;-webkit-box-pack:justify;-ms-flex-pack:justify;justify-content:space-between;-webkit-box-align:center;-ms-flex-align:center;align-items:center}.comment-item .info .hd .username{color:#888;font-size:15.25px;font-weight:400;line-height:1.2}.comment-item .info .hd .control{display:-webkit-box;display:-ms-flexbox;display:flex;-webkit-box-orient:horizontal;-webkit-box-direction:normal;-ms-flex-direction:row;flex-direction:row;-webkit-box-align:center;-ms-flex-align:center;align-items:center}.comment-item .info .hd .control .btn-share{color:#888;font-size:.75rem;margin-right:1rem}.comment-item .info .hd .control .btn-praise{display:-webkit-box;display:-ms-flexbox;display:flex;-webkit-box-orient:horizontal;-webkit-box-direction:normal;-ms-flex-direction:row;flex-direction:row;-webkit-box-align:center;-ms-flex-align:center;align-items:center;font-size:15.25px;text-decoration:none}.comment-item .info .hd .control .btn-praise i{color:#888;display:inline-block;font-size:.75rem;margin-right:.3rem;margin-top:-.01rem}.comment-item .info .hd .control .btn-praise i.on,.comment-item .info .hd .control .btn-praise span{color:#ff5a05}.comment-item .info .bd{color:#353535;font-size:15.25px;font-weight:400;white-space:normal;word-break:break-all;line-height:1.6}.comment-item .info .time{color:#888;font-size:9px;line-height:1}.comment-item .info .reply .reply-hd{font-size:15.25px}.comment-item .info .reply .reply-hd span{margin-left:-12px;color:#888;font-weight:400}.comment-item .info .reply .reply-hd i{color:#ff5a05;font-size:15.25px}.comment-item .info .reply .reply-content{color:#353535;font-size:15.25px;font-weight:400;white-space:normal;word-break:break-all}.comment-item .info .reply .reply-time{color:#888;font-size:9px}
</style>
</head>
<body>
<div id="app">
<div data-v-87ffcada="" class="article" id="watermark">
<div data-v-87ffcada="" class="main main-app">
<h1 data-v-87ffcada="" class="article-title pd">
31讲误删数据后除了跑路，还能怎么办
</h1>
<div data-v-87ffcada="" class="article-content typo common-content pd"><img data-v-87ffcada=""
src="https://static001.geekbang.org/resource/image/c1/19/c197f72fb1639cde5ac57ffe5a847419.jpg">
<div data-v-87ffcada="" id="article-content" class="">
<div class="text">
<p>今天我要和你讨论的是一个沉重的话题：误删数据。</p><p>在前面几篇文章中，我们介绍了MySQL的高可用架构。当然，传统的高可用架构是不能预防误删数据的，因为主库的一个drop table命令，会通过binlog传给所有从库和级联从库，进而导致整个集群的实例都会执行这个命令。</p><p>虽然我们之前遇到的大多数的数据被删，都是运维同学或者DBA背锅的。但实际上，只要有数据操作权限的同学，都有可能踩到误删数据这条线。</p><p>今天我们就来聊聊误删数据前后，我们可以做些什么，减少误删数据的风险，和由误删数据带来的损失。</p><p>为了找到解决误删数据的更高效的方法，我们需要先对和MySQL相关的误删数据，做下分类：</p><ol>
<li>
<p>使用delete语句误删数据行；</p>
</li>
<li>
<p>使用drop table或者truncate table语句误删数据表；</p>
</li>
<li>
<p>使用drop database语句误删数据库；</p>
</li>
<li>
<p>使用rm命令误删整个MySQL实例。</p>
</li>
</ol><h1>误删行</h1><p>在<a href="https://time.geekbang.org/column/article/76446">第24篇文章</a>中，我们提到如果是使用delete语句误删了数据行，可以用Flashback工具通过闪回把数据恢复回来。</p><p>Flashback恢复数据的原理，是修改binlog的内容，拿回原库重放。而能够使用这个方案的前提是，需要确保binlog_format=row 和 binlog_row_image=FULL。</p><!-- [[[read_end]]] --><p>具体恢复数据时，对单个事务做如下处理：</p><ol>
<li>
<p>对于insert语句，对应的binlog event类型是Write_rows event，把它改成Delete_rows event即可；</p>
</li>
<li>
<p>同理，对于delete语句，也是将Delete_rows event改为Write_rows event；</p>
</li>
<li>
<p>而如果是Update_rows的话，binlog里面记录了数据行修改前和修改后的值，对调这两行的位置即可。</p>
</li>
</ol><p>如果误操作不是一个，而是多个，会怎么样呢？比如下面三个事务：</p><pre><code>(A)delete ...
(B)insert ...
(C)update ...
</code></pre><p>现在要把数据库恢复回这三个事务操作之前的状态，用Flashback工具解析binlog后，写回主库的命令是：</p><pre><code>(reverse C)update ...
(reverse B)delete ...
(reverse A)insert ...
</code></pre><p>也就是说，如果误删数据涉及到了多个事务的话，需要将事务的顺序调过来再执行。</p><p><strong>需要说明的是，我不建议你直接在主库上执行这些操作。</strong></p><p>恢复数据比较安全的做法，是恢复出一个备份，或者找一个从库作为临时库，在这个临时库上执行这些操作，然后再将确认过的临时库的数据，恢复回主库。</p><p>为什么要这么做呢？</p><p>这是因为，一个在执行线上逻辑的主库，数据状态的变更往往是有关联的。可能由于发现数据问题的时间晚了一点儿，就导致已经在之前误操作的基础上，业务代码逻辑又继续修改了其他数据。所以，如果这时候单独恢复这几行数据，而又未经确认的话，就可能会出现对数据的二次破坏。</p><p>当然，<strong>我们不止要说误删数据的事后处理办法，更重要是要做到事前预防</strong>。我有以下两个建议：</p><ol>
<li>
<p>把sql_safe_updates参数设置为on。这样一来，如果我们忘记在delete或者update语句中写where条件，或者where条件里面没有包含索引字段的话，这条语句的执行就会报错。</p>
</li>
<li>
<p>代码上线前，必须经过SQL审计。</p>
</li>
</ol><p>你可能会说，设置了sql_safe_updates=on，如果我真的要把一个小表的数据全部删掉，应该怎么办呢？</p><p>如果你确定这个删除操作没问题的话，可以在delete语句中加上where条件，比如where id>=0。</p><p>但是，delete全表是很慢的，需要生成回滚日志、写redo、写binlog。所以，从性能角度考虑，你应该优先考虑使用truncate table或者drop table命令。</p><p>使用delete命令删除的数据，你还可以用Flashback来恢复。而使用truncate /drop table和drop database命令删除的数据，就没办法通过Flashback来恢复了。为什么呢？</p><p>这是因为，即使我们配置了binlog_format=row，执行这三个命令时，记录的binlog还是statement格式。binlog里面就只有一个truncate/drop 语句，这些信息是恢复不出数据的。</p><p>那么，如果我们真的是使用这几条命令误删数据了，又该怎么办呢？</p><h1>误删库/表</h1><p>这种情况下，要想恢复数据，就需要使用全量备份，加增量日志的方式了。这个方案要求线上有定期的全量备份，并且实时备份binlog。</p><p>在这两个条件都具备的情况下，假如有人中午12点误删了一个库，恢复数据的流程如下：</p><ol>
<li>
<p>取最近一次全量备份，假设这个库是一天一备，上次备份是当天0点；</p>
</li>
<li>
<p>用备份恢复出一个临时库；</p>
</li>
<li>
<p>从日志备份里面，取出凌晨0点之后的日志；</p>
</li>
<li>
<p>把这些日志，除了误删除数据的语句外，全部应用到临时库。</p>
</li>
</ol><p>这个流程的示意图如下所示：</p><p><img src="https://static001.geekbang.org/resource/image/2f/db/2fafd0b75286e0163f432f85428ff8db.png" alt=""></p><center><span class="reference">图1 数据恢复流程-mysqlbinlog方法</span></center><p>关于这个过程，我需要和你说明如下几点：</p><ol>
<li>
<p>为了加速数据恢复，如果这个临时库上有多个数据库，你可以在使用mysqlbinlog命令时，加上一个–database参数，用来指定误删表所在的库。这样，就避免了在恢复数据时还要应用其他库日志的情况。</p>
</li>
<li>
<p>在应用日志的时候，需要跳过12点误操作的那个语句的binlog：</p>
<ul>
<li>如果原实例没有使用GTID模式，只能在应用到包含12点的binlog文件的时候，先用–stop-position参数执行到误操作之前的日志，然后再用–start-position从误操作之后的日志继续执行；</li>
<li>如果实例使用了GTID模式，就方便多了。假设误操作命令的GTID是gtid1，那么只需要执行set gtid_next=gtid1;begin;commit; 先把这个GTID加到临时实例的GTID集合，之后按顺序执行binlog的时候，就会自动跳过误操作的语句。</li>
</ul>
</li>
</ol><p>不过，即使这样，使用mysqlbinlog方法恢复数据还是不够快，主要原因有两个：</p><ol>
<li>
<p>如果是误删表，最好就是只恢复出这张表，也就是只重放这张表的操作，但是mysqlbinlog工具并不能指定只解析一个表的日志；</p>
</li>
<li>
<p>用mysqlbinlog解析出日志应用，应用日志的过程就只能是单线程。我们在<a href="https://time.geekbang.org/column/article/77083">第26篇文章</a>中介绍的那些并行复制的方法，在这里都用不上。</p>
</li>
</ol><p><strong>一种加速的方法是，</strong>在用备份恢复出临时实例之后，将这个临时实例设置成线上备库的从库，这样：</p><ol>
<li>
<p>在start slave之前，先通过执行<br>
change replication filter replicate_do_table = (tbl_name) 命令，就可以让临时库只同步误操作的表；</p>
</li>
<li>
<p>这样做也可以用上并行复制技术，来加速整个数据恢复过程。</p>
</li>
</ol><p>这个过程的示意图如下所示。</p><p><img src="https://static001.geekbang.org/resource/image/65/f1/65bb04929b8235fb677c7a78b5bd67f1.png" alt=""></p><center><span class="reference">图2 数据恢复流程-master-slave方法</span></center><p>可以看到，图中binlog备份系统到线上备库有一条虚线，是指如果由于时间太久，备库上已经删除了临时实例需要的binlog的话，我们可以从binlog备份系统中找到需要的binlog，再放回备库中。</p><p>假设，我们发现当前临时实例需要的binlog是从master.000005开始的，但是在备库上执行show binlogs 显示的最小的binlog文件是master.000007，意味着少了两个binlog文件。这时，我们就需要去binlog备份系统中找到这两个文件。</p><p>把之前删掉的binlog放回备库的操作步骤，是这样的：</p><ol>
<li>
<p>从备份系统下载master.000005和master.000006这两个文件，放到备库的日志目录下；</p>
</li>
<li>
<p>打开日志目录下的master.index文件，在文件开头加入两行，内容分别是 “./master.000005”和“./master.000006”;</p>
</li>
<li>
<p>重启备库，目的是要让备库重新识别这两个日志文件；</p>
</li>
<li>
<p>现在这个备库上就有了临时库需要的所有binlog了，建立主备关系，就可以正常同步了。</p>
</li>
</ol><p>不论是把mysqlbinlog工具解析出的binlog文件应用到临时库，还是把临时库接到备库上，这两个方案的共同点是：误删库或者表后，恢复数据的思路主要就是通过备份，再加上应用binlog的方式。</p><p>也就是说，这两个方案都要求备份系统定期备份全量日志，而且需要确保binlog在被从本地删除之前已经做了备份。</p><p>但是，一个系统不可能备份无限的日志，你还需要根据成本和磁盘空间资源，设定一个日志保留的天数。如果你的DBA团队告诉你，可以保证把某个实例恢复到半个月内的任意时间点，这就表示备份系统保留的日志时间就至少是半个月。</p><p>另外，我建议你不论使用上述哪种方式，都要把这个数据恢复功能做成自动化工具，并且经常拿出来演练。为什么这么说呢？</p><p>这里的原因，主要包括两个方面：</p><ol>
<li>
<p>虽然“发生这种事，大家都不想的”，但是万一出现了误删事件，能够快速恢复数据，将损失降到最小，也应该不用跑路了。</p>
</li>
<li>
<p>而如果临时再手忙脚乱地手动操作，最后又误操作了，对业务造成了二次伤害，那就说不过去了。</p>
</li>
</ol><h1>延迟复制备库</h1><p>虽然我们可以通过利用并行复制来加速恢复数据的过程，但是这个方案仍然存在“恢复时间不可控”的问题。</p><p>如果一个库的备份特别大，或者误操作的时间距离上一个全量备份的时间较长，比如一周一备的实例，在备份之后的第6天发生误操作，那就需要恢复6天的日志，这个恢复时间可能是要按天来计算的。</p><p>那么，我们有什么方法可以缩短恢复数据需要的时间呢？</p><p>如果有非常核心的业务，不允许太长的恢复时间，我们可以考虑<strong>搭建延迟复制的备库。</strong>这个功能是MySQL 5.6版本引入的。</p><p>一般的主备复制结构存在的问题是，如果主库上有个表被误删了，这个命令很快也会被发给所有从库，进而导致所有从库的数据表也都一起被误删了。</p><p>延迟复制的备库是一种特殊的备库，通过 CHANGE MASTER TO MASTER_DELAY = N命令，可以指定这个备库持续保持跟主库有N秒的延迟。</p><p>比如你把N设置为3600，这就代表了如果主库上有数据被误删了，并且在1小时内发现了这个误操作命令，这个命令就还没有在这个延迟复制的备库执行。这时候到这个备库上执行stop slave，再通过之前介绍的方法，跳过误操作命令，就可以恢复出需要的数据。</p><p>这样的话，你就随时可以得到一个，只需要最多再追1小时，就可以恢复出数据的临时实例，也就缩短了整个数据恢复需要的时间。</p><h1>预防误删库/表的方法</h1><p>虽然常在河边走，很难不湿鞋，但终究还是可以找到一些方法来避免的。所以这里，我也会给你一些减少误删操作风险的建议。</p><p>第一条建议是，账号分离。这样做的目的是，避免写错命令。比如：</p><ul>
<li>我们只给业务开发同学DML权限，而不给truncate/drop权限。而如果业务开发人员有DDL需求的话，也可以通过开发管理系统得到支持。</li>
<li>即使是DBA团队成员，日常也都规定只使用只读账号，必要的时候才使用有更新权限的账号。</li>
</ul><p>第二条建议是，制定操作规范。这样做的目的，是避免写错要删除的表名。比如：</p><ul>
<li>在删除数据表之前，必须先对表做改名操作。然后，观察一段时间，确保对业务无影响以后再删除这张表。</li>
<li>改表名的时候，要求给表名加固定的后缀（比如加_to_be_deleted)，然后删除表的动作必须通过管理系统执行。并且，管理系删除表的时候，只能删除固定后缀的表。</li>
</ul><h1>rm删除数据</h1><p>其实，对于一个有高可用机制的MySQL集群来说，最不怕的就是rm删除数据了。只要不是恶意地把整个集群删除，而只是删掉了其中某一个节点的数据的话，HA系统就会开始工作，选出一个新的主库，从而保证整个集群的正常工作。</p><p>这时，你要做的就是在这个节点上把数据恢复回来，再接入整个集群。</p><p>当然了，现在不止是DBA有自动化系统，SA（系统管理员）也有自动化系统，所以也许一个批量下线机器的操作，会让你整个MySQL集群的所有节点都全军覆没。</p><p>应对这种情况，我的建议只能是说尽量把你的备份跨机房，或者最好是跨城市保存。</p><h1>小结</h1><p>今天，我和你讨论了误删数据的几种可能，以及误删后的处理方法。</p><p>但，我要强调的是，预防远比处理的意义来得大。</p><p>另外，在MySQL的集群方案中，会时不时地用到备份来恢复实例，因此定期检查备份的有效性也很有必要。</p><p>如果你是业务开发同学，你可以用show grants命令查看账户的权限，如果权限过大，可以建议DBA同学给你分配权限低一些的账号；你也可以评估业务的重要性，和DBA商量备份的周期、是否有必要创建延迟复制的备库等等。</p><p>数据和服务的可靠性不止是运维团队的工作，最终是各个环节一起保障的结果。</p><p>今天的课后话题是，回忆下你亲身经历过的误删数据事件吧，你用了什么方法来恢复数据呢？你在这个过程中得到的经验又是什么呢？</p><p>你可以把你的经历和经验写在留言区，我会在下一篇文章的末尾选取有趣的评论和你一起讨论。感谢你的收听，也欢迎你把这篇文章分享给更多的朋友一起阅读。</p><h1>上期问题时间</h1><p>我在上一篇文章给你留的问题，是关于空表的间隙的定义。</p><p>一个空表就只有一个间隙。比如，在空表上执行：</p><pre><code>begin;
select * from t where id>1 for update;
</code></pre><p>这个查询语句加锁的范围就是next-key lock (-∞, supremum]。</p><p>验证方法的话，你可以使用下面的操作序列。你可以在图4中看到显示的结果。</p><p><img src="https://static001.geekbang.org/resource/image/12/65/12eb6a38c347203f60df72ecaea95565.png" alt=""></p><center><span class="reference">图3 复现空表的next-key lock</span></center><p><img src="https://static001.geekbang.org/resource/image/53/9f/531b6556ffc82c6b02f9a010a3ceb09f.png" alt=""></p><center><span class="reference">图4 show engine innodb status 部分结果</span></center><p>评论区留言点赞板：</p><blockquote>
<p>@老杨同志 给出了正确的分析和SQL语句验证方法；<br>
@库淘淘 指出了show engine innodb status验证结论。</p>
</blockquote><p>赞这些思考和反馈。</p><p><img src="https://static001.geekbang.org/resource/image/09/77/09c1073f99cf71d2fb162a716b5fa577.jpg" alt=""></p>
</div>
</div>
</div>
<div data-v-87ffcada="" class="article-comments pd"><h2 data-v-87ffcada=""><span
data-v-87ffcada="">精选留言</span></h2>
<ul data-v-87ffcada="">
<li data-v-87ffcada="" class="comment-item"><img
src="https://static001.geekbang.org/account/avatar/00/13/d2/cd/6fb14677.jpg" class="avatar">
<div class="info">
<div class="hd"><span class="username">苍茫</span>
</div>
<div class="bd">有一次，我维护一张表，需要手动修改大量数据的状态，sql就很多，然后我保存到txt文件中以附件的形式发给部门老大审批，部门老大审批后转发邮件给运维，然后运维这哥们用的是360浏览器，他预览的sql，然后全部复制到客户端执行，但是问题也在这，360浏览器预览的时候由于文本偏长，到了某一条语句只有前半部分的update语句，没有后面的条件，然后就悲剧了。全表的状态都变成同一个。然后我就特别莫名其妙，还被老大批了一顿。说我写的脚本有问题。这锅我可不背，我把脚本在本地备份库跑了一遍又一遍就是没有问题。然后我再去运维哥们那，叫他再复制一下脚本就发现问题了。好在执行脚本前进行了表备份。扩展一下，如果你用谷歌浏览器就不会出现这种问题！发现问题后，立马恢复了数据 <br></div>
<span class="time">2019-01-23 23:46</span>
<div class="reply">
<div class="reply-hd"><span>作者回复</span></div>
<p class="reply-content"> 这个是血泪经验<br><br>拷贝文本执行，这个操作还可能存在字符集隐患。<br><br>这个事情更深一层逻辑，是你做了创造性的事情，非常优秀。<br>而这个运维同学认为他只是一个”复制粘贴执行的人”， 这种思路下是迟早会出问题的。</p>
<p class="reply-time">2019-01-24 08:14</p>
</div>
</div>
</li>
<li data-v-87ffcada="" class="comment-item"><img
src="http://thirdwx.qlogo.cn/mmopen/vi_32/hGLA7hlgfLk3VQs1m3HbkGCg0zicgaSJeYFGfW7JgocuicpoN0Ukyic7MouDXXxBDAKSJLJyEWb3Ef7ic6K6bOKbsw/132" class="avatar">
<div class="info">
<div class="hd"><span class="username">linhui0705</span>
</div>
<div class="bd">对生产数据库操作，公司DBA提出的编写脚本方法，个人觉得还是值得分享，虽说可能大部分公司也可能有这样的规范。<br>修改生产的数据，或者添加索引优化，都要先写好四个脚本：备份脚本、执行脚本、验证脚本和回滚脚本。备份脚本是对需要变更的数据备份到一张表中，固定需要操作的数据行，以便误操作或业务要求进行回滚；执行脚本就是对数据变更的脚本，为防Update错数据，一般连备份表进行Update操作；验证脚本是验证数据变更或影响行数是否达到预期要求效果；回滚脚本就是将数据回滚到修改前的状态。<br>虽说分四步骤写脚本可能会比较繁琐，但是这能够很大程度避免数据误操作。 <br></div>
<span class="time">2019-01-23 20:40</span>
<div class="reply">
<div class="reply-hd"><span>作者回复</span></div>
<p class="reply-content"> 非常好的经验<br>如果能够切实执行，即使有出问题，也是可以很快恢复的<br>把这些脚本当做开发代码来维护，是一个很好的实践</p>
<p class="reply-time">2019-01-23 23:34</p>
</div>
</div>
</li>
<li data-v-87ffcada="" class="comment-item"><img
src="https://static001.geekbang.org/account/avatar/00/13/f8/70/f3a33a14.jpg" class="avatar">
<div class="info">
<div class="hd"><span class="username">某、人</span>
</div>
<div class="bd">总结下今天的知识点:<br>我觉得DBA的最核心的工作就是保证数据的完整性<br>今天老师也讲到了先要做好预防,预防的话大概是通过这几个点：<br>1.权限控制与分配(数据库和服务器权限)<br>2.制作操作规范<br>3.定期给开发进行培训<br>4.搭建延迟备库<br>5.做好sql审计,只要是对线上数据有更改操作的语句(DML和DDL)都需要进行审核<br>6.做好备份。备份的话又分为两个点.<br>(1)如果数据量比较大,用物理备份xtrabackup。定期对数据库进行全量备份,也可以做增量备份。<br>(2)如果数据量较少,用mysqldump或者mysqldumper。再利用binlog来恢复或者搭建主从的方式来恢复数据。<br>定期备份binlog文件也是很有必要的<br>还需要定期检查备份文件是否可用,如果真的发生了误操作,需要恢复数据的时候,发生备份文件不可用,那就更悲剧了<br><br>如果发生了数据删除的操作,又可以从以下几个点来恢复:<br>1.DML误操作语句造成数据不完整或者丢失。可以通过flashback,不过我们目前用的是美团的myflash,也是一个不错的工具，本质都差不多.都是先解析binlog event,然后在进行反转。把delete反转为insert,insert反转为delete,update前后image对调。所以必须设置binlog_format=row 和 binlog_row_image=full.<br>切记恢复数据的时候,应该先恢复到临时的实例,然后在恢复回主库上。<br>2.DDL语句误操作(truncate和drop),由于DDL语句不管binlog_format是row还是statement.在binlog里都只记录语句,不记录image所以恢复起来相对要麻烦得多。只能通过全量备份+应用binlog的方式来恢复数据。一旦数据量比较大,那么恢复时间就特别长,<br>对业务是个考验。所以就涉及到老师在第二讲提到的问题了，全量备份的周期怎么去选择 <br></div>
<span class="time">2019-01-23 14:14</span>
<div class="reply">
<div class="reply-hd"><span>作者回复</span></div>
<p class="reply-content"> </p>
<p class="reply-time">2019-01-23 18:22</p>
</div>
</div>
</li>
<li data-v-87ffcada="" class="comment-item"><img
src="https://static001.geekbang.org/account/avatar/00/10/93/8a/abb7bfe3.jpg" class="avatar">
<div class="info">
<div class="hd"><span class="username">亮</span>
</div>
<div class="bd">CREATE TABLE `t` (<br>`id` int(11) NOT NULL,<br>`city` varchar(16) NOT NULL,<br>`name` varchar(16) NOT NULL,<br>`age` int(11) NOT NULL,<br>`addr` varchar(128) DEFAULT NULL,<br>PRIMARY KEY (`id`),<br>KEY `city` (`city`)<br>) ENGINE=InnoDB;<br><br>老师请教您16章的问题，您提到“city、name、age 这三个字段的定义总长度是36”，这个是怎么算出来的呢，varchar(16)是可以保存16个字符，占用了49个字节（utf8），所以我没想明白36是怎么来的。<br><br>第二个问题是max_length_for_sort_data参数系统默认是1024，是1024个字节的意思吗？<br><br>2019-01-23<br><br> 作者回复<br><br>1. age(11)其实是4个字节哈<br>2. 对，单位是字节<br><br>谢谢老师，不过还是没明白，age是4个字节，city和name分别是49个字节，49+49+4=102字节，36是怎么来的呢？再次感谢<br> <br></div>
<span class="time">2019-01-23 16:55</span>
<div class="reply">
<div class="reply-hd"><span>作者回复</span></div>
<p class="reply-content">哦 抱歉哈，我这边验证的时候默认用的latin1，是16+16+4</p>
<p class="reply-time">2019-01-23 18:28</p>
</div>
</div>
</li>
<li data-v-87ffcada="" class="comment-item"><img
src="https://static001.geekbang.org/account/avatar/00/0f/9d/60/fe522a1a.jpg" class="avatar">
<div class="info">
<div class="hd"><span class="username">技术人成长</span>
</div>
<div class="bd">我只想说，作者功力过于深厚了！ <br></div>
<span class="time">2019-01-25 12:15</span>
</div>
</li>
<li data-v-87ffcada="" class="comment-item"><img
src="https://static001.geekbang.org/account/avatar/00/13/e6/ee/e3c4c9b3.jpg" class="avatar">
<div class="info">
<div class="hd"><span class="username">Cranliu</span>
</div>
<div class="bd">个人觉得，预防同样很重要，一般的dml操作，我是先ctas要操作的数据，drop/truncate 的时候先逻辑备份。 <br></div>
<span class="time">2019-01-23 08:37</span>
<div class="reply">
<div class="reply-hd"><span>作者回复</span></div>
<p class="reply-content">对的，备份的意识很重要。<br><br><br>不过“drop/truncate 的时候先逻辑备份”这么做的不多^_^ <br>主要的原因是逻辑备份可能会对系统有额外消耗。（全表扫描）<br><br></p>
<p class="reply-time">2019-01-23 09:00</p>
</div>
</div>
</li>
<li data-v-87ffcada="" class="comment-item"><img
src="https://static001.geekbang.org/account/avatar/00/13/f4/cf/2af390ad.jpg" class="avatar">
<div class="info">
<div class="hd"><span class="username">511</span>
</div>
<div class="bd">早~ <br></div>
<span class="time">2019-01-23 08:35</span>
</div>
</li>
<li data-v-87ffcada="" class="comment-item"><img
src="https://static001.geekbang.org/account/avatar/00/14/20/3a/90db6a24.jpg" class="avatar">
<div class="info">
<div class="hd"><span class="username">Long</span>
</div>
<div class="bd">又到了讲故事(事故)的时候了，历史上遇到过很多次事故。全表误删除，误更新不下于8次，有MySQL 的DB也有memory DB. 有一次同事比较搞笑的是，有一次一张重要的权限控制表更新，由于用的是workbench 界面工具当时写了where条件，但是在选中执行行的时候where条件在第二行，没选中，还在执行前的时候手动把session 级的sql_safe_updates=0了，也没有点开那个autocommit取消的按钮。然后一执行，全表更新了，导致全网只有一个用户可以正常登录。还有其他的误操作，总结历史遇到过的这类问题基本就是几类<br>1. 登错环境，以为是测试环境，一顿操作猛如虎，一看环境是生产，回头一看，表已经drop了……<br>2. sql写的有问题，逻辑错误，或者条件缺失，常见的如不带where；or关键字的逻辑没有用括号括好<br>3. 还有一些奇葩的，比如where 字段1=字段2写成了字段1+字段2，逻辑等于判断变成了是否为1的判断了，大概率全表更新了。<br><br>错误解决大部分都是用备份恢复或者根据错误的逻辑来逻辑恢复。<br><br><br>还有一个，最近在尝试的，就是ibd文件中有坏页，只要一读到那个坏页，就会crash，报错spaceid page no should be多少多少，尝试了copy frm, ibd，ibdata, iblogfile这些表结构，数据文件，数据字典，undo redo 日志，也尝试用了undrop的工具也解析不出来。这个表比较特殊，是一个特殊库，没备份，表没有索引没法通过走索引跳过那个坏页的那些行，现在的状态是，只能用nysqldump恢复一部分数据。 我想通过16进制，自己慢慢找到那个脏写的数据，然后修改一下文件……<br>老师有什么比较好的建议吗？或者后面会说到ibd文件的物理结构之类的吗？ 感谢 <br></div>
<span class="time">2019-01-28 04:32</span>
<div class="reply">
<div class="reply-hd"><span>作者回复</span></div>
<p class="reply-content">感谢你的分享，都是血泪教训。。<br>我看有几个是用的可视化工具导致的，后面还是尽量用MySQL客户端敲命令吧<br><br>ibd文件坏页我之前有回答过其他同学的，看下这个<br>https://weibo.com/1933424965/H3qIu0JYo?from=page_1005051933424965_profile&wvr=6&mod=weibotime</p>
<p class="reply-time">2019-01-28 08:41</p>
</div>
</div>
</li>
<li data-v-87ffcada="" class="comment-item"><img
src="https://static001.geekbang.org/account/avatar/00/13/f6/d1/dcafd7cf.jpg" class="avatar">
<div class="info">
<div class="hd"><span class="username">PengfeiWang</span>
</div>
<div class="bd">老师，您好，有个问题请教一下：<br>关于MySQL备份有效性的验证，你有什么好的方法可以推荐吗？目前只能通过不定期的备份恢复来验证。 <br></div>
<span class="time">2019-01-25 15:46</span>
<div class="reply">
<div class="reply-hd"><span>作者回复</span></div>
<p class="reply-content">大家都是这么做的</p>
<p class="reply-time">2019-01-25 18:47</p>
</div>
</div>
</li>
<li data-v-87ffcada="" class="comment-item"><img
src="https://static001.geekbang.org/account/avatar/00/13/ef/3e/9c3a8abc.jpg" class="avatar">
<div class="info">
<div class="hd"><span class="username">AI杜嘉嘉</span>
</div>
<div class="bd">老师，接着上面问题。是删表，线上rename，有什么风险吗？需要注意什么？rename是不是ddl操作 <br></div>
<span class="time">2019-01-25 15:42</span>
<div class="reply">
<div class="reply-hd"><span>作者回复</span></div>
<p class="reply-content">是，不过rename的执行速度很快<br></p>
<p class="reply-time">2019-01-25 18:47</p>
</div>
</div>
</li>
<li data-v-87ffcada="" class="comment-item"><img
src="http://thirdwx.qlogo.cn/mmopen/vi_32/DYAIOgq83eop9WylZJicLQxlvXukXUgPp39zJHyyReK5s1C9VhA6rric7GiarbfQMuWhdCCDdxdfL610Hc4cNkn9Q/132" class="avatar">
<div class="info">
<div class="hd"><span class="username">还一棵树</span>
</div>
<div class="bd">我遇到过一个线上误truncate表的，最终选择的处理过程如下：<br>1、创建一个同版本的空mysql实例，建一个名字+结构一模一样的表<br>2、discard这个表的tablespace<br>3、从之前的备份集中 innobackupex --apply-log 并记录binlog位置（用innobackupex备份的）。还原后找到误操作表的.ibd文件，copy到新实例对应的位置<br>4、在之前创建的mysql实例上import tablespace<br>5、利用mysqlbinlog 处理增量数据<br>6、最后导出 再导入 <br></div>
<span class="time">2019-01-24 20:19</span>
<div class="reply">
<div class="reply-hd"><span>作者回复</span></div>
<p class="reply-content"><br>这基本上是最快的恢复步骤了</p>
<p class="reply-time">2019-01-24 20:46</p>
</div>
</div>
</li>
<li data-v-87ffcada="" class="comment-item"><img
src="https://static001.geekbang.org/account/avatar/00/13/d2/cd/6fb14677.jpg" class="avatar">
<div class="info">
<div class="hd"><span class="username">苍茫</span>
</div>
<div class="bd">有一次我在查询数据倒数报表给业务方，那个脚本是我写的，关联了很多表，还跨了库，一个主表有一万多条纪录，关联另一张操作记录表好像是10万条数据。因为要统计多步操作步骤，所以每一步的操作记录我就得按照不同的条件关联产生临时表（关联中有group 还有max（）聚合函数，这个是需求导致的），一开始写好的查询很快有了结果。那天11点多的时候，我执行那个脚本，发现很慢没有反应，然后我就把连接关了，重复几次操作，然后生产库就被我搞挂了。后面运维的同学操作了一波才恢复过来。这次也是运维同学背的锅。后面，还把我的操作给贴出来了，做通报批评。我想问下为啥会出现这种情况呢？<br>后续我的组长对我写的sql进行了优化，主要是把联表操作需要的信息放在子查询中，然后再操作记录表中加了索引，有了备份库，每次执行脚本导出数据都是在备份库中导出，就再也没有发生这个问题了。 <br></div>
<span class="time">2019-01-24 19:42</span>
<div class="reply">
<div class="reply-hd"><span>作者回复</span></div>
<p class="reply-content">后面有一篇专门说这个，敬请期待哈</p>
<p class="reply-time">2019-01-24 20:17</p>
</div>
</div>
</li>
<li data-v-87ffcada="" class="comment-item"><img
src="http://thirdwx.qlogo.cn/mmopen/vi_32/DYAIOgq83erJFlHhylrbLANtehiaX50wgVa2Z1ibQAdLpgyW4gCpEyOKEI9bPNZZBiabrP2oCleZWc2KKyKADz8tg/132" class="avatar">
<div class="info">
<div class="hd"><span class="username">xishuai</span>
</div>
<div class="bd">老师，麻烦问一下，5.7.21上innodb的表两列（有中文有英文）建的全文索引，最小分词1，按中文可以查询，按英文有些查询不出来，您知道原因吗？ <br></div>
<span class="time">2019-01-24 18:52</span>
<div class="reply">
<div class="reply-hd"><span>作者回复</span></div>
<p class="reply-content">全文索引有stop words的，你看看是不是落在stop words里了</p>
<p class="reply-time">2019-01-24 20:18</p>
</div>
</div>
</li>
<li data-v-87ffcada="" class="comment-item"><img
src="http://thirdwx.qlogo.cn/mmopen/vi_32/G9pdXkStPJoCwmpxux3kshQFrhWOnKcia1AH2O6uSTSGAVMm7AO7h76t2w7BpnVl6vp2hlzODAibia5xa7KIKvtWg/132" class="avatar">
<div class="info">
<div class="hd"><span class="username">catalina</span>
</div>
<div class="bd">老师，我们现在需要将一个库下面的所有表的数据同步到另外一个库，每个表有几百万数据吧，大约十多张表。有什么好的方法吗？ <br></div>
<span class="time">2019-01-24 18:22</span>
<div class="reply">
<div class="reply-hd"><span>作者回复</span></div>
<p class="reply-content">原库的这几个表还会继续更新吗？ 如果会继续更新，就用搭主备的方法；<br>如果没更新了，后面有一个文章专门讲这个问题哈</p>
<p class="reply-time">2019-01-24 20:21</p>
</div>
</div>
</li>
<li data-v-87ffcada="" class="comment-item"><img
src="https://static001.geekbang.org/account/avatar/00/10/41/27/3ff1a1d6.jpg" class="avatar">
<div class="info">
<div class="hd"><span class="username">hua168</span>
</div>
<div class="bd">大神，有亲戚小公司搞DBA一年，我想问一下：<br>1.DBA一般发展方向是怎样的呀？运维和开发我了解，DBA没接触过，无法给建议，一般的升级过程是怎样的？<br>2.以后发展方向是怎样？现在都是开源、大数据时代时代，阿里又搞“去IOE”，一般oracle DBA发展前景不好吧？<br><br>能帮指一个大概的方向吗？谢谢~~ <br></div>
<span class="time">2019-01-24 15:24</span>
</div>
</li>
<li data-v-87ffcada="" class="comment-item"><img
src="https://static001.geekbang.org/account/avatar/00/11/8a/3e/30c05bce.jpg" class="avatar">
<div class="info">
<div class="hd"><span class="username">aliang</span>
</div>
<div class="bd">老师好。这是第6讲评论区Tony Du的评论：<br>session A: begin; select * from t limit 1; 最先启动sessionA<br>session B: begin; select * from t limit 1; 紧接着启动sessionB<br>session C: alter table t add f int; 然后再是启动sessionC<br>session D: begin; select * from t limit 1; 最后是启动sessionD<br>他说session C会被A和B阻塞，D会被C阻塞；当A和B提交后，D是可以继续执行得到查询结果的，但是C仍然被阻塞，只有D提交后C才能执行成功。我自己在5.6和5.7按他的步骤做了试验，结果和他一样。<br>然后我再做了一次试验，这次把D的begin;去掉，变成了：<br>session A: begin; select * from t limit 1; 最先启动sessionA<br>session B: begin; select * from t limit 1; 紧接着启动sessionB<br>session C: alter table t add f int; 然后再是启动sessionC<br>session D: select * from t limit 1; 最后是启动sessionD<br>结果是当A和B提交后，D和C都能执行成功了（和老师的结果一样）。我的问题是：为什么第一次session D显式开启事务，和第二次不显式开启的结果不一样呢？ <br></div>
<span class="time">2019-01-24 11:12</span>
</div>
</li>
<li data-v-87ffcada="" class="comment-item"><img
src="https://static001.geekbang.org/account/avatar/00/13/dd/39/f5747c5d.jpg" class="avatar">
<div class="info">
<div class="hd"><span class="username">太福</span>
</div>
<div class="bd">因为时间原因，前面的课程没跟上，在这里请教个最近线上mysql遇到的问题：<br> 一个从库mysql5.6版本,正常情况下只有3到5个并发sql在查询，每分钟用下面的sql查看一次检测到的<br> SELECT t1.* FROM information_schema.`PROCESSLIST` t1 WHERE info is not null ORDER BY time desc;<br> 前一次检测还是几个sql在查询，下1分钟查到2000多个sql在跑，很多堆积了几十秒的sql，状态“Sending data” “Creating sort index”<br> ，而这些sql在正常情况下是不到1秒就查到结果了的，且cpu使用率与io很低，看起来mysql僵死的了。<br>有两个问题：1）问题突然出现<br> 2）大量sql在跑，而cpu与磁盘io反而比正常下降；这是从库，写只有主从同步，其它都是读查询。<br>配置：64G内存，bp分配40G，io使用不高<br>,业务量没大变动，也没新版本发布，大体排除业务并发加大导致的。 <br></div>
<span class="time">2019-01-24 10:24</span>
</div>
</li>
<li data-v-87ffcada="" class="comment-item"><img
src="https://static001.geekbang.org/account/avatar/00/11/45/64/2b09a36b.jpg" class="avatar">
<div class="info">
<div class="hd"><span class="username">风二中</span>
</div>
<div class="bd">老师，您好。如何设置binlog 的备份时间呢，感觉RPO 时间总是不能为零，如果是informix 可以只丢一个逻辑日志。对于需要保证mysql恢复 RPO 时间为零，有什么建议吗？备库延迟1小时，加每小时备份一次binlog 。 <br></div>
<span class="time">2019-01-23 19:36</span>
<div class="reply">
<div class="reply-hd"><span>作者回复</span></div>
<p class="reply-content">嗯 对于核心业务，使用延迟复制的备份<br><br>RPO时间为0？有这么凶残的业务需求吗。。我能想到的就是多套延迟备份的库。<br>比如开3个， 一个是10分钟，一个20分钟，一个30分钟（主要考虑成本）<br>RPO这么敏感的，应该有对应敏感的监控，误操作要是30分钟还不能发现，可以挑战一下，这个业务是不是值得这么高的指标^_^<br><br></p>
<p class="reply-time">2019-01-23 20:09</p>
</div>
</div>
</li>
<li data-v-87ffcada="" class="comment-item"><img
src="" class="avatar">
<div class="info">
<div class="hd"><span class="username">700</span>
</div>
<div class="bd">老师，请教。假如我有数据库的物理备份和逻辑备份（mydumper），因为 mydumper 导出的数据是按表名分开存放的，那么表误删数据的时候优先考虑逻辑备份（误删数据表的备份集）+binlog 恢复比物理备份恢复会快点？基于此，我总感觉物理备份只是在要恢复整个实例时才会优先考虑，而恢复整个实例的场景又是比较少的，毕竟一般大家的线上架构至少都是主从模式。所以逻辑备份被物理备份更实用。这种想法算是说得通吗？ <br></div>
<span class="time">2019-01-23 18:23</span>
<div class="reply">
<div class="reply-hd"><span>作者回复</span></div>
<p class="reply-content">其实是要看表的大小<br><br>如果是一个大表，逻辑恢复还是比较慢的，毕竟用物理备份来恢复出实例，相对会快些。<br><br>当然如果你已经有了一个成熟系统用逻辑恢复来实现，也不用改它，主要关注一下是否满足SLA就可以了^_^<br>facebook就是主要用逻辑备份的</p>
<p class="reply-time">2019-01-23 19:16</p>
</div>
</div>
</li>
<li data-v-87ffcada="" class="comment-item"><img
src="https://static001.geekbang.org/account/avatar/00/14/06/b1/ba6b4335.jpg" class="avatar">
<div class="info">
<div class="hd"><span class="username">高强</span>
</div>
<div class="bd">老师你好，问个带子查询的delete/update/insert问题，Delete from A where name in(
<br> Select name from B where time<’2019-01-23 11:11:12’
<br>) 这条语句删除A表记录之前是不是也会把表 B满足条件的记录也会给锁住呢?<br>我试验了一下会锁住B表记录的，有没有其他办法不让锁B表呢? <br></div>
<span class="time">2019-01-23 16:38</span>
<div class="reply">
<div class="reply-hd"><span>作者回复</span></div>
<p class="reply-content">改成RC隔离级别试试</p>
<p class="reply-time">2019-01-23 18:25</p>
</div>
</div>
</li>
</ul>
</div>
</div>
</div>
</div>
</body>
</html>