da en en da en en sv da en et da da da da da da en en da da en en sv fr de de fr fr fr en el en en en en en en da da da da en ms zh oc te te da da da it da hi en da da it fr kn en da it id kn en da it ca kn en da it de kn en da da ja en en en da da en en sv fr de de fr fr fr en en en en en en en en da da da en en en da en da zh da da ja en en en da ja en en sv fr en en zh en da da da en da ja en en sv en en da en en sv fr de de fr el it en it en en da sl en sl da da ja en en en da da ja en ja da en da ja en en sv en en da pl en pl da da ja en en sv fr de en en en en da ja en en en en en da da da da da sv da nb nb en da da da da en nl da sv da en
MariaDB replikering: Når replikeringen fejler – NerdGirl
Forbud fører sjældent noget godt med sig
(Last Updated On: 2. marts 2018)
Slavens status viser ingen fejlmeddelelser
Hvis det er helt galt
Du har sikkert opdaget at din slave ikke længere replikerer ved at kigge på SHOW SLAVE STATUS, her et eksempel:
Slave_SQL_Running er “No”, den skal naturligvis helst stå til “Yes”.
Seconds_Behind_Master er “NULL”. Her skal der altid stå et tal.
Slave_SQL_Running_State bør ikke være tom.
Derudover er der i SHOW SLAVE STATUS også  information om IO og SQL fejl:
Her er det gået grueligt galt. Slaven er kommet så langt bagud, at den ikke kan indhente det tabte:
Got fatal error 1236 from master when reading data from binary log: ‘Could not find GTID state requested by slave in any binlog files. Probably te slave state is too old and required binlog files have been purged.’
Her er et par mindre fatale sql fejl. Når det opdages i tide, er det forholdsvist nemt at fikse.
På min master har jeg konfigureret at phpmyadmin databasen IKKE skal med i de binære logfiler. Men PhpMyAdmin har en kedelig uhensigtsmæssighed. Den glemmer at udføre USE phpmyadmin; før den arbejder med data. Derfor havner disse queries alligevel i loggen og læses af min slave… og da phpmyadmin databasen ikke eksisterer på min slave, fejler den:
Error ‘Table ‘phpmyadmin.pma_recent’ doesn’t exist’ on query. Default database: ”. Query: ‘REPLACE INTO phpmyadmin.pma_recent (username, tables) […]
Her er der et cronjob der tilsyneladene har en fejl et sted. I hvert fald forsøger den sig med en INSERT der forårsager en “Duplicate entry”:
Error ‘Duplicate entry ‘131954’ for key ‘PRIMARY” on query. Default database: ‘shop_live’. Query: ‘INSERT INTO Total (id, blocked, filtered) VALUES(‘131954′,’2′,0)’
Her forsøges opdateret en række, der ikke findes på slaven:
Could not execute Update_rows_v1 event on table shop_live.StatusDate; Can’t find record in ‘StatusDate’ […]
Nedenstående fejl har jeg oplevet 2 gange, hvor det begge gange var slavens binære log der var blevet korrupt. Læs mere her: MariaDB replikering: Korrupt binær log på slave
Relay log read failure: Could not parse relay log event entry. Te possible reasons are: te master’s binary […]
Når replikeringen stopper pga SQL fejl, kan du forsøge dig med at springe et par queries over. Den her virker for mig i de fleste tilfælde:
MariaDB> SET GLOBAL SQL_SLAVE_SKIP_COUNTER=2; START SLAVE;
MariaDB> SET GLOBAL SQL_SLAVE_SKIP_COUNTER=2; START SLAVE;
Hvis det ikke virker i første omgang, så prøv at forøge tallet. I ovennævnte eksempel vil replikeringen ignorere de 2 næste queries og derefter fortsætte som normalt. Slaven vil i løbet af kort tid indhente det forsømte. Se efter Seconds_Behind_Master som gerne skulle gå i 0 efter lidt tid.  Skip_Counter fortæller hvor mange queries den mangler at skippe. Men med så lavt et talt som 2, vil den meget hurtig gå i 0 igen.
Hvis der er fejl du ikke ønsker skal stoppe din replikering, kan du sætte slave-skip-errors i my.cnf. Her angiver du fejlkode(r) efter behov. Du kan se fejlkoden ud for Last_*_Errno i output fra SHOW SLAVE STATUS\G. Flere koder adskilles med komma:
MariaDB> FLUSH TABLES; /etc/mysql/my.cnf: slave-skip-errors = 1062,1146 # service mysql restart MariaDB> START SLAVE;
# service mysql restart
Men pas på. Fejl er indikationer på at der er noget galt i et eller andet program/script/job der kommunikerer med databasen, og bør derfor ikke ignoreres medmindre du ved hvad du gør.
Slavens status viser ingen fejlmeddelelser
Hvis der ikke er nogen fejlmeddelelser at se i output fra SHOW SLAVE STATUS skal du kigge i fejlloggen (som regel /var/log/mysql/error.log). Her et eksempel:
Failed to open te relay log './mysqld-relay-bin.000010' (relay_log_pos 104838338)
Failed to open te relay log './mysqld-relay-bin.000010' (relay_log_pos 104838338)
Slaven kan af en eller anden årsag ikke læse sin egen logfil og vi skal derfor tvinge den til at oprette en ny. Notér værdierne fra følgende felter i SHOW SLAVE STATUS\G:
den binære log på masteren som slaven er i gang med at læse fra
den position i ovenstående log slaven skal starte fra
Start med at nulstille slaven. Dette tvinger den til at oprette en ny logfil. Normalt vil man udføre en STOP SLAVE kommando først, men i dette tilfælde er slaven allerede stoppen pga. fejlen:
Nu er slaven nulstillet, og vi skal derfor fortælle den hvorfra den skal starte. Erstat værdierne i nedenstående med ovennævnte:
MariaDB> CHANGE MASTER TO master_log_file='mariadb-bin.000133', /* Relay_Master_Log_File */ master_log_pos=314603124; /* Exec_Master_Log_Pos */
MariaDB> CHANGE MASTER TO
master_log_file='mariadb-bin.000133', /* Relay_Master_Log_File */
master_log_pos=314603124; /* Exec_Master_Log_Pos */
Hvis det er helt galt
Når noget er gået helt galt og din slave er kommet så langt bagud, at det er håbløst at fikse, må du starte forfra. Det er ofte tilfældet når du støder på en Last_IO_Error.
Find et tidspunkt hvor ingen vigtige cronjobs kører og der er færrest brugere på systemet. Din master vil nemlig blive låst for både læsning og skrivning mens vi laver en backup.
Log på din master server. Lås den og notér dig herefter masterens position:
MariaDB> FLUSH TABLES WITH READ LOCK; MariaDB> SHOW MASTER STATUS\G;
MariaDB> FLUSH TABLES WITH READ LOCK;
MariaDB> SHOW MASTER STATUS\G;
*************************** 1. row *************************** File: mariadb-bin.000031 Position: 373046832 Binlog_Do_DB: Binlog_Ignore_DB: mysql,replication [...] 1 row in set (0.00 sec)
*************************** 1. row ***************************
1 row in set (0.00 sec)
Du må IKKE forlade din mysql prompt da dette vil frigøre din lås. Log derfor på i en anden session og lav din backup:
$ mysqldump -pkode -u bruger --add-drop-database --skip-triggers --routines --databases database1 database2 > masterdump.sql
$ mysqldump -pkode -u bruger --add-drop-database --skip-triggers --routines --databases database1 database2 > masterdump.sql
Det er vigtigt at du i ovenstående kun udvælger de databaser der normalt skrives til dine binære logfiler.
Gå derefter tilbage i din første session, og lås op igen:
Nu er der igen adgang og alt kører som normalt.
Kopiér dit dump til slaven, evt via scp:
$ scp masterdump.sql bruger@slaveserver.com:
$ scp masterdump.sql bruger@slaveserver.com:
Nu er vi færdige med din master.
Log ind på din slave som nu skal stoppes og nulstilles:
MariaDB> STOP SLAVE; MariaDB> RESET SLAVE;
I en anden session, kan du nu indlæse data fra masteren:
$ mysql -pkode -u bruger < masterdump.sql
$ mysql -pkode -u bruger < masterdump.sql
Ovenstående kan tage laaaaaang tid, afhængig af hvor meget data filen indeholder. Det tog mig omkring ½ time at indlæse en fil på 7GB. Hvis du er i tvivl om der overhovedet sker noget, så prøv at logge på databasen i en anden session og kør SHOW PROCESSLIST et par gange for at se at output ændrer sig.
Nu skal vi fortælle slaven fra hvilket tidspunkt den skal opdatere. Vi ændrer derfor filnavn og position med CHANGE_MASTER_TO og starter derefter slaven igen:
MariaDB> CHANGE MASTER TO master_log_file='mariadb-bin.000031', master_log_pos=373046832; MariaDB> START SLAVE;
MariaDB> CHANGE MASTER TO
Tjek status og se at alt kører som det skal:
MariaDB> SHOW SLAVE STATUS\G;
MariaDB> SHOW SLAVE STATUS\G;
Posted in Server Tagged gendan data, mariadb, slave
Konfigurering af L2TP VPN på Fedora 26
MariaDB replikering: Tjek af data
I gang med Angular 13 på Linux
Brug af grep kommandoen
Installer Asbru Connection Manager på Fedora
Installer DBeaver på Fedora
Node Package Manager (npm)
Linux: Afvikle en kommando som en anden bruger
MariaDB: Slå generel log til midlertidigt
Udskift nouveau driver med NVIDIA på Fedora 33 – og fortryd
Skab overblik over dine DMARC rapporter
Kategorier Vælg kategori Aftensmad Akrylmaling Bagværk Computer Dessert Fotografi Generelt Grød Hakket oksekød Hobby Hvidkål Ikke kategoriseret Internet IT Krop og sind PHP Pizza Politik Samfund Server Tips & Tricks Vegansk Webudvikling
Arkiver Vælg måned august 2022 april 2022 marts 2022 oktober 2021 maj 2021 marts 2021 februar 2021 januar 2021 december 2020 november 2020 oktober 2020 august 2020 juli 2020 juni 2020 marts 2020 januar 2020 december 2019 november 2019 oktober 2019 august 2019 juni 2019 april 2019 februar 2019 december 2018 oktober 2018 september 2018 juli 2018 juni 2018 maj 2018 april 2018 februar 2018 januar 2018 december 2017 oktober 2017 september 2017 august 2017 juli 2017 juni 2017 maj 2017 april 2017 januar 2017 december 2016 november 2016 oktober 2016 september 2016 januar 2016 december 2015 november 2015 oktober 2015 september 2015
Proudly powered by WordPress | Theme: chichi by xtianmark.