Feb
19
2019
--

Percona Server for MongoDB 3.4.19-2.17 Is Now Available

Percona Server for MongoDB

Percona Server for MongoDB

Percona announces the release of Percona Server for MongoDB 3.4.19-2.17 on February 19, 2019. Download the latest version from the Percona website or the Percona Software Repositories.

Percona Server for MongoDB 3.4 is an enhanced, open source, and highly-scalable database that is a fully-compatible, drop-in replacement for MongoDB 3.4 Community Edition. It supports MongoDB 3.4 protocols and drivers.

Percona Server for MongoDB extends MongoDB Community Edition functionality by including the Percona Memory Engine and MongoRocks storage engines, as well as several enterprise-grade features:

Percona Server for MongoDB requires no changes to MongoDB applications or code. This release is based on MongoDB 3.4.19.

In this release, Percona Server for MongoDB supports the ngram full-text search engine. Thanks to Sunguck Lee (@SunguckLee) for this contribution. To enable the ngram full-text search engine, create an index passing ngram to the default_language parameter:

mongo > db.collection.createIndex({name:"text"}, {default_language: "ngram"})

New Features

  • PSMDB-250: The ngram full-text search engine has been added to Percona Server for MongoDB.Thanks to Sunguck Lee (@SunguckLee) for this contribution.

Bugs Fixed

  • PSMDB-272mongos could crash when running the createBackup command.

Other bugs fixed: PSMDB-247

The Percona Server for MongoDB 3.4.19-2.17 release notes are available in the official documentation.

Feb
18
2019
--

Percona Server for MongoDB 4.0.5-2 Is Now Available

Percona Server for MongoDB

Percona Server for MongoDB

Percona announces the release of Percona Server for MongoDB 4.0.5-2 on February 18, 2019. Download the latest version from the Percona website or the Percona Software Repositories.

Percona Server for MongoDB is an enhanced, open source, and highly-scalable database that is a fully-compatible, drop-in replacement for MongoDB 4.0 Community Edition. It supports MongoDB 4.0 protocols and drivers.

Percona Server for MongoDB extends Community Edition functionality by including the Percona Memory Engine storage engine, as well as several enterprise-grade features. It also includes MongoRocks storage engine (which is now deprecated). Percona Server for MongoDB requires no changes to MongoDB applications or code.

This release includes all features of MongoDB 4.0 Community Edition. Most notable among these are:

Note that the MMAPv1 storage engine is deprecated in MongoDB 4.0 Community Edition.

In Percona Server for MongoDB 4.0.5-2, data at rest encryption becomes GA. The data at rest encryption feature now covers the temporary files used for external sorting and the rollback files. You can decrypt and examine the contents of the rollback files using the new perconadecrypt command line tool.

In this release, Percona Server for MongoDB supports the ngram full-text search engine. Thanks to Sunguck Lee (@SunguckLee) for this contribution. To enable the ngram full-text search engine, create an index passing ngram to the default_language parameter:

mongo > db.collection.createIndex({name:"text"}, {default_language: "ngram"})

New Features

  • PSMDB-276perconadecrypt tool is now available for decrypting the encrypted rollback files.
  • PSMDB-250: The Ngram full-text search engine has been added to Percona Server for MongoDB.Thanks to Sunguck Lee (@SunguckLee) for this contribution.

Bugs Fixed

  • PSMDB-234: It was possible to use a key file for encryption the owner of which was not the owner of the mongod process.
  • PSMDB-273: When using data at rest encryption, temporary files for external sorting and rollback files were not encrypted
  • PSMDB-257: MongoDB could not be started with a group-readable key file owned by root.
  • PSMDB-272mongos could crash when running the createBackup command.

Other bugs fixed: PSMDB-247

The Percona Server for MongoDB 4.0.5-2 release notes are available in the official documentation.

Feb
06
2019
--

Percona Server for MongoDB 3.6.10-3.0 Is Now Available

