SSD Nodes Learn 🎉 VPS $5.50/महिन्यापासून
मार्गदर्शक Matt Connorद्वारे Matt Connor

VPS वर Matrix Synapse homeserver कसा चालवायचा

VPS वर Matrix Synapse homeserver वर्षभर चालवण्यासाठी 1 vCPU आणि 2 GB RAM ची मर्यादा, Postgres, media retention, registration सुरक्षा आणि backups समजून घ्या.

Matrix Synapse homeserver चालू ठेवण्यासाठी आवश्यक बाबी

Matrix Synapse स्थापित करणे सोपे आहे, पण त्याकडे दुर्लक्ष करणेही तितकेच सोपे आहे. स्थापनेसाठी एक apt repository, एक configuration file, एक reverse proxy block आणि एक DNS record पुरेसे असतात. मात्र homeserver वर्षभर निरोगी ठेवण्यासाठी वेगळे व्यवस्थापन आवश्यक असते: प्रत्यक्ष database, नियमितपणे prune केला जाणारा media store, अनोळखी व्यक्तींना वापरता न येणारी registration व्यवस्था आणि server चे दोन्ही भाग समाविष्ट करणारा backup.

हे मार्गदर्शक Ubuntu 24.04 LTS साठी आहे. यात matrix.org apt repository मधून Synapse स्थापित केले जाते. Debian आणि Ubuntu साठी Synapse प्रकल्प स्वतः देखरेख करत असलेला हा package source आहे. Package versions दर काही आठवड्यांनी बदलतात, त्यामुळे येथे कोणताही version number दिलेला नाही. खालील प्रत्येक path आणि option सध्याच्या Synapse documentation मधून घेतलेला आहे.

Sizing: 1 vCPU आणि 2 GB RAM मुळे प्रत्यक्षात काय शक्य होते

August 2026 पर्यंत प्रकाशित sizing pages मध्ये Synapse homeserver साठी 1 vCPU आणि 2 GB RAM ही रचना सामान्यतः सुचवली जाते. एका परिस्थितीसाठी हे योग्य आहे: private server, काही users, लहान rooms आणि सक्रिय public rooms नसणे. दुसऱ्या परिस्थितीबाबत Synapse documentation स्पष्ट आहे. मोठ्या public rooms, जसे #matrix:matrix.org, मध्ये join करायचे असल्यास "At least 1GB of free RAM" आवश्यक असल्याचे त्यात नमूद आहे. ही free RAM Python, Postgres आणि kernel साठी लागणाऱ्या memory व्यतिरिक्त असते.

एका room मुळे sizing बदलू शकते, कारण join प्रक्रिया अशाच प्रकारे काम करते. स्थानिक user एखाद्या room मध्ये join झाल्यावर तुमचा homeserver त्या room मधील पूर्ण participant बनतो. त्या room मधील प्रत्येक इतर server कडून येणारा प्रत्येक event तो स्वीकारतो, प्रत्येक event वरील signature पडताळतो आणि room ची state स्थानिक पातळीवर साठवतो. मोठ्या public room मध्ये शेकडो servers वर हजारो members असतात. त्यामुळे तुमचा server हे काम सतत करतो, तुमचा user पुन्हा तो room उघडतो किंवा नाही तरीही. नंतर room सोडला तरी आधी साठवलेला history हटत नाही.

Synapse ची बहुतेक RAM caches साठी वापरली जाते. caches section मध्ये एक global_factor आहे, जो सर्व caches एकाच वेळी scale करतो. SYNAPSE_CACHE_FACTOR environment variable देखील हीच गोष्ट निश्चित करते. हे मूल्य वाढवल्यास database queries कमी करण्यासाठी अधिक RAM वापरली जाते. ते कमी केल्यास RAM वाचवण्यासाठी CPU आणि Postgres time अधिक वापरला जातो. Postgres ला स्वतंत्र memory हवी असते. त्यामुळे 2 GB च्या server वर दोघांमध्ये त्याच megabytes साठी स्पर्धा होते.

लहान plan साठी दोन व्यावहारिक नियम आहेत. Swap जोडा: swap मुळे Synapse वेगवान होत नाही, परंतु मोठ्या join दरम्यान kernel ने process बंद करण्यापासून ते वाचवते. त्यानंतर पहिल्या आठवड्यापासून disk monitor करा, कारण मर्यादेशिवाय वाढणाऱ्या दोन गोष्टी म्हणजे media store आणि room state tables. दोन्ही disk वर साठवल्या जातात.

Postgres का, आणि SQLite हा पर्याय का उरत नाही

Debian package ची सुरुवात SQLite वर होते. पहिल्यांदा सेवा सुरू करण्यासाठी ते योग्य आहे; परंतु इतर लोक वापरणाऱ्या server साठी ते योग्य नाही. SQLite एका वेळी केवळ एका writer ला परवानगी देते. Federation traffic आणि client requests एकाच वेळी write करतात. त्यामुळे एखादी जलद request धीम्या request मागे थांबते. वापरकर्त्यांना दिसणारे लक्षण म्हणजे app काही सेकंद अनियमितपणे hang होते.

दुसरे कारण रचनात्मक आहे. एकापेक्षा अधिक CPU core वापरण्याची समर्थित पद्धत म्हणजे Synapse चे worker processes. Workers साठी Postgres आवश्यक आहे. SQLite वर राहिल्यास performance सोबत upgrade path देखील गमावला जातो.

नंतर migration करणे समर्थित आहे; परंतु त्यासाठी downtime लागतो. त्यामुळे users येण्यापूर्वी ते करा. Synapse मध्ये synapse_port_db उपलब्ध आहे. ते SQLite database मधील data तयार केलेल्या Postgres database मध्ये copy करते:

synapse_port_db --sqlite-database homeserver.db --postgres-config homeserver-postgres.yaml

तुम्हाला Synapse च्या शेजारी container मध्ये database चालवायचा असल्यास, त्याचे फायदे-तोटे database Docker मध्ये किंवा host वर चालवणे येथे दिले आहेत.

Ubuntu 24.04 वर Synapse स्थापित करा

sudo apt install -y lsb-release wget apt-transport-https
sudo wget -O /usr/share/keyrings/matrix-org-archive-keyring.gpg https://packages.matrix.org/debian/matrix-org-archive-keyring.gpg
echo "deb [signed-by=/usr/share/keyrings/matrix-org-archive-keyring.gpg] https://packages.matrix.org/debian/ $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/matrix-org.list
sudo apt update
sudo apt install matrix-synapse-py3

Ubuntu 24.04 वर lsb_release -cs हे noble दाखवते आणि matrix.org repository noble suite प्रकाशित करते. Ubuntu च्या स्वतःच्या archive मधील matrix-synapse package वापरू नका. Synapse project तसे न करण्यास सांगते, कारण त्या builds त्याच्या releases पेक्षा मागे असतात आणि त्यांमध्ये ज्ञात security bugs असतात.

Installer server name विचारतो आणि दिलेले उत्तर /etc/matrix-synapse/conf.d/server_name.yaml मध्ये लिहितो. हे उत्तर काळजीपूर्वक द्या. server_name हा प्रत्येक user ID (@alice:example.com) मधील colon नंतरचा भाग आहे आणि तुमचा server तयार करत असलेल्या प्रत्येक room मध्ये तो समाविष्ट केला जातो. तो नंतर बदलल्यास कोणतीही गोष्ट हलत नाही; त्यातून वेगळा homeserver तयार होतो. तुमचे bare domain, example.com, वापरा, Synapse स्वतः matrix.example.com वर चालत असला तरी. Delegation या दोन्हींना जोडते. पुढील section मध्ये ते स्पष्ट केले आहे.

Package Synapse ला matrix-synapse user म्हणून चालवते, त्याचा data /var/lib/matrix-synapse अंतर्गत ठेवते आणि /etc/matrix-synapse/homeserver.yaml नंतर /etc/matrix-synapse/conf.d/ मधील प्रत्येक file वाचते. तुमच्या स्वतःच्या settings conf.d मधील छोट्या files मध्ये ठेवा. Package upgrades त्यांना बदलणार नाहीत.

sudo systemctl restart matrix-synapse
systemctl status matrix-synapse
sudo journalctl -u matrix-synapse -n 100 --no-pager

