Super informative! Thank you Bryan and Jaime. I will take a look at that task and see if I can be of any help.
On Sat, May 9, 2020 at 1:38 AM Jaime Crespo <jcre...@wikimedia.org> wrote: > One clarification, > > While everything Bryan says is right, I have to say that the main factor > in not allowing writes on wikireplicas wasn't pain for administration > (which was real) as much as avoiding continuous blockage of data due to > other users creating long-running write queries (pain for users). As Bryan > says, indeed a read only service allows automatic load balancing to spread > the load, avoiding outages. Long running read queries can cause overload, > but not blocking. > > Creating regularly summary tables that are useful for several users is > something that I would like to explore, but as I mentioned here: > https://lists.wikimedia.org/pipermail/cloud/2020-April/001051.html there > is a lot of programming and a list of problems to solve before that could > be setup. This is right now not a priority, but like with every task on > Wikimedia (see the linked task), volunteer work could help speed it up 0:-). > > On Sat, May 9, 2020 at 3:01 AM Bryan Davis <bd...@wikimedia.org> wrote: > >> On Fri, May 8, 2020 at 3:01 PM Brooke Storm <bst...@wikimedia.org> wrote: >> > >> > No, the wikireplicas are read-only. >> >> There is slightly more context for this restriction in the blog post >> that announced the "new" Wiki Replicas databases in 2017 [0]. >> >> The prior generation of Wiki Replica databases did allow arbitrary >> table creation by users. This was both a powerful feature and a cause >> of pain for system administration. User created tables were not >> replicated across the cluster which meant that when system maintenance >> was performed tables or data would mysteriously vanish from the point >> of view of the user if traffic was routed to a different backend >> server. Data would also be irretrievably lost when a server >> experienced major system failures. It was a difficult decision for the >> Cloud Services and DBA teams to make to remove this useful feature, >> but doing so has allowed much greater ease of administration and by >> extension better availability and less replication drift issues for >> the wiki databases than was possible with the feature in place. >> >> [0]: >> https://phabricator.wikimedia.org/phame/post/view/70/new_wiki_replica_servers_ready_for_use/ >> >> Bryan >> -- >> Bryan Davis Technical Engagement Wikimedia Foundation >> Principal Software Engineer Boise, ID USA >> [[m:User:BDavis_(WMF)]] irc: bd808 >> >> _______________________________________________ >> Wikimedia Cloud Services mailing list >> Cloud@lists.wikimedia.org (formerly lab...@lists.wikimedia.org) >> https://lists.wikimedia.org/mailman/listinfo/cloud > > > > -- > Jaime Crespo > <http://wikimedia.org> > _______________________________________________ > Wikimedia Cloud Services mailing list > Cloud@lists.wikimedia.org (formerly lab...@lists.wikimedia.org) > https://lists.wikimedia.org/mailman/listinfo/cloud
_______________________________________________ Wikimedia Cloud Services mailing list Cloud@lists.wikimedia.org (formerly lab...@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/cloud