Percona Server for MongoDB

Percona Server for MongoDB

Percona announces the release of Percona Server for MongoDB 3.6.10-3.0 on February 6, 2019. Download the latest version from the Percona website or the Percona Software Repositories. This
release is also available for Ubuntu 18.10 (Cosmic Cuttlefish).

Percona Server for MongoDB is an enhanced, open source, and highly-scalable database that is a fully-compatible, drop-in replacement for MongoDB 3.6 Community Edition. It supports MongoDB 3.6 protocols and drivers.

Percona Server for MongoDB extends Community Edition functionality by including the Percona Memory Engine storage engine, as well as several enterprise-grade features. It also includes MongoRocks storage engine (which is now deprecated). Percona Server for MongoDB requires no changes to MongoDB applications or code.

In Percona Server for MongoDB 3.6.10-3.0, data at rest encryption becomes GA. The data at rest encryption feature now covers the temporary files used for external sorting and the rollback files. You can decrypt and examine the contents of the rollback files using the new perconadecrypt command line tool.

In this release, Percona Server for MongoDB supports the ngram full-text search engine. Thanks to Sunguck Lee (@SunguckLee) for this contribution. To enable the ngram full-text search engine, create an index passing ngram to the default_language parameter:

mongo > db.collection.createIndex({name:"text"}, {default_language: "ngram"})

New Features

  • PSMDB-276perconadecrypt tool is now available for decrypting the encrypted rollback files.
  • PSMDB-250: The Ngram full-text search engine has been added to Percona Server for MongoDB. Thanks to @SunguckLee on GitHub

Bugs Fixed

  • PSMDB-234: It was possible to use a key file for encryption the owner of which was not the owner of the mongod process.
  • PSMDB-269: In some cases, a hot backup was not using the correct path to the keydb directory designated for data encryption.
  • PSMDB-273: When using data at rest encryption, temporary files for external sorting and rollback files were not encrypted
  • PSMDB-272mongos could crash when running the createBackup command.
  • PSMDB-233: WiredTiger encryption options were silently ignored at server startup, although a storage engine different from WiredTiger was used.
  • PSMDB-257: MongoDB could not be started with a group-readable key file owned by root.
  • PSMDB-266: In some cases, it was possible to add arbitrary collections to the keydb directory which may only store encryption data.

Other bugs fixed: PSMDB-239PSMDB-243

The Percona Server for MongoDB 3.6.10-3.0 release notes are available in the official documentation.

Feb
05
2019
--

Upcoming Webinar Wed 2/6: Percona Software News and Roadmap Update

Percona Software News and Roadmap Update Webinar

Percona Software News and Roadmap Update WebinarJoin Percona CEO Peter Zaitsev as he presents Percona Software News and Roadmap Update on Wednesday, February 6, 2019, at 11:00 AM PST (UTC-8) / 2:00 PM EST (UTC-5).

Register Now

Come and listen to Percona CEO Peter Zaitsev discuss what’s new in Percona open source software. Topics include Percona Server for MySQL and MongoDB, Percona XtraBackup, Percona Toolkit, Percona XtraDB Cluster and Percona Monitoring and Management.

During this webinar, Peter will talk about newly released features in Percona software. He will also show a few quick demos and share with you highlights from the Percona open source software roadmap.

Peter will also talk about new developments in Percona commercial services and finish with a Q&A.

Register today to join Peter for his Percona Software News and Roadmap Update.

Jan
31
2019
--

A New PMM Dashboard to Monitor Memory Usage!

Dashboard to Monitor Memory Usage in Linux

While the PMM team works hard on our PMM 2.0 release, we have been working on a few things in the background which we’d like to show off !  In particular we have developed a new dashboard that displays metrics related to memory usage on Linux systems. The dashboard leverages information collected by node_exporter. The graphs take advantage of  /proc filesystem files, specifically:

  • meminfo: Provides information about distribution and utilization of memory. This varies by architecture and compile options.
  • vmstat: Provides information about block IO and CPU activity in addition to memory.

