Svět MySQL & MariaDB

Průvodce replikací MySQL: nastavení, typy a řešení problémů pro vysokou dostupnost

Aplikace / Ostatní
目次

1. Co je replikace MySQL? Přehled a případy použití

Replikace MySQL je funkce, která synchronizuje kopii databáze na jiný server v reálném čase. Tím zvyšuje redundanci databáze i její výkon. Níže podrobně vysvětjeme, kde se replikace MySQL používá a jak funguje.

Přehled replikace MySQL

Replikace MySQL se skládá z hlavního serveru a jednoho nebo více podřízených serverů, které sdílejí obsah databáze napříč více servery. Konkrétně hlavní server zapisuje aktualizace do binárního logu a podřízený server čte a aplikuje tyto aktualizace, aby zůstal synchronizován. To umožňuje službám pokračovat i při selhání hlavního serveru přepnutím na podřízený server.

Případy použití replikace MySQL

Replikace MySQL se široce využívá v následujících scénářích:

  • Vysoká dostupnost – Minimalizuje prostoje přepnutím nařízený server v případě selhání.
  • Vyvažování zátěže – Distribuuje dotazy jen pro čtení na podřízené servery, čímž snižuje zátěž hlavního serveru.
  • Ochrana dat zálohování – Protože replikace kopíruje data v reálném, může sloužit i jako záložní řešení.

Typy replikace

Replikace MySQL má následující typy, podle toho, jak jsou data synchronizována:

  • Asynchronní replikace – Hlavní server nečeká, až podřízený potvrdí přijetí aktualizací, což umožňuje rychle odezvy. Některá data však mohou podřízenému nedorazit, pokud dojde k selhání.
  • Polosynchronní replikace – Hlavní server čeká, dokud alespoň jeden podřízený nepotvrdí přijetí dat, než pokračuje. To poskytuje vyšší spolehlivost, ale může být mírně pomalejší.

V další sekci vysvětlíme základnímy replikace MySQL, včetně binárních logů a GTID.

2. Základní pojmy replikace MySQL

Pro pochopení replikace MySQL je nezbytné znát roli binárního logu a GTID (Global Transaction ID), které zajišťují přesnou replikaci dat.

Role hlavního a podřízeného serveru

V replikaci MySQL mají hlavní server a podřízený server odlišné role. Hlavní server zapisuje aktualizace do binárního logu a distribuuje je podřízeným. Podřízený server aplikuje tyto logy, aby aktualizoval svá data a udržel stejný stav jako hlavní server.

Binární log a relay log

Replikace MySQL se opírá o dva klíčové logy:

  1. Binární log
  • Binární log zaznamenává změny dat (INSERT, UPDATE, DELETE atd.) na hlavním serveru. To umožňuje podřízenému udržet stejný jako hlavní server.
  1. Relay log
  • Relay log je uložen na podřízeném serveru a obsahuje binární log přijatý od hlavního serveru. SQL vlákno podřízeného serveru provádí tento relay log sekvenčně, aby aplikovalo změny.

Co je GTID (Global Transaction ID)?

GTID přiřazuje každé transakci jedinečné ID, čímž zajišťuje konzistenci napříč více podřízenými servery. S GTID není nutné sledovat pozici v binárním logu a pouze neaplikované transakce jsou automaticky aplikovány, což zjednodušuje správu.

Výhody GTID

  • Jedinečná identifikace – Každá transakce má jedinečný GTID, což jasně ukazuje, které transakce byly aplikovány.
  • Snadná obnova – Po restartu jsou automaticky znovu aplikovány jen neaplikované transakce.
  • Efektivní správa – GTID zjednodušuje správu replikace ve velkých prostředích s mnoha podřízenými servery.

Pro povolení GTID nastavte gtid_mode=ON a enforce_gtid_consistency=ON na hlavním i podřízeném serveru. Tím se aktivuje replikace založená na GTID.

V další sekci se podíváme na krok‑za‑krokem nastavení replikace MySQL.

