SQL Server Linux-ზე: რა მუშაობს და რა აკლია

SQL Server Linux-ზე იგივე მონაცემთა ბაზის ძრავია, რაც Windows-ზე, და არა პორტი ან შეკვეცილი გადაწერა. T-SQL იდენტურია, .bak ფაილები ურთიერთჩანაცვლებადია, SSMS და ყველა დრაივერი მას ერთნაირად უკავშირდება, და აპლიკაცია ვერ გაარჩევს, რომელი ოპერაციული სისტემაა ქვემოთ. განსხვავებულია ყველაფერი ძრავის გარშემო: მას mssql-conf-ით და გარემოს ცვლადებით აკონფიგურირებ და არა SQL Server Configuration Manager-ით, მისი ფაილები /var/opt/mssql-ში ცხოვრობს, გზები რეგისტრს არჩევს, და Windows-ზე ორიენტირებული ფუნქციების სია იქ საერთოდ არ არის. აპლიკაციის ბაზისთვის დაკარგული ფუნქციებიდან ჩვეულებრივ არცერთი არ არის მნიშვნელოვანი. DBA-სთვის, რომელსაც Windows-იდან ჩვევები მოაქვს, რამდენიმე მნიშვნელოვანია.

ეს გზამკვლევი განიხილავს SQL Server 2022-ს Linux-ზე, მათ შორის Express ედიციას, რომელსაც პატარა ჰოსტინგის სერვერები უშვებს, და ყურადღებით ასხვავებს, რომელი განსხვავება მოდის Linux-იდან და რომელი Express-იდან.

როგორ უშვებს Microsoft Windows-ის ძრავს Linux-ზე#

SQL Server ოცდაათი წლის განმავლობაში Windows-ისთვის იწერებოდა და Microsoft-ს ის არ გადაუწერია. SQL Server 2017-დან ძრავი მუშაობს SQL Platform Abstraction Layer-ზე, SQLPAL-ზე - პატარა ბიბლიოთეკურ ოპერაციულ სისტემაზე, რომელიც ძრავს აძლევს Windows-ის ფორმის სერვისებს, რომლებსაც ის ელის (მეხსიერების მართვა, ნაკადები, I/O), და მათ ქვემოთ Linux-ის გამოძახებებად თარგმნის. პროცესი, რომელსაც ps-ში ხედავ, არის sqlservr, რომელიც mssql მომხმარებლით მუშაობს, და ჩვეულებრივ ინსტალაციაზე მას systemd მართავს როგორც mssql-server სერვისს.

პრაქტიკული შედეგები:

• წარმადობა შესადარისია. Microsoft ორივე პლატფორმისთვის აქვეყნებს benchmark-ის შედეგებს, და ჩვეულებრივ დატვირთვებზე ოპერაციულ სისტემას მიკუთვნებად მნიშვნელოვან სხვაობას ვერ იპოვი.
• ძრავის ვერსია იგივეა. SQL Server 2022 Linux-ზე იღებს იმავე cumulative update-ებს, იმავე compatibility level 160-ს და იმავე query optimiser-ს, რაც Windows-ზე.
• მეხსიერებას ძრავი მართავს და ის kernel-ს არ ეთმობა. SQL Server Linux-ზე თავს თავად ზღუდავს, ნაგულისხმევად მისთვის ხილული მეხსიერების 80 პროცენტით, რომ out-of-memory killer-მა არ მოკლას. კონტეინერის შიგნით ახალი build-ები კონტეინერის მეხსიერების ლიმიტს კითხულობენ და არა ჰოსტის ჯამურ მოცულობას.

ბოლო პუნქტი ჰოსტინგის სერვერებზე მნიშვნელოვანია. SQL Server, რომელსაც ჰგონია, რომ ჰოსტის 128 GB აქვს, მხიარულად გაიზრდება, სანამ კონტეინერი თავის რეალურ ლიმიტზე არ გაჩერდება. თუ SQL Server-ს შენს საკუთარ კონტეინერში უშვებ, ლიმიტი აშკარად დააყენე და აღმოჩენას ნუ ენდობი; Linux-ზე kernel-ის out-of-memory ქცევა დაუნდობელია, როგორც Linux swap და OOM killer ხსნის.

