Changes between Version 6 and Version 7 of SharedMemoryIPC

Apr 12, 2013, 7:14:00 AM (6 years ago)



  • SharedMemoryIPC

    v6 v7  
    267267recovers consistency.
    269 === 5.6 Full Data Source Reconfiguration ===
    271 Updating the entire configuration of data sources can be a bit more
    272 tricky.  We'll probably first need to introduce a concept of
    273 generation ID of configuration, which will be managed by the cfgmgr
    274 per module basis.  Processes referring to the configuration of the
    275 same module (like "data_sources") use the generation ID of that
    276 module's configuration so they can determine which version of config
    277 is referred to in case of migration.  On top of this, both the manager
    278 and readers will keep two sets of data source clients (and associated
    279 states), and performs operation for the new version of the set just
    280 like the initial start up, while using the current set.  When
    281 migration is fully completed the old version of the set (and maps)
    282 will be discarded.
    284 More details will have to be considered, though.  They are still quite
    285 open.
    287 === 5.7 Rebuild Initial Map File On Demand ===
     269=== 5.6 Rebuild Initial Map File On Demand ===
    289271The described scenario so far implicitly assumed that the created/existing
    295277original master file(s)).
    297 Details of this are quite open, too.
     279Details of this are quite open.
     281== 6. Full Data Source Reconfiguration ==
     283Updating the entire configuration of data sources will be a bit more
     284tricky.  This is a rough sketch of initial ideas on how it would work.
     285While it looks like workable, more details will probably have to be
     288=== 6.1. Configuration generation IDs ===
     290First, we'll need a concept of generation ID of configuration, which
     291will be managed by the cfgmgr per module basis.  Processes referring
     292to the configuration of the same module (like "data_sources") use the
     293generation ID of that module's configuration so they can determine
     294which version of config is referred to in case of migration.
     296Generation IDs monotonically increase and the latest one will be saved
     297in the configuration DB file.
     299=== 6.2. Memory Manager Behavior ===
     301The Memmgr now manages sets of data source clients and mapped files
     302per generation ID of the "data_sources" configuration.  Memmgr keeps
     303a set of a particular generation ID as long as some reader still uses
     304a memory segment of that generation.
     306segment_info_update and its ack message now contain the corresponding
     307generation ID.
     309mapped file names would now include the generation ID, too, e.g.
     310zone-mapped-in-sqlite3-42.0 where "in" is RR class, "sqlite3" is the
     311data source name, and 42 is the generation ID.
     313When the memmgr receives a configuration update for full data source,
     314it will create a whole new set of data source clients and mapped files
     315(so, during the migration we'll at least maintain 4 mapped files per
     316data source), and then send segment_info_update message to all readers
     317for all mapped segments.  It waits until it gets ack from all
     318outstanding updates.  On completion, the memgmr can be sure all
     319readers now use the new generation of segments, so it can discard
     320any information including mapped segments of older generations.
     322=== 6.3. Reader Behavior ===
     324Likewise, readers maintain sets of data source client lists per
     325generation ID.
     327When a reader receives a configuration update for full data source,
     328it tries to complete all WAITING segments for the corresponding client
     329list, just like the initial setup.  When all segments are set,
     330it swaps the new and old sets, wait until the old one is cleaned up,
     331*then* respond to the latest segment_info_update message (the ordering
     332is important because the memmgr will assume the reader does not use
     333the old generation of segment anymore on receiving the ack).
     335It would be possible that a reader receives a segment_info_update for
     336a generation ID older (smaller) than the generation of its first data
     337source configuration.  It happens if a reader joins the system later
     338than others immediately followed by a configuration update.  the
     339reader would only get the latest generation ID from config manager,
     340while memmgr still doesn't get that generation of config.  In such a
     341case, the reader can simply respond to the update.
     343It would also be possible that a reader receives a segment_info_update
     344for a generation ID newer (larger) than its latest generation.  This
     345means a configuration update has been delivered to memgmr and is also
     346coming to the reader but has not arrived.  In this case, the reader
     347should keep the update message (pending ack) until it gets the
     348corresponding configuration update.  As long as the system is working
     349correctly this event should eventually happen.  At that point the
     350reader can resume handling the saved update message and respond to it.