# New roles in FDB 6.2?

**URL:** <https://forums.foundationdb.org/t/new-roles-in-fdb-6-2/2009>\
**Category:** Using FoundationDB\
**Created:** [March 17, 2020, 6:22pm UTC](https://forums.foundationdb.org/t/new-roles-in-fdb-6-2/2009 "2020-03-17T18:22:44Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![ntrhieu89](https://sea1.discourse-cdn.com/foundationdb/user_avatar/forums.foundationdb.org/ntrhieu89/32/587_2.png) [@ntrhieu89](https://forums.foundationdb.org/u/ntrhieu89)\
**Post date:** [March 17, 2020, 6:22pm UTC](https://forums.foundationdb.org/t/new-roles-in-fdb-6-2/2009/1 "2020-03-17T18:22:44Z")

</div>

When upgrading from FDB 6.0 to FDB 6.2, I notice some new roles: `ratekeeper`, `router` and `data_distributor`, which are not mentioned here [https://apple.github.io/foundationdb/configuration.html](https://apple.github.io/foundationdb/configuration.html).

Do you have a reference document for that, and what is the recommended configurations (how many processes per each role) in a 3DCs, two-regions setup?

---

<div class="post-metadata">

**Author:** ![alexmiller](https://sea1.discourse-cdn.com/foundationdb/user_avatar/forums.foundationdb.org/alexmiller/32/326_2.png) [@alexmiller](https://forums.foundationdb.org/u/alexmiller)\
**Post date:** [March 18, 2020, 5:40am UTC](https://forums.foundationdb.org/t/new-roles-in-fdb-6-2/2009/2 "2020-03-18T05:40:21Z")

</div>

I’d first recommend taking a look at [Roles / Classes matrix](https://forums.foundationdb.org/t/roles-classes-matrix/1340), which will give you the nicer view of how and where the new roles will fit into the new processes. Overall, there’s been a trend of adding new types of things that can live in stateless class processes happily, so it’s always nice to have an extra few of them laying around.

`ratekeeper` and `data_distributor` were both previously pieces of `master` that got broken out to reduce master CPU usage (and to let them survive across recoveries). If you had a `master` class process in your 6.0 cluster, then they’ll prefer to be there. Otherwise, they’ll migrate towards other `stateless` class processes if they’re available and preferably unused.

`log_router` is the piece that pulls mutations from the primary to the secondary in a multi-region cluster. FDB will recruit a number of them that matches the number of transaction logs that you have, or you can configure it with `log_routers=N`. As log routers are stateless, they’ll probably just use the processes that you have allocated to be the proxies/resolver/master/etc. in the secondary in the case of a failover, so I don’t really expect that you’ll need to allocate any new processes for them.

But the feedback that we didn’t update the documentation about configuration is appreciated.