CN116932285A - MariaDB database master-slave switching method and device based on arbitration disk - Google Patents

MariaDB database master-slave switching method and device based on arbitration disk Download PDF

Info

Publication number
CN116932285A
CN116932285A CN202310909297.2A CN202310909297A CN116932285A CN 116932285 A CN116932285 A CN 116932285A CN 202310909297 A CN202310909297 A CN 202310909297A CN 116932285 A CN116932285 A CN 116932285A
Authority
CN
China
Prior art keywords
mariadb
database
switching
standby
host node
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202310909297.2A
Other languages
Chinese (zh)
Inventor
庄欢
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Jinan Inspur Data Technology Co Ltd
Original Assignee
Jinan Inspur Data Technology Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Jinan Inspur Data Technology Co Ltd filed Critical Jinan Inspur Data Technology Co Ltd
Priority to CN202310909297.2A priority Critical patent/CN116932285A/en
Publication of CN116932285A publication Critical patent/CN116932285A/en
Pending legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1446—Point-in-time backing up or restoration of persistent data
    • G06F11/1448—Management of the data involved in backup or backup restore
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1446—Point-in-time backing up or restoration of persistent data
    • G06F11/1456—Hardware arrangements for backup
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/14—Handling requests for interconnection or transfer
    • G06F13/16—Handling requests for interconnection or transfer for access to memory bus
    • G06F13/1605—Handling requests for interconnection or transfer for access to memory bus based on arbitration
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/23—Updating
    • G06F16/2365—Ensuring data consistency and integrity
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management

Abstract

The embodiment of the application relates to a MariaDB database master-slave switching method and device based on an arbitration disk, comprising the following steps: the latest GTID transaction numbers of the main and standby MariaDB databases are acquired at fixed time and stored in an arbitration disk; when the fact that the current host node holds a preset floating IP is detected, consistency detection is carried out on data in the primary and backup MariaDB databases; determining whether to perform main-standby switching on the MariaDB database based on the data consistency detection result; and if the primary and standby switching is determined to be performed on the MariaDB database, triggering a Heartbase script deployed in the current host node to perform the primary and standby switching on the MariaDB database based on a preset rule. Therefore, a data consistency checking mechanism is added, whether the primary data and the secondary data are consistent or not is judged according to the GTID transaction numbers of the primary database and the secondary database, the problem of data loss in the database switching process is avoided, and the integrity and consistency of service data are ensured.

Description

