The MySQL database administration and developing is a very interesting field to be in. If you ever thought about taking your career into that field then here is a guide that might help you get started.
The first thing you should know from an industry point-of-view, there are very very few MySQL DBAs around. The companies that are looking for them range from start-ups that have matured and done well for themselves to large enterprises that have figured that MySQL is by now, safe to use.
Unfortunately, there are a few issues with finding work in MySQL and I will address them in this post.
Firstly, who usually turns out to be a MySQL DBA?
From my experience (and the research done by a recruitment agent who specializes in this niche), you are in one of three roles at the moment:
1) A developer who discovered that MySQL and relational databases are easy to understand (aka the accidental DBA).
2) A system administrator who has had to maintain and monitor MySQL DBs for some time
3) (A lot rarer) An existing DBA in MS SQL or Oracle who wants to switch over to MySQL.
I have yet to encounter something who "jumped the chasm" from nothing stright into MySQL DBAing and I suppose that this learning curve and career leap-of-faith is why there are so few of them out there.
Secondly, why would you like to be a MySQL DBA?
Well, as I mentioned, this is quite a niche. Salaries can reflect that. Here in London UK, you can currently get between £40,000 to £75,000 depending on your experience or you can contract for £350 - £550 a day, all with the usual agencies. I am not that familiar with American salaries, but I have seen $95,000 to $120,000 per year.
While the money is good and allows me a level of comfort, I find MySQL and relational databases quite interesting. It seems to me like a very critical role where you need to be knowledgeable of quite a few areas:
1) You need to understand how the application uses the database and the manner in which it needs data from it.
2) You need to understand how problems can be solved using relational models (or algebra).
3) You need to understand how the database tries to fulfil requests for data, like using indexes and how they work.
4) You need to have a deep understanding of how the hardware works with the databases.
I guess you can see this role as the "anti-abstraction" between the application and the hardware. I always found that fascinating.
I also feel that data can help us understand a lot and have always tried to help with business intelligence, reporting and now, Big Data. I feel that insights from data can really help... for lack of a better word, mankind in the long run.
But that's just me. Your motivations could be different.
Finally, what are the issues between you and finding a MySQL job?
Being a niche has meant that it has taken some time for a standard to form to make finding work smoother.
No Official Standards
A lot of companies that advertise for a full-time MySQL DBA (for the first time) from my experience do not have a good idea what they are looking for.
You can think of the situation like this:
The people in the company, be it developers or system administrator, complain to management that they need a professional to come in help solve some difficult problems. Those people have been trying to solve those problems on their own, but are unsure if they are doing it right or that the results are not what they had hoped for.
Management approaches either their HR department or an agency to help them find the right person. What I have seen is that those agencies or HR people get some standard for a DBA from a different technology such as Oracle or MS SQL.
For example, if you see on a job advertisement "Must know how to write procedures, functions and triggers" then it maybe the case that the role was converted from MS SQL. Why? Because it is rare that companies that use MySQL use stored procedures, functions or triggers and tend to prefer to keep the logic inside their application.
(Although I am currently working for a company that does in fact use quite a few store procedures). You have to use your own discretion and see for yourself.
Pre-packaged Contracts
If the hiring company is using agencies, another problem would be that they have to fit the agency's template. For example, if it is a contract position, it has to fit within a three to six months time period. Agencies will not entertain the idea of anything less then that time frame (although I have seen someone con an agency with a two-week trial period). If a contract needs less then three months then you will find yourself sitting on your hands in some office drinking free-but-bad coffee and counting the minutes till you come home.
Not Fully Understanding the Role
A real problem I have seen with full-time positions is over-estimating how long some tasks will take to complete. I have seen managers come to me with a mental list of tasks for the next six months to a year only to be confused when I complete this list within a month or a month and a half. It seemed to me that the work given to me was estimated for a developer to "code a solution to this problem" within a period of six months, because those managers were more familiar to that type of estimation.
I usually ask how many servers they have to know if that position is right for me. In cases like that, you may have to take some initiative and find yourself some additional work. Monitoring and backups projects are usually good in those situations.
It could be that some of my views are a little outdated and the situation is not as bad as I remember it a few years ago. Today, I went to see some job advertisements as research for this post and they were not too bad. However, I would like to pass on my experiences to future MySQL DBAs at the risk of sounding as if I am ranting.
How do you make the leap into being a MySQL DBA?
This would be my suggestion:
1) Take more interest in your MySQL DB at your current work till you feel comfortable with it.
2) Read articles online. When I first started, this was one of the biggest reason why I decided to be a MySQL DBA. The community around MySQL was/is very welcoming.
3) Try new things that you read about or came up by yourself - but in your own testing environment. Make doubly sure your findings are correct before recommending it to your company.
4) Optional: go to a course as a supplement to the above points, not a replacement.
Like many things in open-source, you need to get your hands dirty and dive right in. You need to be curious about it and it needs to excite you. Do not be afraid to try new things and mitigate risks by setting up your own testing environment to practice on. And when you get to a stage when you think you know a lot, buy a few books on the subject and you will discover how much more you can learn about it.
Good luck if you should choose this profession and feel free to ask questions in the comments area.
What you say makes a lot of sense. I'd also suggest that there are some gotchas or differences with MySQL which can make the switch tricky and people expect different things:
ReplyDelete1. MySQL engines. These provide different ways of storing data, have different configuration options and thus can dramatically change how a mysql server behaves. A MySQL DBA needs to be aware of these. This does not really come up the same way in other RDBMSes.
2. MySQL is not always feature complete. MySQL is now much more mature but DBAs coming over from other RDBMSes may have to adjust to the fact that for somethings MySQL may be poor, and thus problems need solving differently (use of sub-SELECTs used to be a real no-no in MySQL land). On the other hand fan-out replication works very well and is "trivial" to setup (one of the reasons that MySQL become so popular). So sometimes it can be frustrating coming over from a different RDBMS, and take a while to adapt to its differences. There's a lot more documentation now than a few years ago but these differences often make you approach a problem differently and come up with a solution which might not make sense with other platforms.
3. I'd guess also that many MySQL DBAs have a lot more knowledge of the underlying OS and hardware than perhaps DBAs of other RDBMSes: that's really needed with MySQL as sometimes a lot of the tooling to tell you what's going on is outside of the database, and you can change the way mysqld runs quite significantly without actually touching the mysqld configuration. Other RDBMSes I guess have more of an environment to live in so perhaps don't need to leave that environment and can live from the SQL command shell. I think most MySQL DBAs don't do that.
Finally I've been told that at many MySQL conferences _all_ the speakers say they are hiring. That's certainly unusual, but for those who are looking to move good news as I guess there are a lot of opportunities out there.