Historia om den fysiska borttagningen av 300 miljoner poster i MySQL

Introduktion

Hej. Jag är ningenMe, webbutvecklare.

Som titeln antyder, är min berättelse en berättelse om fysiska borttagningar av 300 miljoner poster i MySQL.

Jag blev intresserad av detta, så jag bestämde mig för att göra en påminnelse (instruktion).

Början - Alert

I den batch servern, som jag använder och underhåller, finns en regelbunden process som en gång om dagen samlar in data från den senaste månaden från MySQL.

Vanligtvis avslutas denna process på ungefär 1 timme, men den här gången avslutades den inte på 7 eller 8 timmar, och alerten slutade inte dyka upp...

Söka efter orsaken

Jag försökte starta om processen, kolla loggar, men såg inget alarmerande.
Frågan indexerades korrekt. Men när jag tänkte på vad som gick fel insåg jag att databasens storlek var ganska stor.

hoge_table | 350'000'000 |

350 miljoner poster. Det verkar som om indexeringen fungerade korrekt, bara mycket långsamt.

Den nödvändiga datainsamlingen för månaden var cirka 12 000 000 poster. Det verkar som om select-kommandot tog mycket tid, och transaktionen fullföljdes länge.

DB

Det här är i grunden en tabell som växer med ungefär 400 000 poster varje dag. Databasen skulle samla in data endast från den senaste månaden, vilket innebär att det var förväntat att den skulle klara av just denna mängd data, men tyvärr var operationen för rotation inte aktiverad.

Denna databas utvecklades inte av mig. Jag tog emot den från en annan utvecklare, så det känns som en teknisk skuld.

Det kom en tidpunkt när mängden dagligt tillagda data blev stor och till slut nådde gränsen. Det är rimligt att tänka att man bör dela upp sådana stora datamängder, men tyvärr gjordes detta inte.

Och här gick jag in i bilden.

Fix

Det skulle vara mer rationellt att minska själva databasen och förkorta tiden för dess bearbetning, än att förändra själva logiken.

Situationen borde förändras avsevärt om jag raderar 300 miljoner poster, så jag bestämde mig för att göra just det... Åh, jag trodde att det verkligen skulle fungera.

Åtgärd 1

Efter att ha förberett en säkerhetskopia, började jag äntligen skicka förfrågningar.

„Skickar förfrågan“

DELETE FROM hoge_table WHERE create_time <= 'YYYY-MM-DD HH:MM:SS';

「…」

「…」

“Hm... Ingen respons. Kanske processen tar lång tid?” — tänkte jag, men av någon anledning kollade jag på grafana och såg att diskbelastningen växte väldigt snabbt.
"Det känns farligt" — tänkte jag igen och stoppade omedelbart förfrågan.

Handling 2

Efter att ha analyserat allt insåg jag att datavolymen var för stor för att radera allt på en gång.

Jag beslöt mig för att skriva ett skript som kan ta bort ungefär 1 000 000 poster och körde det.

「jag implementerar skriptet」

"Nu bör det verkligen fungera", — tänkte jag

Handling 3

Den andra metoden fungerade, men visade sig vara mycket arbetsintensiv.
För att göra allt på ett ordnat sätt, utan onödig stress, skulle det ta ungefär två veckor. Men detta scenario uppfyllde inte tjänstekraven, så jag var tvungen att ge upp det.

Så här är vad jag beslöt mig för att göra:

Kopiera tabellen och byta namn

Från föregående steg insåg jag att borttagning av en så stor datavolym skapar en lika stor belastning. Därför beslutade jag att skapa en ny tabell från grunden med hjälp av insert och flytta de data jag planerade att ta bort dit.

| hoge_table     | 350'000'000|
| tmp_hoge_table |  50'000'000|

Om jag skapar en ny tabell med samma storlek som angivet ovan, bör hastigheten för databehandling också bli 1/7 snabbare.

Efter att ha skapat tabellen och bytt namn på den började jag använda den som mastertabell. Nu, om jag tar bort tabellen med 300 miljoner poster, borde allt vara i ordning.
Jag lärde mig att truncate eller drop skapar mindre belastning än delete och bestämde mig för att använda det alternativet.

Genomförande

„Skickar förfrågan“

INSERT INTO tmp_hoge_table SELECT FROM hoge_table create_time > 'YYYY-MM-DD HH:MM:SS';

「…」
「…」
「eh…？」

Handling 4

Jag trodde att den föregående idén skulle fungera, men efter att jag skickade insert-förfrågan uppstod flera fel. MySQL visar ingen nåd.

Jag var så trött att jag började tänka att jag inte ville göra detta längre.

Jag satte mig ner och insåg att, kanske, för en enda gång var mängden insert-förfrågningar för stor…
Jag försökte skicka en insert-förfrågan på den datamängd som databasen borde hantera på en dag. Det lyckades!

Och efter det fortsätter vi att skicka förfrågningar med samma datamängd. Eftersom jag behöver ta bort en månads datamängd, upprepar vi denna operation ungefär 35 gånger.

Byta namn på tabellen

Här var turen på min sida: allt gick smidigt.

Alert försvann

Hastigheten för batchbearbetningen ökade.

Tidigare tog den här processen ungefär en timme, nu tar det cirka 2 minuter.

När jag hade säkerställt att alla problem var lösta, tog jag bort 300 miljoner poster. Jag raderade tabellen och kände mig som nyfödd.

Sammanfattning

Jag insåg att rotate processing hade missats under batchbearbetning, och det var den huvudsakliga problemet. Ett sådant arkitektoniskt misstag leder till bortkastad tid.

Tänker du på belastningen vid dat replication när du tar bort poster från databasen? Låt oss inte överbelasta MySQL.

De som är kunniga inom databaser kommer definitivt inte att möta ett sådant problem. Jag hoppas att denna artikel har varit användbar för andra.

Tack för att du läste!

Vi skulle vara mycket glada om du berättar för oss om du gillade denna artikel, om översättningen var tydlig, och om den var till hjälp för dig?

Källa: habr.com