search

FreeUKGen / MyopicVicar

MyopicVicar (short-sighted clergyman!) is an open-source genealogy record database and search engine. It powers the FreeREG database of parish registers, the FreeCEN database of census records, the next version of FreeBMD database of Civil Registration indexes and other Genealogical applications.
46 stars 15 forks source link

24 P Update MongoDB to 4.0 #1216

Closed Captainkirkdawson closed 5 years ago

Captainkirkdawson commented 7 years ago

Priority 16 ( 0 6 7 3)

It is advisable to update Mongodb and Its import/dump utilities to v 3.4

Late July is the time frame needs #1676 needs #1386

lemon-ukgen commented 7 years ago

Upstream carries 3.4 so we can drop our custom package, great.

Some care around scripts that are wired to the mongod32 program names. I think this is just mongoctl now.

Captainkirkdawson commented 6 years ago

@lemon-ukgen

Mongodb now has version 3.6 and version 4. We must upgrade to 3.4 then 3.6 then 4.0

Clearly we need to do this in a step wise fashion.

I am not going to be able to deal with this until mid October. So can we schedule some of your time to get at least the first version 3.4 available for mid October

lemon-ukgen commented 6 years ago

That's fine @Captainkirkdawson, I am not planning on being away.

FreeBSD does not yet package 4.0. If they still don't by October we'll roll our own package for it.

We might take the opportunity to move the MongoDB servers to FreeBSD 11.2. This requires two reboots and ~30 minutes per server.

lemon-ukgen commented 5 years ago

Is this still on the cards @Captainkirkdawson ? Even if it's not, we should schedule the FreeBSD upgrade on the MongoDB servers soon.

Captainkirkdawson commented 5 years ago

Absolutely. We need to step through 3.4, 3.6 to 4.0. The db must be moved through each it cannot go from 3.2 to 4.0 in one step. So that is going to be a real pain. Will it be possible to get those 3 versions installed so that we can step the app carefully through each.

I also need to update the FR app. That is story #1386. We were hoping to restart that one in the next sprint after this one. It would likely be advisable to do this before moving the db through the versions.

Which should we do first mongodb or FreeBSD 11.2?

Captainkirkdawson commented 5 years ago

@lemon-ukgen having thought about this overnight I believe we should do FreeBSD 11.2 first. Will raise as separate story. #1676

Captainkirkdawson commented 5 years ago

@lemon-ukgen what are your plans to installing Mongodb3.4?

lemon-ukgen commented 5 years ago

Now that we've done the OS upgrade in #1676 we can do this work whenever convenient to you, @Captainkirkdawson. Well, almost, I am away Friday 5th April until after Easter.

mongodb34, mongodb36, mongodb40 packages are available from FreeBSD repos.

It sounds like we need to work in tandem on this. Something like:

This is assuming we can have mismatched pairs during the upgrade (ie: at one point we'll have pairs with 4.0/3.2 mixed. If that's not OK, then we can do it the other way around:

And the sideways variation:

I don't have much insight into which is preferable, mongo-wise.

Captainkirkdawson commented 5 years ago

@lemon-ukgen Good news about the 4.0 package. Yes we will have to do this in close cooperation. 1) All members of a shard must be on the same version before doing an upgrade so we will have to use your second (sideways) process above. 2) We also need to do secondaries first and primaries last. 3) We may need to reconfigure the arbiters for a shard during the process. Will look at that 4) I believe we should hold off enabling new features until the end and do that over an extended period of time (Likely will not need your support for that) 5) We MUST do the standalone on vervet first to make sure there are no surprises. It supports the test2 urls. When could we start or vervet? I need to map out the process in more detail as we have 20 instances spread over the 6 mongos

Captainkirkdawson commented 5 years ago

@lemon-ukgen The process as I see it; mongo2; mongo3; mongo1; mongo5; mongo4; mongo6 Mongsdb upgrade process On vervet. Shut down the stanalone mongod instance. Replace the existing binary with the 3.4 mongod binary and restart mongod_standalone. If things on test2 are working OK. Then connect to the mongo shell on vervet with mongo --port 27017 --ssl –sslAllowInvalidCertificates and db.adminCommand( { setFeatureCompatibilityVersion: "3.4" } ) Recheck test2. If OK proceed with production database servers

Ensure that the mongo servers have the primary set up shown in the annex. Start a mongo on any server with mongo --port 27017 --ssl --sslAllowInvalidCertificates sh.stopBalancer() and check that balancer is stopped with sh.getBalancerState() until it is clearly stopped Stop all mongodb instances on mongo2. Update mongo2. Restart mongodb-sharded and mongodb-mongos.conf Stop all mongodb instances on mongo3. Update mongo3. Restart mongodb-sharded; and mongodb-arbiter_for_shard1.conf and mongodb-mongos.conf and mongodb-config_server Step down mongo1 sharded Stop all mongodb instances on mongo1. Update mongo1. Restart mongodb-sharded and mongodb-arbiter_for_shard3.conf and mongodb-mongos.conf and mongodb-config_server Stop all mongodb instances on mongo5. Update mongo5. Restart mongodb-sharded and mongodb-arbiter_for_shard2.conf and mongodb-mongos.conf and mongodb-config_server Step down mongo4 sharded to secondary. Stop all mongodb instances on mongo4. Update mongo4. Restart mongodb-sharded and mongodb-arbiter_for_shard3.conf and mongodb-mongos.conf and mongodb-config_server Step down mongo6 sharded to secondary. Step down mongo6 mongodb-config_server to secondary Stop all mongodb instances on mongo6. Update mongo6. Restart mongodb-sharded and mongodb-mongos.conf and mongodb-config_server Step down mongo2 sharded; Step down mongo3; sharded Step down mongo5 sharded Ensure all instances are running as in annex Start the balancer by connecting to a mongos with mongo --port 27017 --ssl –sslAllowInvalidCertificates and then sh.setBalancerState(true) Finally if everything running well connect to a mongos with mongo --port 27017 --ssl –sslAllowInvalidCertificates and db.adminCommand( { setFeatureCompatibilityVersion: "3.4" } ) Repeat again for 3.6 and then 4.0 Annex mongo1 sudo -u mongodb mongod --config /usr/local/etc/mongodb-sharded.conf

runs on port 27018 and replSetName: shard1 Primary

sudo -u mongodb mongod --config /usr/local/etc/mongodb-arbiter_for_shard3.conf

runs on port 27020

sudo -u mongodb mongos --config /usr/local/etc/mongodb-mongos.conf

runs on port 27017

sudo -u mongodb mongod --config /usr/local/etc/mongodb-config_server.conf

runs on port 27019 and replSetName: csReplSet

mongo2 sudo -u mongodb mongod --config /usr/local/etc/mongodb-sharded.conf

runs on port 27018 and replSetName: shard1

sudo -u mongodb mongos --config /usr/local/etc/mongodb-mongos.conf

runs on port 27017

mongo3 sudo -u mongodb mongod --config /usr/local/etc/mongodb-sharded.conf

runs on port 27018 and replSetName: shard2

sudo -u mongodb mongod --config /usr/local/etc/mongodb-arbiter_for_shard1.conf

runs on port 27015

sudo -u mongodb mongod --config /usr/local/etc/mongodb-config_server.conf

runs on port 27019 and replSetName: csReplSet

sudo -u mongodb mongos --config /usr/local/etc/mongodb-mongos.conf

runs on port 27017

mongo4 sudo -u mongodb mongod --config /usr/local/etc/mongodb-sharded.conf

runs on port 27018 and replSetName: shard2 Primary

sudo -u mongodb mongod --config /usr/local/etc/mongodb-config_server.conf

runs on port 27019 and replSetName: csReplSet

sudo -u mongodb mongos --config /usr/local/etc/mongodb-mongos.conf

runs on port 27017

mongo5 sudo -u mongodb mongod --config /usr/local/etc/mongodb-sharded.conf

runs on port 27018 and replSetName: shard3

sudo -u mongodb mongod --config /usr/local/etc/mongodb-arbiter_for_shard2.conf

runs on port 27016

sudo -u mongodb mongod --config /usr/local/etc/mongodb-config_server.conf

runs on port 27019 and replSetName: csReplSet

sudo -u mongodb mongos --config /usr/local/etc/mongodb-mongos.conf

runs on port 27017

mongo6 sudo -u mongodb mongod --config /usr/local/etc/mongodb-sharded.conf

runs on port 27018 and replSetName: shard3 Primary

sudo -u mongodb mongod --config /usr/local/etc/mongodb-config_server.conf

runs on port 27019 and replSetName: csReplSet Primary

sudo -u mongodb mongos --config /usr/local/etc/mongodb-mongos.conf

runs on port 27017

lemon-ukgen commented 5 years ago

vervet is already on 3.4, btw. Happened during the (somewhat troublesome) FreeBSD upgrade.

Captainkirkdawson commented 5 years ago

Have activated new features for mongo 3.4. test2 on both cen and reg appear to run OK at least on basic search functions