Practical MySQL & MariaDB

Vysvětlení replikace MySQL: nastavení, GTID, monitorování a průvodce řešením problémů

Pokročilé / Ostatní
目次

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

MySQL replication je funkce, která synchronizuje kopie databáze na jiné servery v reálném čase. To zlepšuje redundanci databáze a výkon. Níže podrobně vysvětlujeme, kdy se replikace MySQL používá a jak funguje.

Přehled replikace MySQL

Replikace MySQL sdílí obsah databáze mezi více servery pomocí hlavního serveru a jednoho nebo více podřízených serverů. Konkrétně jsou aktualizace dat zaznamenané v binárním logu hlavního serveru čteny a aplikovány podřízenými servery, aby data zůstala synchronizována. To umožňuje kontinuitu služby přepnutím na podřízený server, pokud hlavní server narazí na selhání.

Případy použití replikace MySQL

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

  • Vysoká dostupnost : V případě selhání přepnutí na podřízený server minimalizuje dobu výpadku.
  • Vyvažování zátěže : Dotazy jen pro čtení lze distribuovat na podřízené servery, čímž se snižuje zátěž na hlavním serveru.
  • Ochrana dat a zálohování : Protože replikace duplikuje data v reálném čase, může také sloužit jako záložní mechanismus.

Typy replikace

Replikace MySQL zahrnuje následující typy podle metody synchronizace:

  • Asynchronní replikace : Hlavní server pokračuje bez čekání na potvrzení od podřízeného. To umožňuje rychlejší odezvu, ale může vést k tomu, že některá data nedojdou k podřízenému během selhání.
  • Polosynchronní replikace : Hlavní server čeká na potvrzení, že data byla podřízeným přijata, před tím než pokračuje. To poskytuje vyšší spolehlivost než asynchronní replikace, i když s mírně pomalejší odezvou.

Další sekce vysvětluje základní koncepty replikace MySQL, včetně binárních logů a GTID.

2. Základní koncepty replikace MySQL

Pro pochopení replikace MySQL je důležité pochopit role binárního logu a GTID (Global Transaction ID), které hrají klíčové role v procesu replikace. Tyto prvky tvoří základ pro 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 zaznamenává aktualizace dat do binárního logu a odesílá je podřízenému. Podřízený aplikuje přijaté logy k aktualizaci svých dat. Výsledkem je, že podřízený udržuje stejná data jako hlavní.

Binární log a relay log

Replikace MySQL se spoléhá na následující dva logy:

  1. Binární log
  • Binární log zaznamenává aktualizace dat (jako INSERT, UPDATE a DELETE) na hlavním serveru. To umožňuje podřízenému serveru udržovat stejný stav dat jako hlavní.
  1. Relay log
  • Relay log ukládá události binárního logu přijaté od hlavního serveru na podřízeném serveru. SQL vlákno podřízeného provádí relay log sekvenčně, aby aplikovalo změny dat.

Co je GTID (Global Transaction ID)?

GTID je mechanismus, který přiřazuje jedinečné ID každé transakci, pomáhá udržovat konzistenci napříč více podřízenými servery. Používáním GTID není nutné specifikovat pozice v binárním logu. Pouze transakce, které ještě nebyly získány z hlavního serveru, jsou automaticky aplikovány na podřízený, což výrazně zjednodušuje správu.

Výhody GTID

  • Jedinečná identifikace : Každé transakci je přiřazeno jedinečné GTID, jasně identifikující, které transakce byly aplikovány.
  • Snadnější obnovení : Při použití GTID jsou po restartu hlavního nebo podřízeného serveru znovu zpracovány pouze neaplikované transakce.
  • Efektivní provozní správa : I ve velkých prostředích s více podřízenými servery může být konzistence transakcí udržována se zjednodušenou správou.

Pro použití GTID jsou vyžadována nastavení gtid_mode=ON a enforce_gtid_consistency=ON. Konfigurace těchto nastavení na jak hlavním, tak podřízeném serveru umožňuje replikaci založenou na GTID.

Další sekce vysvětluje konkrétní kroky pro nastavení replikace MySQL.

3. Postup nastavení replikace MySQL

Tato sekce popisuje kroky potřebné k nastavení replikace MySQL. Po jejich provedení můžete nakonfigurovat základní strukturu master‑slave a povolit synchronizaci dat v reálném čase.

Konfigurace hlavního (master) serveru

Nejprve upravte konfigurační soubor hlavního serveru (obvykle my.cnf nebo my.ini), aby byl povolen binární log a nastaveno ID serveru.

  1. Upravit konfigurační soubor
  • Přidejte následující nastavení pod sekci [mysqld] a nastavte jedinečné ID serveru (například 1).
    [mysqld]
server-id=1
log-bin=mysql-bin
  • server-id musí být jedinečné číslo pro každý server a log-bin zapíná binární log.
  1. Vytvořit replikace uživatele
  • Vytvořte dedikovaného uživatele pro replikaci na hlavním serveru a přidělte mu potřebná oprávnění.
    CREATE USER 'repl'@'%' IDENTIFIED BY 'password';
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%';
FLUSH PRIVILEGES;
  • Tento uživatel je vyžadován, aby slave server mohl přistupovat k datům z masteru.
  1. Zkontrolovat stav masteru
  • Zjistěte aktuální soubor binárního logu a pozici (umístění logu). Tyto informace jsou potřeba při konfiguraci slave serveru.
    SHOW MASTER STATUS;
  • File (název log souboru) a Position zobrazené tímto příkazem budou použity v konfiguraci slave.

Konfigurace slave serveru

Dále upravte konfigurační soubor slave serveru a nastavte ID serveru a informace o masteru.

  1. Upravit konfigurační soubor
  • Nastavte jedinečné server-id i na slave serveru (například 2). Tato hodnota se musí lišit od ID serveru masteru.
    [mysqld]
server-id=2
  • Také je běžné nastavit read_only=ON, aby se zabránilo zápisu dat na slave serveru.
  1. Nastavit informace o masteru na slave
  • Proveďte následující příkaz na slave serveru a zadejte hostname masteru, uživatele, název souboru binárního logu a pozici.
    CHANGE MASTER TO
    MASTER_HOST='master_host',
    MASTER_USER='repl',
    MASTER_PASSWORD='password',
    MASTER_LOG_FILE='mysql-bin.000001',
    MASTER_LOG_POS=123;
  • Zadejte hodnoty potvrzené dříve na masteru pro MASTER_LOG_FILE a MASTER_LOG_POS.
  1. Spustit replikaci
  • Spusťte následující příkaz na slave serveru pro zahájení replikace.
    START SLAVE;

Ověření stavu replikace

Ověřte, že replikace mezi master a slave je nakonfigurována správně.

  • Zkontrolovat stav masteru
    SHOW MASTER STATUS;
  • Zkontrolovat stav slave
    SHOW SLAVE STATUS\G;
  • Pokud Slave_IO_Running i Slave_SQL_Running ukazují Yes, replikace funguje normálně.

Další sekce popisuje pokročilé konfigurace replikace, včetně rozdílů mezi asynchronní a semi‑synchronní replikací a nastavení pomocí GTID.

4. Typy replikace a pokročilé použití

Replikace MySQL zahrnuje dva hlavní typy podle metody synchronizace dat: asynchronní replikace a semi‑synchronní replikace. Pochopením jejich charakteristik a výběrem vhodného typu podle vašeho případu použití můžete zlepšit jak výkon systému, tak jeho spolehlivost. Tato sekce také vysvětluje výhody používání GTID (Global Transaction Identifier) pro konfiguraci replikace.

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

1. Asynchronní replikace

V asynchronní replikaci hlavní server (master) vrátí klientovi odpověď okamžitě po dokončení transakce. Jinými slovy, master může pokračovat ve zpracování nových požadavků, i když je synchronizace se slave serverem zpožděna. To poskytuje vynikající odezvu a je vhodné pro systémy zaměřené na rozložení zátěže. Avšak při selhání existuje riziko, že data, která ještě nebyla aplikována na slave, mohou být ztracena.

2. Semi‑synchronní replikace

In semi‑synchronní replikaci master server vrací odpověď klientovi až po potvrzení, že přenos dat na slave server byl dokončen. To zlepšuje konzistenci dat, ale protože čeká na slave, může se prodloužit doba odezvy transakcí. Semi‑synchronní replikace je vhodná pro systémy, které vyžadují vysokou konzistenci dat nebo prostředí, kde je spolehlivost dat nejvyšší prioritou.

Replikace pomocí GTID

GTID (Global Transaction Identifier) přiřazuje každé transakci jedinečný identifikátor a udržuje konzistenci transakcí mezi master a slave. Povolení GTID usnadň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 : S GTID může slave automaticky identifikovat transakce, které ještě nebyly aplikovány, což usnadňuje zachování konzistence.
  • Zjednodušená správa replikace : GTID zvyšuje efektivitu při failoveru, přepínání master/slave a úlohách obnovy. Protože již nemusíte zadávat pozice binárního logu, jsou operace jednodušší.

Konfigurace GTID replikace

Pro použití GTID musíte do konfiguračních souborů jak mastera, tak slave přidat a povolit následující volby.

Konfigurace master serveru

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

Konfigurace slave serveru

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

V prostředí s povoleným GTID se replikace provádí automaticky pomocí GTID pouhým nastavením informací o masteru na slave pomocí příkazu CHANGE MASTER TO.

Další sekce vysvětluje metody údržby MySQL replikace a klíčové body monitorování pro provozní správu.

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

Pro správný provoz MySQL replikace jsou nezbytné pravidelná údržba a monitorování. Tato sekce popisuje příkazy pro kontrolu, zda replikace funguje normálně, a jak řešit běžné chyby.

Jak zkontrolovat stav replikace

Použijte následující příkazy k ověření stavu synchronizace mezi masterem a slave.

Kontrola stavu mastera

Stav replikace master serveru můžete ověřit pomocí příkazu SHOW MASTER STATUS. Tento příkaz zobrazí aktuální název souboru binárního logu a pozici, což vám umožní potvrdit nejnovější aktualizace, které by měly být doručeny slave.

SHOW MASTER STATUS;

Výstup obvykle obsahuje následující pole:

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

Kontrola stavu slave

Stav replikace slave serveru můžete zkontrolovat pomocí příkazu SHOW SLAVE STATUS. Výsledky obsahují informace potřebné k určení, zda slave funguje správně.

SHOW SLAVE STATUS\G;

Klíčová pole zahrnují:

  • Slave_IO_Running a Slave_SQL_Running : Pokud jsou oba Yes, slave běží normálně.
  • Seconds_Behind_Master : Udává, jak daleko je slave za masterem (v sekundách). Ideálně by tato hodnota měla být 0.

Odstraňování problémů s replikací

Běžné problémy během provozu replikace zahrnují chyby připojení a nesoulad dat. Níže jsou typické případy chyb a jak je řešit.

1. Chyby připojení

Pokud je Slave_IO_Running No, znamená to, že slave se nemůže připojit k masteru. Zkuste následující:

  • Ověřte název hostitele nebo IP adresu mastera : Ujistěte se, že adresa mastera je správná.
  • Zkontrolujte nastavení firewallu : Ověřte, že požadovaný port (obvykle 3306) je otevřený.

2. Nesoulad dat

If Last_Error obsahuje chybovou zprávu, mohlo dojít k nesouladu dat mezi masterem a slaveem. V takových případech zastavte slave a aplikujte opravy před restartováním replikace.

STOP SLAVE;
# Restart after applying fixes
START SLAVE;

3. Snížení zpoždění replikace

Zpoždění replikace může být způsobeno omezeními hardwaru slave serveru nebo síťovými problémy. V případě potřeby může upgrade konfigurace slave serveru zlepšit výkon.

Další sekce podrobněji zkoumá problémy s replikací a poskytuje další řešení.

6. Běžné problémy a jejich řešení

Během provozu MySQL replikace se mohou objevit různé problémy. Tato sekce vysvětluje běžné problémy a jak je řešit. Včasné odhalení problémů a aplikace správných oprav pomáhá udržet stabilní provoz systému.

1. Když je Slave_IO_Running zastaven

Symptom: Pokud Slave_IO_Running ukazuje No ve výstupu SHOW SLAVE STATUS, slave se nemůže připojit k masteru.

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

  • Síťové problémy : Pokud existuje problém s konektivitou sítě, slave nemůže přistupovat k masteru. Zkontrolujte nastavení firewallu a potvrďte, že je master dosažitelný.
  • Nesprávný název hostitele nebo IP adresa mastera : Ověřte, že název hostitele nebo IP adresa uvedená v CHANGE MASTER TO je správná.
  • Problémy s oprávněními uživatele : Pokud replikační uživatel na masteru nemá dostatečná oprávnění, připojení selže. Potvrďte, že byla správná oprávnění udělena pomocí GRANT REPLICATION SLAVE .

