When I read the replication of data from the primary server to secondary servers of InnoDB. It surprises me that the replication is async or at least semi-async. So I have the following question that in the case of async replication, the primary may go down with some of its secondary nodes not receiving the replication info. And the afterward selection of the next primary doesn't consider which secondary is closest to the old primary, and thus one node without some of the latest async-replication may be chosen. In this way, could we conclude that the primary-secondary cluster is not consistent?
This question is almost the same as an old one I answered: Does mySQL replication have immediate data consistency?
You're right that there is a risk of data loss in an asynchronous replica-set. If the primary is lost, it's possible that its replicas have not applied the latest changes. Even in what MySQL calls "semi-synchronous," the replica may have received the logs of all events, but not yet applied them.
During a failover scenario, it's safest if the replica remains read-only and doesn't allow itself to be writeable by clients until it has fully "caught up" by applying all its pending logs.
It's up to you to design applications to be tolerant of delays while this happens.
We'd like everything to be fully consistent and available with no delay, but the only way that's possible is if every transaction committed on the primary must wait for the same changes to be applied on the replica.
In most companies, this is not a tradeoff they're willing to accept. They'd rather have the transactions run as fast as possible on the primary under normal conditions, and accept the small risk of data loss during a failover.