-
Notifications
You must be signed in to change notification settings - Fork 152
Description
Description
We currently have some requirements for Readyset to work:
https://readyset.io/docs/reference/configure-your-database
However, we do not enforce them in the code. We should check if upstream database is correctly configured from the get go before we start snapshotting.
As one example, if someone has binlog_format=STATEMENT
, we will first snapshot the table and later if we receive a replication event for that table as STATEMENT
, we will stop replicating.
Note: also add REA-4912
This needs to work for Private(standalone) and Cloud.
In case the new check finds a miss-match configuration / version we should decide what to do:
Abort - Stop readyset process.
- Pros:
- We will notice right away if something is not configured correctly.
- If things succeed, users are more likely to see a true benefit of Readyset
- Cons:
- Readyset will be down.
- This might create some friction in user/customer acquisition.
- When Shallow cache is implemented on Readyset, potentially Readyset would have shallow all the queries.
Continue/Proxy - Do not snapshot any table but keep online
- Pros:
- Readyset acts as a proxy
- Shallow cache will take care of the queries
- No downtime for customers
- Cons:
- This will silently looks like everything is ok and will require investigation on why deep caches are not created.
Change in user-visible behavior
Requires documentation change