Hello, Am 19.09.2007 um 10:29 schrieb James Rutherford:
> A long time ago, a few of us looked into the feasibility of clustering > DSpace, and recorded the results here: > > http://wiki.dspace.org/index.php/HOWTO_Clustering > > There are three layers which you may want to cluster, each having a > different level of difficulty in implementation: filesystem > (relatively > easy), tomcat (still reasonably simple), and the database (much > harder). > The conclusion that I came to about clustering the database was > that to > do so with open source tools was, at the time, pretty much infeasible. I have no own experience with Clustering but think that the assessment of Slony on the page cited is rather pessimistic. Slony is the primary solution for clustering in the Postgres arena. The other two Java solutions sound great and are certainly good companions for DSpace, but with Slony you will get the support of the Postgres community. As I dont have own experience with this, I refrain from changing the wiki page, but I want to report some considerable different perceptions of the Slony feature set in the Postgres community. First, they say, that Slony is only one building block in a high availability scenario in the sense of unix tools that try to do one thing properly instead of being jack of all trades. You could complain about Postgres not supporting failover and loadbalancing by default if you are in search for a truly integrated solution. They say that Slony is very reliable in what it does. For automatic failover, they say that there are probably other changes required in such a case that need to be managed hand in hand and as such they delegate this task to another tool such as Networkmanagement or Clustermanagement with no special preference - further investigation needed. Schema changes are an issue during development but not while operating a HA cluster. The command line tool slonik can be used during updates. Connection brokering might be done by pgpool or pgbouncer. The points that Slony does not solve however are: Replication is available for bytea but not for LOB. The multiple master topology. Again, this might be managed during switchover triggered by an ex- ternal Management solution by promoting a former slave that was up to date to become the master. So in case Sequoia and Terracotta turn out not to be the way to go, then Slony deserves a second look. But I agree that all this doesnt sound to be a job for an afternoon. Bye, Christian ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ DSpace-tech mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dspace-tech
