A function to transfer vbucket from one replicaset to another #2

knazarov · 2017-12-20T17:04:36Z

Implement vshard.storage.transfer(vbucket_id, new_uri) which will transfer a virtual bucket from the current replicaset to another:

Function checks that both nodes are masters
Bucket is transferred in the batch mode using the single CALL (i.e. no partial transfers)
Old replicaset should fail all WRITE operations during the transfer
Two-phase operation should be used to change _vbucket table after the transfer
If COMMIT fails on one of the nodes, when just do nothing for now

Receiving buckets should be garbaged but sending buckets should be checked against its destination. Fixed #2

Recovery fiber tracks buckets, which can not be sent during too long time. It periodically tries to learn their status on destination replicasets and either activates them back or makes them garbage. Closes #2

@TarantoolBot

Closes #207 @TarantoolBot document Title: vshard.router.bucket_id_strcrc32() and .bucket_id_mpcrc32() vshard.router.bucket_id() is deprecated, each its usage logs a warning. It still works, but will be deleted in future. Behaviour of the old bucket_id() function is now available as vshard.router.bucket_id_strcrc32(). It works exactly like the old function, but does not log a warning. The reason why there is a new function bucket_id_mpcrc32() is that the old bucket_id() and the new bucket_id_strcrc32() are not consistent for cdata numbers. In particular, they return 3 different values for normal Lua numbers like 123, for unsigned long long cdata (like 123ULL, or ffi.cast('unsigned long long', 123)), and for signed long long cdata (like 123LL, or ffi.cast('long long', 123)). Note, this is important! vshard.router.bucket_id(123) vshard.router.bucket_id(123LL) vshard.router.bucket_id(123ULL) Return 3 different values!!! For float and double cdata (ffi.cast('float', number), ffi.cast('double', number)) these functions return different values even for the same numbers of the same floating point type. This is because tostring() on a floating point cdata number returns not the number, but a pointer at it. Different on each call. vshard.router.bucket_id_strcrc32() behaves exactly the same, but does not log a warning. In case you need that behaviour. vshard.router.bucket_id_mpcrc32() is safer. It takes a CRC32 from MessagePack encoded value. That is, bucket_id of integers does not depend on their Lua type. However it still may return different values for not equal floating point types. That is, ffi.cast('float', number) may be reflected onto a bucket id not equal to ffi.cast('double', number). This can't be fixed, because a float value, even being casted to double, may have a garbage tail in its fraction. Floating point keys should not be used to calculate a bucket id, usually. P.S. #1: bucket_id_mpcrc32() in case of a string key does not encode it into MessagePack, but takes hash right from the string. This does not affect consistency of the function, but makes it as fast as bucket_id_strcrc32(). P.S. #2: be very careful in case you store floating point types in a space. When data is returned from a space, it is cased to Lua number. And if that value had empty fraction part, it will be treated as integer by bucket_id_mpcrc32(). So you need to do explicit casts in such cases. Example of the problem: s = box.schema.create_space('test', {format = {{'id', 'double'}}}) _ = s:create_index('pk') inserted = ffi.cast('double', 1) -- Value is stored as double. s:replace({inserted}) -- But when returned to Lua, stored as Lua number, not cdata. returned = s:get({inserted}).id type(returned), returned --- - number - 1 ... vshard.router.bucket_id_mpcrc32(inserted) --- - 1411 ... vshard.router.bucket_id_mpcrc32(returned) --- - 1614 ...

@TarantoolBot

Closes #207 @TarantoolBot document Title: vshard.router.bucket_id_strcrc32() and .bucket_id_mpcrc32() vshard.router.bucket_id() is deprecated, each its usage logs a warning. It still works, but will be deleted in future. Behaviour of the old bucket_id() function is now available as vshard.router.bucket_id_strcrc32(). It works exactly like the old function, but does not log a warning. The reason why there is a new function bucket_id_mpcrc32() is that the old bucket_id() and the new bucket_id_strcrc32() are not consistent for cdata numbers. In particular, they return 3 different values for normal Lua numbers like 123, for unsigned long long cdata (like 123ULL, or ffi.cast('unsigned long long', 123)), and for signed long long cdata (like 123LL, or ffi.cast('long long', 123)). Note, this is important! vshard.router.bucket_id(123) vshard.router.bucket_id(123LL) vshard.router.bucket_id(123ULL) Return 3 different values!!! For float and double cdata (ffi.cast('float', number), ffi.cast('double', number)) these functions return different values even for the same numbers of the same floating point type. This is because tostring() on a floating point cdata number returns not the number, but a pointer at it. Different on each call. vshard.router.bucket_id_strcrc32() behaves exactly the same, but does not log a warning. In case you need that behaviour. vshard.router.bucket_id_mpcrc32() is safer. It takes a CRC32 from MessagePack encoded value. That is, bucket_id of integers does not depend on their Lua type. However it still may return different values for not equal floating point types. That is, ffi.cast('float', number) may be reflected onto a bucket id not equal to ffi.cast('double', number). This can't be fixed, because a float value, even being casted to double, may have a garbage tail in its fraction. Floating point keys should not be used to calculate a bucket id, usually. P.S. #1: bucket_id_mpcrc32() in case of a string key does not encode it into MessagePack, but takes hash right from the string. This does not affect consistency of the function, but makes it as fast as bucket_id_strcrc32(). P.S. #2: be very careful in case you store floating point types in a space. When data is returned from a space, it is cased to Lua number. And if that value had empty fraction part, it will be treated as integer by bucket_id_mpcrc32(). So you need to do explicit casts in such cases. Example of the problem: s = box.schema.create_space('test', {format = {{'id', 'double'}}}) _ = s:create_index('pk') inserted = ffi.cast('double', 1) -- Value is stored as double. s:replace({inserted}) -- But when returned to Lua, stored as Lua number, not cdata. returned = s:get({inserted}).id type(returned), returned --- - number - 1 ... vshard.router.bucket_id_mpcrc32(inserted) --- - 1411 ... vshard.router.bucket_id_mpcrc32(returned) --- - 1614 ...

rtsisyk pushed a commit that referenced this issue Dec 28, 2017

Recovery bucket on master activation

821a54a

Receiving buckets should be garbaged but sending buckets should be checked against its destination. Fixed #2

rtsisyk closed this as completed in f046e57 Jan 17, 2018

Gerold103 changed the title ~~I'm forced to use login/password in URI specification~~ A function to transfer vbucket from one replicaset to another Jan 17, 2018

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

A function to transfer vbucket from one replicaset to another #2

A function to transfer vbucket from one replicaset to another #2

knazarov commented Dec 20, 2017 •

edited by Gerold103

Loading

A function to transfer vbucket from one replicaset to another #2

A function to transfer vbucket from one replicaset to another #2

Comments

knazarov commented Dec 20, 2017 • edited by Gerold103 Loading

knazarov commented Dec 20, 2017 •

edited by Gerold103

Loading