Introduction
Qui l’eût cru en 2009, 10 ans plus tôt, Microsoft SQL Server 2019 sur les plateformes Linux. Certainement pas l’auteur de ce papier, mais Microsoft l’a fait !
SQL Server 2017 était déjà supporté sur Linux, mais de nombreuses fonctions manquaient par rapport à la version Windows comme la réplication, la haute disponibiltié, le coordinateur de transactions distribuées (DTC), certains mécanismes d’authentification avec l’Active Directory ainsi que des fonctionnalités dans l’agent SQL Server… Liste des fonctionnalités manquantes dans SQL Server 2017 sur Linux.
SQL Server 2019 sur Linux inclut maintenant les fonctionnalités majeures manquantes de la version SQL Server 2017. Explorons donc SQL Server 2019 sur Linux.
Dans cet article, SQL Server 2019 est installé sur Ubuntu 18.04 : Ubuntu 16.04 est actuellement la seule version supportée, mais cela fonctionne sur Ubuntu 18.04 à des fins de tests.
Le multi-instances et les instances nommées ne sont pas (encore ?) supportés sur Linux, des architectures tierces comme Docker doivent être utilisées pour cela.
Dans cet article donc, une instance SQL Server standalone est installée. Comme la majorité des entreprises implémentent des parefeux
pour empêcher les serveurs de communiquer avec l’extérieur, les installations sont faites en mode hors ligne (offline) avec les
packages *.deb
fournis par Microsoft.
- Le moteur SQL Server écoute sur le port 1433 et s’exécute avec le user
mssql
. - Les fichiers de bases de données ne sont pas créés dans le répertoire par défaut.
- L’agent SQL Server, SSL et l’authentification avec l’Active Directory ne sont pas abordés ici.
Après l’installation, les 2 premiers tests réalisés sont :
- La restauration sur SQL Server 2019 / Linux d’une base de données à partir de sa sauvegarde SQL Server 2016 / Windows.
- L’export/import d’une table avec bcp en mode natif de SQL Server 2016 / Windows vers SQL Server 2019 / Linux.
Ces 2 tests montreront s’il est facile ou non, dans ce contexte cross-plateformes, de migrer des bases de données de SQL Server 2016 sous Windows vers SQL Server 2019 sous Linux.
Prérequis
Les prérequis systèmes sont les suivants pour SQL Server 2019 sur les plateformes Linux :
- Mémoire : 2GB
- Type de système de fichiers : XFS ou EXT4
- Espace disque : 6 GB
- Vitesse de processeur : 2 GHz
- Nombre de cores : 2
- Type de processeur : x64
Utiliser la commande fsck
ou mount
pour vérifier les types de systèmes de fichiers sur lesquels
SQL Server sera installé :
fsck -N /dev/sda1
[/sbin/fsck.ext4 (1) -- /] fsck.ext4 /dev/sda1
mount | grep '^/dev/sda1'
/dev/sda1 on / type ext4 (rw,relatime,data=ordered)
Le programme d’installation de SQL Server 2019 créé le compte mssql
si celui-ci n’existe pas.
Si on travaille dans des environnements avec des id
normalisés pour les comptes, préparer en avance le compte mssql
, c’est le cas ici :
root@vps$ useradd mssql -g dba -d /home/mssql -m -s /bin/bash -u 10006
root@vps$ passwd mssql
Installations des packages : serveur et outils clients
Serveur
Télécharger d’abord le package mssql-server à partir du site Web de Microsoft.
Pour ce package, choisir Ubuntu 16.04 même si le système cible est Ubuntu 18.04 :
https://packages.microsoft.com/ubuntu/16.04/.
Le package SQL Server 2019 CTP 3 (mssql-server_15.0.1600.8-1_amd64.deb
) est dans le sous répertoire
./mssql-server-preview/pool/main/m/mssql-server
.
Envoyer le package sur le serveur Ubuntu et vérifier les dépendances :
root@vps$ dpkg -I mssql-server_15.0.1600.8-1_amd64.deb | grep 'Depends:'
Depends: libunwind8, libnuma1, libc6, adduser, libc++1, gdb, debconf, hostname, openssl (>= 1.0.1g), python (>= 2.7.0), libgssapi-krb5-2, libsss-nss-idmap0, gawk, sed, libpam0g, libldap-2.4-2, libsasl2-2, libsasl2-modules-gssapi-mit, tzdata
Peu de dépendances, mais certaines sont très importantes : openssl >=
1.0.1g et python >=
2.7.0.
Installer les packages manquants (ici 4) :
root@vps$ apt install libc++1 gdb libsss-nss-idmap0 libsasl2-modules-gssapi-mit
puis installer le package mssql-server, l’installation est très simple :
root@vps$ dpkg -i mssql-server_15.0.1600.8-1_amd64.deb
Selecting previously unselected package mssql-server. (Reading database ... 133143 files and directories currently installed.) Preparing to unpack mssql-server_15.0.1600.8-1_amd64.deb ... Unpacking mssql-server (15.0.1600.8-1) ... Setting up mssql-server (15.0.1600.8-1) ... +--------------------------------------------------------------+ Please run 'sudo /opt/mssql/bin/mssql-conf setup' to complete the setup of Microsoft SQL Server +--------------------------------------------------------------+ Processing triggers for libc-bin (2.27-3ubuntu1) ... Processing triggers for man-db (2.8.3-2ubuntu0.1) ...
La configuration sera faite ultérieurement après l’installation des packages des outils clients.
À propos de l’installation, les binaires (sqlservr
…) et les librairies sont installés dans /opt/mssql
(propriétaire : root
). Probablement qu’il est possible d’installer SQL Server dans le répertoire de son choix,
mais il est préférable d’éviter des méthodes compliquées (fakeroot…) pour une version CTP (Technology Preview) sur une version d’Ubuntu
non supportée, et plus particulièrement si un upgrade vers une version plus récente est prévu dans les semaines qui viennent.
/opt/mssql/bin
/opt/mssql/lib
Un répertoire /var/opt/mssql
est également créé (propriétaire : mssql
).
Ce répertoire contient le fichier de configuration mssql.conf
de la future instance. À cette étape, une seule entrée dans ce fichier : sqlagent désactivé.
/var/opt/mssql/mssql.conf
[sqlagent]
enabled = false
Outils clients
Pour les outils clients, installer les packages dans l’ordre ci-dessous en raison des dépendances :
- unixodbc, si il n’est pas déjà installé. La version
>= 2.3.1
est requise. - msodbcsql17 (version 17.3) : pilote Microsoft ODBC.
- mssql-tools (version 17.3) : outils sqlcmd et bcp .
Les packages sont téléchargés à partir du site web de Microsoft : https://packages.microsoft.com/ubuntu/18.04/prod/pool/main/m/. Pour les outils clients, cette fois la version exacte d’Ubuntu est sélectionnée (18.04).
- msodbcsql17 :
./msodbcsql17/msodbcsql17_17.3.1.1-1_amd64.deb
. - mssql-tools :
./mssql-tools/mssql-tools_17.3.0.1-1_amd64.deb
.
Les dépendances sont les suivantes :
root@vps$ dpkg -I msodbcsql17_17.3.1.1-1_amd64.deb | grep 'Depends:'
Depends: libc6 (>= 2.21), libstdc++6 (>= 4.9), libkrb5-3, openssl, debconf (>= 0.5), unixodbc (>= 2.3.1)
root@vps$ dpkg -I mssql-tools_17.3.0.1-1_amd64.deb | grep 'Depends:'
Depends: libc6 (>= 2.21), libstdc++6 (>= 4.9), libkrb5-3, openssl, debconf (>= 0.5), msodbcsql17 (>= 17.3.0.0), msodbcsql17 (<< 17.4.0.0)
Installer UnixOdbc >=
2.3.1 :
root@vps$ apt install unixodbc
puis les packages MS SQL Server ODBC Driver et MS SQL Server client tools :
root@vps$ dpkg -i msodbcsql17_17.3.1.1-1_amd64.deb
root@vps$ dpkg -i mssql-tools_17.3.0.1-1_amd64.deb
Microsoft ODBC SQL driver 17 est alors installé dans le répertoire /opt/microsoft/msodbcsql17
et
MS SQL Server tools (sqlcmd
et bcp
) dans le répertoire /opt/mssql-tools/bin
.
Pour un usage facile des outils sqlcmd
et bcp
, ajouter le répertoire /opt/mssql-tools/bin
dans la variable d’environnement $PATH
pour le compte mssql
. À faire dans les fichiers $HOME/.bashrc
et $HOME/.profile
.
$HOME/.bashrc, $HOME/.profile
export PATH="$PATH:/opt/mssql-tools/bin"
Construction et lancement de l’instance MS SQL Server
Configuration de l’instance SQL Server
Avant de construire l’instance, certaines options peuvent être préparées (comme par exemple la localisation des bases de données…).
Pour la liste complète des options, exécuter mssql-conf list
:
root@vps$ /opt/mssql/bin/mssql-conf list
... filelocation.defaultdatadir Default directory for data files ... filelocation.defaultlogdir Default directory for log files filelocation.errorlogfile Error log file location filelocation.masterdatafile Master database data file location filelocation.masterlogfile Master database log file location ...
Sans aucune configuration personnalisée avant le lancement de mssql-conf setup
,
les fichiers de bases de données sont créés par défaut dans le répertoire /var/opt/mssql
.
Ce n’est pas vraiment ce que l’on souhaite, notamment si les fichiers de données et journaux de transactions sont séparés sur des
supports différents, ou bien tout simplement pour installer ceux-ci sur des LUN SAN.
La configuration est donc faite juste avant, surtout la localisation des fichiers de bases de données.
Évidemment pour chaque répertoire, le propriétaire doit être mssql
.
root@vps$ /opt/mssql/bin/mssql-conf set filelocation.masterdatafile /sqlpac/mssql/system/master.mdf
root@vps$ /opt/mssql/bin/mssql-conf set filelocation.masterlogfile /sqlpac/mssql/system/mastlog.ldf
root@vps$ /opt/mssql/bin/mssql-conf set filelocation.defaultdatadir /sqlpac/mssql/dbfiles
root@vps$ /opt/mssql/bin/mssql-conf set filelocation.defaultlogdir /sqlpac/mssql/tlogfiles
root@vps$ /opt/mssql/bin/mssql-conf set filelocation.errorlogfile /opt/mssql/dba/srvmssql/log/errorlog
root@vps$ /opt/mssql/bin/mssql-conf set errorlog.numerrorlogs 10
root@vps$ /opt/mssql/bin/mssql-conf set filelocation.defaultbackupdir /opt/mssql/dba/srvmssql/backup
root@vps$ /opt/mssql/bin/mssql-conf set filelocation.defaultdumpdir /opt/mssql/dba/srvmssql/crashdump
Chaque paramètre personnalisé est consigné dans le fichier de configuration /var/opt/mssql/mssql.conf
. Ce fichier de
configuration remplace quelque peu la base de registres Windows pour un bon nombre de paramètres (default datadir…).
/var/opt/mssql/mssql.conf
[sqlagent]
enabled = false
[filelocation]
defaultdatadir = /sqlpac/mssql/dbfiles
defaultlogdir = /sqlpac/mssql/tlogfiles
masterdatafile = /sqlpac/mssql/system/master.mdf
masterlogfile = /sqlpac/mssql/system/mastlog.ldf
errorlogfile = /opt/mssql/dba/srvmssql/log/errorlog
defaultbackupdir = /opt/mssql/dba/srvmssql/backup
defaultdumpdir = /opt/mssql/dba/srvmssql/crashdump
[errorlog]
numerrorlogs = 10
Lancement de mssql-conf setup
Tout est prêt : packages serveur, clients et la configuration. L’instance est alors construite avec mssql-conf
et l’option setup
.
root@vps$ /opt/mssql/bin/mssql-conf setup
L’édition Developer est choisie et la licence est acceptée.
Un mot de passe est défini pour le login SQL Server sa
:
Enter the SQL Server system administrator password:
Confirm the SQL Server system administrator password:
Configuring SQL Server...
ForceFlush is enabled for this instance.
ForceFlush feature is enabled for log durability.
Created symlink /etc/systemd/system/multi-user.target.wants/mssql-server.service → /lib/systemd/system/mssql-server.service.
Setup has completed successfully. SQL Server is now starting.
Connexion au moteur SQL Server avec sqlcmd
La première connexion est maintenant réalisée avec le login sa
:
mssql@vps$ sqlcmd -Usa
select @@version go
Microsoft SQL Server 2019 (CTP3.0) - 15.0.1600.8 (X64) May 17 2019 00:56:19 Copyright (C) 2019 Microsoft Corporation Developer Edition (64-bit) on Linux (Ubuntu 18.04.2 LTS) <X64>
Paramètres par défaut : collation, port
Le serveur Ubuntu est installé en anglais, mais quel est alors l’interclassement par défaut ? L’interclassement appliqué est SQL_Latin1_General_CP1_CI_AS.
select name, collation_name from sys.databases where name='master' go
name collation_name ------------ ----------------------------------------------- master SQL_Latin1_General_CP1_CI_AS
exec sp_helpsort go
Server default collation ------------------------- Latin1-General, case-insensitive, accent-sensitive, kanatype-insensitive, width-insensitive for Unicode Data, SQL Server Sort Order 52 on Code Page 1252 for non-Unicode Data
Utiliser /opt/mssql/bin/mssql-conf set-collation
pour modifier si nécessaire l’interclassement des bases systèmes.
Le service SQL Server tourne sans surprise sur le port par défaut 1433 avec le compte mssql
:
netstat -tulpn | grep LISTEN | grep 'sqlservr' | grep '1433'
tcp 0 0 0.0.0.0:1433 0.0.0.0:* LISTEN 7023/sqlservr tcp6 0 0 :::1433 :::* LISTEN 7023/sqlservr
Par défaut, le nombre de processus SQL Server (sqlservr
) dépend du nombre de cores, ici 2 cores :
ps -ef | grep 'sqlservr'
mssql 7012 1 0 14:54 ? 00:00:01 /opt/mssql/bin/sqlservr mssql 7023 7012 22 14:54 ? 00:01:30 /opt/mssql/bin/sqlservr
Service mssql-server : start, stop, status
Un service mssql-server
est automatiquement créé et activé, les commandes habituelles sont disponibles pour démarrer, stopper, redémarrer
et voir le statut du service SQL Server :
root@vps$ systemctl start mssql-server root@vps$ systemctl stop mssql-server root@vps$ systemctl restart mssql-server root@vps$ systemctl status mssql-server
● mssql-server.service - Microsoft SQL Server Database Engine Loaded: loaded (/lib/systemd/system/mssql-server.service; enabled; vendor preset: enabled) Active: active (running) since wed 2019-05-29 16:27:35 CEST; 7s ago Docs: https://docs.microsoft.com/en-us/sql/linux Main PID: 8502 (sqlservr) Tasks: 129 CGroup: /system.slice/mssql-server.service ├─8502 /opt/mssql/bin/sqlservr └─8528 /opt/mssql/bin/sqlservr
Bien entendu, l’activation et la désactivation du service SQL Server est possible comme tout service.
root@vps$ systemctl enable mssql-server
root@vps$ systemctl disable mssql-server
Connexion depuis un client Windows
Si le parefeu Ubuntu ufw est configuré pour rejeter toutes les connexions entrantes par défaut, ne pas oublier d’ouvrir le port 1433 de SQL Server :
root@vps$ ufw allow 1433
Rule added Rule added (v6)
Des tests ont été réalisés avec SQL Server Management Studio 17.2 (SSMS 17.2) :
Pas de soucis immédiats, mais des erreurs apparaissent lors des reverse engineering (par exemple, clic droit sur une table : Script Table as CREATE To New Query Query Editor).
Utiliser SSMS 18, disponible depuis peu (GA), première version compatible avec SQL Server 2019 (compatibility level 150). Comme d’habitude, une installation très longue, des problèmes rencontrés, et un bon nombre d’applications dépendantes installées (.NET Framework 4.7.2, Visual Studio Isolated Shell 2017 for SSMS, Microsoft Visual Studio Tools for Applications 2017…).
Transferts de données cross platformes Windows / Linux (backup, restore, bcp)
Backup / Restore
Un test a été fait pour restaurer une sauvegarde de la base de démo AdventureworksDW2016CTP3, sauvegarde venant de Windows SQL Server 2016.
Tout est OK ! Aucune étape supplémentaire dans ce contexte cross-plateforme, la commande dbcc checkdb
n’a pas remonté
d’exceptions. De plus, la migration vers SQL Server 2019 est effectuée normalement comme si nous étions sur une plateforme Windows.
restore database AdventureworksDW from disk='/opt/mssql/dba/srvmssql/backup/win/AdventureworksDW2016CTP3.bak' with move 'AdventureWorksDW2014_Data' to '/sqlpac/mssql/dbfiles/AdventureworksDW.mdf', move 'AdventureWorksDW2014_Log' to '/sqlpac/mssql/tlogfiles/AdventureworksDW.ldf', replace go
Processed 186680 pages for database 'AdventureworksDW', file 'AdventureWorksDW2014_Data' on file 1. Processed 3 pages for database 'AdventureworksDW', file 'AdventureWorksDW2014_Log' on file 1. Converting database 'AdventureworksDW' from version 835 to the current version 902. Database 'AdventureworksDW' running the upgrade step from version 835 to version 836. ... Database 'AdventureworksDW' running the upgrade step from version 901 to version 902. RESTORE DATABASE successfully processed 186683 pages in 15.777 seconds (92.442 MB/sec).
dbcc checkdb('AdventureworksDW') go
DBCC results for 'AdventureworksDW'. ... CHECKDB found 0 allocation errors and 0 consistency errors in database 'AdventureworksDW'.
CREATE DATABASE FOR ATTACH
Quant à attacher des fichiers de données et des journaux de transactions venant de Windows SQL Server 2016, mêmes résultats : aucun problème et la migration est opérée.
create database AdventureworksDW on (filename = '/sqlpac/mssql/dbfiles/AdventureworksDW.mdf'), (filename = '/sqlpac/mssql/tlogfiles/AdventureworksDW.ldf') for attach go
Converting database 'AdventureworksDW' from version 852 to the current version 902. ... Database 'AdventureworksDW' running the upgrade step from version 901 to version 902.
bcp out / in avec des données Unicode de Windows vers Linux
Dans un serveur Windows SQL Server 2016, des données en unicode sont insérées dans une table appelée t_bcp_unicode
dans le but de tester le transfer avec bcp out / in en mode natif.
create table t_bcp_unicode
( lang varchar(20) not null,
comment nvarchar(200) not null)
go
insert into t_bcp_unicode values ('FR','Une rue française')
go
insert into t_bcp_unicode values ('DE','eine Straße')
go
insert into t_bcp_unicode values ('CH',N'一条街')
go
insert into t_bcp_unicode values ('RU',N'улица')
go
insert into t_bcp_unicode values ('GR',N'ένα δρόμο')
go
Les données sont exportées dans un fichier avec bcp SQL Server 2016 en mode natif :
SRVWIN> bcp sqlpac..t_bcp_unicode out t_bcp_unicode.bcpc -Slocalhost -T -n
L’import dans SQL Server 2019 / Linux est alors réalisé et sans aucun problème :
mssql@vps$ bcp sqlpac..t_bcp_unicode in t_bcp_unicode.bcpn -Svps -Usa -n
mssql@vps$ sqlcmd -Usa
use sqlpac go select * from t_bcp_unicode go
lang comment -------------------- ----------------------------------- FR Une rue française DE eine Straße CH 一条街 RU улица GR ένα δρόμο
Conclusion
Les instances nommées et multiples ne sont pas (encore ?) possibles, mais il est très facile de construire SQL Server sur Linux. De plus, les bases de données SQL Server peuvent être attachées ou chargées depuis les environnements windows sans étapes supplémentaires, ce qui est en fait peu surprenant, Windows et Linux étant toutes deux des plateformes de type "Little Endian" (numérotation des octets de droite à gauche).
Malheureusement, des benchmarks n’ont pas encore été menés, n’ayant pas des machines avec les mêmes caractéristiques matérielles, mais il y a un bon article sur ce sujet : Microsoft SQL Server 2017 plus rapide sous Linux que Windows ? Pas si sûr…