Replication एका source (master) पासून एक किंवा अधिक replicas कडे बदल stream करते. Source प्रत्येक commit झालेला बदल त्याच्या binary log (binlog) मध्ये नोंदवतो; प्रत्येक replica चा I/O thread तो log copy करतो आणि एक SQL/applier thread तो replay करतो, त्यामुळे replicas समान data कडे एकरूप होतात.
writes
app ---------> --- binlog ---> <-- reads
| <-- reads
+---------- binlog ---> <-- reads
ROW (प्रत्यक्ष row images नोंदवते, सुरक्षित default), STATEMENT, किंवा MIXED.Writes source कडे निर्देशित करा आणि SELECT replicas वर पसरवा. Read-heavy apps (बहुतेक web apps) replicas जोडून reads जवळपास रेषीय (linearly) scale करतात, तर एकमेव source अजूनही सर्व writes हाताळतो.
-- 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
Async replicas source च्या मागे राहत असल्यामुळे, जो user लिहितो आणि लगेच एका replica मधून वाचतो त्याला त्याचा स्वतःचा बदल दिसणार नाही ("read-your-writes" चे उल्लंघन). Latency-sensitive किंवा नुकतेच-लिहिलेले reads source कडे route करा, किंवा semi-sync वापरा.
Reads scale करण्यासाठी आणि failover/backups साठी एक warm standby मिळवण्यासाठी replication हे मानक पहिले पाऊल आहे. त्याची निर्णायक मर्यादा — lag, आणि single write bottleneck — खरे designs घडवते: तुम्ही कधीकधी stale data का वाचता आणि write scaling ला अखेरीस फक्त अधिक replicas नव्हे तर sharding का लागते हे स्पष्ट करते.
सविस्तर उत्तरांसह IT मुलाखत प्रश्नांचे ग्रंथालय — Junior पासून Senior पर्यंत.
देणगी द्या