1. Get your MongoDB Atlas Replicaset
2. Make sure you can access the MongoDB Atlas Replicaset using port 27017/TCP
3. Setup your desktop with the following as described in the embedded Loom:
- Install MongoDB Compass on the desktop
- Install a coding environment with recent VS Code ready for .NET Core
Now when everything is ready, you start coding your project and enjoy the combined power of .NET Core and MongoDB
Keep Performing,
Moshe Kaplan
Having a MongoDB Relicaset was always simple, but with MongoDB Atlas, it is simple than ever.
In this two sessions video we'll learn:
1. How to open a MongoDB Atlas account, create a project and a new cluster (Replicaset)
2. How to verify you can connect your Replicaset
Well it is super simple, and you can actually try the MongoDB guide or my embedded video:
I used for this task a t2.medium AWS instance with 2 burstable cores, 4GB RAM and 8GB gp2 SSD disks.
Keep Performing,
Today we'll disucss the need for data masking due to privacy regulations such as GDPR that becone more and more common in the industry.
In order to deploy such a solution we'll utlize two great products:
1. Percona Server 8.0.17 that has recently introduced the data masking plugin (that is compatible w/ MySQL Enterprise one. This plugin exposes multiple functions that translate sensitive strings such as SSN and emails to masked strings.
2. ProxySQL a proxy server that supports modifying SQL queries on the fly. For example replacing SELECT ssn FROM users; with SELECT mask_ssn(ssn) FROM users;
The Percona Server will serve as our MySQL solution (you can use it as a slave instance if you need it for analyst purposes only). while the ProxySQL will serve as a Proxy that modifies SQL queries to utilize the Percona server data masking functions. You may also need to limit users access from the network to the Percona server.
Bottom Line
New times bring new products that can serve us to create novel solutions
Keep Performing,
If you environment is bound to Prometheus it is best we focus on this platform as a baseline.
Customer Question:
We have a 4 nodes replicaset w/ leading nodes each with different priority. From time to time, when we suffer from network issues, all the replicaset goes down.
Why is this Happens?
Since two of the nodes are a single site and the two other on two other sites, when the first site goes offline, no site can create a majority. Therefore, you must remove one of the nodes in the first site to avoid these downtimes.
Moreover, the MongoDB selects the primary node by priority. If the primary is unstable, everytime it will go offline, a secondary will be chosen w/ a possible few secondds replicaset downtime. When the high priority node goes back online, it will be selected again to primary (and causing another possible downtime).
Therefore, if there is no good reason, avoid specifing variable priorities.
How to fix It?
1. Perform the task during off peak hours
2. Remove the arbiter node by rs.remove()
3. Verify replicaset is okay by running rs.status()
4. Modify the remaining nodes configuration:
cfg = rs.conf()
cfg.members[0].priority = 1
cfg.members[1].priority = 1
cfg.members[2].priority = 1
rs.reconfig(cfg)
5. Verify again.
Bottom Line
Keep it Simple :-)
Keep Performing,
Tools
Checklist