On Wed, Apr 6, 2011 at 6:17 AM, Stewart Smith <[email protected]> wrote: > should have said what vBucket maps to what machine, the number of > vBuckets and the list of machines. i.e. all the information needed to > work out which machine to talk to.
Right. Infact my idea was to maintain this information client side only. The problem was updating the mappings when you relocate a bucket, but that seems solvable with your hint below. >>> The mapping can also change, and could quite easily be implemented for >>> moving a shard to a new machine. We'd just need a way in the server to >>> return that a database is read only (attempt r/w op on a shard, get back >>> "currently read only") while doing the migration. After migration, >>> ideally we could use an error saying "shard has relocated" at which >>> point the client could update its mapping and connect to the correct >>> server. Maybe something like this: When I relocate a vbucket, I just ask the clients to ping server which returns r/w status, and update their mappings accordingly. So the round trips would be only once - when you relocate. I bet the client_key thing in the protocol can be leveraged to this end. -- Anurag Priyam http://about.me/yeban/ _______________________________________________ Mailing list: https://launchpad.net/~drizzle-discuss Post to : [email protected] Unsubscribe : https://launchpad.net/~drizzle-discuss More help : https://help.launchpad.net/ListHelp
