Replication ნაკადავს ცვლილებებს source (master)-იდან ერთ ან მეტ replica-ზე. Source იწერს ყოველ დაფიქსირებულ ცვლილებას თავის binary log (binlog)-ში; თითო replica-ის I/O thread აკოპირებს ამ log-ს, ხოლო SQL/applier thread ხელახლა ასრულებს მას, ამიტომ replica-ები ერთსა და იმავე მონაცემებთან იყრებიან.
writes
app ---------> --- binlog ---> <-- reads
| <-- reads
+---------- binlog ---> <-- reads
ROW (ლოგავს ფაქტობრივ სტრიქონის სურათებს, უსაფრთხო ნაგულისხმევი), STATEMENT ან MIXED.ჩაწერები მიმართეთ source-ისკენ და გაანაწილეთ SELECT-ები replica-ებზე. წაკითხვაზე ორიენტირებული აპლიკაციები (უმეტესი ვებ აპლიკაცია) მასშტაბირებენ წაკითხვას თითქმის ხაზობრივად replica-ების დამატებით, ხოლო ერთადერთი source ჯერ კიდევ ამუშავებს ყველა ჩაწერას.
-- Replica-ზე, დააკვირდით, რამდენად ჩამორჩება ის:
SHOW REPLICA STATUS\G
-- Seconds_Behind_Source: 2 <- replication lag
-- Replica_IO_Running: Yes
-- Replica_SQL_Running: Yes
რადგან async replica-ები ჩამორჩებიან source-ს, მომხმარებელი, რომელიც წერს და შემდეგ მაშინვე კითხულობს replica-დან, შეიძლება ვერ ხედავდეს საკუთარ ცვლილებას ("read-your-writes" დარღვევა). latency-ისადმი მგრძნობიარე ან ახლახან ჩაწერილი წაკითხვები მიმართეთ source-ისკენ, ან გამოიყენეთ semi-sync.
Replication არის სტანდარტული პირველი ნაბიჯი წაკითხვის მასშტაბირებისა და failover/backup-ისთვის თბილი standby-ის მისაღებად. მისი განმსაზღვრელი შეზღუდვა — lag და ერთადერთი ჩაწერის ბოთლის ყელი — აყალიბებს რეალურ დიზაინებს: ის ხსნის, თუ რატომ კითხულობთ ხანდახან მოძველებულ მონაცემებს და რატომ საჭიროებს ჩაწერის მასშტაბირება საბოლოოდ sharding-ს და არა უბრალოდ მეტ replica-ს.
IT გასაუბრების კითხვების ბიბლიოთეკა დეტალური პასუხებით — Junior-დან Senior-მდე.
შემოწირულობა