Introduction des Réplica Set dans MySQL

Avec l’arrivée de la version 8.0.19 de MySQL fraîchement sortie, une nouvelle fonctionnalité attendue est sortie, MySQL InnoDB ReplicaSet. Concrètement cela permet de créer et gérer des serveurs en réplication asynchrone et en utilisant MySQL Router et la fonctionnalité de clonage. C’est une approche plus traditionnelle de la haute disponibilité et plus simple qu’InnoDB Cluster. Les réplications Master/slave sont très répandues, et conviendraient davantage aux personnes réticentes à utiliser InnoDB Cluster. Il est hautement probable que cette fonctionnalité puisse être utilisée conjointement à InnoDB Cluster pour augmenter la scalabilité en lecture des grosses architectures.

Avec quelques commandes très simples il est possible de mettre en place une réplication master/slave et avec la fonctionnalité de clonage, les nœuds sont provisionnés sans effort et plus rapidement qu’avec un traditionnel backup/restore.

Cette fonctionnalité sera détaillée dans un prochain article.

Ci-dessous un schéma de cette nouvelle topologie.

Source : https://mysqlserverteam.com/introducing-mysql-innodb-replicaset/

MySQL élu base de données de l’année !

Une bonne année pour MySQL qui commence par une belle récompense, élu “DBMS of the YEAR 2019” par le site DB-engines qui mesure la popularité des moteurs de bases de données en fonction de nombreux critères avec 334 DBMS référencés !

La concurrence est rude mais sa popularité a fortement évolué en 2019 ce qui lui vaut cette récompense. Les développeurs ont grandement amélioré ce moteur et notamment à travers MySQL 8.0 et toutes les nouvelles fonctionnalités qui y sont associées. L’intégration d’un moteur NoSQL type document, Innodb Cluster, les Clones, de meilleures performances etc. La liste est longue ! 2020 devrait aussi avoir son lot de nouveautés pour MySQL !

Source : https://db-engines.com/en/blog_post/83

How to find and remove orphaned ASM files

This is a very annoying task when you have to purge old and unused files from ASM. Of course you can try to run the script provided by Oracle support in the Doc.Id 552082.1 , but the query is deprecated for post 12c grid infra. There is another note for post 12c ( 2228573.1 ) but here we will try another method.

In our databases we could have some files with OMF and some files with classical naming convention. So the first step is to list all files in disk groups, but when an asm alias ( due to the classical naming convention ) is present, display only this alias, not the target file.

(suite…)

Common issues on Cassandra.

Nous allons faire une passe sur les différents problèmes récurrents que nous avons rencontrés et établir une checklist en cas de problème.

1/ ReadTimeoutException sur un INSERT IF NOT EXISTS :

Description :

Des timeouts apparaissent suite à un changement de code applicatif : Il a été rajouté un INSERT IF NOT EXISTS.

(suite…)

Comment gérer la consistance des données sous Cassandra quand on a plusieurs tables contenant les mêmes données.

Nous allons traiter dans cet article de la gestion de la consistance des données dupliquées entre plusieurs tables. Pour rappel sous Cassandra, la duplication des données n’est pas considérée comme un antipattern comme sous certains SGBDs, on va au contraire préférer dupliquer les données afin d’avoir des structures de tables optimisées pour les requêtes.

Problématique : Lors d’une action que ce soit ajout, suppression, modification de données, il faut modifier toutes les tables où sont dupliquées les données. Il est donc impératif de maintenir un plan/modèle de données à jour. Mais la vraie problématique est si un insert/delete/update échoue sur une ou plusieurs tables pour une raison X, on aura un problème de cohérence puisque certaines tables auront étés mises à jour et d’autres non.

Afin de gérer la consistance des données dupliquées à travers plusieurs tables, nous recommandons deux options :

(suite…)

Les anti-patterns sous Apache Cassandra

Les anti-patterns ou mauvaises configurations possibles sont légion sous Cassandra, nous allons voir les principaux auxquels nous avons été confrontés que ce soit au niveau du matériel, de la modélisation ou encore de la configuration.

Rappel : la modélisation sous Cassandra, nécessite une attention toute particulière (90% du temps de réflexion doit être sur la création du modèle).

Anti-patterns au niveau de la modélisation :

  • Avoir plus de 100k lignes par partition (100k de lignes est la valeur maximum recommandé)
  • Avoir des partitions supérieur à 100Mb
  • Trop de tables:
    • Warning : si plus de 200 tables dans un cluster
    • Echec : si plus de 500 tables
  • Des Full scans / Cluster scans
  • Les LightWeights transactions (4 fois plus lents en moyenne qu’une opération)
  • Allow filtering (sauf si la requête utilise une seule partition)
  • Utilisation massive ou récurrente des indexes secondaires
  • Utiliser le type String pour représenter des dates et timestamps
  • Ne pas avoir tester son modèle sur des données réelles avec une volumétrie similaire
  • Utiliser le modèle read-before-write pour les transactions
  • Abuser des opérations de “deletes”
  • Utiliser des batchs qui requêtent multiples partitions

(suite…)

Mécanismes de repair d’un nœud absent d’un cluster Cassandra.

Lorsqu’un nœud est injoignable/absent d’un cluster Cassandra, il convient d’investiguer sur la raison de cette indisponibilité afin de connaître la raison pour la prévenir ou résoudre l’erreur en découlant.

On peut regarder plusieurs points tels que :

  • Log d’erreur
  • Log de debug
  • Log du garbage collector
  • Analyse des graphiques si vous avez un outil d’analyse ou une supervision
  • Utiliser les utilitaires nodetool
  • Analyse réseau
  • Vérification de l’uptime
  • Vérification de la log système

Une fois l’erreur identifiée, il faut convenir d’un mécanisme de réparation approprié. Par exemple si un nœud est absent du cluster pour un problème réseau ou le serveur/Cassandra était OFF (perte d’ESX, erreur humaine, …), il y a trois cas possibles de réparation possible.

(suite…)

Attentes “Cursor Mutex X” après upgrade Oracle 12.2

Suite à un upgrade vers Oracle 12.2, vous constatez de fortes attentes de type “Cursor Mutex X”.

Ceci est documenté dans la note Oracle: Cursor Mutex X Wait Events: After Upgrading To 12.2 (Doc ID 2298504.1).

Pour valider que vous êtes bien dans ce cas de figure et corriger ce comportement:

1/ Vérifier si vous avez un nombre élevé de version count pour certains traitements:

SQL> select sql_id,version_count from v$sqlarea where version_count>1000 order by 2;
SQL_ID        VERSION_COUNT
------------- -------------
cbm0xnu20su8h          1257
b0xwuj30mff4t          2575
4v6dakjg9k25c          7967

 

2/ Valider que le paramètre caché “_cursor_obsolete_threshold” a la valeur par défaut de la 12.2 (=8192)

SQL> select ksppinm, ksppstvl from x$ksppi a, x$ksppsv b where a.indx=b.indx and ksppinm like '%obsolete%';
KSPPINM                                            KSPPSTVL
-------------------------------------------------- --------------------------------------------------
_cursor_obsolete_threshold                         8192

 

3/ Modifier la valeur du paramètre caché (passage à 1024) et redémarrer l’instance.

SQL> alter system set "_cursor_obsolete_threshold"=1024 scope=spfile;

Purge des tables AWR

Il existe un problème de purge sur certaines tables AWR. Cela a été constaté sur les versions 11. Cela entraîne une augmentation importante du tablespace SYSAUX. Les tables suivantes ont été identifiées :

  • sys.wrh$_event_histogram
  • sys.wrh$_active_session_history

En cas de taille importante du tablespace SYSAUX, on pourra vérifier avec la requête suivante les segments les plus volumineux et confirmer ainsi que ce sont bien les tables listées ci-dessus qui sont consommatrices.

SQL> select owner,segment_name, segment_type, sum(bytes)/1024/1024 from dba_segments where TABLESPACE_NAME='SYSAUX' group by segment_name, segment_type, owner order by 4;

La procédure pour purger ces tables est la suivante (exemple avec sys.wrh$_event_histogram)  :

1/ Arrêt de la collecte AWR

Dans une configuration RAC, la commande n’est à passer que sur un seul noeud.

SQL> exec dbms_workload_repository.modify_snapshot_settings(interval => 0); 

2/ Sauvegarde des lignes non orphelines dans une table temporaire (sys.wrh$_event_histogram_save)

Pour rappel, le nom de la table ne doit pas dépasser 30 caractères.

SQL> create table sys.wrh$_event_histogram_save tablespace SYSAUX as
select * from sys.WRH$_EVENT_HISTOGRAM
where (dbid,instance_number,snap_id) in (select dbid,instance_number,snap_id from dba_hist_snapshot); 

ATTENTION : Penser à surveiller la volumétrie d’archivelogs. Le nombre de lignes déplacées peut-être estimé ainsi :

SQL> select count(*)
from sys.wrh$_event_histogram
where (dbid,instance_number,snap_id) in (select dbid,instance_number,snap_id from dba_hist_snapshot);

3/ Truncate de la table sys.wrh$_event_histogram

SQL> truncate table sys.wrh$_event_histogram drop storage;

4/ Réinsertion des lignes sauvegardées dans la table wrh$_event_histogram

SQL> insert /*+ APPEND */ into sys.wrh$_event_histogram
select * from sys.wrh$_event_histogram_save;

SQL> commit;

5/ Calcul des statistiques de la table wrh$_event_histogram

SQL> EXEC DBMS_STATS.gather_table_stats('SYS', 'WRH$_EVENT_HISTOGRAM', 
cascade => TRUE);

6/ Réactivation de la collecte AWR

SQL> exec dbms_workload_repository.modify_snapshot_settings(interval => 60);

7/ Suppression de la table temporaire

SQL> drop table sys.wrh$_event_histogram_save;