यशस्वीपणे सुरू झाल्यावर listeners सुरू होतात आणि त्यानंतर सेवा शांत राहते. systemd unit सेवा exit झाल्यानंतर काही seconds ने ती पुन्हा सुरू करते. त्यामुळे Synapse नाकारत असलेली config अशी unit म्हणून दिसते जी सुरू होऊन loop मध्ये वारंवार बंद होते. journal मधील शेवटच्या lines मध्ये नाकारलेली key नमूद केलेली असते.

Postgres कडे Synapse निर्देशित करा

sudo apt install -y postgresql
sudo -u postgres createuser --pwprompt synapse_user
sudo -u postgres createdb --encoding=UTF8 --locale=C --template=template0 --owner=synapse_user synapse

Locale हा केवळ दिखाऊ घटक नाही. वेगळ्या COLLATE आणि CTYPE मूल्यांसह तयार केलेल्या database वर Synapse सुरू होत नाही, जोपर्यंत database config मध्ये allow_unsafe_locale सेट केलेले नसते. त्यानंतरची दस्तऐवजीकृत दुरुस्ती म्हणजे dump घेऊन तो योग्य पद्धतीने तयार केलेल्या database मध्ये पुन्हा load करणे. हे पहिल्याच वेळी योग्यरीत्या तयार करा.

database:
  name: psycopg2
  txn_limit: 10000
  args:
    user: synapse_user
    password: secretpassword
    dbname: synapse
    host: localhost
    port: 5432
    cp_min: 5
    cp_max: 10

तुमच्या सर्व config files मध्ये नेमकी एकच database: key ठेवा. homeserver.yaml मधील SQLite block बदलून त्याजागी Postgres configuration ठेवा. conf.d अंतर्गत दुसरी प्रत जोडू नका. त्यामुळे कोणती configuration प्रत्यक्ष वापरात आहे याबाबत कधीही संभ्रम राहणार नाही. Restart करा. त्यानंतर Synapse खरोखर Postgres वापरत आहे हे सिद्ध करा:

sudo -u postgres psql synapse -c "SELECT count(*) FROM users;"

संख्या दिसल्यास Synapse ने या database मध्ये त्याचा schema तयार केला आहे. missing relation संबंधी error आल्यास Synapse अजूनही SQLite file मध्ये लिहित आहे. याचा अर्थ तुम्ही संपादित केलेली config file वाचली जात नाही.

Reverse proxy, TLS आणि federation ला आवश्यक असलेल्या .well-known फाइल्स

Synapse localhost ला bind केलेल्या port 8008 वर plain HTTP ऐकते. TLS आणि public port तिच्यासमोरील reverse proxy कडे असतात.

listeners:
- port: 8008
  tls: false
  type: http
  x_forwarded: true
  bind_addresses:
  - '::1'
  - '127.0.0.1'
  resources:
  - names:
    - client
    - federation
    compress: false

x_forwarded: true मुळे proxy ने सेट केलेल्या X-Forwarded-For header वर Synapse विश्वास ठेवते. हे नसल्यास प्रत्येक client 127.0.0.1 वरून आल्यासारखा दिसतो. त्यामुळे rate limiting ला एकच अत्यंत व्यस्त local user दिसतो आणि सर्वांना एकत्र throttle केले जाते.

location ~ ^(/_matrix|/_synapse/client) {
    proxy_pass http://localhost:8008;
    proxy_set_header X-Forwarded-For $remote_addr;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header Host $host:$server_port;
    client_max_body_size 50M;
    proxy_http_version 1.1;
}

या block संदर्भात Synapse documentation मध्ये दिलेला एक इशारा अनेकांचे अनेक दिवस वाचवू शकतो. Port नंतर कोणताही path, अगदी एकच / देखील, proxy_pass मध्ये जोडू नका. त्यानंतर nginx URI चे canonicalisation करते. त्यामुळे sending server ने sign केलेले bytes बदलतात आणि federation requests ची signature verification अयशस्वी होते. मात्र सामान्य client requests सुरू राहतात.

client_max_body_size हे Synapse च्या max_upload_size इतके किंवा त्यापेक्षा मोठे असणे आवश्यक आहे. nginx मध्ये लहान संख्या असल्यास त्यापेक्षा मोठे uploads Synapse पर्यंत पोहोचण्यापूर्वीच nginx कडून 413 Request Entity Too Large सह नाकारले जातात. त्यामुळे अपयशाचे कारण स्पष्ट करणारी Synapse log line मिळत नाही.

