Replication परिवर्तनों को एक source (master) से एक या अधिक replicas तक stream करता है। source हर committed परिवर्तन को अपने binary log (binlog) में दर्ज करता है; हर replica का I/O thread उस log को copy करता है और एक SQL/applier thread उसे दोबारा चलाता है, इसलिए replicas उसी data पर converge हो जाती हैं।
writes
app ---------> --- binlog ---> <-- reads
| <-- reads
+---------- binlog ---> <-- reads
ROW (वास्तविक row images लॉग करता है, सुरक्षित default), STATEMENT, या MIXED।writes को source पर भेजें और SELECTs को replicas में फैलाएँ। Read-heavy apps (अधिकांश web apps) replicas जोड़कर reads को लगभग रैखिक रूप से 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-संवेदनशील या अभी-लिखे गए reads को source पर route करें, या semi-sync का उपयोग करें।
Replication reads को scale करने और failover/backups के लिए एक गर्म standby पाने का मानक पहला कदम है। इसकी परिभाषित सीमा — lag, और एकल write bottleneck — वास्तविक designs को आकार देती है: यह समझाती है कि आप कभी-कभी बासी data क्यों पढ़ते हैं और write scaling को अंततः केवल अधिक replicas नहीं, बल्कि sharding की ज़रूरत क्यों होती है।
विस्तृत उत्तरों के साथ IT इंटरव्यू प्रश्नों की एक लाइब्रेरी — जूनियर से सीनियर तक।
दान करें