I'm running optaweb-employee-rostering in a dockerized Wildfly server, persisting data with MySql database running in a container too. The .war file is not built in sever's Docker image, it's manually deployed in it via Wildfly's admin interface. Every time container is stopped a restarted, the application rebuild sample data, deleting any data saved during usage, so that the final behavior is the same as ram based storage: the data is lost if the server stops.
Is there a way to avoid this behavior and keep saved data on server restart?
This is caused by the hbm2dll value here and due to the Generator's post construct. In the current openshift image there are environment variables to change that.
We're working on streamlining this "getting started" and "putting it into production" experience, as part of the refactor to react / springboot.
Related
App Service on Standard plan, using MySQL in-app database. App is stopped, and a manual backup always completes as "partial". The configuration for the backup blade shows no database exists. I am concerned that the database in the filesystem is not being included, so the restore will fail.
How can I be confident in Azure App Service Backup?
Thanks.
Added Information: Backup Log
CorrelationId: 19a70ee5-7158-49e9-8f58-35e39f231a34
Creating temp folder.
Retrieve site meta-data.
Backing up the databases.
Failed to backup in-app database. Skipping in-app database backup.
Backing up site content and uploading to the blob...
Uploading metadata to the blob.
Partially Succeeded means that there were likely some files which could not be backed up, because they were locked for some reason. When this happens the backup process skips them and backs up the rest of the site and database if configured. You should be able to see which files were skipped in the log file. If for some reason you do not need these files backed up you can skip them by following the instructions in section “Backup just part of your app” here.
Stopping Locked On-Demand/Triggered Azure Webjob sometimes is the reason for a Partially Succeeded backup status
Using Azure website backup feature means you backup below things
1. Your web app configurations
2. Your actual web app file contents
3. The Azure MySQL database - This is optional. i.e. you can choose to back it up or not.
You can also try using using schedule backups. There is two options for this either schedule a full backup or partial backup using kudu console.
You may refer to this doc https://learn.microsoft.com/en-us/azure/app-service/manage-backup
Before I keep going down this path (explained below) can someone verify I am on the right track? Or How do you work with test data for local development and refresh it regularly.
For our local development we run a standalone mysql and use an import script to load sanitized test data. The import script takes over 2 hours. I am at the point where I have mysql running in a container and I can load the test data inside. The container fully loaded is 50GB. I am having trouble saving it with docker commit and docker export/docker import. "Error processing tar file(exit status 1): unexpected EOF" From researching this error I need to be on the latest version of Docker 18.09.3. Right now I am using an AWS ami that only goes to version 18.06.1-ce. So currently I am spinning up another EC2 server with a Centos ami to load the newest version on docker.
I have been working on this project for 2 weeks and would appreciate any advice.
If container size if 50GB, I assume you are loading full mysql data in the docker image or load data in container and now want to same container state.
Best way would be to mount host directory to container to hold mysql data. In this way, your mysql image is immutable and data is mounted on the image.
This data can be copied on any other server and run the new mysql container.
I am working on a JAVA web application and i have mysql as my backend. I make DB calls from my application. But whenever i make any change in DB, my local server has to be restarted to redeploy my java EAR for the updated DB changes to be reflected, Is there a way i can get the updated DB changes without restarting my local server?
Please let me know.
You don't need to restart your local server unless and until you want to change the database mean you want to point to entirely different database schema.
And if you want to change i.e adding extra columns to the database then also it will work fine but if you delete columns or table from current schema then only you need to change your code and start your server again.
Note :-
In case if you are working with Dynamic Web Project in eclipse with Tomcat server configured within then you don't need to do that also because server will reload your project after some time automatically.
In production mode, when lifting a Sails application, the database tables are not created upon lift, while in dev mode, they are. Right now, when deploying, I'm running in dev mode once first so that the tables can be created and then running in prod mode. Is there a way around this?
No; this is by design. In the production environment, Sails does not do any migration to ensure that data isn't corrupted or lost when lifting.
From the Sails deployment guide:
Sails sets all your models to migrate:safe when run in production, which means no auto-migrations are run on starting up the app. You can set your database up the following way: Create the database on
the server and then run your sails app with migrate:alter locally, but
configured to use the production server as your db. This will
automatically set things up. In case you can't connect to the server
remotely, you'll simply dump your local schema and import it into the
database server.
I have a java webapp using hibernate over MYSQL db. I need at least an hour of data maintenance daily, hence I need to bring down the db and switch to the backup db.
I don't see an elegant way to switch to another db from my app using hibernate. Is there?
Other totally different ways for database maintenance is welcome.
As you are using a Java WebApp, I assume you are using a container (like Tomcat) or an application server (like JBoss). In both cases, you should be using managed connections by the container, via JNDI. In such case, you can just use JMX (or the admin console) to change the actual datasource, to point to the backup DB, clean the pool and reopen new connections. When you are done, just perform the same steps, pointing the datasource to the actual database.
If you are not using managed connections by the container, you are out of luck. As the Hibernate configuration is static, you'll need to bring down your app, deploy a new version of it with your persistence.xml/hibernate.cfg.xml pointing to the backup, do the maintenance, and deploy the "old" version when you are done.