[sclug] JOB: MySQL database architect (Reading, UK)
jt@camalyn.org
jt
Thu Jan 29 12:46:08 UTC 2009
JOB:
hi List,
I am working with a client in Reading (Berkshire, UK) who are looking
to ?recruit a MySQL database architect to work closely with their
development and operations teams - both of which are growing parts of
the clients overall business. Whilst the developers have had some
involvement with capacity planning and performance monitoring of the
live system in conjunction with the Operations team this responsibility
will move entirely to the database architect over time.
?This isn't a development role so the db architect wouldn't be taking
over the writing of all SQL or anything (which would be impractical in
any case) but they would be expected to use their expertise in advising
the developers how best to tune their code. ?Stored procedures are not
currently used but they will probably look at it in the future and this
again would be something that the architect would certainly get involved
in as well as requirement to revisit existing SQL with a view to perhaps
rewrite and/ or optimise.
They are running a mixture of ?4.1 and 5.0. They don't run enterprise as
they always aim to employ talented staff so they can support everything
as far as possible in house. This goes for the OS as well, which is why
they use CentOS and not RHEL.
?
Although as part of the role's remit will be to find new opportunities
to exploit new features or better use existing ones there are ?no
immediate plans to upgrade to 5.1 as they are quite happy for early
adopters to find and fix the bugs before they make any decision on it.
Currently there are no specific bottlenecks or db problems as such, the
focus is changing in such a way that they need to be able to store more
data and consequently they need to have the architect in place.
However, although there are no specific issues, there is also a focus on
continual improvement of what they have. As with all IT systems, there
is always something that can be optimised. Identifying potential future
bottlenecks and avoiding them is also part of the role.
In terms of the number of high transactional servers - which would be
the definite focus - we are looking at high 30s. They do use MySQL
replication but not clustering at this time.
If anybody is interested in discussing this role with me further
(including salary) please contact me off list using james at camalyn.org
All the best,
JAMES
>> to learn more about Camalyn please visit http://www.camalyn.org
More information about the Sclug
mailing list