ედიციები Linux-ზე და რას ამატებს სურათს Express#

ყველა ედიცია არსებობს Linux-ზე: Express, Developer, Standard, Enterprise, პლუს Evaluation. ედიცია ინსტალაციისას ირჩევა, ან ინტერაქტიულად mssql-conf setup-ით, ან კონტეინერში MSSQL_PID გარემოს ცვლადით (Express, Developer, Standard, Enterprise ან პროდუქტის გასაღები).

Express უფასოა და სრულად ფუნქციონალური ფიქსირებული ზღვრების ფარგლებში, რომლებიც ორივე ოპერაციულ სისტემაზე მოქმედებს:

ეს ედიციის ზღვრებია და არა Linux-ის, მაგრამ ისინი განსაზღვრავს, როგორ იქცევა Linux-ის Express სერვერი. კერძოდ, buffer pool-ის ზღვარი ნიშნავს, რომ Express ინსტანციისთვის 6 GB მეხსიერების მიცემა მას 6 GB-იან cache-ს არ აძლევს: მონაცემთა cache დაახლოებით 1.4 GB-ზე ჩერდება, დანარჩენი კი plan cache-ს, query-ის სამუშაო მეხსიერებას, კავშირებსა და ოპერაციულ სისტემას ემსახურება. მეტი მეხსიერება მაინც გეხმარება, მაგრამ არა წრფივად. SQL Server Express ჰოსტინგი განიხილავს, როდის არის ეს ზღვრები საკმარისი.

კონფიგურაცია: mssql-conf და გარემოს ცვლადები#

Windows-ზე ინსტანციის დონის პარამეტრებს SQL Server Configuration Manager-სა და რეესტრში ცვლი. Linux-ზე ეკვივალენტი არის mssql-conf, სკრიპტი, რომელიც /var/opt/mssql/mssql.conf-ს არედაქტირებს:

$ sudo /opt/mssql/bin/mssql-conf set memory.memorylimitmb 3072$ sudo /opt/mssql/bin/mssql-conf set network.tcpport 1433$ sudo /opt/mssql/bin/mssql-conf set filelocation.defaultbackupdir /var/opt/mssql/backup$ sudo /opt/mssql/bin/mssql-conf traceflag 1222 on$ sudo systemctl restart mssql-server

ცვლილებების უმეტესობა მხოლოდ restart-ის შემდეგ ამოქმედდება. თავად ფაილი ჩვეულებრივი INI-ა და იკითხება:

[memory]memorylimitmb = 3072[network]tcpport = 1433[filelocation]defaultbackupdir = /var/opt/mssql/backup[traceflag]traceflag0 = 1222

პარამეტრები, რომლებსაც სავარაუდოდ შეეხები:

კონტეინერში იგივე პარამეტრები ჩვეულებრივ გარემოს ცვლადებად გადაეცემა პირველი გაშვებისას: ACCEPT_EULA=Y, MSSQL_SA_PASSWORD, MSSQL_PID, MSSQL_COLLATION, MSSQL_TCP_PORT, MSSQL_MEMORY_LIMIT_MB, MSSQL_DATA_DIR, MSSQL_LOG_DIR და MSSQL_BACKUP_DIR. ძველი ცვლადი SA_PASSWORD ზოგიერთ image-ზე ჯერ კიდევ მუშაობს და მოძველებულად არის გამოცხადებული.

sp_configure-ით დაყენებული max server memory Linux-ზეც არსებობს და კვლავ ზღუდავს buffer pool-ს და დაკავშირებულ cache-ებს. ის memory.memorylimitmb-ის შიგნით ჯდება, რომელიც მთელ პროცესს ზღუდავს. თუ ორივეს აკონტროლებ, memorylimitmb დააყენე იმაზე, რისი დათმობაც მანქანას შეუძლია, max server memory კი მასზე ცოტა დაბლა.

