Mysql replicatie werkt niet meer

[serienummer]

Hoi,
Ik ben redelijk nieuw met MySQL dus pak me niet te hard aan.
Ik ga het proberen zo makkelijk mogelijk uit te leggen.
Mocht je wat belangrijke informatie missen dan hoor ik dat graag.

Ik heb een vraag.
Ik heb 2 servers waarvan 1 server een failover server is.

Server 1 heeft een MySQL master, slave configuratie. Zodat als er geschreven wordt in de database dat dit meteen in server 2 wordt gezet.

Server 2 heeft ook een MySQL master, slave configuratie. Mocht er informatie van server 2 in de database komen gaat die meteen naar server 1.

Nu liep ik tegen het probleem aan dat de log bestanden "mysqld-relay-bin.000152" 1 gig per dag groot waren.
Dus met 2 weken was de schrijf vol.. Dus aan de google gegaan. Blijkbaar ben ik niet de enige, er zijn meer mensen die er last van hebben. Ergens wordt het advies gegeven dat je de bestanden gewoon kan verwijderen. Na enig doorzoeken zonder resultaat heb ik besloten om een aantal bestanden te verwijderen.
Vanaf dat moment werkt de replicatie niet meer. Ik krijg het ook niet meer aan de praat.

ALs ik het commando "START SLAVE; invoer krijg ik de volgende melding.

code:

ERROR 1201 (HY000): Could not initialize master info structure; more error messages can be found in the MySQL error log

Als ik de log uit lees staat er dit in:

code:

100205 11:26:32 [ERROR] log ./mysqld-relay-bin.000119 listed in the index, but failed to stat
100205 11:26:32 [ERROR] Error counting relay log space

Ik heb het volgende geprobeerd

code:

STOP SLAVE;
RESET SLAVE;
CHANGE MASTER TO MASTER_HOST=ipadres remote server;
MASTER_USER=username;
MASTER_PASSWORD=password;
MASTER_LOG_FILE=log_file;
MASTER_LOG_POS=log_position;
START SLAVE

Ik blijf de zelfde melding krijgen.

Service mysqld stop, start, restart.
server booten enz.

Ik krijg het niet meer aan de praat.
Ik hoop dat jullie een idee hebben, anders moet ik de server opnieuw installeren (4 dagen werk).

Alvast bedankt voor het meedenken

Groeten
Palermo

[cariolive23]

Voordat je verder gaat, ga eerst je backupprocedure controleren en zorg dat je dagelijks bruikbare backups maakt die je ook weer terug kunt zetten. Mocht er dan iets gruwelijk misgaan, dan heb je tenminste nog een backup waar je op kunt vertrouwen.

Verder kan ik je niet helpen met MySQL.

[Verwijderd]

Allereerst het verwijderen van binlog bestanden is niet heel handig, je zult dit selectief moeten doen. De slave herstarten kan uiteraard, maar je zult moeten zorgen dat je een bestaande binlog file opgeeft en de correcte positie.

Om een en andere weer aan de praat te krijgen zou ik je adviseren om eerst te zorgen dat Server 1 master is en dus de meest up-to-date versie heeft van de database. Dan Server 2 de slave inrichten. Daarna ditzelfde andersom te doen.

Je kunt oudere binlog files verwijderen die bijvoorbeeld de laatste x dagen niet zijn aangepast. Verder is het handig om je meer te gaan verdiepen in MySQL en replicatie als je dit soort zaken moet onderhouden. Replicatie is niet heel moeilijk, maar een beetje kennis en ervaring helpen je dit soort foutjes te voorkomen en replicatie sneller weer in de lucht te krijgen.

[Creepy]

Dit is gewoon een serversoftware probleem, geen programeer probleem. Dus ik verplaats je topic door naar Serversoftware en Windows Servers.

Je replicatie is afhankelijk van die binlogs! De binlog op je master server wordt doorgegeven aan de slave server en die speelt die binlog af. Als je de binlog hebt verwijderd die de slave aan het lezen was, dan heb je nu een aardig probleem. Met de tips van RavEn50 zou je dit weer moeten kunnen rechttrekken, mits je nog minstens 1 server hebt waar alle, correct, data instaat.

[silentsnake]

Heb je al je binlogs weggegooid? Want dan ben je wel een beetje de sjaak. Er vanuitgaande dat je data consistent is en dat je geen brakke tables heb, doe het volgende:

- Replicatie stoppen
- Dump maken op de master van al je databases en daarna je master stoppen. Een idee is om van te voren je databases te locken zodat er geen transactie meer plaats kan vinden.
- Je mysqldumps restoren op de slave
- Op de master het "reset master" commando geven. Dit zal wat errors geven omdat ie binlogs wil weggooien die niet meer bestaan.
- Master starten en kijken of de master een goede binlog aanmaakt
- Slave starten. Wellicht dat je daarvoor eerst de relay files moet weggooien, maar dat weet ik niet zeker.
- Check met een show slave status of je slave nu goed repliceert.

Je tables locken en je master database stoppen is belangrijk om er voor te zorgen dat de master en slave 100% in sync zijn. 1 row die niet consistent is kan er al voor zorgen dat de replicatie stopt.

En om dit probleem te verhelpen in de toekomst heb je een "expire_log_days" entry in de my.cnf. Hiermee zorgt MySQL er zelf voor dat je na een X aantal dagen de binlogs vanzelf op een nette manier opgeschoond worden. Wat je ook nog kan doen is het "PURGE BINARY LOGS TO 'filenaam'" commando gebruiken om op een nette manier je binary logs te purgen. Uiteraard niet doen als je slave achterloopt, anders heb je een probleem!

Oh en nog wat leesvoer:

http://dev.mysql.com/doc/...en/purge-binary-logs.html
http://dev.mysql.com/doc/refman/5.0/en/binary-log.html

Om maar een quote te doen van de bovenstaande links:

If you are using replication, you should not delete old binary log files on the master until you are sure that no slave still needs to use them. For example, if your slaves never run more than three days behind, once a day you can execute mysqladmin flush-logs on the master and then remove any logs that are more than three days old. You can remove the files manually, but it is preferable to use PURGE BINARY LOGS, which also safely updates the binary log index file for you (and which can take a date argument).

[ Voor 24% gewijzigd door silentsnake op 05-02-2010 21:15 ]

[serienummer]

Hoi,
Dank je wel voor de reacties..

Ik heb niet alle mysqld-relay-bin.xxx logs verwijderd. maar een aantal. Waar ik niet naar gekeken heb is of de files nog gebruikt werden. dat is niet zo slim Ik ben me er ook van bewust dat ik de fout heb gemaakt.
Ik probeer het ook nu weer recht te trekken (als dat nog kan).

cariolive23 schreef op vrijdag 05 februari 2010 @ 13:25:
Voordat je verder gaat, ga eerst je backupprocedure controleren en zorg dat je dagelijks bruikbare backups maakt die je ook weer terug kunt zetten. Mocht er dan iets gruwelijk misgaan, dan heb je tenminste nog een backup waar je op kunt vertrouwen.

Verder kan ik je niet helpen met MySQL.

Ik heb een script ingesteld dat hij dagelijks om 11:00 een back-up maakt van de SQL data.

Verwijderd schreef op vrijdag 05 februari 2010 @ 13:42:
Allereerst het verwijderen van binlog bestanden is niet heel handig, je zult dit selectief moeten doen. De slave herstarten kan uiteraard, maar je zult moeten zorgen dat je een bestaande binlog file opgeeft en de correcte positie.

Om een en andere weer aan de praat te krijgen zou ik je adviseren om eerst te zorgen dat Server 1 master is en dus de meest up-to-date versie heeft van de database. Dan Server 2 de slave inrichten. Daarna ditzelfde andersom te doen.

Je kunt oudere binlog files verwijderen die bijvoorbeeld de laatste x dagen niet zijn aangepast. Verder is het handig om je meer te gaan verdiepen in MySQL en replicatie als je dit soort zaken moet onderhouden. Replicatie is niet heel moeilijk, maar een beetje kennis en ervaring helpen je dit soort foutjes te voorkomen en replicatie sneller weer in de lucht te krijgen.

Server 1 is master en loopt gewoon door gelukkig werkt hij helemaal. Verdiepen is goed maar dan moet er wel geld voor zij en de baas loopt niet zo hard in deze periode.

silentsnake schreef op vrijdag 05 februari 2010 @ 20:56:
Heb je al je binlogs weggegooid? Want dan ben je wel een beetje de sjaak. Er vanuitgaande dat je data consistent is en dat je geen brakke tables heb, doe het volgende:

- Replicatie stoppen
- Dump maken op de master van al je databases en daarna je master stoppen. Een idee is om van te voren je databases te locken zodat er geen transactie meer plaats kan vinden.
- Je mysqldumps restoren op de slave
- Op de master het "reset master" commando geven. Dit zal wat errors geven omdat ie binlogs wil weggooien die niet meer bestaan.
- Master starten en kijken of de master een goede binlog aanmaakt
- Slave starten. Wellicht dat je daarvoor eerst de relay files moet weggooien, maar dat weet ik niet zeker.
- Check met een show slave status of je slave nu goed repliceert.

Alles loopt redelijk zoals je het beschreven heb alleen als ik de slave start op de de server 2 dan blijf ik de volgende melding krijgen..

code:

mysql> start slave;
ERROR 1201 (HY000): Could not initialize master info structure; more error messages can be found in the MySQL error log
mysql>

zelfs met het verwijderen van de gehele database en het herstarten van de server en dan de SQLdump van server 1 terug zetten dan werkt het nog niet...
Ik vraag me af waarom deze zo vast zit.. hij blijft maar vragen om een mysqld-relay-bin.000119

code:

log ./mysqld-relay-bin.000119 listed in the index, but failed to stat
Error counting relay log space

[cariolive23]

serienummer schreef op maandag 08 februari 2010 @ 11:53:
Ik heb een script ingesteld dat hij dagelijks om 11:00 een back-up maakt van de SQL data.

Dat is stap 1, dit wil nog helemaal niet zeggen dat er bruikbare backups beschikbaar zijn wanneer de pleuris uitbreekt. In de praktijk blijkt dat al snel 50% van alle backups niet binnen redelijke tijd een systeem weer online kunnen brengen, ze zijn dus redelijk waardeloos. Dat je een script hebt ingesteld, prachtig, maar dit zegt verder helemaal niets.

Ga dus testen of jouw backups wel bruikbaar zijn, jouw replica is bv. al niet bruikbaar (daar gaat het topic tenslotte over), daar hoef je dus geen redding van te verwachten.

[serienummer]

cariolive23 schreef op maandag 08 februari 2010 @ 13:09:
[...]

Dat is stap 1, dit wil nog helemaal niet zeggen dat er bruikbare backups beschikbaar zijn wanneer de pleuris uitbreekt. In de praktijk blijkt dat al snel 50% van alle backups niet binnen redelijke tijd een systeem weer online kunnen brengen, ze zijn dus redelijk waardeloos. Dat je een script hebt ingesteld, prachtig, maar dit zegt verder helemaal niets.

Ga dus testen of jouw backups wel bruikbaar zijn, jouw replica is bv. al niet bruikbaar (daar gaat het topic tenslotte over), daar hoef je dus geen redding van te verwachten.

Dit zou betekenen dat je elke dag de back-up moet testen. dat is een tijdrovende klus..

[cariolive23]

Niet elke dag, dat is ook wat overdreven maar je moet het wel regelmatig testen. Jouw replicatie heb je al naar de bliksem geholpen, de kans dat backups ook stuk gaan (bv. worden overschreven of op dezelfde schijf staan waar de database al staat) is dan ook vrij groot.

[alt-92]

serienummer schreef op maandag 08 februari 2010 @ 16:36:
Dit zou betekenen dat je elke dag de back-up moet testen.

Er is ook nog zoiets als een gulden middenweg, en dat is dat je ééns per maand je backup/restore met een Disaster Recovery test gaat controleren.
Je kan beter weten waar je aan toe bent voordat het een keer goed misgaat.

dat is een tijdrovende klus..

So? Alles from scratch weer op moeten zetten en je gegevens weer invoeren duurt nog langer.
Aan jou de keuze

[serienummer]

Probleem krijgen we niet opgelost.
Helaas. we installeren de server opnieuw.
Ik probeer nu de aanstichter te vinden van het probleem..
Dat is dat de bestanden te groot worden.

Silentsnake had al een tip gegeven om de data netjes te laten opruimen
Daarvoor heb ik het een en ander gevonden.

in etc/my.cnf heb ik het volgende gezet.
# The following can be used as easy to replay backup logs or for replication.
log_bin                 = /var/log/mysql/mysql-bin.log
# WARNING: Using expire_logs_days without bin_log crashes the server! See README 
expire_logs_days        = 5
max_binlog_size         = 5M

Maar helaas werkt het niet.
Heeft iemand een andere tip.