MySQL Minecraft plugin-ებისა და ქსელებისთვის

Minecraft plugin-ების უმეტესობას MySQL არ სჭირდება. ისინი მონაცემებს საკუთარ საქაღალდეში YAML ფაილებში, SQLite-ში ან H2-ში ინახავენ და ერთ სერვერზე ეს სავსებით საკმარისია. ნამდვილი მონაცემთა ბაზის სერვერი - MySQL, MariaDB, ან PostgreSQL, სადაც plugin მას უჭერს მხარს - ორ შემთხვევაში გჭირდება: როცა რამდენიმე სერვერმა ერთი და იგივე მონაცემები უნდა დაინახოს (უფლებები, ban-ები, ეკონომიკა მთელ ქსელში), ან როცა plugin იმდენს წერს, რომ ლოკალური ფაილური ბაზა ვიწრო ადგილად იქცევა, რაც პრაქტიკაში დატვირთულ სერვერზე CoreProtect-ს ნიშნავს. დანარჩენი ყველაფერი შეიძლება იქ დარჩეს, სადაც არის.

ეს პოსტი განიხილავს, რომელი plugin-ები იგებენ, როგორ დააკავშირო ისინი სწორი პარამეტრებით, რამდენ კავშირს ხსნიან, და რა უნდა გააზიარო ქსელში და რა - ცალკე დატოვო.

როდის ღირს მონაცემთა ბაზა და როდის არა#

Plugin-ის მიერ შენახვის არჩევანი ორ რამეს წყვეტს: ვის შეუძლია მონაცემების წაკითხვა და რამდენად სწრაფად შეიძლება მათი ჩაწერა.

ლოკალური შენახვა - YAML, SQLite, H2 - სერვერის საკუთარ დისკზეა და მისი გამოყენება მხოლოდ ამ სერვერის პროცესს შეუძლია. არანაირ მოწყობას არ საჭიროებს, არაფრის გაშვებული შენარჩუნება არ სჭირდება და სერვერის დანარჩენ საქაღალდესთან ერთად ხვდება backup-ში. მისი შეზღუდვებია ერთდროულობა (SQLite და H2 ჩაწერებს რიგში აყენებს) და მისაწვდომობა (მეორე სერვერი მას ვერ ხედავს).

მონაცემთა ბაზის სერვერი ცალკე პროცესია, რომელსაც ქსელით უკავშირდები. მას ერთდროულად ნებისმიერი რაოდენობის Minecraft სერვერი შეიძლება დაუკავშირდეს, ერთდროულ ჩაწერებს სწორად უმკლავდება და მისი მოთხოვნა თამაშის გარედანაც შეიძლება - მაგალითად ვებსაიტიდან, რომელიც ban-ების სიას ან მოთამაშეთა სტატისტიკას აჩვენებს. ფასი კიდევ ერთი გაშვებული სერვისია, კიდევ ერთი მონაცემების ნაკრები, კიდევ ერთი რამ, რისი backup-იც საჭიროა, და რამდენიმე მილიწამის დაყოვნება ყოველ მოთხოვნაზე.

ხაფანგი ისაა, რომ ყველაფერი MySQL-ზე გადაიტანო, რადგან რომელიღაც გზამკვლევმა თქვა, რომ ეს "უკეთესია". Plugin, რომელიც ოც კილობაიტ კონფიგურაციის მსგავს მონაცემს ინახავს და გაშვებისას ერთხელ კითხულობს, ვერაფერს იგებს, სამაგიეროდ ახლა დამოკიდებულია იმაზე, რომ ბაზა სერვერის გაშვებამდე იყოს ჩართული.

Plugin-ები, რომლებიც ბაზას უჭერენ მხარს, და რას ინახავენ#

ეს ყველაზე გავრცელებულებია. ზუსტი გასაღებების საკითხში შენი ვერსიისთვის თითოეული plugin-ის საკუთარი wiki არის ავტორიტეტი; ქვემოთ მოცემული ფორმები ამჟამინდელია.

ზოგიერთ ეკონომიკის plugin-საც შეუძლია ბაზის გამოყენება; EssentialsX-ს არ შეუძლია და ბალანსებს თითო მოთამაშის YAML ფაილებში ინახავს - ეკონომიკის გზამკვლევი ბაზაზე დაფუძნებულ ალტერნატივებს განიხილავს.

რუკის plugin-ები განსაკუთრებული შემთხვევაა. Tile-ების ბაზაში შენახვა შესაძლებელია, მაგრამ იშვიათად არის მომგებიანი: ის სურათების დიდ, ძირითადად სტატიკურ ნაკრებს ბაზაში გადაიტანს, რომლის backup-იც და მიწოდებაც შემდეგ საჭიროა. რუკის tile-ები დისკზე დატოვე, თუ კონკრეტული მიზეზი არ გაქვს - Dynmap და BlueMap ამ არჩევანს ხსნის.

ბაზისა და მომხმარებლის შექმნა#

რომელ ძრავასაც არ უნდა იყენებდე, ნიმუში ერთია: ერთი ბაზა (ან ერთი ცხრილის პრეფიქსი) plugin-ის თითო დანიშნულებაზე, ერთი მომხმარებელი, რომელსაც უფლებები მხოლოდ ამ ბაზაზე აქვს, და ძლიერი გენერირებული პაროლი.

ბაზის სერვერზე, რომელსაც თავად მართავ, MySQL-ში ან MariaDB-ში:

CREATE DATABASE mc_luckperms CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;CREATE USER 'mc_luckperms'@'%' IDENTIFIED BY 'a-long-generated-password';GRANT ALL PRIVILEGES ON mc_luckperms.* TO 'mc_luckperms'@'%';FLUSH PRIVILEGES;

utf8mb4 მნიშვნელოვანია. მოთამაშეები emoji-ებს და არალათინურ სიმბოლოებს სახლების, მაღაზიების, ნიკნეიმების სახელებში და ჩატში წერენ; MySQL-ის ძველი utf8 კოდირება თითო სიმბოლოზე მხოლოდ სამ ბაიტს ინახავს და ძირითადი სიბრტყის გარეთ ყველაფერზე ეცემა. თანამედროვე plugin-ების უმეტესობა ცხრილებს utf8mb4-ში ქმნის, თუ ბაზის ნაგულისხმევი ამის საშუალებას იძლევა.

'%' კავშირებს ნებისმიერი მისამართიდან უშვებს. თუ ბაზა და Minecraft სერვერები კერძო ქსელში არიან, ნაცვლად ამ დიაპაზონით შეზღუდე. თუ ბაზა ინტერნეტიდან მისაწვდომია, ძლიერი პაროლი ერთადერთია, რაც მას პლანეტის ყველა სკანერისგან ჰყოფს - იხილე ბაზის უსაფრთხოების ჩამონათვალი.

პანელ ჰოსტზე ამ ბრძანებებს ჩვეულებრივ თავად არ უშვებ. RE:NODE-ზე ყოველ Minecraft გეგმაში შედის ბაზის slot: მას პანელიდან ქმნი და მას მოჰყვება გენერირებული host, user და პაროლი, პლუს ღილაკი "Open in phpMyAdmin", რომელიც ერთჯერადი token-ით შეგიყვანს ცხრილების დასათვალიერებლად და მოთხოვნების გასაშვებად. ეს სამი მნიშვნელობა არის ის, რასაც plugin-ის კონფიგურაციაში ჩასვამ.

LuckPerms-ის დაკავშირება#

LuckPerms არის plugin, რომელსაც ხალხის უმეტესობა პირველს გადაიტანს, და მისი კონფიგურაცია კარგი შაბლონია დანარჩენებისთვის. plugins/LuckPerms/config.yml-ში:

storage-method: mysqldata:  address: db.example.com:3306  database: mc_luckperms  username: mc_luckperms  password: 'a-long-generated-password'  pool-settings:    maximum-pool-size: 10    minimum-idle: 10    maximum-lifetime: 1800000    keepalive-time: 0    connection-timeout: 5000  table-prefix: 'luckperms_'messaging-service: auto

