All the online tutorials said that you shall delete the copy in the leaf node then make the other copy in the internal node = (the successor of that key) , my question is that what guarantees for us that this successor wasn't existing in an internal node before replacing our key copy in the internal node by it , because if such a thing happened we will have the value of that key (successor) existing more than one time in more than one internal node.
I found no answers for that in the online tutorials
Before getting to your question, it is a misconception to regard the keys of the internal nodes as actual data keys. They are merely index-keys, and don't really need to belong to the tree's data set, although it is common to have them updated to reflect the minimum key that is present in its corresponding subtree.
In comments you refer to this documentation and to the example of the deletion of the key 25:
But note that the update of the key in a parent node is not strictly necessary. The same documentation stated at the start:
- STEP 1 Find leaf L containing (key,pointer) entry to delete
- STEP 2 Remove entry from L
- STEP 2a If L meets the "half full" criteria, then we're done.
The case where key 25 is removed, fits the condition of step 2a, i.e. after it has been removed from the leaf node, "we're done". This is actually true. In this case the update of the key in ancestor node(s) is optional.
Now to your main question:
what guarantees for us that this successor wasn't existing in an internal node before replacing our key copy in the internal node by it
The keys that exist in internal nodes are always a lower bound for the keys in the next subtree below it. Unless that subtree will undergo shifts or merges due to the deletion, the least key in that subtree will become a key that previously was not the least key in that same subtree. In the example, 28 was not the least key in the subtree because that least key in that subtree was 25. So we can be sure 28 is not present in an internal node.
It is a different story if the leaf node happened to only have 25 as key, but then we get into a shift or merge operation, which will bring updates to multiple keys.