მართვად ჰოსტზე mssql-conf-ის გაშვება ჩვეულებრივ საერთოდ არ შეგიძლია - ინსტანციის კონფიგურაცია ჰოსტს ეკუთვნის და ის შენ sa-ს გაძლევს. ყველაფერი, რისი შეცვლაც T-SQL-იდან შეგიძლია (sp_configure, ALTER DATABASE, ALTER SERVER CONFIGURATION), კვლავ მუშაობს, და ეს თითქმის ყველაფერს ფარავს, რაც აპლიკაციას სჭირდება.

ფაილები, გზები და რეგისტრის მგრძნობელობა#

ნაგულისხმევი ინსტალაცია ყველაფერს /var/opt/mssql-ში ინახავს:

/var/opt/mssql/  data/       system and user database files (.mdf, .ldf), default backups  log/        errorlog, errorlog.1 ... and extended event files  secrets/    the machine key  mssql.conf  the configuration file

ბინარები /opt/mssql/-შია, ბრძანების ხაზის ინსტრუმენტები კი /opt/mssql-tools18/bin/-ში მიმდინარე version 18-ის პაკეტებისთვის (/opt/mssql-tools/bin/ ძველებისთვის). error log ტექსტური ფაილია, რომლის წაკითხვაც ნებისმიერი ინსტრუმენტით შეგიძლია, რაც ხშირად უფრო სწრაფია, ვიდრე SSMS-ით გახსნა:

$ sudo tail -n 50 /var/opt/mssql/log/errorlog

გზებთან დაკავშირებით ორი რამ აბნევს Windows-იდან გადმოსულებს:

1. ფაილური სისტემა რეგისტრს არჩევს. /var/opt/mssql/Data/app.mdf და /var/opt/mssql/data/app.mdf სხვადასხვა ფაილია. BACKUP ან RESTORE ... WITH MOVE არასწორი რეგისტრით ჩავარდება operating system error 2-ით.
2. გზები სერვერს ეკუთვნის. RESTORE DATABASE ... FROM DISK = 'C:\backups\app.bak', შენი ლეპტოპის SSMS-იდან გაშვებული, ამ ფაილს Linux მანქანაზე ეძებს. ჯერ ფაილი სერვერზე დააკოპირე.

ფაილური სისტემის რეგისტრის მგრძნობელობა ცალკე საკითხია შენი მონაცემების რეგისტრის მგრძნობელობისგან. უდრის თუ არა 'Smith' = 'smith', collation წყვეტს, ზუსტად ისე, როგორც Windows-ზე. Linux-ზე სერვერის ნაგულისხმევი collation არის SQL_Latin1_General_CP1_CI_AS, რომელიც რეგისტრს არ არჩევს, ამიტომ ცხრილების სახელები, სვეტების სახელები და შედარებები ისე იქცევა, როგორც Windows-ის მომხმარებლები ელიან. ის ინსტალაციისას ირჩევა MSSQL_COLLATION-ით ან mssql-conf set-collation-ით, დეტალებს კი SQL Server-ის collation-ები და Unicode განიხილავს.

რა აკლია Linux-ზე#

Microsoft ინახავს Linux-ზე მხარდაუჭერელი ფუნქციების ოფიციალურ სიას, რომელიც ვერსიებსა და cumulative update-ებს შორის იცვლება, ამიტომ შეამოწმე ის შენი ზუსტი build-ისთვის. SQL Server 2022-ის მდგომარეობით მთავარი ხარვეზებია:

რაც თავიდან აკლდა და ახლა არსებობს: თავად SQL Server Agent (ფასიან ედიციებზე), full-text ძებნა (ცალკე პაკეტი mssql-server-fts), Database Mail, განაწილებული ტრანზაქციები MSDTC-ით, Active Directory ავთენტიფიკაცია დამატებითი მოწყობით და Always On availability group-ები Pacemaker-ით Windows Server Failover Clustering-ის ნაცვლად.

იმპორტისთვის ერთი უსაფრთხოების განსხვავებაა მნიშვნელოვანი. Linux-ზე ფიქსირებული სერვერის როლი bulkadmin მხარდაჭერილი არ არის, ამიტომ BULK INSERT-ს და OPENROWSET(BULK ...)-ს sysadmin სჭირდება. login-ი, რომელსაც მხოლოდ ბაზის უფლებები აქვს, სერვერის დისკიდან ფაილებს ვერ ჩატვირთავს; ამის ნაცვლად გამოიყენე bcp ან აპლიკაციის მხარეს bulk copy ქსელით, რასაც sqlcmd და bcp განიხილავს.

