The version of Postgis turns out to be too old to be used by the Maps team, please install Postgis 2.1.7 and Postgress 9.4. Per community input, the OSM database should be dropped and re-imported. Updating to Jessie is not a requirement.
Also, according to the OSM community (Paul), the default Postgres server configuration is very inefficient, and needs to be updated. Please see http://www.paulnorman.ca/blog/2014/11/new-server-postgresql-tuning/
Per @yuvipanda, other users are ok with this.
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | • madhuvishy | T106218 Setup wikilabels infrastructure and deployment | |||
| Resolved | akosiaris | T101233 Upgrade postgres on labsdb1004 / 1005 to 9.4, and PostGis 2.1 |
I asked them and they're ok with it :)
And nope, not the right assignee :) This has no assignee atm.
This also requires labsdb1005 to be upgraded since that's the postgres slave for this instance, but it's also the master for tools-db mysql setup.
Trusty, which is the easy upgrade path, has postgis 2.1.2 and postgres 9.3. @MaxSem, @Yurik, are those sufficient ? Otherwise we are going to need a reinstall to jessie which has the versions requested. Which means some downtime. As far as reimporting the databases go, since 9.x this is not really needed for postgres. There is pg_upgrade which can do the upgrade in place. However, and given postgis 2.1, it seems indeed that the gis database will need a reimport.
Finally, postgres databases are already tuned, see https://phabricator.wikimedia.org/diffusion/OPUP/browse/production/files/postgres/tuning.conf
Lets either lower the priority of this or resolve it outright - we are trying an alternative approach.
I'm going to go ahead and decline this outright (rather than resolve as @Yurik suggests), since if I'm incorrect, anyone can re-open the task easily enough. We didn't really do the things requested, hence declined.
It should still happen at some point - yurik isn't the only user of the machine and others will appreciate the upgrade as well.
Change 225558 had a related patch set uploaded (by Alexandros Kosiaris):
labsdb1004: Reinstall as jessie
Change 225562 had a related patch set uploaded (by Alexandros Kosiaris):
Stop labsdb1004 replication to labsdb1005
Change 225562 merged by Alexandros Kosiaris:
Stop labsdb1004 replication to labsdb1005
@akosiaris I've manually granted all of labs access with:
host all all 10.0.0.0/8 md5
We should puppetize this.
Actually, it was not done. It was running in a screen session and was interrupted by the restart of postgres to get the above change. I 've restarted it. Yes we should use file_line to puppetize this. My augeas approach at https://phabricator.wikimedia.org/diffusion/OPUP/browse/production/modules/postgresql/manifests/user.pp;11ebc94ab56c629ae6c5e784ec13a678d3c09d2a$73 is unfortunately not the best one around
The restored finished. Minor errors here and there but we should be mostly good to go. Resolving this
Reopening this because [[https://phabricator.wikimedia.org/diffusion/OPUP/browse/production/manifests/site.pp;5e38ec5ba7c75ef570038dda8e7308e038ec7dfa$1455-1468|manifests/site.pp]] reads:
node 'labsdb1004.eqiad.wmnet' {
# Bug: T101233
#$postgres_slave = 'labsdb1005.eqiad.wmnet'
#$postgres_slave_v4 = '10.64.37.9'
role(postgres::master, labs::db::slave)
}
node 'labsdb1005.eqiad.wmnet' {
# Bug: T101233
# $postgres_master = 'labsdb1004.eqiad.wmnet'
# include role::postgres::slave
role(labs::db::master)
}This was changed by c5e469409bc80133ff5883bb89a8229219a008d5:
commit c5e469409bc80133ff5883bb89a8229219a008d5
Author: Alexandros Kosiaris <akosiaris@wikimedia.org>
Date: Sat Jul 18 13:43:23 2015 -0500
Stop labsdb1004 replication to labsdb1005
Upgrading labsdb1004 to jessie for postgres 9.4 means that labsdb1005
will not be able to replicate. Remove replication until we get
labsdb1005 updated as well
Bug: T101233
Change-Id: I5bbf14fed7677237de98ba9700164a77827c0245I don't know if replication is now enabled (or if even labsdb1005 is still a PostgreSQL slave), but the manifest needs to be updated to reflect the status quo.
labsdb1005 is not longer a postgres slave. I 've removed both comments to fix that and no longer give that impression (fixing a few other minor stuff in the process) Re-resolving.