Practical MySQL & MariaDB

Ufafanuzi wa Uiga wa MySQL: Mipangilio, GTID, Ufuatiliaji, na Mwongozo wa Utatuzi wa Tatizo

Ya Juu / Nyingine
目次

1. Nini Replication ya MySQL? Muhtasari na Matumizi

Ukurakaza wa MySQL ni kipengele kinachosawazisha nakala za hifadhidata kwenye seva nyingine kwa wakati halisi. Hii inaboresha upatikanaji wa nakala za hifadhidata na utendaji. Hapo chini, tunaelezea kwa undani wakati wa kurakaza wa MySQL hutumika na jinsi inavyofanya kazi.

Muhtasari wa Kurakaza ya MySQL

Ukurakaza wa MySQL hushiriki maudhui ya hifadhidata kati ya seva nyingi kwa kutumia master server na moja au zaidi ya slave servers. Hasa, masasisho ya data yanayotolewa katika logi ya binary ya master server husomwa na kutekelezwa na slave servers ili kudumisha data sawa. Hii inaruhusu uendelevu wa huduma kwa kubadilisha kwenda slave server ikiwa master server itakutana na hitilafu.

Matumizi ya Kurakaza ya MySQL

Ukurakaza wa MySQL hutumika sana katika hali zifuatazo:

  • High Availability : Katika tukio la hitilafu, kubadilisha kwenda slave server hupunguza muda wa kuzimwa.
  • Load Balancing : Maswali ya kusoma pekee yanaweza kusambazwa kwa slave servers, kupunguza mzigo kwenye master server.
  • Data Protection and Backup : Kwa sababu kurakaza hurepeta data kwa wakati halisi, inaweza pia kutumika kama mbinu ya nakala ya akiba.

Aina za Kurakaza

Ukurakaza wa MySQL unajumuisha aina zifuatazo kulingana na njia ya usawazishaji:

  • Asynchronous Replication : Master inaendelea bila kusubiri uthibitisho kutoka kwa slave. Hii inaruhusu majibu ya haraka lakini inaweza kusababisha baadhi ya data isifikie slave wakati wa hitilafu.
  • Semi-Synchronous Replication : Master husubiri uthibitisho kwamba data imepokelewa na slave kabla ya kuendelea. Hii inatoa uaminifu zaidi kuliko usawazishaji usio sambamba, ingawa na majibu ya polepole kidogo.

Sehemu ijayo inaelezea dhana za msingi za kurakaza ya MySQL, ikijumuisha logi za binary na GTID.

2. Dhana za Msingi za Kurakaza ya MySQL

Ili kuelewa kurakaza ya MySQL, ni muhimu kuelewa majukumu ya binary log na GTID (Global Transaction ID), ambayo yanacheza majukumu muhimu katika mchakato wa kurakaza. Vipengele hivi vinaunda msingi wa kurakaza sahihi ya data.

Majukumu ya Master na Slave

Katika kurakaza ya MySQL, master server na slave server wana majukumu tofauti. Master huhifadhi masasisho ya data katika binary log na kuyatuma kwa slave. Slave inatekeleza logi zilizopokelewa ili kusasisha data yake. Kwa hivyo, slave inahifadhi data sawa na master.

Binary Log na Relay Log

Ukurakaza wa MySQL hutegemea logi mbili zifuatazo:

  1. Binary Log
  • Binary log huhifadhi masasisho ya data (kama INSERT, UPDATE, na DELETE) kwenye master server. Hii inaruhusu slave server kudumisha hali ya data sawa na master.
  1. Relay Log
  • Relay log huhifadhi matukio ya binary log yaliyopokelewa kutoka kwa master kwenye slave server. Thread ya SQL ya slave inatekeleza relay log kwa mpangilio ili kutekeleza mabadiliko ya data.

Nini GTID (Global Transaction ID)?

GTID ni mbinu inayowapa kila muamala kitambulisho cha kipekee, ikisaidia kudumisha usawa kati ya slaves nyingi. Kwa kutumia GTID, kutaja nafasi za binary log hakuhitajiki. Ni muamala ambao bado haujapokelewa kutoka kwa master pekee ndio yanayotumika kiotomatiki kwenye slave, jambo linalorahisisha usimamizi sana.

