Nach einem medialen Drehbuch scheinen immer wieder junge Männer mit einem blutigen Spektakel ihre Leben beenden zu wollen. Ist das politisch?

Are you looking to improve your MySQL performance? Application success is often limited by poor MySQL performance. Please join Percona CEO and Founder Peter Zaitsev for this exclusive webinar on Wednesday, July 20th, 2016 at 11:00 AM PDT (UTC – 7) as he presents “Practical MySQL Performance Optimization“.

Peter Zaitsev discusses how to get excellent MySQL performance while being practical. In other words, spending time on what gives you the best return. The webinar updates Peter’s ever-popular Practical MySQL Performance Optimization presentation. It covers the important points for improving MySQL performance. It also includes a discussion of the new tools and features in the latest MySQL 5.7 release, as well as their most important aspects – so you can employ them for maximum database performance.

Areas covered:

• Hardware
• MySQL Configuration
• Schema and Queries
• Application Architecture
• MySQL 5.7 New Tools and Features

Peter will highlight practical approaches and techniques for optimizing your time. He will also focus on the queries that are most important for your application. At the end of this webinar, you will know how to optimize MySQL performance in the most practical way.

Peter Zaitsev, CEO

Peter Zaitsev co-founded Percona and assumed the role of CEO in 2006. As one of the foremost experts on MySQL strategy and optimization, Peter leveraged both his technical vision and entrepreneurial skills to grow Percona from a two-person shop to one of the most respected open source companies in the business. With over 150 professionals in 20 plus countries, Peter’s venture now serves over 3000 customers – including the “who’s who” of internet giants, large enterprises and many exciting startups. Percona was named to the Inc. 5000 in 2013, 2014 and 2015.

Peter was an early employee at MySQL AB, eventually leading the company’s High Performance Group. A serial entrepreneur, Peter co-founded his first startup while attending Moscow State University where he majored in Computer Science. Peter is a co-author of High Performance MySQL: Optimization, Backups, and Replication, one of the most popular books on MySQL performance. Peter frequently speaks as an expert lecturer at MySQL and related conferences, and regularly posts on the Percona Data Performance Blog. He has also been tapped as a contributor to Fortune and DZone, and his recent ebook Practical MySQL Performance Optimization Volume 1 is one of percona.com’s most popular downloads. Peter lives in North Carolina with his wife and two children. In his spare time, Peter enjoys travel and spending time outdoors.

Erstmals wurde ein Cyberwar ausgerufen, aber offenbar hat das US-Cyberkommando bislang wenig Erfolg

Der ukrainische Journalist und Kriegsdienstverweigerer Ruslan Kotsaba wurde in einer Berufungsverhandlung freigesprochen. Ein gutes Zeichen für andere politische Gefangene?

Die beiden Austragspolitiker kritisieren das Schweigen der Bundesregierung zum Chilcot-Bericht

Was geschieht mit den türkischen Hubschrauberinsassen, die im griechischen Alexandoupolis gelandet sind?

Der Präsident der Philippinen fordert seine Bürger auf, Dealer und Drogenabhängige in Eigenregie zu beseitigen

Nach Dallas hat wahrscheinlich wieder ein junger Schwarzer drei Polizisten in Baton Rouge erschossen, wo vor zwei Wochen ein Schwarzer von Polizisten mit Schüssen getötet wurde

Labour erhöht Mitwahlgebühr von drei auf 25 Pfund - die höhere Urwahlabgabe müssen auch neu eingetretene Corbyn-Anhänger entrichten

Es drängen sich Parallelen zum letzten Putsch in Spanien 1981 auf, der zur Absicherung der Monarchie diente

Wann es den strafrechtlichen Abschlussbericht des JIT geben wird, steht in den Sternen, Russland, die Ukraine und die USA sind sich in der Blockade einig

Über die Folgen der Automatisierung und den Mythos der Vollbeschäftigung

Präsident Erdogan fordert die Menschen auf, gegen den Putsch auf die Straßen zu gehen

Was nutzt ein Ausnahmezustand und die Bombardierung von Syrien, wenn ein junger, offenbar nicht religiöser Mann aus persönlichen Motiven ein finales und blutiges Aufmerksamkeitsspektakel insziert

Warum man jeden neuen Roland-Emmerich-Film gesehen haben sollte

Die Regierungen von Bayern, Nordrhein-Westfalen und Schleswig-Holstein sollen darauf verpflichtet werden, im Bundesrat gegen CETA zu stimmen

Come speak at Percona Live Europe, and get access to the entire conference.

The Percona Live Open Source Database Performance Conference Europe 2016 is the premier event for the rich and diverse MySQL, MongoDB and ODBMS ecosystems in Europe. Attendees include DBAs, SysAdmins, developers, architects, CTOs, CEOs, and vendors from around the world. It’s a great place to meet and participate with the open source community.

Want to go, but having a hard time getting the budget approved? We have a solution: be a speaker and get a complimentary full pass!

Submit your speaking proposal for a Percona Live session and share your MySQL, MongoDB and ODBMS ideas, case studies, best practices, and technical knowledge in front of an intelligent, engaged audience open source technology users. If selected as a speaker by our Conference Committee, you will receive a complimentary full conference pass.

Speaking at Percona Live is a great way to further the goals of open source software, and give back to a community that is literally changing the world.

Below are examples of some of the outstanding speakers from this year’s Percona Live Conference in Santa Clara. Speakers are made up of CEOs, Directors, DBAs, and a celebrity or two:

• Let Robots Manage your Schema (without destroying all humans)!
  Jenni Snyder, MySQL DBA at Yelp
• A quick chat with Bill Nye, the Science Guy!
  Bill Nye, CEO of The Planetary Society
• High Availability Using MySQL Group Replication
  Luis Soares, Principal Software Engineer at Oracle
• Running MongoRocks in Production
  Igor Canadi, Software Engineer at Facebook
• Operational Buddhism — Building Reliable Services from Unreliable Components
  Ernie Souhrada, Database Engineer and Bit Wrangler at Pinterest
• MySQL and Docker Strategies
  Giuseppe Maxia, Quality Assurance Director at VMware
• What’s New in MySQL
  Geir Høydalsvik, Senior Software Development Director at Oracle, and Simon Mudd, DBA at booking.com

Speaking at Percona Live puts you in some pretty great company, and pays for your pass! Submit your speaking proposal today! The submission deadline is Monday, July 18th.

See the interviews from some of our speakers from this year’s Percona Live Conference in Santa Clara below.

In this post, I want to talk about MongoDB data durability options across MongoDB versions.

I consider a write durable if, once confirmed by the server, it becomes permanent at the node or cluster level (ignoring catastrophic failures like all nodes on a cluster failing at the same time).

MongoDB lets you choose between different levels of data durability using Write Concern. Unlike server-side configured durability (as you get with Innodb using innodb_flush_log_at_trx_commit), the client specifies the Write Concern on each write operation.

As indicated in the linked manual page, the Write Concern specification can include a w and a j field (among other things).

The w field determines the number of nodes that must confirm a write before the client acknowledges it, with the following possible values:

• 1: meaning the primary,
• “majority”: meaning a majority of the nodes,
• Any other integer value, meaning that many nodes.

The j field requests acknowledgement that for every node determined by the “w” value, writes are confirmed to the on-disk journal. Otherwise, the write is confirmed only in memory.

How the client specifies Write Concern depends on the programming language and driver used. Here is how it javascript does it, using the mongo command line client:

db.test.insert({_id: 1}, {writeConcern: {w:1, j:1}})

while to use the same write concern on C, with the mongo-c-driver, you must do this before the corresponding write operation:

mongoc_write_concern_t wc = mongoc_write_concern_new();
mongoc_write_concern_set_w(wc, 1);
mongoc_write_concern_set_journal(wc, 1);

To get a better understanding of what this means from a durability perspective I ran a few tests using the following environment:

• A single client, using the mongo command line client, inserting an auto-incrementing integer as the single field (_id) of a collection.
• Standalone mongod, and a replica set of 4 mongod instances, all on the same machine. You can repeat the tests using this script as a guide (the only requisite would be that mongod and mongo are on the shell’s path).
• SIGKILL sent to the Primary node while the writes are happening.
• Comparing the last value for _id reported by the client, with the maximum value available in the collection, on the new Primary node after the replica set reconfigures (or on the standalone mongod, after I manually restarted it).
• MongoDB 3.0.4 and 3.2.7, using WiredTiger as the storage engine.

(I’ll discuss performance perspectives in a future post.)

In all cases, I indicate “missing docs” if the value reported by the client is higher than the value reported by db.collection.find().sort({_id:-1}).limit(1)

Here are the results for a standalone mongod:

Standalone w j Missing docs 1 1 No 1 0 Yes 0 0 Yes 0 1 No

 

The first three don’t hold surprises, but the last one does. The mongo-c-driver does not let you specify a write concern of {w:0, j:1}, and a cursory inspection of the MongoDB code makes me believe that “w:0” is interpreted as “w:1”. This would explain the result.

Here are the results for a four node replica set:

Replica Set w j Missing docs “majority” 1 No “majority” 0 No 0 1 Yes

 

Again, w:0, j:1 is transformed into w:1, j:1. How can no data get lost in a standalone mongod, but can get lost in a replica set? The answer is in the standalone case, after SIGKILL I restarted the same instance. In that case, WiredTiger performs crash recovery. Since we request acknowledgement for write confirmation to the on-disk journal, the last _id is recovered (if needed), and no docs go missing.

However, in my replica set tests, I did not restart the SIGKILLED instance. Instead, I let mongod do its thing and automatically reconfigure the set, promoting one of the Secondaries as a new Primary. In this context, having a write concern that only requests acknowledgements of writes on the master is a liability, and leads to lost data.

When specifying w:”majority”, it is important to note that the value j:0 gets replaced with j:1 since version 3.2. That explains the lack of lost documents. I also tested 3.0 and, in that case, docs went missing when using w:"majority", j:0. This probably explains the behavior changed in 3.2, and, depending on your use cases, might justify an upgrade if you’re on an older version.

In conclusion, MongoDB data durability options lets you satisfy different requirements on a per operation basis, with the client being responsible for using the desired setting. When using a Write Concern that does not guarantee full durability, a mongod crash is enough to cause the loss of unconfirmed documents. In this sense, the Write Concern values that include j:0  are analogous to running Innodb with innodb_flush_log_at_trx_commit set to 0.

The “majority” value for the w component is valid even in the standalone case (where it is treated as “1”), so I think {w:"majority", j:1} is a good value to use in the general case to guarantee data durability.

Auf den Philippinen und in Honduras wurden Umweltschützerinnen ermordet, die offensichtlich Geschäftsinteressen von Unternehmern im Wege standen

Staatsanwaltschaft: "Alles deutet auf Suizid hin", aber Fragen bleiben