Practical MySQL & MariaDB

MySQL ප්‍රතිලේඛනය පැහැදිලි කිරීම: සැකසීම, GTID, නිරීක්ෂණය, සහ දෝෂ නිරාකරණ මාර්ගෝපදේශය

උසස් / අනෙකුත් (Advanced / Other)
目次

1. MySQL Replication යනු කුමක්ද? දළ විශ්ලේෂණය සහ භාවිතා කිරීම්

MySQL replication යනු ඩේටාබේස් පිටපතක් අනෙකුත් සේවාදායකවලට සංසන්දනය කරන විශේෂාංගයකි. මෙය ඩේටාබේස් අභිබවාය සහ කාර්ය සාධනය වැඩි දියුණු කරයි. පහතින්, MySQL replication භාවිතා වන විට සහ එය ක්‍රියා කරන ආකාරය විස්තරාත්මකව පැහැදිලි කරමු.

MySQL Replication හි දළ විශ්ලේෂණය

MySQL replication ප්‍රධාන සේවාදායකය (master server) සහ එකක් හෝ ඊට වැඩි සේවක සේවාදායකයින් (slave servers) භාවිතයෙන් ඩේටාබේස් අන්තර්ගතය බහු සේවාදායක අතර බෙදා හරින විශේෂාංගයකි. විශේෂයෙන්ම, ප්‍රධාන සේවාදායකයේ binary log හි ලියාපදිංචි කරන ලද දත්ත යාවත්කාලීන කිරීම් සේවක සේවාදායකයින් විසින් කියවා යෙදෙන අතර, දත්ත සංසන්දනය තබා ගැනීමට උපකාරී වේ. මෙය ප්‍රධාන සේවාදායකයේ දෝෂයක් ඇති වුවහොත් සේවක සේවාදායකයකට මාරු වීමෙන් සේවාවේ අඛණ්ඩතාවය සහතික කරයි.

MySQL Replication හි භාවිතා කිරීම්

MySQL replication පහත සිදුවීම්වලදී පුළුල් ලෙස භාවිතා වේ:

  • ඉහළ ලබාගැනීම් : දෝෂයක් ඇති වුවහොත්, සේවක සේවාදායකයකට මාරු වීමෙන් බාධාව අවම කරයි.
  • බර සමබර කිරීම : කියවීමට පමණක් විමසීම් සේවක සේවාදායකයින් වෙත ව්‍යාප්ත කළ හැකි අතර, ප්‍රධාන සේවාදායකයේ බර අඩු කරයි.
  • දත්ත ආරක්ෂණය සහ බැකප් : replication තත්ත්වයේදී දත්ත අනුකරණය කිරීම නිසා, එය බැකප් යාන්ත්‍රණයක් ලෙසද ක්‍රියා කළ හැක.

Replication හි වර්ග

MySQL replication සමකාලීනකරණ ක්‍රමය මත පහත වර්ග ඇතුළත් වේ:

  • අසමකාලීන Replication : ප්‍රධාන සේවාදායකය සේවකයෙන් තහවුරු කිරීම් බලාපොරොත්තු නොවී ඉදිරියට යයි. මෙය වේගවත් ප්‍රතිචාර කාල සපයන නමුත් දෝෂයක් ඇති වූ විට සමහර දත්ත සේවකයට නොපැමිණිය හැක.
  • අර්ධ-සමකාලීන Replication : ප්‍රධාන සේවාදායකය දත්ත සේවකය විසින් ලබාගත් බව තහවුරු කිරීම් බලාපොරොත්තු වේ. මෙය අසමකාලීන replication ට වඩා ඉහළ විශ්වාසනීයභාවය සපයන නමුත් තරමක් මන්දගාමී ප්‍රතිචාර කාල සමඟ.

ඊළඟ කොටස MySQL replication හි මූලික සංකල්ප, binary logs සහ GTID ඇතුළුව පැහැදිලි කරයි.

