Some of the issues this approach suffers from:

The size of the WAL can become too large. In fact in Hadoop the edit log is checkpointed and a snapshot of the metadata is created called the FsImage. The edit log starts afresh onwards from the checkpoint. This allows to rein-in the size of the edit log.

In the context of databases, the WAL is strongly coupled with the choice of the storage engine. The WAL contains fine-grained details such as what bytes were changed on which disk blocks, which becomes problematic if the storage format were to be changed. So consider a scenario where the storage format is changed in the next higher version of the database software currently running on the master and the follower nodes. In this situation, it’s not possible to upgrade the system without bringing it down since the followers and the leader all must run the same version of software and use the same storage engine format. Otherwise, we could update the followers to the next version, initiate a failover to elect a new leader and then update the old leader to the new version. This zero downtime upgrade is not possible when using WAL shipping as a replication strategy.