3. Kroky pro nastavení replikace MySQL

Tato sekce popisuje, jak konfigurovat replikaci MySQL krok po kroku. Dodržením těchto instrukcí můžete vytvořit základní prostředí hlavní‑podřízený a dosáhnout synchronizace dat v reálném čase.

Konfigurace hlavního serveru

Nejprve upravte konfigurační soubor hlavního serveru (obvykle my.cnf nebo my.ini), abyste povolili binární logování a přiřadili ID serveru.

  1. Upravit konfigurační soubor
  • Přidejte následující nastavení do sekce [mysqld] a nastavte jedinečné ID serveru (např. 1).
    [mysqld]
server-id=1
log-bin=mysql-bin
  • server-id musí být jedinečné pro každý server. log-bin povoluje binární logování.
  1. Vytvořte uživatele pro replikaci
  • Vytvořte uživatele pro replikaci na hlavním serveru a udělte mu požadovaná oprávnění.
    CREATE USER 'repl'@'%' IDENTIFIED BY 'password';
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%';
FLUSH PRIVILEGES;
  • Tento uživatel je potřebný, aby slave mohl přistupovat k datům hlavního serveru.
  1. Zkontrolujte stav hlavního serveru
  • Zkontrolujte aktuální soubor binárního logu a pozici, které budou potřeba pro konfiguraci slave.
    SHOW MASTER STATUS;
  • Hodnoty File a Position, které jsou zobrazeny, budou použity při konfiguraci slave.

Konfigurace slave serveru

Dále upravte konfigurační soubor slave serveru tak, aby obsahoval jedinečné ID serveru a specifikoval informace o masteru.

  1. Upravte konfigurační soubor
  • Přiřaďte slave serveru jedinečné server-id (nap. 2). ID serveru se musí lišit od ID hlavního serveru.
    [mysqld]
server-id=2
  • Je také běžné povolit read_only=ON, aby se zabránilo neúmyslným zápisům na slave.
  1. Nastavte informace o masteru na slave
  • Spusťte následující příkaz na slave serveru a uveďte hostitele masteru, uživatele, soubor binárního logu a pozici logu.
    CHANGE MASTER TO
    MASTER_HOST='master_host',
    MASTER_USER='repl',
    MASTER_PASSWORD='password',
    MASTER_LOG_FILE='mysql-bin.000001',
    MASTER_LOG_POS=123;
  • Použijte hodnoty MASTER_LOG_FILE a MASTER_LOG_POS, získané z výstupu SHOW MASTER STATUS na masteru.
  1. Spusťte replikaci
  • Proveďte následující příkaz na slave serveru pro spuštění replikace.
    START SLAVE;

Zkontrolujte stav replikace

Ověřte, zda replikace mezi master a slave funguje správně.

  • Zkontrolujte stav masteru
    SHOW MASTER STATUS;
  • Zkontrolujte stav slave
    SHOW SLAVE STATUSG;
  • Pokud oba Slave_IO_Running a Slave_SQL_Running ukazují Yes, replikace běží normálně.

V další sekci prozkoumáme pokročilé konfigurační možnosti pro MySQL replikaci, včetně rozdílů mezi asynchronní a semi-synchronní replikací a nastaveními založenými na GTID.

4. Typy replikace a aplikace

MySQL replikace existuje ve dvou hlavních typech v závislosti na metodě synchronizace: asynchronní replikace a semi-synchronní replikace. Porozumění rozdílům a tomu, kdy který typ použít, pomáhá optimalizovat výkon a spolehlivost. Tato sekce také popisuje výhody používání GTID (Global Transaction Identifier) v replikacích.

Rozdíly mezi asynchronní a semi-synchronní replikací

1. Asynchronní replikace

V asynchronní replikaci hlavní server okamžitě odpoví klientovi po dokončení transakce, aniž čekal, až slave provede aktualizaci. To zajišťuje vynikající odezvu, což je vhodné pro systémy vyvažování zátěže. Nicméně, pokud dojde k selhání, mohou být ztraceny transakce, které ještě nebyly na slave aplikovány.