2. MySQL Replication හි මූලික සංකල්ප

MySQL replication තේරුම් ගැනීමට, binary log සහ GTID (Global Transaction ID) හි භූමිකා ග්‍රහණය කිරීම වැදගත් වේ, ඒවා replication ක්‍රියාවලියේ තීරණාත්මක භූමිකා ඉටු කරයි. මෙම අංග replication හි මූලධර්මීය පදනම සාදයි.

ප්‍රධාන සහ සේවක හි භූමිකා

MySQL replication හි, ප්‍රධාන සේවාදායකය (master server) සහ සේවක සේවාදායකය (slave server) වෙනස් භූමිකා ඇත. ප්‍රධාන සේවාදායකය දත්ත යාවත්කාලීන binary log හි ලියාපදිංචි කර සේවකයට යවයි. සේවකය ලබාගත් logs යෙදීමෙන් එහි දත්ත යාවත්කාලීන කරයි. ফলে, සේවකය ප්‍රධාන සේවාදායකයේ එලෙසම දත්ත තබා ගනී.

Binary Log සහ Relay Log

MySQL replication පහත දෙක logs මත රඳා පවතී:

  1. Binary Log
  • Binary log ප්‍රධාන සේවාදායකයේ දත්ත යාවත්කාලීන (INSERT, UPDATE, සහ DELETE වැනි) ලියාපදිංචි කරයි. මෙය සේවක සේවාදායකයට ප්‍රධාන සේවාදායකයේ එලෙසම දත්ත තත්ත්වය තබා ගැනීමට ඉඩ සලසයි.
  1. Relay Log
  • Relay log ප්‍රධාන සේවාදායකයෙන් ලබාගත් binary log සිදුවීම් සේවක සේවාදායකයේ ගබඩා කරයි. සේවකයේ SQL thread relay log අනුපිළිවෙලින් ක්‍රියාත්මක කර දත්ත වෙනස්කම් යෙදයි.

GTID (Global Transaction ID) යනු කුමක්ද?

GTID යනු ගනුදෙනුවක් සෑම එකකටම අනන්‍ය ID එකක් ප්‍රාණය කරන යාන්ත්‍රණයකි, එය බහු සේවකයින් අතර ස්ථිරභාවය තබා ගැනීමට උපකාරී වේ. GTID භාවිතයෙන් binary log පිහිටුම් විශේෂ කිරීම අනිවාර්ය නොවේ. ප්‍රධාන සේවාදායකයෙන් තවමත් ලබාගෙන නැති ගනුදෙනු පමණක් ස්වයංක්‍රීයව සේවකයට යෙදෙන අතර, කළමනාකරණය ඉතා සරල කරයි.

GTID හි වාසි

  • අනන්‍ය හඳුනාගැනීම : ගනුදෙනුවක් සෑම එකකටම අනන්‍ය GTID එකක් ප්‍රාණය වන අතර, යෙදූ ගනුදෙනු හඳුනාගැනීමට පැහැදිලිව උපකාරී වේ.
  • සරල පුනරුද්ධරණය : GTID භාවිතයෙන්, ප්‍රධාන හෝ සේවකයේ නැවත ආරම්භයෙන් පසු යෙද නොකළ ගනුදෙනු පමණක් නැවත ක්‍රියාත්මක වේ.
  • කාර්යක්ෂම මෙහෙයුම් කළමනාකරණය : බහු සේවකයින් සහිත විශාල පරිමාණ පරිසරවලදී පවා, ගනුදෙනු ස්ථිරභාවය සරල කළමනාකරණයෙන් තබා ගත හැක.

GTID භාවිතා කිරීමට gtid_mode=ON සහ enforce_gtid_consistency=ON සැකසුම් අවශ්‍ය වේ. මෙම සැකසුම් ප්‍රධාන සහ සේවකයේ සකස් කිරීමෙන් GTID මත පදනම් වූ replication සක්‍රිය වේ.

