I have a problem quite similar with this post but was thinking for an easiest implementation
My Django app is deployed on a remote server with Postgresql database (main central remote database).
Users online: data are stored both in the remote database and, if possible, in a local postgresql database (local database hosted on a dedicated laptop)
Users offline (when server where app is hosted is down): 'central' user need to be able to use Django web app on the dedicated laptop (with PWA) with the most up-to-date local database
When back online, the remote database is synchronized
Django can use multiple databases.
But is my solution possible?
I have read for Django sync and collect-offline apps...
thanks for advices
I have a django website with PostgreSQL database hosted on one server with a different company and a mirror of that django website is hosted on another server with another company which also have the same exact copy of the PostgreSQL database . How can i sync or update that in real time or interval
Postgresql has master-slave replication. Try That!
I am trying to map a newly created local claim to the claims of a service providers.
Some notes about my WSO2 implementation:
I am using Postgres databases in AWS's Relational Database Service. I followed the steps here to set up my master, metrics, and bps databases: https://docs.wso2.com/display/ADMIN44x/Changing+to+PostgreSQL#ChangingtoPostgreSQL-ChangingthedefaultdatabaseChangingthedefaultWSO2_CARBON_DBdatasource
My steps to map the claim look like this:
Create a local claim
Attempt to add the newly created claim to a service provider
My issue is that the claim I created in step 1 doesn't appear in the dropdown in step 2. I have confirmed that the claim is being written to my master Postgres database under the idn_claim table. If it's in the idn_claim table, shouldn't it show in the dropdown when adding a claim?
The same steps have worked for me with the following setups:
Using the built-in H2 database (no config changes)
Using a LOCAL Postgres database that is setup using the same configuration files and seeding scripts as the scenario above.
I'm stumped about why everything works as expected using the H2 database or a Local Postgres database (with identical setup) but it doesn't work with a Postgres database in AWS.
I had few questions that might be easy for others, but that I couldn't wrap my head around.
In developing a "PRODUCTION LEVEL" full-stack web application(node.js/react/webpack),
1) Where do you set up your database? (when developing, I'm using apache couchdb running on my localhost, but when deployed, is cloud database(cloudant) the only solution? or am i missing something?)
2) Is it recommended to deploy my server(node.js) to either digital ocean/aws/heroku, AND set up a third party database else where? (in my case, I'm have to use either Digital Ocean/Aliyun(Chinese Web Service), but they don't seem to have a database package that comes with couchDB) - What is the practical solution for production level application?
3) If cloud database is the practical solution, What Do I do if there is no database storage center for CouchDB located in China? is there a cloud database storage that universally saves all noSQL data regardless of your type of DB? (mongoDB, couchDB, etc.,)
4) AWS/Heroku provides add-ons where you can connect cloud database to my application, does this make the speed of my application faster? For Digital Ocean, it shows article about setting up CouchDB with their service, but does that mean that database will be available for my users to access? or is that just for development purposes
5) Where and How does "Docker" come in to play to help in my situation?
Sincerely,
I cannot say for CouchDB, but I have hosted multiple web applications on AWS using their RDS Database (MySQL). The service you choose (AWS/DO/Heroku), depends on your application and your requirements (pricing etc).
I don't think AWS has a package for MongoDB, but there is a third party service MongoLabs, which can host the MongoDB Database, I bet there would be some out there for CouchDB too.
Or if you cannot get a third party hosting, consider installing the database on your server itself. Getting a VPS from either DO or AWS and setting it up yourself could be an option in that case. The link you mentioned in your last paragraph would help you here. And yes, if you use that and let node connect to it, you can use it just like any other cloud based database, just that it would be on your server.
I haven't used Docker, so cannot say if and how that could help
UPDATE: (reply to comment)
A VPS is a server in the cloud. You don't set up the database on your local computer, no one can access that. You set up your database on the VPS (in the cloud) and then everyone can access that.
A VPS is like your own clean copy of server (ubuntu/fedora) in the cloud, so you can pretty much do anything on it, like your local computer. So basically your database would also be in the cloud.
There are actually 2 ways you could do that.
Get a VPS, install your database and set up your node.js server on the same VPS. Your node application would access the database on the same VPS.
Get a VPS specially for the database, and set up your node.js on another VPS, this would separate the database and node app on two different servers.
To answer part of your question... if you set up a CouchDB server on Digital Ocean (or on AWS, Azure, Google Cloud etc) it will be available to your production users, not just you. You will want to set up security/firewall to limit who can access your server of course.
Cloudant provide CouchDb as a service, in other words you would not have to install the software or manage a server.
With Digital Ocean/AWS/Azure/Google it is down to you to manage the virtual server and the database/other software on it. You can install CouchDb on any of these services and you can install both NodeJS and CouchDb on the same virtual server if you wish.
Bitnami have a CouchDb package that you can use to deploy CouchDb on to several of the major hosting companies, which makes the setup process easier.
I see that AWS and Azure have data centres in China, but at the moment Digital Ocean do not as far as I am aware. I hope this helps
What is the difference between Sitecore's core, master, and web databases?
Master: Contains all versions of all items. This is the database that content authors interact with, and is the default database used by the Sitecore Content Ediitor.
Web: This contains only the current versions of items. This is the database that supports the live website.
Core: This database has two purposes:
It contains definitions for the Sitecore user interface (Content Editor, Page Editor, etc.). This is where you would go to add, for example, a new Right-click option to the Content Editor or a new ribbon button to the Page Editor.
It contains the ASP.NET membership tables that drive authentication and security.
I recommend you look at the Launch Sitecore site to understand more about the CMS.
From the page on Sitecore Architecture:
Master
The Master database is the authoring database - it contains all versions of any content or assets.
Core
The Core database is all Sitecore settings, as well as the tables containing the .Net membership provider (i.e. users/roles contained in the Sitecore repository)
Web
The Web database is only the latest published version, and the content that is driving the live web site. Therefore it is a subset of the master database, optimised for size and speed. When content is published, or goes through the publishing task of a workflow, the latest content version is copied from the master to web database.
Of course, in an Enterprise deployment, you may have multiple Sitecore instances, which may share DBs (or not)
Some great answers here but it's worth a clear note that the Web database is the default publishing target and is not set in stone. You can rename it to whatever you wish as well as have multiple publishing targets similar to 'Web'.
e.g. We have a Sitecore instance with two websites (website and intranet), thusly the Master database contains all the items for both sites. For publishing we have two targets 'Website' and 'Intranet' that are hosted by different SQL servers.
Ultimately our connections include: Core; Master; Website; Intranet (the latter two being copies of the original 'Web' database of course)