Open Query blog » Uncategorized

The Anti-SQL Coalition – The Daily WTF

arjen — Tue, 22 Nov 2011 02:49:53 +0000

http://thedailywtf.com/Articles/The-AntiSQL-Coalition-.aspx

“There is a small coalition of developers at the office who are vehemently anti-database,” writes Bob, “naturally, this faction also doesn’t value ‘experience’ — mostly, because they have none. At least, not outside their university studies. They’ll often liken a database server to a file system, and suggest that it’s just a convenient way to store blobs of data — but everything else is inelegant bloat.”

Open Query looking for new colleagues!

arjen — Thu, 15 Sep 2011 04:42:05 +0000

My colleagues and I are looking for extra talent – is that you? What we do:help clients prevent problems (rather than being the fire department), we work on a subscription basis although we also do some ad-hoc consulting, and training. Apart from MySQL/MariaDB query and DBA work, we do quite a bit of system administration. Mainly Red Hat and Debian based distros, and expect to see replication and the MySQL-MMM multi-master system. You’d work from home, whereever it might be, so you will need to be self-motivating (but we do keep in touch online). What we’re not: a full-time employer. With us, you make a life rather than a living. Everybody is contracted part-time. You can make enough to live comfortably, but that has nothing to do with hours. If you’re stressed about not filling all hours in your week with work-work-work, we’re not the company for you… there’s more to life than work, and we feel that’s really important. Haven’t scared you off yet? Groovy. Take a peek at our jobs page for additional detail and contact info. Hope to hear from you!

Various Anniversaries

arjen — Tue, 13 Sep 2011 02:33:27 +0000

This week, ten years ago, I was in London for MySQL AB‘s first “train the trainer” course, also meeting (for the first time) my first boss at MySQL Kaj. I’d been hired mid August as employee#25, also doing training but actually primarily as tech-writer for the MySQL documentation (taking over from Jeremy Cole, and essentially I was the documentation team for quite some time . So from this you can deduce that yes, I was hired without meeting either Kaj or anyone in-person! I don’t think we even had a phone call, only email. Oh the days The training week itself was of course disrupted quite a bit by the events in New York. We had Jeremy who had come on a UA flight from the US, and others from all over the place… it also taught some students a lesson about browsing the net while in a training course, it can end up very distracting. The oddest event I remember about that particular trip happened upon departure from Heathrow: someone with a clipboard went round the long queues asking whether anybody was carrying eyebrow tweezers. No other items/questions, just that. I stayed with MySQL for about 6 years, until with a brief break, I started my own company Open Query in 2007 (about half a year before the Sun acquisition). So this September marks the 4-year anniversary of that event already. I spotted an old business card earlier, reminding me that early on we did not just MySQL consulting and training, but also (OSS) business advice – that’s now essentially spun off to Upstarta. The MySQL side of my business has changed quite significantly as well, going from the usual reactive consulting to proactive subscriptions, in part based on Pythian‘s successful model. A key difference has been that we don’t do emergencies. This disruptive shift happened somewhat by luck, after a talk at Linux Users of Victoria in April 2009. Ben Dechrai made a video recording of this interactive “Relax! A Failure is not an Emergency…” try-out. It also mentioned the BlueHackers initiative/stickers. While some people including competitors regard our “no emergencies” approach as nuts , it has worked out very well and apart from making customers happy it’s created the sane lifestyle I was looking for (so I could spend more time with my daughter), and enabled contracting others as well. We’re still growing organically, having adapted our internal tools and processes for the proactive service approach along the way – obviously, it’s now more about project management than handling incident tickets. Like my time at MySQL AB, my journey since then has so far proven interesting, educational, and mostly enjoyable. Later in the year I aim to once again buy a house with a modest garden. And it’s the independence that’ll have made that -and my other explorations- possible. Who knows what lies ahead – most fun when you create your own future!

Wikileaks Cable Offers New Insights Into Oracle-Sun Deal | PCWorld Business Center

arjen — Wed, 31 Aug 2011 02:59:44 +0000

WikiLeaks Cable Offers New Insights into Oracle-Sun Deal (PC World)

Nothing too new or shocking in there, but the cable does offer some interesting insights.

A Stick Figure Guide to the Advanced Encryption Standard (AES)

arjen — Wed, 24 Aug 2011 00:24:42 +0000

http://www.moserware.com/2009/09/stick-figure-guide-to-advanced.html

Jeff Moser on software development

Open Query, new on Fifth Ave

arjen — Fri, 01 Apr 2011 02:22:35 +0000

Some of you already know since you helped us move, we recently shifted Open Query’s main office to Fifth Avenue, next door to Elizabeth’s. The new place is comfortable, I really like it so far. Anna is also happy with her new admin space and cat Figaro has found an empty spot on a bookshelf to stretch out on! The lease costs are a bit steep, as is common these days… chances are we’ll just buy our next place.

Follow-Up yes this was an April 1st post. But, everything in the above post is the truth, it’s just phrased to be very open for a bit of mis-interpretation I find that the real world provides plenty of fun and unbelievable yet true tidbits, so why bother making up nonsense!

PayPal & decisions on acceptable use

arjen — Tue, 07 Dec 2010 07:25:29 +0000

As you may know Open Query uses PayPal for some of its financial transactions. I filed the following question with PayPal support. Note that with this question I regard it as completely immaterial whether one supports of Julien Assange or WikiLeaks actions or not. Naturally companies have the right to choose which clients to serve, but in this case they did cite a specific clause as the reason for cancellation and I don’t see how it applies. Also, PayPal is close to an effective monopoly in its sphere of operation, and that too comes with consequences and responsibilities. Anyway, the letter is below – naturally I’ll also post PayPal’s response. === As a business client of PayPal, I would like to inquire what PayPal’s decision making process is regarding violation of its “Acceptable Use” Policy. I refer specifically to the published (https://www.thepaypalblog.com/2010/12/paypal-statement-regarding-wikileaks/) permanent restriction of the WikiLeaks account, quoting “… payment service cannot be used for any activities that encourage, promote, facilitate or instruct others to engage in illegal activity.” Considering that at this point in time no charges have been laid against WikiLeaks for any of its activities, in any country, and not even a subpoena has seen the light of day, what basis did PayPal use for this decision? Surely if there is illegal activity, this is typically indicated by a criminal conviction or at least a subpoena related to a prosecution. I find it extremely worrying, and would appreciate some more clarity as this may our continued use of your service. Naturally companies have the right to choose which clients to serve, but in this case PayPal did cite a specific clause as the reason for cancellation and I don’t see how it applies. Obviously, we would prefer to not conduct business through an organisation which may at any point cancel our service for essentially arbitrary reasons which may include political disagreement, lobbying by third parties, or other forms of pressure. It would be great to narrow down that list of possibilities, ideally to 0. The law exists for a reason, it protects us all. Companies can’t go about playing judge&jury. Awaiting your response, Regards, Arjen Lentz Exec.Director, Open Query === PayPal’s initial response

Thank you for contacting PayPal in regards to our acceptable use policy and our decision made on the account for WikiLeaks. For security reasons we cannot discuss any details of a PayPal account with a third party. The status of a PayPal account can only be discussed with the account holder to ensure that sensitive account information is not disclosed. For more information regarding WikiLeaks donations, we advise you to contact the organization called Wau Holland used to raise funds for WikiLeaks. To learn more about the Acceptable Use Policy, please refer to our Help Centre and the Legal Agreements section on the PayPal website.

=== My reply Thank you for your reply. The documents you’re referring to explicitly do not answer my question, which is why I asked. I am inquiring about other publically available information, from you, and asking for clarification: PayPal made a public statement about cancelling Wau Holland’s PayPal service, quoting a specific sentence from the acceptable use policy. It’s at https://www.thepaypalblog.com/2010/12/paypal-statement-regarding-wikileaks/ So, both the fact that an account was cancelled and some aspect of the reasoning was made public by you. So all I am asking is clarification of your own this public statement, as it affects me as a PayPal client. The sentence you refer to in the publication is “… payment service cannot be used for any activities that encourage, promote, facilitate or instruct others to engage in illegal activity.” and such matters are, by nature, a matter of public record also. Therefore, it should be no problem at all for you to simply tell me what illegal activity you are referring to. Did they promote, facilitate or instruct? Which one is it? And which illegal activity? As you’ll be aware, what is “illegal” is defined by law; if the law has been broken, charges can be filed – then of course there is a presumption of innocence, but if a case is proven and a conviction is made, then naturally action is taken. No charges have been filed against Wau Holland, thus PayPal appears to have no legal basis for its action – it amounts to arbitrary choice and not actually based on the stated Acceptable Use clause. As I mentioned in my original question, of course a company has the right to choose its customers – that’s why it has terms, conditions, acceptable use policies, etc. It makes it clear to would-be-customers what can be expected. If you put in a clause “we reserve the right to cancel any client’s service at any point at our discretion” then indeed you can do what you like, and clients know what to expect. It’s clear. However, that’s not what you did. In this case your actions don’t appear to jive with your own published policies, and your initial response to me does not inspire any more. The issue in a way has nothing to do with WikiLeaks or Wau Holland and whether their actions are likable or not. But what it appears to mean for PayPal clients: if a malicious third party contacts PayPal or PayPal itself “feels like it”, my account may be suspended even if I did not break any stated PayPal policy. As a person, and entrepreneur, this worries me greatly. It becomes a matter of PayPal being predictable and trustworthy as a business partner. I think that is quite worthy of a more constructive and comprehensive response from the side of PayPal. thanks Regards, Arjen. === Their reply (9 Dec) Thanks for contacting PayPal. I appreciate the opportunity to assist you with your questions. (yes that was the entire reply) === My reply (9 Dec) yes? I too would appreciate that [assisting me with my questions], but you haven’t so far. The above text was the only bit in your email, not actually addressing my questions. Looking forward to your proper reply. thanks === No further correspondence was received. On the same day though, this appeared in the press: Caving to pressure from supporters, PayPal releases WikiLeaks’ funds Well, that’s something, But doesn’t actually address the questions I raised, which were of a generic business nature and not restricted to the WikiLeaks issue. The issue is that PayPal appears to be an unpredictable business partner, not adhering to its own terms of service when (for whatever reason) it sees fit. That is a serious problem.

Cache pre-loading on mysqld startup

arjen — Wed, 01 Dec 2010 06:08:58 +0000

The following quirky dynamic SQL will scan each index of each table so that they’re loaded into the key_buffer (MyISAM) or innodb_buffer_pool (InnoDB). If you also use the PBXT engine which does have a row cache but no clustered primary key, you could also incorporate some full table scans. To make mysqld execute this on startup, create /var/lib/mysql/initfile.sql and make it be owned by mysql:mysql

SET SESSION group_concat_max_len=100*1024*1024;
SELECT GROUP_CONCAT(CONCAT('SELECT COUNT(`',column_name,'`) FROM `',table_schema,'`.`',table_name,'` FORCE INDEX (`',index_name,'`)') SEPARATOR ' UNION ALL ') INTO @sql FROM information_schema.statistics WHERE table_schema NOT IN ('information_schema','mysql') AND seq_in_index = 1;
PREPARE stmt FROM @sql;
EXECUTE stmt;
DEALLOCATE PREPARE stmt;
SET SESSION group_concat_max_len=@@group_concat_max_len;

and in my.cnf add a line in the [mysqld] block

init-file = /var/lib/mysql/initfile.sql

That’s all. mysql reads that file on startup and executes each line. Since we can do the whole select in a single (admittedly quirky) query and then use dynamic SQL to execute the result, we don’t need to create a stored procedure. Of course this kind of simplistic “get everything” only really makes sense if the entire dataset+indexes fit in memory, otherwise you’ll want to be more selective. Still, you could use the above as a basis, perhaps using another table to provide a list of tables/indexes to be excluded – or if the schema is really stable, simply have a list of tables/indexes to be included instead of dynamically using information_schema. Practical (albeit niche) application: In a system with multiple slaves, adding in a new slave makes it start with cold caches, but since with loadbalancing it will pick up only some of the load it often works out ok. However, some environments have dual masters but the application is not able to do read/write splits to utilise slaves. In that case all the reads also go to the active master. Consequentially, the passive master will have relatively cold caches (only rows/indexes that have been updated will be in memory) so in case of a failover the amount of disk reads for the many concurrent SELECT queries will go through the roof – temporarily slowing the effective performance to a dismal crawl: each query takes longer with the required additional disk access so depending on the setup the server may even run out of connections which in turn upsets the application servers. It’d sort itself out but a) it looks very bad on the frontend and b) it may take a number of minutes. The above construct prevents that scenario, and as mentioned it can be used as a basis to deal with other situations. Not many people know about the init-file option, so this is a nice example. If you want to know how the SQL works, read on. The original line is very long so I’ll reprint it below with some reformatting:

SELECT GROUP_CONCAT(CONCAT(
  'SELECT COUNT(`',column_name,'`)
          FROM `',table_schema,'`.`',table_name,
          '` FORCE INDEX (`',index_name,'`)'
       ) SEPARATOR ' UNION ALL ')
  INTO @sql
  FROM information_schema.statistics
  WHERE table_schema NOT IN ('information_schema','mysql')
  AND seq_in_index = 1;

The outer query grabs each regular db/table/index/firstcol name that exists in the server, writing out a SELECT query that counts all not-NULL values of the indexed column (so it must scan the index), forcing that specific index. We then abuse the versatile and flexible GROUP_CONCAT() function to glue all those SELECTs together, with “UNION ALL” inbetween. The result is a single very long string, so we need to tweak the maximum allowed group_concat output beforehand to prevent truncation.

Oracle Blamed for Laws of Nature

arjen — Fri, 05 Nov 2010 01:53:02 +0000

A catchy headline, and I believe more accurate than Oracle Puts the Squeeze on SMBs with MySQL Price Hike (Network World) and MySQL price hikes reveal depth of Oracle’s wallet love [MySQL Jacking up MySQL Prices] (The Register). Slightly more realistic is Oracle kills low-priced MySQL support (again The Register). First, let’s review what Oracle has actually done: they ditched the MySQL enterprise Basic and Silver offerings. For Oracle, that makes sense. Their intended client base is “enterprise” (high end, think big corporates) and their MySQL sales and cost structure reflects this. It’s not a new thing that came with MySQL at Oracle, because MySQL at Sun Microsystems and MySQL AB before it had the same approach. A company simply cannot operate below its market – that is not simply a matter of choice, instead it is dictated by their processes and cost structure. Smart people like Clayton Christensen at Harvard Business School have done ample research on this, here I’ll just give one simple example: If you hire a sales person on commission and their quarterly quota is $100k, then they have to talk with clients that have at least a $10k-$20k potential (qualified leads), and they need to close (sign contract) with at least 10 within the period. They simply cannot spend any time on talking with potential $1k customers. We may lament this state of affairs, but you can see how, given the choices made (sales person hired, commission system, quota), it’s as inevitable as an apple falling when you drop it. The way I describe this at Upstarta: if a company wants different results, they need to make sure that their business processes and cost structure lead them in that direction. But the simple fact is that most companies don’t have an internal feedback cycle that keeps an eye on these things, so they just go with the flow of consequences of common choices: aim for large(r) clients, grow turnover, get higher operational costs along the way – that in itself is a cycle and the only direction this particular one can go is up. As a natural consequence, over time old low-end offerings and clients need to be jettisoned – one way or another. I say horay for Oracle to finally acknowledge this, since Sun Microsystems and MySQL AB before it did not (for whatever reason). This is years overdue. Whether the original MySQL company should have aimed to also serve smaller clients also is an entirely separate topic – and one which I covered at length previously (including internally in my time at MySQL AB), but it’s very much a station long passed. Once you float upward in the market, you can’t operate or move downward. Now, are SMBs using MySQL actually getting squeezed by Oracle? They are not. There is no lock-in. This is about service contracts, not licensing. As we all know, MySQL is GPL licensed and internal use (even on a website or SaaS offering) is well within GPL parameters. There are a number of different companies offering service for MySQL, different types of service and delivery models and a corresponding wide range of pricing. So SMBs and anyone else has a choice, each can pick the type of service most suited to their needs. Let us celebrate and promote that freedom within the MySQL ecosystem, rather than being outraged about dropped apples falling!

Replication and “the lost binlog”

arjen — Fri, 03 Sep 2010 01:26:44 +0000

Unless you set sync_binlog = 1, a system crash on the master will likely fail any slave with an “Client requested master to start replication from impossible position” error. Generally, this kind of situation requires manual intervention. When we see this, we make sure things indeed failed “past the end” of a binlog (i.e. the bit that didn’t get to the physical platter before the crash), reposition the slave to the next binlog, and use the Maatkit tools to ensure the slave is properly synced. sync_binlog=1 is a problem in itself, because it makes the server not just do one fsync per commit, but several and that’s serious overhead. sync_binlog is actually not a boolean but a “fsync binlog every N commits” where 0 meaning “never”. So you could set it to 10 (fsync every 10 commits) and thus reduce the loss a little bit while not doing too much harm to performance. But it’s not ideal and won’t always prevent the above error.