You're looking for "key escrow", which is often a very bad idea. Even if this fits your use case, you're creating a single point of failure.
I'm sure that there are more sophisticated approaches, but here is a very simple one:
You need a pseudorandom function (PRF) and a public key encryption scheme.
Draw a random key $k$ for the PRF and use it as master key.
Then whenever generating a public/private key pair, take a unique bitstring $id$, compute $PRF(k,id)$ and use the result as randomness for the key generation algorithm of the public key encryption scheme, which gives you a private key $sk$ and a public key $pk$. Store a table that maps $pk$ to $id$.
This fulfills everything that you want: As long as the key $k$ is not revealed, the public key encryption scheme works as intended and is secure. But if I know $k$, I can look $id$ up in the table, recompute $PRF(k,id)$, derive $sk$ and decrypt.
Here, $id$ is a nonce in the weak sense: it can either be fully random or implemented by a counter; you "just" need to make sure that it is never repeated. (If it is a counter, you can also not store the table in the first place, and just try enough counter values until you have the right one, if you need to decrypt rarely with the master key.)