-
-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
Magento 2 Recipe: Cache prefix generated different cache prefixes when deploying to multiple hosts #3790
Comments
@valguss Hope you have any suggestions how we could resolve this. |
For the moment i'd suggest disabling using the cache_prefixes |
@valguss, yes, I can get the release in sync quite easily. However I'm stuck with the first / "alias" part of the key. |
You could override the task in your
I've just updated
to
|
@valguss, thanks. We can do a workaround but would like to see this fixed in the official recipe as well and would like to contribute to a solution. Best practice is to have the same redis DB per environment. So in theory we could drop the "get('alias')" part of the prefix all together. Or we could use the "stage" of the host, so that the first part of the prefix is the same for all hosts in that stage. Can you just do get('stage') in order to get the host stage? |
Using stage sounds like a better solution. The premise I was going for was for our specific setup where staging sites sit on the same server as the live env, so was trying to make the key unique to each environment so that they didn't clash. Will get a PR up shortly to change it though. Thanks |
Stage sounds good to me. I get your use case and with using "stage" this still works. I do think it's better to use a different Redis database number for a test environment and a live environment when they are both on the same server. Something like this:
|
Now updated to check if stage is available and fall back to alias |
What do you think about something like this:
So
You don't actually need the previous number do you? And to sync accross installs, maybe you can use a static variable to generate it once?
|
This issue has been automatically closed. Please, open a discussion for bug reports and feature requests. Read more: [https://github.com//discussions/3888] |
1 similar comment
This issue has been automatically closed. Please, open a discussion for bug reports and feature requests. Read more: [https://github.com//discussions/3888] |
Not sure why this is being closed as the PR is still open. |
The bot went a bit wild I guess. Reopening. |
This issue has been automatically closed. Please, open a discussion for bug reports and feature requests. Read more: [https://github.com//discussions/3888] |
lol |
How good that we have bots to help us by taking over annoying tasks and taking some of the burden off our shoulders these days. I can't wait for AI to step in and help the bot to be even more productive for us. |
Apparently the bot was a bit drunk. Reopening. Let's see if the gets the hint :-P |
This issue has been automatically closed. Please, open a discussion for bug reports and feature requests. Read more: [https://github.com//discussions/3888] |
Ahh, I think @antonmedv has disallowed issues in general and just want to have discussion 👀 |
Maybe set exempt-issue-labels and tag it with one of those? https://github.com/actions/stale?tab=readme-ov-file#exempt-issue-labels |
@mautz-et-tong you're right, I hadn't seen that #3888 |
Yes. =) |
Situation:
We have Magento 2 projects which are load balanced between different servers. For instance 2 frontend web servers for visitors and a seperate backend service for the Magento backoffice. All servers point to the same Redis instance which is located on the database server. We're deploying with the configuration:
after: deploy:shared: magento:set_cache_prefix deploy:magento: magento:cleanup_cache_prefix
Actual result:
The set cache prefix is different per host because it will take the alias and release number. So for one server it will be:
production_web35_12_
And on the other server the prefix is set to:
production_web40_9_
Issue:
The issue is that cache will not be cleared correctly. The prefix should be the same for all 3 webservers in order for 1 webserver to clear the cache for the other two as well.
Expected result:
The generated cache key should be the same for all hosts within the same "stage" and release. So if we deploy to "stage" production to 3 webservers, the generated key should be the same for all 3 servers for Magento to work correctly.
Upvote & Fund
The text was updated successfully, but these errors were encountered: