MongoDB
 sql >> база данни >  >> NoSQL >> MongoDB

Ръководство за разработчици за комплекти реплики на MongoDB

MongoDB често включва работа с голям набор от данни, включително вградени масиви и обекти на масиви. Ето защо винаги е важно да гарантирате, че скоростта на обработка на вашата база данни е възможно най-бърза, за да подобрите операциите за четене и запис. Освен това, за да избегнете аномалии в данните, които могат да възникнат поради непоследователност на данните, трябва да се уверите, че данните ви са в повишена наличност само в случай, че искате да имате възстановяване от случай на хардуерна повреда или някои прекъсвания на услугата. MongoDB предоставя 2 концепции за тази цел - ReplicaSets и Sharding.

Репликация в MongoDB

Репликация главен-подчинен

Това е една от най-старите техники, използвани, за да се гарантира, че данните винаги са достъпни за потребителите, дори когато една система се повреди. Репликацията Master-Slave обаче е остаряла в последните версии на MongoDB от 3.2 и по този начин е заменена с набори от реплики.

За да направите тази конфигурация, единият стартира 2 екземпляра на mongod, като се има предвид, че единият е в главен режим, а другият е подчинен.

За да стартирате екземпляр в главен режим, изпълнете:

mongod --master --port portNumber

Опциите --master инструктират mongod да създаде колекция local.oplog.$main, с която списък с операции се поставят на опашка за подчинените, които да прилагат при репликиране на данните.

За да стартирате екземпляр на mongod в подчинен режим, просто изпълнете:

mongod --slave --source <masterhostname><:<port>>

Тук трябва да посочите името на хоста и порта на главния екземпляр към аргумента --source. Това е обобщен преглед на използването на главната подчинена репликация и тъй като тя е остаряла, интересът ни ще бъде върху наборите реплики.

Набори реплики

Това е група от процеси на MongoDB, известни като mongod екземпляри, които основно хостват същия набор от данни. Характеризира се с един първичен възел и няколко вторични възела за носещи данни. Първичният възел получава всички операции по запис и записва всички други промени в своя набор от данни в своя дневник за операции. Вторичните възли, от друга страна, репликират дневника на операциите на първичния и прилагат операциите към своя набор от данни, така че техните набори от данни да отразяват основния набор от данни. С прости думи можем да кажем, че имаме машина A като основен възел и машина B и C като вторични възли. Машина А получава операция за запис и прави промени в своите данни и след това прави списък с направените промени. След това машини B и C ще копират операции от предоставения списък, в този случай oplog, и ще ги изпълнят, така че получените данни да са същите като в машина A.

Както бе споменато по-горе, винаги е важно да се гарантира висока наличност на данни, особено в производствената среда. Репликацията идва на помощ, като предоставя излишък на данни в различни екземпляри на Mongod. В случай на загуба на данни, тъй като копия на едни и същи данни се съхраняват в различни бази данни на множество места, е лесно да ги възстановите в съществуващата.

При много работещи екземпляри операциите за четене и запис от клиенти се изпращат до различни сървъри и следователно скоростта на обработка се увеличава. Основната структура на процеса на репликация е показана по-долу.

Понякога основният може да не е наличен, например поради прекъсване на връзката с интернет или прекъсване на услугата. В този случай наборът от реплика ще посочи вторичен за първичен възел. Доколкото заявките за четене се правят основно към основния, в някои случаи заявките за четене могат да бъдат изпратени до вторичните, но бъдете внимателни, тъй като върнатите данни може да не отразяват това, което е в основния, или по-скоро данните може да не са актуални.

Арбитри

В случай на избор на първични избори, ще ви е необходим допълнителен mongod екземпляр към набора реплика, за да добавите глас в изборния процес. Този екземпляр се нарича арбитър и основните му характеристики са:

  1. Той няма копие на набора от данни, следователно не изисква толкова мощен хардуер, колкото възлите, носещи данни.
  2. Не може да бъде повишен, за да стане основен.
  3. Те винаги имат 1 електорален глас, за да позволят на набора реплика да има нечетен брой членове с право на глас без допълнителни разходи за допълнителен член, който репликира данни. Следователно неговата решаваща роля е да избира първичен възел, когато той не е наличен.
  4. Остава непроменено.

