Que dois-je demander lors d'un entretien MySQL DBA?

Je suis développeur de logiciels et j'aide mon équipe à embaucher un DBA MySQL. Les principaux défis auxquels nous sommes confrontés sont les suivants:

• Requêtes et performances plus lentes dues à Hibernate.

• Gestion de base de données (sauvegardes, optimisation, correctifs, sécurité).

• Évolutivité due à l'augmentation des données provenant de nouvelles sources de données et à l'accumulation de données plus anciennes.

• Nous prévoyons de commencer l'exploration et l'entreposage de données à l'avenir. Je ne sais pas comment mais c'est la direction.

Nous avons généralement des cas de programmation où nous demandons aux développeurs de créer quelque chose pour une interview, mais il est un peu difficile de faire une interview DBA de la même manière.

Pouvez-vous donner des suggestions sur la façon dont l'entretien devrait être mené?

Pas une liste complète, mais une liste approximative de choses que j'essaierais de couvrir. Cela dépend également du fait qu'il s'agira du premier "vrai" DBA ou d'une équipe DBA. Que le DBA soit également responsable des machines, ou seulement de la base de données en plus. etc.

• quelle configuration RAID doit être utilisée
• stratégies de sauvegarde des bases de données.
• Des choses spécifiques à MySQL comme les différences entre MyISAM et InnoDB
• stratégies de sauvegarde et restauration
• Laissez-les faire des requêtes SQL et une optimisation des requêtes (utilisation d'expliquer, etc. même lorsque vous utilisez hibernate. Parfois, il est bon de contourner hibernate pour gagner en performances)
• ai-je mentionné des stratégies de sauvegarde
• Pour l'évolutivité, un administrateur de base de données doit connaître les différents modes de réplication (RBR, SBR, réplication en mode mixte, maintenance de la réplication telle que l'observation du retard de réplication et la maintenance du journal des événements)
• Réglage InnoDB
• Quels types de fichiers sont écrits par la base de données (par exemple, ibdata et fichiers journaux) et comment ils peuvent être organisés (par exemple, un fichier ibdata par table, les déplacer sur différentes partitions, compression InnoDB)
• Discutez des outils de surveillance. Qu'utilisez-vous, ont-ils de l'expérience avec cet outil ou un outil similaire?
• J'examinerais également des outils système comme iostat / memstat / vmstat / tout ce que votre système d'exploitation fournit. Donnez-leur un système avec une certaine charge et laissez-les trouver la cause
• Et peut-être discuter des problèmes de sauvegarde MySQL et surtout de restauration ;-)

Je suis sûr que d'autres ici peuvent étendre cette liste

J'ai écrit à ce sujet il y a quelque temps , après avoir contribué au processus d'entrevue à Percona.

Je pense que pour évaluer quelqu'un, il faut essayer de lui faire faire ce qu'il ferait dans les activités quotidiennes normales. Des questions aléatoires comme "Qu'est-ce qu'un type de données série dans MySQL?" ou des questions de renseignement comme "pourquoi les trous de l'homme sont-ils ronds?" n'atteignez pas cela.

Vous voulez également vous assurer de donner à tout le monde le même test. Si vous avez un entretien de conversation ouverte uniquement, les personnes les plus confiantes et (légèrement manipulatrices) se démarqueront, car elles peuvent contourner subtilement vos questions et les transformer en celles auxquelles elles sont bonnes à répondre. Vous ne réaliserez pas toujours quand cela se produit, mais il contient souvent quelque chose comme "quand j'ai commencé en tant que DBA, nous avions 2 Mo de RAM et utilisions des bandes .. bla bla bla": P

Cela dit, voici ma liste standard de questions:

• Décrivez le processus par lequel la réplication MySQL fonctionne?
• Que signifie la composante D d'ACID en termes pratiques?
• Que change innodb_flush_method = O_DIRECT? (Soyez prudent avec celui-ci: la compréhension commune de cela est souvent fausse .)
• Supposons que j'écrive une requête comme "INSERT INTO my_table (a, b) VALUES (1,2)". Décrivez-moi avec autant de détails que possible ce qui se passe à l'intérieur de MySQL.

Je suggère de consulter également certaines listes déjà établies concernant les entretiens DBA:

• Top 10 des questions d'entrevue SQL Server DBA - par notre propre Brent Ozar

  • questions préférées:
  • "Pouvez-vous me donner des références d'autres DBA et développeurs qui ne sont pas dans votre entreprise?"
  • "Un chef de projet a besoin d'un nouveau serveur SQL. Que lui demandez-vous?"

• Questions d'entretien pour Junior DBA - par notre propre Thomas LaRock

  • question préférée: "Si je vous demandais d'apprendre à faire une requête plus rapidement, où iriez-vous?"

• Questions de filtrage de la base de données - par Grant Fritchey

  • question préférée: "Vous êtes le DBA. Le téléphone sonne. Un des utilisateurs est en ligne. Ils disent" La base de données est lente ". Puis ils raccrochent. Que faites-vous? "

Ce sont tous d'excellents rédacteurs SQL Server. Je sais que certaines des questions peuvent être orientées vers SQL Server, mais la plupart ne le sont pas et peuvent être utilisées dans une interview DBA générale.

Bien que je convienne que les nombreuses questions d'entrevue apparemment aléatoires (par exemple, le trou d'homme couvrent une), ne sont pas vraiment utiles ... (sauf, peut-être pour un designer industriel, et juste pour ce seul cas).

Une fois que vous avez dépassé l'aspect trivial de beaucoup d'entre eux, ils sont destinés à être des choses dont vous ne connaissez pas la réponse, et vous devrez donc décrire comment vous vous y prendriez pour trouver la réponse. Ou pas. Par exemple:

• inventer quelque chose de plausible et / ou essayer de faire des conneries sur votre chemin. (pourrait être utile pour les ventes et le marketing? tout autre domaine, ne pas embaucher.)
• L'estimer sur la base d'autres informations
• expliquer comment vous obtiendriez les informations nécessaires pour résoudre le problème

...etc.

Quand j'ai été en charge du processus d'embauche dans le passé, j'essaie de faire un entretien téléphonique complètement imprévu de 5 à 15 minutes (appelez-les simplement, comme s'ils pouvaient vous donner quelques minutes ... tout le monde ne le pouvait pas, car certains étaient au travail qu'ils envisageaient de quitter) ... juste pour évaluer combien je pense qu'ils font des conneries sur leur curriculum vitae.

Par exemple, lorsque nous embauchions un programmeur PL / SQL senior, je leur demandais quelles étaient les parties d'un bloc PL / SQL. Ces jours-ci, c'est la première chose qui se présente dans Google ... ce n'était pas le cas en 2003. La plupart des personnes que nous avons interviewées ont peut-être déjà utilisé Oracle, elles ont peut-être écrit SQL pour Oracle ... mais si vous ne peut pas me donner un indice que vous savez à quoi ressemble un bloc PL / SQL, vous n'êtes pas prêt pour un travail de programmeur PL / SQL senior.

...

Et, cela étant dit, ma question de base pour toute entrevue en personne est:

Star Wars ou Star Trek?

En partie, vous pouvez voir comment ils gèrent une situation où il n'y a pas de meilleure réponse, s'ils sont diplomatiques dans leur réponse ou s'ils pensent en dehors de la boîte (par exemple, Dr. Who ou Firefly sont des réponses valides). Là où je travaille actuellement (un laboratoire de physique spatiale), dire que vous n'avez jamais vu l'un ou l'autre pourrait être un échec à moins que vous ne soyez un étranger. Dire que vous n'aimez pas non plus, et expliquer pourquoi avec une bonne raison serait un laissez-passer, cependant. Regarder trop l'un ou l'autre peut être un échec (car personne ne veut travailler avec cette personne)