Ang Mundo ng MySQL at MariaDB

Gabay sa MySQL Replication: Pag-setup, Mga Uri, at Pag-troubleshoot para sa Mataas na Availability

Mga aplikasyon / iba pa
目次

1. Ano ang MySQL Replication? Pangkalahatang-ideya at Mga Kaso ng Paggamit

Ang MySQL Replication ay isang tampok na nag-sinasabay ang isang kopya ng isang database sa isa pang server sa oras na totoong. Ito ay nagpapahusay ng redundancy ng database at performance. Sa ibaba, ipinapaliwanag namin nang detalyado kung saan ginagamit ang MySQL Replication at kung paano ito gumagana.

Pangkalahatang-ideya ng MySQL Replication

Ang MySQL Replication ay binubuo ng isang master server at isa o higit pang slave servers, na nagbabahagi ng nilalaman ng database sa maraming server. Sa partikular, ang master server ay nagsisirekord ng mga pag-update sa binary log, at ang slave server ay nagbabasa at nag-aaplay ng mga pag-update na iyon upang manatiling magkasabay. Ito ay nagbibigay-daan sa mga serbisyo na magpatuloy kahit na mabigo ang master server, sa pamamagitan ng paglipat sa isang slave server.

Mga Kaso ng Paggamit ng MySQL Replication

Ang MySQL Replication ay malawak na ginagamit sa mga sumusunod na senaryo:

  • High Availability : Bawasan ang downtime sa pamamagitan ng paglipat sa isang slave server sa oras ng pagkabigo.
  • Load Balancing : Ipagpahiwatig ang mga read-only queries sa mga slave servers upang mabawasan ang load sa master.
  • Data Protection and Backup : Dahil ang replication ay nagkukopya ng data sa oras na totoong, ito rin ay maaaring magsilbing solusyon sa backup.

Mga Uri ng Replication

Ang MySQL Replication ay may mga sumusunod na uri, depende sa kung paano nag-sinasabay ang data:

  • Asynchronous Replication : Ang master ay hindi naghihintay na kumpirmahin ng slave ang pagtanggap ng mga pag-update, na nagbibigay-daan sa mas mabilis na tugon. Gayunpaman, maaaring hindi makarating sa slave ang ilang data kung mangyari ang pagkabigo.
  • Semi-Synchronous Replication : Ang master ay naghihintay hanggang kumpirmahin ng hindi bababa sa isang slave ang pagtanggap ng data bago magpatuloy. Ito ay nagbibigay ng mas mataas na reliability ngunit maaaring bahagyang mas mabagal.

Sa susunod na seksyon, ipapaliwanag namin ang mga basicong konsepto ng MySQL Replication, kabilang ang binary logs at GTIDs.

2. Mga Basicong Konsepto ng MySQL Replication

Upang maunawaan ang MySQL Replication, mahalagang malaman ang papel ng binary log at GTID (Global Transaction ID), parehong tinitiyak ang tumpak na replication ng data.

Mga Papel ng Master at Slave

Sa MySQL Replication, ang master server at slave server ay may natatanging mga papel. Ang master ay nagsisirekord ng mga pag-update sa binary log at ipinamahagi ang mga ito sa mga slave. Ang slave server ay nag-aaplay ng mga log na ito upang i-update ang data nito, na nagpapanatili ng parehong estado tulad ng master.

Binary Log at Relay Log

Ang MySQL Replication ay umaasa sa dalawang pangunahing log:

  1. Binary Log
  • Ang binary log ay nagsisirekord ng mga pagbabago ng data (INSERT, UPDATE, DELETE, atbp.) sa master server. Ito ay tinitiyak na ang slave ay maaaring panatilihin ang parehong estado tulad ng master.
  1. Relay Log
  • Ang relay log ay naka-imbak sa slave server, na naglalaman ng binary log na natanggap mula sa master. Ang SQL thread ng slave ay nag-execute ng relay log na ito nang sunod-sunod upang mag-aplay ng mga pagbabago.

Ano ang GTID (Global Transaction ID)?

Ang GTID ay nagta-task ng natatanging ID sa bawat transaksyon, na tinitiyak ang consistency sa maraming slave. Sa GTID, hindi na kailangan ang pagsubaybay sa binary log position, at awtomatikong mag-aaplay lamang ang mga hindi pa na-aplay na transaksyon, na nagpapasimple sa pamamahala.

Mga Kalamangan ng GTID

  • Natatanging Pag-identify : May natatanging GTID ang bawat transaksyon, na ginagawang malinaw kung aling transaksyon ang na-aplay na.
  • Madaling Recovery : Pagkatapos ng restart, awtomatikong muling mag-aaplay lamang ang mga hindi pa na-aplay na transaksyon.
  • Epektibong Pamamahala : Ang GTID ay nagpapasimple sa pamamahala ng replication sa malalaking kapaligiran na may maraming slave.