მეორე ჩვევა, რომელიც უნდა დატოვო, Windows ავთენტიფიკაციაა. ჰოსტინგის Linux ინსტანცია SQL authentication-ს იყენებს: login-ის სახელს და პაროლს, მათ შორის sa-ს. connection string-ები Integrated Security=true-ით ან Trusted_Connection=yes-ით მასთან არ იმუშავებს.

SQL Server-ის თავად გაშვება Linux-ზე#

მანქანაზე, რომელსაც შენ აკონტროლებ, მხარდაჭერილი პლატფორმებია Red Hat Enterprise Linux, SUSE Linux Enterprise Server და Ubuntu (ზუსტი ვერსიებისთვის Microsoft-ის მიმდინარე სია შეამოწმე, რადგან ის ყოველ რელიზთან იცვლება), პლუს ოფიციალური კონტეინერის image. კონტეინერი ბევრად ყველაზე სწრაფი გზაა დეველოპმენტისთვის ლოკალური ინსტანციის მისაღებად:

$ docker run -d --name sql2022 \    -e ACCEPT_EULA=Y \    -e MSSQL_SA_PASSWORD='Choose-a-long-one-9' \    -e MSSQL_PID=Express \    -p 1433:1433 \    -v sqldata:/var/opt/mssql \    mcr.microsoft.com/mssql/server:2022-latest

პაროლი ნაგულისხმევ პოლიტიკას უნდა აკმაყოფილებდეს - მინიმუმ რვა სიმბოლო ოთხიდან სამი კლასიდან: დიდი ასოები, პატარა ასოები, ციფრები და სიმბოლოები - თორემ კონტეინერი ჩაირთვება და მაშინვე გავა, log-ში პაროლის შეცდომით. /var/opt/mssql-ზე volume მიამაგრე, თორემ ბაზები კონტეინერთან ერთად გაქრება. SQL Server 2019-დან image არა-root mssql მომხმარებლით მუშაობს, ამიტომ bind-mount-ით მიმაგრებული დირექტორია ამ მომხმარებლის ID-სთვის ჩაწერადი უნდა იყოს.

CPU-ს მხრივ, SQL Server-ს Linux-ისთვის x86-64 სჭირდება. native ARM build არ არსებობს, რისი ცოდნაც ღირს ARM-ის სადეველოპერო ლეპტოპის ან ARM სერვერის ყიდვამდე.

RE:NODE-ზე SQL Server-ის ხაზი უშვებს SQL Server 2022 Express-ს Linux-ზე, საკუთარ კონტეინერში. sa პაროლი გენერირდება, ბაზა შენთვის იქმნება და sa-ს ნაგულისხმევად ყენდება, SSMS კი უკავშირდება სერვერის სახელით, დაწერილი როგორც host,port მძიმით. მუშაობ T-SQL-ით და იმ ინსტრუმენტებით, რომლებიც უკვე გაქვს; ინსტანციის დონის კონფიგურაციას შენ მაგივრად აგვარებენ.

განახლებები და ვერსიები Linux-ზე#

Windows-ზე cumulative update-ები ინსტალერებად მოდის, ხშირად Windows Update-ით. Linux-ზე SQL Server ჩვეულებრივი პაკეტია Microsoft-ის რეპოზიტორიიდან, და განახლება არის პაკეტის upgrade, რასაც სერვისის restart მოჰყვება:

$ sudo apt-get update$ sudo apt-get install mssql-server     # Ubuntu$ sudo yum update mssql-server          # Red Hat

რეპოზიტორია, რომელსაც დაარეგისტრირებ, განსაზღვრავს major ვერსიას და განახლების არხს. Microsoft ყოველი major ვერსიისთვის აქვეყნებს cumulative-update რეპოზიტორიას და GDR რეპოზიტორიას (მხოლოდ უსაფრთხოების გასწორებები), და დამატებისას ერთს ირჩევ. უკან დაბრუნება ნიშნავს კონკრეტული ადრეული პაკეტის ვერსიის დაყენებას, რასაც პაკეტების მენეჯერი გააკეთებს, თუ მას დაასახელებ - რაც Windows-ის ინსტალერს ასე მარტივად არასოდეს გაუხდია.

კონტეინერებში image-ის tag არის ვერსია. mcr.microsoft.com/mssql/server:2022-latest ყოველ cumulative update-თან ერთად მოძრაობს, რაც დეველოპმენტისთვის მოსახერხებელია და ცუდი იდეაა ყველაფრისთვის, რაც გაინტერესებს, რადგან ხელახლა ჩამოტვირთულ კონტეინერს შეუძლია ჩუმად შეცვალოს build. production-ში კონკრეტული cumulative-update-ის tag დააფიქსირე და განაახლე შეგნებულად. volume-ზე არსებული ბაზის ფაილები ადგილზე განახლდება, როცა მათ პირველად უფრო ახალი build ხსნის, და აღდგენილი backup-ის მსგავსად, შემდეგ მათ ძველი build ვეღარ გახსნის. ყოველ განახლებამდე backup აიღე - იგივე წესია, რაც Windows-ზე, და ისეთივე მნიშვნელოვანი.

იმის სანახავად, რას უშვებ სინამდვილეში, ნებისმიერი კლიენტიდან:

SELECT @@VERSION;SELECT SERVERPROPERTY('ProductVersion')     AS version,       SERVERPROPERTY('ProductUpdateLevel') AS cu,       SERVERPROPERTY('Edition')            AS edition;

@@VERSION Linux-ზე build-თან ერთად დისტრიბუციასაც ასახელებს, რაც ყველაზე სწრაფი გზაა იმის დასადასტურებლად, რომ ჰოსტინგის ინსტანცია Linux-ია და რომელი ედიციაა.

რა იცვლება შენი აპლიკაციისთვის#

ჩვეულებრივ არაფერი. დრაივერები იმავე TDS პროტოკოლით ელაპარაკებიან იმავე ძრავს, ამიტომ connection string, რომელიც Windows-ზე მუშაობს, Linux-ზეც იმუშავებს, როგორც კი სწორ ჰოსტსა და პორტზე მიუთითებს და SQL authentication-ს გამოიყენებს. დეტალები, რომელთა შემოწმებაც ღირს:

• დაშიფვრის ნაგულისხმევები. ახალი დრაივერები - Microsoft.Data.SqlClient 4.0 და შემდეგი, ODBC Driver 18, version 18-ის ბრძანების ხაზის ინსტრუმენტები - ნაგულისხმევად შიფრავენ და სერტიფიკატს ამოწმებენ. self-signed სერტიფიკატი მაშინ შემოწმებას ვერ გაივლის; ან აშკარად ენდე მას (TrustServerCertificate=True), ან ნამდვილი დააყენე. SQL Server-ის connection string-ები თითოეული დრაივერის ზუსტ საკვანძო სიტყვებს შეიცავს.
• პორტი. ჰოსტინგის ინსტანციები ხშირად არანაგულისხმევ პორტს უსმენენ, და SQL Server-ის სინტაქსი ამისთვის მძიმეა: db.example.net,14330 და არა ორწერტილი.
• ფაილების გზები შენს კოდში. ყველაფერს, რაც BACKUP, BULK INSERT ან CREATE DATABASE ინსტრუქციებს C:\ გზებით აგებს, Linux-ის გზები სჭირდება.
• ყველაფერი, რაც `xp_cmdshell`-ს, OLE automation-ს ან unsafe CLR-ს იყენებს. ის ბაზიდან აპლიკაციაში ან სკრიპტში უნდა გადავიდეს.

არსებული ბაზის გადატანა ჩვეულებრივი backup და აღდგენაა, WITH MOVE-ით, რომელიც ყოველ ფაილს Linux-ის გზაზე მიუთითებს; ბაზის მიგრაცია SQL Server ჰოსტინგზე ამას ნაბიჯ-ნაბიჯ გადის.

