Before downgrading the binaries, you must downgrade the feature
compatibility version and remove any 3.4 features incompatible with 3.2 or earlier versions as outlined
below. These steps are necessary only if
featureCompatibilityVersion has ever been set to "3.4".

This command must perform writes to an internal system collection.
If for any reason the command does not complete successfully, you
can safely retry the command on the mongos instance as the operation is
idempotent.

Convert any data of decimal type. In versions
of MongoDB earlier than 3.4, operations against documents that
contain decimal type may fail. For some
possible conversion options, see
Model Monetary Data.

If you have v:2 indexes (i.e. the default version for indexes
created in MongoDB 3.4 if featureCompatibilityVersion:"3.4"),
reindexthecollection to recreate
all indexes on the collection as v:1 before downgrading MongoDB.

You must perform this operation on both the shards and the config
servers:

any other operation that modifies the cluster meta-data in any
way. See Sharding Reference for a complete list of
sharding commands. Note, however, that not all commands on the
Sharding Reference page modify the cluster meta-data.

Using either a package manager or a manual download, get the latest
release in the 3.2 series. If using a package manager, add a new
repository for the 3.2 binaries, then perform the actual downgrade
process.

Once upgraded to 3.4, you cannot downgrade to a 3.2.7 or earlier
version. You can only downgrade to a 3.2.8 or later version.