Upang i-activate ang GTID, i-set ang gtid_mode=ON at enforce_gtid_consistency=ON sa parehong master at slave servers. Ito ay nag-a-activate ng GTID-based replication.

Sa susunod na seksyon, tatalakayin namin ang hakbang-hakbang na pag-set up ng MySQL Replication.

3. Mga Hakbang sa Pag-set Up ng MySQL Replication

Ang seksyong ito ay nagpapaliwanag kung paano i-configure ang MySQL Replication nang hakbang-hakbang. Sa pamamagitan ng pagsunod sa mga tagubilin na ito, maaari mong i-set up ang isang basicong master-slave environment at makamit ang oras na totoong data synchronization.

Konpigurasyon ng Master Server

Una, i-edit ang configuration file ng master server (karaniwang my.cnf o my.ini) upang i-activate ang binary logging at magtalaga ng server ID.

  1. I-edit ang Configuration File
  • Idagdag ang mga sumusunod na setting sa seksyon na [mysqld], at i-set ang isang natatanging server ID (hal., 1).
    [mysqld]
server-id=1
log-bin=mysql-bin
  • Ang server-id ay dapat na natatangi bawat server. Ang log-bin ay nag-e-enable ng binary logging.
  1. Lumikha ng isang Replication User
  • Lumikha ng isang replication user sa master server at bigyan ng kinakailangang privileges.
    CREATE USER 'repl'@'%' IDENTIFIED BY 'password';
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%';
FLUSH PRIVILEGES;
  • Ang user na ito ay kinakailangan para sa slave upang ma-access ang data ng master.
  1. Suriin ang Master Status
  • Suriin ang kasalukuyang binary log file at position, na kailangan para sa slave configuration.
    SHOW MASTER STATUS;
  • Ang mga halaga ng File at Position na ipapakita ay gagamitin kapag nagko-configure ng slave.

Slave Server Configuration

Susunod, i-edit ang slave server configuration file upang i-set ang isang natatanging server ID at tukuyin ang master information.

  1. I-edit ang Configuration File
  • Magtalaga ng isang natatanging server-id (hal., 2) sa slave server. Ang server ID ay dapat na iba sa master.
    [mysqld]
server-id=2
  • Karaniwang pinapagana rin ang read_only=ON upang maiwasan ang hindi sinasadyang writes sa slave.
  1. I-configure ang Master Information sa Slave
  • Patakbuhin ang sumusunod na command sa slave server, na tukoy ang master host, user, binary log file, at log position.
    CHANGE MASTER TO
    MASTER_HOST='master_host',
    MASTER_USER='repl',
    MASTER_PASSWORD='password',
    MASTER_LOG_FILE='mysql-bin.000001',
    MASTER_LOG_POS=123;
  • Gumamit ng mga halagang MASTER_LOG_FILE at MASTER_LOG_POS na nakuha mula sa output ng SHOW MASTER STATUS ng master.
  1. Simulan ang Replication
  • Patakbuhin ang sumusunod na command sa slave server upang simulan ang replication.
    START SLAVE;

Suriin ang Replication Status

I-verify kung gumagana nang tama ang replication sa pagitan ng master at slave.

  • Suriin ang Master Status
    SHOW MASTER STATUS;
  • Suriin ang Slave Status
    SHOW SLAVE STATUSG;
  • Kung parehong Slave_IO_Running at Slave_SQL_Running ay nagpapakita ng Yes, ang replication ay tumatakbo nang normal.

Sa susunod na seksyon, tatalakayin natin ang mga advanced configuration options para sa MySQL Replication, kabilang ang mga pagkakaiba sa pagitan ng asynchronous at semi-synchronous replication at GTID-based setups.

4. Mga Uri at Aplikasyon ng Replication

Ang MySQL Replication ay may dalawang pangunahing uri batay sa synchronization method: asynchronous replication at semi-synchronous replication. Ang pag-unawa sa mga pagkakaiba at kung kailan gagamitin ang bawat isa ay tumutulong upang i-optimize ang performance at reliability. Tinalakay din sa seksyong ito ang mga kalamangan ng paggamit ng GTID (Global Transaction Identifier) sa replication setups.

Mga Pagkakaiba sa Pagitan ng Asynchronous at Semi-Synchronous Replication

1. Asynchronous Replication

Sa asynchronous replication, ang master server ay agad na tumutugon sa client kapag natapos na ang transaction, nang hindi hinintay ang slave na i-apply ang update. Ito ay nagbibigay ng mahusay na responsiveness, na ginagawang angkop para sa load-balancing systems. Gayunpaman, kung mangyari ang pagkabigo, ang anumang transactions na hindi pa na-apply sa slave ay maaaring mawala.

