Shulou(Shulou.com)06/01 Report--

This is a miscellaneous article.

The previous article introduces the double main structure written by single node, and failover.

Later on. Let's take it as a joke, it's a gossip about life.

In the MySQL HA scenario, there is a simple replication-based architecture that requires three MySQL instances. Normally, the structure looks like this, where the red arrow represents the write request.

It can be called "single node write master master copy".

Note: for simplicity here, the existence of Proxy is omitted.

A brief introduction to this structure:

Although it is dual-master, the replication structure here is written by a single node, according to Oracle Dataguard:

That is, M1 as the real Primary and M2 as the Standby,S as the slave library of Primary.

Assuming M1 and M2 and S are names, then Primary and standby are its functions.

It is necessary for Client to exist as three instances here, because of the business request of Client, M1, M2 and S exist.

So what role do these three instances (or three database members) play in such an architecture?

M1:

As a Primary, it has been confronted with all kinds of requests from client, including writing and reading.

M2:

When M1 fails, M2, as Standby, will replace M1 and preempt VIP, and M2 begins to receive read and write requests from client.

S:

Its function... It is more tragic, it is not important, but it may not be less:

Maybe it needs to share the pressure of read request for Primary.

Maybe its hardware configuration is not as good as M1 or M2.

Maybe it will be used for backup every day, under the pressure of highly intensive IO.

It may also be regarded as the main reason for some data inconsistencies.

Worst of all, this slave:

Always be the slave of M1 or M2.

Is always set on the existence of read_only=1,super_read_only=1.

You don't even need to create an account to read and write requests to Client.

In other words, this instance can never be a Primary.

When M1 fails, the architecture diagram becomes:

(the process of switching Primary is called failover.)

When M1 has problems, such as downtime, its own process crash, and so on.

At this point, M2 gets the VIP and declares, "I am Primary." this "switch" is generally called failover.

The switching time depends on the judgment of keepalived (such as whether it is really unavailable, whether M2 is lagging behind, etc.).

At this point, Client starts sending read and write requests to the new Primary, M2.

S will begin to copy M2 data and continue to work silently.

Of course, S is still the same slave, continuing to make "sacrifices" for Client.

Moreover, every subsequent failover has little to do with S.

In line with preciseness and seriousness, this HA scheme is introduced.

If it is said to be for DBA employees.

So the following is what I want to say, and anyone can read it.

Let's first take a look at the explanation of the above "professional terms" on translate.google.com:

Primary (also known as Master):

Adjective

Main main, primary

Main main, major, primary, principal, chief

Standby (also known as Secondary):

Noun

Rely on stand-by

Support bracing, brace, steady, foothold, stand-by

Support for stand-by

Adjective

Standby stand-by, inactive

Slave (as if it can only be called Slave):

Noun

Slave slave

Slave slave

Annex annex, attachment, accessory, appendix, enclosure, slave

Verb

Work hard, slave.

Ironically, slave is used as a verb, which can be understood as "work hard".

If you think of Client as a "male / goddess", or as a "strong" partner in a relationship.

Then the read request can be understood as "giving" or "giving".

Then writing a request is understood as "giving back".

Then Primary's is called "authentic", or "protagonist".

Then Standby can be called "spare tire" or "supporting role".

What about Slave (i.e. S)? In the words of my friend. Well, I don't know what to say.

VIP is the sign to determine who is the authentic card, and whoever gets the VIP is the authentic one.

Here's an explanation of VIP:

VIP is Virtual IP. Whoever has VIP in hand is Primary.

To describe the above professional failover process in simplified words is:

When the real man fails, and then after a certain period of time, the spare tire becomes a "real" and continues to maintain a romantic relationship with the man / goddess.

To be more specific, it may be:

There is something wrong with the authentic brand, such as it may be sick or dead, or it may be that it is not so good to the man / goddess, or the simplest understanding is that both parties are no longer in love.

At this point, the supporting role who is always ready, that is, after preparing for a while (in the process of VIP contention), he said to client, "I'll deal with the read and write request later!" .

But in this framework, what is more bloody is that when the backup tire becomes the real one, the original one will still exist as a "spare tire" in this framework.

Perhaps the male / goddess will still think of the original real king, and the old real gentleman will also begin to miss the male / goddess.

Because one day the new authentic gentleman also has a problem, the old authentic gentleman will continue to replace it.

Although unhappy, M1 and M2 reached a consensus.

Wait, what about Mr. slave?

The worst is, of course, Mr. Slave. As mentioned above, Mr. Slave will never be chosen as a real name by a male / goddess. This is true in the computer world, and it also exists in real life. (feel sorry for someone who can't even be a backup.)

Mr. Slave is giving silently, giving silently behind, and the man / goddess may not give a feedback (write request) to Mr. Slave.

Because Slave is not even qualified to be a "spare tire", it was designed at the beginning of the project.

Maybe it's just because of Mr. Slave's bad luck.

Or maybe it's just because the Slave is a little lower-looking than the real king and the spare tire, or a little shorter (that is, the hardware configuration is a little worse).

The man / goddess accepted the dedication of Mr. Slave and asked Mr. Slave, "you'll still be there," and Mr. Slave said happily, "I've always been there."

M1 and M2, the real and spare tyres, also patted Slave on the shoulder and said, "Brother, steady."

Of course, this is only in the computer world.

In a relationship between people, it can't be that simple, it's not as simple as "Oh, you can't do it, I'll do it".

But on the other hand, it is very simple to understand the dual-master replication structure according to the structure of [Slave- genuine-spare tire].

Later, he continued to ask this friend who is not a DBA, and his understanding is that. Jack.

There seems to be nothing wrong with it. It's just that in this framework, you don't need a Slave to replace a spare tire.

Why did you write this article?

There is no need for the spotlight to hit here, I have no story to tell, and there is nothing to start performing.

Maybe it's just something I happened to think of when I was working on the two-master experimental structure of keepalived+ recently.

Perhaps after reading some stories, after reading some people's lives, I happen to think of something.

Later, ah, the company decided to withdraw the project.

Because. With Client gone, there is no need for three MySQL instances.

In other words, M1, M2 and S may not be needed, and the data may all be emptied.

These data are all given to them by Client.

Maybe all three machines made a backup for themselves before emptying.

Draw a small hard disk, compress the data and put it in it.

Of course, it's also possible that... These data from all three machines may be emptied.

Because they may be included in a new project and begin to accept data that trusts Client.

Maybe all the data on one of the three machines will not be emptied.

It's just that it is put into the warehouse forever and is no longer used by the company.

Although it looks old, it has no value of being used again.

But maybe it's for the best.

If this story has to be told again, maybe I can think of …...

Maybe one day after a long time.

The dusty machine was wiped off the dust layer, connected to the power supply and network cable, and turned on.

Then decompress the compressed data and re-import it into the database.

"look, all the data from that project were still here at that time."

"I thought I'd never see you again."

-- the end--

Author's official account on Wechat (continuously updated)

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.