2. Semi-synchronní replikace

V semi-synchronní replikaci hlavní server čeká, dokud alespoň jeden slave neobdrží data, než odpoví klientovi. To zlepšuje konzistenci dat, ale zvyšuje dobu odezvy transakce, protože master musí čekat na potvrzení. Semi-synchronní replikace je ideální pro prostředí, kde jsou upřednostňovány konzistence dat a spolehlivost.

Replikace s GTID

GTID (Global Transaction Identifier) přiřazuje každé transakci jedinečné ID, což zajišťuje konzistenci mezi master a slave servery. Povolení GTID zjednodušuje správu replikace ve srovnání s tradiční replikací založenou na pozicích binárního logu.

Výhody GTID

  • Zlepšená konzistence dat : GTID umožňuje slave automaticky identifikovat nelikovanéakce, čímž zajišťuje konzistenci.
  • Zjednodušená správa : GTID odstraňuje potřebu ručně zadávat pozice binárního logu, což usnadňuje operace přepnutí a obnovy.

Nastavení replikace GTID

Pro povolení GTID přidejte následující volby do konfiguračních souborů mastera a slave.

Konfigurace serveru master

[mysqld]
server-id=1
log-bin=mysql-bin
gtid_mode=ON
enforce_gtid_consistency=ON

Konfigurace serveru slave

[mysqld]
server-id=2
gtid_mode=ON
enforce_gtid_consistency=ON
read_only=ON

Jakmile je GTID povoleno, nastavení replikace na slave pomocí příkazu CHANGE MASTER TO automaticky zvládne replikaci založenou na GTID.

V následující sekci vysvětlíme postupy údrž a monitorování MySQL replikace.

5. Údržba a monitorování replikace

Pro efektivní provoz MySQL replikace jsou nezbytné pravidelná údržba a monitorování. Tato sekce vysvětluje, jakěřit stav replikace a jak řešit běžné chyby.

Jak zkontrolovat stav replikace

Použijte následující příkazy k monitorování synchronizace mezi servery master a slave.

Kontrola stavu master

Na serveru master spusťte SHOW MASTER STATUS pro zobrazení aktuálního souboru binárního logu a pozice. To ukazuje nejnovější aktualizace, které budou odeslány slaveům.

SHOW MASTER STATUS;

Klíčová pole zahrnují:

  • File : Název aktuálního souboru binárního logu
  • Position : Aktuální pozice v binárním logu
  • Binlog_Do_DB a Binlog_Ignore_DB : Databáze zahrnuté nebo vyloučené z replikace

Kontrola stavu slave

Na serveru slave spusťte SHOW SLAVE STATUS pro kontrolu zdraví replikace.

SHOW SLAVE STATUSG;

Důležitá pole zahrnují:

  • Slave_IO_Running a Slave_SQL_Running : Obě by mě být Yes, pokud replikace fungujeálně.
  • Seconds_Behind_Master : Udává, jak daleko je slave pozadu v sekundách. Ideálně by mělo být 0.

Řešení problémů s replikací

Běžné problémy v replikaci zahrnují chyby připojení a nesoulad dat. Níže jsou typické případy chyb a řešení.

1. Chyby připojení

Pokud je Slave_IO_Running No, slave se nemůže připojit k masteru. Možná řešení zahrnují:

  • Ověřte hostitele/IP mastera : Ujistěte se, že je nastavená správná adresa.
  • Nastavení firewallu : Potvrďte, že port 3306 je otevřený a přístupný.

2. Nesoulad dat

Pokud se v Last_Error objeví chyby, může dojít k nesouladu dat mezi masterem a slave. Pro vyřešení:

STOP SLAVE;
# Fix the data manually
START SLAVE;

Pro velké nesoulady synchronizujte znovu obnovením úplné zálohy z.

3. Zpoždění replikace

