From pgbackups documentation:
Note that capturing a backup does add some load on your database for the duration of the backup. How this impacts your application will vary with the size of your database and the nature of the app. Consider taking backups on a follower if there is a significant impact from running them on the master.
I know I can create a manual backup using the command heroku pgbackups:capture FOLLOWER_DATABASE_URL
But when I add the pgbackups addon through the website https://addons.heroku.com/pgbackups it comes with autoback that I don't know how to turn off. When installing the addon, it asks me which app to add it to, but not which database. I have no idea when the automatic backup will run, nor do I know which database it will run on, the primary or the follower.
The autobackup will run on the primary database -- you can only capture backups on a follower manually.
Related
Anytime my app goes to sleep and comes back on, I lose data in my database
And I'm not storing any media, it's just form data (texts)... I built the app on strapi and I've followed all their guidelines but it keeps happening. I'd be happy if anyone can help
Local data (files, db) is cleared after a Dyno restart because the Heroku File System is ephemeral. A Dyno is restarted (at least) every 24hrs.
In your case Strapi uses SQLite where data is saved in a local file.
Strapi suggests to configure Postgres on Heroku, alternatively you can use an external DB storage service.
First of all:
As you create content types with strapi it generates the code (= new files) for the according controllers/routes/services
Heroku does not persist data after a restart
After a restart strapi checks which content types exist in the code and deletes the tables of nonexisting types from the database.
Therefore, on Heroku you have to set up all your content types locally and connect to an external db (e.g. Heroku Postgres) but never strapi's default textfile based db.
Then push the generated files and finally deploy.
Thus, on Heroku you should always run in production mode. This way the option to alter content types is completely blocked and you will not run into the issue of data loss after a restart.
I'm trying to downgrade a heroku postgres db from standard to hobby basic. As I'm not fully using the web app currently but there is still some data in there that needs to be kept. How can I downgrade? (some downtime is fine).
Update: managed to setup and promote a new database based on the inststructions below, but i can't deprovision the old one.
heroku info shows:
Heroku's instructions for upgrading with pg:copy will also work for downgrading. Here's the summary:
Provision a new database
Enter maintenance mode to prevent database writes
Transfer data to the new database
Promote the new database
Exit maintenance mode
If your app isn't live (not being actively written to), you can skip the maintenance mode steps.
Once you've done that, you can deprovision your old database.
I'm fairly new to server administration. I have my Laravel app up and running and I want to make sure it has proper backups. I have researched some backup packages and I have settled on https://github.com/spatie/laravel-backup.
However, once the server fails, I need to know how to use the most recent backup (which will be on AWS S3) to restore the database on the rebuilt server. Are there any suggestions for guides on how to do this? I can't seem to find any unless it doesn't really require much learning and instead just a couple mySQL commands.
Thanks!
I would use replication and within Laravel i would try to switch connection to the replica database server so things can run smoothly until the problem is resolved.
Take a look at this Cross-Region Replication
A typical production environment is automatically running backups on most important things that your deployment needs in order to recover from a failure. Those parts would commonly be your database and storage folder, and configuration files.
Also when you deploy a laravel application there aren't many things that are "worth" backing up , you can choose the entire disk to be mirrored somewhere or you can schedule a backup script which run every N times and backups the things that are more important to your application.
Personally i wouldn't rely on an package from laravel to handle my backups , you can always use other backup utilities, replication and so on.
Update
Take a look at the link below:
User Guide » Amazon RDS DB Instance Lifecycle » Backing Up and Restoring
Backing Up and Restoring
You can call the API function RestoreDBInstanceFromDBSnapshot as showed on example.
But i don't think something automated exists that would auto restore or magically make everything work, you need to do a lot of security checks if something like that would even be attempted. Final word i believe a good solution manually entering or sending the request would be the most solid solution.
What is the recommended way to upgrade a Heroku Postgres production database to 9.2 with minimal downtime? Is it possible to use a follower, or should we take the pgbackups/snapshots route?
Until logical followers in 9.4, you'll have to dump and restore (for the reasons Craig describes). You can simplify this with pgbackups:transfer. The direct transfer is faster than dump and restore, but know that you won't have a snapshot to keep.
The script below is basically Heroku's Using PG Backups to Upgrade Heroku Postgres Databases
with modification for pgbackups:transfer. (If you have multiple instances, say a staging server, add "-a" or "--remote" to each Heroku line to specify which server.)
# get the pgbackups plugin
heroku plugins:install git://github.com/heroku/heroku-pg-extras.git
# provision new db
heroku addons:add heroku-postgresql:crane --version=9.2
# wait for it to come online, make note of new color
heroku pg:wait
# prevent new data from arriving during dump
heroku ps:scale worker=0 web=0
heroku maintenance:on
# copy over the DB. could take a while.
heroku pgbackups:transfer OLDCOLOR NEWCOLOR
# promote new database as default for DATABASE_URL
heroku pg:promote NEWCOLOR
# start everything back up and test
heroku ps:scale worker=N web=N
heroku maintenance:off
heroku open
# remove old database
heroku addons:remove HEROKU_POSTGRESQL_OLDCOLOR
Note that if you compare your data size between them, the new one may be much smaller because of efficiencies in 9.2. (My 9.2 was about 70% of the 9.1.)
Heroku followers are, AFAIK, just PostgreSQL streaming replica servers. This means you can't use them across versions, you must have binary-compatible databases.
The same techniques should apply as ordinary PostgreSQL, except that you may not be able to use pg_upgrade on Heroku. This requires shell (ssh, etc) access as the postgres user on the system that hosts the database, so I doubt it's possible on Heroku unless they've provided a tool to run pg_upgrade for you. I can't find much information on this.
You will probably have to look at using Slony-I, Bucardo, or another trigger-based replication solution to do the upgrade unless you can find a way to run pg_upgrade on a Heroku database instance. The general idea is that you set up a new 9.2 instance, use Slony to clone data from the 9.1 instance into it, then once they're fully in sync you stop the 9.1 instance, remove the Slony triggers, and switch clients over to the 9.2 instance.
Search for more information on "postgresql low downtime upgrade slony" etc, see how you go.
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.