[ale] advice needed.

[Christopher Fowler]

Atlanta Geek wrote:
> T
> Joshua Kite
> The admin, install and backing up the web app in smaller offices could
> get expensive.  And when I say smaller offices these might be offices
> of larger organizations. So IT is not involved in the decision process
> or support process. And this is why I think that the real solution is
> SAAS.
> I also thought there might be a way to run a vmware image that would
> almost set up itself. Stealling a lot of the configuration information
> from its host machine.
>   
None of my users backup their server.  They should, but don't.
I knew this going into the project. 

Every server we provide makes a VPN connection back to
a server in Peak 10.  We call this server 'support'.  It has some
decent resources.   It runs MANY instances of MySQL as slaves
to each of these servers.  Around 1am it snapshots each database
and compresses it.  I've actually used these snapshots to trace
changes to configuration to a particular day.  In some cases a specific
user.  I do not back up the server.  I do not backup log files or
even the software.  The only thing I can not replace is their data.

This may not work for databases that are massive.  Our product is
very load load.  It does alarm tracking, notification, inspection, etc
of remote sites.  Out databases can average possibly 20M.  Not very 
big.  Some of the audit tables can be larger than the data.

We are creating a new product that may increase db usage 100 fold.
At this point our bandwidth cost will increase so we may use this
backup service from a freebie (part of support agreement) to a
paid model.

I'm glad I built this system.  I've had to restore some servers and
replace some using the data we've backed up.  I think Sid Lane
gave the presentation at ALE NW on MySQL replication.  I attended
that talk and then implemented.  The only issue I ran into was the
"One slave per master" issue.  This was easily solved with UNIX
know-how and perl.  I basically placed every slave instance on the same 
server using a different TCP port.   Management of this was
a headache so I wrote Perl programs that gave me CLI tools for
access, backup, creation, deletion, startup, etc of all these instances.
I can access the slave by customer name thanks to XML::Simple in
perl.  This was a bit difficult to get working but the ability to run all
these slaves on one server was cheaper than one server per customer.
It may not work for larger databases and higher transactions.