Heroku shared database not resetting - heroku

Trying to reset my Rails app's shared database on Heroku.
Doing the following appears to work.
heroku pg:reset SHARED_DATABASE --confirm rabid-raccoon-2000
I get: Resetting SHARED_DATABASE (DATABASE_URL)... done
And running heroku run rake db:migrate after that appears to work as well. But when I run heroku run console, or try to use the app, it does not reflect the changes (it still uses an ancient db schema- even right after I reset it).
I've tried this with both the free 5mb free db, as well as with the $15 shared db, both to no avail. No idea what db it's working with.
My database.yml is checked into version control, but I don't see how that can be a problem.

Just deleted the app and started over. Explanations are welcome.

Just a thought... I followed the directions here to set up a beta postgresql database. The plus is that it gives me direct access to the database so I can change anything needed by my tables.
I then removed the generated .sql file with "git rm conf/evolutions/default/1.sql," committed and pushed to heroku. Happily, the app is now working!
This issue is very frustrating, especially since it mostly affects people using Heroku for the first time (w/ the shared database). It wasn't the database script since it worked just fine on the local dev database. Hope this helps you out for next time.

Related

discord.py how to make a JSON file work on Heroku

When I host the bot using Heroku it no longer calculates the JSON files (even if it makes them work they do not appear) and when I restart it is as if nothing had happened and reset everything.
How can I do?
Heroku does not store changes made to files. Heroku dynos restart every once in a while, and that is when data is lost; redeploying the app can also cause the data to be lost. Using a third-party database, such as MongoDB is recommended.

Trying to setup heroku app on my pc

I am going through the getting started guide with heroku and I hit a snag, cannot seem to access the remote database it connects but there is no database name. I have installed postgres sql 9.5 locally but attempting to push the local database I created fails also and when i run heroku pg:info it never responds.
I am going through the documentation but there is a lot of it, so hopefully some psql wizard will see this and go, oh this is what he is doing wrong and let me know.
It's likely that you have not "Created" the database. rake db:create - This needs to be done on Heroku's servers and your local machine.
Not quite correct,I am not using ruby, one major caveat I did not notice initially is that I was not in the bash shell which might have been part of my problem, what i wound up doing was connecting to the postgresql remote instance from my local install using pgadmin and creating the table manually from there. I had to get the connection info which I obtained by using heroku pg:credentials DATABASE which gave me the info I needed to add the server in pgadmin, you do need to check ssl for that within the tool, and it helps to add the database name to restricted so you see only your database, not the whole 10 gazillion they have in production :) I hope this helps anyone else that has the same problem.
Thanks

Trouble Migrating from Shared DB to Dev Plan

I just followed the steps to migrate my very small shared db to Heroku's new "dev" plan. Everything went very smoothly until I tried $ heroku addons:remove shared-database
I received the following error:
$ heroku addons:remove shared-database
-----> Removing shared-database from [my_app]... failed
! Shared databases cannot be removed
I have confirmed that my DATABASE_URL matches my HEROKU_POSTGRESQL_[COLOR]_URL, and that my app is fully functioning.
I work at Heroku on the Data team. We're sorry about that: the problem you observed was a temporary problem on our end, not a problem with your code. Please try again, it was an issue on the bamboo stack specifically.
As an aside, consider using the cedar stack. :)

Heroku: rogue transfer in progress

I started a migration on Heroku last night that gave me no feedback for hours, and which I eventually stopped because it wasn't clear if the system was even doing anything.
Ever since, it's been a nightmare. I cannot access the relevant database tables in heroku console, I can't migrate, rollback, or use pgbackups.
Helpfully, pgbackups gave me a one line explanation just now:
a transfer is currently in progress
This I assume is the migration I tried to execute hours ago. How can I stop whatever Heroku is doing so I can do a quick restore and get back up and running?
You can remove the problem backup stuck in the "a transfer is currently in progress" by finding the name of the backup and then destroying it. E.g.
heroku pgbackups
My problem backup was listed like this:
b210 | 2013/01/02 12:29.33 | unknown | DATABASE_URL
So to destroy it I just did:
heroku pgbackups:destroy b210
It removed the problem backup for me so I could get on with using pgbackups again properly.
I just had this problem too. Found an easier way of fixing it - briefly remove the pgbackups addon.
heroku addons:remove pgbackups
heroku addons:add pgbackups
WARNING as mentioned in the comments below, this will destroy all extant backups!
I accidentally did a transfer from my COLOR_URL database to my DATABASE_URL which was the same database. heroku pgackups:transfer let this happen which caused the main database to get stuck in
a transfer is currently in progress
I fixed it by looking at the process list pg:ps and killing all connections pg:killall
After doing this and looking at pg:ps the process list was empty and I was free to use the main database again with pgbackups.
NOTE this could be a destructive operation so make sure you have a snapshot before you do this.
The real solution is to contact Heroku support and have them kill the rogue process for you. They say they are re-architecting pgbackups to give users more control.
It never became clear what happened - after a day or so I was able to interact with heroku console, but I was never able to run another migration. This is what I did:
Renamed my app to something else.
Created a new app in its place, checking the stack was the same, and copying over all add-ons and domains.
I restored the database from pgbackups (highly recommended if you're not using this add-on).
This fixed the problem. Note: Be careful to check that your pgbackup doesn't cause unacceptable data loss.

Hot deploy on Heroku with no downtime

A bad side of pushing to Heroku is that I must push the code (and the server restarts automatically) before running my db migrations.
This can obviously cause some 500 errors on users navigating the website having the new code without the new tables/attributes: the solution proposed by Heroku is to use the maintenance mode, but I want a way with no downside letting my webapp running everytime!
Is there a way? For example with Capistrano:
I prepare the code to deploy in a new dir
I run (backward) migrations and the old code continue to work perfectly
I swith mongrel instance to the new dir and restart the server
...and I have no downtime!
You could setup a second Heroku app which points to the same DB as your primary production app and use the secondary app to run your DB migrations without interrupting production (assuming the migrations don't break the previous version of your app).
Let's call the Heroku apps PRODUCTION and STAGING.
Your deploy sequence would become something like:
Deploy new code to STAGING
git push heroku staging
Run database migrations on STAGING (to update PROD db)
heroku run -a staging-app rake db:migrate
Deploy new code to PRODUCTION
git push heroku production
The staging app won't cost you anything since you won't need to exceed Heroku's free tier and it would be pretty trivial to setup a rake deploy script to do this for you automatically.
Good luck!
If you're able to live with two versions of the same app live at the same time, Heroku now has a preboot feature.
https://devcenter.heroku.com/articles/preboot
The only method to improve the process somewhat is what this guy suggests. This is still not a hot deploy scenario though:
http://casperfabricius.com/site/2009/09/20/manage-and-rollback-heroku-deployments-capistrano-style/
One thing I would suggest is pushing only your migrations up to Heroku first and running them before you push your codebase. This would entail committing the migrations as standalone commits and manually pushing them each time (which is not ideal). I'm very surprised there is not a better solution to this issue with all of the large apps hosted on Heroku now.
You actually will have some downtime when Heroku restarts your app. They have a new feature called Preboot that starts up new dynos before taking out the old ones: https://devcenter.heroku.com/articles/labs-preboot/
As for database migrations, that article links to this one on how to deal with that issue: http://pedro.herokuapp.com/past/2011/7/13/rails_migrations_with_no_downtime/
I first commit the migrations, run them, then push the rest of the code. Add a single file like so:
git commit -m 'added migration' -- db/migrate/2012-your-migration.rb
Heroku can't deploy by capistrano. You are block by tool released by heroku.
The no downtime system is impossible in all cases. How change your schema with big change without stop your server. If you don't stop it, you can avoid some change and your database can be inconsistent. SO the using of maintenance page is a normal solution.
If you want a little solution to avoid problem is a balancing in two server. One with only read database during your migration. You can switch to this instance during your migration avoiding the maintenance page. After your migration you come back to your master.
Right now I don't see any possibility to do this without downtime. I hate it too.
This console command does it in the smallest amount of time I can think of
git push heroku master &&
heroku maintenance:on &&
sleep 5 &&
heroku run rails db:migrate &&
sleep 3 &&
heroku ps:restart &&
heroku maintenance:off
git push heroku master to push the master branch to heroku
heroku maintenance:on to put on maintenance so no 500s
sleep 5 to let the dynos start up the new code (without it, the migration might fail)
heroku run rails db:migrate to do the actual migration
heroku ps:restart out of experience the restart makes sure the new dynos have the latest schema
heroku maintenance:off turns of the maintenance
You might have to add -a <app name> behind all heroku commands if you have multiple apps.
Just one command will run these in series in terminal on Mac OSX.

Resources