Противно на арбитъра, други набори реплики могат да бъдат преобразувани в първични от вторични и обратно.

Асинхронна репликация

Процесът на репликация протича в две форми на синхронизация на данни. Първо, членовете в набора се попълват с пълни данни при първоначалното синхронизиране. Следващата репликация се извършва, за да се приложат напреднали промени към целия набор от данни.

При първоначалното синхронизиране данните се копират от един член на набора реплика в друг. Когато процесът приключи, членът преминава във вторичния възел.

Автоматично прекратяване при отказ на MongoDB

Може да има прекъсване на услугата като прекъсване на връзката с мрежата, което идва с последица от прекратяване на комуникацията между първичния и вторичния. Ако прекъсването е повече от 10 секунди или не успее напълно, оставащият набор от реплики ще гласува за член да стане новият основен. Вторичният възел, който получава мнозинството от гласовете, става новият първичен.

Във версия 3.0 на MongoDB наборът реплика може да има до 50 членове със 7 членове с право на глас.

Членове на набор от копия с приоритет нула

Това са вторични членове, които нито могат да преминат като първични възли, нито могат да предизвикат избори. В набора от данни има решаващи роли да:поддържат копия на набора от данни, избират първичен възел и изпълняват операции за четене. Те действат като резервно копие, където нов член може да не успее да добави веднага. По този начин той ще съхранява актуализираните данни и може незабавно да замени недостъпен член.

Членове на скрити реплики на MongoDB

Това са членове без връзка с клиентските приложения. Те се използват за натоварвания с различни изисквания за използване от други вторични членове. Те получават само основния трафик за репликация, който е по време на първоначалното синхронизиране.

Членове на отложен набор от реплики на MongoDB

Те копират данни от oplog файла на основния възел в рамките на определена продължителност. Те винаги отразяват забавено състояние или предишна форма на набора. Следователно те са важни при откриването на грешки и дават намек за това как човек може да се възстанови от тези грешки, например ако има изхвърлена база данни. Когато избирате размера на закъснението, трябва да имате предвид това:

  1. Продължителността трябва да бъде по-малка от капацитета на операционния дневник, който за механизмите за съхранение на WiredTiger, MMAPv1 и In-Memory е 50 GB. В противен случай забавеният член не може успешно да репликира операции.
  2. Продължителността на закъснението трябва да е равна или малко по-голяма от очакваната продължителност на прозореца за поддръжка.

Конфигурация

Това е член с нулев приоритет, той е скрит, следователно не се вижда от приложенията и накрая може да участва в изборния процес. Следователно, за да конфигурирате приоритет, да кажем, че имате 10 члена във вашия набор от реплика, можете да изберете член на позиция n като член[n] и да зададете неговите свойства като:

{
    “_id”: <num>, 
    “Host”: <hostname: port>,
    “Priority”: 0,
    “slaveDelay”: <seconds>,
    “Hidden”: true
}

Или с помощта на обвивката mongo, свързана към основната, можете да изпълните тези команди, за да зададете първия член на набора реплика като отложен:

cfg = rs.conf()
cfg.members[0].priority = 0
cfg.members[0].hidden = true
cfg.members[0].slaveDelay = 3600
rs.reconfig(cfg)

След задаване на тези конфигурации, забавеният вторичен не може да стане основен и следователно скрит от приложения. Членът ще бъде забавен с 1 час (3600 секунди) от операциите на oplog.

Severalnines Станете DBA на MongoDB – Пренасяне на MongoDB в Производството Научете какво трябва да знаете, за да внедрите, наблюдавате, управлявате и мащабирате MongoDB Изтеглете безплатно

Как да стартирате набор от реплики

