Blog

Waarom crashen databases en wat kunt u eraan doen?

Bent u ooit geconfronteerd met een databasecrash? De database-instellingen bestaan uit de systeemserverhardware en de softwarestack waarop het besturingssysteem en de andere vereiste softwarepakketten worden uitgevoerd. Een databaseserver en de bijbehorende containers en plug-ins draaien erop. Al deze samen zijn verbonden met de binnen- en buitenwereld via netwerkhardware en -software zoals firewalls, switches en routers.

Het lijkt misschien ideaal als zo'n complexe setup 24/7 zonder problemen of downtime draait, maar dat is bij een systeem- of databasebeheerder niet het geval. De reden is simpel, en de software- en hardwarenetwerken zijn niet 100 procent foutbestendig.

Er is een constante verandering in de interne en externe omgeving. In wezen komt er nieuwe software aan, bestaande software wordt bijgewerkt. Databasegroei, geheugengebruik, logbestanden en caches, groeiende buffers en al die uitdagingen die relevant zijn voor een dynamische omgeving, hebben ook betrekking op een database.

Van een database, het hostsysteem en het netwerk wordt verwacht dat ze nogal wat beveiligings- en onderhoudsroutines en protocollen zullen ondergaan die een uptime van 99, xx procent garanderen. Zelfs als er iets onverwachts gebeurt, moet de DBA de database zo vroeg mogelijk kunnen herstellen. Laten we in dit artikel de redenen bespreken die een databasecrash kunnen veroorzaken die de robuustheid van een database beïnvloedt.

Waarom crashen databases?

1. Weinig onderhoud aan scripts vóór implementatie

Hier zijn een paar redenen waarom dit kan gebeuren:

  1. Databases raken gedestabiliseerd wanneer er geen sleutels en indexen nodig zijn om redundantie en voortgangsreactietijd te elimineren.
  2.  Slechte prestaties als gevolg van de laatste upgrades van systeemsoftware en de database functioneert niet goed samen.
  3.  Mismanagement bij de planning van uw databaseconfiguratie.

2. De database staat op de verkeerde server

De race voor serverhosting is vandaag een nieuwe wedstrijd!

Het configureren van het systeem of het plannen van een upgrade kan verleidelijk lijken tegen een goedkoper tarief. Maar als u geen zorgvuldige strategie heeft, kunnen uw database en informatie op gedeelde servers terechtkomen, wat gebruikers kan weigeren wanneer het netwerk vol is in het gebruik van gedeelde bronnen. Een slechte query of configuratie, een defecte applicatieconfiguratie of een gecompromitteerde applicatie of database kunnen een paar redenen zijn waarom dit gebeurt.

Als gevolg hiervan heeft de database een tekort aan bronnen, inclusief geheugen en verwerking.

3. Onvriendelijke toepassing en vragen

Te veel of te trage zoekopdrachten zijn het gevolg van het feit dat de gegevensserver van uw toepassing niet correct is geprogrammeerd. Dit kan er ook toe leiden dat er traag of te veel zoekopdrachten worden uitgevoerd. Deze zoekopdrachten worden gedaan wanneer er onder of overmatig gebruik is van indexen en het samenvoegen van bidirectionele tabellen.

Dit resulteert op zijn beurt in verkwistende, defecte en zelfs afwezige indexen. Het komt allemaal neer op waardeloos kwaliteitsontwerp, slechte codering, slechte optimalisatievragen en een gebrek aan standaarden.

4. Hardware- en softwarefouten

Wat gebeurt er als er een host-serverhardware of een stroomstoring is? Uw databaseserver crasht! Is het geen nachtmerrie? Het kan van alles zijn zoals een hardwarestoring van de hostserver (processor, geheugenschijven, RAM, moederbord, netwerkhardware, enz.) Of een stroomstoring en een daaropvolgende servercrash kan een reden zijn voor het abrupt stoppen van de database, waardoor een crash ontstaat. Het geval is vergelijkbaar met de softwarefout die van invloed is op de threads en afhankelijkheidspakketprocessen van de databaseserver. Om dergelijke crashes te voorkomen, is het beter om kwaliteitshardware, een plan voor stroomback-up te waarborgen en een rigoureus systeembeheer te onderhouden.

5. Weinig geheugen en swapruimte

Waar haalt en gebruikt een database geheugen?

Het zijn caches, buffers en logbestanden zoals index- en gegevensbestanden. De databaseserver dupliceert gegevens uit gegevensbestanden in de databasebuffercache. Naarmate het gegevensvolume in de database toeneemt, neemt ook de informatie over het bestandssysteem toe.

In het geval dat in-memory resources niet worden toegewezen met een gelijke hoeveelheid geheugen, zal de database proberen SWAP-geheugen te bemachtigen. Als er niet genoeg SWAP-ruimte beschikbaar is, kan de databaseserver crashen of stoppen met werken vanwege een gebrek aan geheugen.

6. Corrupties en bestandsrechten

Beschadigde gegevens, indexbestanden of toestemmingsproblemen veroorzaken een aanzienlijk aantal databasecrashes. Er zijn ook andere redenen:

  1. Een database zonder nauwkeurige vergrendeling schrijft een gegevens of index en andere processen wijzigen deze. Databaseserverprocessen gebruiken dezelfde gegevensdirectory in het hostsysteem die geen ondersteuning biedt voor externe bestandsvergrendeling of juiste vergrendeling van het bestandssysteem. Dit kan de databaseservers uitschakelen.
  2. De databaseserver probeert mogelijk te lezen of te schrijven vanuit een gegevens- / indexbestand dat al gecrasht of beschadigd is.
  3.  Een defect stuk hardware beschadigt een gegevens- / indexbestand.

7. Geen deskundige DBA aan boord

Systemen zouden moeten falen als u geen proactieve DBA aan boord heeft die beschikt over vooruitziende blik en planningsoplossingen. Een DBA-aanbieder wordt verondersteld alles voor u te begeleiden. Ze kunnen uw systeembehoeften opschalen, de gegevensintegriteit controleren, problemen detecteren, de logboeken bewaken en de prestatieruimte optimaliseren.

Dit vereist constante planning en een kritische organisatie om systeemcrashes te voorkomen die zowel uw database als uw bedrijf ernstig kunnen beschadigen.

Afronden!

Om de bovengenoemde storingen te voorkomen, kiest u een DBA die u onmiddellijk resultaat kan opleveren. Zmanda's Zmanda Recovery Manager (ZRM) voor MySQL is een gebruiksvriendelijke, flexibele en robuuste back-up- en hersteloplossing die het leven van een databasebeheerder vereenvoudigt. Het kan machine-kritieke omgevingen voor transactieverwerking met een hoog volume met vertrouwen in iedereen beheren MySQL servers die draaien op Linux, Solaris, Windows en Mac Os.

Wacht niet tot uw systeem crasht of faalt! We zijn hier voor jou!

Laat een antwoord achter

nl_NLDutch
en_USEnglish fr_FRFrench it_ITItalian es_ESSpanish de_DEGerman pt_BRPortuguese sv_SESwedish tr_TRTurkish jaJapanese pl_PLPolish zh_TWChinese id_IDIndonesian ko_KRKorean ms_MYMalay thThai nl_NLDutch