With the architecture change in oracle 12, specifically containers and pluggable databases should, should sid naming conventions be changes to help identify db as container or plugin or which plugins go with which containers. Suggestions and advice appreciated
You only have an sid per container database and not per pluggable database. Nothing changed in that respect. To connect to pluggable database you have to use services.
Related
We are migrating our Postgresql v10 (Linux) database to Azure and due to the timeframe involved would prefer not to change our current use of the npgsql driver in our apps.
Has anyone had any experience here? Can we utilize our use of that driver with very little or no changes to our code?
The one thing I'm aware of is that queries must use the shard column to help the Citus coordinator distribute to the right node. Anything else?
Thank you!
I have no personal experience with Citus, but as far as I know, Citus is supposed to be extremely compatible with PostgreSQL - definitely at the wire protocol level - and so general PostgreSQL drivers (like Npgsql) are supposed to work fine with it.
You may definitely need to change the way you're doing things at a higher level (e.g. sharding), but at the low-level database driver level Npgsql should be OK.
In order to use MongoDB on my node.js AWS EC2 instance do I simply install MongoDB and create a database within the instance via the command line after logging in via SSH?
In other words do I simply create a DB in the EC2 instance for my web app just as I would locally on my machine?
just from long (and at the beginning painful) experience with EC2 & MongoDB..here are some gotcha's.
I am assuming you are just starting off from your question - so I am going to assume a minimal setup:
If you install MongoDB on a server with access to the Internet, then make sure you also apply MongoDB roles to your DB. Do not, I repeat, do not leave it open to the world. Admin and read/write roles are critical here, and MongoDB docs will help you. BTW, even if it is totally secure behind a firewall and other such things, always use roles. They are your last line of defense.
Study and understand exactly how security groups work, in order to limit Inbound and Outbound.
If you can, use the Elastic IP. It will save you many headaches if you move servers, not the least of which is that your IP will not change.
When you gear up to a front facing Internet server, and Mongo behind it, be it with Sharding, Clusters etc. read up on the NAT gateway. It is confusing at first, but the NAT Gateway (not the NAT instance), is a decent setup in one configuration or another.
Take snapshots or complete images of your environment when you change it. This is great for backup, and also when you move to a more robust server, it will save you a great deal of work.
If you have not already, try using MongoBooster or RoboMongo. They will help you immensely with your Mongo work.
Good luck and enjoy!
The actual AWS implementation of MongoDB is DocumentDB, which from what i can tell is built on the opensource version of MongoDB version 3.6, so newer MongoDb features are/might/will not be supported.
An interesting article comparing DocumentDb with MongoDb Atlas(mongoDm cloud solution):
https://medium.com/#michaelrbock/nosql-showdown-mongodb-atlas-vs-aws-documentdb-5dfb00317ca2
In the end if you really want MongoDB on AWS my opinion is you should just install it on a EC2 machine, I've done it via DocumentDB and some mongodb commands don't work, or chose AWS own NOSQL solution DynamicDB instead, DocumentDB just seems to be up there for competition with MongoDB Atlas cloud solution or just for having some dedicated MongoDB for companies that use it and want to move to AWS.
You have different alternatives. To answer your question: yes, you can do it that way. But, there is also an official guide by Amazon to set up a MongoDB cluster on AWS.
Also, if you only need a NoSQL database, you should also check DynamoDB, developed by Amazon. That would eliminate the need of an EC2 instance for the database. For more info, check the official docs.
I am new to Distributed databases and the initial roadblock am facing is to have a distributed transaction across heterogeneous databases where the control goes to Transaction Manager which is mostly the OS implementation (MSDTC in Windows).
How are generally Distributed Transactions implemented on Linux?
And if they are implemented which major databases have support for it? (MSSQL, MYSQL, POSTGRES, ORACLE, SYBASE)
I don't think there is any service like MSDTC in Linux. I expect you will need to use some 3rd party transaction manager. Or maybe you could try to port MSDTC to Linux on Mono (no idea how hard it is or if possible).
I'm not much familiar with transaction managers other than for Java.
I am trying to deploy an Akka application on Azure, that uses the journal persistence plugin.
I cannot find a working combination when it comes to the persistence plugin I should use.
So far I looked into:
akka-persistence-mongo and Azure Document Store with Mongo driver: it does not work because akka-persistence-mongo is not compatible with the latest reactive-mongo version that supports SSL
akka-persistence-jdbc and an Azure SQL server: it seems the akka-persistence-jdbc is only compatible with Slick H2, Oracle and MySQL drivers
I do not have any strong performance requirements, this is why both solutions would have worked.
My best guess for the moment is akka-persistence-redis with Microsoft Azure Redis.
I am proposing a contribution to this plugin to make it compatible with Microsoft Azure Redis (authentication, as well as a strange error when calling zrangebyscore that I do not have with a local Redis).
I am completely new to elasticsearch but I like it very much. The only thing I can't find and can't get done is to secure elasticsearch for production systems. I read a lot about using nginx as a proxy in front of elasticsearch but I never used nginx and never worked with proxies.
Is this the typical way to secure elasticsearch in production systems?
If so, are there any tutorials or nice reads that could help me to implement this feature. I really would like to use elasticsearch in our production system instead of solr and tomcat.
There's an article about securing Elasticsearch which covers quite a few points to be aware of here: http://www.found.no/foundation/elasticsearch-security/ (Full disclosure: I wrote it and work for Found)
There's also some things here you should know: http://www.found.no/foundation/elasticsearch-in-production/
To summarize the summary:
At the moment, Elasticsearch does not consider security to be its job. Elasticsearch has no concept of a user. Essentially, anyone that can send arbitrary requests to your cluster is a “super user”.
Disable dynamic scripts. They are dangerous.
Understand the sometimes tricky configuration is required to limit access controls to indexes.
Consider the performance implications of multiple tenants, a weakness or a bad query in one can bring down an entire cluster!
Proxying ES traffic through nginx with, say, basic auth enabled is one way of handling this (but use HTTPS to protect the credentials). Even without basic auth in your proxy rules, you might, for instance, restrict access to various endpoints to specific users or from specific IP addresses.
What we do in one of our environments is to use Docker. Docker containers are only accessible to the world AND/OR other Docker containers if you explicitly define them as such. By default, they are blind.
In our docker-compose setup, we have the following containers defined:
nginx - Handles all web requests, serves up static files and proxies API queries to a container named 'middleware'
middleware - A Java server that handles and authenticates all API requests. It interacts with the following three containers, each of which is exposed only to middleware:
redis
mongodb
elasticsearch
The net effect of this arrangement is the access to elasticsearch can only be through the middleware piece, which ensures authentication, roles and permissions are correctly handled before any queries are sent through.
A full docker environment is more work to setup than a simple nginx proxy, but the end result is something that is more flexible, scalable and secure.
Here's a very important addition to the info presented in answers above. I would have added it as a comment, but don't yet have the reputation to do so.
While this thread is old(ish), people like me still end up here via Google.
Main point: this link is referenced in Alex Brasetvik's post:
https://www.elastic.co/blog/found-elasticsearch-security
He has since updated it with this passage:
Update April 7, 2015: Elastic has released Shield, a product which provides comprehensive security for Elasticsearch, including encrypted communications, role-based access control, AD/LDAP integration and Auditing. The following article was authored before Shield was available.
You can find a wealth of information about Shield here: here
A very key point to note is this requires version 1.5 or newer.
Ya I also have the same question but I found one plugin which is provide by elasticsearch team i.e shield it is limited version for production you need to buy a license and please find attached link for your perusal.
https://www.elastic.co/guide/en/shield/current/index.html