[MXS-2251] Allow end-user specified classification Created: 2019-01-09  Updated: 2022-09-08  Resolved: 2022-09-08

Status: Closed
Project: MariaDB MaxScale
Component/s: QueryClassifier
Affects Version/s: None
Fix Version/s: N/A

Type: New Feature Priority: Major
Reporter: Johan Wikman Assignee: Todd Stoffel (Inactive)
Resolution: Won't Do Votes: 0
Labels: None


 Description   

If the MaxScale parser fails to parse a statement, it may be incorrectly classified (e.g. a statement that should be sent to master is sent to some slave, a statement that should be sent to one server is sent to all, etc.).

Fixing these kind of issues typically requires that the MaxScale parser is modified, which at minimum requires a new MaxScale release and occasionally may be time-consuming and hard to implement.

To allow end-users and support to make quick fixes, it would be valuable if:

  • it would be possible to specify a canonical statement and how it should be classified (to master, to some slave or to all)
  • MaxScale would consult that user-specified classification if it fails to parse a statement.

That way a failure of MaxScale to correctly classify a statement could quickly be addressed by end-users and support as a temporary measure until a proper fix is available.



 Comments   
Comment by markus makela [ 2022-04-25 ]

This is technically already implemented to some degree by the namedserverfilter: matching a specific query with a regex is doable but not as convenient as using the canonical form. The benefit of a regex over a canonical form is that you don't need an exact match for it to work.

Perhaps extending the namedserverfilter with a mechanism to match on the canonical form might be a refinement that makes it easier to use for this purpose. The users can extract the canonical forms from the output of maxctrl show qc_cache or by manually writing them. The output of maxctrl classify <sql> can also be extended to have the canonical form which would make it much easier to define them.

Generated at Thu Feb 08 04:12:46 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.