New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[docdb] Regular DB special records could affect the correctness of a middle key calculation for split #10163
Labels
Projects
Comments
rthallamko3
changed the title
Regular DB special records could affect the correctness of a middle key calculation for split
[docdb] Regular DB special records could affect the correctness of a middle key calculation for split
Oct 18, 2021
robertsami
added a commit
that referenced
this issue
Nov 11, 2021
Summary: This diff enables automatic tablet splitting by default in 2.11.0 In addition, we set `txn_max_apply_batch_records` to its max value to effectively turn off this feature. We do this to avoid interaction with a known bug whereby ApplyTransactionState records adversely affect split key calculation. See #10163 Test Plan: Ran itest with no test failures Jenkins: rebase: 2.11.0 Jenkins: hot Reviewers: timur, rao, bogdan Reviewed By: bogdan Subscribers: jenkins-bot, ybase Differential Revision: https://phabricator.dev.yugabyte.com/D13828
robertsami
added a commit
that referenced
this issue
Nov 24, 2021
…t affect tablet splitting Summary: We currently have a bug whereby ApplyTransactionState records can throw off our split key calculation. This revision effectively turns off large transaction batching entirely. We should re-enable it once this bug is fixed. Test Plan: Jenkins Reviewers: bogdan, timur, rthallam Reviewed By: rthallam Subscribers: ybase Differential Revision: https://phabricator.dev.yugabyte.com/D13906
arybochkin
added a commit
that referenced
this issue
Feb 18, 2022
…ss of a middle key calculation for split Summary: The presence of special records inside regular RocksDB could affect the correctness of middle key calculation. Having a special key as the split key will affect the correctness of tablet spitting. Returning an error status is enough in that case as this will delay the tablet spitting (tablet will receive more records and this will lead to a different middle key being picked). Most likely this error will never be hit as the number of special records is negligibly small and they sort before any user record. Special keys are `(kTransactionApplyState, 7)` for regular DB, `(kExternalTransactionId, 8)`and `(kTransactionId, 'x')` for intents-db. This fix updates `Tablet::GetEncodedMiddleSplitKey()` to throw an error when a special key is selected as the middle key (and some other cases where a more sensible error is needed). Corresponding tests are also added both for hash and range partitioning as DocKeys are generated in a slightly different way depending on partitioning. Also several test routines were updated to provide handling with respect to current partitioning. Test Plan: ybd --cxx-test integration-tests_tablet-split-itest --gtest_filter "*TabletSplitSystemRecordsITest.GetSplitKey*" ybd --cxx-test integration-tests_tablet-split-itest ybd --cxx-test tablet_tablet-split-test ybd --cxx-test client_ql-tablet-test --gtest_filter QLTabletTest.GetMiddleKey Reviewers: timur, rsami Reviewed By: rsami Subscribers: mbautin, ybase Differential Revision: https://phabricator.dev.yugabyte.com/D15114
jayant07-yb
pushed a commit
to jayant07-yb/yugabyte-db
that referenced
this issue
Mar 8, 2022
…orrectness of a middle key calculation for split Summary: The presence of special records inside regular RocksDB could affect the correctness of middle key calculation. Having a special key as the split key will affect the correctness of tablet spitting. Returning an error status is enough in that case as this will delay the tablet spitting (tablet will receive more records and this will lead to a different middle key being picked). Most likely this error will never be hit as the number of special records is negligibly small and they sort before any user record. Special keys are `(kTransactionApplyState, 7)` for regular DB, `(kExternalTransactionId, 8)`and `(kTransactionId, 'x')` for intents-db. This fix updates `Tablet::GetEncodedMiddleSplitKey()` to throw an error when a special key is selected as the middle key (and some other cases where a more sensible error is needed). Corresponding tests are also added both for hash and range partitioning as DocKeys are generated in a slightly different way depending on partitioning. Also several test routines were updated to provide handling with respect to current partitioning. Test Plan: ybd --cxx-test integration-tests_tablet-split-itest --gtest_filter "*TabletSplitSystemRecordsITest.GetSplitKey*" ybd --cxx-test integration-tests_tablet-split-itest ybd --cxx-test tablet_tablet-split-test ybd --cxx-test client_ql-tablet-test --gtest_filter QLTabletTest.GetMiddleKey Reviewers: timur, rsami Reviewed By: rsami Subscribers: mbautin, ybase Differential Revision: https://phabricator.dev.yugabyte.com/D15114
arybochkin
added a commit
that referenced
this issue
Mar 18, 2022
…t the correctness of a middle key calculation for split Summary: Original commit: fb24aea / D15114 The presence of special records inside regular RocksDB could affect the correctness of middle key calculation. Having a special key as the split key will affect the correctness of tablet spitting. Returning an error status is enough in that case as this will delay the tablet spitting (tablet will receive more records and this will lead to a different middle key being picked). Most likely this error will never be hit as the number of special records is negligibly small and they sort before any user record. Special keys are (kTransactionApplyState, 7) for regular DB, (kExternalTransactionId, 8)and (kTransactionId, 'x') for intents-db. This fix updates Tablet::GetEncodedMiddleSplitKey() to throw an error when a special key is selected as the middle key (and some other cases where a more sensible error is needed). Corresponding tests are also added both for hash and range partitioning as DocKeys are generated in a slightly different way depending on partitioning. Also several test routines were updated to provide handling with respect to current partitioning. Test Plan: ybd --cxx-test integration-tests_tablet-split-itest --gtest_filter "*TabletSplitSystemRecordsITest.GetSplitKey*" ybd --cxx-test integration-tests_tablet-split-itest ybd --cxx-test tablet_tablet-split-test ybd --cxx-test client_ql-tablet-test --gtest_filter QLTabletTest.GetMiddleKey Reviewers: rsami Reviewed By: rsami Subscribers: ybase Differential Revision: https://phabricator.dev.yugabyte.com/D15830
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
The presence of special records inside regular RocksDB could affect the correctness of a middle key calculation. If we have more special records than regular records in the SST file - we might get a middle key that belongs to the special records key range.
From: @spolitov :
So, just throwing an error, in that case, should work and most likely is already happening, but we need to recheck and test this.
The text was updated successfully, but these errors were encountered: