There is no "proper" practice for this. There are many ways you can approach it, each with pros and cons that need to be evaluated against all your other requirements.
Is a component allowed to have another component inside? For example I saw a RenderComponent that contains a Mesh inside. Is the mesh also a component or the raw data of it, which should be stored inside the RenderComponent?
If you want to support the concept of having compenents nested inside or otherwise attached to other components, you can. There is nothing wrong with it. It can add some amount of flexibility, although it tends to also add complexity as a tradeoff. It's up to you: do you need or want this to accomplish your goals?
What happens when an instance of component needs to be shared by two entities?
The same thing that happens when any piece of data needs to be shared. Generally you either simply share it (by having the entities refer to the component via some kind of referential semantics, and have actual lifetime of the component controlled elsewhere, not by the entities themselves), or refactor the system so you don't need to share the data.
If an entity should be just an integer, how do you organize the relationship between entities? Should it have a parent/child/linked entity or should all these relationship be managed by the system?
An entity does not have to be just an integer. That's just one way to look at it. That "entity is literally just an integer" approach can present these kind of relationship problems: you can't store anything else with an integer, directly. Instead you can either make the entity more complex, so it can directly reference related entities, or store relationships externally in a table mapping integers to lists of related entity integers, et cetera. It is up to you.
Your big misconception here is that "entity component systems" are a single thing with a single objectively-best way to build them. This is false. You'll find lots of writing on the internet describing various different ways to implement entity systems, many of them will be written in a dogmatic style or otherwise implying strongly that this is "the" way, and that all other ways are wrong.
This is true of almost nothing in software engineering, and it's certainly not true of entity systems. As you can guess from the common theme in my responses to your specific questions, you can structure your entity system however best makes sense to solve the problems you need to solve. I'd advise you to prefer the simpler solutions first, but beyond that it is up to you.
What you build won't be "so and so's entity system," as described on their blog, but it will be your entity system and that's more important.