Upgrade MongoDB MMS monitoring agent

PROBLEM:
How to upgrade MongoDB MMS monitoring agent?

SOLUTION:
The MongoDB Monitoring Service (MMS) is a cloud-based monitoring service, designed by MongoDB, to monitor the health of MongoDB deployments. MMS provides an agent that runs on MongoDB servers, and this agent reports information such as opcounters, memory information, number of connections, network I/O, database storage size, and more. All of this information is available in customizable charts that are displayed in your web browser.

To install the monitoring agent register here and follow the wizard instructions.

To upgrade:

• Open MMS dashboard
• Choose "Administration" -> "Agents"
• Click one of the links in the "Monitoring" section
• A window with header "Install or Update the Monitoring Agent.." will open
• In the header section, choose "UPDATE"
• Continue with the instructions in the page (example below..)

Example (for RHEL/CentOS (5.X, 6.X), SUSE, and Amazon Linux - RPM):

1. Download the 32-bit or 64-bit rpm.

curl -OL https://mms.mongodb.com/download/agent/monitoring/mongodb-mms-monitoring-agent-2.8.0.143-1.x86_64.rpm

2. Install the package

sudo rpm -U mongodb-mms-monitoring-agent-2.8.0.143-1.x86_64.rpm

If you find this useful, you are welcome to press one of the ads in this page.. Thanks!

ORMs Suck?

As systems become more complex, software developers must rely upon more abstractions. Each abstraction tries to hide complexity, letting a developer write software that "handles" the many variations of modern computing.
However, the "leaky abstraction" law claims that developers of reliable software must learn the abstraction's underlying details anyway.

Example:
The SQL language abstracts away the procedural steps for querying a database, allowing one to merely define what one wants. But certain SQL queries are thousands of times slower than other logically equivalent queries. On an even higher level of abstraction, ORM systems, which isolate object-oriented code from the implementation of object persistence using a relational database, still force the programmer to think in terms of databases, tables, and native SQL queries as soon as performance of ORM-generated queries becomes a concern.

If you find this useful, you are welcome to press one of the ads in this page.. Thanks!

Will NoSQL kill the DBA position?

I’m afraid it’s unlikely. You see, every new or old technology has its advantages and drawbacks. The reality is that NoSQL stands for “Not Just SQL” rather than “No SQL” so the relational database isn't going away anytime soon. Organizations still need transaction atomicity for their mission critical business transactions. When a customer makes a credit card payment or a trader executes a trade, those business transactions need to be committed in real-time to disk. The state of the transaction and its data needs to be consistent wherever that data is updated and accessed from. The reason why NoSQL solutions are so fast, elastic, scalable, and available is because they are basically in-memory distributed data stores that run across multiple nodes and physical servers–meaning that if one node fails, there are plenty others to take over. Therefore when a transaction writes to one node, it’s incredibly fast–but that data has to then be replicated across all nodes in the NoSQL grid for the data to be truly consistent.

Read/Write consistency is still something that NoSQL based solutions have yet to conquer; they sacrifice ACID for read/write performance, elasticity, and high availability.  So while NoSQL enables applications to scale with high transaction concurrency and data volumes, they need to work in parallel with relational databases to ensure data consistency.

If you find this useful, you are welcome to press one of the ads in this page.. Thanks!

Network problems between MongoDB nodes

PROBLEM:
MongoDB replica sets provide high availability through replication and automated failover. We have a cluster comprising three nodes: replicas "mentos-a" and "mentos-b", plus an arbiter. The problem is that every X seconds, the PRIMARY steps down and the cluster failover to the other node.

SOLUTION:
The way we detect a downed node is by a loss of heartbeats and heartbeat responses. Heartbeat responses time out after 10 seconds and then if we have not received a heartbeat from them in the past two seconds (they are sent every two seconds), we mark them as down. So it is common for the election process to take 10 seconds before it starts.

We can change the number of seconds that the replica set members wait for a successful heartbeat from each other. If a member does not respond in time, other members mark the delinquent member as inaccessible.
In the following example we will change the default 2 seconds heartbeat to 30 seconds

rs0:PRIMARY> cfg = rs.conf();
{
 "_id" : "rs0",
 "version" : 2,
 "members" : [
  {
   "_id" : 0,
   "host" : "mentos-a:27017"
  },
  {
   "_id" : 1,
   "host" : "mentos-b:27017"
  },
  {
   "_id" : 2,
   "host" : "mentos-c:27017",
   "arbiterOnly" : true
  }
 ]
}
rs0:PRIMARY> cfg["settings"] = { heartbeatTimeoutSecs : 30 }
{ "heartbeatTimeoutSecs" : 30 }
rs0:PRIMARY> rs.reconfig(cfg);
{ "down" : [ "mentos-a:27017" ], "ok" : 1 }
rs0:PRIMARY> rs.conf()
{
 "_id" : "rs0",
 "version" : 3,
 "members" : [
  {
   "_id" : 0,
   "host" : "mentos-a:27017"
  },
  {
   "_id" : 1,
   "host" : "mentos-b:27017"
  },
  {
   "_id" : 2,
   "host" : "mentos-c:27017",
   "arbiterOnly" : true
  }
 ],
 "settings" : {
  "heartbeatTimeoutSecs" : 30
 }
}

If you find this useful, you are welcome to press one of the ads in this page.. Thanks!

Push/Pull to git repos without entering your credentials all the time

PROBLEM:
You need to enter your git credentials all the time when you pull/push

SOLUTION:
Well, do this...

nano ~/.netrc

# Put the following 8 lines in ~/.netrc file
# change "yourSecret" to the secret key you are using to pull/push (not your github login password)
# change "yourLogin" to the github login
# Note about a limitation: password in .netrc file should not contain spaces, since the .netrc file is parsed against spaces, tabs and new-lines

machine github.com
login yourLogin
password yourSecret
protocol https
machine api.github.com
login yourLogin
password yourSecret
protocol https

# set chmod permissions (600 - owner can read and write)
chmod 600 ~/.netrc

# try get latest from master (and see you don't need to enter your credentials)
git checkout master
git pull origin master

If you find this useful, you are welcome to press one of the ads in this page.. Thanks!

Why skipping Windows 9 ?

PROBLEM:
Why Microsoft is skipping Windows 9 ?

SOLUTION:
One of the technical reasons is too many legacy apps don't use the correct versioning APIs.
You can see examples in the following Java legacy code:

See more details here and here. But before, you are welcome to press one of the ads in this page.. Thanks!

How to fix Shellshock (CVE-2014-6271 bash vulnerability)

PROBLEM:
You need to fix remote code execution through bash (Shellshock)

SOLUTION:

Ubuntu

sudo apt-get update && sudo apt-get install bash

See more details here

Centos

sudo yum update bash

See more details here

Do I need to reboot or restart services after installing this update?
No, a reboot of your system or any of your services is not required. This vulnerability is in the initial import of the process environment from the kernel. This only happens when Bash is started. After the update that fixes this issue is installed, such new processes will use the new code, and will not be vulnerable. Conversely, old processes will not be started again, so the vulnerability does not materialize.

Shellshock vs. Heartbleed
Heartbleed allowed remote access to small amount of data in the memory of affected machines. Shellshock is enabling remote code injection of arbitrary commands pre-auth which is potentially far more dire.

If you find this useful, you are welcome to press one of the ads in this page.. Thanks!