{"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\/sv\/blog\/administrirovanie\/istoriya-o-fizicheskom-udalenii-300-millionov-zapisej-v-mysql","title":{"rendered":"Historia om den fysiska borttagningen av 300 miljoner poster i MySQL","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Introduktion<\/h2>\n

\nHej. Jag \u00e4r ningenMe, webbutvecklare.<\/p>\n

Som titeln antyder, \u00e4r min ber\u00e4ttelse en ber\u00e4ttelse om fysiska borttagningar av 300 miljoner poster i MySQL.<\/p>\n

Jag blev intresserad av detta, s\u00e5 jag best\u00e4mde mig f\u00f6r att g\u00f6ra en p\u00e5minnelse (instruktion).<\/p>\n

B\u00f6rjan - Alert<\/h2>\n

\nI den batch servern<\/a>, som jag anv\u00e4nder och underh\u00e5ller, finns en regelbunden process som en g\u00e5ng om dagen samlar in data fr\u00e5n den senaste m\u00e5naden fr\u00e5n MySQL. <\/p>\n

Vanligtvis avslutas denna process p\u00e5 ungef\u00e4r 1 timme, men den h\u00e4r g\u00e5ngen avslutades den inte p\u00e5 7 eller 8 timmar, och alerten slutade inte dyka upp... <\/a><\/noindex><\/p>\n

S\u00f6ka efter orsaken<\/h2>\n

\nJag f\u00f6rs\u00f6kte starta om processen, kolla loggar, men s\u00e5g inget alarmerande.
\nFr\u00e5gan indexerades korrekt. Men n\u00e4r jag t\u00e4nkte p\u00e5 vad som gick fel ins\u00e5g jag att databasens storlek var ganska stor. <\/p>\n

hoge_table | 350'000'000 |<\/code><\/pre>\n
\n350 miljoner poster. Det verkar som om indexeringen fungerade korrekt, bara mycket l\u00e5ngsamt.<\/p>\n
Den n\u00f6dv\u00e4ndiga datainsamlingen f\u00f6r m\u00e5naden var cirka 12 000 000 poster. Det verkar som om select-kommandot tog mycket tid, och transaktionen fullf\u00f6ljdes l\u00e4nge. <\/p>\n
DB<\/h2>\n
\nDet h\u00e4r \u00e4r i grunden en tabell som v\u00e4xer med ungef\u00e4r 400 000 poster varje dag. Databasen skulle samla in data endast fr\u00e5n den senaste m\u00e5naden, vilket inneb\u00e4r att det var f\u00f6rv\u00e4ntat att den skulle klara av just denna m\u00e4ngd data, men tyv\u00e4rr var operationen f\u00f6r rotation inte aktiverad.<\/p>\n
Denna databas utvecklades inte av mig. Jag tog emot den fr\u00e5n en annan utvecklare, s\u00e5 det k\u00e4nns som en teknisk skuld. <\/p>\n
Det kom en tidpunkt n\u00e4r m\u00e4ngden dagligt tillagda data blev stor och till slut n\u00e5dde gr\u00e4nsen. Det \u00e4r rimligt att t\u00e4nka att man b\u00f6r dela upp s\u00e5dana stora datam\u00e4ngder, men tyv\u00e4rr gjordes detta inte.<\/p>\n
Och h\u00e4r gick jag in i bilden.<\/p>\n
Fix<\/h2>\n
\nDet skulle vara mer rationellt att minska sj\u00e4lva databasen och f\u00f6rkorta tiden f\u00f6r dess bearbetning, \u00e4n att f\u00f6r\u00e4ndra sj\u00e4lva logiken.<\/p>\n
Situationen borde f\u00f6r\u00e4ndras avsev\u00e4rt om jag raderar 300 miljoner poster, s\u00e5 jag best\u00e4mde mig f\u00f6r att g\u00f6ra just det... \u00c5h, jag trodde att det verkligen skulle fungera.<\/p>\n
\u00c5tg\u00e4rd 1<\/h2>\n
\nEfter att ha f\u00f6rberett en s\u00e4kerhetskopia, b\u00f6rjade jag \u00e4ntligen skicka f\u00f6rfr\u00e5gningar.<\/p>\n
\u201eSkickar f\u00f6rfr\u00e5gan\u201c<\/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
\u201cHm... Ingen respons. Kanske processen tar l\u00e5ng tid?\u201d \u2014 t\u00e4nkte jag, men av n\u00e5gon anledning kollade jag p\u00e5 grafana och s\u00e5g att diskbelastningen v\u00e4xte v\u00e4ldigt snabbt. 
\n\"Det k\u00e4nns farligt\" \u2014 t\u00e4nkte jag igen och stoppade omedelbart f\u00f6rfr\u00e5gan.<\/p>\n
Handling 2<\/h2>\n
\nEfter att ha analyserat allt ins\u00e5g jag att datavolymen var f\u00f6r stor f\u00f6r att radera allt p\u00e5 en g\u00e5ng.<\/p>\n
Jag besl\u00f6t mig f\u00f6r att skriva ett skript som kan ta bort ungef\u00e4r 1 000 000 poster och k\u00f6rde det.<\/p>\n
\u300cjag implementerar skriptet\u300d<\/p>\n
\"Nu b\u00f6r det verkligen fungera\", \u2014 t\u00e4nkte jag<\/p>\n
Handling 3<\/h2>\n
\nDen andra metoden fungerade, men visade sig vara mycket arbetsintensiv.
\nF\u00f6r att g\u00f6ra allt p\u00e5 ett ordnat s\u00e4tt, utan on\u00f6dig stress, skulle det ta ungef\u00e4r tv\u00e5 veckor. Men detta scenario uppfyllde inte tj\u00e4nstekraven, s\u00e5 jag var tvungen att ge upp det.<\/p>\n
S\u00e5 h\u00e4r \u00e4r vad jag besl\u00f6t mig f\u00f6r att g\u00f6ra:<\/p>\n
Kopiera tabellen och byta namn<\/h3>\n
\nFr\u00e5n f\u00f6reg\u00e5ende steg ins\u00e5g jag att borttagning av en s\u00e5 stor datavolym skapar en lika stor belastning. D\u00e4rf\u00f6r beslutade jag att skapa en ny tabell fr\u00e5n grunden med hj\u00e4lp av insert och flytta de data jag planerade att ta bort dit.<\/p>\n
| hoge_table     | 350'000'000|\n| tmp_hoge_table |  50'000'000|<\/code><\/pre>\n
\nOm jag skapar en ny tabell med samma storlek som angivet ovan, b\u00f6r hastigheten f\u00f6r databehandling ocks\u00e5 bli 1\/7 snabbare.<\/p>\n
Efter att ha skapat tabellen och bytt namn p\u00e5 den b\u00f6rjade jag anv\u00e4nda den som mastertabell. Nu, om jag tar bort tabellen med 300 miljoner poster, borde allt vara i ordning.
\nJag l\u00e4rde mig att truncate eller drop skapar mindre belastning \u00e4n delete och best\u00e4mde mig f\u00f6r att anv\u00e4nda det alternativet.<\/p>\n
Genomf\u00f6rande<\/h3>\n
\n\u201eSkickar f\u00f6rfr\u00e5gan\u201c<\/p>\n
INSERT INTO tmp_hoge_table SELECT FROM hoge_table create_time > 'YYYY-MM-DD HH:MM:SS';<\/code><\/pre>\n
\n\u300c…\u300d
\n\u300c…\u300d
\n\u300cem…\uff1f\u300d<\/p>\n
Handling 4<\/h2>\n
\nJag trodde att den f\u00f6reg\u00e5ende id\u00e9n skulle fungera, men efter att jag skickade insert-f\u00f6rfr\u00e5gan uppstod flera fel. MySQL visar ingen n\u00e5d.<\/p>\n
Jag var s\u00e5 tr\u00f6tt att jag b\u00f6rjade t\u00e4nka att jag inte ville g\u00f6ra detta l\u00e4ngre.<\/p>\n
Jag satte mig ner och ins\u00e5g att, kanske, f\u00f6r en enda g\u00e5ng var m\u00e4ngden insert-f\u00f6rfr\u00e5gningar f\u00f6r stor\u2026
\nJag f\u00f6rs\u00f6kte skicka en insert-f\u00f6rfr\u00e5gan p\u00e5 den datam\u00e4ngd som databasen borde hantera p\u00e5 en dag. Det lyckades!<\/p>\n
Och efter det forts\u00e4tter vi att skicka f\u00f6rfr\u00e5gningar med samma datam\u00e4ngd. Eftersom jag beh\u00f6ver ta bort en m\u00e5nads datam\u00e4ngd, upprepar vi denna operation ungef\u00e4r 35 g\u00e5nger.<\/p>\n
Byta namn p\u00e5 tabellen <\/h3>\n
\nH\u00e4r var turen p\u00e5 min sida: allt gick smidigt.<\/p>\n
Alert f\u00f6rsvann<\/h3>\n
\nHastigheten f\u00f6r batchbearbetningen \u00f6kade.<\/p>\n
Tidigare tog den h\u00e4r processen ungef\u00e4r en timme, nu tar det cirka 2 minuter. <\/p>\n
N\u00e4r jag hade s\u00e4kerst\u00e4llt att alla problem var l\u00f6sta, tog jag bort 300 miljoner poster. Jag raderade tabellen och k\u00e4nde mig som nyf\u00f6dd.<\/p>\n
Sammanfattning<\/h2>\n
\nJag ins\u00e5g att rotate processing hade missats under batchbearbetning, och det var den huvudsakliga problemet. Ett s\u00e5dant arkitektoniskt misstag leder till bortkastad tid. <\/p>\n
T\u00e4nker du p\u00e5 belastningen vid dat replication n\u00e4r du tar bort poster fr\u00e5n databasen? L\u00e5t oss inte \u00f6verbelasta MySQL.<\/p>\n
De som \u00e4r kunniga inom databaser kommer definitivt inte att m\u00f6ta ett s\u00e5dant problem. Jag hoppas att denna artikel har varit anv\u00e4ndbar f\u00f6r andra.<\/p>\n
Tack f\u00f6r att du l\u00e4ste!<\/p>\n
Vi skulle vara mycket glada om du ber\u00e4ttar f\u00f6r oss om du gillade denna artikel, om \u00f6vers\u00e4ttningen var tydlig, och om den var till hj\u00e4lp f\u00f6r dig?<\/i>
\n
K\u00e4lla: 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\udd47Ber\u00e4ttelsen om att fysiskt ta bort 300 miljoner poster i MySQL | ProHoster","description":"Introduktion Hej.","canonical_url":"https:\/\/prohoster.info\/sv\/blog\/administrirovanie\/istoriya-o-fizicheskom-udalenii-300-millionov-zapisej-v-mysql","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"sv_SE","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\/sv\/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\/sv\/wp-json\/wp\/v2\/posts\/95518","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/comments?post=95518"}],"version-history":[{"count":1,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/posts\/95518\/revisions"}],"predecessor-version":[{"id":159882,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/posts\/95518\/revisions\/159882"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/media?parent=95518"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/categories?post=95518"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/tags?post=95518"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}