ხაზები, რომლებიც მნიშვნელოვანია:

• storage-method დისტანციური შენახვისთვის იღებს mysql, mariadb, postgresql ან mongodb მნიშვნელობას. თუ სერვერი MariaDB-ა, გამოიყენე mariadb; დრაივერები ოდნავ განსხვავდება.
• address პორტსაც შეიცავს. თუ არ მიუთითებ, ძრავას ნაგულისხმევი პორტი იგულისხმება.
• messaging-service: auto LuckPerms-ს აიძულებს, ცვლილებები სერვერებს შორის გაავრცელოს. SQL შენახვით და Redis-ის გარეშე ის ბაზის პერიოდულ შემოწმებაზე გადადის. სწორედ ეს ხდის ისე, რომ /lp user Steve parent add vip ერთ სერვერზე დანარჩენებზეც გადატვირთვის გარეშე მოქმედებს.

არსებული უფლებების გადასატანად, ნულიდან დაწყების ნაცვლად, ძველ შენახვაზე გაუშვი /lp export backup, შეცვალე კონფიგურაცია, გადატვირთე, შემდეგ /lp import backup. Export LuckPerms-ის საქაღალდეში შეკუმშულ ფაილად ჩნდება; ნებისმიერ შემთხვევაში backup-ად შეინახე. როცა შენახვა მოწესრიგდება, LuckPerms-ის გზამკვლევი ჯგუფებსა და კონტექსტებს განიხილავს.

CoreProtect-ის დაკავშირება#

CoreProtect ლოგავს ყოველ ბლოკის ცვლილებას, კონტეინერის ტრანზაქციას და ჩატის ხაზს. დატვირთულ survival სერვერზე ეს კვირაში მილიონობით სტრიქონია და SQLite იწყებს გაჭირვებას - ძებნას წამები სჭირდება, ხოლო რიგი, რომელიც ლოგებს წერს, შეიძლება ჩამორჩეს. სწორედ მაშინ ამართლებს MySQL.

use-mysql: truetable-prefix: co_mysql-host: db.example.commysql-port: 3306mysql-database: mc_coreprotectmysql-username: mc_coreprotectmysql-password: 'a-long-generated-password'

CoreProtect SQLite-ის მონაცემებს MySQL-ში თავისით არ გადაიტანს. გადართვა ახალ, ცარიელ ლოგს იწყებს; ძველი database.db plugin-ის საქაღალდეში რჩება. ან დათანხმდი ახალ დასაწყისს (და ძველი ფაილი რამდენიმე კვირა შეინახე, რომ ძებნისთვის დროებით უკან გადართო), ან გამოიყენე მიგრაციის ინსტრუმენტი, რომელსაც ენდობი, და ჯერ ასლზე გამოსცადე.

ზომა დაგეგმე. CoreProtect ის plugin-ია, რომელიც ბაზას ყველაზე სავარაუდოდ გაავსებს. purge-ის ჩვევა თავიდანვე ჩამოაყალიბე - /co purge t:30d ოცდაათ დღეზე ძველ მონაცემებს შლის - და დაგეგმე, რადგან სამი წლის ბლოკების ლოგი იშვიათად ღირს იმ დისკად. CoreProtect-ის ცხრილები სერვერებს შორის არ გააზიარო: თითოეული სერვერის კოორდინატები და სამყაროების სახელები აირეოდა. თითოეულ სერვერს საკუთარი ბაზა ან საკუთარი table-prefix მიეცი.

Connection pool-ები: რამდენ კავშირს ხსნი სინამდვილეში#

თითქმის ყველა Java plugin, რომელიც ბაზას ელაპარაკება, connection pool-ს იყენებს, ჩვეულებრივ HikariCP-ს. Pool გაშვებისას კავშირების ფიქსირებულ რაოდენობას ხსნის და ღიად ინახავს, რომ მოთხოვნებმა დაკავშირების ფასი არ გადაიხადონ. Plugin-ისთვის ეს ეფექტურია, ბაზისთვის კი ადვილად შეიძლება შეაფასო ნაკლებად.

