About the trap that the database (DB) becomes unusable due to Docker update
Hi, this is Teppei Mimachi.
In the case I wrote last time After updating to Docker 3.0.0, something did not start --Qiita,
The story is derailed, but downgrading to 2.5. Series has definitely solved the error in 3.0.0 this time. Regarding 2.5.0 (another error occurred), I will write an article if I have a chance, but since I probably do not do it like a straightforward method, it seems to be an article like a diary, so I am wondering whether to write it.
I wrote ..., but the last time I posted the article was 2020/12/12, and today is New Year's Eve on 2020/12/31.
It's been a while since I've had a lot of days left, but I'd like to introduce the __ method that is probably not the same as the above __ method.
What is the non-straightforward method?
Environment construction from __1 __ or more !!!
Yes, that's really it. It's not a big deal ...
But this is not enough, so if you want to go deeper, After rebuilding the environment with Docker-compose, in order to completely restore the contents of the Rails application (contents of MVC model etc.), I think that it is necessary to move from the old Rails application that was created halfway to the new Rails application. However, The file you copied and pasted at that time
- Replace all app directories
- Replace all test directories
- Replace all public directories
- Replace all db directories
- Replace all but datebase.yml in the config directory
With this, I was able to renew the DB and create the same Rails application.
In addition, when changing the application name, There should be no problem if you refer to Until you change the Rails app name and change the GitHub repository name --Qiita.
In my case, I slightly modified the app name from illustrations __ → __ illustration, so after changing the app name, I executed steps 1 to 5 above to recover.
What kind of error did you get?
Again, for more details, I would like you to read the previous article Matter that did not start after updating to Docker 3.0.0 --Qiita, but if you excerpt a part ...
By the way, my Docker version is 2.5.1 → 3.0.0 (this error occurred) → 2.5.0 (another error occurred) → 3.0.1 (because of the same error as in 2.5.0, we are working on it) It has become.
... ↑ This, __2.5.0 (another error occurred) → 3.0.1 (because it is the same error as in 2.5.0, we are dealing with it) __ ← This part __ another error __ , PG :: ConnectionBad I get an error.
By the way, at this time, I coped with it by rebuilding the environment, but a week later, the latest version called 3.0.2 came out, and when I updated it, the same PG :: ConnectionBad occurred again. It's gone.
What is PG :: ConnectionBad?
When I looked it up, I found various causes, but in summary, I can't connect to __postgresql! The error is __. Postgresql, which was previously available, can no longer be used by updating Docker. This is a problem ...
Conclusion
__Docker Preference> Experimental Features> Use gRPC Fuse for file sharing is turned off (it is on by default) __
After all, this is the answer.
By doing this, the database connection will be successful and PG :: ConnectionBad will not occur.
What is Use gRPC Fuse for file sharing? I thought, I searched with Google Translate, __Use gRPC Fuse for file sharing → (Japanese translation) Experimental function> Use gRPC fuse for file sharing __
Hmm ... I don't know.
Among the things I searched for, Recent (2020/08) Docker for Mac file access slow problem memo --Qiita ← This article was the most helpful, but this time To summarize after excerpting the directly connected part
A new file system called __gRPC-FUSE has been introduced, and it is ON by default, so in some cases, switch to the old one (osxfs) in the settings and use it. __
It will be. In other words, the usage of turning off Use gRPC Fuse for file sharing is a legacy method. It may need to be changed someday, but it will be at a later date ...
at the end
One question here arose in me.
First of all, this article was written as a memorandum for me personally, so I think the content was very difficult to convey, but what's more? As an additional note on the premise that it can be a neighbor
In the previous article After updating to Docker 3.0.0, something stopped working --Qiita
By the way, my Docker version is 2.5.1 → 3.0.0 (this error occurred) → 2.5.0 (another error occurred) → 3.0.1 (because of the same error as in 2.5.0, we are working on it) It has become.
From __2.5.0 (another error occurred) __, at this point
Error screen
Cannot start service ec-cube: Mounts denied
ERROR: Encountered errors while bringing up the project.
↑ This error has disappeared,
↑ I wrote this in the sense that an PG :: ConnectionBad error occurred.
Just in case at this time
I intended to turn off __Use gRPC Fuse for file sharing.
However, if Use gRPC Fuse for file sharing was turned off, the theory is that PG :: ConnectionBad should not have occurred when the Docker version was 2.5.0.
I thought, "Use gRPC Fuse for file sharing was turned off intention."
① Turn off Use gRPC Fuse for file sharing.
② Press Apply & Restart.
Press this __② Apply & Restart. Isn't it just because I forgot __?
I made a very rudimentary mistake.
Recommended Posts