da en en da en en sv da en en da da da en da da en da en da da da en da en en sv fr de de fr en it en en de en da da da da ja en en sv fr de de fr en en en en en en da en da en en sv fr de en en en en da sv nb en da da da da en sv en da sv en en sv fr en da en da en da da ja en en sv fr de de fr fr ja en en en en nb en da ja en en sv fr zh en en en en sv fr de ja de uz en en en sv ja en ja en en sv zh en da en da en da da en sv en da hu en en en da en en sv en en da da en da en da da da da da da da da en en sv en en da da en en sv fr de de es en hy da ru da da da da da en ja zh en sv fr de ja en zh zh en da da da da da sv da nb nb en da da da da en nl da sv da en
MariaDB replikering: Tjek af data – NerdGirl
Forbud fører sjældent noget godt med sig
(Last Updated On: 16. december 2020)
Efter et stykke tid, vil du sikkert gerne vide om alt bliver replikeret korrekt til din slave og fikse eventuelle forskelle i data mellem master og slave. Her er percona-toolkit et rigtig godt værktøj
Bemærk i nedenstående kodeblokke: Når du ser ordet MASTER i første linje, skal blokken eksekveres på din master server, og vise versa når der står SLAVE.
Husk at replikere Percona databasen
Bug i version 3.0.4 – ?
Vi skal bruge to værktøjer, nemlig pt-table-checksum og pt-table-sync. Begge tools er tilgængelige i percona-toolkit
Læs evt. også her “Configuring percona repository on Debian and Ubuntu”
Opret en bruger til formålet. Denne bruger vil også blive brugt til at forbinde til din slave. Hvis du ikke replikerer mysql databasen, skal du derfor huske at oprette denne bruger både på master og slave. Bemærk at jeg opretter brugeren med ‘10.0.0%’  og ‘localhost’ for at sikre den kun kan opnå adgang fra det interne net:
GRANT REPLICATION SLAVE,REPLICATION CLIENT,PROCESS,SUPER, RELOAD, SELECT, INSERT, UPDATE ON *.* TO `pt_checksum`@'10.0.0%' IDENTIFIED BY 'checksum_password';
GRANT ALL PRIVILEGES ON percona.* TO `pt_checksum`@'10.0.0%';
GRANT REPLICATION SLAVE,REPLICATION CLIENT,PROCESS,SUPER, RELOAD, SELECT, INSERT, UPDATE ON *.* TO `pt_checksum`@'localhost' IDENTIFIED BY 'checksum_password';
GRANT ALL PRIVILEGES ON percona.* TO `pt_checksum`@'localhost';
Man kan sagtens give privilegier til en database der ikke er oprettet endnu. Databasen Percona oprettes automatisk første gang du afvikler pt-table-checksum.
Husk at replikere Percona databasen
Percona databasen oprettes automatisk af pt-table-checksum og du skal sikre den bliver replikeret. Jeg kom engang til at føje den til bin-ignore-db i masterens konfiguration. Det har den konsekvens at pt-table-checksum hænger i al evighed (indtil du stopper den selv) og spytter denne fejl ud:
Waiting for te --replicate table to replicate... Waiting for te --replicate table to replicate... Waiting for te --replicate table to replicate... Waiting for te --replicate table to replicate...
Waiting for te --replicate table to replicate...
Waiting for te --replicate table to replicate...
Waiting for te --replicate table to replicate...
Waiting for te --replicate table to replicate...
Slet Percona databasen på masteren
Fjern Percona fra bin-ignore-db
Sådan kunne det se ud når du tjekker din replikering for uoverensstemmelser i data mellem master og slave:
#MASTER pt-table-checksum --config master.conf --databases-regex=^firmanavn
pt-table-checksum --config master.conf --databases-regex=^firmanavn
Filen master.conf ser således ud:
user = pt_checksum password = hemmelig-kode host = localhost
Første gang jeg afprøvede ovennævnte, fik jeg et fantastisk fint resultat. Alt så ud til at være replikeret til slaven… Lige indtil jeg læste en af de første linjer:
pt-table-checksum diffs cannot be detected because no slaves were found
Det den fortæller her er, at den ikke kan konstatere forskel i data mellem master og slave, fordi den ganske enkelt ikke kan finde slaven.
Så først skal du sikre dig at pt-table-checksum kan få information om din slave via din master. Det skal helst se således ud:
/*MASTER*/ SHOW SLAVE HOSTS; +-----------+-----------+------+-----------+ | Server_id | Host | Port | Master_id | +-----------+-----------+------+-----------+ | 2 | 10.0.0.49 | 3306 | 1 | +-----------+-----------+------+-----------+
| Server_id | Host      | Port | Master_id |
| 2         | 10.0.0.49 | 3306 | 1         |
Hvis SHOW SLAVE HOSTS ikke returnerer noget information, skal du sætte report_host i my.cnf på slaven. Du sætter den til et hostnavn eller ip som kan bruges til at forbinde fra masteren:
/*SLAVE*/ STOP SLAVE; FLUSH TABLES;
#SLAVE my.cnf: [mysqld] report_host = 10.0.0.49
#SLAVE service mysql restart
Sådanne… vi prøver pt-table-checksum igen på masteren. Men ak og ve:
Replica [hostnavn] has binlog_format MIXED which could cause pt-table-checksum to break replication. Please read “Replicas using row-based replication” in te LIMITATIONS section of te tool’s documentation. If you understand te risks, specify –no-check-binlog-format to disable this check.
Og under LIMITATIONS finder vi følgende:
pt-table-checksum requires statement-based replication, and it sets binlog_format=STATEMENT on te master, but due to a MySQL limitation replicas do not honor this change. Therefore, checksums will not replicate past any replicas using row-based replication that are masters for further replicas.
Det her er altså kun et problem hvis min slave er “relay” for andre slaver. Det er ikke tilfældet, så jeg skulle roligt kunne tilføje --no-check-binlog-format:
#MASTER pt-table-checksum --config master.conf --databases-regex=^firmanavn --no-check-binlog-format
pt-table-checksum --config master.conf --databases-regex=^firmanavn --no-check-binlog-format
Replication filters are set on these hosts: [hostnavn]
Please read te –check-replication-filters documentation to learn how to solve this problem. at /usr/bin/pt-table-checksum line 9825.
Du kan læse om konsekvenserne ved brug af –no-check-replication-filters her. Det er ikke et problem for mit vedkommende:
#MASTER pt-table-checksum --config master.conf --databases-regex=^firmanavn --no-check-binlog-format --no-check-replication-filters
pt-table-checksum --config master.conf --databases-regex=^firmanavn --no-check-binlog-format --no-check-replication-filters
… og nu kører den 🙂
I output skal du holde øje med kolonnerne diff og skipped. De skulle gerne være 0 (nul) hele vejen igennem, medmindre der er difference i data mellem master og slave.
Bug i version 3.0.4 – ?
Fra og med pt-table-checksum version 3.0.4 kan du, såfremt output ikke viser fejl når den burde, være ramt af denne bug:
Løsningen er at tilføje --set-vars binlog_format=statement
Denne bug var stadig ikke løst sidst jeg tjekkede i september 2020, og eksisterer således stadig i version 3.2.1.
Se yderligere info i mit spørgsmål/svar på StackOverflow: https://stackoverflow.com/questions/4609…
Når du med pt-table-checksum har fundet differencer mellem master og slave, kan du udbedre det med pt-table-sync. Husk at vi her tager udgangspunkt i et simpelt master -> slave setup. Derudover forudsætter eksemplet her, at det er slaven der mangler data i forhold til masteren.
Find et tidspunkt hvor Seconds_Behind_Master er 0 (nul), hvis det er muligt.
Først beder jeg pt-table-sync om at skrive de sql queries der skal til for at slaven kan føres up-to-date. Jeg udelader --execute og bruger i stedet --print. Output skrives til en sql fil så jeg kan vurdere de ændringer pt-table-sync mener der skal til. Derefter kan jeg vælge at eksekvere filen. :
#MASTER pt-table-sync --print --sync-to-master --databases=shop_test,shop_prod h=10.0.0.49, F=./auth.cnf > sync.sql
pt-table-sync --print --sync-to-master --databases=shop_test,shop_prod h=10.0.0.49, F=./auth.cnf > sync.sql
Man bør ikke angive brugernavne og adgangskode på kommandolinien, og jeg har derfor disse oplysninger i auth.cnf som ser således ud:
#SLAVE - auth.cnf [client] user=pt_checksum password=hemmelig-kode host=10.0.0.49
Erstat 10.0.0.49 med den interne ip på din slave, eller slavens hostnavn. Erstat pt_checksum og hemmelig-kode med dine egne værdier for den bruger du oprettede.
Det kan godt se lidt underligt ud at host angives begge steder, men pt-table-sync insisterer på at der skal angives en host i kommandoen, og host i filen læses af mysql der bruges når data indlæses (Se næste afsnit).
Hvis --databases udelades vil den medtage alt. Du bør derfor angive de databaser der skal synkroniseres.
Indlæs data på slaven
På slaven kan du nu stoppe synkronisering midlertidigt, mens du indlæser data. Bemærk --default-character-set som jeg har medtaget fordi databasen i dette tilfælde har latin1 som standard karaktersæt. Uden den parameter vil fejlen “Incorrect string value” opstå når data indlæses.
#SLAVE mysql --defaults-extra-file=auth.cnf -e "STOP SLAVE;FLUSH TABLES" mysql --defaults-extra-file=auth.cnf --default-character-set='latin1' < sync.sql mysql --defaults-extra-file=auth.cnf -e "START SLAVE"
mysql --defaults-extra-file=auth.cnf -e "STOP SLAVE;FLUSH TABLES"
mysql --defaults-extra-file=auth.cnf --default-character-set='latin1' < sync.sql
mysql --defaults-extra-file=auth.cnf -e "START SLAVE"
Posted in Server Tagged mariadb, pt-table-checksum, pt-table-sync, replikering, slave, tjek
MariaDB replikering: Når replikeringen fejler
MariaDB replikering: Korrupt binær log på slave
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.