In addition to being weird terminology, I have never found a case where "master/slave" is even used correctly. In almost every instance "primary/replica" would be a much better description for how the system actually behaves.
https://en.wikipedia.org/wiki/Master/slave_(technology)
It's used correctly in several of the cases listed here. Also, Jenkins uses (or used?) the term correctly.
- Master database tells the slaves what to write
- Master clock tells slave the time
- Master HDD controls the computer , so indirectly controls secondary -- though in this case slave HDD is more auxiliary rather than subordinate (this terminology isnt used anymore anyway)
In any case, master/slave terminology is historical and generally unproblematic, except apparently in the US, but so many words are problematic for someone somewhere that it's not wise to go down that road
When people use it for hardware and software, there's a tacit understanding that the power relationship must be preserved.
These two are diametrically opposed.
Once that happens, they are no longer master and slave, of course.
But that's only an ad-hoc state of affairs; the only thing telling a database (in postgres, at least) that it's a replica is that it has a couple of settings telling it what to replicate from, and if you remove those and restart (or otherwise trigger a failover), the replica becomes the new master.
For example, "primary/secondary" is slowly being adopted, but I find it very confusing because it can also mean two modules that perform the same function in parallel, but have a different priority for receiving input.
There are times when the slave drive communicates with the master (rather than the host controller), and the master controls things.
I'm the opposite of an expert, but here's one example according to a document (https://www.ele.uri.edu/courses/ele408/s2001/projects/roland...) that I found. From section 6.3.4:
During power on initialization or after RESET- is negated, DASP- shall be
asserted by Drive 1 within 400 msec to indicate that Drive 1 is present.
Drive 0 shall allow up to 450 msec for Drive 1 to assert DASP-. If Drive 1
is not present, Drive 0 may assert DASP- to drive an activity LED.