В това ръководство ще видим стъпка по стъпка как можем да конфигурираме набор от реплика в MongoDB.

  1. Да приемем, че имате 3 mongodb, които искате да репликирате, и те са конфигурирани по следния начин:
    1. Mongod1.conf работи на порт 27017
    2. Mongod2.conf работи на порт 27018
    3. Mongod3.conf работи на порт 27019

    Уверете се, че сте добавили името на набора от реплика, което няма да се промени във всеки файл. Можете да направите това, като добавите или промените стойността на опцията replSet на име по ваш избор.

  2. Можем да стартираме първата инстанция, като изпълним

    sudo mongod --config /etc/mongo/mongod1.conf

    Това е, ако нямате работещ екземпляр на mongod. След това направете същото за другите случаи. За да проверите за работещи екземпляри във вашата машина, изпълнете

    ps -ax | grep mongo

    Ще получите списък като този:

    4328 ttys000    0:06.15 mongod
4950 ttys001    0:00.00 grep mongo
    Това означава, че първият екземпляр в MongoDB по подразбиране работи на порт 27017, следователно го имаме като първи в списъка. Ако сте стартирали останалите, те също ще бъдат очертани в списъка със съответните им URL адреси на пътя. За да се свържете с екземпляр в обвивката на mongo, изпълнете тази команда:
    mongo  --port port_number i.e mongo  --port 27017.
    В нашия случай обаче трябва да се свържем с име на набор от реплика, така че трябва да добавим i името към командата:
    mongod --replSet replicaSetName --dbpath /usr/local/var/mongo/mongod --port 27017
    В този случай нашата replicaSetName =“testrep”

  3. Нека проверим дали има активиран набор от реплики, като изпълним rs.status()

    Ако получите резултат като:

    {
    "ok" : 0,
    "errmsg" : "not running with --replSet",
    "code" : 76,
    "codeName" : "NoReplicationEnabled"
}

    Тогава това означава, че няма активиран набор от реплики. Иначе, ако получите резултата като

    {
    "operationTime" : Timestamp(0, 0),
    "ok" : 0,
    "errmsg" : "no replset config has been received",
    "code" : 94,
    "codeName" : "NotYetInitialized",
    "$clusterTime" : {
        "clusterTime" : Timestamp(0, 0),
        "signature" : {
            "hash" : BinData(0,"AAAAAAAAAAAAAAAAAAAAAAAAAAA="),
            "keyId" : NumberLong(0)
        }
    }
}

    тогава това означава, че репликата все още не е стартирана.

  4. Методът rs.initiate() ще ни помогне да стартираме нов набор от реплики и екземплярът, в който е иницииран, става наш основен възел. Така че можем да инициираме такъв в нашия екземпляр, като изпълним метода иницииране. rs.initiate().

  5. Проверете отново състоянието на набора от реплика, като изпълните rs.status().members. Сега трябва да видите нещо като

    "members" : [
        {
            "_id" : 0,
            "name" : "localhost:27018",
            "health" : 1,
            "state" : 1,
            "stateStr" : "PRIMARY",
            "uptime" : 577,
            "optime" : {
                "ts" : Timestamp(1535301271, 1),
                "t" : NumberLong(1)
            },
            "optimeDate" : ISODate("2018-08-26T16:34:31Z"),
            "syncingTo" : "",
            "syncSourceHost" : "",
            "syncSourceId" : -1,
            "infoMessage" : "could not find member to sync from",
            "electionTime" : Timestamp(1535301265, 1),
            "electionDate" : ISODate("2018-08-26T16:34:25Z"),
            "configVersion" : 1,
            "self" : true,
            "lastHeartbeatMessage" : ""
        }
    ]

    Е, добре. Нашият интерес ще бъде опцията members, тъй като можем да видим, че е n масив с 1 член в него. Проверявайки опцията stateStr на първия член, в този случай тя е зададена на Primary, което означава, че това ще действа като наш основен възел.

  6. Добавете нов член към набора от реплика, като използвате неговото име на хост. За да проверите за името на хоста на свързания екземпляр, който искате да добавите, run

    db.serverStatus().host

    Ще получите нещо като

    ervername.local:27019

    Така от PRIMARY можете да добавите друг член, като изпълните тази команда в mongo shell:

    rs.add("servername.local:27019");

  7. Изпълнете командата за състояние

    rs.status().members

    За да проверите дали промените са направени.

    Сега трябва да имате нещо, което изглежда така:

    [
    {
        "_id" : 0,
        "name" : "localhost:27018",
        "health" : 1,
        "state" : 1,
        "stateStr" : "PRIMARY",
        "uptime" : 11479,
        "optime" : {
            "ts" : Timestamp(1535312183, 1),
            "t" : NumberLong(1)
        },
        "optimeDate" : ISODate("2018-08-26T19:36:23Z"),
        "syncingTo" : "",
        "syncSourceHost" : "",
        "syncSourceId" : -1,
        "infoMessage" : "",
        "electionTime" : Timestamp(1535301265, 1),
        "electionDate" : ISODate("2018-08-26T16:34:25Z"),
        "configVersion" : 2,
        "self" : true,
        "lastHeartbeatMessage" : ""
    },
    {
        "_id" : 1,
        "name" : "127.0.0.1:27019",
        "health" : 1,
        "state" : 2,
        "stateStr" : "SECONDARY",
        "uptime" : 15,
        "optime" : {
            "ts" : Timestamp(1535312183, 1),
            "t" : NumberLong(1)
        },
        "optimeDurable" : {
            "ts" : Timestamp(1535312183, 1),
            "t" : NumberLong(1)
        },
        "optimeDate" : ISODate("2018-08-26T19:36:23Z"),
        "optimeDurableDate" : ISODate("2018-08-26T19:36:23Z"),
        "lastHeartbeat" : ISODate("2018-08-26T19:36:26.302Z"),
        "lastHeartbeatRecv" : ISODate("2018-08-26T19:36:27.936Z"),
        "pingMs" : NumberLong(0),
        "lastHeartbeatMessage" : "",
        "syncingTo" : "localhost:27018",
        "syncSourceHost" : "localhost:27018",
        "syncSourceId" : 0,
        "infoMessage" : "",
        "configVersion" : 2
    }
]

    Вече имаме 2 члена, единият е ПЪРВЕН възел, а другият е ВТОРИЧЕН възел. Можете да добавите още членове, но не повече от 50. Сега нека направим база данни в екземпляра на порт 27018 като основен.

    Ако изключим основния, ще се случи отказ и тъй като имаме само 1 първичен, той автоматично ще бъде прехвърлен във вторичен. Сега, ако се свържем с този на порт 27019, трябва да получите същите бази данни и колекции с техните документи.

    Сега, ако прекъснатият първичен възел се свърже отново, той ще бъде добавен като вторичен, тъй като копира операции от oplog на съществуващия първичен.

