[sclug] JOB: *nix (pref CentOS or RH) Sysadmin with "good" MySQL skills (Reading, UK) [previously advertised as MySQL database architect]

jt@camalyn.org jt
Wed Feb 25 12:36:31 UTC 2009


hi List Members - ?following a shift in my clients internal requirements
- where the emphasis is no longer on recruiting someone into a design
role, although this *may* be there in the future for someone to grow
into - ?the client would like to hire instead a *nix sysadmin (pref
CentOS or RH) that has good MySQL skills,  other DB skills, e.g. Oracle,
are no longer a substitute as the focus is once again more on someone
who can improve the client's existing systems.

Please contact me off list (using james at camalyn.org) for further
details.

all the best,
JAMES



On Tue, 2009-02-10 at 13:09 +0000, jt at camalyn.org wrote:
> ?Hi List Members
> 
> ?Having re-discussed this job with the client I can now say that
> exclusive experience with MySQL is not necessarily what the client are
> looking for.  Although the database architect should certainly be
> familiar with MySQL.  What?s more important is that the candidates have
> experience designing large, replicated, globally distributed databases
> built for performance. 
> 
> If it helps, previously I have recruited a MySQL Database Admin/
> Architect in Reading (where this role is also based) at a base salary of
> ?55k.  
> 
> Please do contact me off list to discuss further.
> 
> Kind regards,
> JAMES
> 
> 
> On Thu, 2009-01-29 at 12:46 +0000, jt at camalyn.org wrote:
> > 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