The information is split into five sections:

  1. Total Memory
  2. VMM (Virtual Memory Manager) Statistics
  3. Memory Statistics
  4. Number and Dynamic of Pages
  5. Pages per Zone

The dashboard will be included as part of the PMM 2.0 release. For you early adopters, you can get it from GrafanaLab and install it alongside your existing Dashboards – it won’t overwrite anything!

Please notice that the dashboard can be imported by ID (9692) in Grafana versions since 5.4.2 or should be downloaded and imported manually in older Grafana versions.

Jan
29
2019
--

Upcoming Webinar Thurs 1/31: Percona Server for MongoDB 4.0 Feature Walkthrough

Percona Server for MongoDB 4.0 Feature Walkthrough

Percona Server for MongoDB 4.0 Feature WalkthroughPlease join Vinodh Krishnaswamy as he presents his talk, Percona Server for MongoDB 4.0 Feature Walkthrough on January 31st, 2019, at 6:00 AM PST (UTC-8) / 9:00 AM EST (UTC-5).

Register Now

Percona Server for MongoDB is an enhanced, open source, and highly-scalable database. Moreover, it is a fully-compatible, drop-in replacement for MongoDB 4.0 Community Edition. It also supports MongoDB 4.0 protocols and drivers.

Percona Server for MongoDB extends the functionality of the MongoDB 4.0 Community Edition by including the Percona Memory Engine storage engine, encrypted WiredTiger storage engine, audit logging, SASL authentication, hot backups, and enhanced query profiling. Additionally, Percona Server for MongoDB requires no changes to MongoDB applications or code.

This release includes all features of MongoDB 4.0 Community Edition 4.0. Most notable among these are:

– Multi-Document ACID transactions
– Type conversion through the new aggregation operators
– Enhancements to the Change Streams support

In order to learn more, register for the Percona Server for MongoDB 4.0 Feature Walkthrough.

Jan
25
2019
--

Open Source Database Conference CFP Deadline Sunday January 27

open source database conference 2019

open source database conference 2019This year at our Open Source Database Conference we’re celebrating open source database technologies that don’t fit into the MySQL®, MongoDB®, MariaDB®, or PostgreSQL realms by featuring them in their very own track. The glamorously-named Other Open Source Databases track! As unbiased champions of open source database solutions, we embrace all flavors of open source database, and pride ourselves at presenting one of the biggest events dedicated to any and all OSDBs.

Another innovation this year is the introduction of a Java programming for open source databases track. Maybe that would be of interest?

The conference takes place at the end of May in Austin, a fantastic place to visit, and state capital of Texas.

As mentioned in a recent blog post, the Track Steering Committee featuring some very talented technologists is in place, and we are ready to start reviewing submissions.  We already have great content across all topics, but in order to make it even better, we would like to keep on getting new submissions until the very last day ?

The call for papers closes this Sunday, January 27, so there is still time for you to send a talk or two for our review. In the open source databases track, we have the following list in mind for potential good topics:

  • Apache Hive
  • Cassandra
  • ClickHouse
  • CockroachDB
  • Consul
  • Elasticsearch
  • FoundationDB
  • InfluxDB
  • Kafka
  • Neo4j
  • Prometheus
  • Redis
  • ScyllaDB
  • Solr
  • SQLite
  • Teradata
  • TiDB
  • Timescale

This list is not exhaustive, so if you can think of any others let me know—and go ahead and submit away, please!

Of course, MySQL, MariaDB, MongoDB and PostgreSQL all have their own tracks, too, so if you have any interesting talks for those, please don’t hesitate to send them in for review by their respective track steering committees.

Did we not mention? Yes, it’s Percona Live!

Jan
23
2019
--

MongoDB Replica Set Scenarios and Internals – Part II (Elections)

mongodb node election to primary

