MySQL master–replica replication எவ்வாறு செயல்படுகிறது, மேலும் அது read scaling-க்கு எவ்வாறு உதவுகிறது?

Question

IT Interview Practice · Accepted Answer

Replication ஆனது ஒரு **source (master)**-இலிருந்து ஒன்று அல்லது அதற்கு மேற்பட்ட **replicas**-க்கு மாற்றங்களை stream செய்கிறது. source ஆனது ஒவ்வொரு commit செய்யப்பட்ட மாற்றத்தையும் அதன் **binary log (binlog)**-இல் பதிவு செய்கிறது; ஒவ்வொரு replica-இன் I/O thread அந்த log-ஐ நகலெடுக்கிறது, மேலும் ஒரு SQL/applier thread அதை மீண்டும் இயக்குகிறது, எனவே replicas ஒரே data-க்கு converge ஆகின்றன. ## ஓட்டம் ``` writes app ---------> [ SOURCE ] --- binlog ---> [ replica 1 ] <-- reads | [ replica 2 ] <-- reads +---------- binlog ---> [ replica 3 ] <-- reads ``` - **Formats** — `ROW` (உண்மையான row images-ஐப் பதிவு செய்கிறது, பாதுகாப்பான இயல்புநிலை), `STATEMENT`, அல்லது `MIXED`. - **Async (இயல்புநிலை)** — source ஆனது replicas-க்காகக் காத்திராமல் commit செய்கிறது: வேகமானது, ஆனால் ஒரு replica பின்தங்கக்கூடும். - **Semi-sync** — source ஆனது குறைந்தபட்சம் ஒரு replica ஒப்புக்கொள்வதற்காகக் காத்திருக்கிறது, durability-க்காக சிறிது latency-ஐ பரிமாறிக்கொள்கிறது. ## Read scaling writes-ஐ source-இல் சுட்டிக்காட்டி `SELECT`-களை replicas முழுவதும் பரப்புங்கள். Read-heavy apps (பெரும்பாலான web apps) replicas-ஐச் சேர்ப்பதன் மூலம் reads-ஐ கிட்டத்தட்ட நேர்கோட்டில் scale செய்கின்றன, அதே வேளையில் ஒற்றை source இன்னும் அனைத்து writes-ஐயும் கையாளுகிறது. ```sql -- On a replica, watch how far behind it is: SHOW REPLICA STATUS\G -- Seconds_Behind_Source: 2 <- replication lag -- Replica_IO_Running: Yes -- Replica_SQL_Running: Yes ``` ## சிக்கல்: replication lag async replicas source-ஐப் பின்தொடர்வதால், எழுதிய பிறகு உடனடியாக ஒரு replica-இலிருந்து படிக்கும் ஒரு user தனது சொந்த மாற்றத்தைப் பார்க்காமல் போகலாம் ("read-your-writes" மீறல்). latency-sensitive அல்லது இப்போதுதான் எழுதப்பட்ட reads-ஐ source-க்கு route செய்யுங்கள், அல்லது semi-sync-ஐப் பயன்படுத்துங்கள். ## இது ஏன் முக்கியம் Replication என்பது reads-ஐ scale செய்யவும், failover/backups-க்கு ஒரு warm standby-ஐப் பெறவும் நிலையான முதல் படியாகும். அதன் வரையறுக்கும் வரம்பு — lag, மற்றும் ஒற்றை write bottleneck — உண்மையான designs-ஐ வடிவமைக்கிறது: நீங்கள் சில நேரங்களில் ஏன் பழைய data-ஐப் படிக்கிறீர்கள் என்பதையும், write scaling-க்கு இறுதியில் ஏன் அதிக replicas மட்டுமல்ல sharding தேவை என்பதையும் இது விளக்குகிறது.

ஓட்டம்

Read scaling

சிக்கல்: replication lag

இது ஏன் முக்கியம்

தொடர்புடைய கேள்விகள்