Zpoždění replikace může být způsobeno omezeními hardware nebo sí Upgrade hardware nebo optimalizace dotazů může výkon zlepšit.

Následující sekce vysvětluje běžné problémy s replikací a jejich podrobná řešení.

6. Bné problémy s replikací a řešení

Různé problémy se mohou během MySQL replikace objevit. Tato sekce podrobně popisuje časté problémy a jak je řešit.

1. Slave_IO_Running je zastaven

Problém: Pokud je Slave_IO_Running No, slave se nemůže připojit k masteru.

Příčiny a řešení:

  • Síťové problémy : Zkontrolujte firewall a konektivitu k masteru.
  • Nesprávný hostitel/IP mastera : Ověřte konfiguraci CHANGE MASTER TO.
  • Uživatelská oprávnění : Ujistěte se, že replikační uživatel má správná oprávnění pomocí GRANT REPLICATION SLAVE .

2. Nesoulad dat na slave

Problém: Data se li mezi masterem a slave.

Příčiny a řešení:

  • Manuální oprava : Zastavte slave, opravte nesouladná data, poté restartujte replikaci. STOP SLAVE; # Opravit data START SLAVE;
  • Úplná resynchronizace : Pro vážné nesoulady importujte znovu zálohu z mastera.

3. Zpoždění replikace

Problém: Seconds_Behind_Master je větší než 0, což znamená, že slave je pozadu.

Příčiny a řešení:

  • Omezení hardwaru : Upgradujte specifikace slave serveru.
  • Optimalizace dotazů : Zlepšete indexy a dotazy, aby se snížil čas zpracování na slave.

4. Chyby v oprávněních uživatele replikace

Problém: Chyby v Last_Error naznačují nedostatečná oprávnění.

Řešení:

  • Udělte správná oprávnění : Zajistěte správná práva replikace. GRANT REPLICATION SLAVE ON *.* TO 'repl'@'slave_ip'; FLUSH PRIVILEGES;

5. Růst binárních logů

Problém: Binární logy mastera rostou nadměrně a spotřebovávají diskové místo.

Řešení:

  • Rotace logů : Použijte expire_logs_days k automatickému vyčištění starých logů. SET GLOBAL expire_logs_days = 7; # Purge logs older than 7 days

Pomocí porozumění a přípravy na tyto běžné problémy mohou administrátoři udržovat stabilní operace replikace.

7. Závěr

Replikace MySQL je nezbytnou funkcí pro zajištění konzistence dat a spolehlivosti systému. Tento článek pokryl základy replikace, postupy nastavení, monitorování a řešení problémů. Níže je rekapitulace klíčových bodů.

Klíčové poznámky

  1. Vyberte správný typ replikace
  • Asynchronní replikace nabízí rychlost a vyrovnávání zátěže, zatímco semi-synchronní replikace poskytuje silnější spolehlivost. Vyberte na základě požadavků systému.
  1. Využijte GTID
  • GTID zjednodušuje replikaci tím, že odstraňuje potřebu specifikovat pozice binárních logů, což je cenné pro velká nebo kritická prostředí.
  1. Pravidelně monitorujte stav
  • Používejte SHOW MASTER STATUS a SHOW SLAVE STATUS často k detekci anomálií včas a minimalizaci rizik.
  1. Ovladněte dovednosti řešení problémů
  • Buďte obeznámeni s řešením problémů specifických pro replikaci, jako jsou chyby připojení, nesrovnalosti a zpoždění.
  1. Spravujte binární logy
  • Zabraňte problémům s využitím disku konfigurací expire_logs_days a pravidelnou rotací logů.

Replikace MySQL vyžaduje kontinuální monitorování a údržbu, nejen počáteční nastavení. Pravidelným kontrolováním stavu a úpravou konfigurací podle potřeby můžete vybudovat a udržovat vysoce spolehlivý databázový systém.

Doufáme, že tento průvodce vám pomůže pochopit a implementovat replikaci MySQL efektivně, což zajistí plynulé a stabilní operace.