Foreword

MAD is capable of being run in multiple instances. There may even be reasons that you would want to use multiple instances. I run several instances, one for my main tasks in my local town, a second for leveling in NYC and a third custom instance. I am considering adding a fourth to cover another town that doesn't need have access to my local town, since I won't be able to look members in the eye to determine if they are good people.

Others often run a separate instance when they reach 50 or so devices they seem to encounter MITM problems. It is hard for me to say if it can be assigned to a VPS related issue, a VM issue, db tuning, MAD issue, python issue(s), setup idiosyncrasies and/or a combination of the aforementioned.

I run on actual hardware with no VM with a fast NVME ssd on a tuned db. Several of us run 50+ on a single instance when using real hardware and have no issues. I personally run 125 atvs on a single instance of MAD.

General Setup

There are a variety of ways to setup multiple instances. You can run from the same directory with a different config file by specifying the config file from the command line. You can run from a different MAD directory. You can use the same or a different database using different instance name specified in the config file. Don't forget venv fun however you choose to set things up. You may or most likely not want to use the same redis cache instance. Of course, separate instances will need to have different rgc and pd ports.

The following list outlines the above with benefits and detractions. This is from my perspective, so may not apply to you.

• Same MAD directory and different config
  • + Easy setup
  • + or - No isolation of setups
  • + or - Different values in config
• Different MAD directory
  • + Can run different versions of MAD
  • + Update of one instance doesn't require restart of the other
  • - More space taken up by MAD on hard drive
  • - More things to maintain
• Same database
  • - Users can see other areas on maps
• Different database
  • + Limit data you have to query
  • + Completely isolated between instances
  • - More to maintain
  • + Can isolate maps for presentation

Leveling Instance Overview

My first foray into multiple instance of MAD was to create a leveling instance. I utilized a different directory and separate database. At one point, I had 60k+ stops as I was leveling in different areas, didn't make sense to clutter up my main instance with all those stops. My users didn't need to know all the stops in Paris and London, nor did the db need to cull through all the extra stops to query my 600 local stops to present the data for a map. I also didn't want to see all the areas from around the world when editing my local stuff on my main instance.

The enemy of efficient leveling is backtracking. It is faster to blow through the stops in order on the calculated route than to go back to pickup ones that were missed for whatever reason and waiting for cooldowns to spin stops that are spread out. So it is up to us to just let the leveling instance do its own thing without being affected by your main instance. Nor did I want my leveling instance to bother my main instance when I change walker settings.

Leveling Instance Setup

The following is a quick overview on setting up a second instance for leveling. If you need to copy and paste specific scans, you should have enough skills to figure out specifics yourself.

1. Make a new database
2. Git clone to a new mad directory, I used MAD-Level
3. Setup your venv
4. Install requirements using the venv
5. Edit your config file for pd, rgc, db setup, madmin values, redis, status-name, etc.
6. Start up mad, I use pm2
7. Make your fences, areas, devices and walkers
8. Fire up your device and do an init scan
9. Get your device leveling

Custom Instances

My custom instance is based off MAD code and db schema that is over two years old. Obviously this requires a separate install directory, a different db and seperate venv. It runs well enough and takes too much work to update, so I keep things as they are, why fix what isn't broke. When I do update, it is only a snapshot in time, mainline MAD may evolve along with the db schema, so it will always be setup as it is.

Moving devices between instances

Obviously one needs to create the device in MAD on the destination instance and update pd/rgc on devices. It is as simple as editing pd and rgc values on the device. But some like to do jobs, so find one here.