In this blog post, we will walk through the internals of the election process in MongoDB®, following on from a previous post on the internals of the replica set. You can read Part 1 here.

For this post, I am refer to the same configurations we discussed before.

Elections: As the term suggests, in MongoDB there is a freedom to “vote”: individual nodes of the cluster can vote and select their primary member for that replica set cluster.

Why Elections? MongoDB maintains high availability through this process.

When do elections take place?

  1. When the node does not found a primary node within the election timeout limit. By default this value is 10s, and from MongoDB version 3.2 this can be changed according to your needs.  The parameter to set this value is
    settings.electionTimeoutMillis

      and can be seen in the logs as:

settings: { chainingAllowed: true, heartbeatIntervalMillis: 2000, heartbeatTimeoutSecs: 10, electionTimeoutMillis: 10000, catchUpTimeoutMillis: 60000, getLastErrorModes: {}, getLastErrorDefaults: { w: 1, wtimeout: 0 }, replicaSetId: ObjectId('5ba8ed10d4fddccfedeb7492') } }

From the mongo shell, the value for the

electionTimeoutMillis

  can be found in replica set configuration as:

rplint:SECONDARY> rs.conf()
{
	"_id" : "rplint",
	"version" : 3,
	"protocolVersion" : NumberLong(1),
	"members" : [
		{
			"_id" : 0,
			"host" : "m103:25001",
			"arbiterOnly" : false,
			"buildIndexes" : true,
			"hidden" : false,
			"priority" : 1,
			"tags" : {
			},
			"slaveDelay" : NumberLong(0),
			"votes" : 1
		},
		{
			"_id" : 1,
			"host" : "192.168.103.100:25002",
			"arbiterOnly" : false,
			"buildIndexes" : true,
			"hidden" : false,
			"priority" : 1,
			"tags" : {
			},
			"slaveDelay" : NumberLong(0),
			"votes" : 1
		},
		{
			"_id" : 2,
			"host" : "192.168.103.100:25003",
			"arbiterOnly" : false,
			"buildIndexes" : true,
			"hidden" : false,
			"priority" : 1,
			"tags" : {
			},
			"slaveDelay" : NumberLong(0),
			"votes" : 1
		}
	],
	"settings" : {
		"chainingAllowed" : true,
		"heartbeatIntervalMillis" : 2000,
		"heartbeatTimeoutSecs" : 10,
		"electionTimeoutMillis" : 10000,
		"catchUpTimeoutMillis" : 60000,
		"getLastErrorModes" : {
		},
		"getLastErrorDefaults" : {
			"w" : 1,
			"wtimeout" : 0
		},
		"replicaSetId" : ObjectId("5c20ff87272eff3a5e28573f")
	}
}

More precisely the value for

electionTimeoutMillis

  can be found at:

rplint:SECONDARY> rs.conf().settings.electionTimeoutMillis
10000

2.  If the priority of the existing primary node is being taken over by another node. For example, during planned maintenance using replica set configuration settings. The priority of the member node can be changed as explained here

The priority of all three members can be seen from the replica set configuration like this:

rplint:SECONDARY> rs.conf().members[0].priority
1
rplint:SECONDARY>
rplint:SECONDARY>
rplint:SECONDARY> rs.conf().members[2].priority
1
rplint:SECONDARY> rs.conf().members[1].priority
1

How do elections work in a MongoDB replica set cluster?