ඊළඟ කොටස MySQL replication සැකසීමේ නිශ්චිත පියවර පැහැදිලි කරයි.

3. MySQL Replication සැකසුම ක්‍රියාවලිය

මෙම කොටස MySQL replication සැකසීම සඳහා අවශ්‍ය පියවර පැහැදිලි කරයි. මෙම පියවර අනුගමනය කිරීමෙන්, ඔබට මූලික master-slave ව්‍යුහයක් සකස් කළ හැකි අතර, තත්‍කාලීන දත්ත සමකාලීනකරණය සක්‍රිය කළ හැකිය.

Master Server සැකසුම් කිරීම

පළමුව, master server හි සැකසුම් ගොනුව (සාමාන්‍යයෙන් my.cnf හෝ my.ini) සංස්කරණය කරන්න binary log සක්‍රිය කිරීමට සහ server ID සකස් කිරීමට.

  1. සැකසුම් ගොනුව සංස්කරණය කිරීම
  • [mysqld] කොටස යටතේ පහත සැකසුම් එකතු කරන්න සහ අනන්‍ය server ID එකක් සකස් කරන්න (උදාහරණයක් ලෙස, 1).
    [mysqld]
server-id=1
log-bin=mysql-bin
  • server-id එක server එකකට අනන්‍ය අංකයක් විය යුතුයි, සහ log-bin binary log සක්‍රිය කරයි.
  1. Replication පරිශීලකයක් සාදන්න
  • master server හි විශේෂ replication පරිශීලකයක් සාදන්න සහ අවශ්‍ය හිමිකම් ලබා දෙන්න.
    CREATE USER 'repl'@'%' IDENTIFIED BY 'password';
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%';
FLUSH PRIVILEGES;
  • මෙම පරිශීලකය slave server master වෙතින් දත්ත ප්‍රවේශ වීම සඳහා අවශ්‍ය වේ.
  1. Master Status පරීක්ෂා කිරීම
  • වත්මන් binary log ගොනුව සහ ස්ථානය (log ස්ථානය) පරීක්ෂා කරන්න. මෙම තොරතුරු slave server සැකසුම් කිරීමේදී අවශ්‍ය වේ.
    SHOW MASTER STATUS;
  • මෙම ප්‍රකාශනය මගින් පෙන්වන File (log ගොනුවේ නම) සහ Position slave සැකසුම්වල භාවිතා වේ.

Slave Server සැකසුම් කිරීම

ඊළඟට, slave server හි සැකසුම් ගොනුව සංස්කරණය කරන්න සහ server ID සහ master තොරතුරු සකස් කරන්න.

  1. සැකසුම් ගොනුව සංස්කරණය කිරීම
  • slave server හිදුත් අනන්‍ය server-id එකක් සකස් කරන්න (උදාහරණයක් ලෙස, 2). මෙම වටිනාකම master හි server ID වෙතින් වෙනස් විය යුතුයි.
    [mysqld]
server-id=2
  • slave server හි දත්ත ලිවීම් වැළැක්වීම සඳහා read_only=ON සකස් කිරීම සුලබයි.
  1. Slave හි Master තොරතුරු සකස් කිරීම
  • slave server හි පහත ප්‍රකාශනය ක්‍රියාත්මක කරන්න, master හි hostname, පරිශීලක, binary log ගොනුවේ නම සහ ස්ථානය විශේෂ කරමින්.
    CHANGE MASTER TO
    MASTER_HOST='master_host',
    MASTER_USER='repl',
    MASTER_PASSWORD='password',
    MASTER_LOG_FILE='mysql-bin.000001',
    MASTER_LOG_POS=123;
  • MASTER_LOG_FILE සහ MASTER_LOG_POS සඳහා master හිදුත් තහවුරු කළ වටිනාකම් ඇතුළත් කරන්න.
  1. Replication ආරම්භ කිරීම
  • slave server හි replication ආරම්භ කිරීම සඳහා පහත ප්‍රකාශනය ක්‍රියාත්මක කරන්න.
    START SLAVE;

