Should I duplicate model and database of master data across services in microservice

If you want your services to look like on this picture, then yes: It is not like you can't do it, but most of the time it will have bad consequences. Communication through REST will not decouple your services significantly. When some service interface changes, all dependent services most likely have to be changed and redeployed. Also while redeploying service, you will have to put all dependent services down, which is not considered a good design for high availability standards.

In the end, you will have microservices application which is slower than alternative monolith app would be, but having almost all the same problems!

I have to disagree with @Robert Harvey

In practice, however, one or more of your microservices (perhaps all of them) will talk to some central data store like a SQL database.

Integration database is well-known antipattern

A much better solution is to use publish-subscribe pattern in order to make communication between your services asynchronous:

Please take a look at CQRS/ES way of implementing this method of communication, Greg Young and other guys offer tons of nice videos on the topic. Just google for "CQRS/ES" keyword. In this approach, each service will become publisher and subscriber at the same time, allowing services to be much less coupled.

Here is a good series of articles about microservices that sheds the light on the controversy around the topic. Very detailed explanation with nice illustrations.

In a microservices architecture each microservice is responsible for its own data. Where that data is physically stored isn't really important. It's fairly common to have a central database for efficiency and to make administration easier. It's when one service writes to a table and a different one reads from or writes to the same table that you're diverging from the microservice architecture. Having one microservice's tables next to another microservice's tables isn't an issue.