Pré-requis : Après l'installation du système il est nécessaire (sauf si vous avez chosi KDE) d'installer KDEbase afin de disposer de "konsole", l'explication est toute simple : seul le terminal "konsole" de KDE permet, à ma connaissance, d'avoir le rendu "semi-graphique" utilisé par les outils Ingres, et surtout d'avoir accès aux "bonnes" touches de fonction exploitées par tous les outils de configuration de Ingres. 
J'installe aussi mon éditeur préféré "yum install vim-X11". 
Le logiciel a été téléchargé et installé dans /var/tmp/INSTALL : 
- ingres-10.0.0-122-NTPL-gpl-linux-ingbuild-x86_64.tgz (#60 Mo) 
Le "détarage" du fichier crée un répertoire du même nom comprenant : 
-rwxr-xr-x 1 ingres 50000    17847 avr 21 19:10 ingres_express_install.sh 
-rw-rw-r-- 1 ingres 50000 78571520 avr 21 19:50 ingres.tar 
-rwxr-xr-x 1 ingres 50000    13299 avr 21 19:10 install.sh 
-rw-r--r-- 1 ingres 50000    15238 avr 21 19:02 LICENSE 
-rw-r--r-- 1 ingres 50000    10636 avr 21 19:29 readme_a64_lnx_nptl.html 
-rw-rw-r-- 1 ingres 50000    28075 avr 21 19:29 readme.html 
L'installation étant parfois en mode texte, parfois en mode semi-graphique je vais essayer de "rendre" au mieux l'aspect des écrans, donc ici pas de belles images, que du texte ! 
Je me connecte dans une session X avec le user "root" (c'est comme cela depuis la version 2006r3) pour lancer l'installation dans une "konsole". 
Ne pas lancer le tentant "ingres_express_install.sh" car il ne réalise qu'une installation minimale avec les données dans le répertoire /opt/Ingres ce qui n'est pas le but visé. 
Il suffit de lancer "./install.sh". 
- Première question : "Please choose a location to install Ingres ", il faut indiquer le nom du répertoire d'installation du logiciel, ici "/opt/Ingres", ce répertoire sera ensuite "pointé" par la variable "II_SYSTEM". 
- Deuxième question "Please choose a user to install Ingres ", indiquer "ingres" puisque nous avons créé cet utilisateur. 
- On défile ensuite la licence GPL ... que l'on accepte ...

Please identify the type of terminal (or terminal emulation software)  you are using by entering its Ingres termcap name (e.g. 'vt100f' for a  VT100 with a function key pad).  If you do not know the termcap name for  your terminal, press return to see a list of the available termcap names.  Enter termcap name, or press return for a list:

Répondre ici "konsole", un menu semi-graphique s'affiche alors :

INGBUILD - Ingres Installation Utility     ┌────────────────────────────────────────────────────────────────────────┐     │        II_SYSTEM: /opt/Ingres                                          │     │     Distribution: /var/tmp/INSTALL/ingres-10.0.0-122-NPTL-gpl-linux-in │     └────────────────────────────────────────────────────────────────────────┘      Custom  - Select this option in order to view the contents of the                distribution medium and/or select components for installation                on your system.  This option will also allow you to upgrade                an existing installation of INGRES products.      Package - Select predefined packages for installation on your system.      Help    - See more instructions on using this program.      To select a menu item, press ESC and type the name of the menu item.    CustomInstall  PackageInstall  Help  Quit  :

Choisir CustomInstall (Cu) l'écran suivant s'affiche :

INGBUILD  - Custom Install from Distribution Medium      Distribution: /var/tmp/INSTALL/ingres-10.0.0-122-NPTL-gpl-linux-ingbuild-x     ┌──────────────────────────────────────────────────────┬─────┬──────────┐     │               Custom Component Options               │ Size│ Install? │     ├──────────────────────────────────────────────────────┼─────┼──────────┤     │Embedded SQL Precompilers                             │  23M│Yes       │     │Ingres 32bit support                                  │  42M│Yes       │     │INGRES 6.x Compatible Message Files                   │   4M│Yes       │     │Ingres Intelligent DBMS                               │ 104M│Yes       │     │Ingres DTP for Tuxedo                                 │  56M│Yes       │     │Ingres Networking                                     │  66M│Yes       │     │Ingres Object Management                              │ 879K│Yes       │     │Ingres ODBC Driver                                    │  65M│Yes       │     │Ingres Protocol Bridge                                │ 947K│Yes       │     │Ingres C2 Security Auditing                           │  25K│Yes       │     │Ingres Replicator                                     │   2M│Yes       │     └──────────────────────────────────────────────────────┴─────┴──────────┘      II_SYSTEM  : /opt/Ingres      To add or remove products from the list of products to be installed,      enter 'y' or 'n' in the 'Install?' column.    Install  ExpressInstall  GetInfo  Help  End

Ici il faut vérifier que tout est à "Yes", puis choisir "Install" (F5), une "boite" affiche un petit récapitulatif :

INGBUILD  - Custom Install from Distribution Medium      Distribution: /var/tmp/INSTALL/ingres-10.0.0-122-NPTL-gpl-linux-ingbuild-x     +------------------------------------------------------+-----+----------+     |               Custom+-----------------------------------------------------+     |=====================|Products selected: 16     Disk space required:   89M |     |Ingres ODBC Driver   | Support modules : 19                           100M |     |Ingres Protocol Bridg|                   --     Temporary storage  :   10M |     |Ingres C2 Security Au|                                                ---- |     |Ingres Replicator    |            Total: 35                           199M |     |Ingres Spatial Object|                                                     |     |Ingres Data Access Se|Do you want to proceed with the installation?        |     |Ingres Star Distribut+-------------+---------------------------------------+     |Query and Reporting R|Yes          |Install all selected products          |     |Query and Reporting T|No           |Cancel requested installation          |     |Terminal Monitors    +-------------+---------------------------------------+     |VisionPro                                             |  66M|Yes       |     +------------------------------------------------------+-----+----------+      II_SYSTEM  : /opt/Ingres      To add or remove products from the list of products to be installed,      enter 'y' or 'n' in the 'Install?' column.

Il suffit de frapper "Entrée" sur le "Yes" présélectionné. 
L'écran s'anime pendant la vérification puis propose dans une nouvelle "boîte" : "Do you want to set up these products now", frapper "Entrée" sur le "Yes" présélectionné. 
Premier setup : "Setting up Application-By-Forms..." 
Se contenter d'appuyer sur entrée, un petit message de confirmation s'affiche : 

ING_ABFDIR configured as /opt/Ingres/ingres/abf 
Application-By-Forms setup complete. 
Press RETURN to continue: 
Il faut encore faire "Entrée" puis un écran "Setting up the Ingres Intelligent DBMS..." récapitule les paramètres de Ingres DBMS, frapper "y" et "Entrée" puis le message suivant s'affiche :

Ingres has the capability to guarantee integrity of all committed  database transactions in the event of a system software failure or  single storage device failure.  IMPORTANT NOTE: if a second storage  device fails before recovery from an initial failure has taken place,  committed transactions may be lost.  If you intend to take advantage of this capability, you need to  have at least two independent storage devices available (one in  addition to the one Ingres is being installed on).  If you do not  have two independent storage devices available, but would like to take  advantage of this capability, you should not complete this setup  procedure at this time.  Do you want to continue this setup procedure? (y/n) [y]

Il s'agit d'un écran d'information au sujet du système de logging, ce type d'écran appairatra par la suite pour les phases importants. Ingres permet d'utiliser un "dual log" sur un disque différent pour augmenter la sécurité des données en cas d'incident sur un disque. Nous ne nous servirons pas de cette fonctionnalité. 
On frappe donc "y" et "Entrée" sans autre forme de procès et l'installeur génère la configuration par défaut. Celle-ci nous conviendra souvent. 
Please enter a valid installation code [II] 
Frapper "Entrée" 
Do you want instructions on configuring your storage locations? (y/n) [y] 
Les "locations" sont les répertoires où Ingres place les différentes catégories d'éléments (log, journal,bases de données, espace de travail ....) , la plupart de ces "locations" sont ensuite pointées par des variables de la forme "II_nom_variable",je préciserais ces éléments au passage, vous pouvez répondre "Y" et voir l'ensemble des conseils, ici je réponds "N". 
II_DATABASE 
Ici je désire que les données des bases soient placées dans le répertoire "/DATA/ingres", je réponds donc /DATA/ingres. 
Please enter the default location for the Ingres Checkpoint Files: 
[/opt/Ingres] 
Les fichiers de "checkpoint" ne sont pas volumineux, ils peuvent très bien être stockés à l'endroit proposé, un jeu de sous-répertoires sera créé, il convient donc de faire "Entrée".

----------------------------------------------------------------------  |                             *** WARNING ***                          |  |  Do not store checkpoint, journal or dump files for a database on    |  |  the same physical device as its data, or you will not be able to    |  |  recover the data stored on that device if it fails.  Please verify  |  |  that the default location you have entered for your                 |  |  Ingres Checkpoint Files:                                            |  |         /opt/Ingres                                                  |  |  is on a different physical device from the default location you     |  |  have entered for your database files:                               |  |         /DATA/ingres                                                 |  ----------------------------------------------------------------------  Is the value you have entered for II_CHECKPOINT correct? (y/n)

Ce type de "warning" est affiché régulièrement afin de nous inciter à réfléchir à la sécurité de notre installation. Si nous sommes "bons" répondre "y" sans crainte. 

Please enter the default location for the Ingres Journal Files: 
[/opt/Ingres] 
Ici aussi nous pouvons prendre cette valeur par défaut. 

Please enter the default location for the Ingres Dump Files: 
[/opt/Ingres] 
Ici aussi nous pouvons prendre cette valeur par défaut. 

Please enter the default location for the Ingres Work Files: 
[/opt/Ingres] 
Ici nous voulons utiliser le même disque que le log, nous mettons donc le nom de notre répertoire réservé : "/LOG/ingtemp". 
Do you want to disable the backup transaction log? (y/n) [n] 
Il s'agit ici du fameux "Dual_log" dont nous n'avons pas besoin pour une machine de test, il n'en serait pas de même en production où il faudrait le positionner sur un autre disque physique que le log standard, nous répondons donc "Y". 

The default size for the Ingres transaction log is: 
           262144K bytes ( 256M bytes) 
Do you want to change the default transaction log size? (y/n) [n] 

Ici la taille proposée est de 256Mo, le log étant un buffer circulaire il est nécessaire de la positionner à une taille suffisante pour supporter la charge transactionnelle. Ici pour certains tests "lourds" il sera positionné à 4Go, répondons "n" pour pouvoir proposer une valeur différente. 
Please enter the desired transaction log size (in Megabytes): 4096 
Suivi de "Entrée" 
Please enter a location for the Ingres transaction log: 
[/opt/Ingres] 
Mettre ici le répertoire que nous avons prévu pour ceci : "/LOG/ingres".

You must now specify the number of CPUs (processors) in this machine  so that Ingres may be set up for this server. If you do not know  the exact number of CPUs, but know that this is a multi-cpu machine,  enter a value of 2.  The value you specify will be used to set the Ingres variable  II_NUM_OF_PROCESSORS and possibly other configuration variables.  Please enter the number of CPUs in this machine [1] Y

Ici, un seul CPU est prévu, il faut ensuite choisir le fuseau horaire (en deux étapes), première liste : 
            AFRICA 
              ASIA 
         AUSTRALIA 
       MIDDLE-EAST 
     NORTH-AMERICA 
    NORTH-ATLANTIC 
     SOUTH-AMERICA 
     SOUTH-PACIFIC 
    SOUTHEAST-ASIA 
        GMT-OFFSET 
Please enter one of the named regions: 

Saisir "NORTH-ATLANTIC" qui envoie sur l'écran suivant où nous choisirons "EUROPE-WESTERN", il faut ensuite valider cette configuration. 

The time zone you have selected is: 
        EUROPE-WESTERN (Western European Time Zone) 
If this is not the correct time zone, you will be given the opportunity to 
select another region. 
Is this time zone correct? (y/n) [y] 

La réponse est "y", sauf si l'on a fait n'importe quoi. Il faut ensuite choisir le jeu de caractères à utiliser pour les données : 

This setting must be assigned one of the following values: 
        UTF8         ALT        KOI8 
       PC857      ARABIC          CW 
     DOSASMO     ELOT437       GREEK 
      HEBREW    HPROMAN8    IBMPC437 
    IBMPC850    IBMPC866    IS885915 
    ISO88591    ISO88592    ISO88595 
    ISO88597    ISO88599    CSGB2312 
       CSGBK    CHINESET    CHINESES 
       CHTHP     CHTBIG5      CHTEUC 
    KANJIEUC      KOREAN    SHIFTJIS 
    PCHEBREW     SLAV852        THAI 
     WARABIC     WHEBREW     WIN1250 
     WIN1252     WIN1253       WTHAI 
Please enter a valid character set [ISO88591] 
J'aime bien le "ISO885915" que je spécifie. 

The character set you have selected is: 
        IS885915 (ISO-8859-15 (Latin 9)) 
Is this the character set you want to use? (y/n) [y] 
Répondre "y" évidemment. 

Cette "page" étant déjà très longue l'installation se poursuit sur une autre page.

Installation Ingres suite. 
How many concurrent users do you want to support? [32] 
Répondre "Entrée", 32 pour des tests c'est déjà pas mal. L'initialisation proprement dite de la BDD commence alors par le LOG

The primary transaction log will now be created as an ordinary (buffered)  system file.  For information on how to create a "raw", or unbuffered,  transaction log, please refer to the Ingres Installation Guide, after  completing this setup procedure.  Creating a 1048576K byte transaction log file...  0%          25%         50%         75%         100%  ||||||||||||||||||||||||||||||||||||

Cela dure quelques instants, le temps de formater 1Go sur le disque. 
Do you wish to associate date data type to refer to ingresdate ? (y/n) [y] 
Valider le "y". 
Do you need strict compliance to the ANSI/ISO standard? (y/n) [n] 
Valider le "n" cela déclenche l'installation proprement dite, les informations présentées ont été "raccourcies" :

Ingres/ingstart  Checking host "com-ingres" for system resources required to run Ingres...  Your system has sufficient resources to run Ingres.  Starting your Ingres installation...  Starting the Name Server...  Allocating shared memory for Logging and Locking Systems...  Starting the Recovery Server...  .....    Creating DBMS System Catalogs . . .    Modifying DBMS System Catalogs . . .    Creating Database Database System Catalogs . . .    Modifying Database Database System Catalogs . . .    Creating Standard Catalog Interface . . .    Creating Front-end System Catalogs . . .  ......  This setup process can create and populate a demonstration database (demodb)  which will be used by the Ingres demonstration applications.  Do you want demodb to be created? (y/n) [y]

Répondre "y" et valider, nous disposerons ainsi d'une petite base de départ. 
..... 
la base "demo" s'installe 
...

...  executing checkpoint to disk  ending checkpoint to disk /opt/Ingres/ingres/ckp/default/demodb of 1 locations  Shutting down the Ingres server...  Ingres Intelligent DBMS setup complete.  Refer to the Ingres Installation Guide for information about  starting and using Ingres.  Press RETURN to continue:

L'initialisation de la base est terminée on passe à la suite :

Setting up Ingres Networking...  .....  If you do not need access to this Ingres server from other hosts,  then you do not need to set up Ingres Networking.  Do you want to continue this setup procedure? (y/n) [y]

Répondre "y" et valider

Installation passwords offer the following advantages over user passwords:  + Remote users do not need login accounts on the server host.  + Installation passwords are independent of host login passwords.  + Installation passwords are not transmitted over the network in any    form, thus providing greater security than user passwords.  + User identity is always preserved.  If you need more information about Ingres Networking authorization,  please refer to the Ingres Connectivity Guide.  Press RETURN to continue:

Comme d'habitude les conseils pour la suite, nous utiliserons un "Installation password". 
Do you want to create an installation password for this server? (y/n) 
Répondre "y" et valider. 
..... 
Enter installation password: 
On entre un beau mot de passe ... et on confirme, on le note pour ne pas l'oublier ! .

Installation password created.  The name server has been shut down.  Ingres Networking has been successfully set up in this installation.  You can now use the "ingstart" command to start your Ingres server.  Refer to the Ingres Installation Guide for more information about  starting and using Ingres.  Press RETURN to continue:

En pressant "Return" on arrive sur la configuration "ODBC" : 
Enter the default ODBC configuration path [ /usr/local/etc ]: 
Valider sans remords 
The default ODBC configuration path is /usr/local/etc 
Is the path information correct? (y/n) [y] 
Répondre "y" et confirmer la réponse. 
The default ODBC configuration path is /usr/local/etc 
Is the path information correct? (y/n) [y] y 
Répondre "y" sans hésiter 

Is this always a read-only driver? (y/n) [n] 
Sur une machine de production répondre "y" sans hésiter, ici on laisse "n" et on confirme ce manquement à la sécurité, la réponse ne se fait pas attendre : 
Could not open from path /usr/local/etc. 
E_CL1904_SI_CANT_OPEN   SIfopen: Can't open file 
Cannot write to specified ODBC configuration path /usr/local/etc 
Writing instead to /opt/Ingres/ingres/files/odbcinst.ini. 
Successfully wrote ODBC configuration files 
An odbcinst.ini file has been created in the directory "/opt/Ingres/ingres/files". 
You may use the utility iiodbcadmn to create and manage 
ODBC data sources. 
See the Ingres Installation Guide for more information. 
Press RETURN to continue: 

C'était bien la peine ! On copiera ce fichier plus tard. 
Le setup de "Ingres Protocol Bridge..." se passe sans question --> Return. 
Le setup de "C2 Security Auditing" se passe sans encombres, il faut valider puis "Setting up Replicator" s'affiche, il faut là aussi valider et on enchaine sur :

Setting up the Ingres Data Access Server...  This procedure will set up the following version of  Ingres Data Access Server:          II 10.0.0 (a64.lnx/122)NPTL  to run on local host:          com-ingres  Do you want to continue this setup procedure? (y/n) [y]

Répondre "y" et valider et on arrive sur la configuration data access server et de JDBC qui se passe sans autre question.

Executing Ingres JDBC driver properties generator utility...  The JDBC driver properties file 'iijdbc.properties' was created in $II_SYSTEM/ingres/files directory  Ingres Data Access Server has been successfully set up in this  installation. Please adjust the startup count and check the listen address  with the cbf utility.  Press RETURN to continue:

On presse, encore, "Entrée" pour passer à la configuration (automatique) de "Ingres Star" à suivre de l'appui sur "Entrée".

INGBUILD  - Custom Install from Distribution Medium      Distribution: /var/tmp/INSTALL/ingres-10.0.0-122-NPTL-gpl-linux-ingbuild-x     +------------------------------------------------------+-----+----------+     |               Custom Component Options               | Size| Install? |     |======================================================+=====+==========|     |Embedded SQL Precompilers                             |  23M|Ready     |     |Ingres 32bit support                                  |  42M|Ready     |     |INGRES 6.x Compatible Message Files                   |   4M|Ready     |     |Ingres Intelligent DBMS                               | 104M|Ready     |     |Ingres DTP for Tuxedo                                 |  56M|Ready     |     |Ingres Networking                                     |  66M|Ready     |     |Ingres Object Management                              | 879K|Ready     |     |Ingres ODBC Driver                                    |  65M|Ready     |     |Ingres Protocol Bridge                                | 947K|Ready     |     |Ingres C2 Security Auditing                           |  25K|Ready     |     |Ingres Replicator                                     |   2M|Ready     |     +------------------------------------------------------+-----+----------+      II_SYSTEM  : /opt/Ingres    +----------------------------------------------------------------------------+   | All installed products are now available for use.                          |   |                                                        [PRESS RETURN]      |   +----------------------------------------------------------------------------+

Le dernier appui sur "Entrée" avant l'appui sur "F3" pour sortir de l'installeur. 
Ensuite le démarrage normal du serveur Ingres est déclenché et se termine par : 

Starting the Visual DBA Remote Command Server... 
Ingres installation successfully started. 
Building the password validation program 'ingvalidpw'. 
Executable successfully installed. 

L'installation est terminée le répertoire /opt/Ingres/ingres contient : 
drwxrwxrwx  2 ingres ingres 4096 mai  3 16:57 abf 
drwxr-xr-x  2 ingres ingres 4096 mai  3 17:12 bin 
drwx------  3 ingres ingres 4096 mai  3 16:58 ckp 
drwxr-xr-x  5 ingres ingres 4096 avr 21 19:49 demo 
drwx------  3 ingres ingres 4096 mai  3 16:59 dmp 
drwxr-xr-x 16 ingres ingres 4096 mai  3 17:12 files 
drwxrwxrwx  3 ingres ingres 4096 avr 21 19:49 install 
drwx------  3 ingres ingres 4096 mai  3 16:59 jnl 
drwxr-xr-x  3 ingres ingres 4096 mai  3 16:57 lib 
drwxrwxrwx  3 ingres ingres 4096 mai  3 17:10 rep 
drwxr-xr-x 10 ingres ingres 4096 avr 21 19:49 sig 
drwxrwxr-x  3 ingres ingres 4096 avr 21 19:48 utility 
drwxr-xr-x  2 ingres ingres 4096 mai  3 17:04 vdba 
-rw-r--r--  1 ingres ingres   28 avr 21 19:28 version.rel 
Après cette installation épuisante un peu de repos avant de passer aux ajustements nécessaires à une utilisation "normale" de Ingres. 
 

Avant les quelques ajustements nécessaires à une utilisation agréable une petite explication sur les "locations". 
Les "locations" sont pour Ingres des espaces disques où peuvent être installées des bases de données ou des parties de bases de données, pour Oracle on utilise le mot "tablespace". Dans ces locations, pour chaque base, Ingres crée un répertoire portant le nom de la base. Un fichier (au sens OS) est ensuite créé pour la plupart des objets de base de données (tables, index ...). 
Toute base a, au moins, une location ou créer les bases "iidbdb" et "imadb". 
- iidbdb = "base des bases", c'est le catalogue général de Ingres. 
- imadb  = base contenant essentiellement des éléments liés à la performance. 

Variables "système" à mettre en place impérativement : 
II_SYSTEM mettre à '/opt/Ingres' 
II_INSTALLATION mettre à II 
PATH y ajouter $II_SYSTEM'/ingres/bin' et $II_SYSTEM'/ingres/lib' 
LD_LIBRARY_PATH y ajouter $II_SYSTEM'/ingres/lib' 
INGRES_TERM à mettre à "vt220" 
TERM à mettre à "vt220", on dispose alors d'un aspect et de fonctionnalités correctes dans une "konsole" pour les utilitaires "semi-graphiques" qui font le délice des amateurs. 
Un petit script à placer par exemple dans le fichier /etc/default/ingres et lancé par "source /etc/default/ingres" dans son ".bashrc" favori, un tel script est fourni en fichier attaché.

Ne pas oublier d'utiliser le "bon" type de terminal (pour moi "konsole") et forcer "TERM" et "INGRES_TERM" à "vt220". Mettre cela dans votre profil. 

Les utilitaires : 
- ingstart       sert a démarrer la base 
- ingstop       sert à stopper la base, possède quelque switchs d'usage courant "-force, -immediate, -kill" et d'autres à découvrir en tapant "ingstop -h". 
- ingstatus     permet de voir les process "Ingres" et leur état 
- cbf               très important, sert à gérer les paramètres de la base. 
- accessdb   qui permet de gérer bases, locations et utilisateurs 

Ceci dit penchons nous sur quelques scripts qui facilitent la vie :

• Script de connexion 
  Le script proposé "ingres" est en à installer dans /etc/default et est "sourcé" dans les scripts de connexion des utilisateurs (ou exécuté par . /etc/default/ingres ) 
  Ce script est par ailleurs utilisé dans les scripts de démarrage proposés. 
  Afficher ce script.
• Script de démarrage (automatique) 
  Le script proposé est en deux parties : 
  Un script coté "ingres" : start_stop à installer dans $II_SYSTEM/ingres 
  Afficher ce script. 
  Un script coté "système" : ingres_cmd à installer dans /etc/init.d avec les bons liens qui se contente d'appeler le script "ingres" 
  Afficher ce script.
• NB : les fichiers attachés doivent être renommés en supprimant de suffixe ".txt"

Compléments de configuration : 
La partie essentielle est la configuration des caches. Ingres permet de créer des bases avec différentes tailles de page (une taille est à choisir pour la valeur par défaut), on peut même avoir des tables avec des tailles différentes dans la même base. 
Ici nous prendrons des pages de 8K pour se comparer aux autres bases déjà testées "à armes égales". 

Petit tour dans "cbf" qui a la "gueule" habituelle.

CBF - Configuration-By-Forms                 Host: com-ingres            II_SYSTEM: /opt/Ingres      II_INSTALLATION: II     ┌────────────────────────┬────────────────────────┬───────────────┐     │System Component        │Configuration Name      │Startup Count  │     ├────────────────────────┼────────────────────────┼───────────────┤     │Name Server             │(default)               │1              │     │DBMS Server             │(default)               │1              │     │Star Server             │(default)               │0              │     │Locking System          │(default)               │1              │     │Logging System          │(default)               │1              │     │Transaction Log         │II_LOG_FILE             │1              │     │Transaction Log         │II_DUAL_LOG             │0              │     │Recovery Server         │(default)               │1              │     │Archiver Process        │(not configurable)      │1              │     │Remote Command          │(not configurable)      │1              │     │Security                │(default)               │1              │     └────────────────────────┴────────────────────────┴───────────────┘    Configure(1)  EditCount(2)  Duplicate(3)  ChangeLog(8)  >

On commence par mettre à zero de "Startup count" de "Star Server" en : 
- se positionnant sur la bonne ligne 
- appuyant sur "F1" pour aller dans la zone de commandes 
- Frappant "Ed" pour EditCount 
On obtient alors une zone de saisie pour la variable concernée : ┌────────────────────────────────────────────────────────────────────────────┐ 
│ Please enter the number of copies of the selected component you want to    │ 
│ execute at startup:                                                        │ 
│                                                                             └────────────────────────────────────────────────────────────────────────────┘ 
On peut alors entrer la valeur souhaitée (ici 0) suivie de "Entrée". 
Toutes les actions s'exécutent, après affichage de la liste, selon le même principe : 
- se positionnr sur l'élément à modifier 
- appuyer sur "F1" 
- frapper le début de la fonction à exécuter 
- réaliser son rêve, frapper "Entrée". 
Pour configurer le "DBMS Server" : 
- se positionner sur la ligne "DBMS Server" 
- Frapper sur "F1" 
- Frapper "co" pour "configure" 
- accéder à la liste des valeurs de configuration 
La liste peut être parcourue, un appui sur "F2" donne accès à une aide dont on sort par "F3". 
Dans cette liste on remarque la variable "connect_limit" positionnée à 32 si vous avez bien suivi la configuration 
de départ. Ce qui nous intéresse dans un premirr temps est le "default_pagesize" magnifiquement déjà positionné 
à 8K. 
On va vérifier la taille des caches, "F1" puis saisir "cache" on voit alors que les caches de 2k et 8K sont "on", on 
se positionne sur le cache "8K", un petit coup de "F1" puis configure nous amène :

┌──────────────────────────────────────────────────────────────┐     │                  DBMS Cache Parameters for 8k Buffers        │     ├────────────────────┬────────────────────┬────────────────────┤     │Name                │Value               │Units               │     ├────────────────────┼────────────────────┼────────────────────┤     │cache_guideline     │medium              │                    │     │dmf_group_size      │8                   │data pages          │     │dmf_separate        │OFF                 │boolean             │     │dmf_write_behind    │ON                  │boolean             │     │                    │                    │                    │     └────────────────────┴────────────────────┴────────────────────┘         Edit(2)  Derived(5)  Restore(6)  ChangeLog(8)  Help(PF2)  >

Un petit coup de "Derived" sur "cache_guideline" nous affiche le détail de la mémoire affectée :

┌────────────────────────────────────────────────────────────────────────┐     │                  Derived DBMS Cache Parameters for 8k                  │     ├────────────────────┬────────────────────┬────────────────────┬─────────┤     │Name                │Value               │Units               │Protected│     ├────────────────────┼────────────────────┼────────────────────┼─────────┤     │dmf_cache_size      │24000               │data pages          │no       │     │dmf_free_limit      │750                 │data pages          │no       │     │dmf_group_count     │750                 │group buffers       │no       │     │dmf_memory          │245760000           │bytes               │no       │     │dmf_modify_limit    │18000               │data pages          │no       │     │dmf_wb_end          │7200                │data pages          │no       │     └────────────────────┴────────────────────┴────────────────────┴─────────┘

J'ai "forcé" le "dmf_cache_size à 24000 et je force dmf_free_limit et dmf_group_count à 2400 pour affecter un peu plus de mémoire aux buffers. Je ne touche pas aux autres valeurs. 
Les autres valeurs fixées par défaut ne doivent pas être modifiées sans un besoin précis (machines de production) et des avis "autorisés" sous peine de manque de performance, l'utilisation de la touche "F2" permet de se documenter sur les variables. 
Après notre petit "bricolage" on sort de ces modifications par "F3" et cbf nous propose de sauvegarder nos mises à jour, nous restons positionnés sur "Yes" et l'appui sur "Entrée" sauvegarde le tout. Un appui sur "F4" nous permet de sortir définitevement de cbf. Il ne nous reste plus qu'à appliquer nos modifications : 
"ingstop -immediate"   cela rappelle le "shutdown immediate;" de Oracle ? 
Puis : 
"ingstart" 
Et c'est Parti ...

La table "habituelle" a été reconstituée à grans coups de "insert/select". Toutefois la syntaxe permettant de "décaler" vers le passé les dates "historiques" conservées en format "texte" AAAAMMJJ n'est pas évidente et forte consommatrice de CPU. 
Calcul des statistiques (optimizedb) (doc disponible) : 
optimizedb -utest -zu4096 -zv test -rxen_stat_v2 
ven mai  7 11:41:25 CEST 2010 
*** statistics for database test version: 01000 
*** table imp_xen rows:793466 pages:15561 overflow pages:15558 
*** column nbsecw of type decimal (length:10, scale:2, nullable) 
date:07-may-2010 10:41:28     unique values:801.000 
repetition factor:990.5942383     unique flag:N complete flag:0 
domain:0 histogram cells:1602 null count:0.0000000       value length:8 

*** statistics for database test version: 01000 
*** table imp_xen rows:793466 pages:15561 overflow pages:15558 
*** column nbsecr of type decimal (length:10, scale:2, nullable) 
........ 
*** statistics for database test version: 01000 
*** table xen_stat_v2 rows:13195433 pages:206183 overflow pages:206177 
*** column deltacpu of type decimal (length:10, scale:2, nullable) 
date:07-may-2010 10:43:00     unique values:61.000 
repetition factor:216318.5781250  unique flag:N complete flag:0 
domain:0 histogram cells:122 null count:0.0000000       value length:8 
ven mai  7 11:43:00 CEST 2010 
Soit un temps de 1 minute et 25 secondes. 
Création du premier index : 
sql -utest test <statv2_cre_idx.sql 
INGRES TERMINAL MONITOR Copyright 2010 Ingres Corporation 
Ingres Linux Version II 10.0.0 (a64.lnx/122)NPTL login 
Wed May  5 14:42:31 2010 
continue 
* * * * * * * * * /* SQL Startup File */ 
create index xen_stat_v2_i1 on xen_stat_v2 (DOMNOM, DATEC, HEUREC) ; 
Executing . . . 
(13147446 rows) 
continue 
Your SQL statement(s) have been committed. 
Ingres Version II 10.0.0 (a64.lnx/122)NPTL logout 
Wed May  5 14:44:30 2010 
Soit environ 1 minute 59 secondes. 
Création du second index : 
sql -utest test <statv2_cre_idx.sql 
INGRES TERMINAL MONITOR Copyright 2010 Ingres Corporation 
Ingres Linux Version II 10.0.0 (a64.lnx/122)NPTL login 
Wed May  5 14:47:34 2010 
continue 
* * * * * * * * * /* SQL Startup File */ 
create index xen_stat_v2_i2 on xen_stat_v2 (DATEC, DOMNOM, HEUREC) ; 
Executing . . . 
(13147446 rows) 
continue 
* 
Your SQL statement(s) have been committed. 
Ingres Version II 10.0.0 (a64.lnx/122)NPTL logout 
Wed May  5 14:49:50 2010 
Soit environ 2 minutes et 16 secondes. 
Comptages : 
1)    comptage "brut" 
sql -utest test <CNT_1.sql 
INGRES TERMINAL MONITOR Copyright 2010 Ingres Corporation 
Ingres Linux Version II 10.0.0 (a64.lnx/122)NPTL login 
Wed May  5 14:53:09 2010 
* * * * * * /* SQL Startup File */ 
select count(*) from xen_stat_v2 
Executing . . . 
┌─────────────┐ 
│col1         │ 
├─────────────┤ 
│     13147446│ 
└─────────────┘ 
(1 row) 
continue 
* 
Your SQL statement(s) have been committed. 
Ingres Version II 10.0.0 (a64.lnx/122)NPTL logout 
Wed May  5 14:53:25 2010 
Soit environ 16 secondes. 
2) Comptage group by 
sql -utest test <CNT_GRP_1.sql 
INGRES TERMINAL MONITOR Copyright 2010 Ingres Corporation 
Ingres Linux Version II 10.0.0 (a64.lnx/122)NPTL login 
Wed May  5 14:55:09 2010 
* * * * * * * * /* SQL Startup File */ 
select domnom,count(*) 
from xen_stat_v2 
group by domnom 
order by domnom 
Executing . . . 
┌────────────────┬─────────────┐ 
│domnom          │col2         │ 
├────────────────┼─────────────┤ 
│Domain-0        │      2512057│ 
│amdx2-2000      │       254925│ 
│amdx2-bi2003    │       255541│ 
...... 
│k2000-ora64     │      2333479│ 
│k2000-ora65     │       898205│ 
│k2000-ora66     │       862580│ 
└────────────────┴─────────────┘ 
(19 rows) 
continue 
* 
Your SQL statement(s) have been committed. 
Ingres Version II 10.0.0 (a64.lnx/122)NPTL logout 
Wed May  5 14:55:29 2010 
Soit environ 20 secondes. 
3) Comptage "group by" 
sql -utest test <CNT_GRP_2.sql                                      
INGRES TERMINAL MONITOR Copyright 2010 Ingres Corporation                        
Ingres Linux Version II 10.0.0 (a64.lnx/122)NPTL login                                            
Wed May  5 14:57:04 2010                                                                            
continue 
* * * * * * * * /* SQL Startup File */ 
select domnom,serveur,count(*) 
from xen_stat_v2 
group by domnom,serveur 
order by domnom,serveur 
Executing . . . 
┌────────────────┬────────────────┬─────────────┐ 
│domnom          │serveur         │col3         │ 
├────────────────┼────────────────┼─────────────┤ 
│Domain-0        │k2000           │      2305773│ 
...... 
│k2000-ora66     │k2000           │       862580│ 
└────────────────┴────────────────┴─────────────┘ 
(24 rows) 
continue 
* 
Your SQL statement(s) have been committed. 
Ingres Version II 10.0.0 (a64.lnx/122)NPTL logout 
Wed May  5 14:57:38 2010 
Soit environ 34 secondes. 
En bref la base de données est assez rapide et n'a pas à rougir devant les performances des autres bases existantes. La gestion des bases Ingres est très simple, beaucoup de bases utilisées dans l'industrie tournent sans aucun DBA qualifié. Si la base est bien installée (répartition et place disque) et paramétrée correctement (taille mémoire, log, espace temporaire, système de "lock") elle peut fonctionner des années quasiment sans intervention, cela n'empêche pas de sauvegarder les données ! 
Petit rappel sur l'outil "sql". 
L'outil "sql" utilisé pour les tests est l'outil "batch" de Ingres (il peut aussi être utilisé "à la main" bien sûr). 
La syntaxe SQL est assez standard, seuls quelques "trucs" peuvent gêner : 
- exécuter l'ordre SQL courant : il faut frapper "\g" pour lancer l'exécution ou "\p\g" pour lister l'ordre et l'exécuter. 
- quitter : il faut frapper "\q" 
Le prompt est marqué par un "*" exemple : 
* help\g 
Executing . . . 
Name                               Owner                              Type 
xen_stat_v2                        test                               table 
xen_stat_v2_i1                     test                               index 
xen_stat_v2_i2                     test                               index 
(3 rows) 
continue 
*\q 
Il faut le savoir ... pour la doc c'est ici. 
Rappel sur les "switchs" : 
Attention dans Ingres, les switchs de commande comme le "-u" dans "sql -utest" ne doivent pas être suivis d'un espace contrairement à beaucoup d'autres logiciels. 
 

Rappel : La machine choisie pour cette installation est une machine fraîchement installée avec une Centos 5.4 sous XEN zt munie de :

• RAM : 1,5G
• CPU : 1
• Disques :
  • 16G système
  • 16G données
  • 16G temporaire et logs

Bien que l'on puisse avec profit en performance utiliser des "raw-devices" : partitions non gérées par l'OS, j'ai choisi d'utiliser des fichiers traditionnels du file-système.

Pré-requis : 
- créer un utilisateur "sybase" 
- Créer un répertoire "/opt/sybase" avec propriétaire "sybase" 
- Créer un répertoire "SYBDAT" avec propriétaire "sybase" dans le deuxième disque monté sur /DATA 
- créer un répertoire "SYBTMP" avec propriétaire "sybase" dans le troisième disque monté sur /LOG 

Détarer l'archive dans un répertoire "propre", au premier niveau deux fichiers : 
- un fichier décrivant les limites légales du logiciel 
- setup.bin 
et un répertoire d'archives contenant le logiciel à installer. 

Installation. 
Se connecter en X et ouvrir une fenêtre terminal, dans le répertoire d'installation, un simple "./setup.bin" lance l'installeur (Java comme beaucoup) qui ouvre sa fenêtre en attendant l'appui sur la touch "Next". Tiens pas de français ? 
Après l'appui sur "Next" écran "Choose Install Folder" 
 
L'écran propose "/opt/sybase" il est sage de l'accepter et de cliquer sur "Next". 
L'écran suivant propose 3 options : "Typical", "Full" et "Custom", étant audacieux je choisis "Full", autant disposer du maximum de possibilités. 

L'écran suivant "Software license type selection" : 

N'ayant pas de license, nous choisirons la version "Free developper". 

Puis il faut définir son pays pour lire le contrat de license dans sa langue ... non, une seule possibilité "All regions" et c'est en anglais ... J'aime bien les questions à choix simple ! Je clique "I agree" (ça veut dire quoi ?) et "Next". 

Un pétit écran de récap : 
  
il me semble que tout est là, même "Sybase Central" que l'on avait parfois du mal à trouver et les drivers JDBC et ODBC. L'installation complète consomme un peu plus de 1,1Go. 
Il ne reste plus qu'à cliquer sur "Install", ce que je m'empresse de faire, l'installation du logiciel démarre avec le petit baratin publicitaire défilant qui nous occupe pendant l'installation. C'est vachement à la mode. 
La fin de l'installation arrive et on nous propose de "retenir" ou non les mots de passe. N'ayant pas besoin de sécurité pour des tests je choisis "Enable" par paresse et clique sur "Next". 
On arrive maintenant aux points importants : la configuration des différents serveurs constituant Sybase : 
 
Il vaut mieux les configurer tous dès le début, cela sera toujours cela de fait, on entre ensuite dans un écran spécifique à chaque process serveur. 
Ecran "Configure New Adaptative Server" 
 
nous propose de nombreux paramètres : 
- Nom , celui préparé me va ... 
- Port number : 5000 ne me gêne pas 
- Application type : je garde "Mixed" car je désire faire plein de choses 
- Page size : Les anciennes pages de 2K étaient un peu trop petites, je vais prendre 8K comme la plupart des bases Oracle. 
- Fichiers de log, je les mets tous dans /opt/sybase/log 
- Devices : c'est comme cela que Sybase nomme les fichiers de données, un certain nombre de "devices" sont obligatoires, il s'agit de leur donner un emplacement physique et une taille. Les tailles proposées par Sybase sont en général un peu "justes" pour des machines d'exploitation, mais ici cela devrait nous suffire. Ces espaces obligatoires sont analogues aux tablespaces "System", "TEMP" ... pour Oracle. 
- Master device : /DATA/SYBDAT/master.dat 
- Master device size : 128 
- Master database size : 64 
- System procedure device : /DATA/SYBDAT/sysprocs.dat 
- System procedure device size : 160 
- System procedure database sise : 160 
- System Device : /DATA/SYBDAT/sybsysdb.dat 
- Sstem device size : 32 
- System database size : 32 
- Tempdb device : je le positionne sur un autre disque /LOG/SYBTMP/tempdbdev.dat 
- Tempdb device size : 256 
- Tempdb database size : 256 
- Enable PCI : je le laisse à "no" 
- Optimize ASE configuration : "yes" 
- available physical memory pour ASE : 1024             
- available CPU for ASE : 1 (limité à 1 pour la version developpeur). 
Un petit "Next" et juste un Warning car j'ai choisi des pages de 8K ce qui est incompatible avec le rechargement de bases "anciennes" qui avaient, en principe, des pages de 2K et nous voilà sur le paramétrage du "Backup Server" : 
- Name : je le laisse 
- Port number : pourquoi pas 5001 
- error log : je le laisse 
"Next" nous emporte vers le "Monitor Server" 
- Nom : je le laisse 
- Port Number : 5002 n'est pas pire qu'un autre 
- Error log : je le laisse 
"Next" conduit vers le paramétrage du "Xp Server" avec son port 5003 et son error log, un autre "Next" nous donne accès au paramétrage du "Job scheduler". Tiens un port number à 4900 ? Pour le reste les valeurs par défaut sont convenables. Après le "Next" suivant nous arrivons au "saint des saints" le superuser "sa" sans possibilité de toucher au mot de passe puisque on a choisi "Enable" pour la gestion des mots de passe . 
Et maintenant les "Web Services" avec un paquet de ports et de mots de passe ...on laisse les valeurs par défaut (sauf pour les mots de passe !). 
Encore un "Next" pour le "Self Discovery Service Adaptor" que je choisis de configurer  le "UDP Adaptor" et je refuse le "JNI" comme j'en ai le droit ! 
Encore "Next" pour arriver sur "Security modules" où je ne coche que les deux premiers. Le "Next" nous permet, enfin, d'arriver à la fin de la configuration et le récap nous permet de revoir un peu tous nos choix avant de cliquer un autre "Next" qui déclenche la création de la base de données et l'affichage des logs des scripts de création et c'est la fin de ce roman passionnant 
 
Cette partie est assez longue car Sybase crée les fichiers de data et les remplit intégralement : ce qui est pris n'est plus à prendre, la place prise est bien réservée. 
Avant de pouvoir s'en servir allons voir un peu le répertoire d'installation qui comporte plein de répertoires ... avec de nombreux sous répertoires "bin" qu'il va falloir ajouter à notre "PATH" avant de pouvoir faire mumuse. 
Heureusement on peut trouver dans "/opt/sybase" le merveilleux script "SYBASE.sh" qui fait çà très bien ". /opt/sybase/SYBASE.sh" résout ce problème pour nous. 
Dans un prochain épisode le lancement des premières commandes, vous apprendrez à mettre des "go" partout dans "isql". 
Pour vous mettre l'eau à la bouche une petite image de l'outil de gestion "Sybase Central" 
 
que l'on peut lancer par : 
./shared/sybcentral600/scjview.sh 
puis se connecter (clic droit sur "Adaptative Server Enterprise" + "Connect", pas de mot de passe (il est stocké, rappelez vous le "Enable". Ici beaucoup de choses se commandent par le "clic droit" et les menus associés. 
Vous avez alors accès au module central de gestion de Sybase qui vous permet même de gérer plusieurs serveurs simultanément, ce module est une véritable "tour de contrôle".

Après l'installation il reste toujours quelques "bricoles" à faire pour avoir un système plus commode et agréable à utiliser.Modifier le .profile (ou le .bashrc) du user de test pour y insérer l'appel à "/opt/sybase/SYBASE.sh" afin de pouvoir travailler sans penser sans arrêt à frapper : 
. /opt/sybase/SYBASE.sh 
Un certain nombre d'ajustements sont indispensables, par exemple "isql" n'aime pas ma locale "fr_FR@euro" (variable LANG), il faudra "forcer" la valeur de LANG à une valeur compatible avec celles existant dans le fichier "/opt/sybase/locales/locales.dat". 
Mettre en place la langue "français". 
Il faut passer par l'utilitaire "sqlloc" (/opt/sybase/ASE-15_0/bin/sqlloc) qui  permet de réaliser cet exploit dans un mode semi-graphique 
  
Ne pas oublier de modifier le "default character set". 
Ma machine utilise les "locales" fr_FR.UTF-8 il m'a fallu pour terminer ajouter une ligne descriptive dans le fichier "/opt/sybase/locales/locales.dat" : 
locale = fr_FR.UTF-8, french, iso_1 
est à insérer dans le paragraphe [linux] après "fr_FR.850 ...". Il reste quelques "bricoles" au niveau des caractères accentués dans les messages, mais les caractères stockés dans la base ressortent correctement.. 
Ces petites mises au point permettent d'ajouter au script "SYBASE.sh" les lignes suivantes : 
LANG=fr_FR.UTF-8 
SYB=/opt/sybase 
export SYB 
On peut ensuite oeuvrer tranquilles sans messages, ou refus, intempestifs lors du lancement des utilitaires. 
Avant de faire quoi que ce soit d'autre il faut : 
- créer un "login" pour pouvoir réaliser des tests 
- créer deux "devices" pour pouvoir créer une base de données de test car il est très fortement déconseillé de créer des objets dans les espaces "système". 
 Device numéro 1 pour les "data' 
 Device numéro 2 pour le "log" 
- créer une base de données pour les tests 
Les scripts fournis peuvent être lancés par : 
cd le_repertoire_de_stockage_des_scripts 
isql -Usa -SCOMSYB15 -D master -i le_nom_du_script 
A la demande de password frapper "Entrée" tout simplement. 
Les scripts fournis ici doivent être personnalisés.

• Script de création du device "DATA" :

disk init name='MABASE', physname='/DATA/SYBDAT/MABASE.dat', vdevno=5, 
size=524288, cntrltype=0, dsync=false, directio=true, skip_alloc= true 
go

• Script de création du device "LOG" :

disk init name='MONLOG', physname='/LOG/SYBTMP/MONLOG.dat', vdevno=6, size=262144, 
cntrltype=0, dsync=false, directio=true, skip_alloc= true 
go

• Script de création de la base de données "MABASE" : 
  create database MABASE  on MABASE = 1024 log on MONLOG = 512 with DURABILITY=FULL
• Script de création du user "test" :

use master 
go 
exec sp_addlogin 'test', 'testpw', @defdb = 'MABASE', @deflanguage = 'french', 
@auth_mech = 'ANY', @fullname='User pour tests' 
go

• Donner la propriété de la base au user "test"

USE MABASE 
go 
exec sp_changedbowner 'test', true 
go 

Quelques "trucs" : 
- Démarrer le serveur Sybase : 
cd /opt/sybase 
nohup ./ASE-15_0/install/RUN_COMSYB15 
On peut lancer de la même façon le "Backup server" (RUN_COMSYB15_BS) ou le "Monitor Server" (RUN_COMSYB15_MS).  
- Stopper le serveur Sybase 
isql -U user_stop -S COMSYB15 -P mot_de_passe <<!FINI 
shutdown SYB_BACKUP 
go 
shutdown 
go 
exit 
!FINI 
Les scripts nécessaires sont fournis en pièces attachées (root : "sybase" à installer dans /etc/init.d, sybase "start_stop_sybase" à installer dans /home/sybase/bini en enlevant le suffixe ".txt" des fichiers, sans oublier le "chown +x ..." qui va bien).

• Se connecter avec "isql" :

isql -Usa -P -Snom_serveur -D nom_de_la_base 

Installation des outils nécessaires pour accéder à la base par JDBC. 
Il est nécessaire d'installer un ensemble de tables dans la base "master" afin que la connexion JDBC soit possible sur la base, il existe deux versions de "JConnect" dans les répertoires de Sybase 15 : JConnect 6 et JConnect 7. Ici j'ai décidé d'installer la version 7. 
Ill faut aller dans le répertoire "/opt/sybase/jConnect-7_0/sp" et de lancer le script qui va avec la version de la base, ici le script "sql_server15.0.sql" à lancer par : 
isql -U sa -S COMSYB15 -i sql_server15.0.sql -o MONLOG.LOG 
(répondre "Entrée" à la demande de mot de passe). Il est ensuite possible de se connecter en JDBC aux différentes bases de données contenues dans cette instance.

Le mini test a été réalisé selon la procédure décrite ici. 
Calcul de la différence de dates : 
set statistics time on 
go 
select min(convert(datetime,DATEC)) as MINI,  
       max(convert(datetime,DATEC)) as MAXI,  
       datediff(day,min(convert(datetime,DATEC)),max(convert(datetime,DATEC))) as DIFF, 
       count(*) as CTR  
from xen_stat_v2 
go 
Génération de la table table temporaire : 
set statistics time on 
go 
select  convert( char(10),dateadd(day, DELTA ,convert(datetime,DATEC)),112) as DATEC,  HEUREC,SERVEUR,DOMNOM,DELTACPU,DELTARX,DELTATX,CPUPCT,NBSECR,NBSECW 
into toto 
from xen_stat_v2 
go 
Insertion des rangs calculés : 
insert into xen_statv2 select * from toto 
go 
Après quelques itérations on arrive au volume voulu :  
1> select count(*) from xen_stat_v2 
2> go 
Temps d'analyse et de compilation 0. 
Adaptive Server cpu time: 0 ms. 
Temps d'analyse et de compilation 0. 
Adaptive Server cpu time: 0 ms. 
-----------  
    13174976   
Temps d'execution 18. 
Adaptive Server cpu time: 1800 ms.  Adaptive Server elapsed time: 22970 ms. 
Soit un peu moins de 23 secondes. 

La taille atteinte par le "LOG" est assez conséquente, à cause des ordres insert et a nécessité la mise en place d'un log de 1536Mo pour que le dernier ordre "insert" atteigne la fin,. On a quand même inséré plus de 6,5 millions de lignes. 
Le volume occupé par la table et ses deux index est d'environ 2200Mo. 

Résultats du mini test.

• Test 1 création de deux index :

Adaptive Server cpu time: 287300 ms.  Adaptive Server elapsed time: 417160 ms. 
Adaptive Server cpu time: 240100 ms.  Adaptive Server elapsed time: 400633 ms. 
Soit un total de #818 secondes ou 13'38 ".

• Test 2 re-calcul des statistiques :

update statistics MABASE.dbo.xen_stat_v2 
go 
Adaptive Server cpu time: 0 ms.  Adaptive Server elapsed time: 165280 ms. 
Le CPU est à >98% durant tout le calcul qui dure 1'45".

• Test 3 quelques "select" :

a) select DOMNOM,count(*) from xen_stat_v2 group by DOMNOM order by DOMNOM 
go 
- passe 1 : Adaptive Server cpu time: 0 ms.  Adaptive Server elapsed time: 35983 ms 
- passe 2 : Adaptive Server cpu time: 0 ms.  Adaptive Server elapsed time: 34093 ms. 
Soit #35 secondes 

b) select DOMNOM,count(*) from xen_stat_v2 group by DOMNOM order by DOMNOM 
go 
- passe 1 : Adaptive Server cpu time: 28900 ms.  Adaptive Server elapsed time: 88873 ms. 
- passe 2 : Adaptive Server cpu time: 0 ms.  Adaptive Server elapsed time: 81843 ms. 
Soit #85 secondes 
Sur ces deux tests le CPU monte à plus de 98%

Il existe un dépôt pour Debian 11 géré directement par Clickhouse, l'installation sera donc simple. 
Afin de ne pas risquer de "polluer" une machine existante j'ai décidé d'installer une machine virtuelle KVM munie d'un "gros" disque car j'avais dans l'idée d'y charger une grosse table, (justement mes archives de Ntopng) qui fait plus de 600 millions de rangs (6 ans d'archives). 
La machine comportait au démarrage : 

CPU       : 4 VCPU 
Disque   : #400Go 
RAM      = 6 Go 

Ajouter la clef GPG de clickhouse (en root) : 

apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv 8919F6BD2B48D754 

Ajouter un fichier "clickhouse.list" dans /etc/apt/sources.list.d contenant : 
deb https://packages.clickhouse.com/deb stable main 

Il suffira alors d'un "apt update" et tout sera prêt pour lancer l'installation : 
apt install --force-overwrite clickhouse-client clickhouse clickhouse-common clickhouse-common-static clickhouse-server clickhouse-tools 

Note : J'ai été obligé d'utiliser --forcce-overwrite à cause du paquet clickhouse-tools. 
L'installation s'est bien passée et tout a fonctionné rapidement, le fichier "service" pour systemd est bien sûr disponible. Le serveur dispose de plusieurs ports dédiés à : 
Port natif
Port Mysql like
Port Postgresql like 

Il est ainsi possible d'utiliser une syntaxe connue telle de Mysql/MariaDB ou Postgresql. 
Je me suis concentré sur la syntaxe Mysql que je connais mieux que celle de Postgres. J'ai donc pu créer rapidement un utilisateur dédié, les bases de données et les tables dont j'avais besoin. 
On peut même créer une base "virtuelle" reliée directement à une base Mysql/MariaDB.
Mon seul problème a été la taille de RAM allouée à cette machine, les 6Go se sont vite avérés insuffisants, le chargement des données ne dépassait pas 100 millions de rangs ... 
Après quelques tâtonnements j'ai vu qu'il ne fallait pas être avare avec la RAM pour obtenir un fonctionnement sans plantage. Lors des chargements de données des "Segmentation fault" et lors de l'exécution d'ordres SQL des plantages pour "(MEMORY_LIMIT_EXCEEDED)".
j'ai donc, par paliers, augmenté la RAM jusqu'à un fonctionnement impeccable obtenu dès 24Go que j'ai un peu poussé à 28Go pour pouvoir charger sans problèmes ma "grosse" table.

28 Go cela fait déjà une jolie VM heureusement que la machine "support" dispose de 64Go !

J'ai lu quelques doc, mais ce qui m'a intéressé c'est la compatibilité avec la syntaxe Mysql. 
Pour l'utiliser pleinement il suffit de connecter son client mysql favori (a installer si besoin) sur le port 9004. Je me suis alors retrouvé dans un environnement "connu" qui m'a permis de faire les premières manips. 
Créer une nouvelle base de données : "CREATE DATABASE toto;" 
Aller voir dans cette base : "use toto;" 
Créer un utilisateur avec les droits d'administration :

create user administrateur identified by 'le_mot_de_passe_qui_tue'; 
grant all on *.* to administrateur;

Par contre pour créer une table il faut se plier à la syntaxe "locale", les types ne sont pas tout à fait les mêmes et il faut un peu "ruser". 
Le "CREATE TABLE" n'offre aucun mystère. 
Pour le "ENGINE" à utiliser il y en a plusieurs j'ai utilisé le plus "simple" : "MergeTree" avec les majuscules pour lequel il faut préciser un "order by xxx" et éventuellement un partitionnement. 
Je n'ai pas testé le partitionnement, pas encore ... 
Pour les champs numériques : int16,int32,int64; UInt16, UInt32 ... 
Pour les champs date : Datetime fonctionne bien 
Pour les champs alphanumériques : String. 
Ne pas oublier de préciser "Nullable(type)" pour les champs qui peuvent prendre la valeur NULL.

En ce qui concerne les fonctions (par exemple celles sur les dates) la syntaxe est, malheureusement, différente de celle proposée par Mysql/MariaDB.

Une fonction particulièrement intéressante pour communiquer avec des bases Mysql/MariaDB est la possibilité de création de bases "distantes". Cette possibilité est analogue aux fonctionnalités accessibles à l'aide du module "federated" de MariaDB. 
Il devient ainsi possible de récupérer directement dans Clickhouse des données d'une base extérieure. C'est cette fonctionnalité que j'ai utilisée pour importer la grosse table destinée aux essais. 
La syntaxe est très simple (connexion sur le port "Mysql" : 
CREATE TABLE toto as select * from base_distante.table.

Le chargement de la table va être possible en utilisant des ordres SQL (syntaxe Mysql) avec :

• Création d'une base distante
• Création d'une table locale
• Insertion dans la table locale des rangs de la table distante.

La création d'une base distante possède une syntaxe proche de celle utilisée par les tables "federated" :

CREATE DATABASE base_distante 
  ENGINE = MySQL('IP:3306', 
  'nom_base_distante', 
  'user distant', 'mot_de_passe_distant') 
  SETTINGS read_write_timeout=10000, connect_timeout=10;

Il est alors possible de faire un "SELECT" sur la base distante. 
La recopie d'une table devient :

insert into base_locale.nom_table 
    select * from base_distante.nom_table 
    where idx > 0 ;

Pour une table volumineuse le temps peut être assez important. Dans mon cas le transfert entre la MV et la machine physique atteignait 130Mo/seconde et le temps total de chargement de plus de 500 millions de rangs a duré un peu moins d'une heure. 
Dans la base MariaDB cette table utilise environ 300GO, Dans la base Clickhouse le volume est d'un peu plus de 140GO. Visiblement la compression semble bien fonctionner. 
 

Pour ce premier test sur cette "grosse" table j'ai repris un ordre SQL dont je m'étais servi pour repérer les plus gros scanneurs. Je rappelle que cette table contient des données enregistrées par Ntopng sur ma machine "pont" vers Internet. Et les scans de port sont extrêmement courants, chaque machine connectée à Internet en subit plusieurs centaines par jour. 
Cet ordre examine toutes les données d'entrée qui n'ont donné lieu à aucune réponse (port fermé ou IP bloquée par le firewall) la sortie est limitée aux 20 plus "gros scanneurs". 
select IP_SRC_ADDR as IP_V4,count(*) as CTR, 
    count(distinct L4_DST_PORT) as NBPORTS, 
    min(FIRST_SWITCHED) as DEBUT,max(LAST_SWITCHED) as FIN 
from flowsv4 
where IP_SRC_ADDR not between '192.158.1.1' and '192.168.3.255' 
  and OUT_BYTES = 0 
group by 1 
order by 2 desc 
limit 20;

Et voici les résulats :

1) Pour Clickhouse :

┌─IP_V4───────────┬────CTR─┬─NBPORTS─┬───────────────DEBUT─┬─────────────────FIN─┐  │ 0.0.0.0         │ 133379 │       2 │ 2016-08-02 21:20:07 │ 2022-08-27 00:13:06 │  │ 45.143.220.101  │  80996 │   64408 │ 2020-03-22 22:19:49 │ 2020-04-17 02:14:24 │  │ 92.63.197.23    │  65295 │   65295 │ 2021-09-17 22:38:39 │ 2021-09-24 05:22:53 │  │ 45.143.200.34   │  46036 │   25699 │ 2021-04-09 23:14:37 │ 2022-02-10 21:25:53 │  │ 173.231.60.195  │  44355 │       2 │ 2021-12-09 06:09:06 │ 2022-03-09 13:07:02 │  │ 92.63.197.108   │  38179 │   32243 │ 2021-08-22 13:29:04 │ 2021-11-25 04:31:09 │  │ 146.88.240.4    │  37229 │      63 │ 2019-04-11 04:59:05 │ 2022-08-26 06:02:19 │  │ 92.63.197.112   │  36060 │   32081 │ 2021-08-22 13:27:51 │ 2021-11-25 10:31:34 │  │ 92.63.197.110   │  35671 │   29999 │ 2021-08-22 13:29:24 │ 2022-07-10 12:52:55 │  │ 212.70.149.69   │  35319 │       1 │ 2020-10-19 04:34:22 │ 2020-12-18 12:52:19 │  │ 10.128.175.2    │  33844 │       1 │ 2018-06-02 05:03:16 │ 2020-07-01 12:23:01 │  │ 176.113.115.246 │  33618 │   32906 │ 2020-01-29 09:24:25 │ 2020-05-09 20:52:01 │  │ 212.70.149.68   │  32400 │       1 │ 2020-08-21 04:34:36 │ 2020-10-16 20:38:35 │  │ 185.176.27.2    │  32322 │   22565 │ 2018-12-06 17:13:49 │ 2020-08-12 23:43:46 │  │ 92.154.95.236   │  31960 │    1092 │ 2017-12-07 23:05:08 │ 2021-12-13 13:30:54 │  │ 185.156.73.91   │  31756 │   20609 │ 2020-10-04 03:09:37 │ 2022-08-26 23:44:13 │  │ 185.156.73.107  │  31625 │   25338 │ 2021-06-19 09:04:14 │ 2022-02-13 12:30:53 │  │ 195.54.166.93   │  31183 │   29850 │ 2020-01-15 21:46:51 │ 2020-02-17 05:38:35 │  │ 51.68.126.248   │  30228 │       4 │ 2020-02-25 22:40:19 │ 2020-04-06 01:24:36 │  │ 92.63.197.105   │  29300 │   16042 │ 2021-05-16 17:24:56 │ 2021-12-07 23:21:30 │  └─────────────────┴────────┴─────────┴─────────────────────┴─────────────────────┘  20 rows in set. Elapsed: 6.138 sec. Processed 488.52 million rows, 18.98 GB (79.59 million rows/s., 3.09 GB/s.)

 2) Pour MariaDB : 