Replication Status තහවුරු කිරීම

master සහ slave අතර replication නිවැරදිව සකස් වී ඇති බව තහවුරු කරන්න.

  • Master Status පරීක්ෂා කිරීම
    SHOW MASTER STATUS;
  • Slave Status පරීක්ෂා කිරීම
    SHOW SLAVE STATUS\G;
  • Slave_IO_Running සහ Slave_SQL_Running දෙකම Yes පෙන්වන්නේ නම්, replication සාමාන්‍යයෙන් ක්‍රියාත්මක වේ.

ඊළඟ කොටස asynchronous සහ semi-synchronous replication අතර වෙනස්කම් ඇතුළු උසස් replication සැකසුම් පැහැදිලි කරයි සහ GTID භාවිතයෙන් සැකසුම් කිරීම.

4. Replication වර්ග සහ උසස් භාවිතය

MySQL replication දත්ත සමකාලීනකරණ ක්‍රමය මත පදනම්ව ප්‍රධාන වර්ග දෙකක් ඇතුළත් වේ: asynchronous replication සහ semi-synchronous replication. ඒවායේ ලක්ෂණ තේරුම් ගැනීමෙන් සහ ඔබේ භාවිතය මත පදනම්ව තෝරා ගැනීමෙන්, ඔබට පද්ධතියේ කාර්ය සාධනය සහ විශ්වාසනීයභාවය දෙකම වැඩිදියුණු කළ හැකිය. මෙම කොටස GTID (Global Transaction Identifier) replication සැකසුම් සඳහා භාවිතා කිරීමේ වාසිද පැහැදිලි කරයි.

Asynchronous සහ Semi-Synchronous Replication අතර වෙනස්කම්

1. Asynchronous Replication

Asynchronous replication හි, master server transaction එකක් අවසන් කළ පසුව කෙලින්ම පරිශීලකයාට ප්‍රතිචාරයක් ලබා දෙයි. තවද, master slave server වෙත සමකාලීනකරණය ප්‍රමාද වූවද නව ඉල්ලීම් සැකසීමට පවා जारी තබා ගත හැකිය. මෙය විශිෂ්ට ප්‍රතිචාර කාර්ය සාධනයක් ලබා දෙයි සහ බර ව්‍යාප්තිය මත අවධානය යොමු කරන පද්ධති සඳහා සුදුසුයි. කෙසේ වෙතත්, දෝෂයකදී, slave server වෙත තවමත් යෙදූ නොකළ දත්ත නැති වීමේ අවදානමක් තිබේ.

2. Semi-Synchronous Replication

In semi-synchronous replication, the master server returns a response to the client only after confirming that data transfer to the slave server has completed. This improves data consistency, but because it waits for the slave, transaction response times may increase. Semi-synchronous replication is well suited for systems that require high data consistency or environments where data reliability is the top priority.

GTID භාවිතා කරමින් ප්‍රතිලේඛනය

GTID (ගෝලීය ගනුදෙනු හැඳුනුම්කරු) සෑම ගනුදෙනුවකටම අද්විතීය හැඳුනුමක් ලබා දී, මාස්ටර් සහ සලව් අතර ගනුදෙනු සමග්‍රහණය රැකගනී. GTID සක්‍රිය කිරීම, සම්ප්‍රදායික බයිනරි ලොග් ස්ථානය-අධාරිත ප්‍රතිලේඛනයට වඩා ප්‍රතිලේඛන කළමනාකරණය පහසු කරයි.