Certificate साठी Ubuntu 24.04 वर Certbot आणि Let's Encrypt यांचे अनुसरण करा. Proxy बाबत अजून निर्णय झाला नसेल, तर TLS चे काम कोणता proxy करतो हे reverse proxy तुलना स्पष्ट करते.

Delegation मुळे server_name हे example.com राहू शकते, तर Synapse matrix.example.com वर चालते. Bare domain वरून दोन फाइल्स serve करा:

location /.well-known/matrix/server {
    default_type application/json;
    return 200 '{"m.server": "matrix.example.com:443"}';
}

location /.well-known/matrix/client {
    default_type application/json;
    add_header Access-Control-Allow-Origin '*';
    return 200 '{"m.homeserver": {"base_url": "https://matrix.example.com"}}';
}

Server फाइल इतर homeservers ना federation traffic कुठे पाठवायचा ते सांगते. त्यामुळे federation default port 8448 ऐवजी 443 वर चालते. Client फाइल Matrix clients ना @alice:example.com साठी कोणता URL वापरायचा ते सांगते. Client फाइलमध्ये Access-Control-Allow-Origin header महत्त्वाचा आहे, कारण browser-based clients ही फाइल cross-origin fetch करतात. हा header नसल्यास browser response block करतो आणि client ला तुमचा homeserver सापडत नसल्याचे कळवतो.

दोन्ही फाइल्स example.com कडूनच valid TLS वर serve झाल्या पाहिजेत. त्या तपासा आणि बाहेरील जगाला काय दिसते तेही तपासा:

curl -s https://example.com/.well-known/matrix/server
curl -s https://matrix.example.com/_matrix/federation/v1/version

पहिल्या command मधून तुम्ही लिहिलेला JSON मिळतो. दुसऱ्या command मधून server implementation आणि त्याची version सांगणारा JSON object मिळतो. यावरून proxy federation path वर Synapse पर्यंत पोहोचत असल्याचे सिद्ध होते. त्यानंतर domain Matrix federation tester मध्ये https://federationtester.matrix.org वर तपासा. हा tester प्रत्यक्ष remote server ज्या मार्गाने जातो त्याच मार्गाचा वापर करतो.

फेडरेशन करायची की नाही: निर्णय जाणीवपूर्वक घ्या

फेडरेशन हा Matrix चा मुख्य उद्देश आहे आणि खर्चाचाही मुख्य स्रोत आहे. फेडरेशन करणारा homeserver तुम्ही कधीही न ऐकलेल्या सर्व्हरकडून connections स्वीकारतो, त्यांचे events प्राप्त करतो, त्यांचे media cache करतो आणि तुमचे वापरकर्ते ज्या प्रत्येक room मध्ये सहभागी होतात त्यांची state साठवतो. हा threat model संदर्भातील निर्णय आहे; तो default नसावा.

तुमच्या वापरकर्त्यांना इतर homeserver वरील लोकांशी संपर्क साधण्याची गरज असल्यास किंवा portable identity हे Matrix निवडण्याचे कारण असल्यास federation सुरू ठेवा. सर्व्हर एका team साठीच असेल आणि त्यावरील प्रत्येक account तुमच्या नियंत्रणाखाली असेल, तर federation करू नका. बंद सर्व्हर कमी data साठवतो, कमी data प्राप्त करतो आणि abuse साठी त्याचे आकर्षण बरेच कमी असते.

Federation पूर्णपणे बंद करण्याऐवजी मर्यादित करण्यासाठी Synapse allow list वापरते:

federation_domain_whitelist:
- lon.example.com
- nyc.example.com

Federation listener साठी firewall rule लागू करण्याचीही documentation शिफारस करते. त्यामुळे अवांछित traffic Python प्रक्रियेपर्यंत पोहोचण्याऐवजी network स्तरावरच थांबतो. Federation पूर्णपणे बंद करण्यासाठी listener resources list मधून federation काढा, /.well-known/matrix/server publish करू नका आणि port 8448 बंद ठेवा.

Matrix चालवण्याचे कारण private team chat असेल आणि federation कधीच आवश्यक नसेल, तर Synapse वापरण्याचा निर्णय घेण्यापूर्वी त्याचा चालू खर्च इतर self-hosted Slack पर्यायांशी तुलना करा. Docker Compose वरील Rocket.Chat कमी क्षमतेच्या machine वर team chat चालवते, कारण त्याला इतर organisation च्या room state साठवण्याची गरज नसते.

मीडिया repository मुळे डिस्क शांतपणे भरत जाते

तुमचे स्वतःचे वापरकर्ते upload करत असलेल्या फाइल्स तुमच्या डिस्कवर कायमच्या साठून राहतात. इतर homeserver वरील वापरकर्त्यांनी पोस्ट केलेल्या फाइल्स तुमच्या एखाद्या client ने त्या दाखवल्या की लगेच तुमच्या डिस्कवर fetch आणि cache केल्या जातात. Synapse प्रतिमांसाठी thumbnails देखील तयार करते. त्यामुळे एका फोटोच्या अनेक फाइल्स तयार होतात. डीफॉल्टनुसार यापैकी काहीही expire होत नाही.

Store शोधा आणि त्याचा आकार मोजा:

grep media_store_path /etc/matrix-synapse/homeserver.yaml
sudo du -sh /var/lib/matrix-synapse/media_store

तुमच्या configuration मध्ये छापला जाणारा path मोजा. Debian package Synapse चा data /var/lib/matrix-synapse अंतर्गत ठेवते. त्यामुळे store सामान्यतः तिथेच असतो. त्यानंतर conf.d मध्ये retention policy सेट करा:

media_retention:
  local_media_lifetime: 90d
  remote_media_lifetime: 14d

या दोन ओळी काळजीपूर्वक वाचा, कारण त्या एकाच प्रकारच्या settings नाहीत. remote_media_lifetime cache expire करते. ती delete केलेली कोणतीही सामग्री फाइलची मालकी असलेल्या server कडून पुन्हा fetch करता येते. local_media_lifetime तुमच्या स्वतःच्या वापरकर्त्यांनी upload केलेले media त्या वयापर्यंत पोहोचल्यावर कायमचे delete करते. एखादा संघ chat मध्ये documents share करतो आणि ते पुढील वर्षीही सापडतील अशी अपेक्षा करतो, तर ते documents गमावले जातील. अनेक servers फक्त remote value सेट करतात.

एकदाच करावयाच्या cleanup साठी admin API milliseconds मधील Unix timestamp स्वीकारते:

BEFORE_TS=$(date -d '30 days ago' +%s%3N)
curl -X POST -H "Authorization: Bearer $ADMIN_TOKEN" \
  "https://matrix.example.com/_synapse/admin/v1/purge_media_cache?before_ts=$BEFORE_TS"

POST /_synapse/admin/v1/purge_media_cache त्या timestamp पूर्वी शेवटच्या वेळी access केलेले cached remote media काढून टाकते. POST /_synapse/admin/v1/media/delete?before_ts=<ms> त्याच नियमाने local media delete करते. आधी remote purge चालवा आणि पुन्हा मोजमाप करा, कारण federation वापरणाऱ्या server वर remote cache साधारणपणे मोठा भाग असतो.

दोन settings एकाच डिस्कवर परिणाम करतात. max_upload_size एका upload चा कमाल आकार मर्यादित करते आणि ते nginx मधील client_max_body_size शी सुसंगत ठेवावे लागते. url_preview_enabled: true तुमचा server remote pages fetch करून clients ना link previews दाखवू देते. यासाठी bandwidth वापरली जाते आणि तुम्ही upload न केलेल्या content चे thumbnails साठवले जातात.

कोणी तुमचा homeserver शोधण्यापूर्वी नोंदणी बंद करा

Scanners काही दिवसांत खुले homeserver शोधतात. खाती तयार करणे मुक्त असल्यास, तुमचा सर्व्हर ज्या प्रत्येक room सोबत federate होतो तिथे spam source बनतो आणि दुसऱ्या बाजूचे administrators तुमचा संपूर्ण domain block करतात. ही reputation damage cleanup नंतरही कायम राहते, कारण block lists manually maintain केल्या जातात.

Synapse बंद स्थितीत ship होते. enable_registration चे default false आहे आणि registration_requires_token चे default false आहे. याशिवाय verification step नसताना registration enabled असल्यास Synapse सुरू होण्यास नकार देते, जोपर्यंत तुम्ही enable_registration_without_verification: true देखील set करत नाही. हा नकार जाणूनबुजून दिलेला आहे. त्यामुळे startup error नाहीसा करण्यासाठी ते on करू नका.

तुम्हाला हवी असलेली खाती manually तयार करा:

sudo register_new_matrix_user -c /etc/matrix-synapse/homeserver.yaml http://localhost:8008

यामध्ये user name, password आणि खाते server admin आहे का, असे विचारले जाते. तुम्ही -c द्वारे दिलेल्या config मधून ते registration_shared_secret वाचते. shared secret सापडत नाही असा संदेश आल्यास, तो secret असलेल्या file कडे -c निर्देशित करा.

खाती manually तयार करणे मोठ्या प्रमाणावर शक्य राहिले नाही, तेव्हा registration tokens हा मधला पर्याय आहे. Token ही अशी string आहे जी नवीन user ने signup वेळी सादर करणे आवश्यक असते. प्रत्येक token किती वेळा वापरता येईल याची मर्यादा त्यात ठेवता येते:

enable_registration: true
registration_requires_token: true
curl -X POST -H "Authorization: Bearer $ADMIN_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"uses_allowed": 1}' \
  https://matrix.example.com/_synapse/admin/v1/registration_tokens/new

body मधून token वगळल्यास Synapse token तयार करून तो परत करते. सक्रिय tokensची यादी GET /_synapse/admin/v1/registration_tokens देते. दोन्ही calls साठी server admin खात्याचा access token आवश्यक असतो. हा access token तुम्ही वर तयार केलेल्या admin user म्हणून login केल्यानंतर मिळवता.

इतरत्र खाती आधीच व्यवस्थापित करणारी organisation local passwords पूर्णपणे वगळू शकते, कारण Synapse login OIDC (OpenID Connect) provider कडे delegate करू शकते. उदाहरणार्थ, self-hosted SSO provider म्हणून Authentik. त्यानंतर नवीन users आणि खाते बंद होणारे users एकाच ठिकाणी व्यवस्थापित करता येतात.

प्रत्यक्षपणे सर्व्हर पुन्हा उभारता येईल असा backup

Synapse backup चे तीन भाग असतात. यांपैकी एकही भाग नसलेला backup असा सर्व्हर restore करतो, जो कोणीही वापरू शकत नाही.

  • Postgres database, ज्यामध्ये प्रत्येक event, account आणि room साठवलेले असतात.
  • Media store directory, ज्यामध्ये upload केलेल्या सर्व files साठवलेल्या असतात.
  • /etc/matrix-synapse, ज्यामध्ये तुमची config आणि सर्व्हरची signing key साठवलेली असते.

Signing key हा लोकांकडून विसरला जाणारा भाग आहे. तुमचा homeserver events वर स्वाक्षरी करण्यासाठी ही private key वापरतो आणि remote servers जुळणाऱ्या public key च्या आधारे events पडताळतात. तुमची key कुठे आहे हे पाहण्यासाठी grep signing_key_path /etc/matrix-synapse/homeserver.yaml चालवा. ती हरवल्यास असा सर्व्हर restore होईल, जो तुमच्या rooms ना तोच सर्व्हर असल्याचे सिद्ध करू शकणार नाही.

sudo -u postgres pg_dump --format=custom --file=/var/backups/synapse-$(date +%F).dump synapse
sudo tar czf /var/backups/synapse-etc-$(date +%F).tgz -C /etc matrix-synapse

आधी database dump घ्या. त्यानंतर media store copy करा. Media files एकदाच लिहिल्या जातात आणि ID द्वारे संदर्भित केल्या जातात. त्यामुळे dump नंतर घेतलेल्या media copy मध्ये फक्त अतिरिक्त files असू शकतात; files गहाळ होऊ शकत नाहीत. उलट क्रम वापरल्यास restored database अशा file कडे निर्देश करू शकतो, जी तुमच्या backup मध्ये capture झालेली नसेल.

