> On 26 Oct 2018, at 1:42 am, Dan Smith <d...@danplanet.com> wrote: > >> I guess our architecture is pretty unique in a way but I wonder if >> other people are also a little scared about the whole all DB servers >> need to up to serve API requests? > > When we started down this path, we acknowledged that this would create a > different access pattern which would require ops to treat the cell > databases differently. The input we were getting at the time was that > the benefits outweighed the costs here, and that we'd work on caching to > deal with performance issues if/when that became necessary. > >> I’ve been thinking of some hybrid cellsv1/v2 thing where we’d still >> have the top level api cell DB but the API would only ever read from >> it. Nova-api would only write to the compute cell DBs. >> Then keep the nova-cells processes just doing instance_update_at_top to keep >> the nova-cell-api db up to date. > > I'm definitely not in favor of doing more replication in python to > address this. What was there in cellsv1 was lossy, even for the subset > of things it actually supported (which didn't cover all nova features at > the time and hasn't kept pace with features added since, obviously). > > About a year ago, I proposed that we add another "read only mirror" > field to the cell mapping, which nova would use if and only if the > primary cell database wasn't reachable, and only for read > operations. The ops, if they wanted to use this, would configure plain > old one-way mysql replication of the cell databases to a > highly-available server (probably wherever the api_db is) and nova could > use that as a read-only cache for things like listing instances and > calculating quotas. The reaction was (very surprisingly to me) negative > to this option. It seems very low-effort, high-gain, and proper re-use > of existing technologies to me, without us having to replicate a > replication engine (hah) in python. So, I'm curious: does that sound > more palatable to you?
Yeah I think that could work for us, so far I can’t think of anything better. Thanks, Sam > > --Dan __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
