{"id":95518,"date":"2020-09-30T19:42:27","date_gmt":"2020-09-30T17:42:27","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/istoriya-o-fizicheskom-udalenii-300-millionov-zapisej-v-mysql"},"modified":"2020-09-30T19:42:27","modified_gmt":"2020-09-30T17:42:27","slug":"istoriya-o-fizicheskom-udalenii-300-millionov-zapisej-v-mysql","status":"publish","type":"post","link":"https:\/\/prohoster.info\/sl\/blog\/administrirovanie\/istoriya-o-fizicheskom-udalenii-300-millionov-zapisej-v-mysql","title":{"rendered":"Zgodba o fizi\u010dnem brisanju 300 milijonov zapisov v MySQL","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Uvod<\/h2>\n

\n\u017divjo. Sem ningenMe, spletni razvijalec.<\/p>\n

Kot je navedeno v naslovu, je moja zgodba zgodba o fizi\u010dnem brisanju 300 milijonov zapisov v MySQL.<\/p>\n

Zanimalo me je to, zato sem se odlo\u010dil narediti opomnik (navodila).<\/p>\n

Za\u010detek \u2014 Alert<\/h2>\n

\nV paketnem stre\u017enikom<\/a>, ki ga uporabljam in vzdr\u017eujem, je redni postopek, ki enkrat na dan zbira podatke za pretekli mesec iz MySQL. <\/p>\n

Obi\u010dajno se ta postopek zaklju\u010di v pribli\u017eno 1 uri, ampak tokrat se ni zaklju\u010dil 7 ali 8 ur, in opomnik ni prenehal pojavljati\u2026 <\/a><\/noindex><\/p>\n

Iskanje vzroka<\/h2>\n

\nPosku\u0161al sem ponovno zagnati postopek, pogledati dnevnike, toda ni\u010d resnega nisem opazil.
\nZahteva se je pravilno indeksirala. Toda ko sem razmi\u0161ljal, kaj gre narobe, sem ugotovil, da je obseg DB precej velik. <\/p>\n

hoge_table | 350'000'000 |<\/code><\/pre>\n
\n350 milijonov zapisov. Zdi se, da je indeksacija delovala pravilno, samo zelo po\u010dasi.<\/p>\n
Zahtevani zbir podatkov za mesec je zna\u0161al pribli\u017eno 12 000 000 zapisov. Zdi se, da je ekipa select vzela veliko \u010dasa in transakcija dolgo \u010dasa ni bila izvedena. <\/p>\n
DB<\/h2>\n
\nV bistvu je to tabela, ki se vsak dan pove\u010duje za pribli\u017eno 400 000 zapisov. Baza bi morala zbirati podatke samo za pretekli mesec, kar pomeni, da je bil izra\u010dun, da bo obvladala prav to koli\u010dino podatkov, toda \u017eal operacija rotate ni bila vklopljena.<\/p>\n
Ta baza podatkov ni bila razvita z mojo pomo\u010djo. Prevzel sem jo od drugega razvijalca, zato ostaja ob\u010dutek, da gre za tehni\u010dno dolgovanje. <\/p>\n
Pri\u0161el je trenutek, ko je obseg dnevno vstavljenih podatkov postal velik in kon\u010dno dosegel mejnik. Predvideva se, da bi pri delu s tako velikimi koli\u010dinami podatkov bilo treba te lo\u010diti, toda tega \u017eal ni bilo storjenega.<\/p>\n
In tu sem stopil v igro.<\/p>\n
Popravek<\/h2>\n
\nBilo bi bolj smiselno zmanj\u0161ati samo DB in skraj\u0161ati \u010das obdelave, kot pa spremeniti samo logiko.<\/p>\n
Situacija bi se morala znatno spremeniti, \u010de izbri\u0161em 300 milijonov zapisov, zato sem se odlo\u010dil to storiti\u2026 Eh, mislil sem, da bo to zagotovo uspelo.<\/p>\n
Dejanje 1<\/h2>\n
\nPotem ko sem pripravil zanesljivo varnostno kopijo, sem kon\u010dno za\u010del po\u0161iljati poizvedbe.<\/p>\n
\u300cPo\u0161iljanje poizvedbe\u300d<\/p>\n
DELETE FROM hoge_table WHERE create_time <= 'YYYY-MM-DD HH:MM:SS';<\/code><\/pre>\n
\n\u300c…\u300d<\/p>\n
\u300c…\u300d<\/p>\n
\u201eHmm\u2026 Ni\u010d. Morda postopek traja predolgo?\u201d \u2013 sem pomislil, a sem vseeno pogledal v grafano in videl, da se je obremenitev diska hitro pove\u010devala. 
\n\u201eTveganje\u201c \u2013 sem pomislil \u0161e enkrat in takoj ustavil poizvedbo.<\/p>\n
Dejanje 2<\/h2>\n
\nPo analizi vsega sem spoznal, da je bila koli\u010dina podatkov prevelika, da bi jo lahko odstranil vse naenkrat.<\/p>\n
Odlo\u010dil sem se, da napi\u0161em skripto, ki lahko izbri\u0161e pribli\u017eno 1.000.000 zapisov, in jo zagnal.<\/p>\n
\u201eizvajam skripto\u201c<\/p>\n
\u201eZdaj bo gotovo uspelo,\u201c \u2013 sem pomislil.<\/p>\n
Dejanje 3<\/h2>\n
\nDruga metoda je delovala, a se je izkazala za zelo zamudno.
\nDa bi vse potekalo urejeno in brez nepotrebnega stresa, bi potreboval pribli\u017eno dva tedna. Vendar to, kar sem imel v mislih, ni ustrezalo zahtevam storitve, zato sem se moral od tega odmakniti.<\/p>\n
Zato sem se odlo\u010dil, da naredim to:<\/p>\n
Kopiramo tabelo in jo preimenujemo.<\/h3>\n
\nIz prej\u0161njega koraka sem spoznal, da odstranitev tako velike koli\u010dine podatkov povzro\u010da enako veliko obremenitev. Zato sem se odlo\u010dil ustvariti novo tabelo od za\u010detka s pomo\u010djo vstavitev in vanjo prenesti podatke, ki sem jih nameraval izbrisati.<\/p>\n
| hoge_table     | 350'000'000|\n| tmp_hoge_table |  50'000'000|<\/code><\/pre>\n
\n\u010ce naredimo novo tabelo enake velikosti, kot je navedeno zgoraj, bi morala hitrost obdelave podatkov biti za 1\/7 hitrej\u0161a.<\/p>\n
Ko sem ustvaril tabelo in jo preimenoval, sem za\u010del uporabljati to kot glavno tabelo. Zdaj, \u010de bom izbrisal tabelo s 300 milijoni zapisov, bi vse moralo biti v redu.
\nUgotovil sem, da truncate ali drop ustvarjata manj\u0161o obremenitev kot delete, in se odlo\u010dil uporabiti ta na\u010din.<\/p>\n
Izvr\u0161evanje<\/h3>\n
\n\u300cPo\u0161iljanje poizvedbe\u300d<\/p>\n
INSERT INTO tmp_hoge_table SELECT * FROM hoge_table WHERE create_time > 'YYYY-MM-DD HH:MM:SS';<\/code><\/pre>\n
\n\u300c…\u300d
\n\u300c…\u300d
\n\u300c\u044d\u043c…\uff1f\u300d<\/p>\n
Dejanje 4<\/h2>\n
\nMislil sem, da bo prej\u0161nja ideja delovala, a po po\u0161iljanju poizvedbe za vstavitev se je pojavilo ve\u010d napak. MySQL ne popu\u0161\u010da.<\/p>\n
\u017de sem bil tako utrujen, da sem za\u010del razmi\u0161ljati, da si tega ne \u017eelim ve\u010d delati.<\/p>\n
Pogledal sem in pomislil, da je mogo\u010de za enkrat poizvedb za vstavitev preve\u010d\u2026
\nPoskusil sem poslati poizvedbo za vstavitev na koli\u010dino podatkov, ki bi jih baza morala obdelati v enem dnevu. Uspelo je!<\/p>\n
No in po tem nadaljujemo z po\u0161iljanjem poizvedb na enako koli\u010dino podatkov. Ker moramo odstraniti mese\u010dno koli\u010dino podatkov, ponovimo to operacijo pribli\u017eno 35-krat.<\/p>\n
Preimenovanje tabele <\/h3>\n
\nTukaj mi je bila sre\u010da naklonjena: vse je potekalo gladko.<\/p>\n
Alerti so izginili.<\/h3>\n
\nHitrost obdelave po\u0161iljk se je pove\u010dala.<\/p>\n
V preteklosti je ta postopek trajal pribli\u017eno eno uro, zdaj pa traja pribli\u017eno 2 minuti. <\/p>\n
Ko sem se prepri\u010dal, da so vse te\u017eave re\u0161ene, sem izbrisal 300 milijonov zapisov. Izbrisal sem tabelo in se po\u010dutil kot ponovno rojen.<\/p>\n
Povzetek<\/h2>\n
\nZavedel sem se, da je bila pri obdelavi v paketih izpu\u0161\u010dena rotacija, kar je predstavljalo glavno te\u017eavo. Tak\u0161na napaka v arhitekturi vodi do prazne izgube \u010dasa. <\/p>\n
Ali ste kdaj pomislili na obremenitev ob replikaciji podatkov, ko bri\u0161ete zapise iz baze? Ne obremenjujmo MySQL.<\/p>\n
Tisti, ki se dobro spoznajo na podatkovne baze, se s tak\u0161no te\u017eavo zagotovo ne bodo soo\u010dili. Upam, da je bil ta \u010dlanek koristen ostalim.<\/p>\n
Hvala za branje!<\/p>\n
Zelo bi nas razveselilo, \u010de bi nam povedali, ali vam je bil ta \u010dlanek v\u0161e\u010d, ali je bil prevod jasen in ali je bil koristen?<\/i>
\n
Izvor: habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"
\u0412\u0432\u0435\u0434\u0435\u043d\u0438\u0435 \u041f\u0440\u0438\u0432\u0435\u0442. \u042f ningenMe, \u0432\u0435\u0431-\u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0447\u0438\u043a. \u041a\u0430\u043a \u0441\u043a\u0430\u0437\u0430\u043d\u043e \u0432 \u043d\u0430\u0437\u0432\u0430\u043d\u0438\u0438, \u043c\u043e\u044f \u0438\u0441\u0442\u043e\u0440\u0438\u044f \u2014 \u044d\u0442\u043e \u0438\u0441\u0442\u043e\u0440\u0438\u044f \u043e \u0444\u0438\u0437\u0438\u0447\u0435\u0441\u043a\u043e\u043c \u0443\u0434\u0430\u043b\u0435\u043d\u0438\u0438 300 \u043c\u0438\u043b\u043b\u0438\u043e\u043d\u043e\u0432 \u0437\u0430\u043f\u0438\u0441\u0435\u0439 \u0432 MySQL. \u042f \u0437\u0430\u0438\u043d\u0442\u0435\u0440\u0435\u0441\u043e\u0432\u0430\u043b\u0441\u044f \u044d\u0442\u0438\u043c, \u043f\u043e\u044d\u0442\u043e\u043c\u0443 \u0440\u0435\u0448\u0438\u043b \u0441\u0434\u0435\u043b\u0430\u0442\u044c \u043f\u0430\u043c\u044f\u0442\u043a\u0443 (\u0438\u043d\u0441\u0442\u0440\u0443\u043a\u0446\u0438\u044e). \u041d\u0430\u0447\u0430\u043b\u043e \u2014 Alert \u0412 \u043f\u0430\u043a\u0435\u0442\u043d\u043e\u043c \u0441\u0435\u0440\u0432\u0435\u0440\u0435, \u043a\u043e\u0442\u043e\u0440\u044b\u0439 \u044f \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u0443\u044e \u0438 \u043e\u0431\u0441\u043b\u0443\u0436\u0438\u0432\u0430\u044e, \u0438\u043c\u0435\u0435\u0442\u0441\u044f \u0440\u0435\u0433\u0443\u043b\u044f\u0440\u043d\u044b\u0439 \u043f\u0440\u043e\u0446\u0435\u0441\u0441, \u043a\u043e\u0442\u043e\u0440\u044b\u0439 \u043e\u0434\u0438\u043d \u0440\u0430\u0437 \u0432 \u0434\u0435\u043d\u044c \u0441\u043e\u0431\u0438\u0440\u0430\u0435\u0442 \u0434\u0430\u043d\u043d\u044b\u0435 \u0437\u0430 \u043f\u043e\u0441\u043b\u0435\u0434\u043d\u0438\u0439 \u043c\u0435\u0441\u044f\u0446 \u0438\u0437 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-95518","post","type-post","status-publish","format-standard","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Zgodba o fizi\u010dnem brisanju 300 milijonov zapisov v MySQL | ProHoster","description":"Uvod Pozdrav.","canonical_url":"https:\/\/prohoster.info\/sl\/blog\/administrirovanie\/istoriya-o-fizicheskom-udalenii-300-millionov-zapisej-v-mysql","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"sl_SI","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0418\u0441\u0442\u043e\u0440\u0438\u044f \u043e \u0444\u0438\u0437\u0438\u0447\u0435\u0441\u043a\u043e\u043c \u0443\u0434\u0430\u043b\u0435\u043d\u0438\u0438 300 \u043c\u0438\u043b\u043b\u0438\u043e\u043d\u043e\u0432 \u0437\u0430\u043f\u0438\u0441\u0435\u0439 \u0432 MySQL | ProHoster","og:description":"\u0412\u0432\u0435\u0434\u0435\u043d\u0438\u0435 \u041f\u0440\u0438\u0432\u0435\u0442.","og:url":"https:\/\/prohoster.info\/sl\/blog\/administrirovanie\/istoriya-o-fizicheskom-udalenii-300-millionov-zapisej-v-mysql","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-09-30T17:42:27+00:00","article:modified_time":"2020-09-30T17:42:27+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"95518","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 11:04:40","updated":"2026-02-09 21:38:05","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/posts\/95518","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/comments?post=95518"}],"version-history":[{"count":1,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/posts\/95518\/revisions"}],"predecessor-version":[{"id":159882,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/posts\/95518\/revisions\/159882"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/media?parent=95518"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/categories?post=95518"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/tags?post=95518"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}