Faida za GTID

  • Unique Identification : Kila muamala unapewa GTID ya kipekee, ikitambua wazi muamala uliotumika.
  • Easier Recovery : Unapotumia GTID, ni muamala usiotumika pekee ndogo unafanyiwa upya baada ya kuanzisha upya master au slave.
  • Efficient Operational Management : Hata katika mazingira makubwa yenye slaves nyingi, usawa wa muamala unaweza kudumishwa kwa usimamizi uliorahisishwa.

Ili kutumia GTID, mipangilio gtid_mode=ON na enforce_gtid_consistency=ON inahitajika. Kusanidi mipangilio hii kwenye master na slave kunaruhusu kurakaza kulingana na GTID.

Sehemu ijayo inaelezea hatua maalum za kuweka kurakaza ya MySQL.

3. Utaratibu wa Kusanidi Urejeshaji wa MySQL

Sehemu hii inaelezea hatua zinazohitajika ili kusanidi urejeshaji wa MySQL. Kwa kufuata hatua hizi, unaweza kusanidi muundo wa msingi wa master‑slave na kuwezesha usawazishaji wa data kwa wakati halisi.

Kusanidi Seva ya Master

Kwanza, hariri faili ya usanidi ya seva ya master (kwa kawaida my.cnf au my.ini) ili kuwezesha logi ya binary na kuweka kitambulisho cha seva.

  1. Hariri Faili ya Usanidi
  • Ongeza mipangilio ifuatayo chini ya sehemu ya [mysqld] na weka kitambulisho cha seva kilicho cha kipekee (kwa mfano, 1).
    [mysqld]
server-id=1
log-bin=mysql-bin
  • server-id lazima iwe nambari ya kipekee kwa kila seva, na log-bin inawasha logi ya binary.
  1. Unda Mtumiaji wa Urejeshaji
  • Unda mtumiaji maalum wa urejeshaji kwenye seva ya master na mpe ruhusa zinazohitajika.
    CREATE USER 'repl'@'%' IDENTIFIED BY 'password';
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%';
FLUSH PRIVILEGES;
  • Mtumiaji huyu unahitajika ili seva ya slave ipate data kutoka kwa master.
  1. Angalia Hali ya Master
  • Angalia faili ya logi ya binary ya sasa na nafasi yake (mahali pa logi). Taarifa hii inahitajika wakati wa kusanidi seva ya slave.
    SHOW MASTER STATUS;
  • File (jina la faili ya logi) na Position zinazotolewa na amri hii zitatumika katika usanidi wa slave.

Kusanidi Seva ya Slave

Ifuatayo, hariri faili ya usanidi ya seva ya slave na sanidi kitambulisho cha seva pamoja na taarifa za master.

  1. Hariri Faili ya Usanidi
  • Weka server-id ya kipekee kwenye seva ya slave pia (kwa mfano, 2). Thamani hii lazima itofautiane na kitambulisho cha seva ya master.
    [mysqld]
server-id=2
  • Pia ni kawaida kuweka read_only=ON ili kuzuia uandishi wa data kwenye seva ya slave.
  1. Sanidi Taarifa za Master kwenye Slave
  • Tekeleza amri ifuatayo kwenye seva ya slave, ukibainisha jina la host ya master, mtumiaji, jina la faili ya logi ya binary, na nafasi.
    CHANGE MASTER TO
    MASTER_HOST='master_host',
    MASTER_USER='repl',
    MASTER_PASSWORD='password',
    MASTER_LOG_FILE='mysql-bin.000001',
    MASTER_LOG_POS=123;
  • Weka thamani zilizothibitishwa awali kwenye master kwa MASTER_LOG_FILE na MASTER_LOG_POS .
  1. Anzisha Urejeshaji
  • Endesha amri ifuatayo kwenye seva ya slave ili kuanzisha urejeshaji.
    START SLAVE;

Kuthibitisha Hali ya Urejeshaji

Thibitisha kuwa urejeshaji kati ya master na slave umewekwa kwa usahihi.

  • Angalia Hali ya Master
    SHOW MASTER STATUS;
  • Angalia Hali ya Slave
    SHOW SLAVE STATUS\G;
  • Ikiwa Slave_IO_Running na Slave_SQL_Running zote zinaonyesha Yes, urejeshaji unafanya kazi kwa kawaida.

