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

Feature Request: emit a metric and log when VSchema contains unrecognized parameters #12476

Closed
maxenglander opened this issue Feb 24, 2023 · 1 comment

Comments

@maxenglander
Copy link
Collaborator

maxenglander commented Feb 24, 2023

Feature Description

In some cases when the VSchema contains parameters which are not understood by VTGate, VTGate will happily accept the VSchema without emitting any metrics or logs indicating that the VSchema contains unknown fields.

To see evidence of this, apply a VSchema with an extra lookup vindex param:

{
  "sharded": true,
  "vindexes": {
    "my_idx": {
      "type": "lookup",
      "params": {
        "from": "my_col1",
        "table": "my_tbl.my_col_idx",
        "to": "keyspace_id",
        "unknown_param": "hello_world"
      },
      "owner": "messages"
    }
  }
}

As far as I can tell (could be wrong!) VTGate doesn't consider this unusual, although it's possible that may vary from one vindex type to another.

It would be great if VTGate could emit a metric and a logging statement when it encounters fields in the VSchema which it does not understand.

Could make this backwards compatible with a VTGate param like --vschema-strict-mode=disable|warn|error:

  • Disable is current behavior.
  • Warn emits logs and metrics.
  • Error emits logs and metrics, and maybe does something else like panic or put VTGate into non-serving state.

Use Case(s)

Here's a use case where this kind of thing would be pretty useful:

  1. A database VSchema is using a performance-impacting vindex param that VTGate understands, everything is good.
  2. Database is rolled into a binary that for some reason doesn't understand that vindex param.
  3. VTGate keeps processing queries, but performance takes a hit.

With the right metrics/logs, and operational team could catch this issue in a dev or staging database before it becomes a problem in prod.

@maxenglander
Copy link
Collaborator Author

Superceded by #13041

This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants