On 19/06/06, Marco Rota <marcor(a)sorint.it> wrote: Install the extension plus dependencies, then insert appropriate markup into the desired template page. Rob Church

On 19/06/06, Marco Rota <marcor(a)sorint.it> wrote: Contact the writer of the extension and ask them to support wiki markup as part of the extension input? Rob Church

On 19/06/06, Tels <nospam-abuse(a)bloodgate.com> wrote: Then have a selective parse done; call the individual functions for brace substitution. Rob Church

Moin, On Monday 19 June 2006 18:39, Gregory Szorc wrote: I don't think this is the right way. The parser should handle this, not every extension re-inventing the parsing/replacing parameter handling etc. This only leads to code duplication with all the negative side effects. Best wishes, Tels -- Signed on Mon Jun 19 20:39:44 2006 with key 0x93B84C15. Visit my photo gallery at http://bloodgate.com/photos/ PGP key on http://bloodgate.com/tels.asc or per email. "Not King yet."

It is also possible to use PHP's session_set_save_handler function to store sessions elsewhere, say in a database table. See http://php.net/session_set_save_handler for more info. In response to the original question, you are probably also curious about database clustering. There has been some talk of this on the list in the past. However, I don't recall anybody ever saying they have set up a MySQL cluster with MediaWiki. However, it should be possible to set up MySQL with multi-master replication. Hopefully MySQL 5.1 will handle all of the current shortcomings, but we will have to wait and see... Gregory Szorc gregory.szorc(a)gmail.com

On 6/19/06, Rob Church <robchur(a)gmail.com> wrote: I thought Wikimedia uses MySQL replication, not clustering. MySQL clustering uses main memory to store tables. Somehow I don't think the Wikimedia servers have that much memory. BTW, MySQL 5.1 will finally support disk-based clustering. Even then, there is still the issue of FULLTEXT indexes in cluster mode. Does the cluster storage engine support FULLTEXT indexes? Greg

Hello, You're slightly wrong. We have enough memory to store our mysql core database in memory. Yes, for non-indexed data. We don't use FULLTEXT indexes on live site anyway. It's pure InnoDB, and search is offloaded to Lucene. Anyway, Cluster is designed to handle zillions of small transactions per second without data loss, it could work as a solution for session storage (and it is used that way on several biggish sites). On the other hand, our access pattern would not like distributed database that much as there're quite a lot of batch reads. We already solve the 'clustering' by simply having replicated sets of database nodes working with different workloads / patterns if needed. We're quite happy with current setup, I guess ;-) Domas

Unless its multi master replication then they are all writable, aren't they? Arthur arthur(a)astarsolutions.co.uk -----Original Message----- With replication, there is only one writeable node

Brion Vibber wrote: Ok, I get it. The master is listed in the wgDBServer variable, and the slaves in the wgDBServers array of arrays. Upon failure of the master, it's a manual process to get writes working again, but reads should function fine. Since I already have my wiki on a replicated 4.1 database, it's a whole lot less work than building a new MySQL 5.0 cluster from scratch with that large learning curve. Y'all have been most helpful! -- Daniel J McDonald, CCIE #2495, CNX, CISSP #78281 Austin Energy gpg Key: http://austinnetworkdesign.com/pgp.key Key fingerprint = B527 F53D 0C8C D38B DCC7 901D 2F19 A13A 22E8 A76A

Hi! Wikimedia database setup is slightly evolved already. We have multiple sets of databases (enwiki/others), and some slaves work only with particular datasets (like holbach, our 4GB box has only dewiki). Additionally we employ application servers in our text external storage role. So we have our own partitioning already. You can always ask MySQL to assist - they've got consultants who have lots of experience with mediawiki!!!! ;-) Domas