GTID හි වාසි

  • දත්ත සමග්‍රහණය වැඩිදියුණු කිරීම : GTID සමඟ, සලව් තවමත් යෙදවී නොමැති ගනුදෙනු ස්වයංක්‍රීයව හඳුනා ගත හැකි අතර, සමග්‍රහණය රැක ගැනීම පහසු වේ.
  • ප්‍රතිලේඛන කළමනාකරණය සරල කිරීම : GTID අසාර්ථකත්වය, මාස්ටර්/සලව් මාරු කිරීම, හා ප්‍රතිසාධන කාර්යයන් සඳහා කාර්යක්ෂමතාව වැඩි කරයි. ඔබට බයිනරි ලොග් ස්ථාන නිරූපණය කිරීමට අවශ්‍ය නොවීම නිසා මෙහෙයුම් සරල වේ.

GTID ප්‍රතිලේඛන වින්‍යාසය

GTID භාවිතා කිරීමට, මාස්ටර් සහ සලව් දෙකේම වින්‍යාස ගොනු වල පහත විකල්ප එක් කර සක්‍රිය කළ යුතුය.

මාස්ටර් සේවාදායක වින්‍යාසය

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

සලව් සේවාදායක වින්‍යාසය

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

GTID සක්‍රිය පරිසරයක, CHANGE MASTER TO විධානය භාවිතා කර සලව් මත මාස්ටර් තොරතුරු සකස් කිරීමෙන් GTID මගින් ප්‍රතිලේඛනය ස්වයංක්‍රීයව සිදු වේ.

ඊළඟ කොටස MySQL ප්‍රතිලේඛන නඩත්තු ක්‍රම සහ මෙහෙයුම් කළමනාකරණය සඳහා ප්‍රධාන නිරීක්ෂණ බින්දු පැහැදිලි කරයි.

5. ප්‍රතිලේඛන නඩත්තු සහ නිරීක්ෂණය

MySQL ප්‍රතිලේඛනය නිසි ලෙස ක්‍රියාත්මක කිරීම සඳහා, නිතර නඩත්තු සහ නිරීක්ෂණය අත්‍යවශ්‍ය වේ. මෙම කොටස ප්‍රතිලේඛනය සාමාන්‍ය ලෙස ක්‍රියා කරනවාදැයි පරීක්ෂා කිරීමේ විධාන සහ සාමාන්‍ය දෝෂ හසුරවීමේ ක්‍රම පැහැදිලි කරයි.

ප්‍රතිලේඛන තත්ත්වය පරීක්ෂා කිරීමේ ක්‍රම

මාස්ටර් සහ සලව් අතර සමමුහුර්ත තත්ත්වය පරීක්ෂා කිරීම සඳහා පහත විධාන භාවිතා කරන්න.

මාස්ටර් තත්ත්වය පරීක්ෂා කිරීම

SHOW MASTER STATUS විධානය භාවිතා කර ඔබට මාස්ටර් සේවාදායකයේ ප්‍රතිලේඛන තත්ත්වය තහවුරු කළ හැක. මෙම විධානය වත්මන් බයිනරි ලොග් ගොනුවේ නාමය සහ ස්ථානය පෙන්වයි, එමඟින් සලව් වෙත ලබා දිය යුතු නවතම යාවත්කාලීන කිරීම් තහවුරු කළ හැක.

SHOW MASTER STATUS;

ප්‍රතිඵලය සාමාන්‍යයෙන් පහත ක්ෂේත්‍ර ඇතුළත් කරයි:

  • File : මාස්ටර් විසින් ජනනය කරන ලද වත්මන් බයිනරි ලොග් ගොනුවේ නාමය
  • Position : බයිනරි ලොග් තුළ වත්මන් ස්ථානය
  • Binlog_Do_DB සහ Binlog_Ignore_DB : ප්‍රතිලේඛනයට ඇතුළත්/බැහැර කරන දත්ත ගබඩා

සලව් තත්ත්වය පරීක්ෂා කිරීම

SHOW SLAVE STATUS විධානය භාවිතා කර ඔබට සලව් සේවාදායකයේ ප්‍රතිලේඛන තත්ත්වය පරීක්ෂා කළ හැක. ප්‍රතිඵලය සලව් නිවැරදිව ක්‍රියා කරනවාදැයි තීරණය කිරීමට අවශ්‍ය තොරතුරු ඇතුළත් කරයි.

