Admettons que nous devions remonter pour une base mysql donnée le top 10 des tables les plus accédées en lecture par temps d’accès. On pourrait utiliser P_S.table_io_waits_summary_by_table par exemple :
mysql> select OBJECT_NAME, INDEX_NAME, COUNT_READ, AVG_TIMER_READ
-> from …[Lire plus]
Avant la version 5.6.24 ou 5.7.6 de MySQL, il n’y a aucun moyen de paramétrer la taille maximale du texte SQL capturé dans P_S.events_statements_summary_by_digest et events_statements_(current,history,history_long). Il est …
[Lire plus]Si vous avez migré plus ou moins récemment de version de MySQL vers 5.7 ou 8.0, vous ne l’avez peut être pas encore remarqué, mais il y a eu quelques petits changements au niveau des variables de statut. Outre le fait de les avoir déplacé …
[Lire plus]Au nom de toute l'équipe MySQL, je souhaite vous remercier pour votre présence !
On a certes dû un peu pousser les murs (sorry for that), mais finalement cela n'a fait que contribuer à rendre l'événement encore plus convivial :)
Et voici les slides:
The post Slides du MySQL Day Paris 2018 – NoSQL + SQL = MySQL first appeared on dasini.net - Journal d'un expert MySQL.
Toute architecture de base de données se doit de se reposer sur 3 piliers, la supervision (monitoring) , la sauvegarde/restauration et la haute disponibilité. Mon premier article de l'année 2018 concerne l'un des meilleurs combos du moment, en matière de haute disponibilité niveau base de données : - MySQL 5.7 Group Replication : la seule solution native HA de MySQL, qui permet notamment de faire du vrai multi-master (avec MySQL NDB Cluster mais ceci est hors sujet). - ProxySQL 1.4 : modestement le meilleur proxy pour MySQL.
I – Les performances Front-End :
CAUSES DES MAUVAISES PERFORMANCES :
Les causes des problèmes de performances front sont connues et bien maitrisées. Les plus significatives sont :
SOLUTION EXISTANTES :
Il existe de nombreux outils permettant d’analyser et d’améliorer la performance « perçue » par vos utilisateurs. Le plus connu est probablement Google Pagespeed qui vous fourni une analyse de vos pages, et la liste des points à …
[Lire plus]The second OSSEC week just ended. Here is a reflection about a feature that does not exist (yet?) in OSSEC. The goal of a SIEM (“Security Incidents and Events Management“) is to collect logs from multiple non-heterogeneous sources and process them to add some extra value to the events. To achieve this, powerful correlation engines can be used to create rules to match different types of events coming from different sources and to create a unique security incident:
if (condition1 && condition2 && condition3)
{
created_security_alert();
}
Once created, The security incident must be processed. The basic action is to notify the right people with messages displayed on a console, new events, emails, etc. But, depending on their criticality, not all security incidents must result in messages. Some correlation rules results may just create new …
[Lire plus]