ჰოსტინგ bundle-ები: აპი, ბაზა და cache ერთად

RE:NODE-ზე bundle არის ორი ან სამი ჩვეულებრივი გეგმა - ჩვეულებრივ აპის სერვერი, მისი ბაზა და ზოგჯერ cache - რომლებიც ერთ checkout-ში იყიდება, ერთ ინვოისზეა და ერთი განახლების თარიღი აქვს, გაუქმებაც ერთად ხდება. ორგეგმიანი bundle იგივე გეგმების ცალ-ცალკე ყიდვაზე 15%-ით იაფია, სამგეგმიანი - 20%-ით. მასში შემავალი თითოეული სერვერი ჩვეულებრივი სერვერია: იგივე panel, console, ფაილები და backup-ები, რაც ნებისმიერ სხვა გეგმას აქვს. ფასდაკლების საფასური სიმკაცრეა: წევრები ერთად ახლდებიან, ცალკე ვერ გაიზრდებიან და ერთის გაუქმება ყველას აუქმებს. თუ შენი სტეკი გადაწყვეტილია და აპირებ, რომ ცოტა ხანს იგივე დარჩეს, bundle უბრალოდ მისი ყიდვის უფრო იაფი გზაა. თუ რომელიმე ნაწილი მალე დანარჩენებს გადაასწრებს, გეგმები ცალ-ცალკე იყიდე.

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

რა არის bundle და რა არ არის#

bundle არის ბილინგის წესი და არა განსხვავებული ტიპის სერვერი. როცა ყიდულობ, panel თითოეულ წევრ სერვერს იმავე კოდით ქმნის, რომლითაც ერთ გეგმას, ამიტომ bundle-ში მოსული PostgreSQL სერვერი ცალკე ნაყიდისგან არ გამოირჩევა. მას აქვს საკუთარი მისამართი და port-ი, საკუთარი დაგენერირებული credentials, საკუთარი რესურსის ლიმიტები, საკუთარი backup სლოტები და საკუთარი console. წევრებს შორის საერთო მხოლოდ ანგარიშია.

იცვლება ის, თუ როგორ არის ეს ნაკრები დაკავშირებული:

• ერთი checkout. bundle-ის ყველა სერვერი ერთი გადახდის შემდეგ იქმნება. ისევე, როგორც ნებისმიერი სხვა გეგმა, ისინი გადახდის დადასტურებისას აიგება, ჩვეულებრივ ერთ წუთში.
• ერთი ინვოისი, ერთი განახლების თარიღი. bundle ერთიანად ახლდება. Finances გვერდი მას აჩვენებს როგორც bundle-ის ბარათს ერთი "Renew all" ღილაკით, ხოლო თითოეული წევრი წერს, რომ bundle-ის ნაწილია და იქ გაგზავნის.
• ერთად გაუქმება. bundle-ის გაუქმებისას მისი ყველა სერვერი მუშაობს გადახდილი ვადის ბოლომდე, შემდეგ კი ყველა ჩერდება. ერთი წევრის გაუქმება მთელ bundle-ს აუქმებს.
• ცალკე გაზრდა არ შეიძლება. წევრ სერვერს ცალკე ვერ განაახლებ, ვერ გაზრდი და ვერ შეამცირებ. panel ამას უარყოფს.

იმასაც ღირს პირდაპირ თქმა, რას არ გაძლევს bundle. ის არ არის წევრებს შორის კერძო ქსელი: აპი ბაზას უკავშირდება ბაზის გეგმის host-ზე და port-ზე, ზუსტად ისე, როგორც მაშინ, თუ ისინი სხვადასხვა დღეს გეყიდა. ის არ არის მართვადი სერვისი, სადაც ჩვენ ბაზას შენი აპისთვის ვარგებთ. და ის არ არის სხვა panel ან სხვა support რიგი. თუ უკვე იცი, როგორ გაუშვა აპი და ბაზა გვერდიგვერდ ცალკე გეგმებზე, bundle-ის გაშვებაც უკვე იცი.

ყველა bundle, რასაც ვყიდით, გამოთვლებით#

ეს არის თორმეტი bundle, რომელიც ამ პოსტის დროს კატალოგშია. ფასები აშშ დოლარებშია თვეში, ერთთვიანი ვადით, და ისინი იცვლება, ამიტომ ჭეშმარიტების წყაროდ საიტის bundle-ების გვერდი და panel shop-ის Bundles ჩანართი ჩათვალე.

კანონზომიერება მარტივია. ყოველი ორგეგმიანი bundle თავისი ჩვეულებრივი ფასების ჯამზე 15%-ით იაფია, ყოველი სამგეგმიანი - 20%-ით. "ცალ-ცალკე" ციფრი გაბერილი საორიენტაციო ფასი არ არის; ეს უბრალოდ გეგმების საკუთარი თვიური ფასების ჯამია. Node.js Standard $7-ია, PostgreSQL Starter - $6, ანუ $13, და მისგან 15% ფასდაკლება $11.05-ია.

აბსოლუტურ ციფრებში დანაზოგი მცირეა - თვეში $1.50-დან $4.20-მდე. წელიწადში ეს $18-დან $50-მდეა, რაც გვერდითი პროექტისთვის რეალური ფულია, ბიზნესისთვის კი ნაკლებად შესამჩნევი. ამას პირდაპირ ვამბობთ და არ ვალამაზებთ: ფასდაკლება bundle-ის არჩევის მიზეზია, როცა ის ერგება, და არა მიზეზი, იყიდო სერვერები, რომლებიც არ გჭირდება.

რას გაძლევს თითოეული წევრი

რესურსები ზემოთ დასახელებული გეგმებისაა. გავრცელებული ნაწილებისთვის:

Java bundle ის გამონაკლისია, რომელიც განზრახ უფრო დიდია: ის იყენებს Java Advanced-ს 4 GB RAM-ით და 1.5 vCPU-ით, რადგან Spring Boot ან Quarkus სერვისი 2 GB-ზე მთელ თავის ცხოვრებას garbage collection-ში ატარებს. მას 512 MB Valkey გეგმა ახლავს. bot stack პირიქით მიდის და იყენებს Starter Python გეგმას (1 GB, 0.5 vCPU), რაც სავსებით საკმარისია ბოტისთვის, რომელიც უმეტესად websocket-ს ელოდება.

როგორ მუშაობს ფასდაკლება და გადახდა#

bundle-ის ფასდაკლება თვიურ ფასზე გამოიყენება და ჩვეულებრივი გრძელვადიანი ფასდაკლებაც ზედ რჩება. bundle-ის 3, 6 ან 12 თვით ყიდვისას იგივე ვადის ფასდაკლებას იღებ, რასაც ერთი გეგმა მოგცემდა, bundle-ის საკუთარ 15%-ზე ან 20%-ზე დაწყობილს. ასე რომ, სტეკის, რომელშიც დარწმუნებული ხარ, ყველაზე იაფად შენახვის გზა 12-თვიანი bundle-ია.

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

• Reward credit-ით bundle-ს ვერ გადაიხდი. Reward credit ცალკეულ ჰოსტინგ ხაზებზეა მიბმული, bundle კი რამდენიმეს კვეთს, ამიტომ checkout მას არ დახარჯავს. შენი wallet-ის ბალანსი და PayPal კი შეიძლება.
• კრიპტო checkout bundle-ებს ჯერ არ იღებს. "Pay with crypto" ერთ გეგმებზე მუშაობს; bundle-ები და VDS შეკვეთები მასში არ არის.
• საიტის შეკვეთის pop-up bundle-ებს არ იღებს. bundle-ების გვერდზე ღილაკი პირდაპირ panel shop-ზე გადადის, სადაც bundle-ებს საკუთარი ჩანართი აქვს.

თუ აგების დროს რამე არასწორად წავა - ვთქვათ, ერთი წევრის შექმნა ვერ მოხერხდა, დანარჩენის კი მოხერხდა - bundle მაინც გადახდილად ჩაიწერება, დაკარგული სერვერი ჩვენს გუნდს ეგზავნება, ხოლო Finances გვერდზე bundle-ის ბარათი წერს, რომელი ნაწილი აკლია, სანამ ის არ დაყენდება. თავიდან ყიდვა არ გჭირდება.

რომელი bundle რომელ პროექტს ერგება#

bundle-ების სახელები საკმაოდ პირდაპირია, მაგრამ შესაბამისობას ახსნა სჭირდება, რადგან არასწორი სტეკი იაფი რომ არის, სწორი არ გახდება.

Node.js + PostgreSQL, Go + PostgreSQL

ტიპური web API-ის ან full-stack აპის ნაგულისხმევი არჩევანი რელაციური მონაცემებით: მომხმარებლები, შეკვეთები, ყველაფერი, რაც foreign key-ებსა და ტრანზაქციებს შეიცავს. Node-ის მხარეს Express, Fastify, NestJS და Next.js; Go-ს მხარეს net/http ან Gin სერვისი. PostgreSQL Starter-ის 1 GB საკმარისია რამდენიმე გიგაბაიტიანი ბაზისთვის და გონივრული რაოდენობის კავშირებისთვის. თუ დარწმუნებული არ ხარ, საერთოდ გჭირდება თუ არა Postgres, Postgres თუ MongoDB უფრო გრძელი არგუმენტაციაა.

Python + PostgreSQL + Valkey

Django, Flask ან FastAPI რელაციური ბაზით და cache-ით. Valkey აქ თავის ადგილს იმსახურებს როგორც Celery-ის ან RQ-ის broker-ი, cache-ის backend-ი და სესიების საცავი. თუ შენს აპს background job-ები არ აქვს და ძვირი გვერდები არ აქვს, Valkey შეიძლება საერთოდ არ გჭირდებოდეს; ამ შემთხვევაში გადახდამდე წაიკითხე როდის გჭირდება რეალურად Redis.

Node.js + MongoDB + Valkey

დოკუმენტის ფორმის API-სთვის: მოქნილი ველებით კონტენტი, event log-ები, ყველაფერი, სადაც სქემა ყოველკვირეულად იცვლება. Valkey ამუშავებს სესიებს, rate limit-ებს და რიგებს, მაგალითად BullMQ-ს. ასეთ ფორმას იღებს ხოლმე Express ან Nest API პირველი რამდენიმე თვის შემდეგ.

Java + PostgreSQL + Valkey და .NET + SQL Server

JVM bundle განკუთვნილია Spring Boot, Quarkus, Micronaut ან Ktor სერვისებისთვის, იმ დამატებითი მეხსიერებით, რაც JVM-ს უნდა. .NET bundle ASP.NET Core ან Blazor აპს SQL Server Express-თან აწყვილებს, რაც მნიშვნელოვანია, როცა აპი SQL Server-სა და მის T-SQL-ზე დაიწერა და Postgres-ზე გადატანა თავისთავად ცალკე პროექტია. Express თითო ბაზას 10 GB-ით ზღუდავს, bundle იქნება თუ არა; თუ ამას ახლოსაც ხარ, თვითონ Express არის არასწორი ვერსია.

PHP stack და Laravel stack

PHP stack იყენებს მარტივ web ჰოსტინგ ხაზს (HTML, CSS, JS და PHP) MySQL 8.4-თან და Valkey-თან - ესაა სწორი არჩევანი ხელით დაწერილი PHP საიტისთვის, ძველი framework-ის აპისთვის ან CMS-ისთვის, რომელსაც თვითონ აყენებ. Laravel stack Laravel-ს ან Symfony-ს FrankenPHP-ზე უშვებს, Composer-ით ინსტალაციით გაშვებისას, და ერგება თანამედროვე Laravel აპს, რომელსაც Valkey სჭირდება cache-ისთვის, სესიებისთვის და რიგებისთვის.

WordPress + Valkey cache

ერთი დაწკაპუნებით WordPress, რომელსაც უკვე თავისი MySQL ბაზა მოყვება, პლუს Valkey სერვერი როგორც მუდმივი object cache. ეს ყველაზე კონკრეტული დანიშნულების bundle-ია: ის ეხმარება საიტს, რომელსაც ჰყავს ავტორიზებული მომხმარებლები, WooCommerce ან მძიმე plugin-ები, სადაც ერთი და იგივე ბაზის მოთხოვნები ყოველ გვერდზე სრულდება. სავიზიტო ბარათის ტიპის საიტს სრული გვერდის cache-ის უკან მისგან ცოტა სარგებელი აქვს.

Ghost + Mail Server

Ghost-ის პუბლიკაცია და შენი საკუთარი Stalwart mail სერვერი, რათა წერილები, რომლებსაც Ghost აგზავნის - წევრის შესვლის ბმულები, ანგარიშის წერილები - შენი დომენიდან გავიდეს. უხერხული ნაწილი ქვემოთაა განხილული: Ghost-ის მასობრივი newsletter-ების გაგზავნა Mailgun-ზეა აგებული, ამიტომ შენი საკუთარი mail სერვერი ტრანზაქციულ წერილებს ფარავს და არა მასობრივ newsletter-ებს, ყუთიდან ამოღებისთანავე.

Strapi + Node.js და bot stack

headless bundle Strapi-ს ერთ სერვერზე აყენებს კონტენტისთვის და Node.js სერვერს Next.js-ის ან Nuxt-ის front end-ისთვის, რომელიც Strapi-ს API-ს კითხულობს. bot stack არის Python პროცესი Discord-ის ან Telegram-ის ბოტისთვის, scraper-ისთვის ან worker-ისთვის, MongoDB-თი იმის შესანახად, რასაც ის აგროვებს. ბოტისთვის გეგმის არჩევა Discord ბოტისთვის განიხილავს, საკმარისია თუ არა Starter.

ნაწილების ერთმანეთთან დაკავშირება#

bundle რომ აიგება, გაქვს ორი ან სამი სერვერი, თითოეულს panel-ში ნაჩვენები მისამართით და port-ით და მისთვის დაგენერირებული credentials-ით. აპი თავისი ბაზის მისამართს ჯადოქრობით ვერ პოულობს; კავშირის დეტალებს შენ აძლევ, ჩვეულებრივ environment variable-ებით, და repository-ში არ ინახავ. Environment variable-ები და საიდუმლოებები განმარტავს, რატომ.

ტიპურ Node.js ან Python აპს PostgreSQL-ითა და Valkey-ით დაახლოებით ასეთი რამ სჭირდება, რეალური host-ებით, port-ებითა და პაროლებით, თითოეული სერვერის გვერდიდან გადაწერილი:

DATABASE_URL=postgres://app_user:GENERATED_PASSWORD@DB_HOST:DB_PORT/app_dbREDIS_URL=redis://:VALKEY_PASSWORD@VALKEY_HOST:VALKEY_PORT/0

Valkey Redis-ის პროტოკოლზე ლაპარაკობს, ამიტომ Redis-ის ყველა client ბიბლიოთეკა - ioredis, redis-py, phpredis, Predis, Lettuce, StackExchange.Redis - მას redis:// URL-ით უკავშირდება, თითქოს Redis იყოს. Laravel-ისთვის იგივე მნიშვნელობები framework-ის საკუთარ გასაღებებში შედის:

DB_CONNECTION=mysqlDB_HOST=MYSQL_HOSTDB_PORT=MYSQL_PORTDB_DATABASE=appDB_USERNAME=appDB_PASSWORD=GENERATED_PASSWORDREDIS_HOST=VALKEY_HOSTREDIS_PORT=VALKEY_PORTREDIS_PASSWORD=VALKEY_PASSWORDCACHE_STORE=redisSESSION_DRIVER=redisQUEUE_CONNECTION=redis

CACHE_STORE Laravel 11-ის სახელია; ძველ ვერსიებში მას CACHE_DRIVER ჰქვია. Valkey-ზე რიგებს ასევე სჭირდება worker პროცესი, რომელიც php artisan queue:work-ს ან Horizon-ს უშვებს, და ესეც თავისთავად გრძელი პროცესია - QUEUE_CONNECTION-ის გადართვამდე დაგეგმე, სად გაეშვება. Laravel-ის production-ზე გაშვება ამას გადის.

WordPress bundle-ისთვის ჩვეულებრივი გზაა Redis Object Cache plugin-ი თავისი მუდმივებით wp-config.php-ში, დამატებული იმ ხაზის ზემოთ, რომელიც რედაქტირების შეწყვეტას ამბობს:

define( 'WP_REDIS_HOST', 'VALKEY_HOST' );define( 'WP_REDIS_PORT', VALKEY_PORT );define( 'WP_REDIS_PASSWORD', 'VALKEY_PASSWORD' );

შემდეგ plugin-ის პარამეტრების გვერდიდან ჩართე object cache და შეამოწმე, რომ ის დაკავშირებულად ჩანს. Valkey როგორც WordPress-ის object cache განიხილავს დეტალებს და eviction პარამეტრებს, რომლებიც სავსე cache-ს შეცდომებად გადაქცევას უშლის.

უბრალო PHP web ხაზზე, სანამ კოდს დაწერ, phpinfo()-ში შეამოწმე redis გაფართოება. თუ ის არ არის, Predis არის წმინდა PHP client, რომელიც Composer-ით ყენდება და გაფართოებას არ საჭიროებს.

Ghost და მისი mail სერვერი

Ghost თავისი mail პარამეტრების კონფიგურაციის mail ბლოკიდან კითხულობს (სტანდარტულ ინსტალაციაში config.production.json, ან mail__options__host ტიპის ექვივალენტური environment variable-ები):

{  "mail": {    "from": "'Your Site' <noreply@example.com>",    "transport": "SMTP",    "options": {      "host": "mail.example.com",      "port": 465,      "secure": true,      "auth": { "user": "noreply@example.com", "pass": "MAILBOX_PASSWORD" }    }  }}

სანამ რამე შემომავალ ყუთში მოხვდება, mail სერვერს სწორად გაკეთებული DNS სჭირდება: MX, SPF, DKIM და DMARC ჩანაწერები, რომლებსაც შენს DNS პროვაიდერთან დაამატებ, რასაც SPF, DKIM და DMARC განმარტებული ეტაპობრივად გადის. გაგზავნა თავიდანვე მუშაობს; ინტერნეტიდან წერილების მისაღებად port 25-ის გადამისამართებაა საჭირო, რასაც support მოთხოვნით აკეთებს, თითო მისამართზე ერთი mail სერვერი. და როგორც ზემოთ: Ghost მასობრივ newsletter-ებს Mailgun-ით აგზავნის, ამიტომ ეს დაყენება შესვლის ბმულებისა და ანგარიშის წერილებისთვისაა, თუ Ghost-ის newsletter-ების გაგზავნის წესს არ შეცვლი.

განახლება, გაუქმება და გადაწყვეტილების შეცვლა#

ეს ის ნაწილია, რომელიც ყიდვამდე უნდა წაიკითხო, რადგან აქ bundle ცალკე გეგმებისგან განსხვავებულად იქცევა.

bundle-ის განახლების ინვოისი მთელ ნაკრებზე ერთხელ იქმნება და ჩვეულებრივი შეხსენებები მოქმედებს: ინვოისი იგზავნება ელფოსტით ვადის გასვლამდე 7 დღით ადრე და ისევ იმ დღეს. "Renew all" ყველა წევრს ერთ თარიღამდე ანახლებს. ბაზას წლით ვერ განაახლებ და აპს თვით; ვადა bundle-ისაა.

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

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

როდის იყიდო გეგმები ცალ-ცალკე#

bundle სწორი არჩევანია, როცა სტეკი ფიქსირებულია და ზომები ემთხვევა. რამდენიმე გავრცელებულ შემთხვევაში ის არასწორია:

• ერთი ნაწილი დანარჩენებზე უფრო სწრაფად გაიზრდება. ბაზა, რომელიც რამდენიმე თვეში 20 GB-ს გადააჭარბებს, ან აპი, რომელსაც ტრაფიკის მოსვლისას 4 GB დასჭირდება. ცალკე გეგმები ერთი-ერთი შეიძლება გაიზარდოს.
• შენ bundle-ისგან განსხვავებული ზომა გჭირდება. bundle-ები ფიქსირებულ დონეებს იყენებს. თუ შენ PostgreSQL Standard გჭირდება Node.js Starter-თან ერთად, ამისთვის bundle არ არსებობს, და სწორი ზომის ორი ცალკე გეგმა სჯობს არასწორი ზომის bundle-ს.
• მესამე ნაწილი არ გჭირდება. სამგეგმიანი bundle 20% ფასდაკლებით ორგეგმიან შესყიდვაზე ჩვეულებრივი ფასით იაფი არ არის, თუ Valkey-ს არასდროს გამოიყენებ. PHP stack $8-ად მაინც უფრო ძვირია, ვიდრე $4-იანი web გეგმა მარტო.
• აპის გეგმის საკუთარი ბაზის სლოტები საკმარისია. ყველა აპისა და web გეგმა მოიცავს ორ ბაზის სლოტს, რომლებიც panel-ში იქმნება დაგენერირებული host-ით, მომხმარებლითა და პაროლით. პატარა საიტს ან ბოტს მოკრძალებული ცხრილით ეს შეიძლება საკმარისი იყოს და ცალკე ბაზის სერვერი საერთოდ არ დასჭირდეს. საკუთარი ბაზის სერვერი ყიდულობს საკუთარ RAM-ს, CPU-ს, დისკს, root წვდომას და backup სლოტებს - ღირს მაშინ, როცა ბაზა მნიშვნელოვანი ხდება და არა უფრო ადრე.
• ნაწილები სხვადასხვა პროექტს ან ადამიანს ეკუთვნის. თუ აპი შენია, ბაზა კი სხვა პროექტთან გაქვს გაზიარებული, მათი განახლების დაკავშირება დამოკიდებულებას ქმნის, რომელიც არ გინდოდა.
• Reward credit-ით ან კრიპტოთი გადახდა გინდა. არც ერთი bundle-ებზე არ მუშაობს.
• სტეკზე ჯერ გადაწყვეტილი არ გაქვს. ტესტური ასლის ერთი თვე გაშვება იაფია, ვიდრე არასწორად არჩეული bundle-ის გაუქმება. Staging და production ერთ ანგარიშზე უფრო მეტს ამბობს ორი ასლის გვერდიგვერდ გაშვებაზე.

შედარების გზა მარტივია: გამოთვალე ცალკე გეგმების ფასი იმ ზომებით, რომლებიც სინამდვილეში გჭირდება, და შემდეგ ნახე, ემთხვევა თუ არა მათ bundle. თუ ემთხვევა, აიღე bundle. თუ ახლოსაა, მაგრამ ზუსტად არა, ცალკე გეგმები იმარჯვებს, რადგან არასწორი ზომის ფასს ყოველდღე იხდი, ფასდაკლება კი თვეში რამდენიმე დოლარია.

Backup-ები და ყოველდღიური მართვა#

თითოეულ წევრ სერვერს საკუთარი backup სლოტები აქვს, მისი გეგმით განსაზღვრული. აპის ხაზებს, PostgreSQL-სა და MongoDB-ს დონის მიხედვით 2-დან 6-მდე სლოტი აქვს, MySQL-ს, SQL Server-სა და Mail-ს 1-დან 4-მდე, პატარა Valkey გეგმებს - 0 ან 1. ეს უკანასკნელი ნაკლებად მნიშვნელოვანია, ვიდრე ჩანს: bundle-ში Valkey არის cache, სესიების საცავი ან რიგი, და თუ მას ძირითად ბაზად იყენებ, არასწორად იყენებ. ის დისკზე AOF-ით და snapshot-ებით ინახავს, ამიტომ restart მას არ ცარიელებს, მაგრამ მონაცემები, რომელთა ხელახლა შექმნაც არ შეიძლება, PostgreSQL-ში, MySQL-ში ან MongoDB-ში უნდა იყოს.

ბაზის სერვერის backup-ები დაგეგმე მის საკუთარ Schedules ჩანართზე და restore გამოსცადე, სანამ დაგჭირდება. ბაზისთვის dump ჩვეულებრივ უფრო სასარგებლოა, ვიდრე მონაცემთა დირექტორიის ფაილური არქივი; ბაზის backup-ები და restore-ები ორივეს განიხილავს და იმასაც, როდის რომელია უსაფრთხო. შენთვის ხილულ backup-ებს გარდა, ყველა სერვერი ასევე ღამით კოპირდება სისტემური backup-ით შენი გეგმის სლოტების გარეთ; ისინი შენს Backups ჩანართზე არ ჩანს და მათგან restore support-ის გავლით ხდება.

მონიტორინგი თითო სერვერზეა. თითოეულ წევრს აქვს საკუთარი console და საკუთარი გრაფიკები მეხსიერების, CPU-სა და დისკისთვის მის ლიმიტებთან მიმართებაში, ამიტომ როცა აპი ნელდება, ბაზის გრაფიკსაც შეხედე. PostgreSQL Starter, რომელიც თავის 0.5 vCPU-ზე ჩამჯდარია, აპიდან ზუსტად ნელ აპად გამოიყურება.

FAQ#

bundle-ის სერვერი უფრო სუსტია, ვიდრე იგივე გეგმა ცალკე ნაყიდი?

არა. panel bundle-ის წევრებს იმავე კოდით აგებს, რაც ერთჯერადი შესყიდვებისთვის, ამიტომ PostgreSQL Starter-ს bundle-ში აქვს იგივე 1 GB RAM, 20 GB NVMe და 0.5 vCPU და იგივე panel-ის შესაძლებლობები, რაც ცალკე ნაყიდს. ერთადერთი განსხვავება ბილინგშია: საერთო განახლების თარიღი, საერთო გაუქმება, ცალკე გაზრდა არ არის.

შემიძლია უკვე არსებულ სერვერებს bundle-ის ფასდაკლება დავამატო?

არა. shop bundle-ს ყიდის როგორც ახალ სერვერების ნაკრებს, რომელიც ერთი checkout-იდან აიგება. თუ აპი უკვე გაქვს და cache გინდა, ერთი Valkey გეგმის ყიდვა პირდაპირი გზაა, და მონაცემები bundle-ის სერვერებზე მოგვიანებით გადაიტანო, თუ დანაზოგი მიგრაციას ღირს.

bundle-ის სერვერები ერთმანეთს კერძო ქსელით ელაპარაკებიან?

არა. აპი თავის ბაზას და cache-ს უკავშირდება თითოეული სერვერისთვის ნაჩვენებ მისამართზე და port-ზე, დაგენერირებული credentials-ით, ზუსტად ისე, როგორც ცალკე გეგმებს. პაროლები repository-ში არ შეინახო და გამოიყენე panel-ის მიერ დაგენერირებული პაროლი, ავტორიზაციის გამორთვის ნაცვლად.

რა ემართება ჩემს მონაცემებს, თუ გავაუქმებ?

სერვერები მუშაობს იმ ვადის ბოლომდე, რომელიც გადაიხადე, შემდეგ კი ჩერდება. ამ დრომდე ჩამოტვირთე backup ან ბაზის dump ყველაფრისა, რაც გინდა. სერვერი რომ წაიშლება, მისი backup-ებიც მასთან ერთად იკარგება, rotation-ისგან დაბლოკილებიც.

შემიძლია bundle-ის წლით გადახდა?

დიახ. bundle-ები იღებს იმავე 3, 6 და 12-თვიან ვადებს, რასაც ერთი გეგმები, და ვადის ფასდაკლება bundle-ის საკუთარ 15%-ზე ან 20%-ზე ემატება. ამიტომ წლიანი bundle ყველაზე დაბალი თვიური ფასია სტეკისთვის, რომელშიც დარწმუნებული ხარ.