SHOW SLAVE STATUS\G;

ප්‍රධාන ක්ෂේත්‍ර ඇතුළත් වේ:

  • Slave_IO_Running සහ Slave_SQL_Running : දෙකම Yes නම්, සලව් සාමාන්‍යව ක්‍රියා කරයි.
  • Seconds_Behind_Master : සලව් මාස්ටර්ට පසුබැසී ඇති කාලය (තත්පර වලින්) පෙන්වයි. ඉතා හොඳින්, මෙම අගය 0 විය යුතුය.

ප්‍රතිලේඛන ගැටළු නිරාකරණය

සාමාන්‍ය ගැටළු අතර සම්බන්ධතා දෝෂ සහ දත්ත අසමතුලිතතා ඇතුළත් වේ. පහත සාමාන්‍ය දෝෂ අවස්ථා සහ ඒවාට ප්‍රතිකාර ලබා දෙන ආකාරය දැක්වේ.

1. සම්බන්ධතා දෝෂ

Slave_IO_Running No නම්, සලව් මාස්ටර්ට සම්බන්ධ වීමට නොහැකි බවයි. පහත කරුණු පරීක්ෂා කරන්න:

  • මාස්ටර් හෝස්ට් නාමය හෝ IP ලිපිනය තහවුරු කරන්න : මාස්ටර් ලිපිනය නිවැරදි බවට සහතික වන්න.
  • ෆයර්වෝල් සැකසුම් පරීක්ෂා කරන්න : අවශ්‍ය පෝට් (සාමාන්‍යයෙන් 3306) විවෘත බව තහවුරු කරන්න.

2. දත්ත අසමතුලිතතාව

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. ප්‍රතිපිළිවෙළ පසුබැසීම අඩු කිරීම

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. පොදු ගැටළු සහ ඒවායේ විසඳුම්

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. Slave_IO_Running නවතී ඇති විට

Symptom: SHOW SLAVE STATUS ප්‍රතිඵලයේ Slave_IO_Running No ලෙස පෙන්වන්නේ නම්, අනුකාරකය ප්‍රධාන සේවාදායකයට සම්බන්ධ වීමට නොහැක.

Causes and Solutions:

  • Network Issues : ජාල සම්බන්ධතා ගැටළුවක් ඇති නම්, අනුකාරකය ප්‍රධාන සේවාදායකයට ප්‍රවේශ වීමට නොහැක. ගිනුම් බාධක (firewall) සැකසුම් පරීක්ෂා කර ප්‍රධාන සේවාදායකය ලැබිය හැකිදැයි තහවුරු කරන්න.
  • Incorrect Master Hostname or IP Address : CHANGE MASTER TO තුළ සඳහන් කරන ලද හෝස්ට් නාමය හෝ IP ලිපිනය නිවැරදිදැයි පරීක්ෂා කරන්න.
  • User Privilege Issues : ප්‍රධාන සේවාදායකයේ ප්‍රතිපිළිවෙළ පරිශීලකයාට ප්‍රමාණවත් අවසර නොමැති නම්, සම්බන්ධතාවය අසාර්ථක වේ. GRANT REPLICATION SLAVE භාවිතයෙන් නිවැරදි අවසර ලබා දී ඇතිදැයි තහවුරු කරන්න.

2. අනුකාරකයේ දත්ත අසමතුලිතතාව

Symptom: ප්‍රධාන සහ අනුකාරක අතර දත්ත නොගැලපේ නම්, අනුකාරකය අසමතුලිත තත්ත්වයකට පත්විය හැක.

Causes and Solutions:

  • Manual Data Correction : අනුකාරකය නවතා, ගැටළුව ඇති ගනුදෙනුව අතින් සකස් කර, පසු ප්‍රතිපිළිවෙළ නැවත ආරම්භ කරන්න. STOP SLAVE; # අවශ්‍ය නම් දත්ත සකසන්න START SLAVE;
  • Resynchronization : අසමතුලිතතාව විශාල නම්, ප්‍රධාන සේවාදායකයෙන් සම්පූර්ණ පිටපතක් ගෙන, අනුකාරකය නැවත සමමුහුර්ත කරගන්න.

3. ප්‍රතිපිළිවෙළ ප්‍රමාදය

Symptom: SHOW SLAVE STATUS ප්‍රතිඵලයේ Seconds_Behind_Master 0 නොවන විට, අනුකාරකය ප්‍රධාන සේවාදායකයට පසුබැසී ඇත. ඉතා හොඳින්, මෙම අගය 0 ට සමීප විය යුතුය.

Causes and Solutions:

  • Slave Hardware Limitations : අනුකාරක සේවාදායකයට ප්‍රමාණවත් සම්පත් නොමැති නම්, එය පසුබැසී යා හැක. දෘඩාංග උත්සාහ කිරීම ප්‍රයෝජනවත් වේ.
  • Query Optimization : ප්‍රධාන සේවාදායකයෙන් ලැබෙන විමසුම් අනුකාරකයේ ක්‍රියාත්මක වීමට බොහෝ කාලයක් ගත වුවහොත්, ප්‍රතිපිළිවෙළ ප්‍රමාදයක් සිදුවේ. දර්ශක (index) එකතු කිරීම සහ විමසුම් සුදානම් කිරීමෙන් සැකසුම් කාලය අඩු කළ හැක.

4. ප්‍රතිපිළිවෙළ පරිශීලක අවසර දෝෂ

Symptom: Last_Error හි අවසර-සම්බන්ධ පණිවිඩයක් පෙන්වන්නේ නම්, අනුකාරකයට ප්‍රධාන සේවාදායකයට සම්බන්ධ වීමට ප්‍රමාණවත් අවසර නොමැති විය හැක.

Causes and Solutions:

  • Reconfigure User Privileges : ප්‍රධාන සේවාදායකයේ සුදුසු අවසර ඇති පරිශීලකයෙක් පවතින බව තහවුරු කරන්න. අවශ්‍ය නම් නැවත වින්‍යාස කරන්න. GRANT REPLICATION SLAVE ON *.* TO 'repl'@'slave_ip_address'; FLUSH PRIVILEGES;

5. බයිනරි ලොග් වර්ධනය

Symptom: ප්‍රධාන සේවාදායකයේ බයිනරි ලොග් ගොනු අධික ලෙස වර්ධනය වී, තැටි ඉඩ පරිභෝජනය කරනු ඇත.

Causes and Solutions:

  • Binary Log Rotation : අධික වර්ධනය වැළැක්වීමට බයිනරි ලොග් නිතරම මකා හෝ සංරක්ෂණය කරන්න. expire_logs_days වින්‍යාස කිරීමෙන්, නියමිත කාලය ඉක්මවා ඇති ලොග් ස්වයංක්‍රීයව ඉවත් කළ හැක. SET GLOBAL expire_logs_days = 7; # දින 7 කට වඩා පැරණි ලොග් මකන්න

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. නිගමනය

MySQL ප්‍රතිලේඛනය යනු දත්ත ස්ථිරභාවය සහ පද්ධති විශ්වාසනීයභාවය වැඩිදියුණු කිරීම සඳහා ඉතා වැදගත් විශේෂාංගයකි. මෙම ලිපියෙහි, MySQL ප්‍රතිලේඛනයේ මූලික සංකල්ප සිට ආරම්භ කරමින්, සකස් කිරීම් ක්‍රියාවලි, නිරීක්ෂණ පුරුදු සහ ගැටලු විසඳීම් ක්‍රම දක්වා සියල්ල ආවරණය කර ඇත. පහතින්, ඵලදායී ප්‍රතිලේඛන කළමනාකරණය සඳහා ප්‍රධාන කරුණු සාරාංශයක් දක්වා ඇත.