არითმეტიკა ასეთია: plugin-ები გამრავლებული სერვერებზე, გამრავლებული pool-ის ზომაზე:

MySQL-ის ნაგულისხმევი max_connections არის 151, ხოლო მართული ან გაზიარებული ბაზის გეგმები ხშირად ნაკლებს უშვებს. პატარა ქსელს შეიძლება კავშირები ამოეწუროს ისე, რომ ვერავინ შეამჩნიოს გადატვირთვამდე, როცა ყველა სერვერი ერთდროულად ცდილობს pool-ის გახსნას და ბოლო იღებს Too many connections-ს.

Minecraft-ის დატვირთვისთვის პატარა pool-ები სავსებით საკმარისია. LuckPerms-ის pool 3-5 თითო სერვერზე საკმარისზე მეტია ქსელისთვის რამდენიმე ასეულ მოთამაშემდე; ის ძირითადად მეხსიერებაში ინახავს და ბაზას შესვლისას და ცვლილებისას მიმართავს. maximum-pool-size და minimum-idle ერთად შეამცირე. Connection pool-ები და ლიმიტები ხსნის, რატომ არის დიდი pool ხშირად უფრო ნელი და არა უფრო სწრაფი.

მონაცემების გაზიარება ქსელში#

მიზეზი, რის გამოც ხალხის უმეტესობა აქ ხვდება, proxy ქსელია: lobby, survival სერვერი და მინიგეიმის სერვერი Velocity-ის უკან. რა გააზიარო და რა არა:

გააზიარე უფლებები (LuckPerms, ყველგან ერთი ბაზა და პრეფიქსი, proxy-ის ჩათვლით), ban-ები და mute-ები (ban plugin-ის ქსელური რეჟიმი) და ყველაფერი, რისი ჩვენებაც ვებსაიტზე გინდა.

არ გააზიარო ბლოკების ლოგები (CoreProtect, თითო სერვერზე), სამყაროსთვის სპეციფიკური მონაცემები, როგორიცაა claim-ები ან რეგიონები (ისინი ერთი სამყაროს კოორდინატებს ეხება), და plugin-ის მონაცემები, სადაც plugin-ის დოკუმენტაცია პირდაპირ არ ამბობს, რომ რამდენიმე სერვერის ერთდროულ ჩაწერას უჭერს მხარს. ორი სერვერი, რომლებიც წერენ ცხრილებში, რომლებსაც plugin საკუთრად თვლის, ჩუმ დაზიანებას იწვევს და არა შეცდომებს.

გააზიარე სიფრთხილით: ეკონომიკის ბალანსები და ინვენტარები. საერთო ბალანსი ნიშნავს, რომ შესყიდვა ერთ სერვერზე და გადახდა მეორეზე შეიძლება ერთმანეთს შეეჯიბრონ; ქსელებისთვის აგებული plugin ამას ბლოკირებით უმკლავდება, plugin, რომელიც უბრალოდ MySQL-ს უჭერს მხარს, შეიძლება ვერა. ინვენტარის სინქრონიზაციის plugin-ებს შეუძლიათ ნივთები გააორმაგონ, როცა სერვერი გადაცემის შუაში კრაშდება. ბევრი ქსელი სწორედ ამ მიზეზით განზრახ ინახავს ცალკე ეკონომიკას თითო რეჟიმზე.

ბაზა და სერვერები ახლოს უნდა იყვნენ. ყოველი მოთხოვნა ორმხრივ გზას იხდის, ხოლო plugin-ები, რომლებიც მთავარ thread-ზე უშვებენ მოთხოვნებს (ცუდად დაწერილები ასე აკეთებენ), tick-ს ამდენი ხნით აჩერებენ. ბაზა იმავე მანქანაზე ან ქსელში მილიწამზე გაცილებით ნაკლები ჯდება; სხვა კონტინენტზე მყოფი კი 100 ms ჯდება თითო მოთხოვნაზე, რაც ორი სრული tick-ია.

