-
Notifications
You must be signed in to change notification settings - Fork 11k
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
Cache Database Driver not Following Database "Sticky" Setting #22763
Comments
You are running Laravel I did the PR for sticky writes to Laravel Try upgrading, then let me know if you have any issues. |
I don't have time to upgrade my whole app, but I may look at using your patch in the meantime. Do you have the PR number handy? |
Here it is: #20445 |
I am newer to laravel, but is there any chance it would get backported to the 5.4.x version, or is the sole answer to upgrade to 5.5? I can do some testing to get a PR for 5.4 if that is "a thing." |
It's up to Taylor - but I would suggest the odds are very low (almost zero).
The time you spend backporting the feature and testing it - you could just upgrade to |
Ok. I will look into upgrading when I have time. |
Description:
It appears the database driver for the cache is not obeying the database sticky setting (which points all reads on a given request to the write host if the session had any writes).
Using Elastic Beanstalk and an RDS backend, using the read replicas (which typically have a delay of about 20 ms), I have a section of code which ensures the cache is working on deploy. The following code fails for me whenever I'm using a read replica.
This test code does not show the key as deleted. However, if I add a sleep longer than the replication delay, it works as expected - which is why I assume this is a sticky issue.
Note that this issue does not show itself with a single DB server.
The text was updated successfully, but these errors were encountered: