Hi @hasan
Are you asking about running multiple instances of Metabase for horizontal scaling?
There’s no auto-scaling, since that would depend on the resources available for each instance.
To take advantage of scaling, you simply start multiple instances of the same version of Metabase and point to the same metadata.
@flamber
We were using metabase on a single instance and metadata was stored in locally in H2 database.
So we created postgres database and migrated that metadata from H2 database to postgres and it started working with 2 instances now .
Does Metabase UI rely on user-session and http-session? If we were to deploy multiple Metabase processes pointing to the same metadata db, will it require Sticky-ness from browser to the process where the user logged in first?
Otherwise, running multiple instances will not be enough to horizontally scale Metabase.
Please advise.
@rohit.chowdhary
When you share the same metadata (including users, sessions, etc), then your users could use non-sticky connections, but I would recommend using sticky connections when possible (just learning experience from other systems).
I have launched metabase application on 2 servers. And both of them are pointing to same MySQL metadata DB. But when try to open any report it redirects back to login page.
More info:
Instances: 2 EC2 Instances running behind an ELB
Mysql has metadata which metabase uses
MB_<ENV_VARIABLES> are set according to MySQL config
sticky is enabled on ELB
Is there anything that I’m missing? I’m guessing it’s session issue because in log I see ERROR CODE 401
Hi @flamber,
Please check the logs as below
I opened url of elb which has 2 servers behind it.
Log of server1:
04-13 11:56:20 DEBUG metabase.middleware :: GET /api/user/current 200 (3 ms) (2 DB calls). Jetty threads: 8/50 (3 busy, 5 idle, 0 queued)
04-13 11:56:20 DEBUG metabase.middleware :: GET /api/database 200 (7 ms) (3 DB calls). Jetty threads: 8/50 (3 busy, 5 idle, 0 queued)
04-13 11:56:39 DEBUG metabase.middleware :: POST /api/session 200 (106 ms) (2 DB calls). Jetty threads: 8/50 (3 busy, 5 idle, 0 queued)
04-13 11:56:39 DEBUG metabase.middleware :: GET /api/user/current 200 (3 ms) (2 DB calls). Jetty threads: 8/50 (3 busy, 5 idle, 0 queued)
04-13 11:56:39 DEBUG metabase.middleware :: GET /api/collection/root/items 200 (21 ms) (7 DB calls). Jetty threads: 8/50 (3 busy, 5 idle, 0 queued)
04-13 11:56:39 DEBUG metabase.middleware :: GET /api/collection/root 200 (1 ms) (2 DB calls). Jetty threads: 8/50 (3 busy, 5 idle, 0 queued)
04-13 11:56:40 DEBUG metabase.middleware :: GET /api/database 200 (2 ms) (3 DB calls). Jetty threads: 8/50 (3 busy, 5 idle, 0 queued)
04-13 11:56:41 DEBUG metabase.middleware :: GET /api/automagic-dashboards/database/65/candidates 200 (977 ms) (7 DB calls). Jetty threads: 8/50 (3 busy, 5 idle, 0 queued)
So it is a successful login
But after that if I click on any question, the logs are generated on 2nd server and log is as follows
04-13 11:57:01 DEBUG metabase.middleware :: GET /api/collection/198 401 (126 µs) (0 DB calls).
“Unauthenticated”
and redirects back to login page again.
So, it is very evident that the session generated is server specific and not for the whole elb.
But I see many people running the metabase on elb with horizontal scaling. I’m not sure how is that possible. Is there a way to externalize metabase session? Or am I missing something?
@mohannv I have a feeling that server2 isn’t connected correctly to the same metadata. Sessions are stored in core_session, so they’re shared across any of the instances.
Post “Diagnostic Info” from Admin > Troubleshooting.
Just to get clarified, everytime there is a login:
A session is created
Stored in cookie “metabase.SESSION_ID” on client side, and “core_session” table on server side
Any request post that is validated using cookie and core_session
So, from client-end it maintains single session even though the request is processed by multiple servers on back of elb, hence validation should be successful if all of them are pointing to single metadata
Please correct me or add any more important points.
Thanks in advance!
@mohannv Correct. And if you prefer not to use cookies, but just a browser session, then you can set environment variable MB_SESSION_COOKIES=true, but the behavior is the same. The lifetime of the cookie is two weeks, but can be changed with the environment variable MAX_SESSION_AGE=20160 (in minutes).