Skip to content
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

Confusion around Keyspace APIs #8016

Open
limbooverlambda opened this issue Apr 2, 2024 · 3 comments
Open

Confusion around Keyspace APIs #8016

limbooverlambda opened this issue Apr 2, 2024 · 3 comments
Labels
type/question The issue belongs to a question.

Comments

@limbooverlambda
Copy link

limbooverlambda commented Apr 2, 2024

Bug Report

What did you do?

I am evaluating the Keyspace APIs that are supported by TiKV API v2 (https://github.com/tikv/client-rust). I am running TiUP locally. I created a non-default keyspace "foo" as follows:

curl -H 'Content-Type: application/json' \
      -d '{ "name": "foo"}' \
      -X POST \
      127.0.0.1:19165/pd/api/v2/keyspaces
{
    "id": 1,
    "name": "foo",
    "state": "ENABLED",
    "created_at": 1712076752,
    "state_changed_at": 1712076752
}%

Looking for the keyspaces:

curl 127.0.0.1:19165/pd/api/v2/keyspaces
{
    "keyspaces": [
        {
            "id": 0,
            "name": "DEFAULT",
            "state": "ENABLED",
            "created_at": 1712076651,
            "state_changed_at": 1712076651
        },
        {
            "id": 1,
            "name": "foo",
            "state": "ENABLED",
            "created_at": 1712076752,
            "state_changed_at": 1712076752
        }
    ],
    "

I am using the TiKV rust client and looks like all the operations are working against the "foo" keyspace.

Now, I decide to disable the "foo" keyspace as follow:

 curl -H 'Content-Type: application/json' \
      -d '{ "state": "DISABLED"}' \
      -X PUT \
      127.0.0.1:19165/pd/api/v2/keyspaces/foo/state
{
    "id": 1,
    "name": "foo",
    "state": "DISABLED",
    "created_at": 1712076752,
    "state_changed_at": 1712077470
}%

The keyspace foo is disabled:

curl 127.0.0.1:19165/pd/api/v2/keyspaces
{
    "keyspaces": [
        {
            "id": 0,
            "name": "DEFAULT",
            "state": "ENABLED",
            "created_at": 1712076651,
            "state_changed_at": 1712076651
        },
        {
            "id": 1,
            "name": "foo",
            "state": "DISABLED",
            "created_at": 1712076752,
            "state_changed_at": 1712077470
        }
    ],
    "next_page_token": ""
}%

Now I send the same operations to the disabled Keyspace.

What did you expect to see?

I expect all operations to fail for the disabled Keyspace. Both PD and Storage Node (tikv) should honor the disabled status of the keyspace and not return any results associated with keys prefixed with the keyspace identifier.

What did you see instead?

All operations are returning keys and values from the disabled keyspace.

What version of PD are you using (pd-server -V)?

Using Tiup /.tiup/components/playground/v1.13.1/tiup-playground --mode tikv-slim --pd.port 19165 --kv.config tikv.yaml

@limbooverlambda
Copy link
Author

Anyone who can shed some light on this?

@ystaticy
Copy link
Contributor

Hi @limbooverlambda,
Thank you for your issue.
The feature you mentioned has not yet been implemented in client-rust.If you're interested in contributing a PR to it,we would be very welcome!

@limbooverlambda
Copy link
Author

Thank @ystaticy . I will be more than happy to contribute. I am however a little unsure about the sequence of events here. Once a Keyspace is marked as disabled, any request from the client can still go through and end up in the TiKV node. If the data is present (the disabled Keyspace has not been GCed), TiKV will still return the data from the disabled keyspaces. In that case client_rust will not not be disabling the keyspace locally. Do we need a periodic polling mechanism for all the keyspaces cached by the client to ensure that they are still valid?

@rleungx rleungx added type/question The issue belongs to a question. and removed type/bug The issue is confirmed as a bug. labels Jun 14, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type/question The issue belongs to a question.
Projects
Status: Need Triage
Development

No branches or pull requests

3 participants