+-----------------+--------+---------+---------------------+---------------------+  | IP_V4           | CTR    | NBPORTS | DEBUT               | FIN                 |  +-----------------+--------+---------+---------------------+---------------------+  | 0.0.0.0         | 133379 |       2 | 2016-08-02 21:20:07 | 2022-08-27 00:13:06 |  | 45.143.220.101  |  80996 |   64408 | 2020-03-22 22:19:49 | 2020-04-17 02:14:24 |  | 92.63.197.23    |  65295 |   65295 | 2021-09-17 22:38:39 | 2021-09-24 05:22:53 |  | 45.143.200.34   |  46036 |   25699 | 2021-04-09 23:14:37 | 2022-02-10 21:25:53 |  | 173.231.60.195  |  44355 |       2 | 2021-12-09 06:09:06 | 2022-03-09 13:07:02 |  | 92.63.197.108   |  38179 |   32243 | 2021-08-22 13:29:04 | 2021-11-25 04:31:09 |  | 146.88.240.4    |  37229 |      63 | 2019-04-11 04:59:05 | 2022-08-26 06:02:19 |  | 92.63.197.112   |  36060 |   32081 | 2021-08-22 13:27:51 | 2021-11-25 10:31:34 |  | 92.63.197.110   |  35671 |   29999 | 2021-08-22 13:29:24 | 2022-07-10 12:52:55 |  | 212.70.149.69   |  35319 |       1 | 2020-10-19 04:34:22 | 2020-12-18 12:52:19 |  | 10.128.175.2    |  33844 |       1 | 2018-06-02 05:03:16 | 2020-07-01 12:23:01 |  | 176.113.115.246 |  33618 |   32906 | 2020-01-29 09:24:25 | 2020-05-09 20:52:01 |  | 212.70.149.68   |  32400 |       1 | 2020-08-21 04:34:36 | 2020-10-16 20:38:35 |  | 185.176.27.2    |  32322 |   22565 | 2018-12-06 17:13:49 | 2020-08-12 23:43:46 |  | 92.154.95.236   |  31960 |    1092 | 2017-12-07 23:05:08 | 2021-12-13 13:30:54 |  | 185.156.73.91   |  31756 |   20609 | 2020-10-04 03:09:37 | 2022-08-26 23:44:13 |  | 185.156.73.107  |  31625 |   25338 | 2021-06-19 09:04:14 | 2022-02-13 12:30:53 |  | 195.54.166.93   |  31183 |   29850 | 2020-01-15 21:46:51 | 2020-02-17 05:38:35 |  | 51.68.126.248   |  30228 |       4 | 2020-02-25 22:40:19 | 2020-04-06 01:24:36 |  | 92.63.197.105   |  29300 |   16042 | 2021-05-16 17:24:56 | 2021-12-07 23:21:30 |  +-----------------+--------+---------+---------------------+---------------------+  20 rows in set (12 min 56,412 sec)

3) Comparaison.

Les résultats sont identiques ce qui est très bien ! 
La comparaison est impressionnante : 6 secondes au lieu de 776 soit quasiment 130 fois plus vite !

On voit aussi que l'adresse IP 45.143.220.101 a scanné quasiment l'intégralité des ports existants en un peu moins d'un mois (scan "lent") ou que l'IP 173.231.60.195 ne scanne que deux ports mais a effectué plus de 40000 connexions en un peu moins d'un an, cela fait quand même plus de 100 par jour.

Cet ordre SQL devait me permettre de voir s'il y avait des trous de numérotation dans les valeurs du champ "idx". 
Il m'a valu de nombreux ennuis avant que la mémoire ne soir "gonflée" avec de méchants messages : 
Received exception from server (version 22.8.2): 
Code: 241. DB::Exception: Received from localhost:9000. DB::Exception: Memory limit (total) exceeded: would use 3.73 GiB (attempt to allocate chunk of 537537181 bytes), maximum: 3.48 GiB. OvercommitTracker decision: Query was selected to stop by OvercommitTracker.: While executing AggregatingTransform. (MEMORY_LIMIT_EXCEEDED)

L'ordre est très simple : 
select min(idx),max(idx), count(distinct idx) from flowsv4;

Dès que la RAM a été "suffisante" (plus de 24Go de RAM) ces messages ont disparu et les résultats sont là et bien là.

1) Résultats Clickhouse.

┌─min(idx)─┬──max(idx)─┬─uniqExact(idx)─┐ 
│        1 │ 488553902 │      488521496 │ 
└──────────┴───────────┴────────────────┘ 
1 row in set. Elapsed: 27.822 sec. Processed 488.52 million rows, 3.91 GB (17.56 million rows/s., 140.47 MB/s.)

2) Résultats MariaDB.

+----------+-----------+---------------------+ 
| min(idx) | max(idx)  | count(distinct idx) | 
+----------+-----------+---------------------+ 
|        1 | 488553902 |           488521496 | 
+----------+-----------+---------------------+ 
1 row in set (5 min 42,522 sec)

3) Résultat final. 
27 secondes contre 342 soit environ 13 fois plus vite.

Le but de cet ordre SQL est de trouver les adresses IP qui ont contacté sans succès la machine, ceci est identifié par une valeur 0 dans le champ OUT_BYTES et qui ont "tenté" des connexions sur au moins 10 ports différents. Ceci peut arriver si la demande a été bloquée par le firewall (drop). 
L'ordre SQL est légèrement différent car les fonctions de gestion des dates ont des syntaxes légèrement différentes.

select IP_SRC_ADDR as SRC,IP_DST_ADDR as DST,      count(distinct L4_DST_PORT) as NPORT  from flowsv4  -- mariadb    where FIRST_SWITCHED > DATE_SUB(now(), interval 20 day)  -- clickhouse where FIRST_SWITCHED > DATE_SUB(DAY,20,now())  and IP_SRC_ADDR not between '192.168.1.1'                  and '192.168.3.255'  and L4_DST_PORT < 15000  group by  SRC,DST  having NPORT > 10  order by SRC;

La différence n'est pas énorme mais il faut y faire attention ... 
Et maintenant passons aux faits.

1) Clickhouse.

┌─SRC─────────────┬─DST─────────┬─NPORT─┐  │ 103.138.109.220 │ 192.168.1.2 │   105 │  │ 103.56.61.144   │ 192.168.1.2 │    12 │  │ 104.156.155.13  │ 192.168.1.2 │  1216 │  │ 104.168.53.114  │ 192.168.1.2 │    23 │     ......  │ 94.232.45.241   │ 192.168.1.2 │    68 │  │ 95.161.131.235  │ 192.168.1.2 │    19 │  └─────────────────┴─────────────┴───────┘  377 rows in set. Elapsed: 0.120 sec. Processed 7.92 million rows, 395.57 MB (66.10 million rows/s., 3.30 GB/s.)

2) MariaDB.

+-----------------+-------------+-------+  | SRC             | DST         | NPORT |  +-----------------+-------------+-------+  | 103.138.109.220 | 192.168.1.2 |   105 |  | 103.56.61.144   | 192.168.1.2 |    12 |  | 104.156.155.13  | 192.168.1.2 |  1216 |  | 104.168.53.114  | 192.168.1.2 |    23 |      ......  | 94.232.45.241   | 192.168.1.2 |    68 |  | 95.161.131.235  | 192.168.1.2 |    19 |  +-----------------+-------------+-------+  377 rows in set (19,137 sec)

3) Comparaison. 
Le rapport entre 19 secondes et 0.12 est frappant, Clickhouse est 158 fois plus rapide.

Cet ordre SQL est très simple et le résultat est plus que spectaculaire, le passage "Clickhouse" a été réalisé avec l'interface compatible Mysql.

L'ordre est très simple :
select count(*),max(LAST_SWITCHED),max(FIRST_SWITCHED) from flowsv4;

1) Résultats Clickhouse.

+-----------+---------------------+---------------------+
| count()   | max(LAST_SWITCHED)  | max(FIRST_SWITCHED) |
+-----------+---------------------+---------------------+
| 521129534 | 2022-11-17 23:35:18 | 2022-11-17 23:35:18 |
+-----------+---------------------+---------------------+
1 row in set (1.863 sec)

2) Résultats MariaDB.

+-----------+--------------------+---------------------+
| count(*)  | max(LAST_SWITCHED) | max(FIRST_SWITCHED) |
+-----------+--------------------+---------------------+
| 521129338 |         1668724485 |          1668724485 |
+-----------+--------------------+---------------------+
1 row in set (13 min 40,620 sec)

3) Résultat final.  
1,85 secondes pour Clickhouse contre 820 pour MariaDB soit environ 440 fois plus vite !

J'ai voulu faire un dernier test qui représente un gros travail toujours à partir de la même table qui atteint maintenant 542 975 185 rangs ce qui représente un bon test.

J'ai voulu chercher les ports TCP les plus attaqués en sélectionnant les connections TCP qui ont fourni un retour de 0 octets, le SQL est donc :

select L4_DST_PORT,count(*) CTR
from local_ntopng.flowsv4
where OUT_BYTES = 0 -- aucune réponse
  and PROTOCOL = 6  -- (TCP)
group by 1
order by CTR DESC
limit 30;

Le résultat est, là aussi, stupéfiant :

Pour Clickhouse les 30 rangs sont retournés en moins de deux secondes (1;813 exactement et en 14 minutes et 18 secondes soit 858 secondes, le rapport de vitesse est proprement stupéfiant ... Clickhouse va 473 fois plus vite que MariaDB.

Rappels :

• Les tests sont faits sur la même machine et les données sont sur les deux disques Samsung SSD 860 de 2To montés en miroir.
• Les résultats présentent de très légères différences car la recopie des données depuis la source n'est pas "synchrone", il y a donc un (tout petit) décalage possible.

Voir les résultats ci-dessous.

CLICKHOUSE 1.813 sec		MariaDB 14 min 18 se
443	1434014	443	1434014
80	1059068	80	1059067
23	749049	23	749049
445	253752	445	253752
22	229300	22	229300
465	184397	465	184397
6379	163679	6379	163679
8080	143206	8080	143205
1433	116601	1433	116600
81	85489	81	85489
3389	85076	3389	85075
5222	77222	5222	77222
25	74815	25	74815
2323	65065	2323	65065
995	62827	995	62827

Il est possible, avec un client Mysql/MariaDB standard, de se connecter à Clickhouse (port 9004) et d'utiliser des ordres SQL avec la syntaxe propre à Mysql/MariaDB. 
Il existe aussi une possibilité d'utiliser un client Postgresl en se connectant à Clickhouse (port 9005), je n'ai pas encore testé cette entrée.

On peut par exemple créer un utilisateur avec : 
create user lechef identified by 'le_beau_password'; 
grant all on *.* to lechef; 
Ce que je préfère nettement au "bidouillage" de fichiers XML.

Par exemple pour charger ma "grosse" table depuis une base MariaDB dans Clickhouse (dans une machine virtuelle) j'ai créé dans Clickhouse un "serveur" connecté à la base située sur la machine "physique" à l'aide d'un ordre "simple" (du même style que pour l'option "federatedx" disponible dans MariaDB :

CREATE DATABASE test_maria 
  ENGINE = MySQL('192.168.2.7:3306', 
  'local_ntopng', 
  'test', 'test') 
  SETTINGS read_write_timeout=10000, connect_timeout=10;

Dans la base "physique" la table est au standard Mysql et on peut donc y accéder à travers cette base "test_maria" par cette sorte de "dblink". L'ordre de chargement des données est très simple :

insert into local_ntopng.flowsv4 
    select * from test_maria.flowsv4;

select min(idx),max(idx),count(distinct idx) from local_ntopng.flowsv4;

Le temps d'exécution est assez important car il faut passer par :

• Mariadb sur la machine physique
• Le réseau entre les deux machines
• Et enfin Clickhouse à travers le fameux dblink.

Comme déjà remarqué la consommation d'IO disques de Clickhouse est très irrégulière et a oscillé entre 0 et 240Mo/seconde. Le lien réseau est toujours resté au dessus de 100MO/sec avec des pointes à près de 200MO/sec (c'est en local sur la même machine physique). 
Les résultats : 
Query OK, 505751818 rows affected (36 min 54.958 sec) 
+----------+-----------+----------------+ 
| min(idx) | max(idx)  | uniqExact(idx) | 
+----------+-----------+----------------+ 
|        1 | 505785066 |      505751818 | 
+----------+-----------+----------------+ 
1 row in set (31.284 sec)

Ce qui n'est pas mauvais et simple pour ceux qui connaissent un peu le SQL.

insert into table1 select * from table2;

Elapsed: 817.372 sec. Processed 524.04 million rows, 200.88 GB 
(641.13 thousand rows/s., 245.76 MB/s.)

CPU > 90 .. 130%
IO  60 .. 370 Mo/seconde la moitié du temps en lecture, l'autre moitié en écriture.

- sudo touch /var/lib/clickhouse/flags/force_drop_table
- sudo chmod 666 /var/lib/clickhouse/flags/force_drop_table

"drop ancienne_table" 

insert into table1 select * from table2;

Elapsed: 817.372 sec. Processed 524.04 million rows, 200.88 GB 
(641.13 thousand rows/s., 245.76 MB/s.)

CPU de 90 .. 130%
IO  60 .. 370 Mo/seconde la moitié du temps en lecture, l'autre moitié en écriture.

Note spécifique : 
La mémoire « huge pages » peut être utilisée mais, au niveau du noyau, le paramètre « transparent_hugepages » ne doit pas être à « always », « madvise » est plus judicieux ici et de toutes façons tout le monde ne met pas en "huge pages" la quantité de mémoire nécessaire.

Clickhouse est un gros mangeur de mémoire et manifeste bruyamment son désaccord s’il ne dispose pas de la mémoire nécessaire à ses opérations. 
Au cours de mes essais, commencés avec une mémoire « faible » (6144Mo), je me suis heurté à quelques plantages pour des questions de mémoire. 
La plupart de ces problèmes ont eu lieu lors des tests de chargement à l’aide de l’utilitaire « clickhouse-mysql ». 
J’ai obtenu plusieurs fois (au fur et à mesure de l’augmentation de la taille mémoire de la machine virtuelle) le message suivant : 
Segmentation fault      clickhouse-mysql 
Dès que la mémoire a été « suffisante » cette erreur a disparu.

Autre type d’erreur rencontrée lors de l’exécution d’un ordre SQL simple (toujours avec une mémoire "insuffisante") permettant de repérer la quantité de « trous » dans la numérotation : 
select min(idx),max(idx), count(distinct idx) from flowsv4; 
Avant les augmentations de mémoire et sur une table partiellement chargée (de 100 à 260 millions de rangs) on obtient un stop brutal de l’ordre SQL avec quelques messages : 
Received exception from server (version 22.8.2): 
Code: 241. DB::Exception: Received from localhost:9000. DB::Exception: Memory limit (total) exceeded: would use 3.73 GiB (attempt to allocate chunk of 537537181 bytes), maximum: 3.48 GiB. OvercommitTracker decision: Query was selected to stop by OvercommitTracker.: While executing AggregatingTransform. (MEMORY_LIMIT_EXCEEDED)

 Dès que la mémoire est « suffisante » et même avec une table de plus de 488 millions de rangs l’ordre s’exécute sans ennuis et avec une rapidité tout à fait satisfaisante : 
┌─min(idx)─┬──max(idx)─┬─uniqExact(idx)─┐ 
│        1 │ 488553902 │      488521496 │ 
└──────────┴───────────┴────────────────┘ 
↙ Progress: 488.52 million rows, 3.91 GB (19.19 million rows/s., 153.56 MB/s.)   
1 row in set. Elapsed: 25.530 sec. Processed 488.52 million rows, 3.91 GB (19.13 million rows/s., 153.08 MB/s.) 
Alors que sur le même volume MariaDB attends à peine moins de 6 minutes avant de donner; heureusement, le même résultat.

Cas spécial du « drop table ». 
Une protection existe contre le drop accidentel d’une table, cette protection (par défaut à 50GB) est gérée par le paramètre « max_table_size_to_drop ». Si vous gardez cette protection le drop d’une « grosse table » peut makgré tout être effectué en créant un fichier spécifique qui sera détruit après le drop (Eh oui, il ne peut servir qu'une fois) : 
sudo touch  /var/lib/clickhouse/flags/force_drop_table 
sudo chown clickhouse: /var/lib/clickhouse/flags/force_drop_table 
Il est alors possible d’effectuer le « drop » de cette "grosse" table. 
Ce paramétrage peut sembler judicieux car le chargement de ces tables est assez consommateur de temps et on ne les charge pas uniquement pour les détruire.

Ce test montre assez bien la vitesse de Clickhouse.

La table "origine" est stockée sur une machine distante, les accès se font donc à travers le réseau. 
Pour MariaDB utilisation de Federatedx pour accès à la base distante, pour Clickhouse la structure équivalente de base Mysql distante avec une syntaxe de création assez semblable à celle utilisée par MariaDB. 
Résultats :

MariaDB : 
Query OK, 1938339 rows affected (33,521 sec) 
Enregistrements: 1938339  Doublons: 0  Avertissements: 0

Clickhouse : 
Query OK, 1939250 rows affected (19.682 sec)

Le temps de transfert depuis la machine d'origine doit être à peu près le même car j'ai redémarré le service sur la machine d'origine pour éviter l'influence du cache.

Les ordres SQL sont identiques :

insert into local_ntopng.flowsv4 
    select * from portail_maria.flowsv4 
    where idx > ( select max(idx) from local_ntopng.flowsv4 );

Les deux tests utilisent un accès réseau vers la machine "origine" des données.

Le montage (NFS ou Samba) pour l'installation du logiciel Oracle 10 est en place, on peut alors se connecter en tant qu'utilisateur "oracle" et lancer le très fameux "./runInstaller" depuis le répertoire d'installation. 
Dès le premier écran on est dans l'ambiance ...  
 
Sur lequel on clique "Installation avancée" pour pouvoir choisir nos options à loisir. 

Premier écran "Répertoire d'inventaire" : 
 
laisser le chemin du répertoire d'inventaire à la valeur proposée, Positionnez le groupe système à "dba". 

Deuxième écran "Type d'installation", cocher "Entreprise Edition". C'est aussi ici que l'on peut ajouter des langues. 
Troisième écran "Détails du répertoire d'origine Oracle Home", 
les valeurs proposée me plaisent ... et on enchaine sur la vérification des paramètres qui me signale juste un avertissement pour mon espace de swap qui n'est pas égal ou supérieur à 1.5 * RAM, je passe à la suite en confirmant que j'ignore superbement cette remarque. 
Dans quelques cas (cela vient de m'arriver), bien que tous les pré-requis soient marqués "success" il arrive qu'il faille "forcer" le passage en cliquant sur "Oui" dans la boite de dialogue qui vous signale un pré-requis non statisfait (?). Il s'agissait alors de la détection des interfaces réseau (pourtant pas en DHCP) ? 
Quatrième écran "Option de configuration" : cocher "Créer une base de données". 
Cinquième écran "Configuration de base de données" : cocher "Usage général", ce modèle est la plus adapté à nos besoins. 
Sixième écran "Options de configuration de la base de données" : 
 
Ici on choisit le nom de la base de données, je la nomme "orcl10g". 
Pour le jeu de caractères je sélectionne "Unicode standard UTF-8 AL32UTF8. 
et je coche "Créer une base de données avec les schémas exemples". 
Septième écran "Option de gestion de base de données" : cliquer "Utiliser le contrôle de base de données" ... et activer les notifications par mail en fournissant serveur de mail valide et adresse existante ! 
Huitième écran "Option de stockage de base de données" ; on clique "Système de fichiers" et on indique notre zone réservée "/DATA/u01". 
Neuvième écran "Sauvegarde et récupération" : cocher "Ne pas activer les saubegardes automatiques". 
Dixième écran : "Mots de passe" : je choisis "Utiliser le même mot de passe ..." et saisis un magnifique mot de passe ... et l'écran de résumé final s'affiche, 
 
on le vérifie pour éviter les surprises et on clique "Installer" et c'est parti :  
Non, on ne clique pas "Arrêter l'installation" ! Le voyant disque clignote, cela doit avancer, la barre de progression aussi. Le link est en cours, c'est bon signe. On arrive aux assistants de configuration, Oracle Net s'est configuré tout seul,la création de la BDD démarre, c'est le pied : 
 
C'est fini, le récap s'affiche en nous rappelant la connexion pour Entreprise Manager : "http://com-ora10g:1158/em", c'est bien noté. On peut dans cet écran aller sur la gestion des mots de passe. 
Et voici le moment des scripts à faire tourner en "root" 
 
et c'est exécuté en deux temps trois mouvements. 
Enfin c'est terminé et l'écran de rappel apparait 
 
on note les info et on "Quitte". 
Un petit "ps -ef' nous montre tous les processes oracle sagement en attente de boulot la "dbconsole" est lancée, on va voir si tout est OK 
 
et cela semble bien être la cas. 
On tente un reboot ... pour le prochain article. 
 

Plusieurs articles sur Oracle avec installation et tests de ASM et RAC.

• Oracle avec ASM
• Oracle avec ASM + RAC

Ces articles seront suivis de quelques tests.

Pour aller plus loin avec ASM la machine "simple" créée précédemment permet de se familiariser avec ASM mais ne permet pas d'essayer des choses que l'on pourrait faire avec une "grosse" machine, ni de tester les possibilités de RAC. Pour réaliser cet essai Xen va me permettre de simuler une machine d'enfer :

• 10 disques dont 9 de données
• 2 processeurs ( seulement sniff...)
• 3 Go de RAM ( seulement re sniff ...)

L'installation sera faite progressivement en partant des pré-requis, tout ceci sera simplifié par la ré-utilisation de l'image du Linux d'Oracle déjà utilisée. Le tout présenté en cinq phases :

• Mise en place des pré-requis
• Installation de ASM complet pour RAC
• Finalisation ASM + cluster
• Installation de la base de données
• Tests

Note : il existe des différences avec l'installation de ASM "simple", elle ne sont que faibles et dues à la gestion supplémentaire d'un "cluster".

Rappel : voir la doc Oracle ici et pour le détail des commandes de "asmcmd" allez voir là, ces docs sont, bien sûr, en anglais, la langue de ceux qui ignorent qu'il existe d'étranges individus dont la langue maternelle n'est pas l'anglais.

Chapitres en cours de réalisation et un peu retardés par des congés et 'autres réalisations ...

J'ai décidé de tester l'installation de Oracle 23c (édition développeur), cette installation sera faite dans une machine virtuelle (KVM) Oracle Linux 8.8 définie comme suit :               
Processeurs : 4 VCPU               
RAM         : 12 Go               
Disques                
Système     : 32Go               
DATA        : 128Go               
INDEX       : 128Go               
Ceci afin de pouvoir effectuer des tests "avec du volume".               
Les disques DATA et INDEX sont des partitions LVM sur des SSD, le disque système est sur un HD classique.               
1) Installation système Oracle Linux 8.8.               
2) Installation Oracle 23c.               
3) Paramétrage minimum.               
4) Quelques tests.

L'installation de Oracle Linux 8.8 se passe sans inconvénients majeurs, ci dessous quelques captures d'écrans.

Ecran de démarrage.

Mais il reste encore des choses à faire ...

Définir l'interface réseau.

Installation résumée.

Tout semble prêt. 

Pour commencer l'installation ... en cliquant sur "Commencer l'installation" et après quelques minutes ...

C'est parti ...

La suite "à venir" après quelque congé ... 
Ca y est je suis revenu de loooongs congés et je vais me remettre aux tests de cette version.

Article original de 2013.

Cette notion de maître / esclave permet diverses améliorations dont la principale est la sécurité, mais on peut y ajouter aussi des améliorations de performance qui seront précisées dans un autre article.

Dans cet exemple on part de deux machines (virtuelles) identiques avec des bases Mysql « vierges » . 
Il faut d'abord vérifier la présence du paquet "libaio1" et dans un premier temps créer les mêmes utilisateurs initiaux avec les mêmes droits. 
On passe ensuite aux opérations "sérieuses" :

Sur l'esclave modifier le fichier « my.cnf » et modifier le « server-id », 'jamais deux serveurs de même ID dans le même réseau) : 
Ancien  : server-id = 1 
Nouveau : server-id = 2

Redémarrer le service.

Sur le maître : 
Vérifier dans le fichier "my.cnf" que le « binlog » est bien activé  (Ligne dé-commentée) : 
log_bin = /var/log/mysql/mysql-bin.log

Redémarrer le service.

Sur la machine maître créer un utilisateur spécifique pour la réplication :

CREATE USER 'replicator'@'%' IDENTIFIED BY 'replicateur'; 
GRANT REPLICATION SLAVE ON *.* TO 'replicator'@'%';

Vérifier la connexion de l'esclave vers le maître avec votre utilisateur de réplication avec la commande suivante (sur l'esclave) : 
mysql –host=maitre –user=replicator –password=replicateur

qui doit fournir une connexion correcte.

On peut alors, toujours sur l'esclave, le « lier » à son maître :

CHANGE MASTER TO MASTER_HOST='mysql1', MASTER_USER='replicator',

MASTER_PASSWORD='replicateur'; START SLAVE;

1) Les premiers tests (simples).

- Vérifier le fonctionnement sur l'esclave :

SHOW SLAVE STATUS;

qui doit vous retourner un rang donnant le "point" de la synchronisation notamment le numéro du fichier "mysql-bin" en cours et d'autres valeurs de la position courante.

- Créer une DATABASE.

Sur le maître créer une base :

CREATE DATABASE VALID ;

Sur l'esclave vérifier l'existence de la base :

USE DATABASE VALID ;

Une fois ce test passé on peut continuer avec

- Créer table :

Sur le maître on crée une table dans notre DB VALID :

CREATE TABLE TOTO ( zone char(6)) ;

On vérifie sur l'esclave :

DESC TOTO ;

Qui doit vous retourner la description de la table TOTO.

On peut ensuite, pour faire bien, insérer des choses dans notre table sur le maître.

insert into TOTO ( zone) values ( "un" ); 
insert into TOTO ( zone) values ( "deux" );

Dans notre base esclave :

select * from TOTO; 
retourne :

+------+ 
| zone | 
+------+ 
| un   | 
| deux | 
+------+ 
2 rows in set (0.00 sec)

Ce qui est exceptionnel !!

2) Des tests plus évolués.

Que se passe-t-il maintenant si : 
- on stoppe l'esclave 
- on fait une insertion sur le maître :

insert into TOTO (zone) values (« trois »).

- on redémarre l'esclave et on effectue le « select » précédent , miracle il nous retourne bien : 
+-------+ 
|  zone | 
+-------+ 
| un    | 
| deux  | 
| trois | 
+-------+ 
3 rows in set (0.00 sec)

3) Remarques finales.

La procédure est ici très simple avec du matériel simple (virtuel ! ), dans la réalité il faudrait prévoir :

• deux liens réseau dont un spécifique à la réplication et qui serait un plus pour limiter au maximum la latence du système.
• de se servir de la base répliquée pour faire des sauvegardes tranquillement, sana perturber la machine "maître".
• de se servir de la machine "esclave"  pour lancer de "gros" ordres SQL de statistiques qui perturberaient plus ou moins fortement le serveur principal.

Il reste très simple d'effectuer cette mise en réplication et cela est assez performant.

Ayant un petit serveur "libre", le malheureux chauffait tellement qu'il se plantait régulièrement et que j'ai du le remplacer vite fait (voir article). Lorsque je l'ai démonté pour voir ce qu'il avait dans le ventre j'ai touché le radiateur et j'ai entendu un petit "clic", depuis cet engin ne chauffe plus ! J'ai donc décidé de l'utiliser avec quelques "vieux" SSD qui traînaient dans un coin pour faire quelques tests avec Mysql. 
J'ai utilisé une base disponible sur une autre machine et qui possède deux tables un peu volumineuses : 10 millions de rangs pour l'une et un peu plus de 100 000 pour l'autre, le tout "pesant" environ 4GO. 
La machine d'origine que j'ai prise pour référence possède : 
CPU        CoreI5 à 3.4Ghz série 5 
RAM       16 Go 
Disques  2 disques 1To à 7200 tours en Raid 1 
Mysql      5.6.30 
La machine "ressuscitée" dispose de : 
CPU        CoreI3 à 3.4GHz série 4 
RAM        16 Go 
Disques   3 SSD assez anciens mais encore vaillants de 32 à 128Go. 
Mysql      5.6.30 puis 5.7.16 
J'ai essayé 2 configurations : 
Standard, tout sur le même disque (SSD), répertoires /var/lib/mysql et /var/log/mysql 
Optimisée système sur un disque, DATA (ex /var/lib/mysql) sur un SSD et LOG (ex /var/log/mysql) sur un autre SSD, bien qu'avec des ordres "SELECT" le log ne soit pas sollicité. 
Remarques : Toutes les tables sont en InnoDB et la valeur de "innodb_buffer_size" est fixée à 2048M. 

La suite bientôt ... c'est fait et c'est ICI. 
 

Mysql : mise en cluster maître/esclave. 
Vous disposez d'une belle application fonctionnant sur une non moins belle base de données Mysql qui contient tout ce qui est nécessaire à votre application. 
Mais que se passera-t-il si votre base est indisponible (crash base, disque ayant rendu l'âme, prise de pied dans la prise de courant ....) ? 
Votre belle application ne fonctionnera plus du tout ... 
La solution : Clusteriser votre base de données en mode maître/esclave. 
Oui, mais ma base existe déjà, comment faire ? Je n'ai pas envie de "dumper" toutes mes tables .... !!! et de les recharger. 
C'est cette histoire que je vais vous conter. 
Vous ne touchez pas à votre serveur original (il marche, ne pas le déranger), et vous préparez une merveilleuse machine, identique pour bien faire, et faites-y une installation complète de Mysql de préférence dans la même version, ici c'est du 5.6 ! Cela marche aussi très bien avec MariaDB. 
Si la structure des répertoires de DATA n'est pas "standard" il vaut mieux refaire à l'identique, cela simplifiera toute la maintenance. 
Un peu de vocabulaire pour la suite :

• Serveur1 : votre serveur "actuel"
• Serveur2 : le petit nouveau.

L'opération consiste à :

• Créer les utilisateurs nécessaires à la réplication (Serveur1).
• Stopper Mysql sur le Serveur1
• Sauvegarder l'intégralité des fichiers de la BDD, si vous utilisez LVM (ou BTRFS) vous pouvez faire un snapshot du support disque de votre base, et la relancer immédiatement. Sinon "tar" fonctionne encore ...
• Modifier le fichier de config de Serveur1
• Stopper Mysql sur Serveur2, et bien nettoyer les répertoires de Mysql, y compris les fichiers de "/var/log/mysql"
• Restaurer les données de Serveur1 sur Serveur2.
• Détruire un petit fichier sur Serveur2 (/var/lib/mysql/auto.cnf)
• Reparamétrer Serveur2 en esclave, et en "read-only", c'est plus prudent.
• Redémarrer Serveur2

Note : Il existe des moyens de faire une sauvegarde "on line" ce qui évite de stopper le serveur, mais dans ce cas il faut enregistrer la position dans le "binlog" pour permettre à l'esclave de repartir juste après la dernière transaction enregistrée.

Vous pouvez alors passer Serveur2 en mode "esclave" et Serveur2 sera maintenu à jour par rapport à Serveur1.

Un peu de détail pour arriver à ce Nirvana : 
1) Créer les utilisateurs pour la réplication sur Serveur1 :

*      Users pour replication  */  create user         'replic_usr'@'mysql1'       identified by 'Mon_Secret';  grant all on *.* to     'replic_usr'@'mysql1'       with grant option; create user         'replic_usr'@'192.168.2.62' identified by 'Mon_Secret';  grant all on *.* to     'replic_usr'@'192.168.2.62' with grant option;  /*  */  create user         'replic_usr'@'mysql2'       identified by 'Mon_Secret';  grant all on *.* to     'replic_usr'@'mysql2'       with grant option; create user         'replic_usr'@'192.168.2.63' identified by 'Mon_Secret';  grant all on *.* to     'replic_usr'@'192.168.2.63' with grant option;

Note : 
Vous avez un Mysql installé sur Serveur2, vérifiez que le user "replic_usr" peut bien se connecter sur Serveur1 : 
mysql -user=replic_usr --password=Mon_Secret -D mysql 
Si tout va bien vous pouvez alors stopper Mysql sur Serveur2. 
2) Une fois ceci réalisé stopper Mysql sur serveur 1. 
Sauvegardez /var/lib/mysql et ici, en plus /DATA/D1 et /DATA/D2 pour compliquer un peu.

3) Pendant ce temps modifier votre fichier "mysqld.cnf" et ajoutez-y  :

### pour Master  server-id               = 1  log-bin                 = mysql-bin  binlog-format           = MIXED  log-slave-updates       = true  gtid-mode               = on  enforce-gtid-consistency= on  master-info-repository  = table  report-host             = mysql1

4) Stoppez Mysql sur Serveur2. 
5) Transportez vos copies sur Serveur2 et restaurez les "en place". 
6) Supprimer le fichier "auto.cnf" dans /var/lib/mysql. 
6) Modifiez le fichier "mysqld.cnf", comme pour Serveur1 sauf "server-id" et "report-host":

### pour Slave    server-id                = 2  read-only                = 1  log-bin                  = mysql-bin  binlog-format            = MIXED  log-slave-updates        = true  gtid-mode                = on  enforce-gtid-consistency = 1  master-info-repository   = table  report-host              = mysql2

7) C'est presque fini : 
Redémarrez Mysql sur Serveur1 et verifiez dans le fichier "error.log" la présence du message : 
/usr/sbin/mysqld: ready for connections. 
Passons maintenant au Serveur2 : 
Nettoyer certains fichier que vous venez de restaurer dans /var/lib/mysql : 
- mysql-bin* 
Son fichier de configuration est correct, bien vérifier que le fichier "auto.cnf" (il contient un UUID) "/var/lib/mysql/auto.cnf" est effacé avant de redémarrer le serveur qui va s'empresser de le recréer avec un nouvel "UUID" différent de celui de Serveur1. 
On peut alors "asservir" notre futur esclave :

mysql -u root -p -D Le_mot_de_passe_qui_va_bien  change MASTER  to MASTER_USER='replic_usr',      MASTER_PASSWORD='Mon_Secret',      MASTER_HOST='192.168.2.62'; \q

Qui devrait répondre gentiment : 
Query OK, 0 rows affected, 2 warnings (0,31 sec) 
Puis : 
start slave; 
qui répond (gentiment lui aussi) : 
Query OK, 0 rows affected (0,11 sec)

Verifications : 
Nos données sont-elles toujours sur le maître :

mysql> show tables;  +--------------------+  | Tables_in_test_del |  +--------------------+  | ANAL_FIR_ARC       |  | ANAL_FIR_TEST      |  | TEST_LOG           |  +--------------------+  3 rows in set (0,00 sec)

Et sur l'esclave ?

mysql> show tables;  +--------------------+  | Tables_in_test_del |  +--------------------+  | ANAL_FIR_ARC       |  | ANAL_FIR_TEST      |  | TEST_LOG           |  +--------------------+  3 rows in set (0,00 sec)

Rien ne s'est perdu en route, nos petites données sont maintenant en sécurité ! 
Maintenant créons une table sur le maître :

create table toto ( zone varchar(32) );  Query OK, 0 rows affected (0,36 sec)  mysql> show tables;  +--------------------+  | Tables_in_test_del |  +--------------------+  | ANAL_FIR_ARC       |  | ANAL_FIR_TEST      |  | TEST_LOG           |  | toto               |  +--------------------+  4 rows in set (0,00 sec)

Et sur l'esclave :

mysql> sow tables;  +--------------------+  | Tables_in_test_del |  +--------------------+  | ANAL_FIR_ARC       |  | ANAL_FIR_TEST      |  | TEST_LOG           |  | toto               |  +--------------------+  4 rows in set (0,00 sec)

Allez on s'en refait un coup, sur le maître :

mysql> insert into toto (zone) values ('Ah oui, comme cela est bon');  commit;

Et sur l'esclave :

mysql> select * from toto;  +----------------------------+  | zone                       |  +----------------------------+  | Ah oui, comme cela est bon |  +----------------------------+  1 row in set (0,00 sec)

A bientôt pour la suite de ces passionnantes aventures dans le monde de Mysql.

J'ai décidé d'installer deux serveurs MariaDB (cela ne change que peu de Mysql) pour tester une configuration multi-maîtres. Pour cela il faut d'abord installer deux machines (virtuelles) identiques. J'ai choisi d'installer une Debian "Stretch" qui devrait prochainement passer en "stable". 
Description des machines :

• CPU        2
• RAM        4096GB
• Disque système 16GB    ext4
• Disque DATA    32GB    LVM, partition "VGDATA/MYSQL" de 24GB montée sur /DATA/mysql.

Il restera ainsi 8GB pour effectuer des "snapshots" destinés à la sauvegarde (article à suivre). 
Pour faciliter l'installation (IP et nom viennent "automagiquement) j'ai créé ces machines dans le serveur dhcp et je les ai insérées dans mon serveur DNS. 
Installation des machines à partir d'une image de cd "debian-testing-amd64-xfce-CD-1.iso". 
Pas de serveur WEB, serveur SSH plus quelques paquets indispensables. 
apt-get install system-config-lvm iproute2 net-tools vim-gtk 
et enlevé "network-manager" que je n'apprécie pas, je préfère le bon vieux fichier "/etc/network/interfaces" et gérer moi même /"etc/resolv.conf". 
Ensuite j'ai installé MariaDB client et serveur en "standard" (je précise la version 10.1) : 
apt-get install mariadb-client-10.1 mariadb-server-10.1 

Quelques modifications dans le fichier /etc/mysql/mysqld.conf.d/50-server.cnf : 
Mettre la BDD "en ligne" : 
bind-address                   = 0.0.0.0 
Dans le "bloc" InnoDB (par exemple) ajout de : 
innodb-buffer-pool-size         = 1024M 
innodb_buffer_pool_instances    = 2 
innodb-file-per-table           = 1 
innodb_additional_mem_pool_size = 8M 
innodb_log_file_size            = 512M 
innodb_log_buffer_size          = 8M 
innodb_read_io_threads          = 2 
innodb_write_io_threads         = 2 
innodb_stats_persistent         = 1 
innodb_stats_persistent_sample_pages = 512

Positionner la variable "server-id" à 1 pour le premier serveur et = 2 pour le second.

Ajouter dans le bloc "[mariadb-10.1]" : 
innodb_flush_log_at_trx_commit = 2 
event_scheduler                = on 
local_infile                   = 0 
plugin-load=validate_password.so 
skip-symbolic-links            = 1 
innodb_flush_method            = O_DIRECT 
binlog_row_image               = minimal 
# 
concurrent_insert              = AUTO 
sync_binlog                    = 1 
innodb_use_native_aio          = 1 
# Sans oublier d'activer le "bin-log" nécessaire au maître 
log_bin                        = /var/log/mysql/mysql-bin.log 
# et le format de log, je préfère "mixed" à "row" ou "statement" 
binlog_format                  = mixed 

Et pour terminer et éviter des problèmes dus aux tables avec identifiant en "auto-increment" : 
Mettre chacune des deux machines (ou plus) sur des séries différentes. Ici l'une générera des identifiants pairs, l'autre des identifiants impairs réduisant ainsi à zéro les risques de collision. 
Sur le serveur 1 : 
auto_increment_increment  = 1 
Sur le serveur 2 : 
auto_increment_increment  = 2 
et sur les deux machines : 
auto_increment_offset     = 2 
La machine 1 génère ainsi la série 1,3,5,7 .... 
la machine 2 la série 2,4,6,8 .... 
Après ces quelques modifications on redémarre Mariadb pour valider nos modifications. 
Il faut ensuite configurer le volume destiné aux données (LVM). 
C'est pour cela que j'ai installé le peu gourmand "system-config-lvm", 
Créer un volume "MARIADBDATA1" (partition 1 du second disque "/dev/xvdb1"), dans ce volume créer un LV "DATA" de 24GB conservant ainsi 8GB pour des snapshots. 
Ce LV est créé en "ext4" et monté sur /DATA/mysql que l'on aura créé auparavant sans oublier un "chmod mysql:mysql /DATA/mysql". 
Ensuite arrêter MariaDB et copier le contenu cd /var/lib/mysql dans le répertoire /DATA/mysql (après montage du disque bien sûr !) et remplacer le répertoire (renommé par sécurité !) d'origine par un lien /var/lib/mysql --> /DATA/mysql on peut alors redémarrer MariaDB.

Les deux machines ont été installées "à la main" (pas en copiant l'image disque) afin de bien vérifier la procédure d'installation. 
Ces deux machines ont une structure identique, le report des données présentes dans le S1 est facilité :

1. On arrête les deux services "mysql"
2. On copie "bêtement les fichiers du répertoire /DATA/mysql de S1 dans celui de S2 (tar)
3. On relance le service et on resynchronise les deux "masters" entre eux.

J'ai voulu installer la version 5.7 de Mysql depuis le repository de Mysql en chargeant depuis le site le paquet "Ubuntu / Debian (Architecture Independent), DEB" qui installe notament un fichier "mysql.list" dans /etc/apt/sources-list.d, ensuite on utilise les outils standard Debian : aptitude, apt-get ou synaptic. 
Remarque : j'ai inhibé le repository "mysql-tools-preview" 
Un "apt-get update" plus loin les choses sont disponibles et on peut installer "mysql-community-client" et "mysql-community-server" version 5.7.16 
J'ai voulu réaliser une installation non "standard" en positionnant les fonctionnalités principales de la base de données sur des systèmes de fichiers différents notamment pour la partie "log" et pour la partie "données"  afin d'optimiser le fonctionnement. 
La machine est munie de :

• CPU    CoreI3 4330
• RAM    16G
• 3 disques SSD

Selon le schéma suivant : 
Un système de fichier racine 
Un système de fichier /DATA/DATA1 pour les données 
Un système de fichier /LOG/LOG1 pour les logs y compris les "logbin".

J'ai configuré le fichier /etc/mysql/mysql.conf.d/mysqld.cnf de la façon suivante :

[mysqld]  pid-file               = /run/mysqld/mysqld.pid  socket                 = /run/mysqld/mysqld.sock  # By default we only accept connections from localhost  bind-address           = 0.0.0.0  # Disabling symbolic-links is recommended to prevent assorted security risks  symbolic-links=0  ### Deplacement des répertoires  datadir                = /DATA/DATA1/mysql  tmpdir                 = /LOG/LOG1/mysql_tmp  log_bin                = /LOG/LOG1/mysql/server-bin  general_log_file       = /LOG/LOG1/mysql/general.log  slow-query-log-file    = /LOG/LOG1/mysql/slow_query.log  server_id              = 11  log_error              = /LOG/LOG1/mysql/error.log  secure-file-priv       = /DATA/DATA1/mysql-files  slave_load_tmpdir      = /LOG/LOG1/mysql_tmp  ### configuration InnoDB

....

Nettoyez toute trace de l'installation imposée lors du démarrage (/var/lib/mysql, /var/log/mysql). 
Vérifiez bien que tous vos répertoires "mysql" ont bien le user et le groupe "mysql" :

cd /DATA//DATA1  ls -al  drwxr-xr-x 6 root  root   4096 nov.  18 20:00 .  drwxr-xr-x 4 root  root   4096 nov.  14 23:27 ..  drwx------ 2 root  root  16384 nov.  12 22:24 lost+found  drwxr-xr-x 5 mysql mysql  4096 nov.  18 20:26 mysql  drwx------ 2 mysql mysql  4096 nov.  18 20:02 mysql-files  cd /LOG/LOG1  drwxr-xr-x 6 root  root   4096 nov.  17 23:22 .  drwxr-xr-x 4 root  root   4096 nov.  15 00:21 ..  drwx------ 2 root  root  16384 nov.  15 00:21 lost+found  drwxr-xr-x 2 mysql mysql  4096 nov.  18 20:04 mysql  drwx------ 2 mysql mysql  4096 nov.  18 20:22 mysql-files  drwxr-xr-x 2 mysql mysql  4096 nov.  18 20:25 mysql_tmp

Il faut maintenant attaquer la partie "systemd" et la corriger pour éluder un script (horrible) rempli de valeurs "en dur" qui viendrait perturber la belle ordonnance de nos paramètres. 
Ce script (/usr/share/mysql/mysql-systemd-start) est à ignorer purement et simplement et à remplacer par un petit script destiné uniquement à initialiser correctement le répertoire "mysqld" dans /run (et pas /var/run qui n'est qu'un lien vers /run) ce script hyper simple (je l'ai appelé "init-mysql") il est fourni à titre d'exemple :

#!/bin/bash  MYSQLRUN=/run/mysqld  if [ ! -d ${MYSQLRUN} ]     then      mkdir ${MYSQLRUN}      chown mysql:mysql ${MYSQLRUN}  fi

Ce n'est vraiment pas grand chose ! 
Attention ce script est exécuté par le user "mysql", le mettre dans /usr/bin par exemple pour qu'il soit accessible sans difficultés.

Modifier le script "systemd" de lancement du service (/lib/systemd/system/mysql.service) pour en extirper la référence à l'horrible "mysql-systemd-start" : 
Partie du script "systemd" modifié :

[Service]  User=mysql  Group=mysql  Type=forking  PermissionsStartOnly=true  PIDFile=/run/mysqld/mysqld.pid  ExecStartPre=/usr/bin/init_mysql  ExecStart=/usr/sbin/mysqld --daemonize --pid-file=/run/mysqld/mysqld.pid  TimeoutSec=60  LimitNOFILE = 5000  Restart=on-abort  RestartPreventExitStatus=1  RuntimeDirectory=mysqld  RuntimeDirectoryMode=755  Ne pas oublier ensuite "systemctl daemon-reload" avant de relancer le service.  Aller modifier le fichier /etc/mysql/conf.d/mysql.cnf (utilisé par le client mysql) pour y indiquer le nom du fichier "socket" :  [mysql]  socket = /run/mysqld/mysqld.sock

On doit encore réaliser un petit truc bizarre, créer un lien entre : 
/etc/mysql/mysql.conf.d/mysqld.cnf et /etc/my.cnf ??? 
On peut alors, enfin, lancer une installation "personnalisée" de l'ensemble en utilisant le paramètre "--initialize--insecure" de mysqld, adieu "mysql_install_db" on ne te regrettera pas trop. 
mysqld --initialize-insecure 
qui crée le user "root" sans mot de passe, il suffira d'en mettre un rapidement avec la commande "set password ..." pour rester correct, la commande se termine rapidement, SSD oblige. 
Cette commande a rempli les répertoires prévus /DATA/DATA1/mysql de ce qui se trouve dans /var/lib/mysql habituellement. 
Tout semble prêt on lance la commande fatidique : 
service mysql start 
qui rend la main rapidement (tout est sur des SSD), on vérifie un peu si tout va bien :

ps -ef | grep mysqld  mysql  2733  1  2 22:52 ?  00:00:00 /usr/sbin/mysqld --daemonize --pid-file=/run/mysqld/mysqld.pid

puis :

ls -al /run/mysqld  drwxr-xr-x  2 mysql mysql 100 nov.  18 22:52 .  drwxr-xr-x 23 root  root  860 nov.  18 22:52 ..  -rw-r-----  1 mysql mysql   5 nov.  18 22:52 mysqld.pid  srwxrwxrwx  1 mysql mysql   0 nov.  18 22:52 mysqld.sock  -rw-------  1 mysql mysql   5 nov.  18 22:52 mysqld.sock.lock

Tout à l'air parfait on lance le client mysql :

mysql  Welcome to the MySQL monitor.  Commands end with ; or \g.  Your MySQL connection id is 2  Server version: 5.7.16-log MySQL Community Server (GPL)Copyright (c) 2000, 2016, Oracle and/or its affiliates. All rights reserved.Oracle is a registered trademark of Oracle Corporation and/or its  affiliates. Other names may be trademarks of their respective  owners.Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.  mysql>

Ouaaaah tout baigne, vite mettons un mot de passe à ce vieux "root" :

use mysql; 
mysql> set password for 'root'@'localhost' = PASSWORD('Un_BeAu_#_PaSsWoRd_ToUt%Neuf?'); 
\q 
Et on teste notre mot de passe :

mysql --user=root -p  Enter password:   Welcome to the MySQL monitor.  Commands end with ; or \g.  Your MySQL connection id is 5  Server version: 5.7.16-log MySQL Community Server (GPL)Copyright (c) 2000, 2016, Oracle and/or its affiliates. All rights reserved.Oracle is a registered trademark of Oracle Corporation and/or its  affiliates. Other names may be trademarks of their respective  owners.Type 'help;' or '\h' for help. Type '\c' to clear the current input statement. mysql>\q

C'est fini, on dispose d'une base toute neuve en version 5.7.16. Montée sur des systèmes de fichiers SSD cela devrait être assez rapide ! 
A bientôt pour quelques tests. 
 

Mettre l'esclave au boulot ! Pour réaliser cet exploit il faut utiliser un "proxy intelligent" capable de distinguer les ordres en lecture seule (SELECT) et les autres (le SELECT ... FOR UPDATE) est un piège. 
Le proxy que j'ai choisi de tester s'appelle "ProxySql", nom très original s'il en est, mais il fonctionne fort bien et est assez simple à manipuler.

Le paquet est téléchargeable (V1.2.1 au moment de ces tests) à : 
https://github.com/sysown/proxysql/releases/download/v1.2.1/proxysql_1.2.1-debi… 
La liste complète des téléchargements est accessible à  l'URL: 
https://github.com/sysown/proxysql/releases/ 
L'installation se fait sans mystère par : 
dpkg -i proxysql_1.2.1-debian8_amd64.deb 
Un script d'init est installé ainsi qu'un fichier de configuration /etc/proxysql.cnf, un répertoire /var/lib/proxysql est créé, de la doc /usr/share/doc ... Tout a l'air présent ! 
Le service n'est pas démarré par défaut, après un "service proxysql initial" (pour la première fois) le service est lancé et écoute sur les ports 6032 et 6033 (paramètres par défaut). 
Ce paramètre "initial" permet d'initialiser la base de données interne de proxysql. 
Si vous n'avez pas personnalisé un minimum votre fichier "proxysql.cnf" vous pouvez le modifier et repasser un petit coup de "initial". Au passage renommer rapidement ce fichier sinon au prochain démarrage il sera réutilisé ! 
Proxysql utilise syslog et vous trouverez ses messages dans /var/log/daemon.log 
Par la suite on n'aura plus besoin de repasser le paramètre "initial", sauf pour réparer une "grosse bêtise". 
Testons maintenant la connexion à Proxysql (user/mot de passe fixés dans proxysql.cnf)  :

mysql -u admin -p  -h 127.0.0.1 -P 6032  Enter password: admin  Welcome to the MySQL monitor.  Commands end with ; or \g.  Your MySQL connection id is 3  Server version: 5.5.30 (ProxySQL Admin Module)  Copyright (c) 2000, 2016, Oracle and/or its affiliates. All rights reserved.  Oracle is a registered trademark of Oracle Corporation and/or its  affiliates. Other names may be trademarks of their respective  owners.  Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.  mysql>

Cela a un petit air connu ... 
Remarque : la connexion par défaut est sur la base "main" :

mysql> show databases;  +-----+---------+-------------------------------+  | seq | name    | file                          |  +-----+---------+-------------------------------+  | 0   | main    |                               |  | 2   | disk    | /var/lib/proxysql/proxysql.db |  | 3   | stats   |                               |  | 4   | monitor |                               |  +-----+---------+-------------------------------+  4 rows in set (0,00 sec)  mysql> use main;  show tables;  +--------------------------------------+  | tables                               |  +--------------------------------------+  | global_variables                     |  | mysql_collations                     |  | mysql_query_rules                    |  | mysql_replication_hostgroups         |  | mysql_servers                        |  | mysql_users                          |  | runtime_global_variables             |  | runtime_mysql_query_rules            |  | runtime_mysql_replication_hostgroups |  | runtime_mysql_servers                |  | runtime_scheduler                    |  | scheduler                            |  +--------------------------------------+  mysql> use disk;  show tables;  +--------------------------------------+  | tables                               |  +--------------------------------------+  | global_variables                     |  | mysql_collations                     |  | mysql_query_rules                    |  | mysql_replication_hostgroups         |  | mysql_servers                        |  | mysql_users                          |  | runtime_global_variables             |  | runtime_mysql_query_rules            |  | runtime_mysql_replication_hostgroups |  | runtime_mysql_servers                |  | runtime_scheduler                    |  | scheduler                            |  +--------------------------------------+  \q

Tiens ? Les mêmes tables sont présentes dans les bases "disk" et "main".

On peut "regarder" le contenu des tables par des ordres "SELECT", ajouter des choses par "INSERT", modifier par "UPDATE", et faire des "DELETE". La plupart des commandes de Mysql fonctionnent (sauf "desc" ?). 
Pour faire des modifications "rollbackables" il faut les faire au sein d'une transaction explicite (begin transaction;), le rollback sera ainsi possible. 
Le proxy dispose de deux règles par défaut "Select for update" et "select" qui envoyent respectivement sur les "hostgroups" 0 et 1, traditionnellement le "0" est le maître (celui qui peut effectuer des modifications de la base) et le groupe 1 celui des esclaves en lecture seule. 
On se dépêche de changer le user "admin:admin" en autre chose de plus sécurisé : 
update global_variables set variable_value = 'new_admin:admin_new' where variable_name = 'admin-admin_credentials'; 
Attention aux '-' , ":" et aux '_' !!! 
Vous avez certainement remarqué les noms des tables doublés entre : 
global_variables 
runtime_global_variables 
..... 
Après une modif dans les tables "sans préfixe" il faut les recopier dans les tables "runtime" puis les sauvegarder sur disque pour rendre les modifications permanentes. 
On peut ainsi préparer une nouvelle config dans les tables "sans préfixe" qui ne sont pas actives puis la basculer sur les tables "runtime" ce qui les rend actives. 
Cela se fait à l'aide de commandes "LOAD" et "SAVE". 
Dans notre cas de modfification de l'accès administrateur il faut : 
Le reporter dans le "runtime" 
LOAD MYSQL VARIABLES TO RUNTIME; 
et les sauvegarder pour la postérité : 
SAVE MYSQL VARIABLES TO DISK;

Dès que vous avez changé le user/mot de passe administrateur vous pouvez (devez) :

• Détruire (ou renommer) le fichier /etc/proxysql.cnf
• Redémarrer le service proxysql

Votre nouveau user/mot de passe sera alors actif.

Pour les tests le hostgroup 0 est une VM Mysql "master", le hostgroup 1 est une VM Mysql "slave" de la première qui ne recevra que les ordres "SELECT" purs exempts de toute clause "FOR UPDATE". 
On revient un peu en arrière et on va voir la config postée initialement dans le fichier "proxysql.cnf" pour nos serveurs Serveur1 (master) et Serveur2 (slave) :

mysql_servers =  (     { address="mysql1" , port=3306 , hostgroup=0 , max_connections=10 },     { address="mysql2" , port=3306 , hostgroup=1 , max_connections=10 }  )  mysql_users:  (    { username = "test" , password = "test", default_hostgroup = 0, active = 1 }  )

Si on regarde (avec notre nouvel "admin") l'état de la table mysql_servers :

select * main.from mysql_servers;  *************************** 1. row ***************************         hostgroup_id: 0             hostname: mysql1                 port: 3306               status: ONLINE               weight: 1          compression: 0      max_connections: 10  max_replication_lag: 0              use_ssl: 0       max_latency_ms: 0  *************************** 2. row ***************************         hostgroup_id: 1             hostname: mysql2                 port: 3306               status: ONLINE               weight: 1          compression: 0      max_connections: 10  max_replication_lag: 0              use_ssl: 0       max_latency_ms: 0  2 rows in set (0,00 sec)

C'est bien l'état indiqué dans le fichier original ,vérifions maintenant nos règles de répartition :

mysql> select * from mysql_query_rules\G  *************************** 1. row ***************************                rule_id: 1                 active: 1               username: NULL             schemaname: NULL                 flagIN: 0            client_addr: NULL             proxy_addr: NULL             proxy_port: NULL                 digest: NULL           match_digest: NULL          match_pattern: ^SELECT .* FOR UPDATE$   negate_match_pattern: 0                flagOUT: NULL        replace_pattern: NULL  destination_hostgroup: 0              cache_ttl: NULL              reconnect: NULL                timeout: NULL                retries: NULL                  delay: NULL         mirror_flagOUT: NULL       mirror_hostgroup: NULL              error_msg: NULL                    log: NULL                  apply: 1  *************************** 2. row ***************************                rule_id: 2                 active: 1               username: NULL             schemaname: NULL                 flagIN: 0            client_addr: NULL             proxy_addr: NULL             proxy_port: NULL                 digest: NULL           match_digest: NULL          match_pattern: ^SELECT   negate_match_pattern: 0                flagOUT: NULL        replace_pattern: NULL  destination_hostgroup: 1              cache_ttl: NULL              reconnect: NULL                timeout: NULL                retries: NULL                  delay: NULL         mirror_flagOUT: NULL       mirror_hostgroup: NULL              error_msg: NULL                    log: NULL                  apply: 1  2 rows in set (0,00 sec)

C'est bien ce que nous voulions installer. 
Quand à notre user il semble lui aussi OK :

select * from MYSQL_USERS\G  *************************** 1. row ***************************                username: test                password: test                  active: 1                 use_ssl: 0       default_hostgroup: 0          default_schema:           schema_locked: 0  transaction_persistent: 0            fast_forward: 0                 backend: 1                frontend: 1         max_connections: 10000

Tout cela a l'air bel et bon.

Site à voir : 
http://severalnines.com/blog/how-proxysql-adds-failover-and-query-control-your-mysql-replication-setup