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 generally
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 primary 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.

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.

When rs.status() shows that the primary has stepped down
and another member has assumed PRIMARY state, shut down the
previous primary and replace the mongod binary with
the 3.2 binary and start the new instance.