Загриженост за записване на набор от реплики MongoDB

Ако MongoDB върне успешна записана тревога за запис, данните ще бъдат съхранени на диска и следователно ще станат достъпни след рестартиране на mongod. Въпреки това, за операциите на запис данните са трайни само след като бъдат репликирани и ангажирани в дневника в полза на мнозинството от гласуващите членове на набора от реплики.

Някои данни може да са твърде големи за актуализиране или вмъкване, следователно може да отнеме повече време от очакваното, докато данните се репликират в други членове. Поради тази причина е препоръчително да редактирате конфигурациите на writeConcern, за да се погрижат за продължителността, в рамките на която една операция трябва да бъде изпълнена. Конфигурациите на writeConcern по подразбиране диктуват, че наборът от реплика изисква потвърждение само от основния член. Загриженост за запис по подразбиране потвърждава операциите за запис само за първичния, но може да бъде отменена, за да се проверят операциите на запис на някои членове на набора от реплики, като се укаже проблемът за запис за конкретна операция на запис. Например:

db.books.insert({name: “James”,place: “Beijing”},{writeConcern: {w: 3, wtimeout: 3600}})

Опцията за запис в този случай диктува, че операцията трябва да върне отговор само след като е разпространен до първичния и поне 2 вторични или ако изтече след 3,6 секунди.

Конфигуриране на загрижеността за запис за MongoDB

Опцията MongoDB getLastErrorDefaults ни дава параметрите за промяна на настройките по подразбиране на проблем за запис в конфигурацията на набора от реплики. Това означава, че операцията трябва да бъде завършена в повечето от гласуващите членове, преди да върне резултата.

cfg = rs.conf()
cfg.settings = {},
cfg.settings.getLastErrorDefaults = {w: “majority”, wtimeout: 3600}
rs.reconfig(cfg)

Стойността на изчакването ще предотврати блокиране на операциите по запис, тоест ако се предполага, че има 5 члена, които да потвърдят опасенията за запис, но за съжаление има 4 или по-малко членове в набора от реплика, операцията ще блокира, докато всички членове не са налични. Чрез добавяне на прага за изчакване блокирането на операцията ще бъде отхвърлено след това време.

Блокиране на репликация

Блокирането на операция, особено когато всички членове са репликирани, гарантира, че няма да се губи повече време в чакане на друг член на набора от реплика да бъде наличен, за да върне отговор. Командната опция MongoDB getLastError диктува как се извършва актуализацията на репликацията с помощта на незадължителния атрибут „w“.

Например тази заявка

db.runCommand({getLastError: 1, w: N, “wtimeout”: 5000});

изисква блокирането да се случи, докато N брой членове не репликират последната операция на запис. Ако N е налично или е по-малко от 2, заявката ще бъде върната. В противен случай, ако стойността за N е равна на 2, главният, еквивалентен на първичния, ще отговори само след като 1 от неговите подчинени устройства бъде репликиран в последната операция.

Wtimeout параметърът основно е да зададе времето в милисекунди, след което командата getLastError ще изтече и ще върне грешка, преди последната опция да бъде репликирана.

Колкото и да е изгодно блокирането, понякога има и ограничение. Това значително забавя операциите за четене, особено ако зададете стойността на "w" да е твърде голяма. Бих препоръчал да зададете стойността на „w“ на 2 или 3 за подобрена безопасност и ефективност.

Предпочитание за четене в MongoDB

Това е основно съседният маршрут, с който се извършват операциите за четене на клиента към набора реплики. Настройката на MongoDB по подразбиране конфигурира операциите за четене към първичните, защото това е тази с най-новата версия на документа, който извличате. Както бе споменато по-горе, върховното предимство за използване на набора от реплики е подобряването на производителността на нашата система от база данни. По този начин е препоръчително да се разпределят операциите за четене на много вторични членове, за да се намали забавянето за приложения, които не изискват непременно актуални данни. Има обаче по-важни причини, поради които трябва да използвате и основното като основно предпочитание:

  1. Поддържане на наличността на данни по време на отказ.
  2. За географски разпределени приложения основното ще предоставя локални четения за клиенти в същия център за данни.
  3. Да не засяга приложенията от предния край, особено тези, които изпълняват системни операции.

Mongo.setReadPref() Метод

Този метод е основно да дефинира как клиентът ще насочва всички заявки към членове на набора от реплика. Необходими са 2 аргумента, mode и tagSet.

Аргументът mode указва предпочитанието за четене, което може да бъде първично, първично предпочитано, вторично, второстепенно предпочитано или най-близкото.

Режимът tagSet определя потребителските предпочитания за четене. Можете също да ги посочите като масив от обекти. Пример за настройка ще бъде:

db.getMongo().setReadPref('primaryPreferred',
                          [ { "dc": "east", "use": "production" },
                            { "dc": "east", "use": "reporting" },
                            { "dc": "east" },
                            {}
                          ] )

Това, което се случва тук, е, че ако клиентът се опита да получи достъп до първия маркер и заявката не премине, той ще бъде избран за второто предпочитание за четене.

