I made a snapshot image copy of my entire server (OS and all) and restored it to an identical provisioned server. Everything appears to work except that I cannot access site1.local site no matter what I try.
I have edited out all site domain references and ssl cert info in site_config.json
I have done “bench setup nginx” and then reloaded nginx
I have restored a backup of the data taken just prior to the snapshot
I have restarted mysql and even reboot the server several times
Nothing I tried would gain me access to the site through a user interface. I always get the “Sorry, We will be back soon” error screen.
However, if I create another site with “bench new-site [new-site-name]” and restore by backup to that site it works just fine.
This leads me to believe that the snapshot image does not keep the active sql database intact and may be causing issues. So… what I was thinking was that I might be able to get the system back to normal by doing the following:
use “bench new-site” command to create another tenant on the system
switch the site_config.json between the new tenant to site1.local
(this should switch the site pointers to the databases, I think…)
use “bench setup supervisor” to get everything back in order then update supervisor
use “bench setup nginx” to reset the site ids and reload gninx
then delete the extra tenant leaving only site1.local with the new datadase
Has anyone done anything like this?
Does anyone foresee a problem in trying this?
Is there “another” way to replace a complete database for site1.local in erpnext?
Or is there a way to possibly repair the database after the snapshot image restore?
Are you using bench restore or mysql -u root -p --verbose mysitedb < mysitedbbackup.sql? I’ve had better luck with the mysql version for large db restores because it won’t time out.
Also, naming your site site1.local as the default site across all your servers is a recipe for a recipe for disaster. Give your sites meaningful names, save yourself some pain.
I use bench to set a custom domain name for my sites. However, when you do that it does not alter the default site1.local name in the system, it just adds the new URL domain name to site_config.json
My problem is that the restored snapshot images are not working on boot-up. Each time I have done this there is a problem with the database in site1.local and I have to create a new tenant in order to have a working database. That in turn leave a dormant and broken database in the site1.local site that can never be used again.
I was hoping to find a way to “replace” the broken database in the default site so I do not have to keep the broken version.
Does that make sense?
Also I use “sudo bench --force --site site1.local restore /path_to_backup.sql” as my restore command. I have never thought about using a direct mysql command for restoring the data. This might be worth a try, but the same data currently has no problems with the bench restore command into another tenant site.
As for naming my sites…
I didn’t think it was valid as a practice to alter the site1.local name?!?
Wouldn’t that cause problems elsewhere in the system?
Is it just as simple as renaming the site directory in ~/frappe-nexr/sites?
Please explain a bit how you do it in your installations.
Anyway… I am still looking for a way to replace a broken database associated with the site.
(Or even a way to repair the current database)
The “broken database” bit is hard. My guess is that you have a version mismatch and I know you’re working against a pinned version; this complicates it because you can’t just do a “bench update” and let the system try to correct itself (and it won’t help with a borked database anyway).
I assume you’ve tried to migrate the broken database?
I name nothing site1.local anymore; I also specifically name the database. I start by naming the bench on install. Personally, I just grab something from a long list of tree names for development or research or personal use or I name it after my customer.
Ahhh… Ok. I can see where this would be easier to maintain. I have not tried any of this before. I have always used the default install and the added domains to the default later.
But, naming the database is something that would make maintenance easier to handle. While I am not the guy that could work that out on my own, I will still look into it further. Right now, I am just fortunate to be able to understand just enough about using the easy install.py script.
It sure would be nice if the database name and the site name could be called out as switches (like --production and --user) of the install script. Otherwise I think it would require a better understanding of how to do an install manually in order to create those changes as you go about the install process.
Thanks for the heads up about this even being possible. It makes for something else I need to educate myself on.
No. I have a valid backup of it prior to the move. That is why I was looking for a way to just replace it and then restore my backup. I tried restoring to the broken database and it didn’t go very well.
I really didn’t want to blow up the whole installation and start over, so I was trying to find a way to preserver all of my customized work and still get a valid database back in play.
Someone can correct me if I’m wrong but I believe database name will be the same as site name. If it isn’t, you can always use easy install script with the --without-site switch and then manually create a new site using the following commands
Ok, now I feel dumb. I’m always trying to over think this stuff.
Thanks for explaining it to me @felix I was pretty much lost on the whole meaning. It makes perfect sense now. Never had considered a purpose to changing the name of the directory.
Ok, now I feel dumb. I’m always trying to over think this stuff.