PostgreSQL ან MongoDB ნაცვლად#

MySQL და MariaDB უმცირესი საერთო მნიშვნელია - ბაზის მხარდაჭერის მქონე თითქმის ყველა plugin მათ ლაპარაკობს. PostgreSQL-ს და MongoDB-ს ნაკლები plugin უჭერს მხარს, მაგრამ ის plugin-ები, რომლებიც ქსელებისთვის ყველაზე მნიშვნელოვანია, ხშირად უჭერენ: LuckPerms ორივეს უჭერს მხარს, LiteBans - PostgreSQL-ს. თუ ქსელისთვის მაინც გამოყოფილ ბაზას უშვებ, ძრავას არჩევამდე ყველა საჭირო plugin შეამოწმე.

RE:NODE-ის database hosting გთავაზობს PostgreSQL-სა და MongoDB-ს ცალკე სერვერებად, გენერირებული superuser პაროლით, გეგმის საკუთარ host-სა და პორტზე - გონივრული ადგილი LuckPerms-ისა და ban plugin-ისთვის მთელ ქსელში, იმ პირობით, რომ ყველა საჭირო plugin ამ ძრავას უჭერს მხარს. თამაშის გეგმის საკუთარი ბაზის slot უფრო მარტივი არჩევანია plugin-ებისთვის, რომლებიც მხოლოდ MySQL-ს ლაპარაკობენ. Postgres თუ MongoDB განსხვავებას ხსნის, თუ არც ერთი არ გამოგიყენებია.

Backup-ები და მოვლა#

Plugin-ის ბაზა ახლა შენი სამყაროს ნაწილია. სამყაროს საქაღალდის სამშაბათის მდგომარეობიდან აღდგენა, როცა უფლებები და ban-ები პარასკევზე რჩება, შეუსაბამობაა, რომელსაც შეამჩნევ. ორივეს backup ერთი განრიგით გააკეთე, და ასევე ნებისმიერი plugin-ის განახლებამდე, რომლის changelog-შიც "database migration" წერია.

$ mysqldump --single-transaction --default-character-set=utf8mb4 \    -h db.example.com -u mc_luckperms -p mc_luckperms > luckperms.sql

--single-transaction InnoDB ცხრილების თანმიმდევრულ snapshot-ს იღებს მათი დაბლოკვის გარეშე, ამიტომ სერვერები dump-ის დროს მუშაობას აგრძელებენ. CoreProtect-ისთვის dump შეიძლება დიდი იყოს; ჯერ ძველი მონაცემები წაშალე და dump-იც შემცირდება. ბაზის backup-ები და აღდგენა განრიგებსა და ტესტირებას განიხილავს.

ორი ჩვევა, რომელიც ღირს: ძველი ლოგის სტრიქონები განრიგით წაშალე და ნუ დაელოდები, სანამ დისკი იჩივლებს, და დროდადრო ბაზის slow query ლოგი შეამოწმე - plugin, რომელიც ინდექსის გარეშე მოთხოვნას უშვებს, იქ გაცილებით ადრე ჩანს, ვიდრე მოთამაშეები ლაგს შეამჩნევენ.

კავშირის შეცდომების მოგვარება#

`Communications link failure`. Plugin-მა ბაზას საერთოდ ვერ მიაღწია. არასწორი host ან პორტი, ბაზა გათიშულია, ან firewall უშლის. Plugin-ის დადანაშაულებამდე იმავე მანქანიდან ნებისმიერი MySQL კლიენტით გამოსცადე.

`Access denied for user 'x'@'y'`. არასწორი პაროლი, ან მომხმარებელი არსებობს, მაგრამ ამ host-იდან დაშვებული არ არის. შეტყობინებაში 'y' არის მისამართი, რომელიც ბაზამ დაინახა - შეადარე შექმნილი მომხმარებლის host-ის ნაწილს.