MariaDB database master-slave switching method and device based on arbitration disk
Technical Field
The embodiment of the application relates to the field of data security, in particular to a MariaDB database master-slave switching method and device based on an arbitration disk.
Background
The traditional MariaDB database master-slave switching based on Heartbeat software is characterized in that the same application service and database are respectively deployed on a master node and a standby node in a host cluster, and resource taking-over of the application service is carried out through Heartbeat. Only one host node (master node) usually provides service to the outside, and the database on the node bears normal business application data writing, and the database on the standby node is kept updated synchronously with the master node database data. When the application service on the host node providing the service fails, the Heartbean automatically starts the same application program on the standby node to continue providing the service, thereby ensuring high availability of the application service. However, since the data synchronization of the MariaDB database is easily affected by the network, the data synchronization mode may be degraded to an asynchronous mode, resulting in a delay in data synchronization, and in this case, if a master-slave switch is performed, there is a risk of data loss.
Disclosure of Invention
In view of this, in order to solve the above technical problems or some technical problems, an embodiment of the present application provides a method and apparatus for switching between master and slave of a MariaDB database based on an arbitration disk.
In a first aspect, an embodiment of the present application provides a method for switching between master and slave states of a MariaDB database based on an arbitration disk, including:
the latest GTID transaction numbers of the main and standby MariaDB databases are acquired at fixed time and stored in an arbitration disk;
when the fact that the current host node holds a preset floating IP is detected, consistency detection is carried out on data in the primary and backup MariaDB databases;
determining whether to perform main-standby switching on the MariaDB database based on the data consistency detection result;
and if the primary and standby switching is determined to be performed on the MariaDB database, triggering a Heartbase script deployed in the current host node to perform the primary and standby switching on the MariaDB database based on a preset rule.
In one possible embodiment, the method further comprises:
when detecting that the current host node holds a preset floating IP, inquiring the latest GTID transaction numbers respectively corresponding to the main and standby MariaDB databases stored in the arbitration disk;
if the latest GTID transaction numbers respectively corresponding to the main and standby MariaDB databases are consistent, determining that the data in the main and standby MariaDB databases are consistent;
and if the latest GTID transaction numbers respectively corresponding to the master and slave MariaDB databases are inconsistent, determining that the data in the master and slave MariaDB databases are inconsistent.
In one possible embodiment, the method further comprises:
if the data in the primary and secondary MariaDB databases are consistent, determining to switch the primary and secondary MariaDB databases;
if the data in the primary and secondary MariaDB databases are inconsistent, determining that primary and secondary switching is not performed on the MariaDB databases, and generating alarm information of inconsistent data.
In one possible embodiment, the method further comprises:
detecting role information of a MariaDB database corresponding to the current host node;
if the role information is a backup database, triggering a start method in a Heartbase script deployed in the current host node;
based on the start method, executing a role switching command in the MariaDB database corresponding to the current host node to switch the role information of the MariaDB database corresponding to the current host node as a main database;
triggering a stop method in a Heartbase script deployed in the current host node if the current host node is detected to release a preset floating IP;
based on the stop method, executing a role switching command in the MariaDB database corresponding to the current host node to switch the role information of the MariaDB database corresponding to the current host node as a backup database.
In one possible embodiment, the method further comprises:
and after the primary-backup switching of the MarianDB database is completed, continuously and regularly acquiring the latest GTID transaction number in the primary-backup MarianDB database and storing the latest GTID transaction number in the arbitration disk.
In one possible embodiment, the method further comprises:
if the main database fails, switching the application service on the main database to the standby database;
and switching the role information of the standby database into a main database, and holding a preset floating IP.
In one possible implementation, the preset floating IP is set by a headbean script.
In a second aspect, an embodiment of the present application provides a MariaDB database master-slave switching device based on an arbitration disk, including:
the acquisition module is used for acquiring the latest GTID transaction number of the main and standby MariaDB databases at fixed time and storing the GTID transaction number into an arbitration disk;
the detection module is used for detecting the consistency of the data in the primary and backup MariaDB databases when detecting that the current host node holds the preset floating IP;
the determining module is used for determining whether to perform main-standby switching on the MariaDB database based on the data consistency detection result;
and the switching module is used for triggering the Heartbeat script deployed in the current host node to perform the active-standby switching on the MariaDB database based on a preset rule if the active-standby switching on the MariaDB database is determined.
In a third aspect, an embodiment of the present application provides a computer apparatus, including: the system comprises a processor and a memory, wherein the processor is used for executing a MariaDB database master-slave switching program based on an arbitration disk stored in the memory so as to realize the MariaDB database master-slave switching method based on the arbitration disk in the first aspect.
In a fourth aspect, an embodiment of the present application provides a storage medium, including: the storage medium stores one or more programs executable by one or more processors to implement the method for master-slave switching of a MariaDB database based on an arbitration disk described in the first aspect.
According to the master-slave switching scheme of the MariaDB database based on the arbitration disk, the latest GTID transaction number of the master-slave MariaDB database is acquired at fixed time and stored in the arbitration disk; when the fact that the current host node holds a preset floating IP is detected, consistency detection is carried out on data in the primary and backup MariaDB databases; determining whether to perform main-standby switching on the MariaDB database based on the data consistency detection result; and if the primary and standby switching is determined to be performed on the MariaDB database, triggering a Heartbase script deployed in the current host node to perform the primary and standby switching on the MariaDB database based on a preset rule. Compared with the prior MariaDB database master-slave switching, whether the data in the master database and the data in the slave database are consistent or not is not considered, so that the problem of data loss possibly occurs during database switching. According to the scheme, a data consistency checking mechanism is added, whether the primary data and the secondary data are consistent or not is judged according to the GTID transaction numbers of the primary database and the secondary database, the problem of data loss in the database switching process is avoided, and the integrity and consistency of service data are ensured.
Drawings
FIG. 1 is a schematic diagram of a MariaDB database active-standby switching deployment based on an arbitration disk according to an embodiment of the present application;
fig. 2 is a schematic flow chart of a MariaDB database active-standby switching method based on an arbitration disk according to an embodiment of the present application;
FIG. 3 is a schematic diagram of a MariaDB database active-standby switching device based on an arbitration disk according to an embodiment of the present application;
fig. 4 is a schematic structural diagram of a computer device according to an embodiment of the present application.
Detailed Description
For the purpose of making the objects, technical solutions and advantages of the embodiments of the present application more apparent, the technical solutions of the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present application, and it is apparent that the described embodiments are some embodiments of the present application, but not all embodiments of the present application. All other embodiments, which can be made by those skilled in the art based on the embodiments of the application without making any inventive effort, are intended to be within the scope of the application.
For the purpose of facilitating an understanding of the embodiments of the present application, reference will now be made to the following description of specific embodiments, taken in conjunction with the accompanying drawings, which are not intended to limit the embodiments of the application.
First, english abbreviations appearing in the examples of the present application are explained:
the MariaDB database management system is a branch of MySQL, is mainly maintained by an open source community, and adopts GPL to authorize permission.
Heartbean: heartbeat is a piece of software that opens a source to provide High-availability (High-availability) services, through which resources (IP and program services, etc.) can be quickly transferred from one computer that has failed to another, on-the-fly, to continue providing services, commonly referred to as High-availability services.
GTID: the full name Global transaction identifiers, also known as global transaction ID. There is a unique GTID value for each transaction to which it corresponds.
Fig. 1 is a schematic diagram of a master-slave switching deployment of a mariadib database based on an arbitration disk, as shown in fig. 1, when a latest GTID transaction number of the master-slave mariadib database is acquired regularly and stored in the arbitration disk, and a host node takes over a floating IP, data consistency detection is performed through the latest GTID transaction number of the master-slave database stored in the arbitration disk, if the GTID transaction numbers are consistent, data are represented to be consistent, a database corresponding to the host node is promoted to be the master database, the database is required to be degraded to be the backup database when the host node releases the floating IP, and the host node detects the floating IP regularly and sets a role of the database, and data inconsistency in the switching process generates an alarm.
Fig. 2 is a schematic flow chart of a method for switching between master and slave of a MariaDB database based on an arbitration disk according to an embodiment of the present application, as shown in fig. 2, the method specifically includes:
s21, the latest GTID transaction numbers of the master MariaDB database and the standby MariaDB database are acquired regularly and stored in an arbitration disk.
In the embodiment of the application, the time can be set, the latest GTID transaction number of the master and slave MariaDB databases is periodically acquired and stored in an arbitration disk. And generating a unique GTID transaction number corresponding to each transactional operation carried out on the data in the database, and representing that the data in the primary and secondary databases are consistent when the latest GTID transaction numbers in the primary and secondary databases are consistent.
S22, when the fact that the current host node holds the preset floating IP is detected, consistency detection is conducted on data in the primary and backup MariaDB databases.
In the embodiment of the application, the preset floating IP is set by a Heartbase script, and when a master node holds the preset floating IP, a MariaDB database corresponding to the master node is a master database, and a MariaDB database corresponding to a standby node is a standby database; when the master node releases the preset floating IP, the MariaDB database corresponding to the master node is a standby database, and the standby node holds the preset floating IP, and the MariaDB database corresponding to the standby node is the master database.
Further, when the fact that the current host node holds the preset floating IP is detected, consistency detection is conducted on data in the master-slave MariaDB database. Executing a start method in a Heartcoat script in a current host node, inquiring latest GTID transaction numbers respectively corresponding to a main and standby MariaDB databases stored in an arbitration disk, and if the latest GTID transaction numbers respectively corresponding to the main and standby MariaDB databases are consistent, determining that the data in the main and standby MariaDB databases are consistent; if the latest GTID transaction numbers respectively corresponding to the main and standby MariaDB databases are inconsistent, determining that the data in the main and standby MariaDB databases are inconsistent.
S23, determining whether to perform master-slave switching on the MariaDB database based on the data consistency detection result.
If the data in the primary and secondary MariaDB databases are consistent, determining to switch the primary and secondary MariaDB databases; if the data in the primary and secondary MariaDB databases are inconsistent, determining that the primary and secondary switching is not performed on the MariaDB databases, generating alarm information of inconsistent data, informing a manager, and manually completing the data consistency processing of the primary and secondary databases by the manager.
And S24, if the primary and standby switching of the MariaDB database is determined, triggering a Heartbeat script deployed in the current host node to perform the primary and standby switching of the MariaDB database based on a preset rule.
If the primary and standby switching of the MariaDB database is determined, triggering a start method in a Heartbeat script deployed in a current host node, detecting role information of the MariaDB database corresponding to the current host node, and if the role information of the MariaDB database corresponding to the host node is a standby database, lifting the database to be the primary database on the premise of ensuring data consistency. And executing a database role switching command to switch the role information of the MariaDB database corresponding to the current host node as a master database.
Optionally, if the current host node is detected to release the preset floating IP, triggering a stop method in a Heartbase script deployed in the current host node, and executing a role switching command in a MariaDB database corresponding to the current host node to switch role information of the MariaDB database corresponding to the current host node to be a standby database.
Further, after the primary-backup switching of the MarianDB database is completed, the latest GTID transaction numbers in the primary-backup MarianDB database are continuously acquired at regular time and stored in the arbitration disk. When the application service on the host node providing the service fails, the Heartbean automatically starts the same application program on the standby node to continue providing the service, and the primary and standby databases complete primary and standby switching through the embodiment of the application, so that high availability and data security of the application service can be ensured.
According to the MariaDB database master-slave switching method based on the arbitration disk, the latest GTID transaction number of the master-slave MariaDB database is acquired at fixed time and stored in the arbitration disk; when the fact that the current host node holds a preset floating IP is detected, consistency detection is carried out on data in the primary and backup MariaDB databases; determining whether to perform main-standby switching on the MariaDB database based on the data consistency detection result; and if the primary and standby switching is determined to be performed on the MariaDB database, triggering a Heartbase script deployed in the current host node to perform the primary and standby switching on the MariaDB database based on a preset rule. Compared with the prior MariaDB database master-slave switching, whether the data in the master database and the data in the slave database are consistent or not is not considered, so that the problem of data loss possibly occurs during database switching. According to the method, a data consistency checking mechanism is added, whether the primary data and the secondary data are consistent or not is judged according to the GTID transaction numbers of the primary database and the secondary database, the problem of data loss in the database switching process is avoided, and the integrity and consistency of service data are ensured.
Fig. 3 is a schematic structural diagram of a master-slave switching device of a MariaDB database based on an arbitration disk according to an embodiment of the present application, which specifically includes:
the acquiring module 301 is configured to acquire the latest GTID transaction number of the master and slave MariaDB databases at regular time and store the GTID transaction number in the arbitration disk;
the detection module 302 is configured to perform consistency detection on data in the master-slave MariaDB database when detecting that the current host node holds a preset floating IP;
a determining module 303, configured to determine whether to perform active-standby switching on the MariaDB database based on the data consistency detection result;
and the switching module 304 is configured to trigger a Heartbeat script deployed in the current host node to perform active-standby switching on the MariaDB database based on a preset rule if it is determined to perform active-standby switching on the MariaDB database.
In one possible implementation manner, the obtaining module 301 is further configured to continue to obtain, at regular time, the latest GTID transaction number in the master-slave maridb database and store the latest GTID transaction number in the arbitrated disk after the master-slave handover is completed for the maridb database.
In a possible implementation manner, the detection module 302 is further configured to query the latest GTID transaction numbers respectively corresponding to the master-slave maridb databases stored in the arbitration disk when detecting that the current host node holds the preset floating IP; if the latest GTID transaction numbers respectively corresponding to the main and standby MariaDB databases are consistent, determining that the data in the main and standby MariaDB databases are consistent; and if the latest GTID transaction numbers respectively corresponding to the master and slave MariaDB databases are inconsistent, determining that the data in the master and slave MariaDB databases are inconsistent.
In a possible implementation manner, the determining module 303 is further configured to determine to perform a master-slave switch on the MariaDB database if the data in the master-slave MariaDB database are consistent; if the data in the primary and secondary MariaDB databases are inconsistent, determining that primary and secondary switching is not performed on the MariaDB databases, and generating alarm information of inconsistent data.
In a possible implementation manner, the switching module 304 is further configured to detect role information of a MariaDB database corresponding to the current host node; if the role information is a backup database, triggering a start method in a Heartbase script deployed in the current host node; based on the start method, executing a role switching command in the MariaDB database corresponding to the current host node to switch the role information of the MariaDB database corresponding to the current host node as a main database; triggering a stop method in a Heartbase script deployed in the current host node if the current host node is detected to release a preset floating IP; based on the stop method, executing a role switching command in the MariaDB database corresponding to the current host node to switch the role information of the MariaDB database corresponding to the current host node as a backup database.
In a possible implementation manner, the switching module 304 is further configured to switch an application service on the primary database to the backup database if the primary database fails; and switching the role information of the standby database into a main database, and holding a preset floating IP.
The master-slave switching device of the mariadib database based on the arbitration disk provided in this embodiment may be a master-slave switching device of the mariadib database based on the arbitration disk as shown in fig. 3, and may perform all steps of the master-slave switching method of the mariadib database based on the arbitration disk as shown in fig. 2, thereby achieving the technical effects of the master-slave switching method of the mariadib database based on the arbitration disk as shown in fig. 2, and detailed description with reference to fig. 2 is omitted herein for brevity.
Fig. 4 is a schematic structural diagram of a computer device according to an embodiment of the present application, and the computer device 400 shown in fig. 4 includes: at least one processor 401, memory 402, at least one network interface 404, and other user interfaces 403. The various components in computer device 400 are coupled together by bus system 405. It is understood that the bus system 405 is used to enable connected communications between these components. The bus system 405 includes a power bus, a control bus, and a status signal bus in addition to a data bus. But for clarity of illustration the various buses are labeled as bus system 405 in fig. 4.
The user interface 403 may include, among other things, a display, a keyboard, or a pointing device (e.g., a mouse, a trackball, a touch pad, or a touch screen, etc.).
It will be appreciated that the memory 402 in embodiments of the application can be either volatile memory or nonvolatile memory, or can include both volatile and nonvolatile memory. The nonvolatile Memory may be a Read-Only Memory (ROM), a Programmable ROM (PROM), an Erasable PROM (EPROM), an Electrically Erasable EPROM (EEPROM), or a flash Memory. The volatile memory may be random access memory (Random Access Memory, RAM) which acts as an external cache. By way of example, and not limitation, many forms of RAM are available, such as Static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double Data Rate SDRAM (Double Data Rate SDRAM), enhanced SDRAM (ESDRAM), synchronous Link DRAM (SLDRAM), and Direct memory bus RAM (DRRAM). The memory 402 described herein is intended to comprise, without being limited to, these and any other suitable types of memory.
In some implementations, the memory 402 stores the following elements, executable units or data structures, or a subset thereof, or an extended set thereof: an operating system 4021 and application programs 4022.
The operating system 4021 includes various system programs, such as a framework layer, a core library layer, a driver layer, and the like, for implementing various basic services and processing hardware-based tasks. The application programs 4022 include various application programs such as a Media Player (Media Player), a Browser (Browser), and the like for realizing various application services. A program for implementing the method of the embodiment of the present application may be included in the application program 4022.
In the embodiment of the present application, the processor 401 is configured to execute the method steps provided in the method embodiments by calling a program or an instruction stored in the memory 402, specifically, a program or an instruction stored in the application program 4022, for example, including:
the latest GTID transaction numbers of the main and standby MariaDB databases are acquired at fixed time and stored in an arbitration disk; when the fact that the current host node holds a preset floating IP is detected, consistency detection is carried out on data in the primary and backup MariaDB databases; determining whether to perform main-standby switching on the MariaDB database based on the data consistency detection result; and if the primary and standby switching is determined to be performed on the MariaDB database, triggering a Heartbase script deployed in the current host node to perform the primary and standby switching on the MariaDB database based on a preset rule.
In one possible implementation manner, role information of a MariaDB database corresponding to the current host node is detected; if the role information is a backup database, triggering a start method in a Heartbase script deployed in the current host node; based on the start method, executing a role switching command in the MariaDB database corresponding to the current host node to switch the role information of the MariaDB database corresponding to the current host node as a main database; triggering a stop method in a Heartbase script deployed in the current host node if the current host node is detected to release a preset floating IP; based on the stop method, executing a role switching command in the MariaDB database corresponding to the current host node to switch the role information of the MariaDB database corresponding to the current host node as a backup database.
In one possible implementation manner, after the primary-standby switching of the mariadib database is completed, the latest GTID transaction number in the primary-standby mariadib database is continuously acquired at regular time and stored in the arbitration disk.
In one possible implementation manner, if the primary database fails, switching an application service on the primary database to the backup database; and switching the role information of the standby database into a main database, and holding a preset floating IP.
In one possible implementation, the preset floating IP is set by a headbean script.
The method disclosed in the above embodiment of the present application may be applied to the processor 401 or implemented by the processor 401. The processor 401 may be an integrated circuit chip having signal processing capabilities. In implementation, the steps of the above method may be performed by integrated logic circuits of hardware in the processor 401 or by instructions in the form of software. The processor 401 described above may be a general purpose processor, a digital signal processor (Digital Signal Processor, DSP), an application specific integrated circuit (Application Specific Integrated Circuit, ASIC), an off-the-shelf programmable gate array (Field Programmable Gate Array, FPGA) or other programmable logic device, discrete gate or transistor logic device, discrete hardware components. The disclosed methods, steps, and logic blocks in the embodiments of the present application may be implemented or performed. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like. The steps of the method disclosed in connection with the embodiments of the present application may be embodied directly in the execution of a hardware decoding processor, or in the execution of a combination of hardware and software elements in a decoding processor. The software elements may be located in a random access memory, flash memory, read-only memory, programmable read-only memory or electrically erasable programmable memory, registers, etc. as well known in the art. The storage medium is located in a memory 402, and the processor 401 reads the information in the memory 402 and, in combination with its hardware, performs the steps of the above method.
It is to be understood that the embodiments described herein may be implemented in hardware, software, firmware, middleware, microcode, or a combination thereof. For a hardware implementation, the processing units may be implemented within one or more application specific integrated circuits (Application Specific Integrated Circuits, ASIC), digital signal processors (Digital Signal Processing, DSP), digital signal processing devices (dspev, DSPD), programmable logic devices (Programmable Logic Device, PLD), field programmable gate arrays (Field-Programmable Gate Array, FPGA), general purpose processors, controllers, micro-controllers, microprocessors, other electronic units designed to perform the functions described herein, or a combination thereof.
For a software implementation, the techniques described herein may be implemented by means of units that perform the functions described herein. The software codes may be stored in a memory and executed by a processor. The memory may be implemented within the processor or external to the processor.
The computer device provided in this embodiment may be a computer device as shown in fig. 4, and may perform all steps of the MariaDB database active-standby switching method based on the arbitration disk as shown in fig. 2, so as to achieve the technical effects of the MariaDB database active-standby switching method based on the arbitration disk as shown in fig. 2, and the detailed description with reference to fig. 2 is omitted herein for brevity.
The embodiment of the application also provides a storage medium (computer readable storage medium). The storage medium here stores one or more programs. Wherein the storage medium may comprise volatile memory, such as random access memory; the memory may also include non-volatile memory, such as read-only memory, flash memory, hard disk, or solid state disk; the memory may also comprise a combination of the above types of memories.
When one or more programs in the storage medium can be executed by one or more processors, the method for switching the master and slave of the MariaDB database based on the arbitration disk and executed on the side of the computer equipment is realized.
The processor is used for executing the master-slave switching program of the MariaDB database based on the arbitration disk stored in the memory so as to realize the following steps of the master-slave switching method of the MariaDB database based on the arbitration disk executed on the computer equipment side:
the latest GTID transaction numbers of the main and standby MariaDB databases are acquired at fixed time and stored in an arbitration disk; when the fact that the current host node holds a preset floating IP is detected, consistency detection is carried out on data in the primary and backup MariaDB databases; determining whether to perform main-standby switching on the MariaDB database based on the data consistency detection result; and if the primary and standby switching is determined to be performed on the MariaDB database, triggering a Heartbase script deployed in the current host node to perform the primary and standby switching on the MariaDB database based on a preset rule.
In one possible implementation manner, when detecting that the current host node holds the preset floating IP, inquiring the latest GTID transaction numbers respectively corresponding to the master and slave MariaDB databases stored in the arbitration disk; if the latest GTID transaction numbers respectively corresponding to the main and standby MariaDB databases are consistent, determining that the data in the main and standby MariaDB databases are consistent; and if the latest GTID transaction numbers respectively corresponding to the master and slave MariaDB databases are inconsistent, determining that the data in the master and slave MariaDB databases are inconsistent.
In one possible implementation manner, if the data in the master and slave mariadib databases are consistent, determining to perform master and slave switching on the mariadib databases; if the data in the primary and secondary MariaDB databases are inconsistent, determining that primary and secondary switching is not performed on the MariaDB databases, and generating alarm information of inconsistent data.
In one possible implementation manner, role information of a MariaDB database corresponding to the current host node is detected; if the role information is a backup database, triggering a start method in a Heartbase script deployed in the current host node; based on the start method, executing a role switching command in the MariaDB database corresponding to the current host node to switch the role information of the MariaDB database corresponding to the current host node as a main database; triggering a stop method in a Heartbase script deployed in the current host node if the current host node is detected to release a preset floating IP; based on the stop method, executing a role switching command in the MariaDB database corresponding to the current host node to switch the role information of the MariaDB database corresponding to the current host node as a backup database.
In one possible implementation manner, after the primary-standby switching of the mariadib database is completed, the latest GTID transaction number in the primary-standby mariadib database is continuously acquired at regular time and stored in the arbitration disk.
In one possible implementation manner, if the primary database fails, switching an application service on the primary database to the backup database; and switching the role information of the standby database into a main database, and holding a preset floating IP.
In one possible implementation, the preset floating IP is set by a headbean script.
Those of skill would further appreciate that the various illustrative elements and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware, computer software, or combinations of both, and that the various illustrative elements and steps are described above generally in terms of function in order to clearly illustrate the interchangeability of hardware and software. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the solution. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present application.
The steps of a method or algorithm described in connection with the embodiments disclosed herein may be embodied in hardware, in a software module executed by a processor, or in a combination of the two. The software modules may be disposed in Random Access Memory (RAM), memory, read Only Memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art.
The foregoing description of the embodiments has been provided for the purpose of illustrating the general principles of the application, and is not meant to limit the scope of the application, but to limit the application to the particular embodiments, and any modifications, equivalents, improvements, etc. that fall within the spirit and principles of the application are intended to be included within the scope of the application.

