Какво е верижна репликация?
Когато говорим за репликация, имаме предвид процеса на правене на излишни копия на данни, за да се изпълнят критериите за проектиране за наличност на данни. Следователно репликацията на веригата се отнася до линейното подреждане на сървърите на MongoDB за образуване на синхронизирана верига. Веригата съдържа първичен възел, последван от вторични сървъри, подредени линейно. Както предполага веригата от думи, сървърът, който е най-близо до първичния сървър, се репликира от него, докато всеки следващ вторичен сървър се репликира от предходния вторичен сървър MongoDB. Това е основната разлика между верижната репликация и нормалната репликация. Верижна репликация се случва, когато вторичен възел избере своята цел, използвайки ping време или когато най-близкият възел е вторичен. Въпреки че репликацията на веригата, както изглежда, намалява натоварването на основния възел, това може да причини забавяне на репликацията.
Защо да използвате верижна репликация?
Системните инфраструктури понякога претърпяват непредвидими повреди, водещи до загуба на сървър и следователно засягащи наличността. Репликацията гарантира, че непредсказуемите повреди не влияят на наличността. Репликацията допълнително позволява възстановяване от хардуерна повреда и прекъсване на услугата. Както верижната, така и неверижната репликация служат на тази цел за осигуряване на наличност въпреки системните откази. След като сте установили, че репликацията е важна, може да попитате защо да използвате именно верижната репликация. Няма разлика в производителността между верижна и неверижна репликация в MongoDb. И в двата случая, когато първичният възел се повреди, вторичните сървъри гласуват за нов действащ първичен и следователно записването и четенето на данни не се засяга и в двата случая. Верижната репликация обаче е типът репликация по подразбиране в MongoDb.
Как да настроите реплика на верига
По подразбиране верижната репликация е активирана в MongoDB. Затова ще разгледаме по-подробно процеса на деактивиране на репликацията на веригата. Основната причина, поради която репликацията на веригата може да бъде деактивирана, е ако причинява забавяне. Достойността на репликацията на веригата обаче е по-добра от недостатъка на изоставането и поради това в повечето случаи нейното деактивиране не е необходимо. Само в случай, че репликацията на веригата не е активна по подразбиране, следните команди ще ви помогнат да активирате.
cfg = rs.config()
cfg.settings.chainingAllowed = true
rs.reconfig(cfg)Този процес е обратим. Когато е принуден да деактивира репликацията на веригата, следният процес се следва религиозно.
cfg = rs.config()
cfg.settings.chainingAllowed = false
rs.reconfig(cfg)Съвети и трикове за репликация на верига
Най-ужасното ограничение на репликацията на веригата е забавянето на репликацията. Закъснението при репликация се отнася до забавянето, което възниква между времето, когато една операция се извършва на първичния и когато същата операция се репликира на вторичния. Въпреки че е естествено невъзможно, винаги е желателно скоростта на репликация да бъде много висока при това забавяне на репликацията да е нула. За да избегнете или сведете до минимум забавянето на репликацията, за да бъде близо до нула, разумно е критериите за проектиране да се използват първични и вторични хостове със същите спецификации по отношение на CPU, RAM, IO и свързани с мрежата спецификации.
Въпреки че репликацията на веригата осигурява наличност на данни, репликацията на веригата може да се използва заедно с водене на журнал. Журналирането осигурява безопасност на данните чрез запис в дневник, който редовно се изтрива на диск. Когато двете се комбинират, три сървъра се записват на заявка за запис, за разлика от само верижната репликация, където само два сървъра се записват на заявка за запис.
Друг важен съвет е използването на w с репликация. Параметърът w контролира броя на сървърите, на които трябва да бъде записан отговор, преди да върне успеха. Когато параметърът w е зададен, getlasterror проверява oplog на сървърите и изчаква, докато дадения брой сървъри „w“ приложи операцията.
Използването на инструмент за наблюдение като MongoDB Monitoring Service (MMS) или ClusterControl ви позволява да получите състоянието на вашите реплика възли и да визуализирате промените във времето. Например, в MMS можете да намерите репликационни графики на забавяне на вторичните възли, показващи вариацията във времето на забавяне на репликацията.
Измерване на ефективността на репликацията на веригата
Вече сте наясно, че най-важният параметър на производителността на верижната репликация е времето на забавяне на репликацията. Затова ще обсъдим как да тестваме за период на забавяне на репликацията. Този тест може да се извърши чрез скрипта на обвивката MongoDb. За да направим тест за забавяне на репликацията, ние сравняваме oplog на последното събитие на първичния възел и oplog на последното събитие на вторичния възел.
За да проверим информацията за основния възел, изпълняваме следния код.
db.printSlaveReplicationInfo()Горната команда ще предостави информация за всички скорошни операции на основния възел. Резултатите трябва да се показват, както е по-долу.
rs-ds046297:PRIMARY db.printSlaveReplicationInfo()
source: ds046297-a1.mongolab.com:46297
synced To: Tue Mar 05 2013 07:48:19 GMT-0800 (PST)
= 7475 secs ago (2.08hrs)
source: ds046297-a2.mongolab.com:46297
synced To: Tue Mar 05 2013 07:48:19 GMT-0800 (PST)
= 7475 secs ago (2.08hrs)След като получихме oplog за първичния възел, сега се интересуваме от oplog за вторичния възел. Следната команда ще ни помогне да получим oplog.
db.printReplicationInfo()Тази команда ще предостави изход с подробности за размера на oplog, дължината на журнала, времето за първо събитие на oplog, времето за последното събитие на oplog и текущото време. Резултатите се показват по-долу.
rs-ds046297:PRIMARY db.printReplicationInfo()
configured oplog size: 1024MB
log length start to end: 5589 secs (1.55hrs)
oplog first event time: Tue Mar 05 2013 06:15:19 GMT-0800 (PST)
oplog last event time: Tue Mar 05 2013 07:48:19 GMT-0800 (PST)
now: Tue Mar 05 2013 09:53:07 GMT-0800 (PST)От oplog на основния сървър последното синхронизиране е извършено на 5 март 2013 г., вторник, 07:48:19 GMT-0800 (PST). От oplog на вторичния сървър последната операция е извършена на 5 март 2013 г. вт, 07:48:19 GMT-0800 (PST). Закъснението при репликация беше нулево и следователно нашата система, репликирана от веригата, работи правилно. Закъснението във времето за репликация обаче може да варира в зависимост от количеството промени, които трябва да бъдат репликирани.
