Re: [Bug-gne]various random thoughts

[Hook]

Tom Chance wrote :
> > i am still in favour of only being able to add
> > articles to the master server.
>
> ditto. certainly until we have a simple mirror system
> set up. maybe u could talk to Paul
> Visscher (address@hidden) about mirroring... cuz gnu
> mirror all their www.gnu.org site, but they dont
> mirror SQL databases... hence we will have to have a
> gnu.org subdomain and so we wont get mirrored.
>
> I'm also still wondering about having the body of
> articles in the db cuz of db load. atm even on a
> fairly fast server it will take a while to fetch the
> whole article body when viewing it. as it is doing
> this, the rest of the db will be either out of action
> or slow, depending on how secure we want to make data
> transfers. So for the moment it will be fine but if
> any one server starts to get at all busy, it could
> cause problems. The alternative is to just plonk the
> body of each article as a text file in a folder and
> then use the db as an index, but then that's just not
> as fun :/

Why would the whole database slow down? My experience with MySQL shows that
it's usually fast enough to do most things, with the exception of thousands
of inserts per second into heavily indexed rows. That, I assume, isn't the
schema that you've got.

A MySQL server will need lots of ram and lots of CPU. MySQL doesn't allow
multiple front-end rdbms servers with the database available behind them
all - the recommended solution to that kind of problem involves replication
onto multiple slaves. In fact, that's probably the way to go anyway.

A master which allows inserts and updates (and potentially deletes too) and
handles the database admin functions. This replicates onto an array of
slaves, each on a separate machine. Accesses to the data from the outside
goes to the slaves not the master via a load-balancing setup (alteons or
somesuch). That way the master is pretty well protected and changing content
won't slow down client access.

Comments?

The Hooker