Режими за четене на предпочитания

  • Основен:това дефинира, че всички операции за четене, прочетени от даден набор от реплика, са първични и е режимът на четене с предпочитание по подразбиране.
  • PrimaryPreferred:Ако само основният не е наличен, тогава операциите за четене могат да се извършват от вторичните.
  • Вторичен:всички операции за четене се извършват от вторичните членове на набора от реплика.
  • SecondaryPreferred:ако само няма наличен вторичен, операциите за четене могат да бъдат направени от първичния.
  • Най-близкият:член с най-малко мрежово забавяне е избран за операция за четене, независимо от неговия тип.

Набори маркери и тяхната конфигурация

Това са опции, които ви позволяват да моделирате начина, по който искате да изглеждат вашите предпочитания за писане и четене. Те се съхраняват в конфигурационния обект на набора реплики. Ако стартирате rs.conf().members, ще получите този обект върнат:

[
    {
        "_id" : 0,
        "host" : "localhost:27018",
        "arbiterOnly" : false,
        "buildIndexes" : true,
        "hidden" : false,
        "priority" : 1,
        "tags" : {
            
        },
        "slaveDelay" : NumberLong(0),
        "votes" : 1
    },
    {
        "_id" : 1,
        "host" : "127.0.0.1:27019",
        "arbiterOnly" : false,
        "buildIndexes" : true,
        "hidden" : false,
        "priority" : 1,
        "tags" : {
            
        },
        "slaveDelay" : NumberLong(0),
        "votes" : 1
    }
]

Както можете да видите, всеки член има атрибут tags.

Основната разлика между „Предпочитания за четене“ и „Загриженост за писане“ е, че първият отчита стойността на маркер, когато избира член, от който да чете, докато вторият не го прави.

Да кажем, че даден маркер за операция за четене е настроен на:

{ "disk": "ssd", "use": "reporting" }

Член в набора реплика трябва да изпълни тези тагове, за да премине операцията за четене. Следователно да кажем конфигурация като тази

{ "disk": "ssd", "use": "reporting", "rack": "a" }

ще удовлетвори заявката, докато тази

{ "disk": "ssd", "use": "production", "rack": "k" }

няма да удовлетвори заявката.

Добавяне на маркери към реплика на набор

За избрания от вас член в набор от реплика, можете да добавяте набори с етикети, като използвате метода rs.conf() в MongoDB.

Да приемем, че сте избрали член на позиция 1 от вашия масив от набори от реплика, можете да добавите набори от етикети, както следва.

conf = rs.conf()
conf.members[0].tags = { "dc": "NYK", "use": "production"  }
conf.members[1].tags = { "dc": "LON", "use": "reporting"  }
conf.members[2].tags = { "use": "production"  }
rs.reconfig(conf)

Модели за внедряване за комплект реплики на MongoDB

  1. Географски разпределен набор от реплики – Подобрява резервирането на данни, освен че защитава данните срещу неизправности като загуба на захранване. Изпълняващите се екземпляри се намират на няколко места.
  2. Тричленен набор от реплики – основната стандартна архитектура за набор от реплики.
  3. Набор от реплики с четири или повече членове – Позволява по-широко резервиране на данни и също така поддържа по-широко разпределение на операциите за четене в набора от реплики.

Техники за настройка за внедряване на набор от реплики на MongoDB