Before real elections, the node runs a dry election. Dry election? Yes, the node first runs dry elections, and if the node wins a dry election, then an actual election begins. Here’s how:

  1. Candidate node asks every node if another node would vote for it through
    replSetRequestVotes

     , without increasing the term itself.

  2. Primary node steps down if it finds a candidate node term higher than itself. Otherwise the dry election fails, and the replica set continues to run as is did before.
  3. If the dry election succeeds, then an actual election begins.
  4. For the real election, the node increments its term and then votes for itself.
  5. VoterRequester sends
    replSetRequestVotes

     command through ScatterGatherRunner and then each node responds back with their vote.

  6. The candidate that receives votes from the most nodes wins the election.
  7. Once the candidate wins, it transits to primary node. Through heartbeats it sends a notification to all other nodes.
  8. Then the candidate node checks if it needs to catch up from the former primary node.
  9. The node that receives the 
    replSetRequestVotes

     command checks its own term and then votes, but only after ReplicationCoordinator receives confirmation from TopologyCoordinator

  10. The TopologyCoordinator grants the vote after following considerations:
    1. Config version must be matched,
    2. Replica set name must be matched
    3. An arbiter voter must not see any healthy primary of greater or equal priority.

An example

A primary (port:25002) Transition to secondary after receiving the

rs.stepDown()

  command.

2019-01-03T03:05:29.972+0000 I COMMAND  [conn124] Attempting to step down in response to replSetStepDown command
2019-01-03T03:05:29.976+0000 I REPL     [conn124] transition to SECONDARY
driver: { name: "NetworkInterfaceASIO-Replication", version: "3.4.15" }, os: { type: "Linux", name: "Ubuntu", architecture: "x86_64", version: "14.04" } }
2019-01-03T03:05:40.874+0000 I REPL     [ReplicationExecutor] Member m103:25001 is now in state PRIMARY
2019-01-03T03:05:41.459+0000 I REPL     [rsBackgroundSync] sync source candidate: m103:25001
2019-01-03T03:05:41.459+0000 I ASIO     [NetworkInterfaceASIO-RS-0] Connecting to m103:25001
2019-01-03T03:05:41.460+0000 I ASIO     [NetworkInterfaceASIO-RS-0] Successfully connected to m103:25001, took 1ms (1 connections now open to m103:25001)
2019-01-03T03:05:41.461+0000 I ASIO     [NetworkInterfaceASIO-RS-0] Connecting to m103:25001
2019-01-03T03:05:41.462+0000 I ASIO     [NetworkInterfaceASIO-RS-0] Successfully connected to m103:25001, took 1ms (2 connections now open to m103:25001)

Dry election at candidate node (port:25001) and success: no primary found.

2019-01-03T03:05:31.498+0000 I REPL     [rsBackgroundSync] could not find member to sync from
2019-01-03T03:05:36.493+0000 I REPL     [SyncSourceFeedback] SyncSourceFeedback error sending update to 192.168.103.100:25002: InvalidSyncSource: Sync source was cleared. Was 192.168.103.100:25002
2019-01-03T03:05:39.390+0000 I REPL     [ReplicationExecutor] Starting an election, since we've seen no PRIMARY in the past 10000ms
2019-01-03T03:05:39.390+0000 I REPL     [ReplicationExecutor] conducting a dry run election to see if we could be elected. current term: 35
2019-01-03T03:05:39.391+0000 I REPL     [ReplicationExecutor] VoteRequester(term 35 dry run) received a yes vote from 192.168.103.100:25002; response message: { term: 35, voteGranted: true, reason: "", ok: 1.0 }

Dry election succeeds and increments term by 1 (here the term was 35 and is incremented to 36). It transitions to primary and enters catchup mode.

2019-01-03T03:05:39.391+0000 I REPL [ReplicationExecutor] dry election run succeeded, running for election in term 36
2019-01-03T03:05:39.394+0000 I REPL [ReplicationExecutor] VoteRequester(term 36) received a yes vote from 192.168.103.100:25003; response message: { term: 36, voteGranted: true, reason: "", ok: 1.0 }
2019-01-03T03:05:39.395+0000 I REPL [ReplicationExecutor] election succeeded, assuming primary role in term 36
2019-01-03T03:05:39.395+0000 I REPL [ReplicationExecutor] transition to PRIMARY
2019-01-03T03:05:39.395+0000 I REPL [ReplicationExecutor] Entering primary catch-up mode.

Other nodes also receive information about the new primary.