2. Semi-Synchronous Replication

Sa semi-synchronous replication, ang master server ay naghihintay hanggang sa makatanggap ng data ang hindi bababa sa isang slave bago tumugon sa client. Ito ay nagpapabuti ng data consistency ngunit nagpapataas ng transaction response time dahil kailangang maghintay ang master ng confirmation. Ang semi-synchronous replication ay angkop para sa mga environment kung saan data consistency at reliability ang prayoridad.

Replication gamit ang GTID

Ang GTID (Global Transaction Identifier) ay nagtalaga ng isang natatanging ID sa bawat transaction, na nag-e-ensure ng consistency sa pagitan ng master at slave servers. Ang pagpapagana ng GTID ay nagpapasimple sa replication management kumpara sa tradisyunal na binary log position-based replication.

Mga Kalamangan ng GTID

  • Pinahusay na Konsistensi ng Data : Pinapayagan ng GTID ang slave na awtomatikong tukuyin ang mga hindi pa naipapatupad na transaksyon, na nagsisiguro ng konsistensi.
  • Pinadaling Pamamahala : Inaalis ng GTID ang pangangailangan na manu‑manong tukuyin ang mga posisyon ng binary log, na ginagawang mas madali ang mga operasyon ng failover at recovery.

Pag‑setup ng GTID Replication

Upang paganahin ang GTID, idagdag ang mga sumusunod na opsyon sa mga configuration file ng master at slave.

Konpigurasyon ng Master Server

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

Konpigurasyon ng Slave Server

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

Kapag na‑enable na ang GTID, ang pag‑setup ng replication sa slave gamit ang utos na CHANGE MASTER TO ay awtomatikong hahawakan ang GTID‑based replication.

Sa susunod na seksyon, ipapaliwanag namin ang mga praktis sa pagpapanatili at pagmamanman ng MySQL Replication.

5. Pagpapanatili at Pagmamanman ng Replication

Upang epektibong patakbuhin ang MySQL Replication, mahalaga ang regular na pagpapanatili at pagmamanman. Ang seksyong ito ay nagpapaliwanag kung paano i‑verify ang status ng replication at kung paano harapin ang mga karaniwang error.

Paano Suriin ang Status ng Replication

Gamitin ang mga sumusunod na utos upang subaybayan ang pagsasabay ng master at slave na mga server.

Suriin ang Status ng Master

Sa master server, patakbuhin ang SHOW MASTER STATUS upang makita ang kasalukuyang binary log file at posisyon. Ipinapakita nito ang mga pinakabagong update na ipapadala sa mga slave.

SHOW MASTER STATUS;

Kasama sa mga pangunahing field ang:

  • File : Pangalan ng kasalukuyang binary log file
  • Position : Kasalukuyang posisyon sa loob ng binary log
  • Binlog_Do_DB at Binlog_Ignore_DB : Mga database na kasama o hindi kasama sa replication

Suriin ang Status ng Slave

Sa slave server, patakbuhin ang SHOW SLAVE STATUS upang suriin ang kalusugan ng replication.

SHOW SLAVE STATUSG;

Kasama sa mga mahalagang field ang:

  • Slave_IO_Running at Slave_SQL_Running : Dapat parehong Yes kung maayos ang pag‑andar ng replication.
  • Seconds_Behind_Master : Nagpapakita kung gaano kalayo ang pagkaantala ng slave sa segundo. Sa ideal, dapat ito ay 0.

Pagsusuri ng Problema sa Replication

Kadalasang mga isyu sa replication ay kinabibilangan ng mga error sa koneksyon at hindi pagkakatugma ng data. Narito ang mga tipikal na kaso ng error at mga solusyon.

1. Mga Error sa Koneksyon

Kung ang Slave_IO_Running ay No, hindi makakonekta ang slave sa master. Maaaring solusyon ay:

  • Suriin ang Master Host/IP : Tiyaking tama ang nakatakdang address.
  • Mga Setting ng Firewall : Siguraduhing bukas at naa‑access ang port 3306.

2. Hindi Pagkakatugma ng Data

Kung may mga error na lumalabas sa Last_Error, maaaring hindi magkatugma ang data ng master at slave. Upang maresolba:

STOP SLAVE;
# Fix the data manually
START SLAVE;

Para sa malalaking hindi pagkakatugma, i‑resynchronize sa pamamagitan ng pag‑restore ng buong backup mula sa master.

3. Pagkaantala ng Replication

Ang pagkaantala ng replication ay maaaring dulot ng limitasyon sa hardware o mga isyu sa network sa slave. Ang pag‑upgrade ng hardware o pag‑optimize ng mga query ay maaaring magpabuti ng performance.

Ipapaliwanag ng susunod na seksyon ang mga karaniwang problema sa replication at ang kanilang detalyadong mga solusyon.

