Replication ले परिवर्तनहरूलाई एउटा source (master) बाट एक वा बढी replicas मा stream गर्छ। Source ले हरेक commit भएको परिवर्तनलाई आफ्नो binary log (binlog) मा रेकर्ड गर्छ; हरेक replica को I/O thread ले त्यो log प्रतिलिपि गर्छ र SQL/applier thread ले यसलाई replay गर्छ, त्यसैले replicas उही डेटामा अभिसरण हुन्छन्।
writes
app ---------> --- binlog ---> <-- reads
| <-- reads
+---------- binlog ---> <-- reads
ROW (वास्तविक row images log गर्छ, सुरक्षित डिफल्ट), STATEMENT, वा MIXED।Writes लाई source तिर पठाउनुहोस् र SELECT हरूलाई 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 भन्दा पछाडि हुने भएकाले, लेखेर तुरुन्तै replica बाट पढ्ने प्रयोगकर्ताले आफ्नै परिवर्तन नदेख्न सक्छ ("read-your-writes" उल्लङ्घन)। Latency-संवेदनशील वा भर्खर लेखिएका reads लाई source तिर route गर्नुहोस्, वा semi-sync प्रयोग गर्नुहोस्।
Replication reads scale गर्ने र failover/backups का लागि warm standby पाउने मानक पहिलो कदम हो। यसको परिभाषित सीमा — lag, र एकल write bottleneck — ले वास्तविक designs आकार दिन्छ: यसले किन तपाईं कहिलेकाहीँ बासी डेटा पढ्नुहुन्छ र किन write scaling ले अन्ततः केवल थप replicas होइन, sharding चाहिन्छ भन्ने व्याख्या गर्छ।
विस्तृत उत्तरसहित IT अन्तर्वार्ता प्रश्नहरूको पुस्तकालय — जुनियरदेखि सिनियरसम्म।
दान गर्नुहोस्