|
Sorry, I replied to Joseph only :
I'm looking for this kind of stuff too...
> > In any case, is it certain that the one mysqld will see the other one's
> > write, with the memory caches etc. As an example, "INSERT DELAYED" might
> > cause problems, as server A may do an "INSERT DELAYED" on a table in the
> > database, then server B may try to read from the same table before
> > server A decides to sync the on-disk database with the in-memory
> > database. Also, the in-memory indices may also be out of sync. Please
> > correct me if I'm wrong!
>
> we'll have to find out what is required to write out the changes to disk.
> I'm hoping it's either disconnecting from the table, or closing the
connection
> with the mysqld.
For now, my idea is to separate read-only queries from write queries :
* read queries could be dispatched by the Director to one of the mySQL
servers (I'm looking for the info for Oracle at this time but the problem is
the same and I'll have a mySQL project of this kind in a week or two).
* update/insert/delete queries could be done as many times as there are SQL
servers. This is at the application level. Don't know if stored procedures
can access other SQL servers. The application will be heavy to maintain,
will forbid some mySQL functionnalities but it has a slight chance to work.
Maybe the system will be slower than having a single mySQL server. I guess
it depends on the ratio #reads / #writes : the highest the ratio, the best
speed improvement.
I don't know if that would work. Nesting transactions on multiple servers
might cause troubles but it seems mandatory. On Oracle, sharing the disk is
not enough because of cache mechanisms (that's why they sell a parallel
server extension !). Really don't know how mySQL deals with this.
Anyone tested this ?
|
