I am absolutely not buying Mongodb Atlas :) I want to make the best I can with MongoDB cloud. Today with MongoDB cloud, when I spin up an AWS instance the automation takes care of joining my MongoDB cloud account w/ the API and group key I've embedded in my system image. What I want to do now is take it to the next level and have that instance register itself as an additional replica of an -existing- replica set and sync up. I can't be the first person to want to do this but I'm coming up empty with Google. Can anyone point me to a gist, blog, rant or other example of how to do this?
Related
I want to add two different database for my node app in mongodb atlas in same cluster i.e. one for production and one for development but mongodb atlas is not showing databasename or myfirstfile after #cluster0.irbg7.mongodb.net/ in the below url. How do i add different database in such situations?
I assume that you already created the cluster. In one cluster you can add multiple Databases.
On your home page, you are able to see something like this.
Click on the Browse Collections to browse the collections.
Now create Database as much as you like.
To connect to the desired database, use the connection string followed by database name.
Example: 'mongodb://<username>:<password>#<clustername>/<dbname>?ssl=true&replicaSet=<replica setname>&authSource=admin
By default in Elasticsearch, the maximum number of open scrolls is 500 but I need to increase this number. There s no problem in updating "search.max_open_scroll_context" in local machine but AWS Elasticsearch has not allowed to make changes.
While trying to update with answer given in this thread configure-search-max-open-scroll-context, the response is: {"Message":"Your request: '/_cluster/settings' payload is not allowed."} while I can perform such operation in my local Elasticsearch but AWS Elasticsearch doesn't seems to allow such operation. Does anyone has answer to this for AWS Elasticsearch or have faced similar?
This is restricted in AWS ES for customer end.
You need to reach out to AWS Support Team for this. Just let them know the value of "search.max_open_scroll_context" that you are looking for and they will update it from the backend.
Here the link to AWS-supported operations on elasticsearch.
Currently, AWS doesn't support updating "search.max_open_scroll_context" as of now. You can definitely contact AWS support to increase the scroll context count. Alternatively, you can use Search-After API instead of scroll.
I am new to google cloud and was wondering if it is possible to run PostgresQL container on Cloud Run but the data_directory of PostgresQL was pointed to Cloud Storage?
If possible, then please could you point me to some tutorials/guides on this topic. And also what are the downsides of this approach?
Edit-0: Just to clarify what I am trying to achieve:
I am learning google cloud and want to write simple application to work along with it. I have decided that the backend code will run as a container under Cloud Run and the persistent data(i.e the database file) will reside on Cloud Storage. Because this is a small app for learning purpose, I am trying to use as less moving parts as possible on the backend(and also ones that are always free). And also both PostgresQL and the backend code will reside in the same container except for the actual data file, which will reside under Cloud Storage. Is this approach correct? Are there better approaches to achieve the same minimalism?
Edit-1: Okay, I got the answer! The Google documentation here mentions the following:
"Don't run a database over Cloud Storage FUSE!"
The buckets are not meant to store database information, some of the limits are the following:
There is no limit to writes across multiple objects, which includes uploading, updating, and deleting objects. Buckets initially support roughly 1000 writes per second and then scale as needed.
There is no limit to reads of objects in a bucket, which includes reading object data, reading object metadata, and listing objects. Buckets initially support roughly 5000 object reads per second and then scale as needed.
One alternative to separate persistent disk for your PostgreSQL database, is to use Google Compute Engine. You can follow the “How to Set Up a New Persistent Disk for PostgreSQL Data” Community Tutorial.
I’ve been working with AEM for over a year now and lately I’ve been trying to move into a high availability setup for author.
My problem is when ever I spin up a server, add sites, and spin up another server the data doesn’t persist to the new instance. I know why this doesn’t work in the traditional setup (repository is stored locally on the file system). However, I’ve attempted using the S3 backend, and it results in the same problem where the data doesn’t persist onto the new instance.
Ive read about using mongoMK (https://helpx.adobe.com/experience-manager/6-3/sites/deploying/using/recommended-deploys.html), I.e. mongodb as a store, but they also recommended using S3 as the backend.
My question is, does anyone have any experience with multiple AEM author instances sharing the same data and node stores, if so do you have any suggestions as to how to get this working or resources where I can read about this?
After further research it seems the only option for backend clustering is to use mongodb. My attempts to use mongodb with AEM as a backend have failed. When I attempt to use the crx3 and crx3mongo run modes it looks like AEM hangs after opening a connection to mongo. I have verified that nothing is getting placed into the DB via a show dbs returning 0.000GB for the corresponfing database.
i want to dockerize my production application. I've got MongoDB set up on server and I want to remove it, and make a docker container with MongoDB which will work on existing data. I already tested this approach, so i created a docker container which storage is pointed to host storage with existing data. Basically it's the new MongoDB instance which work on data created by previous mongoDB which existed on Host. And it works, so i can query data, my application can connect to this database and so on. My question is, what are the threats to this approach? And if this is even good approach, or when i created new mongoDB instance should i import dump data from previous one ?
I guess there's no right and wrong in this case. It depends on how you want to have it working.
Let's say you left Mongodb running in the cloud.
Is it a development database? If yes, how would you keep coding / testing without access to that?