Идеалният набор от реплика ще изисква добре подредена архитектура с поне 3 члена за производствена система. Тези стратегии за внедряване ще ви помогнат да активирате страхотен набор от реплики.

  1. Използвайте отложени и скрити членове, за да поддържате специални функции като отчитане и архивиране.
  2. Винаги правете броя на разположените членове нечетен. Както обсъдихме по-горе, при избора на първични членове ще е необходим нечетен брой членове. Затова се уверете, че имате нечетен номер и ако не, винаги можете да добавите арбитър.
  3. За разгръщания с тежко четене ще трябва да балансирате натоварването. Следователно от вас ще се изисква да разпространявате четения на вторичния, за да подобрите производителността на четене. Освен това, когато данните нарастват с времето, можете да добавите още членове и да ги разпределите, но имайте предвид, че трябва да ги конфигурирате по такъв начин, че първостепенният дизайн е да изберете основния.
  4. Винаги имайте предвид отказоустойчивостта. Това основно определя колко членове могат да бъдат недостъпни в даден момент и колко ще останат, за да поддържат изборния процес на първичните избори. Ако нямате първичен, за съжаление наборът от реплика няма да приеме никакви операции за запис.
  5. Добавете нови членове към съществуващия набор от реплика, преди да се появи търсене.
  6. Използвайте набори от маркери за набор от реплики, за да гарантирате, че всички операции се репликират в конкретни центрове за данни. Можете също да използвате тези маркери при маршрутизиране за операциите за четене за конкретни машини за внедряване.
  7. Разположете повечето от членовете си на едно място, за да избегнете пречките, които ще възникнат от разделянето на мрежата. Разделянето на мрежата може да бъде резултат от прекъсната комуникация между центровете за данни, което следователно възпрепятства процеса на репликация и процеса на избор на първичен.
  8. От съображения за безопасност разпределете членовете си географски, освен да правите някои скрити. Можете да зададете приоритет на поне 2 или 3 членове на нула, за да предотвратите превръщането им в основни.
  9. Използвайте дневник, за да защитите загубата на данни, която може да доведе до нещо като прекъсване на захранването. Това гарантира, че данните се записват на диск в случай на внезапно изключване.

Регистърът на операциите (Oplog)

Oplog поддържа запис на главните операции, които трябва да бъдат приложени към подчинените. Съхранява се в база данни, наречена локална в oplog.$main колекция. Създава се, когато стартирате член на набор от реплика за първи път. В горната граница, oplog е ограничен до размер от 50 GB за всички машини за съхранение. Размерът на oplog може да бъде променен от настройка по подразбиране. Ако този размер бъде достигнат например за 24 часа работа, вторичните няма да могат да копират от него през това време удобно и може в крайна сметка да не копират изобщо. Можете да промените размера на oplog, като използвате опцията replSetResizeOplog, т.е.

db.database({replSetResizeOplog:1, size: 16384})

Ако искате да намалите размера на този oplog, това ще доведе до премахване на някои данни. Основното въздействие на това в набора от реплики е, че членовете, синхронизирани с този възел, стават остарели. По този начин ще трябва да синхронизирате повторно тези членове.

Модели на работното натоварване, които биха изисквали голям размер на Oplog

  1. Актуализиране до няколко документа наведнъж. Множеството операции за актуализиране трябва да бъдат преведени в отделна операция за подобряване на резултатите в различните възли. Тази операция ще използва огромно пространство от oplog пространството.
  2. Значителен брой актуализации на място. Това обикновено се случва, когато актуализирането на данни на документи не увеличава непременно размера на този документ. Базата данни ще записва голям брой операции в oplog, като по този начин ще увеличи размера му.
  3. Изтриванията са равни на същото количество данни като вмъкванията. Това се случва, когато се опитате да изтриете количество данни (почти) равно на количеството данни, което вмъквате. Тази операция ще увеличи размера на oplog.

Заключение

Репликацията е един важен аспект на базите данни, който разработчиците трябва да разберат. Той гарантира повишена наличност на данни. Вашият MongoDB сървър може да се повреди, например, поради прекъсване на захранването, но все пак бихте искали клиентите ви да имат достъп до неговите данни. Ако имате репликирани данни на друг сървър, вашите клиенти ще могат да продължат да имат достъп до данни от него, ако основният сървър се повреди. Освен това има увеличено балансиране на натоварването, така че вместо всички потребители да имат достъп до един единствен сървър, ние виждаме компромисите от обслужването на трафик от вторични реплики.


  1. Redis
    2.   
  2. MongoDB
    3.   
  3. Memcached
    4.   
  4. HBase
    5.   
  5. CouchDB

  1. Бази данни за документи:излишни данни, препратки и т.н. (специално MongoDB)

  2. Как можете да посочите реда на свойствата в javascript обект за MongoDB индекс в node.js?

  3. Как да настроите MySQL Master-Slave репликация на Ubuntu 18.04

  4. Автоматизиране и управление на MongoDB в облака

  5. Създайте клъстер от база данни в облака с MongoDB Atlas