Replication ફેરફારોને એક source (master) થી એક કે વધુ replicas સુધી stream કરે છે. source દરેક committed ફેરફારને તેના binary log (binlog) માં નોંધે છે; દરેક replica નો I/O thread એ log ને copy કરે છે અને એક SQL/applier thread તેને ફરી replay કરે છે, તેથી replicas એ જ ડેટા પર converge થાય છે.
writes
app ---------> --- binlog ---> <-- reads
| <-- reads
+---------- binlog ---> <-- reads
ROW (વાસ્તવિક row images log કરે છે, સલામત default), STATEMENT, કે MIXED.writes ને source પર દોરો અને SELECTs ને 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-સંવેદનશીલ કે હમણાં-લખાયેલ reads ને source પર route કરો, કે semi-sync વાપરો.
Replication એ reads ને scale કરવાનું અને failover/backups માટે warm standby મેળવવાનું પ્રમાણભૂત પ્રથમ પગલું છે. તેની વ્યાખ્યાત્મક મર્યાદા — lag, અને એકમાત્ર write bottleneck — વાસ્તવિક designs ને આકાર આપે છે: તે સમજાવે છે કે તમે ક્યારેક stale ડેટા કેમ વાંચો છો અને write scaling ને આખરે ફક્ત વધુ replicas નહીં, sharding કેમ જોઈએ છે.
વિગતવાર જવાબો સાથે IT ઇન્ટરવ્યૂ પ્રશ્નોની લાઇબ્રેરી — જુનિયરથી સિનિયર સુધી.
દાન કરો