Claims (10)

1. A MariaDB database active-standby switching method based on an arbitration disk is characterized by comprising the following steps:
the latest GTID transaction numbers of the main and standby MariaDB databases are acquired at fixed time and stored in an arbitration disk;
when the fact that the current host node holds a preset floating IP is detected, consistency detection is carried out on data in the primary and backup MariaDB databases;
determining whether to perform main-standby switching on the MariaDB database based on the data consistency detection result;
and if the primary and standby switching is determined to be performed on the MariaDB database, triggering a Heartbase script deployed in the current host node to perform the primary and standby switching on the MariaDB database based on a preset rule.
2. The method of claim 1, wherein the performing consistency detection on the data in the master-slave MariaDB database when the current host node is detected to hold the preset floating IP comprises:
when detecting that the current host node holds a preset floating IP, inquiring the latest GTID transaction numbers respectively corresponding to the main and standby MariaDB databases stored in the arbitration disk;
if the latest GTID transaction numbers respectively corresponding to the main and standby MariaDB databases are consistent, determining that the data in the main and standby MariaDB databases are consistent;
and if the latest GTID transaction numbers respectively corresponding to the master and slave MariaDB databases are inconsistent, determining that the data in the master and slave MariaDB databases are inconsistent.
3. The method of claim 2, wherein the determining whether to switch master and slave the MariaDB database based on the data consistency detection result comprises:
if the data in the primary and secondary MariaDB databases are consistent, determining to switch the primary and secondary MariaDB databases;
if the data in the primary and secondary MariaDB databases are inconsistent, determining that primary and secondary switching is not performed on the MariaDB databases, and generating alarm information of inconsistent data.
4. The method of claim 3, wherein triggering the Heartbeat script deployed in the current host node to switch the MariaDB database between active and standby based on a preset rule if it is determined to switch the MariaDB database between active and standby comprises:
detecting role information of a MariaDB database corresponding to the current host node;
if the role information is a backup database, triggering a start method in a Heartbase script deployed in the current host node;
based on the start method, executing a role switching command in the MariaDB database corresponding to the current host node to switch the role information of the MariaDB database corresponding to the current host node as a main database;
triggering a stop method in a Heartbase script deployed in the current host node if the current host node is detected to release a preset floating IP;
based on the stop method, executing a role switching command in the MariaDB database corresponding to the current host node to switch the role information of the MariaDB database corresponding to the current host node as a backup database.
5. The method according to claim 4, wherein the method further comprises:
and after the primary-backup switching of the MarianDB database is completed, continuously and regularly acquiring the latest GTID transaction number in the primary-backup MarianDB database and storing the latest GTID transaction number in the arbitration disk.
6. The method of claim 5, wherein the method further comprises:
if the main database fails, switching the application service on the main database to the standby database;
and switching the role information of the standby database into a main database, and holding a preset floating IP.
7. The method of claim 1, wherein the preset floating IP is set by a headbean script.
8. The MariaDB database master-slave switching device based on the arbitration disk is characterized by comprising:
the acquisition module is used for acquiring the latest GTID transaction number of the main and standby MariaDB databases at fixed time and storing the GTID transaction number into an arbitration disk;
the detection module is used for detecting the consistency of the data in the primary and backup MariaDB databases when detecting that the current host node holds the preset floating IP;
the determining module is used for determining whether to perform main-standby switching on the MariaDB database based on the data consistency detection result;
and the switching module is used for triggering the Heartbeat script deployed in the current host node to perform the active-standby switching on the MariaDB database based on a preset rule if the active-standby switching on the MariaDB database is determined.
9. A computer device, comprising: the system comprises a processor and a memory, wherein the processor is used for executing a MariaDB database master-slave switching program based on an arbitration disk stored in the memory so as to realize the MariaDB database master-slave switching method based on the arbitration disk as claimed in any one of claims 1 to 7.
10. A storage medium storing one or more programs executable by one or more processors to implement the arbitrated disk-based MariaDB database master-slave switching method of any one of claims 1-7.
CN202310909297.2A 2023-07-24 2023-07-24 MariaDB database master-slave switching method and device based on arbitration disk Pending CN116932285A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202310909297.2A CN116932285A (en) 2023-07-24 2023-07-24 MariaDB database master-slave switching method and device based on arbitration disk

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202310909297.2A CN116932285A (en) 2023-07-24 2023-07-24 MariaDB database master-slave switching method and device based on arbitration disk