हे तीनही भाग VPS च्या बाहेर साठवा. off-site snapshots साठी restic या रचनेसाठी योग्य आहे. Media store हा मोठा भाग असतो आणि runs दरम्यान त्यात फारच कमी बदल होतात. त्यामुळे deduplication मुळे प्रत्येक snapshot लहान राहतो.

यानंतर restore चा सराव करा. कारण तुम्ही कधीही restore न केलेला backup हा केवळ एक अंदाज असतो. दुसरा VPS तयार करा, तीच package install करा, config restore करा, त्याच encoding आणि locale सह database तयार करा, dump त्यात pg_restore करा, media store पुन्हा copy करा आणि login करा. यासाठी किती वेळ लागला ते लिहून ठेवा. तोच तुमचा वास्तविक recovery time आहे.

स्टेट टेबल मोठ्या झाल्यावर: compaction

Synapse room state हे state groups म्हणून साठवते. Federation करणाऱ्या server वर state_groups_state हा बहुतेक वेळा database मधील सर्वात मोठा object बनतो. कोणताही बदल करण्यापूर्वी मोजमाप करा:

sudo -u postgres psql synapse -c "SELECT pg_size_pretty(pg_database_size('synapse'));"
sudo -u postgres psql synapse -c "SELECT pg_size_pretty(pg_total_relation_size('state_groups_state'));"

जर तुमच्या database चा बहुतांश भाग या एकाच table मध्ये असेल, तर प्रकल्प त्यासाठी rust-synapse-compress-state हा compressor उपलब्ध करून देतो. तो कोणत्याही room च्या state चा अर्थ न बदलता state group hierarchy चे पुनर्लेखन करून rows ची संख्या कमी करतो. तो Rust वापरून build केला आहे:

sudo apt install -y build-essential libssl-dev pkg-config git
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
git clone https://github.com/matrix-org/rust-synapse-compress-state.git
cd rust-synapse-compress-state/synapse_auto_compressor
cargo build --release
./target/release/synapse_auto_compressor -p postgresql://synapse_user:secretpassword@localhost/synapse -c 500 -n 100

-c एकावेळी तो किती state groups वर काम करतो हे ठरवते आणि -n या run मध्ये अशा किती chunks वर प्रक्रिया करतो हे ठरवते. Auto compressor ने किती काम पूर्ण केले याची नोंद ठेवतो. त्यामुळे पुढील run तेथूनच सुरू होतो. यामुळे त्याचे schedule करणे सुरक्षित होते. त्याच्या documentation नुसार हे बदल append-only tables वर transactions मध्ये लागू केले जातात. त्यामुळे Synapse सुरू असतानाही ते चालवता येते. तरीही पहिल्या run पूर्वी database backup घ्या.

येथे Postgres मधील एक तपशील अनेकांना आश्चर्यचकित करतो. Rows delete केल्यावर space file system ला परत मिळत नाही; तो Postgres कडे reuse साठी राहतो. त्यामुळे मोठ्या compaction नंतर df मध्ये कोणताही बदल दिसणार नाही. VACUUM FULL तो space परत मिळवून देते. त्यासाठी table वर exclusive lock आणि table च्या आकाराएवढी अंदाजे मोकळी disk space आवश्यक असते. म्हणून ते maintenance म्हणून schedule करा; अचानक चालवू नका.

सर्व्हर निरोगी असल्याचे दर्शवणाऱ्या तपासण्या

systemctl status matrix-synapse
curl -s https://example.com/.well-known/matrix/server
curl -s https://matrix.example.com/_matrix/federation/v1/version
sudo -u postgres psql synapse -c "SELECT pg_size_pretty(pg_database_size('synapse'));"
sudo du -sh /var/lib/matrix-synapse/media_store

निरोगी स्थिती म्हणजे unit active आहे आणि पुन्हा पुन्हा restart होत नाही. Delegation file तुमचे m.server value परत करते. Federation version endpoint JSON परत करते. तसेच, दोन size numbers ची मागील महिन्याच्या आकड्यांशी तुलना करता येते. Size तपासणी अनेकदा वगळली जाते. मात्र disk भरल्यास Synapse server कोणतीही सूचना न देता बंद पडू शकतो. Volume भरल्यावर Postgres लिहू शकत नाही. त्यामुळे database ला स्पर्श करणारी प्रत्येक request Synapse कडून fail होते.

FAQ

Matrix Synapse सर्व्हरला किती RAM आवश्यक आहे?

काही वापरकर्ते, लहान rooms आणि मोठ्या public rooms नसलेल्या private homeserver साठी 2 GB RAM पुरेशी असते. August 2026 पर्यंत प्रकाशित झालेल्या बहुतांश sizing pages मध्येही हीच शिफारस आहे. तुमचे वापरकर्ते #matrix:matrix.org सारख्या मोठ्या public rooms मध्ये सहभागी होणार असतील, तर Synapse documentation नुसार उर्वरित गरजांव्यतिरिक्त किमान 1 GB free RAM ठेवा. कारण अशा वेळी तुमचा सर्व्हर त्या room ची state साठवतो आणि त्याचा traffic सतत process करतो. 2 GB plan वर swap जोडा, जेणेकरून एखाद्या मोठ्या join मुळे kernel process बंद करणार नाही.

SQLite ऐवजी PostgreSQL वापरणे आवश्यक आहे का?

काही मोजक्या वापरकर्त्यांनंतर, होय. SQLite मध्ये एका वेळी फक्त एक writer असू शकतो. त्यामुळे load वाढल्यावर federation traffic आणि client requests एकमेकांना block करतात आणि requests काही सेकंद अडकतात. Synapse चे worker processes, म्हणजे एकापेक्षा जास्त CPU cores वापरण्याची समर्थित पद्धत, Postgres आवश्यक करतात. नंतरचे migration synapse_port_db वापरून करता येते आणि त्यासाठी downtime लागतो. त्यामुळे वापरकर्ते येण्यापूर्वी --encoding=UTF8 --locale=C --template=template0 वापरून database तयार करा.

माझ्या Synapse चा disk usage सतत का वाढत आहे?

एक directory आणि एक table यासाठी कारणीभूत असतात. तुमचा सर्व्हर ज्या rooms मध्ये सहभागी आहे, त्यात upload केलेली प्रत्येक file media store साठवतो. यामध्ये remote users च्या media च्या cached copies आणि generated thumbnails यांचाही समावेश असतो. media_retention configure करेपर्यंत काहीही expire होत नाही. Federating server वर room state वाढत गेल्याने state_groups_state table मोठी होत जाते आणि rust-synapse-compress-state तिचा आकार कमी करते. कोणत्या भागावर काम करायचे ते ठरवण्यापूर्वी दोन्ही मोजा: तुमच्या media_store_path वर du -sh वापरून आणि SELECT pg_size_pretty(pg_total_relation_size('state_groups_state')); वापरून.

माझ्या homeserver वर अनोळखी लोकांची registration कशी थांबवू?

enable_registration हे false या default वरच ठेवा आणि register_new_matrix_user वापरून accounts तयार करा. ही पद्धत मोठ्या प्रमाणावर वापरता येईनाशी झाल्यावर registration_requires_token: true सोबत enable_registration: true सेट करा आणि POST /_synapse/admin/v1/registration_tokens/new द्वारे तयार केलेले tokens वितरित करा. Synapse चा startup refusal थांबवण्यासाठी केवळ enable_registration_without_verification: true सेट करू नका. Open homeserver spam source बनतो आणि इतर administrators तुमचे संपूर्ण domain block करतात.

माझ्या homeserver ने federate करावे का?

Federation हा exposure विषयीचा निर्णय आहे; तो default असणे आवश्यक नाही. तुमच्या वापरकर्त्यांना इतर homeservers वरील लोकांशी संपर्क साधायचा असल्यास federate करा. सर्व्हर फक्त एका team साठी वापरला जात असल्यास federation बंद ठेवा. अशा non-federating server वर कमी data साठवला जातो, कमी data प्राप्त होतो आणि abuse देखील लक्षणीयरीत्या कमी असतो. मध्यम पर्याय म्हणून, federation_domain_whitelist federation केवळ निर्दिष्ट partner domains पर्यंत मर्यादित करते. तरीही केवळ application-layer check वर अवलंबून न राहता federation listener साठी firewall rule लागू करण्याची शिफारस Synapse documentation करते.

#matrix#synapse#self-hosting#postgresql#federation