2. Nesoulad dat na slave

Symptom: Pokud data neodpovídají mezi masterem a slaveem, slave může vstoupit do nekonzistentního stavu.

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

  • Manuální oprava dat : Zastavte slave, ručně opravte problematickou transakci a poté restartujte replikaci. STOP SLAVE; # Opravte data, pokud je to nutné START SLAVE;
  • Resynchronizace : Pokud je nesoulad rozsáhlý, vytvořte úplnou zálohu z masteru a resynchronizujte slave.

3. Zpoždění replikace

Symptom: Pokud Seconds_Behind_Master není 0 ve výstupu SHOW SLAVE STATUS, slave zaostává za masterem. Ideálně by tato hodnota měla být co nejblíže nule.

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

  • Omezení hardwaru slave : Pokud má slave server nedostatečné zdroje, nemusí držet krok. Upgrade hardwaru může být účinný.
  • Optimalizace dotazů : Pokud dotazy přijaté z masteru trvají na slave příliš dlouho, může dojít ke zpoždění replikace. Přidání indexů a optimalizace dotazů může snížit dobu zpracování.

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

Symptom: Pokud Last_Error zobrazuje zprávu související s oprávněním, slave možná nemá dostatečná oprávnění pro připojení k masteru.

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

  • Překonfigurujte oprávnění uživatele : Ujistěte se, že na masteru existuje uživatel s odpovídajícími oprávněními. Překonfigurujte jej v případě potřeby. GRANT REPLICATION SLAVE ON *.* TO 'repl'@'slave_ip_address'; FLUSH PRIVILEGES;

5. Růst binárního logu

Symptom: Binární logy masteru mohou nadměrně růst a zabírat diskový prostor.

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

  • Rotace binárních logů : Pravidelně odstraňujte nebo archivujte binární logy, aby nedocházelo k nadměrnému růstu. Nastavením expire_logs_days můžete automaticky odstraňovat logy starší než zadané období. SET GLOBAL expire_logs_days = 7; # Odstraňte logy starší než 7 dní

Pochopením těchto běžných problémů MySQL replikace a jejich řešení můžete zajistit plynulejší provozní správu. Další sekce shrnuje klíčové body pro správu replikace.

7. Závěr

MySQL replikace je kritickou funkcí pro zlepšení konzistence dat a spolehlivosti systému. V tomto článku jsme pokryli vše od základních konceptů MySQL replikace po postupy nastavení, monitorovací praktiky a metody řešení problémů. Níže je shrnutí klíčových bodů pro efektivní správu replikace.

Hlavní poznatky

  1. Výběr správného typu replikace
  • Asynchronní replikace poskytuje rychlejší odezvu a je ideální pro rozložení zátěže. Pokud je však prioritou spolehlivost, je vhodnější semi-synchronní replikace. Vyberte podle požadavků vašeho systému.
  1. Efektivní využití GTID
  • GTID eliminuje potřebu specifikovat pozice binárního logu a umožňuje plynulé řízení transakcí. Je zvláště užitečná v prostředích s více slave servery nebo tam, kde je kritický failover.
  1. Pravidelné monitorování stavu
  • Používejte SHOW MASTER STATUS a SHOW SLAVE STATUS k pravidelnému sledování provozního stavu jak master, tak slave serverů. Rychlý zásah při zjištění anomálií minimalizuje rizika, jako je nekonzistence dat nebo zpoždění.
  1. Zvládnutí základního řešení problémů
  • Běžné problémy s replikací zahrnují chyby připojení slave, nekonzistence dat a zpoždění. Porozumění základním řešením pro každý problém zajišťuje plynulejší provoz.
  1. Správa binárních logů
  • Protože binární logy mohou zabírat značné místo na disku, doporučuje se nastavit expire_logs_days pro automatické čištění a provádět pravidelnou údržbu.

MySQL replikace není jednorázová úloha nastavení. Kontinuální monitorování a řádná údržba jsou nezbytné. Pravidelným přezkoumáváním stavu systému a úpravou konfigurací podle potřeby můžete vybudovat a udržet vysoce spolehlivý databázový systém.

Doufáme, že tento průvodce vám pomůže lépe pochopit a implementovat MySQL replikaci. Přejeme vám plynulé a stabilní operace replikace.