`Unknown database`. კონფიგურაციაში მითითებული ბაზის სახელი არ არსებობს ან სხვა რეგისტრით წერია. Linux-ზე MySQL-ის ბაზების სახელები რეგისტრის მიმართ მგრძნობიარეა.

`Too many connections`. ზემოთ აღწერილი pool-ის არითმეტიკა. შეამცირე pool-ები, ან იპოვე plugin, რომელიც კავშირებს ჟონავს, სერვერის მუშაობისას პროცესების სიის ყურებით.

`Public Key Retrieval is not allowed`. ახალი MySQL სერვერი caching_sha2_password ავთენტიფიკაციით და დრაივერი, რომელიც გასაღების დაუშიფრავი კავშირით მიღებაზე უარს ამბობს. ან TLS-ით დაუკავშირდი, ან (კერძო ქსელში) plugin-ის კავშირის თვისებებს დაუმატე allowPublicKeyRetrieval=true, თუ მათი მითითების საშუალებას იძლევა.

სერვერი შემთხვევით წამით იყინება. Plugin, რომელიც მთავარ thread-ზე უშვებს მოთხოვნებს ნელ ან შორეულ ბაზაზე. spark პროფილში plugin-საც და JDBC გამოძახებასაც გაჩვენებს.

FAQ#

MySQL უფრო სწრაფია, ვიდრე SQLite, Minecraft plugin-ებისთვის?

ერთ სერვერზე მსუბუქი გამოყენებისას ჩვეულებრივ არა - სწრაფ ლოკალურ დისკზე SQLite-ს ქსელის ორმხრივი გზა არ აქვს. MySQL იგებს ინტენსიური ერთდროული ჩაწერებისას, როგორიცაა CoreProtect დატვირთულ სერვერზე, და ერთადერთი ვარიანტია, როცა რამდენიმე სერვერი მონაცემებს იზიარებს.

შეუძლია ჩემი ქსელის ყველა სერვერს ერთი ბაზის გამოყენება?

მათ შეუძლიათ ერთი ბაზის სერვერის გამოყენება. ცხრილებს იზიარებენ თუ არა, plugin-ზეა დამოკიდებული: LuckPerms და ban plugin-ები ამისთვის არის შექმნილი, ბლოკების ლოგერები და claim-ის plugin-ები - არა. ეჭვის შემთხვევაში თითოეულ სერვერს საკუთარი ცხრილის პრეფიქსი მიეცი.

რა ხდება, თუ ბაზა გაითიშება?

Plugin-ები, რომლებსაც ის სჭირდება, ჩავარდება: LuckPerms-მა შეიძლება შესვლაზე უარი თქვას ან ქეშირებულ მონაცემებზე გადავიდეს, CoreProtect ჩაწერებს რიგში აყენებს, შემდეგ კი შეცდომას აგდებს. შენს სამყაროებს არაფერი ემართება. ჯერ ბაზა გაუშვი, შემდეგ თამაშის სერვერები, და ბაზა ისეთ ადგილას ნუ დადებ, რომელიც მასზე დამოკიდებულ სერვერებზე ნაკლებად სანდოა.

MariaDB გამოვიყენო თუ MySQL?

Minecraft plugin-ებისთვის ისინი ურთიერთშემცვლელია. სადაც plugin ცალკე mariadb ვარიანტს გთავაზობს, MariaDB-სთან ის გამოიყენე, რადგან შესაბამის დრაივერს ირჩევს.

რა ზომის გახდება ბაზა?

LuckPerms და ban plugin-ები პატარა რჩება, ჩვეულებრივ რამდენიმე მეგაბაიტი დიდ ქსელებზეც კი. CoreProtect გამონაკლისია და დატვირთულ სერვერზე თვეებში გიგაბაიტებს შეიძლება მიაღწიოს. ძველი ლოგები განრიგით წაშალე და ზომა პროგნოზირებადი დარჩება.