ප්‍රධාන ඉගෙනුම්

  1. නිවැරදි ප්‍රතිලේඛන වර්ගය තෝරා ගැනීම
  • අසින්ක්‍රනස් ප්‍රතිලේඛනය වේගවත් ප්‍රතිචාර කාල සපයන අතර, බර ව්‍යාප්තිය සඳහා ආදර්ශීය වේ. කෙසේ වෙතත්, විශ්වාසනීයභාවය ප්‍රමුඛ වන විට, අර්ධ-සින්ක්‍රනස් ප්‍රතිලේඛනය වඩාත් සුදුසුය. ඔබේ පද්ධති අවශ්‍යතා මත පදනම්ව තෝරන්න.
  1. GTID හි ඵලදායී භාවිතය
  • GTID බাইනරි ලොග ස්ථාන නිශ්චිත කිරීමේ අවශ්‍යතාවය ඉවත් කරයි සහ සුමට ගනුදෙනු කළමනාකරණය සක්‍රීය කරයි. එය බහු ස්ලේව් සහිත පරිසරවල හෝ බිඩිඩවර් සඳහා වැදගත් වන විට විශේෂයෙන් යොදා ගත හැකිය.
  1. නිතිපතා තත්ත්ව නිරීක්ෂණය
  • SHOW MASTER STATUS සහ SHOW SLAVE STATUS භාවිතයෙන් මාස්ටර් සහ ස්ලේව් සේවාදායකයන්ගේ ක්‍රියාකාරී තත්ත්වය නිතිපතා නිරීක්ෂණය කරන්න. අසාමාන්‍යතා හඳුනාගැනීමේදී ඉක්මන් ක්‍රියාමාර්ග ගැනීමෙන් දත්ත අනුකූලතාවය හෝ ප්‍රමාදය වැනි අවදානම් අවම කරයි.
  1. මූලික ගැටලු විසඳීම් ප්‍රායෝගිකව ඉගෙන ගැනීම
  • සුලබ ප්‍රතිලේඛන ගැටලුවලට ස්ලේව් සම්බන්ධතා දෝෂ, දත්ත අනුකූලතාවයේ නොගැලපීම් සහ ප්‍රමාදය ඇතුළත් වේ. එක් එක් ගැටලුව සඳහා මූලික විසඳුම් තේරුම් ගැනීමෙන් සුමට මෙහෙයුම් සහතික කරයි.
  1. බাইනරි ලොග කළමනාකරණය
  • බাইනරි ලොග්වලට සැලකිය යුතු ඩිස්ක් අවකාශයක් භාවිතා විය හැකි බැවින්, ස්වයංක්‍රීය පිරිසිදු කිරීම සඳහා expire_logs_days සකස් කිරීම සහ නිතිපතා නඩත්තු කිරීම නිර්දේශ කෙරේ.

MySQL ප්‍රතිලේඛනය එක් වරක සකස් කිරීමේ කාර්යයක් නොවේ. නිතිපතා නිරීක්ෂණය සහ නිවැරදි නඩත්තු කිරීම අත්‍යවශ්‍ය වේ. පද්ධති තත්ත්වය නිතිපතා සමාලෝචනය කිරීමෙන් සහ අවශ්‍ය විට සකස් කිරීම් වෙනස් කිරීමෙන්, ඔබට ඉහළ විශ්වාසනීය දත්ත සමුදාය පද්ධතියක් ගොඩනඟා ගත හැකි වේ.

අපි බලාපොරොත්තු වන්නේ මෙම මාර්ගෝපදේශය MySQL ප්‍රතිලේඛනය ගැන ඔබට වඩා හොඳින් තේරුම් ගැනීමට සහ ක්‍රියාත්මක කිරීමට උපකාරී වේවි. සුමට සහ ස්ථායී ප්‍රතිලේඛන මෙහෙයුම් ඔබට ශුභාෂිංශනා.