2019-01-03T03:05:31.498+0000 I REPL [rsBackgroundSync] could not find member to sync from
2019-01-03T03:05:36.493+0000 I REPL [SyncSourceFeedback] SyncSourceFeedback error sending update to 192.168.103.100:25002: InvalidSyncSource: Sync source was cleared. Was 192.168.103.100:25002
2019-01-03T03:05:41.499+0000 I REPL [ReplicationExecutor] Member m103:25001 is now in state PRIMARY

This is how MongoDB is able to maintain high availability by electing primary node from the replica set clusters in the case of existing primary node failures.


Photo by Daria Shevtsova from Pexels

Jan
21
2019
--

Percona Live 2019: Committee Announced and a Short Extension

Percona Live 2019

Percona Live 2019We had a great response to our call for papers, thank you! However great we believe having the conference in Austin, TX will be, moving to a new area of the US is still a leap of faith until we see the numbers. So we’re thankful that so many of you continue to support and take part in our Open Source Database Conference. We have great plans for the event going forward, and look forward to sharing them with you.

In fact, one new initiative is already underway. Instead of having one relatively small committee that reviews all of the papers for all tracks, we are taking a different approach this year. Each track is led by a Percona engineer or manager in the role of “Track Champion”, and they each are establishing a Track Steering Committee to review the submissions for that one track.

There are many benefits to this approach. First of all, it means that folk with in-depth knowledge of a technology review a smaller number of papers, and can focus on that subject. It also means that the committee members can enter more meaningful dialogue with the Track Champion about the ‘shape’ of the track at the conference, to make sure that the content is of high quality and offers innovative insights… or, at least, that it addresses the issues that are most important to users of the technology.

You may know, too, that at Percona we are committed to being unbiased champions of open source database solutions. By widening the team that influences the nature of the conference, we believe we are better supporting this mission.

So who’s on the committee? You can read all about them on the conference website. Thank you, again, to all that have volunteered time and experience to this effort.

A short extension

So now you know about the changes to the committee structure. You’ve read about the people who are going to read your abstracts. And you’ve realized that the conference is going to be in an exciting new city that you’ve not visited before.

You’re kicking yourself that you didn’t manage to finish that submission, right? Life gets in the way, and wouldn’t you know it, yesterday was the NFL Conference Championship games etc etc (that’s the semi-final to those of us outside North America…)

Well, we have some great news…we’re going to give you one more week. Yes, that’s right, the deadline is extended to Sunday, January 27. Don’t miss out again, this is the last chance for your submission to be guaranteed consideration for the Percona Live Open Source Database Conference 2019. It’s going to be a great event!

And if you’ve still no plans to submit, but are keen to attend?

Mark May 28-30, 2019 in your diary and subscribe to this blog to be amongst the first to hear when ticket sales are launched.

Don’t forget, the earlier you get your tickets, the more $’s you save.
Jan
16
2019
--

Percona Server for MongoDB 3.2.22-3.13 Is Now Available

Percona Server for MongoDB Operator

Percona Server for MongoDB 3.2

Percona is glad to announce the release of Percona Server for MongoDB 3.2.22-3.13 on January, 16 2019. Download the latest version from the Percona web site or the Percona Software Repositories.

Percona Server for MongoDB is an enhanced, open source, and highly-scalable database that is a fully-compatible, drop-in replacement for MongoDB 3.2 Community Edition. It supports MongoDB 3.2 protocols and drivers.

Percona Server for MongoDB extends the functionality of MongoDB Community Edition by including the Percona Memory Engine storage engine, as well as several enterprise-grade features. Percona Server for MongoDB requires no changes to MongoDB applications or code.

This release is based on MongoDB 3.2.22. There are no additional improvements or new features on top of those upstream fixes.

The Percona Server for MongoDB 3.2.22-3.13 release notes are available in the official documentation.

Powered by WordPress | Theme: Aeros 2.0 by TheBuckmaker.com