(anonymous) wrote: > [...]
> Database replication came up yet again in the office hours. Many > developers (myself included) seem to be holding off on Labs until database > replication is up and running. The sooner this can happen, the better. But > the remaining sticking point seems to be cross-database joins, which > people in the office hours suggested using federated tables or application > logic to replace. It would help if the Labs folks could better explain > _why_ cross-database joins won't be supported (I think most developers > would agree with the reasoning) and offer better guidance and > documentation for how to work around this hurdle. (For example, what is a > federated table?) > [...] The problem with this decision is the effort spent and the insincerity. If database replication for Labs would have meant moving some dbxxx servers to labsdbxxx, adding the views existing on Toolserver and tightening some firewall rules, it could have been set up in a month, and any moaning about having to use federated tables would have been si- lenced by the minutes it would take to add another server to the cluster to increase performance compared to the years it takes at Toolserver. Or there could have been some new concept like Galera men- tioned by Nosy that eases maintenance because it is not some sparsely documented Solaris thingy in River style. But now the plan is to have two clusters (PreLabsDBDBS and LabsDB), use triggers to remove data and then (addition- ally!) views, end up with less functionality than the Toolserver while gaining nothing, and all that takes half a year to set up in a cloak-and-dagger way while publicly the need for cross-database JOINs is acknowledged. Tim _______________________________________________ Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