Sehemu ijayo inaelezea usanidi wa juu wa urejeshaji, ikijumuisha tofauti kati ya urejeshaji usio sambamba na urejeshaji usio sambamba kwa nusu, na usanidi kwa kutumia GTID.

4. Aina za Urejeshaji na Matumizi ya Juu

Urejeshaji wa MySQL una aina mbili kuu kulingana na njia ya usawazishaji wa data: urejeshaji usio sambamba na urejeshaji usio sambamba kwa nusu. Kwa kuelewa sifa zao na kuchagua kulingana na hali yako ya matumizi, unaweza kuboresha utendaji wa mfumo na uaminifu. Sehemu hii pia inaelezea faida za kutumia GTID (Kitambulisho cha Muamala wa Kimataifa) kwa usanidi wa urejeshaji.

Tofauti Kati ya Urejeshaji Usio Sambamba na Urejeshaji Usio Sambamba kwa Nusu

1. Urejeshaji Usio Sambamba

Katika urejeshaji usio sambamba, seva ya master hurudisha jibu kwa mteja mara baada ya kumaliza muamala. Kwa maneno mengine, master inaweza kuendelea kushughulikia maombi mapya hata wakati usawazishaji kwa seva ya slave umechelewa. Hii inatoa utendaji mzuri wa majibu na inafaa kwa mifumo inayolenga usambazaji wa mzigo. Hata hivyo, wakati wa kushindwa, kuna hatari kwamba data ambayo haijatumika bado kwenye seva ya slave itapotea.

2. Urejeshaji Usio Sambamba kwa Nusu

In replikasyon nusu-synchronous, seva ya master hurudisha jibu kwa mteja tu baada ya kuthibitisha kwamba uhamisho wa data kwa seva ya slave umekamilika. Hii inaboresha uthabiti wa data, lakini kwa sababu inangoshea slave, muda wa majibu ya miamala unaweza kuongezeka. Nusu-synchronous replication inafaa sana kwa mifumo inayohitaji uthabiti wa data wa juu au mazingira ambapo uaminifu wa data ni kipaumbele cha juu.

Replikasyon kwa kutumia GTID

GTID (Kitambulisho cha Muamala wa Kimataifa) inapeana kitambulisho cha kipekee kwa kila muamala na huhifadhi uthabiti wa muamala kati ya master na slave. Kuwezesha GTID hufanya usimamizi wa replikasyon kuwa rahisi zaidi ikilinganishwa na replikasyon ya jadi inayotegemea nafasi ya logi ya binary.

Faida za GTID

  • Uthabiti wa Data Ulioboreshwa : Kwa GTID, slave inaweza kiotomatiki kutambua miamala ambayo haijatumika bado, na kufanya iwe rahisi kudumisha uthabiti.
  • Usimamizi wa Replikasyon Ulio Rahisi : GTID huboresha ufanisi kwa ajili ya kushughulikia hitilafu, kubadilisha master/slave, na kazi za urejeshaji. Kwa kuwa huna haja tena ya kutaja nafasi za logi ya binary, operesheni zinakuwa rahisi.

Usanidi wa Replikasyon ya GTID

Ili kutumia GTID, lazima uongeze na uweke chaguo zifuatazo katika faili za usanidi za master na slave.

Usanidi wa Seva ya Master

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

Usanidi wa Seva ya Slave

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

Katika mazingira yaliyowezesha GTID, replikasyon inafanywa kiotomatiki kupitia GTID kwa kuweka tu taarifa za master kwenye slave kwa kutumia amri ya CHANGE MASTER TO.

Sehemu ijayo inaelezea mbinu za matengenezo ya replikasyon ya MySQL na pointi muhimu za ufuatiliaji kwa usimamizi wa uendeshaji.

5. Matengenezo na Ufuatiliaji wa Replikasyon

Ili kuendesha replikasyon ya MySQL ipasavyo, matengenezo na ufuatiliaji wa mara kwa mara ni muhimu. Sehemu hii inaelezea amri za kukagua kama replikasyon inafanya kazi kwa kawaida na jinsi ya kushughulikia makosa ya kawaida.

Jinsi ya Kukagua Hali ya Replikasyon

Tumia amri zifuatazo kukagua hali ya usawazishaji kati ya master na slave.

Kukagua Hali ya Master

Unaweza kuthibitisha hali ya replikasyon ya seva ya master kwa kutumia amri ya SHOW MASTER STATUS. Amri hii inaonyesha jina la faili ya logi ya binary ya sasa na nafasi yake, ikikuruhusu kuthibitisha masasisho ya hivi karibuni yanayopaswa kutumwa kwa slave.

SHOW MASTER STATUS;

Matokeo kwa kawaida yanajumuisha sehemu zifuatazo:

  • File : Jina la faili ya logi ya binary ya sasa iliyotengenezwa na master
  • Position : Nafasi ya sasa ndani ya logi ya binary
  • Binlog_Do_DB na Binlog_Ignore_DB : Hifadhidata zilizojumuishwa/kutojumuishwa katika replikasyon

Kukagua Hali ya Slave

Unaweza kukagua hali ya replikasyon ya seva ya slave kwa kutumia amri ya SHOW SLAVE STATUS. Matokeo yanajumuisha taarifa zinazohitajika ili kubaini kama slave inafanya kazi kwa usahihi.

SHOW SLAVE STATUS\G;

Sehemu muhimu ni pamoja na:

  • Slave_IO_Running na Slave_SQL_Running : Ikiwa zote mbili ni Yes, slave inafanya kazi kwa kawaida.
  • Seconds_Behind_Master : Inaonyesha slave imechelewa kwa kiasi gani kutoka kwa master (kwa sekunde). Kwa ideal, thamani hii inapaswa kuwa 0.

Utatuzi wa Makosa ya Replikasyon

Masuala ya kawaida wakati wa uendeshaji wa replikasyon yanajumuisha makosa ya muunganisho na kutokuwepo kwa usawa wa data. Hapo chini kuna kesi za makosa za kawaida na jinsi ya kuyashughulikia.

1. Makosa ya Muunganisho

Kama Slave_IO_Running ni No, ina maana slave haiwezi kuunganishwa na master. Jaribu yafuatayo:

  • Thibitisha jina la hosti au anwani ya IP ya master : Hakikisha anwani ya master ni sahihi.
  • Angalia mipangilio ya firewall : Thibitisha kuwa bandari inayohitajika (kwa kawaida 3306) imefunguliwa.

2. Kutokuwepo kwa Usawa wa Data

If Last_Error contains an error message, a data inconsistency may have occurred between the master and slave. In such cases, stop the slave and apply corrections before restarting replication.

STOP SLAVE;
# Restart after applying fixes
START SLAVE;

3. Kupunguza Chelewa ya Ureplikaji

Replication lag can be caused by slave hardware limitations or network issues. If needed, upgrading the slave server configuration can improve performance.

The next section explores replication troubles in more detail and provides further solutions.

6. Masuala ya Kawaida na Suluhisho Yake

During MySQL replication operation, various issues may arise. This section explains common problems and how to resolve them. Detecting issues early and applying the correct fixes helps maintain stable system operation.

1. Wakati Slave_IO_Running Imesimamishwa

Dalili: If Slave_IO_Running shows No in the output of SHOW SLAVE STATUS, the slave is unable to connect to the master.

Sababu na Suluhisho:

  • Matatizo ya Mtandao : If there is a network connectivity problem, the slave cannot access the master. Check firewall settings and confirm that the master is reachable.
  • Jina la Host la Master au Anwani ya IP Isiyo Sahihi : Verify that the hostname or IP address specified in CHANGE MASTER TO is correct.
  • Masuala ya Ruhusa za Mtumiaji : If the replication user on the master does not have sufficient privileges, the connection will fail. Confirm that the correct privileges have been granted using GRANT REPLICATION SLAVE .

2. Kutokuelewana kwa Data kwenye Slave

Dalili: If data does not match between the master and slave, the slave may enter an inconsistent state.

Sababu na Suluhisho:

  • Urekebishaji wa Data wa Mikono : Stop the slave, manually fix the problematic transaction, and then restart replication. STOP SLAVE; # Fix data if necessary START SLAVE;
  • Ulinganishaji Upya : If the inconsistency is large-scale, take a full backup from the master and resynchronize the slave.

3. Chelewa ya Ureplikaji

Dalili: If Seconds_Behind_Master is not 0 in the output of SHOW SLAVE STATUS, the slave is lagging behind the master. Ideally, this value should be as close to 0 as possible.

Sababu na Suluhisho:

  • Vikwazo vya Vifaa vya Slave : If the slave server has insufficient resources, it may not keep up. Upgrading hardware can be effective.
  • Uboreshaji wa Maswali : If queries received from the master take too long to execute on the slave, replication delay can occur. Adding indexes and optimizing queries can reduce processing time.

4. Makosa ya Ruhusa za Mtumiaji wa Ureplikaji

Dalili: If Last_Error shows a permission-related message, the slave may not have sufficient privileges to connect to the master.

Sababu na Suluhisho:

  • Sanidi Upya Ruhusa za Mtumiaji : Ensure that a user with appropriate privileges exists on the master. Reconfigure if necessary. GRANT REPLICATION SLAVE ON *.* TO 'repl'@'slave_ip_address'; FLUSH PRIVILEGES;

5. Ukuaji wa Logi ya Binary

Dalili: The master’s binary logs may grow excessively, consuming disk space.

Sababu na Suluhisho:

  • Uzungushaji wa Logi ya Binary : Regularly delete or archive binary logs to prevent excessive growth. By configuring expire_logs_days , you can automatically remove logs older than a specified period. SET GLOBAL expire_logs_days = 7; # Delete logs older than 7 days

By understanding these common MySQL replication issues and their solutions, you can ensure smoother operational management. The next section summarizes key points for replication management.

7. Hitimisho

MySQL replication ni kipengele muhimu kwa kuboresha uthabiti wa data na uaminifu wa mfumo. Katika makala hii, tulijifunza kila kitu kutoka dhana za msingi za ukurakaza wa MySQL hadi taratibu za usanidi, mbinu za ufuatiliaji, na njia za utatuzi wa matatizo. Hapo chini kuna muhtasari wa pointi kuu za usimamizi bora wa ukurakaza.

Mambo Muhimu

  1. Kuchagua Aina Sahihi ya Ukurakaza
  • Ukurakaza usio sambamba (asynchronous) hutoa majibu ya haraka zaidi na ni bora kwa usambazaji wa mzigo. Hata hivyo, ikiwa uaminifu ndicho kipaumbele, ukurakaza nusu‑sambamba (semi‑synchronous) ni sahihi zaidi. Chagua kulingana na mahitaji ya mfumo wako.
  1. Matumizi Mazuri ya GTID
  • GTID inaondoa haja ya kutaja nafasi za logi za binary na inaruhusu usimamizi laini wa miamala. Inafaa hasa katika mazingira yenye watumwa wengi (slaves) au ambapo uhamisho wa huduma (failover) ni muhimu.
  1. Ufuatiliaji wa Hali ya Mara kwa Mara
  • Tumia SHOW MASTER STATUS na SHOW SLAVE STATUS kufuatilia hali ya uendeshaji ya seva za master na slave kwa kawaida. Kuchukua hatua haraka baada ya kugundua hitilafu hupunguza hatari kama kutokubaliana kwa data au kuchelewa.
  1. Kukamilisha Utatuzi wa Matatizo ya Msingi
  • Masuala ya kawaida ya ukurakaza yanajumuisha makosa ya muunganisho wa slave, kutokubaliana kwa data, na ucheleweshaji. Kuelewa suluhisho za msingi kwa kila tatizo huhakikisha uendeshaji laini.
  1. Usimamizi wa Logi za Binary
  • Kwa kuwa logi za binary zinaweza kutumia nafasi kubwa ya diski, inashauriwa kusanidi expire_logs_days kwa usafi otomatiki na kufanya matengenezo ya mara kwa mara.

Ukurakaza wa MySQL si jukumu la usanidi mara moja. Ufuatiliaji wa mara kwa mara na matengenezo sahihi ni muhimu. Kwa kupitia hali ya mfumo kwa kawaida na kurekebisha usanidi inapohitajika, unaweza kujenga na kudumisha mfumo wa hifadhidata wenye uaminifu mkubwa.

Tunatumai mwongozo huu utakusaidia kuelewa na kutekeleza ukurakaza wa MySQL vizuri zaidi. Tunakutakia operesheni za ukurakaza zisizo na matatizo na thabiti.