6. Karaniwang Isyu sa Replication at mga Solusyon

Maaaring lumitaw ang iba’t ibang isyu sa MySQL Replication. Ang seksyong ito ay naglalahad ng mga karaniwang problema at kung paano ito lutasin.

1. Napatigil ang Slave_IO_Running

Isyu: Kung ang Slave_IO_Running ay No, hindi makakonekta ang slave sa master.

Sanhi at mga Solusyon:

  • Mga Isyu sa Network : Suriin ang firewall at konektividad papunta sa master.
  • Maling Master Host/IP : I‑verify ang configuration ng CHANGE MASTER TO.
  • Pribilehiyo ng User : Tiyaking may tamang pahintulot ang replication user gamit ang GRANT REPLICATION SLAVE.

2. Hindi Pagkakatugma ng Data ng Slave

Isyu: Hindi magkatugma ang data sa pagitan ng master at slave.

Sanhi at mga Solusyon:

  • Manwal na Pag‑ayos : I‑stop ang slave, itama ang hindi magkatugmang data, pagkatapos ay i‑restart ang replication. STOP SLAVE; # Fix data START SLAVE;
  • Buong Resync : Para sa malubhang hindi pagkakatugma, i‑reimport ang backup mula sa master.

3. Pagkaantala ng Replication

Isyu: Ang Seconds_Behind_Master ay higit sa 0, na nangangahulugang ang slave ay nahuhuli.

Mga Sanhi at Solusyon:

  • Mga Limitasyon sa Hardware : I-upgrade ang mga specs ng slave server.
  • Pag-optimize ng Query : Pagbutihin ang mga index at query upang mabawasan ang oras ng pagproseso sa slave.

4. Mga Error sa Pribilehiyo ng Replication User

Isyu: Ang mga error sa Last_Error ay nagpapahiwatig ng kakulangan sa pribilehiyo.

Solusyon:

  • Magbigay ng Tamang Pribilehiyo : Tiyaking maayos ang mga karapatan sa replication. GRANT REPLICATION SLAVE ON *.* TO 'repl'@'slave_ip'; FLUSH PRIVILEGES;

5. Paglago ng Binary Log

Isyu: Ang mga binary log ng master ay lumalaki nang labis, kumukonsumo ng espasyo sa disk.

Solusyon:

  • Pag-ikot ng Log : Gamitin ang expire_logs_days upang awtomatikong tanggalin ang mga lumang log. SET GLOBAL expire_logs_days = 7; # Purge logs older than 7 days

Sa pamamagitan ng pag-unawa at paghahanda sa mga karaniwang problemang ito, maaaring mapanatili ng mga administrador ang matatag na operasyon ng replication.

7. Konklusyon

Ang MySQL Replication ay isang mahalagang tampok para matiyak ang pagkakakonsistente ng data at pagiging maaasahan ng sistema. Tinatalakay ng artikulong ito ang mga batayan ng replication, mga hakbang sa pag-setup, pagmamanman, at pag-troubleshoot. Narito ang buod ng mga pangunahing punto.

Mga Pangunahing Kaalaman

  1. Pumili ng Tamang Uri ng Replication
  • Ang asynchronous replication ay nag-aalok ng bilis at load balancing, habang ang semi-synchronous replication ay nagbibigay ng mas matibay na pagiging maaasahan. Pumili batay sa pangangailangan ng sistema.
  1. Gamitin ang GTID
  • Pinapasimple ng GTID ang replication sa pamamagitan ng pag-alis ng pangangailangang tukuyin ang mga posisyon ng binary log, na nagiging mahalaga para sa malalaking o kritikal na kapaligiran.
  1. Regular na Subaybayan ang Status
  • Gamitin ang SHOW MASTER STATUS at SHOW SLAVE STATUS nang madalas upang maagang matuklasan ang mga anomalya at mabawasan ang panganib.
  1. Kasanayan sa Pag-troubleshoot ng Master
  • Maging pamilyar sa paghawak ng mga isyu na partikular sa replication tulad ng mga error sa koneksyon, hindi pagkakatugma, at lag.
  1. Pamahalaan ang Binary Logs
  • Iwasan ang mga isyu sa paggamit ng disk sa pamamagitan ng pag-configure ng expire_logs_days at regular na pag-ikot ng mga log.

Ang MySQL Replication ay nangangailangan ng patuloy na pagmamanman at pagpapanatili, hindi lamang paunang pag-setup. Sa pamamagitan ng regular na pagsuri ng status at pag-aayos ng mga configuration kung kinakailangan, maaari kang magtayo at mapanatili ang isang lubos na maaasahang sistema ng database.

Sana ang gabay na ito ay makatulong sa iyong pag-unawa at pagpapatupad ng MySQL Replication nang epektibo, na nagtitiyak ng maayos at matatag na operasyon.