i'm now trying to migrate my parse db to a mLab with a parse server hosting it in AWS Elastick Beanstalk.
While migrating, I had few pending problems and i will be glad if you know about these questions.
After migrating the DB, will the parse server that is hosted by
Parse.api.com will continue connecting to the DB that is migrated?
After deploying my development DB and parse server to mongoLab and AWS, will the parse.api.com with the production DB still remains running with the app that is used by the user?
After migrating the development DB and also the Parse Server to AWS, is it possible to migrate the prduction DB?
After migrating the DB, will the parse server that is hosted by
Parse.api.com will continue connecting to the DB that is migrated?
That is correct, api.parse.com will hit your self-hosted database for as long as you don't delete the app on parse.com/close your Parse account or until Parse shuts down in January 2017.
Should you chose to delete the app on parse.com, all users that haven't updated to a version of your app that uses your own Parse Server will be left with a broken app until they install the update of your app.
After deploying my development DB and parse server to mongoLab and AWS, will the parse.api.com with the production DB still remains
running with the app that is used by the user?
Assuming that your development and production Parse Apps are two different apps on Parse you will need to migrate them separately and yes, if you only migrate your development app (let's call it App A for now), App B (your production app) won't be effected until you migrate it as well. Of course any non-migrated app will stop working all-together at the end of January 2017.
After migrating the development DB and also the Parse Server to AWS, is it possible to migrate the production DB?
You are free to migrate as many databases/apps you want. So the answer is yes, you can migrate your production/development versions as well.
Related
I am planning to deploy my website later and need to know the lite DB in the development/testing stage of the app that needs to be changed to PG especially when the websites allows its users to do a number of tasks which require a number of DBS.
When transferring the DB through deployment to a server; i.e. digital ocean, do you need to rewrite the DB code in the PG?
With the new feature of Azure Website deployment slots' "Slot Settings", we can 'pin' a connection string and app settings to a particular slot. I have set up two slots: production and staging, and verified I can swap between them and point to the correct database. The database is being updated automatically using code first migrations. However, I'm unsure how exactly a "rollback" would (or should) work with the database in this scenario.
For example, consider the following:
App v1 is running in staging and pointed to staging Db v1
App v1 is running in production and pointed to production Db v1
App v2 is deployed to staging, and Code First Migrations updates staging Db to Db v2
staging and production slots are swapped.
App v2 is running in production, and production db is updated to Db v2.
App v1 is running in staging, but pointed at staging db, which is still Db v2
Is there a way to roll the staging database back to v1? If an "emergency" occurred and I had to swap staging and production again, would there be a way to get the production database back to v1? I understand this can be done using Update-Database, but am unclear how to set it up as automated as possible in Azure Websites.
I think you answered your own question. Unless there is a staging db on DBv1 then you would have to manually update your staging database to do the rollback. I do not think there is an automated way of doing this.
I've used Taps before on Heroku, but what is a good solution on non-heroku rails apps?
You could create a capistrano task/s to mysqldump on the source database, gzip the file, then scp it to the destination and execute the mysql script there to import.
I wrote a Capistrano recipe some time ago to sync a MySQL database and files between different environments: https://gist.github.com/111597
OK, there are some things you need to keep in mind. If you are using SQlite for development and MySQL / Postgre for production on the server, then sinking is almost impossible. On the contrary if you are using the same DB engines you can use administrator interface like MySQL administrator on your desktop and generate a backup file and upload it to server and vice versa.
May hosting providers provide PHPMyAdmin to take backups and restore it on the server.
I am using postgresql database for my Heroku Application.
I have very large database on AmazonAws as heroku not providing the Postgresql Database.
Now my client want to switch to EngineYard from Heroku.
Can i use same database (w/o taking backup and then reload) for my application on the EngineYard?
If YES
How can i use or steps for using the Existing AmazonAws Database with the new EngineYard Application.
You can, but only if you are using a dedicated database. From the Heroku database FAQ
Shared Database
No, connecting to your database from machines outside of Heroku is not
supported. We recommend that you encapsulate data access in an API to
manipulate it.
Dedicated Database
It's possible to connect to our dedicated databases using our
pg:ingress feature. Please see using the PG console for more
information.
The database connection string is available in the DATABASE_URL config. You can run
$ heroku config --long
to view it. However, it won't probably work if you use a shared database because it seems connection is restricted to the Heroku net.
Surely this is just a case of getting the correct connection credentials for the DB regardless of where it's hosted?
For instance, if the DB is on Heroku, then ENV['DATABASE_URL'] give you everything you need. All these details then go in your database.yml as normal (assuming you're using ActiveRecord)
For the record, Heroku do provide Postgres and it's part of their core business.
Considering migrating an app to Heroku. Currently we build & test locally before deploying to our own server for hosting...But the application is growing and now wondering if it's reasonable to have, say, 3 versions of our app. One local to developer's machines. A second (testing) deployed via Capistrano to an internal server. And then finally a third on Heroku (production). Databases would not need to be shared.
Any problems or advice for this sort of scenario?
I think it's a good thing to have a staging server with the same environment as your production. So instead of internal server, wouldn't it be better to test on heroku?
For this purpose I've created another app on heroku and before updating my production app, I push my app to the staging one.
I would highly recommend the heroku_san gem which simplifies pushing app to heroku to just rake staging deploy.
I do this. I have development on developer's machines, staging, and production.
Staging is our test sandbox and sometimes also shares user databases with production so I can let users beta test, etc.
Whether or not you use Heroku for production really doesn't matter does it?