Publications (1)

Publication Number Publication Date
CN116932285A true CN116932285A (en) 2023-10-24

Family

ID=88389244

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202310909297.2A Pending CN116932285A (en) 2023-07-24 2023-07-24 MariaDB database master-slave switching method and device based on arbitration disk

Country Status (1)

Country Link
CN (1) CN116932285A (en)

Similar Documents

Publication Publication Date Title
US8127174B1 (en) Method and apparatus for performing transparent in-memory checkpointing
US20090044044A1 (en) Device and method for correcting errors in a system having at least two execution units having registers
US10545913B1 (en) Data storage system with on-demand recovery of file import metadata during file system migration
US7882388B2 (en) Dual independent non volatile memory systems
CN109491609B (en) Cache data processing method, device and equipment and readable storage medium
KR20220010040A (en) Error recovery method and device
US11748215B2 (en) Log management method, server, and database system
CN112506710B (en) Distributed file system data restoration method, device, equipment and storage medium
CN108920301B (en) Data backup method and system, and data recovery method and system
CN106815094B (en) Method and equipment for realizing transaction submission in master-slave synchronization mode
US20090132534A1 (en) Remote replication synchronizing/accessing system and method thereof
CN115145697A (en) Database transaction processing method and device and electronic equipment
CN113744064A (en) Method and apparatus for performing transactions in block link points
JP5466717B2 (en) Apparatus, method, and computer program for maintaining data integrity (apparatus for maintaining data consistency)
CN112600690B (en) Configuration data synchronization method, device, equipment and storage medium
CN108647112B (en) Data backup method and device and distributed transaction processing system
US10169440B2 (en) Synchronous data replication in a content management system
CN107526652B (en) Data synchronization method and storage device
CN105868038B (en) Memory error processing method and electronic equipment
CN109062731B (en) Idempotent control method and device during database switching
CN116932285A (en) MariaDB database master-slave switching method and device based on arbitration disk
CN115543393A (en) Upgrading method, electronic device and storage medium
US20220138177A1 (en) Fault tolerance for transaction mirroring
US9471409B2 (en) Processing of PDSE extended sharing violations among sysplexes with a shared DASD
CN109510867B (en) Data request processing method and device, storage medium and electronic equipment

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination