One place for hosting & domains

      gérer

      Comment utiliser ps, kill et nice pour gérer des processus sous Linux


      Introduction


      Un serveur Linux, tout comme tous les autres ordinateurs que vous connaissez, exécute des applications. L’ordinateur considère cela comme des « processus ».

      Bien que Linux se chargera de la gestion de bas niveau et en coulisses du cycle de vie d’un processus, vous avez besoin de pouvoir interagir avec le système d’exploitation et à le gérer ainsi à un niveau supérieur.

      Dans ce guide, nous allons voir certains des aspects simples de la gestion de processus. Linux vous propose un vaste ensemble d’outils.

      Nous allons voir ces idées sur un Ubuntu 12.04 VPS. Cependant, toute distribution Linux moderne fonctionnera de manière similaire.


      top


      Afin de déterminer quels sont les processus en cours d’exécution sur votre serveur, la façon la plus simple consiste à exécuter la commande top :

      top***
      
      top - 15:14:40 up 46 min, 1 user, load average: 0.00, 0.01, 0.05 Tasks:  56 total,   1 running, 55 sleeping, 0 stopped, 0 zombie Cpu(s): 0.0%us, 0.0%sy,  0.0%ni,100.0%id, 0.0%wa,  0.0%hi,  0.0%si, 0.0%st Mem:   1019600k total,   316576k used,   703024k free, 7652k buffers Swap:        0k total,        0k used,        0k free,   258976k cached   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND            1 root      20 0 24188 2120 1300 0.0 0.2   0:00.56 init     2 root 20   0 0 0 0 S 0 0.0 0:00.00 kthreadd     3 root      20 0 0    0 0 S 0.0 0.0 0:00.07 ksoftirqd/0     6 root RT 0 0    0 S  0.0  0.0   0:00.00 migration/0            7 root      RT   0     0 0    0 S  0.0  0.0   0:00.03 watchdog/0             8 root       0 -20     0    0    0 S  0.0  0.0   0:00.00 cpuset                 9 root       0 -20     0    0    0 S  0.0  0.0   0:00.00 khelper               10 root      20   0     0    0    0 S  0.0  0.0   0:00.00 kdevtmpfs
      

      Le premier morceau d’information vous donne les statistiques sur les systèmes, comme la charge du système et le nombre total de tâches.

      Vous pouvez facilement voir qu’il y a 1 processus en cours d’exécution et que 55 processus sont dormants (aka idle/n’utilisant pas les ressources du processeur).

      La partie inférieure comporte les processus en cours d’exécution et leurs statistiques d’utilisation.

      htop


      Vous disposez d’une version améliorée de top, appelée htop, dans les référentiels. Installez-la avec cette commande :

      sudo apt-get install htop
      

      Si nous exécutons la commande htop, l’affichage qui apparaîtra sera plus convivial :

      htop***
      
        Mem[|||||||||||           49/995MB]     Load average: 0.00 0.03 0.05   CPU[                          0.0%]     Tasks: 21, 3 thr; 1 running   Swp[                         0/0 Mo]     Uptime: 00:58:11   PID USER      PRI  NI  VIRT   RES   SHR S CPU% MEM%   TIME+  Command  1259 root       20   0 25660  1880  1368 R  0.0  0.2  0:00.06 htop     1 root       20   0 24188  2120  1300 S  0.0  0.2  0:00.56 /sbin/init   311 root       20   0 17224   636   440 S  0.0  0.1  0:00.07 upstart-udev-brid   314 root       20   0 21592  1280   760 S  0.0  0.1  0:00.06 /sbin/udevd --dae   389 messagebu  20   0 23808   688   444 S  0.0  0.1  0:00.01 dbus-daemon --sys   407 syslog     20   0  243M  1404  1080 S  0.0  0.1  0:00.02 rsyslogd -c5   408 syslog     20   0  243M  1404  1080 S  0.0  0.1  0:00.00 rsyslogd -c5   409 syslog     20   0  243M  1404  1080 S  0.0  0.1  0:00.00 rsyslogd -c5   406 syslog     20   0  243M  1404  1080 S  0.0  0.1  0:00.04 rsyslogd -c5   553 root       20   0 15180   400   204 S  0.0  0.0  0:00.01 upstart-socket-br
      

      Vous pouvez en savoir plus sur la manière d’utiliser top et htop ici.


      top et htop vous offrent tous les deux une belle interface pour visualiser les processus en cours d’exécution, similaire à un gestionnaire de tâches graphique.

      Cependant, ces outils ne sont pas toujours suffisamment flexibles pour couvrir tous les scénarios correctement. Une commande puissante appelée ps est souvent utilisée pour répondre à ces problèmes.

      Lorsque vous appelez une commande sans arguments, la sortie peut manquer d’éclat :

      ps***
      
        PID TTY          TIME CMD  1017 pts/0    00:00:00 bash  1262 pts/0    00:00:00 ps
      

      Cette sortie affiche tous les processus associés à l’utilisateur et la session du terminal actuels. Cela est logique, car nous exécutons actuellement bash et ps avec ce terminal.

      Pour obtenir une image plus complète des processus sur ce système, nous pouvons exécuter ce qui suit :

      ps aux***
      
      USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND root         1  0.0  0.2  24188  2120 ?        Ss   14:28   0:00 /sbin/init root         2  0.0  0.0      0     0 ?        S    14:28   0:00 [kthreadd] root         3  0.0  0.0      0     0 ?        S    14:28   0:00 [ksoftirqd/0] root         6  0.0  0.0      0     0 ?        S    14:28   0:00 [migration/0] root         7  0.0  0.0      0     0 ?        S    14:28   0:00 [watchdog/0] root         8  0.0  0.0      0     0 ?        S<   14:28   0:00 [cpuset] root         9  0.0  0.0      0     0 ?        S<   14:28   0:00 [khelper] . . .
      

      Ces options indiquent à ps d’afficher les processus détenus par tous les utilisateurs (quel que soit le terminal auquel ils sont associés) sous un format convivial pour les utilisateurs.

      Pour avoir une vue en arborescencee, dans laquelle les relations hiérarchiques sont illustrées, nous pouvons exécuter la commande avec les options suivantes :

      ps axjf***
      
       PPID   PID  PGID   SID TTY      TPGID STAT   UID   TIME COMMAND     0     2     0     0 ?           -1 S        0   0:00 [kthreadd]     2     3     0     0 ?           -1 S        0   0:00  _ [ksoftirqd/0]     2     6     0     0 ?           -1 S        0   0:00  _ [migration/0]     2     7     0     0 ?           -1 S        0   0:00  _ [watchdog/0]     2     8     0     0 ?           -1 S<       0   0:00  _ [cpuset]     2     9     0     0 ?           -1 S<       0   0:00  _ [khelper]     2    10     0     0 ?           -1 S        0   0:00  _ [kdevtmpfs]     2    11     0     0 ?           -1 S<       0   0:00  _ [netns] . . .
      

      Comme vous pouvez le voir, le processus kthreadd est montré comme un parent du processus ksoftirqd/0 et les autres.

      Une remarque sur les identifiants de processus


      Dans les systèmes de type Linux et Unix, chaque processus se voit attribuer un process ID ou** PID**. Voici de quelle manière le système d’exploitation identifie et assure le suivi des processus.

      Vous pouvez rapidement obtenir le PID d’un processus en utilisant la commande pgrep :

      pgrep bash***
      
      1017
      

      Cette commande interrogera simplement l’ID du processus et la renverra.

      Le premier processus généré au démarrage, appelé init, se voit attribuer le PID de « 1 ».

      pgrep init***
      
      1
      

      Ce processus est ensuite chargé de générer tout autre processus sur le système. Les processus suivants se voient attribuer des numéros PID plus grands.

      Le parent d’un processus est le processus qui était chargé de le générer. Les processus parent disposent d’un PPID, que vous pouvez voir dans l’en-tête des colonnes dans de nombreuses applications de gestion de processus, dont top, htop et ps.

      Toute communication sur les processus entre l’utilisateur et le système d’exploitation implique, à un moment donné de l’opération, la traduction entre les noms de processus et le PID. C’est pour cette raison que les utilitaires vous indiquent le PID.

      Relations parent-enfant


      La création d’un processus enfant se fait en deux étapes : fork(), qui crée un nouvel espace d’adresse et copie les ressources que le parent possède via une copie-sur-écriture pour les rendre disponibles sur le processus enfant ; et exec(), qui charge un exécutable dans l’espace de l’adresse et l’exécute.

      Dans le cas où un processus enfant meurt avant son parent, l’enfant devient un zombie jusqu’à que le parent collecte les informations le concernant ou indique au noyau qu’il n’a pas besoin de ces informations Les ressources du processus enfant seront ensuite libérées. Cependant, si le processus parent meurt avant l’enfant, l’enfant sera adopté par l’init, bien qu’il puisse également être réattribué à un autre processus.


      Tous les processus de Linux répondent à des signals. Les signaux permettent d’indiquer aux programmes, au niveau du système d’exploitation, de s’arrêter ou de modifier leur comportement.


      La façon la plus courante de transmettre des signaux à un programme consiste à utiliser la commande kill.

      Comme vous pouvez vous y attendre, la fonctionnalité par défaut de cet utilitaire consiste à tenter de tuer un processus :

      <pre>kill <span class=“highlight”>PIDoftarget_process</span></pre>

      Cela envoie le signal TERM au processus. Le signal TERM indique au processus de bien vouloir se terminer. Cela permet au programme d’effectuer des opérations de nettoyage et de s’arrêter en douceur.

      Si le programme se comporte mal et ne se ferme pas lorsque le signal TERM est actionné, nous pouvons escalader le signal en passant le signal KILL :

      <pre>kill -KILL <span class=“highlight”>PIDoftarget_process</span></pre>

      Il s’agit d’un signal spécial que n’est pas envoyé au programme.

      Au lieu de cela, il est envoyé au noyau du système d’exploitation qui interrompt le processus. Vous pouvez l’utiliser pour contourner les programmes qui ignorent les signaux qui leur sont envoyés.

      Chaque signal est associé à un numéro que vous pouvez passer à la place du nom. Par exemple, vous pouvez passer « -15 » au lieu de « -TERM » et « -9 » au lieu de « -KILL ».


      Les signaux ne servent pas uniquement à fermer des programmes. Vous pouvez également les utiliser pour effectuer d’autres actions.

      Par exemple, de nombreux démons redémarrent lorsqu’un signal HUP ou de suspension leur est envoyé Apache est un programme qui fonctionne ainsi.

      <pre>sudo kill -HUP <span class=“highlight”>pidofapache</span></pre>

      La commande ci-dessus poussera Apache à recharger son fichier de configuration et à reprendre le contenu d’utilisation.

      Vous pouvez répertorier tous les signaux que vous pouvez envoyer avec kill en saisissant :

      kill -l***
      
      1) SIGHUP    2) SIGINT   3) SIGQUIT  4) SIGILL   5) SIGTRAP  6) SIGABRT  7) SIGBUS   8) SIGFPE   9) SIGKILL 10) SIGUSR1 11) SIGSEGV 12) SIGUSR2 13) SIGPIPE 14) SIGALRM 15) SIGTERM . . .
      

      Bien que la façon classique d’envoyer des signaux consiste à utiliser des PIDS, il existe également des méthodes de le faire avec des noms de processus réguliers.

      La commande pkill fonctionne de manière pratiquement de la même manière que kill, mais elle fonctionne plutôt avec le nom d’un processus :

      pkill -9 ping
      

      La commande ci-dessus est l’équivalent de :

      kill -9 `pgrep ping`
      

      Vous pouvez utiliser la commande killall pour envoyer un signal à chaque instance d’un processus donné :

      killall firefox
      

      La commande ci-dessus enverra le signal TERM à chaque instance de firefox en cours d’exécution sur l’ordinateur.


      Il vous arrivera souvent de vouloir ajuster la priorité donnée aux processus dans un environnement de serveur.

      Certains processus peuvent être considérés comme critiques à la mission pour votre situation, tandis que d’autres peuvent être exécutés chaque fois qu’il y aura des ressources restantes.

      Linux contrôle la priorité par le biais d’une valeur appelée niceness.

      Les tâches hautement prioritaires sont considérées comme moins nice, car elles ne partagent pas également les ressources. Les processus faiblement prioritaires sont en revanche nice car ils insistent à prendre seulement des ressources minimales.

      Lorsque nous avons exécuté top au début de l’article, il y avait une colonne nommée « NI ». Il s’agit de la valeur nice du processus :

      top***
      
       Tasks:  56 total,   1 running,  55 sleeping,   0 stopped,   0 zombie Cpu(s):  0.0%us,  0.3%sy,  0.0%ni, 99.7%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st Mem:   1019600k total,   324496k used,   695104k free,     8512k buffers Swap:        0k total,        0k used,        0k free,   264812k cached   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND            1635 root      20   0 17300 1200  920 R  0.3  0.1   0:00.01 top                    1 root      20   0 24188 2120 1300 S  0.0  0.2   0:00.56 init                   2 root      20   0     0    0    0 S  0.0  0.0   0:00.00 kthreadd               3 root      20   0     0    0    0 S  0.0  0.0   0:00.11 ksoftirqd/0
      

      Les valeurs nice peuvent aller de « -19/-20  » (priorité la plus grande) à «19/20» (priorité la plus faible) en fonction du système.

      Pour exécuter un programme avec une certaine nice valeur, nous pouvons utiliser la commande nice :

      <pre>nice -n 15 <span class=“highlight”>commandtoexecute</span></pre>

      Elle fonctionne uniquement au démarrage d’un nouveau programme.

      Pour modifier la valeur nice d’un programme déjà en cours d’exécution, nous utilisons un outil appelé renice :

      <pre>renice 0 <span class=“highlight”>PIDtoprioritize</span></pre>

      Remarque : bien que nice fonctionne avec un nom de commande par nécessité, renice fonctionne en appelant le PID de processus

      Conclusion


      La gestion de processus est un sujet parfois difficile à comprendre pour les nouveaux utilisateurs car les outils utilisés sont différents de leurs homologues graphiques.

      Cependant, les idées sont familières et intuitives et deviennent naturelles avec un peu de pratique. Étant donné que les processus sont impliqués dans toutes les tâches que vous effectuez avec un système informatique, il est essentiel que vous appreniez à les contrôler efficacement.

      <div class=“author”>Par Justin Ellingwood</div>



      Source link

      Comment utiliser Systemctl pour gérer les services et les unités de Systemd


      Introduction

      systemd est un gestionnaire de systèmes d’initialisation et de systèmes qui est devenu la nouvelle norme pour les distributions de Linux. Étant largement adopté, cela vaut la peine de se familiariser avec systemd car l’administration de serveurs vous sera considérablement plus facile. En apprendre davantage sur les outils et les démons qui composent systemd vous permettra de mieux apprécier la puissance, la flexibilité et les capacités qu’il vous offre ou, tout du moins, de travailler avec un minimum de tracas.

      Au cours de ce guide, nous allons discuter de la commande systemctl, qui est l’outil de gestion essentiel pour contrôler le système d’initialisation. Nous allons voir de quelle la manière vous pouvez gérer les services, vérifier les états, modifier les états du système et travailler avec les fichiers de configuration.

      Notez que, bien que systemd soit devenu le système d’initialisation par défaut de nombreuses distributions Linux, il n’est pas universellement implémenté sur toutes les distributions. Si au cours de ce tutoriel votre terminal déclenche l’erreur bash: systemctl is not installed, il est alors probable que votre machine ait installé un système d’initialisation.

      Gestion de service

      L’objectif fondamental d’un système d’initialisation est d’initialiser les composants qui doivent être démarrés une fois que le noyau Linux est lancé (traditionnellement connus sous le nom de composants « userland »). De plus, le système d’initialisation vous permet de gérer à tout moment les services et les démons du serveur alors que le système est en marche. Dans cette optique, nous allons commencer par certaines des opérations de base de gestion de service.

      Dans systemd, la cible de la plupart des actions sont des « unités », c’est-à-dire des ressources que systemd sait gérer. Les unités sont classées par le type de ressources qu’elles représentent. Leur configuration se fait avec des fichiers que l’on appelle des « fichiers de l’unité ». Vous pouvez déduire le type de chaque unité à l’aide du suffixe qui se trouve à la fin du fichier.

      Pour les tâches de gestion de service, l’unité cible correspondra aux unités de service pour lesquelles les fichiers de l’unité se terminent par le suffixe .service. Cependant, en réalité, pour la plupart des commandes de gestion de service, vous n’avez pas nécessairement besoin du suffixe .service. En effet, systemd est assez intelligent pour savoir que, lorsque vous utilisez les commandes de gestion de service, vous souhaitez probablement travailler sur un service.

      Démarrage et arrêt des services

      Si vous souhaitez démarrer un service systemd en exécutant les instructions qui se trouvent dans le fichier de l’unité du service, utilisez la commande start. Si vous opérez comme un non-root user, vous devrez utiliser sudo car cela affectera l’état du système d’exploitation :

      • sudo systemctl start application.service

      Comme nous l’avons précédemment mentionné, étant donné que systemd sait qu’il doit rechercher les fichiers *.service pour les commandes de gestion de service, il vous suffirait de saisir la commande de la manière suivante :

      • sudo systemctl start application

      Même si, à des fins d’administration générale, vous pouvez utiliser le format ci-dessus, nous allons utiliser le suffixe .service pour le reste des commandes par soucis de clarté afin de définir clairement la cible sur laquelle nous travaillons.

      Pour arrêter un service en cours d’exécution, vous pouvez plutôt utiliser la commande stop :

      • sudo systemctl stop application.service

      Redémarrage et rechargement

      Pour redémarrer un service en cours d’exécution, vous pouvez utiliser la commande restart :

      • sudo systemctl restart application.service

      Si l’application en question est en capacité de recharger ses fichiers de configuration (sans redémarrage), vous pouvez lancer la commande reload pour initier ce processus :

      • sudo systemctl reload application.service

      Si vous ne savez pas si le service intègre la fonctionnalité qui lui permet de recharger sa configuration, vous pouvez lancer la commande reload-or-restart Si disponible, vous rechargerez la configuration en place. Sinon, le service redémarrera pour récupérer la nouvelle configuration :

      • sudo systemctl reload-or-restart application.service

      Activation et désactivation des services

      Les commandes ci-dessus vous seront utiles pour démarrer ou arrêter des services pendant la session en cours. Vous devez les activer pour demander à systemd de lancer automatiquement les services au démarrage.

      Pour lancer un service au démarrage, utilisez la commande enable :

      • sudo systemctl enable application.service

      Cela créera un lien symbolique à partir de la copie du fichier de service du système (généralement dans /lib/systemd/system ou /etc/systemd/system) à l’emplacement du disque où systemd cherche les fichiers de démarrage automatique (généralement /etc/systemd/system/some_target.target.wants. Nous verrons ce qu’est une cible plus tard dans ce guide).

      Pour désactiver le démarrage automatique d’un service, vous pouvez saisir :

      • sudo systemctl disable application.service

      Cela supprimera le lien symbolique indiquant que le service doit être démarré automatiquement.

      N’oubliez pas que l’activation du service ne le déclenche pas pendant la session en cours. Si vous souhaitez démarrer le service et, dans le même temps, l’activer au démarrage, vous devez lancer à la fois la commande start et la commande enable.

      Vérification de l’état des services

      Pour vérifier l’état d’un service sur votre système, vous pouvez utiliser la commande status :

      • systemctl status application.service

      Vous pourrez ainsi consulter l’état des services, la hiérarchie des groupes et les premières lignes du journal.

      Par exemple, lorsque vous souhaitez vérifier l’état d’un serveur Nginx, le résultat peut s’afficher comme suit :

      Output

      ● nginx.service - A high performance web server and a reverse proxy server Loaded: loaded (/usr/lib/systemd/system/nginx.service; enabled; vendor preset: disabled) Active: active (running) since Tue 2015-01-27 19:41:23 EST; 22h ago Main PID: 495 (nginx) CGroup: /system.slice/nginx.service ├─495 nginx: master process /usr/bin/nginx -g pid /run/nginx.pid; error_log stderr; └─496 nginx: worker process Jan 27 19:41:23 desktop systemd[1]: Starting A high performance web server and a reverse proxy server... Jan 27 19:41:23 desktop systemd[1]: Started A high performance web server and a reverse proxy server.

      Cela vous donne un bon aperçu de l’état actuel de l’application, vous signalant tout problème et toute action à mettre en œuvre.

      Certaines méthodes vous permettent également de contrôler des états spécifiques. Par exemple, si vous souhaitez vérifier si une unité est actuellement active (en cours d’exécution), vous pouvez utiliser la commande is-active :

      • systemctl is-active application.service

      Cela renverra l’état actuel de l’unité, qui est généralement active ou inactive. Si elle est active, le code de sortie affichera « 0 », ce qui simplifie l’analyse dans les scripts shell.

      Pour voir si l’unité est activée, vous pouvez utiliser la commande is-enabled :

      • systemctl is-enabled application.service

      Vous pourrez ainsi voir si le service est enabled ou disabled et le code de sortie sera à nouveau configuré sur « 0 » ou « 1 » en fonction de la réponse à la question de la commande.

      Une troisième vérification consiste à voir si l’état de l’unité indique un échec. Cela indique qu’un problème est survenu au démarrage de l’unité en question :

      • systemctl is-failed application.service

      Cela reverra active si l’exécution se fait correctement ou failed si une erreur survient. Si l’unité est intentionnellement arrêtée, elle peut renvoyer unknown ou inactive. Le statut de sortie « 0 » indique qu’une défaillance est survenue. Le statut de sortie « 1 » indique tout autre statut.

      Présentation générale des états du système

      Jusqu’à présent, les commandes nous ont permis de gérer des services uniques, mais pas vraiment de consulter l’état actuel du système. Il existe un certain nombre de commandes systemctl qui vous donnent ces informations.

      Liste des unités en cours d’utilisation

      Pour avoir une liste de toutes les unités actives que systemd reconnaît, nous pouvons utiliser la commande list-units :

      Cela affichera une liste de toutes les unités considérées comme actives par systemd sur le système. La sortie finale ressemblera à peu près à ceci :

      Output

      UNIT LOAD ACTIVE SUB DESCRIPTION atd.service loaded active running ATD daemon avahi-daemon.service loaded active running Avahi mDNS/DNS-SD Stack dbus.service loaded active running D-Bus System Message Bus dcron.service loaded active running Periodic Command Scheduler dkms.service loaded active exited Dynamic Kernel Modules System getty@tty1.service loaded active running Getty on tty1 . . .

      La sortie affiche les colonnes suivantes :

      • UNIT : le nom de l'unité systemd
      • LOAD : si la configuration de l'unité a été analysée par systemd. La configuration des unités chargées est gardée en mémoire.
      • ACTIVE : un état résumé indiquant si l'unité est active. Il s'agit généralement d'une méthode assez simple d'établir si l'unité a bien démarré ou pas.
      • SUB : il s'agit d'un état de niveau inférieur qui donne des informations plus détaillées sur l'unité. Il varie souvent en fonction du type, de l'état et du mode de fonctionnement réel de l'unité.
      • DESCRIPTION : une courte description textuelle de ce que l'unité est/fait.

      Étant donné que la commande list-units affiche uniquement les unités actives par défaut, toutes les entrées ci-dessus afficheront loaded dans la colonne LOAD et active dans la colonne ACTIVE. Cet affichage correspond en réalité au comportement par défaut de systemctl lorsque vous l'appelez sans commandes supplémentaires. Vous verrez donc la même chose se produire si vous appelez systemctl sans arguments :

      Nous pouvons instruire systemctl de générer des informations différentes en ajoutant des balises supplémentaires. Par exemple, pour consulter toutes les unités que systemd a chargées (ou tente de charger), qu'elles soient actuellement actives ou pas, vous pouvez utiliser la balise --all comme suit :

      • systemctl list-units --all

      Cela affichera toute unité que systemd a chargée ou tenté de charger, quel que soit l'état actuel du système. Certaines unités deviennent inactives après leur exécution et il se peut que certaines autres, celles que systemd a tenté de charger, restent introuvables sur le disque.

      Vous pouvez filtrer ces résultats en utilisant d'autres balises. Par exemple, nous pouvons utiliser la balise --state= pour indiquer les états LOAD, ACTIVE ou SUB que nous souhaitons consulter. Nous allons devoir garder la balise --all pour que systemctl permette l'affichage des unités inactives :

      • systemctl list-units --all --state=inactive

      Un autre filtre est couramment utilisé, le filtre --type=. Nous pouvons indiquer à systemctl d'afficher uniquement le type d'unités qui nous intéresse. Par exemple, pour consulter uniquement les unités de service actives, nous pouvons utiliser :

      • systemctl list-units --type=service

      Liste de tous les fichiers de l'unité

      La commande list-units affiche uniquement les unités que systemd a tentées d'analyser et de charger en mémoire. Étant donné que systemd lira uniquement les unités dont il pense avoir besoin, les unités disponibles sur le système ne seront pas nécessairement toutes répertoriées. Pour voir tous les fichiers de l'unité disponibles au sein des chemins de systemd, notamment ceux que systemd n'a pas tenté de charger, vous pouvez utiliser la commande list-unit-files à la place :

      • systemctl list-unit-files

      Les unités sont des représentations des ressources dont systemd a connaissance. Étant donné que systemd n'a pas nécessairement lu toutes les définitions de l'unité dans cet écran, seules les informations concernant les fichiers en eux-mêmes sont présentées. La sortie a deux colonnes : le fichier de l'unité et l'état.

      Output

      UNIT FILE STATE proc-sys-fs-binfmt_misc.automount static dev-hugepages.mount static dev-mqueue.mount static proc-fs-nfsd.mount static proc-sys-fs-binfmt_misc.mount static sys-fs-fuse-connections.mount static sys-kernel-config.mount static sys-kernel-debug.mount static tmp.mount static var-lib-nfs-rpc_pipefs.mount static org.cups.cupsd.path enabled . . .

      L'état indiquera généralement enabled, disabled, static ou masked. Dans ce contexte, static signifie que le fichier de l'unité ne contient pas de section install, qui sert à activer une unité. De ce fait, ces unités ne peuvent pas être activées. Habituellement, cela signifie que soit l'unité effectue une action unique, soit elle est uniquement utilisée qu'en tant que dépendance d'une autre unité et ne doit pas être exécutée seule.

      Nous allons voir dans un moment ce que masked signifie.

      Gestion de l'unité

      Jusque-là, nous avons travaillé avec les services et affiché des informations sur l'unité et sur les fichiers de l'unité dont systemd a connaissance. Cependant, en utilisant d'autres commandes, nous pouvons trouver des informations plus spécifiques sur les unités.

      Affichage du fichier de l'unité

      Pour afficher le fichier de l'unité que systemd a chargé sur son système, vous pouvez utiliser la commande cat qui a été ajoutée dans la version 209 de systemd). Par exemple, pour voir le fichier de l'unité de démon de planification atd, nous pourrions saisir :

      • systemctl cat atd.service

      Output

      [Unit] Description=ATD daemon [Service] Type=forking ExecStart=/usr/bin/atd [Install] WantedBy=multi-user.target

      On obtient ainsi le fichier de l'unité tel que reconnu par le processus systemd en cours d'exécution. Cela peut s'avérer important si vous avez récemment modifié des fichiers de l'unité ou si vous écrasez certaines options dans un fragment du fichier de l'unité (nous allons couvrir cela plus tard).

      Affichage des dépendances

      Pour voir une arborescence des dépendances de l'unité, vous pouvez utiliser la commande list-dependencies :

      • systemctl list-dependencies sshd.service

      Cela affichera une cartographie hiérarchisée des dépendances qui doivent être traitées afin de démarrer l'unité concernée. Dans ce contexte, les dépendances incluent les unités qui sont soit requises ou souhaitées par les unités au-dessus.

      Output

      sshd.service ├─system.slice └─basic.target ├─microcode.service ├─rhel-autorelabel-mark.service ├─rhel-autorelabel.service ├─rhel-configure.service ├─rhel-dmesg.service ├─rhel-loadmodules.service ├─paths.target ├─slices.target . . .

      Les dépendances récursives s'affichent uniquement pour .target, qui indique les états du système. Pour lister de manière récursive toutes les dépendances, ajoutez la balise --all.

      Pour afficher les dépendances inverses (les unités qui dépendent de l'unité spécifiée), vous pouvez ajouter la balise --reverse à la commande. D'autres balises vous seront utiles : --before et --after. Vous pouvez les utiliser pour afficher les unités qui dépendent de l'unité spécifiée qui a démarré avant et après elles, respectivement.

      Vérification des propriétés de l'unité

      Pour consulter les propriétés de niveau inférieur d'une unité, vous pouvez utiliser la commande show. Elle affichera une liste de propriétés configurées pour l'unité spécifiée en utilisant un format key=value :

      • systemctl show sshd.service

      Output

      Id=sshd.service Names=sshd.service Requires=basic.target Wants=system.slice WantedBy=multi-user.target Conflicts=shutdown.target Before=shutdown.target multi-user.target After=syslog.target network.target auditd.service systemd-journald.socket basic.target system.slice Description=OpenSSH server daemon . . .

      Pour afficher une seule propriété, vous pouvez faire utiliser la balise -p accompagnée du nom de la propriété. Par exemple, pour voir les conflits que l'unité sshd.service a, vous pouvez saisir :

      • systemctl show sshd.service -p Conflicts

      Output

      Conflicts=shutdown.target

      Masquage et affichage des unités

      Dans la section Gestion de service, nous avons vu de quelle manière arrêter ou désactiver un service, mais systemd a également la possibilité de marquer une unité comme étant totalement impossible à démarrer, automatiquement ou manuellement, en la reliant à /dev/null. On dit alors que l'on « masque » l'unité, et il est possible de le faire avec la commande mask :

      • sudo systemctl mask nginx.service

      Tant qu'elle est masquée, tout démarrage automatique ou manuel du service Nginx est impossible.

      Si vous vérifiez la list-unit-files, vous verrez que le service est maintenant répertorié comme étant masqué :

      • systemctl list-unit-files

      Output

      . . . kmod-static-nodes.service static ldconfig.service static mandb.service static messagebus.service static nginx.service masked quotaon.service static rc-local.service static rdisc.service disabled rescue.service static . . .

      Si vous tentez de lancer le service, vous verrez s'afficher le message suivant :

      • sudo systemctl start nginx.service

      Output

      Failed to start nginx.service: Unit nginx.service is masked.

      Pour afficher une unité et rendre son utilisation à nouveau possible, utilisez la commande unmask :

      • sudo systemctl unmask nginx.service

      Cela renverra l'unité à l'état précédent, ce qui lui permettra son démarrage ou son activation.

      Modification des fichiers de l'unité

      Bien que ce tutoriel ne traite pas du format spécifique des fichiers de l'unité, systemctl met à votre disposition des mécanismes intégrés d'édition et de modification des fichiers de l'unité pour vous permettre de faire des réglages. Cette fonctionnalité a été ajoutée dans la version 218 de systemd.

      Par défaut, la commande edit ouvrira le fragment de code du fichier de l'unité concerné :

      • sudo systemctl edit nginx.service

      Il s'agira d'un fichier vierge qui pourra être utilisé pour remplacer ou ajouter des directives à la définition de l'unité. Un répertoire sera créé dans le répertoire /etc/systemd/systemd qui contient le nom de l'unité avec un .d annexé. Par exemple, pour le nginx.service, un répertoire appelé nginx.service.d sera créé.

      Au sein de ce répertoire, un fragment de code appelé override.conf sera créé. Une fois l'unité chargée, systemd fusionnera, en mémoire, le fragment de code de remplacement avec le fichier de l'unité dans son intégralité. Les directives du fragment de code auront la priorité sur celles qui se trouvent dans le fichier de l'unité d'origine.

      Si vous souhaitez modifier l'intégralité du fichier de l'unité au lieu de créer un fragment de code, vous pouvez passer la balise --full.

      • sudo systemctl edit --full nginx.service

      Cela chargera le fichier de l'unité actuelle dans l'éditeur dans lequel vous pouvez le modifier. Lorsque l'éditeur se ferme, le fichier modifié sera écrit dans /etc/systemd/system, ce qui aura la priorité sur la définition de l'unité du système (qui se trouve généralement dans /lib/systemd/system).

      Pour supprimer tous les ajouts que vous avez effectués, vous pouvez supprimer soit le répertoire de configuration de l'unité .d ou le fichier de service modifié de /etc/systemd/system. Par exemple, pour supprimer un fragment de code, nous pourrions saisir :

      • sudo rm -r /etc/systemd/system/nginx.service.d

      Pour supprimer un fichier complet de l'unité modifié, il faudrait entrer :

      • sudo rm /etc/systemd/system/nginx.service

      Après avoir supprimé le fichier ou le répertoire, vous devez recharger le processus systemd pour qu'il ne tente plus de référencer ces fichiers et réutilise les copies du système. Vous pouvez le faire en tapant :

      • sudo systemctl daemon-reload

      Réglage de l'état du système (niveau d'exécution) avec des cibles

      Les cibles sont des fichiers spéciaux de l'unité qui décrivent un état ou un point de synchronisation du système. Comme avec les autres unités, les fichiers qui définissent des cibles peuvent être identifiés par leur suffixe, dans ce cas .target. Seules, les cibles ne font pas grand-chose, mais elles permettent de regrouper d'autres unités ensemble.

      Vous pouvez les utiliser pour mettre le système dans certains états, tout comme les autres systèmes d'initialisation utilisent les niveaux d'exécution. Elles servent de référence lorsque certaines fonctions sont disponibles. Elles vous permettent ainsi de spécifier l'état souhaité au lieu d'avoir à spécifier les unités individuellement pour produire cet état.

      Par exemple, il existe un swap.target qui est utilisé pour indiquer que le swap est prêt à être utilisé. Les unités qui font partie de ce processus peuvent se synchroniser avec cette cible en indiquant dans leur configuration qu'elles sont WantedBy= ou RequiredBy= le swap.target. Les unités qui nécessitent la disponibilité d'un swap peuvent spécifier cette condition en utilisant les spécifications Wants=, Requires=, et After= pour indiquer la nature de leur relation.

      Obtention et configuration de la cible par défaut

      Le processus systemd a une cible par défaut qu'il utilise au lancement du système. En satisfaisant la cascade des dépendances de cette cible unique, le système est amené à l'état souhaité. Pour trouver la cible par défaut de votre système, saisissez :

      Output

      multi-user.target

      Au besoin, pour configurer une autre cible par défaut, vous pouvez utiliser le set-default. Par exemple, si vous avez installé un bureau graphique et que vous souhaitez que le système s'y lance par défaut, vous pouvez modifier votre cible par défaut en conséquence :

      • sudo systemctl set-default graphical.target

      Liste des cibles disponibles

      Vous pouvez obtenir une liste des cibles disponibles sur votre système en saisissant :

      • systemctl list-unit-files --type=target

      Contrairement aux niveaux d'exécution, plusieurs cibles peuvent être actives à la fois. Une cible active indique que systemd a tenté de lancer toutes les unités liées à la cible et n'a pas encore réessayé de les détruire. Pour voir toutes les cibles actives, entrez :

      • systemctl list-units --type=target

      Isolation des cibles

      Il est possible de lancer toutes les unités associées à une cible et d'arrêter toutes celles qui ne font pas partie de l'arborescence de dépendance. La commande dont nous avons besoin pour cela s'appelle, comme il se doit, isolate. Le processus est similaire à celui qui permet de changer le niveau d'exécution sur les autres systèmes d'initialisation.

      Par exemple, si vous opérez dans un environnement graphique dans lequel graphical.target est active, vous pouvez arrêter le système graphique et mettre le système dans un état de ligne de commande multi-utilisateur en isolant le multi-user.target. Étant donné que graphical.target dépend de multi-user.target, mais pas l'inverse, toutes les unités graphiques seront arrêtées.

      Il est conseillé de consulter les dépendances de la cible que vous isolez avant d'effectuer cette procédure afin de s'assurer de ne pas arrêter les services essentiels :

      • systemctl list-dependencies multi-user.target

      Une fois satisfait des unités qui seront restées actives, vous pouvez isoler la cible en saisissant le texte suivant :

      • sudo systemctl isolate multi-user.target

      Utilisation de raccourcis pour les événements importants

      Il existe des cibles définies pour les événements importants comme la mise à l'arrêt ou le redémarrage. Cependant, systemctl intègre également quelques raccourcis qui ajoutent quelques fonctionnalités supplémentaires.

      Par exemple, pour mettre le système en mode sauvetage (utilisateur unique), vous pouvez utiliser la commande rescue au lieu de isolate rescue.target :

      Cela permettra d'avoir une fonctionnalité supplémentaire qui avertira tous les utilisateurs connectés de l'événement.

      Pour arrêter le système, vous pouvez utiliser la commande halt :

      Pour lancer un arrêt complet, vous pouvez utiliser la commande poweroff :

      Vous pouvez déclencher un redémarrage avec la commande reboot :

      Ces fonctionnalités avertiront les utilisateurs que l'événement est en cours, ce qui ne se fera pas en exécutant ou isolant uniquement la cible. Notez que la plupart des machines relieront les commandes les plus courtes et les plus classiques de ces opérations afin qu'elles fonctionnent correctement avec systemd.

      Par exemple, pour redémarrer le système, vous pouvez généralement taper :

      Conclusion

      Maintenant, vous devriez vous être familiarisé avec certaines des capacités de base de la commande systemctl qui vous permettent d'interagir avec votre instance systemd et de la contrôler. L'utilitaire systemctl sera votre principal point d'interaction pour gérer l'état des services et l'état du système.

      Bien que systemctl fonctionne principalement avec le processus de base systemd, il existe d'autres composants de l'écosystème systemd qui sont contrôlés par d'autres utilitaires . D'autres capacités, comme la gestion des journaux et les sessions utilisateur, sont traitées par des démons et des utilitaires de gestion distincts (journald/journalctl et (logind/loginctl respectivement). Prenez le temps de vous familiariser avec les autres outils et démons pour que la gestion soit plus facile.



      Source link

      Comment gérer et utiliser les triggers de base de données MySQL sur Ubuntu 18.04


      L’auteur a choisi the Apache Software Foundation pour recevoir un don dans le cadre du programme Write for DOnations.

      Introduction

      Dans MySQL, un trigger (ou déclencheur) est une commande SQL définie par l’utilisateur qui est automatiquement invoquée lors d’une opération INSERT, DELETE ou UPDATE. Le code trigger est associé à une table et est détruit une fois que la table est supprimée. Vous pouvez spécifier une heure de déclenchement de l’action et définir si elle sera activée avant ou après l’événement défini dans la base de données.

      Les triggers ont plusieurs avantages. Par exemple, vous pouvez les utiliser pour générer la valeur d’une colonne dérivée lors d’une instruction INSERT. Un autre cas d’utilisation consiste à faire respecter l’intégrité référentielle par laquelle vous pouvez utiliser un trigger pour sauvegarder un enregistrement dans plusieurs tables apparentées. D’autres avantages incluent la journalisation des actions des utilisateurs dans les tables d’audit ainsi que la copie en direct des données dans différents schémas de base de données à des fins de redondance, pour éviter un point de défaillance.

      Vous pouvez également utiliser des triggers pour maintenir des règles de validation au niveau de la base de données. Cela permet de partager la source de données entre plusieurs applications sans rompre la logique commerciale. Cela réduit considérablement les allers-retours vers le serveur de la base de données, ce qui améliore donc le temps de réponse de vos applications. Comme le serveur de base de données exécute des triggers, ils peuvent profiter de ressources serveur améliorées telles que la RAM et le processeur.

      Dans ce tutoriel, vous allez créer, utiliser et supprimer différents types de triggers dans votre base de données MySQL.

      Conditions préalables

      Avant de commencer, assurez-vous que vous disposez de ce qui suit :

      Étape 1 — Création d’un exemple de base de données

      Dans cette étape, vous allez créer un exemple de base de données client avec plusieurs tables, afin de démontrer le fonctionnement des triggers MySQL.

      Pour en savoir plus sur les requêtes MySQL, consultez notre Introduction aux requêtes dans MySQL.

      Tout d’abord, connectez-vous à votre serveur MySQL en tant que root :

      Entrez votre mot de passe root MySQL lorsqu’il vous est demandé et cliquez sur ENTER pour continuer. Lorsque vous voyez l’invite mysql>, exécutez la commande suivante pour créer une base de données test_db :

      Output

      Query OK, 1 row affected (0.00 sec)

      Ensuite, accédez à test_db avec :

      Output

      Database changed

      Vous commencerez par créer une table de clients customers. Cette table contiendra les enregistrements des clients (customers), y compris les customer_id, customer_name, et level. Il y aura deux niveaux de clients : BASIC et VIP.

      • Create table customers(customer_id BIGINT PRIMARY KEY, customer_name VARCHAR(50), level VARCHAR(50) ) ENGINE=INNODB;

      Output

      Query OK, 0 rows affected (0.01 sec)

      Maintenant, ajoutez quelques enregistrements à la table customers. Pour ce faire, exécutez les commandes suivantes une par une :

      • Insert into customers (customer_id, customer_name, level )values('1','JOHN DOE','BASIC');
      • Insert into customers (customer_id, customer_name, level )values('2','MARY ROE','BASIC');
      • Insert into customers (customer_id, customer_name, level )values('3','JOHN DOE','VIP');

      Vous verrez la sortie suivante après avoir exécuté chacune des commandes INSERT :

      Output

      Query OK, 1 row affected (0.01 sec)

      Pour vous assurer que les échantillons d’enregistrements ont été insérés avec succès, exécutez la commande SELECT :

      Output

      +-------------+---------------+-------+ | customer_id | customer_name | level | +-------------+---------------+-------+ | 1 | JOHN DOE | BASIC | | 2 | MARY ROE | BASIC | | 3 | JOHN DOE | VIP | +-------------+---------------+-------+ 3 rows in set (0.00 sec)

      Vous allez également créer une autre table pour conserver les informations relatives au compte de clients customers. La table contiendra les champs customer_id et status_notes

      Exécutez la commande suivante :

      • Create table customer_status(customer_id BIGINT PRIMARY KEY, status_notes VARCHAR(50)) ENGINE=INNODB;

      Ensuite, vous allez créer une table de ventes sales. Cette table contiendra les données de vente (sales) relatives aux différents clients via la colonne customer_id :

      • Create table sales(sales_id BIGINT PRIMARY KEY, customer_id BIGINT, sales_amount DOUBLE ) ENGINE=INNODB;

      Output

      Query OK, 0 rows affected (0.01 sec)

      Vous allez ajouter des échantillons de données aux données de vente sales lors des étapes à venir, tout en testant les triggers. Ensuite, créez une table audit_log pour enregistrer les mises à jour apportées à la table des ventes sales lorsque vous implémenterez le trigger AFTER UPDATE à l’étape 5 :

      • Create table audit_log(log_id BIGINT PRIMARY KEY AUTO_INCREMENT, sales_id BIGINT, previous_amount DOUBLE, new_amount DOUBLE, updated_by VARCHAR(50), updated_on DATETIME ) ENGINE=INNODB;

      Output

      Query OK, 0 rows affected (0.02 sec)

      Avec la base de données test_db et les quatre tables en place, vous allez maintenant travailler avec les différents triggers MySQL dans votre base de données.

      Étape 2 — Création d’un trigger Before Insert

      Dans cette étape, vous allez examiner la syntaxe d’un trigger MySQL avant d’appliquer cette logique pour créer un trigger BEFORE INSERT qui valide le champ sales_amount lorsque des données sont insérées dans la table sales.

      La syntaxe générale utilisée pour créer un trigger MySQL est illustrée dans l’exemple suivant :

      DELIMITER //
      CREATE TRIGGER [TRIGGER_NAME]
      [TRIGGER TIME] [TRIGGER EVENT]
      ON [TABLE]
      FOR EACH ROW
      [TRIGGER BODY]//
      DELIMITER ;
      

      La structure du trigger comprend :

      DELIMITER // : le délimiteur MySQL par défaut est ; — il est nécessaire de le changer en autre chose afin que MySQL traite les lignes suivantes comme une seule commande jusqu’à ce qu’il atteigne votre délimiteur personnalisé. Dans cet exemple, le délimiteur est changé en // et ensuite le délimiteur ; est redéfini à la fin.

      [TRIGGER_NAME] : Un trigger doit avoir un nom et c’est là que vous incluez la valeur.

      [TRIGGER TIME] : Un trigger peut être invoqué à différents moments. MySQL vous permet de définir si le trigger démarrera avant ou après une opération de base de données.

      [TRIGGER EVENT]: Les triggers ne sont appelés que par les opérations INSERT, UPDATE et DELETE. Vous pouvez utiliser n’importe quelle valeur ici en fonction de ce que vous voulez réaliser.

      [TABLE]: Tout trigger que vous créez sur votre base de données MySQL doit être associé à une table.

      FOR EACH ROW : Cette instruction ordonne à MySQL d’exécuter le code du trigger pour chaque ligne que ce dernier affecte.

      [TRIGGER BODY] : le code qui est exécuté lorsque le trigger est invoqué est appelé_ trigger body​​_​. Ce peut être une seule instruction SQL ou plusieurs commandes. Notez que si vous exécutez plusieurs instructions SQL sur le trigger body, vous devez les inclure dans un bloc BEGIN... END.

      Remarque : Lorsque vous créez le trigger body, vous pouvez utiliser les mots-clés OLD et NEW pour accéder aux valeurs de colonnes anciennes et nouvelles entrées lors d’une opération INSERT, UPDATE et DELETE. Dans un déclencheur DELETE, seul le mot-clé OLD peut être utilisé (que vous utiliserez à l’étape 4).

      Vous allez maintenant créer votre premier trigger BEFORE INSERT. Ce trigger sera associé à la table des ventes sales et il sera invoqué avant l’insertion d’un enregistrement pour valider le sales_amount. La fonction du trigger consiste à vérifier si le sales_amount inséré dans la table des ventes est supérieur à 10000 et à signaler une erreur si cette valeur est évaluée comme vraie (true).

      Assurez-vous que vous êtes connecté au serveur MySQL. Ensuite, entrez les commandes MySQL suivantes une par une :

      • DELIMITER //
      • CREATE TRIGGER validate_sales_amount
      • BEFORE INSERT
      • ON sales
      • FOR EACH ROW
      • IF NEW.sales_amount>10000 THEN
      • SIGNAL SQLSTATE '45000'
      • SET MESSAGE_TEXT = 'Sale has exceeded the allowed amount of 10000.';
      • END IF//
      • DELIMITER ;

      Vous utilisez l’instruction IF... THEN... END IF pour évaluer si la quantité fournie lors de l’instruction INSERT est comprise dans votre plage. Le trigger est capable d’extraire la nouvelle valeur sales_amount fournie en utilisant le mot-clé NEW.

      Pour faire apparaître un message d’erreur générique, vous utilisez les lignes suivantes pour informer l’utilisateur de l’erreur :

      SIGNAL SQLSTATE '45000'
      SET MESSAGE_TEXT = 'Sale has exceeded the allowed amount of 10000.';
      

      Ensuite, insérez un enregistrement avec un sales_amount de 11000 dans la table des ventes pour vérifier si le trigger arrêtera l’opération :

      • Insert into sales(sales_id, customer_id, sales_amount) values('1','1','11000');

      Output

      ERROR 1644 (45000): Sale has exceeded the allowed amount of 10000.

      Cette erreur montre que le code du trigger fonctionne comme prévu.

      Essayez maintenant un nouvel enregistrement avec une valeur de 7500 pour vérifier si la commande aboutira :

      • Insert into sales(sales_id, customer_id, sales_amount) values('1','1','7500');

      Comme la valeur est dans la plage recommandée, vous verrez la sortie suivante :

      Output

      Query OK, 1 row affected (0.01 sec)

      Pour confirmer que les données ont été insérées, exécutez la commande suivante :

      La sortie confirme que les données sont dans la table :

      Output

      +----------+-------------+--------------+ | sales_id | customer_id | sales_amount | +----------+-------------+--------------+ | 1 | 1 | 7500 | +----------+-------------+--------------+ 1 row in set (0.00 sec)

      Dans cette étape, vous avez testé des triggers pour valider les données avant leur insertion dans une base de données.

      Ensuite, vous allez travailler avec le trigger AFTER INSERT pour enregistrer les informations connexes dans différentes tables.

      Étape 3 — Création d’un trigger After Insert

      Les triggers AFTER INSERT sont exécutés lorsque les enregistrements sont insérés avec succès dans une table. Cette fonctionnalité peut être utilisée pour exécuter automatiquement d’autres logiques commerciales. Par exemple, dans une application bancaire, un déclencheur AFTER INSERT peut fermer un compte de prêt lorsqu’un client a fini de rembourser le prêt. Le trigger peut surveiller tous les paiements insérés dans une table de transactions et fermer le prêt automatiquement une fois que le solde du prêt est à zéro.

      Dans cette étape, vous travaillerez avec votre table customer_status en utilisant un trigger AFTER INSERT pour entrer des enregistrements de clients apparentés.

      Pour créer le trigger AFTER INSERT, entrez les commandes suivantes :

      • DELIMITER //
      • CREATE TRIGGER customer_status_records
      • AFTER INSERT
      • ON customers
      • FOR EACH ROW
      • Insert into customer_status(customer_id, status_notes) VALUES(NEW.customer_id, 'ACCOUNT OPENED SUCCESSFULLY')//
      • DELIMITER ;

      Output

      Query OK, 0 rows affected (0.00 sec)

      Ici, vous demandez à MySQL d’enregistrer un autre enregistrement dans la table customer_status une fois qu’un nouvel enregistrement client est inséré dans la table de clients customers.

      Maintenant, insérez un nouvel enregistrement dans la table customers pour confirmer que votre code de trigger sera invoqué :

      • Insert into customers (customer_id, customer_name, level )values('4','DAVID DOE','VIP');

      Output

      Query OK, 1 row affected (0.01 sec)

      Comme l’enregistrement a été inséré avec succès, vérifiez qu’un nouvel enregistrement de statut a été inséré dans la table customer_status :

      • Select * from customer_status;

      Output

      +-------------+-----------------------------+ | customer_id | status_notes | +-------------+-----------------------------+ | 4 | ACCOUNT OPENED SUCCESSFULLY | +-------------+-----------------------------+ 1 row in set (0.00 sec)

      La sortie confirme que le trigger a bien été exécuté.

      Le trigger AFTER INSERT est utile pour surveiller le cycle de vie d’un client. Dans un environnement de production, les comptes clients peuvent subir différentes étapes telles que l’ouverture, la suspension et la fermeture du compte.

      Dans les étapes suivantes, vous allez travailler avec des triggers UPDATE.

      Étape 4 — Création d’un trigger Before Update

      Un trigger BEFORE UPDATE est similaire au trigger BEFORE INSERT — la différence est le moment où ils sont invoqués. Vous pouvez utiliser le trigger BEFORE UPDATE pour vérifier une logique commerciale avant de mettre à jour un enregistrement. Pour tester cela, vous utiliserez la table customers dans laquelle vous avez déjà inséré certaines données.

      Vous disposez de deux niveaux pour vos clients dans la base de données. Dans cet exemple, une fois qu’un compte client est mis à jour au niveau VIP, le compte ne peut pas être retrogradé au niveau BASIC. Pour faire appliquer une telle règle, vous allez créer un trigger BEFORE UPDATE qui s’exécutera avant l’instruction UPDATE, comme indiqué ci-dessous. Si un utilisateur de la base de données tente de rétrograder un client du niveau VIP au niveau BASIC, une exception définie par l’utilisateur sera déclenchée.

      Entrez les commandes SQL suivantes une par une pour créer le trigger BEFORE UPDATE :

      • DELIMITER //
      • CREATE TRIGGER validate_customer_level
      • BEFORE UPDATE
      • ON customers
      • FOR EACH ROW
      • IF OLD.level='VIP' THEN
      • SIGNAL SQLSTATE '45000'
      • SET MESSAGE_TEXT = 'A VIP customer can not be downgraded.';
      • END IF //
      • DELIMITER ;

      Vous utilisez le mot-clé OLD pour capturer le niveau fourni par l’utilisateur lors de l’exécution de la commande UPDATE. Encore une fois, vous utilisez l’instruction IF... THEN... END IF pour signaler à l’utilisateur une instruction d’erreur générique.

      Ensuite, exécutez la commande SQL suivante qui tente de rétrograder un compte client associé au customer_id 3 :

      • Update customers set level='BASIC' where customer_id='3';

      Vous verrez la sortie suivante fournissant le SET MESSAGE_TEXT: :

      Output

      ERROR 1644 (45000): A VIP customer can not be downgraded.

      Si vous exécutez la même commande pour un client de niveau BASIC, et que vous essayez de faire passer le compte au niveau VIP, la commande sera exécutée avec succès :

      • Update customers set level='VIP' where customer_id='1';

      Output

      Rows matched: 1 Changed: 1 Warnings: 0

      Vous avez utilisé le trigger BEFORE UPDATE pour faire appliquer une règle commerciale. Vous allez maintenant utiliser un trigger AFTER UPDATE pour l’enregistrement des audits.

      Étape 5 — Création d’un trigger After Update

      Un trigger AFTER UPDATE est invoqué une fois qu’un enregistrement de base de données est mis à jour avec succès. Ce comportement rend le trigger adapté à l’enregistrement des audits. Dans un environnement multi-utilisateurs, l’administrateur peut vouloir consulter un historique des modifications apportées par les utilisateurs dans une table particulière, à des fins d’audit.

      Vous allez créer un trigger qui enregistre l’activité de mise à jour de la table sales. Notre table audit_log contiendra des informations sur les utilisateurs MySQL qui mettent à jour la table sales, la date de la mise à jour, et les valeurs new et old de sales_amount.

      Pour créer le trigger, exécutez les commandes SQL suivantes :

      • DELIMITER //
      • CREATE TRIGGER log_sales_updates
      • AFTER UPDATE
      • ON sales
      • FOR EACH ROW
      • Insert into audit_log(sales_id, previous_amount, new_amount, updated_by, updated_on) VALUES (NEW.sales_id,OLD.sales_amount, NEW.sales_amount,(SELECT USER()), NOW() )//
      • DELIMITER ;

      Vous insérez un nouvel enregistrement dans la table audit_log. Vous utilisez le mot-clé NEW pour récupérer la valeur du sales_id et du nouveau sales_amount En outre, vous utilisez le mot-clé OLD pour récupérer le sales_amount précédent puisque vous voulez enregistrer les deux montants à des fins d’audit.

      La commande SELECT User() récupère l’utilisateur actuel de l’opération et l’instruction NOW() extrait la valeur de la date et de l’heure actuelle du serveur MySQL

      Maintenant, si un utilisateur essaie de mettre à jour la valeur d’un enregistrement dans la table sales, le trigger log_sales_updates va insérer un nouvel enregistrement dans la table audit_log.

      Créons un nouvel enregistrement de ventes avec un sales_id aléatoire de 5 et essayons de le mettre à jour. En premier lieu, insérez l’enregistrement des ventes avec :

      • Insert into sales(sales_id, customer_id, sales_amount) values('5', '2','8000');

      Output

      Query OK, 1 row affected (0.00 sec)

      Ensuite, mettez à jour l’enregistrement :

      • Update sales set sales_amount='9000' where sales_id='5';

      Vous verrez la sortie suivante :

      Output

      Rows matched: 1 Changed: 1 Warnings: 0

      Exécutez maintenant la commande suivante pour vérifier si le trigger AFTER UPDATE a pu enregistrer un nouvel enregistrement dans la table audit_log :

      Le trigger a enregistré la mise à jour. Votre sortie indique l’ancien et le nouveau sales_amount enregistrés avec l’utilisateur qui a mis à jour les enregistrements :

      Output

      +--------+----------+-----------------+------------+----------------+---------------------+ | log_id | sales_id | previous_amount | new_amount | updated_by | updated_on | +--------+----------+-----------------+------------+----------------+---------------------+ | 1 | 5 | 8000 | 9000 | root@localhost | 2019-11-07 09:28:36 | +--------+----------+-----------------+------------+----------------+---------------------+ 1 row in set (0.00 sec)

      Vous disposez également de la date et de l’heure auxquelles la mise à jour a été effectuée, ce qui est précieux à des fins d’audit.

      Ensuite, vous utiliserez le trigger DELETE pour faire respecter l’intégrité du référencement au niveau de la base de données.

      Étape 6 — Création d’un trigger Before Delete

      Les triggers BEFORE DELETE sont invoqués avant qu’une instruction DELETE ne s’exécute sur une table.  Ces types de triggers sont généralement utilisés pour faire respecter l’intégrité référentielle dans différentes tables apparentées. Par exemple, chaque enregistrement de la table sales concerne un customer_id de la table customers. Si un utilisateur de la base de données a supprimé un enregistrement de la table customers qui a un enregistrement lié dans la table sales, vous n’auriez aucun moyen de connaître le client associé à cet enregistrement.

      Pour éviter cela, vous pouvez créer un trigger BEFORE DELETE pour faire appliquer votre logique. Exécutez les commandes SQL suivantes une par une :

      • DELIMITER //
      • CREATE TRIGGER validate_related_records
      • BEFORE DELETE
      • ON customers
      • FOR EACH ROW
      • IF OLD.customer_id in (select customer_id from sales) THEN
      • SIGNAL SQLSTATE '45000'
      • SET MESSAGE_TEXT = 'The customer has a related sales record.';
      • END IF//
      • DELIMITER ;

      Maintenant, essayez de supprimer un client qui a un enregistrement de vente connexe :

      • Delete from customers where customer_id='2';

      Vous recevrez alors la sortie suivante :

      Output

      ERROR 1644 (45000): The customer has a related sales record.

      Le trigger BEFORE DELETE peut empêcher la suppression accidentelle d’informations connexes dans une base de données.

      Toutefois, dans certaines situations, vous pouvez vouloir supprimer tous les enregistrements associés à un enregistrement particulier dans les différentes tables connexes. Dans cette situation, vous utiliserez le trigger AFTER DELETE, que vous allez tester à l’étape suivante.

      Étape 7 — Création d’un trigger After Delete

      Les triggers AFTER DELETE sont activés une fois qu’un enregistrement a été supprimé avec succès. Vous pouvez par exemple utiliser un trigger AFTER DELETE dans une situation où le niveau de remise qu’un client particulier reçoit est déterminé par le nombre de ventes effectuées pendant une période définie. Si certains des enregistrements du client sont supprimés de la table sales, le niveau de réduction du client devrait être réduit.

      Une autre utilisation du trigger AFTER DELETE consiste à supprimer des informations connexes d’une autre table une fois qu’un enregistrement de table de base est supprimé.  Par exemple, vous allez définir un trigger qui supprime l’enregistrement du client si les enregistrements de ventes avec le customer_id correspondant sont supprimés de la table sales. Exécutez la commande suivante pour créer votre trigger :

      • DELIMITER //
      • CREATE TRIGGER delete_related_info
      • AFTER DELETE
      • ON sales
      • FOR EACH ROW
      • Delete from customers where customer_id=OLD.customer_id;//
      • DELIMITER ;

      Ensuite, exécutez ce qui suit pour supprimer tous les enregistrements de ventes associés à un customer_id de 2 :

      • Delete from sales where customer_id='2';

      Output

      Query OK, 1 row affected (0.00 sec)

      Vérifiez maintenant s’il existe des enregistrements pour le client dans la table sales :

      • Select * from customers where customer_id='2';

      Vous recevrez une sortie Empty Set puisque l’enregistrement client associé au customer_id de 2 a été supprimé par le trigger :

      Output

      Empty set (0.00 sec)

      Vous avez maintenant utilisé chacune des différentes formes de triggers pour effectuer des fonctions spécifiques. Ensuite, vous allez voir comment vous pouvez supprimer un trigger de la base de données si vous n’en avez plus besoin.

      Étape 8 — Suppression de triggers

      Comme pour tout autre objet de la base de données, vous pouvez supprimer des triggers à l’aide de la commande DROP. Voici la syntaxe de suppression d’un trigger :

      Drop trigger [TRIGGER NAME];
      

      Par exemple, pour supprimer le dernier trigger AFTER DELETE que vous avez créé, exécutez la commande suivante :

      • Drop trigger delete_related_info;

      Output

      Query OK, 0 rows affected (0.00 sec)

      La nécessité de supprimer des triggers se pose lorsque vous voulez en recréer la structure. Dans ce cas, vous pouvez supprimer le trigger et en redéfinir un nouveau avec les différentes commandes de trigger.

      Conclusion

      Dans ce tutoriel, vous avez créé, utilisé et supprimé les différents types de triggers d’une base de données MySQL. À l’aide d’un exemple de base de données relative aux clients, vous avez mis en place des triggers pour différents cas d’utilisation tels que la validation des données, une application de logique d’entreprise, l’enregistrement des audits et la mise en application de l’intégrité référentielle.

      Pour obtenir des informations supplémentaires sur l’utilisation de votre base de données MySQL, consultez ce qui suit :



      Source link