I have also seen problems with MySQL, and in my case they were with restoring backups. It was a bug with dump/restore, but having and individual dumpfile for each database saved my bacon. I was able to restore everything but the database causing the problem, hand-fix the export file, and then reload with minimal downtime to everything but the affected database.
Is there any benefit in doing cold file-based backups of the databases as well?
Ideally, I'd like to see the mysql exports as well as any static content rsynced to the telascience servers nightly.
I'd also like to see the PEER1 servers doing cross-backups on a fast cycle (1 hour?), with the ability to turn up the services on the alternate server and re-point DNS if one goes down.
Jason
________________________________
From: shawn barnes [mailto:sbarnes@dmsolutions.ca]
Sent: Tue 2006-12-05 6:33 AM
To: sac@sac.osgeo.org
Subject: Re: [SAC] Drupal "development" Instance / New logins
Howard,
I have set up MySQL with InnoDB in the past - the storage space is a
little larger and benchmarks are a little slower but, not signicantly
different than using MyISAM. The only concern i know about in using
InnoDB is making sure to disable write-back cache on the drives/drive
controllers. I'll be on the systems soon to discover if this is
possible or not.
Have you set up MySQL with a transactional Storage Engine? Is there
anything else i should be looking at?
And i like the idea of a full dump and mirroring it with TelaScience.
shawn
Howard Butler wrote:
I do not hope to gum up the works, but I must admit to being somewhat
skeptical of running our lives on MySQL. I spent a few hours last
week recovering GDAL's bugzilla instance from a crashed table due to a
disk filling up and mucking up MySQL's transaction stuff. I know that
bazillions of sites do their business on MySQL, so maybe the problem
was just the storage backend that was chosen, and nothing more.
I suggest we use a full mysqldump backup strategy (with a mirror of it
to the TelaScience system) until it is no longer practical to do so.
Also, I suggest we make sure to use a transactional MySQL backend in
hopes of preventing MySQL hiccups that can occur with something like
MyISAM.
Howard
On Dec 5, 2006, at 7:55 AM, shawn barnes wrote:
I think it's a great idea. I'll never disagree with using a testing
environment before installing and working on live systems.
i'm going to begin working on the new servers today and will be
installing drupal, et al. in the next couple of days, is there a
specific version of drupal/drupal-modules/mysql to install?
shawn
Tyler Mitchell wrote:
Sounds fine to me. Shawn, will this fit with your approach?
Btw, we just received access to our new servers from PEER1 hosting, so
now Shawn has access to the production systems.
Tyler
On 12/4/06, Frank Warmerdam <warmerdam@pobox.com> wrote:
Hobu,
Could you create an LDAP account for Kanhaiya Kale (perhaps userid
"kanhaiya" like he uses on the cn system).
Everyone,
My intention is for Kanhaiya (KK if I may) to setup a "development"
drupal
instance on shell.telascience.org (198.202.74.218). For now this
will be
where we can see what the script-loaded html content from the
www.osgeo.org
web site will look in Drupal, but longer term I forsee this being the
development Drupal server assuming we want to be a bit careful
about how we
handle the "live" Drupal server once it is the live OSGeo web
presence.
I don't see this "using up" .218, it should just be one of a few
things that
go on there.
Does anyone have any concerns with this use of the .218 server? I
believe
John is already looking into setting up the right version of mysql.
Best regards,
-----------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam,
warmerdam@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | President OSGeo,
http://osgeo.org
)