Linux ინსტანციის პრობლემების მოგვარება#

სერვისი კონფიგურაციის ცვლილების შემდეგ არ ირთვება. წაიკითხე /var/opt/mssql/log/errorlog და journalctl -u mssql-server. ჩვეული მიზეზებია ძრავის მინიმუმზე დაბალი მეხსიერების ლიმიტი, TLS სერტიფიკატის ფაილი, რომელსაც mssql მომხმარებელი ვერ კითხულობს, ან მონაცემთა დირექტორია არასწორი მფლობელით.

Operating system error 5 ან 13 BACKUP-ზე ან RESTORE-ზე. უფლებები. mssql მომხმარებელს უნდა შეეძლოს backup ფაილის წაკითხვა და სამიზნე დირექტორიაში ჩაწერა.

დისტანციურად დაკავშირება შეუძლებელია. შეამოწმე, რომ პორტი უსმენს (ss -ltnp | grep 1433), რომ firewall მას უშვებს და რომ კლიენტი პორტისთვის მძიმეს იყენებს. კლიენტის "Named Pipes Provider" შეცდომები ნიშნავს, რომ ის სერვერამდე საერთოდ ვერ მივიდა.

Login failed for user 'sa'. Linux-ზე Windows ავთენტიფიკაციის სარეზერვო ვარიანტი არ არსებობს. პაროლი გადააყენე mssql-conf set-sa-password-ით, სანამ სერვისი გაჩერებულია, მანქანაზე, რომელსაც აკონტროლებ; ჰოსტინგის სერვერზე გამოიყენე პაროლი, რომელიც ჰოსტმა დააგენერირა.

FAQ#

არის SQL Server Linux-ზე Windows-ზე ნელი?

არა ისე, რომ აპლიკაციის ბაზისთვის შეამჩნიო. ეს იგივე ძრავია იმავე optimiser-ით, და Microsoft ორივეს თანაბრად უჭერს მხარს. საცავის სიჩქარე, მეხსიერება და query-ების დიზაინი ოპერაციულ სისტემაზე ბევრად დიდ სხვაობას ქმნის.

შემიძლია SSMS-ის გამოყენება SQL Server-თან Linux-ზე?

დიახ. SSMS Windows-ზე მუშაობს და ქსელით უკავშირდება ინსტანციას ნებისმიერ პლატფორმაზე. SSMS-ის რამდენიმე ფუნქცია, რომელიც სერვერზე Windows-ს ეყრდნობა, მაგალითად Agent job-ის ნაბიჯების ზოგიერთი ტიპი, არ იმოქმედებს, მაგრამ დათვალიერება, query-ები, backup-ები და execution plan-ები ყველა მუშაობს.

მჭირდება ლიცენზია SQL Server Express-ისთვის Linux-ზე?

არა. Express production-ში გამოსაყენებლად უფასოა Linux-ზე, ისევე როგორც Windows-ზე, თავისი ზღვრების ფარგლებში: 10 GB თითო ბაზაზე, ოთხი ბირთვი და დაახლოებით 1.4 GB buffer pool-ის მეხსიერება. Developer ედიციაც უფასოა, მაგრამ მხოლოდ დეველოპმენტისა და ტესტირებისთვის.

უჭერს SQL Server Linux-ზე მხარს Windows ავთენტიფიკაციას?

მხოლოდ Linux მანქანაზე დამატებითი Active Directory კონფიგურაციით. ჰოსტინგის ინსტანციები SQL authentication-ს იყენებენ login-ით და პაროლით, რასაც ყველა დრაივერი უჭერს მხარს. ამოიღე Trusted_Connection და Integrated Security შენი connection string-ებიდან.

ცხრილების სახელები Linux-ზე რეგისტრს არჩევს?

ნაგულისხმევად არა. ობიექტების სახელები ბაზის collation-ს მიჰყვება, რომელიც ნაგულისხმევად რეგისტრს არ არჩევს, ამიტომ Orders და orders ერთი და იგივე ცხრილია. ფაილების გზები კი რეგისტრს არჩევს, რადგან ისინი Linux-ის ფაილურ სისტემას ეკუთვნის.