Der Grund, warum MySQL die Binlog-Datei manuell registriert und Master-Slave-Anomalien verursacht

Der Grund, warum MySQL die Binlog-Datei manuell registriert und Master-Slave-Anomalien verursacht

1. Quelle des Problems

Ein Freund von @水米田 hat mich nach dem Master-Slave basierend auf der POSITION gefragt. Er tat Folgendes

Fügen Sie dem Verzeichnis einige gesicherte Binlog-Dateien hinzu, ändern Sie die Indexdatei und fügen Sie diese Binlog-Dateien hinzu
Binärprotokolle leeren
Dann kommt es zu erheblichen Verzögerungen im gesamten Master-Slave-Umfeld.

2. Freundestest

Hier ist ein weiterer Test von meinem Freund @徐晨亮:

Auf dem Master:
(root:db1@xucl:10:30:22)[(keine)]> Binärprotokolle anzeigen;
+---------------------+-------------+
| Protokollname | Dateigröße |
+---------------------+-------------+
|mysql-binlog.000031 | 1019 |
|mysql-binlog.000032 | 424 |
|mysql-binlog.000033 | 244 |
|mysql-binlog.000034 | 2332 |
|mysql-binlog.000035 | 2134 |
|mysql-binlog.000036 | 845915 |
|mysql-binlog.000037 | 11735 |
|mysql-binlog.000038 | 284 |
|mysql-binlog.000039 | 284 |
|mysql-binlog.000040 | 284 |
|mysql-binlog.000041 | 284 |
|mysql-binlog.000042 | 234 |
+---------------------+-------------+
12 Zeilen im Satz (0,00 Sek.)
(root:db1@xucl:10:30:34)[(keine)]> Binärprotokolle nach „mysql-binlog.000039“ löschen;
Abfrage OK, 0 Zeilen betroffen (0,00 Sek.)
(root:db1@xucl:10:30:49)[(keine)]> Binärprotokolle anzeigen;
+---------------------+-------------+
| Protokollname | Dateigröße |
+---------------------+-------------+
|mysql-binlog.000039 | 284 |
|mysql-binlog.000040 | 284 |
|mysql-binlog.000041 | 284 |
|mysql-binlog.000042 | 234 |
+---------------------+-------------+
4 Zeilen im Satz (0,00 Sek.)
Führen Sie „Daten einfügen (root:db1@xucl:10:31:23)[xucl]> in t-Werte einfügen (9,9)“ aus.
Kopieren Sie das gesicherte Binärprotokoll zurück in das ursprüngliche Verzeichnis und ändern Sie die Indexdatei, um [root@izbp12nspj47ypto9t6vyez logs]# ll zu registrieren.
Gesamtnutzung 884
-rw-r----- 1 mysql mysql 1019 Mai 20 22:03 mysql-binlog.000031
-rw-r----- 1 mysql mysql 424 20. Mai 22:03 mysql-binlog.000032
-rw-r----- 1 mysql mysql 244 20. Mai 22:03 mysql-binlog.000033
-rw-r----- 1 mysql mysql 2332 20. Mai 22:03 mysql-binlog.000034
-rw-r----- 1 mysql mysql 2134 20. Mai 22:03 mysql-binlog.000035
-rw-r----- 1 mysql mysql 845915 20. Mai 22:03 mysql-binlog.000036
-rw-r----- 1 mysql mysql 11735 20. Mai 22:05 mysql-binlog.000037
-rw-r----- 1 mysql mysql 284 20. Mai 22:06 mysql-binlog.000038
-rw-r----- 1 mysql mysql 284 21. Mai 10:28 mysql-binlog.000039
-rw-r----- 1 mysql mysql 284 21. Mai 10:28 mysql-binlog.000040
-rw-r----- 1 mysql mysql 284 21. Mai 10:28 mysql-binlog.000041
-rw-r----- 1 mysql mysql 491 21. Mai 10:31 mysql-binlog.000042
-rw-r----- 1 mysql mysql 204 21. Mai 10:30 mysql-binlog.index
Binärprotokolle der Hauptbibliothek leeren
(root:db1@xucl:10:32:51)[(keine)]> Binärprotokolle leeren;
Abfrage OK, 0 Zeilen betroffen (0,01 Sek.)
(root:db1@xucl:10:32:57)[(keine)]> Binärprotokolle anzeigen;
+---------------------+------------+
| Protokollname | Dateigröße |
+---------------------+-------------+
|mysql-binlog.000031 | 1019 |
|mysql-binlog.000032 | 424 |
|mysql-binlog.000033 | 244 |
|mysql-binlog.000034 | 2332 |
|mysql-binlog.000035 | 2134 |
|mysql-binlog.000036 | 845915 |
|mysql-binlog.000037 | 11735 |
|mysql-binlog.000038 | 284 |
|mysql-binlog.000039 | 284 |
|mysql-binlog.000040 | 284 |
|mysql-binlog.000041 | 284 |
|mysql-binlog.000042 | 541 |
|mysql-binlog.000043 | 234 |
+---------------------+-------------+
13 Zeilen im Satz (0,00 Sek.)
An dieser Stelle meldet der Slave folgenden Fehler:
(root:db1@xucl:10:31:05)[(keine)]> Slave-Status anzeigen\G
*************************** 1. Reihe ***************************
        Slave_IO_State:
         Master_Host: 127.0.0.1
         Master_Benutzer: repl
         Master_Port: 3306
        Verbindungswiederholung: 60
       Master_Log_File: mysql-binlog.000035
     Read_Master_Log_Pos: 194
        Relay_Log_File: izbp12nspj47ypto9t6vyez-relay-bin.000011
        Relay_Log_Pos: 373
    Relay_Master_Log_File: mysql-binlog.000035
       Slave_IO_Running: Nein
      Slave_SQL_Running: Ja
       Replicate_Do_DB:
     Replikat_Ignorieren_DB:
      Tabelle_replizieren:
    Tabelle_Ignorieren_replizieren:
   Wild_Do_Tabelle replizieren:
 Tabelle_Wild_Ignore_replizieren:
          Last_Errno: 0
          Letzter_Fehler:
         Skip_Counter: 0
     Exec_Master_Log_Pos: 194
       Relay_Log_Space: 648
       Until_Condition: Keine
        Bis_Log_Datei:
        Bis_Log_Pos: 0
      Master_SSL_Allowed: Nein
      Master_SSL_CA_Datei:
      Master_SSL_CA_Pfad:
       Master_SSL_Zertifikat:
      Master_SSL_Chiffre:
        Master_SSL_Schlüssel:
    Seconds_Behind_Master: NULL
Master_SSL_Verify_Server_Cert: Nein
        Last_IO_Errno: 1236
        Last_IO_Error: Beim Lesen der Daten aus dem Binärprotokoll ist vom Master der schwerwiegende Fehler 1236 aufgetreten: „GTID-Transaktion kann nicht repliziert werden, wenn @@GLOBAL.GTID_MODE = OFF, bei Datei /storage/single/mysql3306/logs/mysql-binlog.000035, Position 194.; das erste Ereignis „mysql-binlog.000039“ bei 234, das letzte Ereignis wurde aus „/storage/single/mysql3306/logs/mysql-binlog.000035“ bei 259 gelesen, das letzte Byte wurde aus „/storage/single/mysql33“ gelesen.“
        Last_SQL_Errno: 0
        Letzter_SQL_Fehler:
 Server-IDs replizieren_ignorieren:
       Master_Server_Id: 3306
         Master_UUID: e8bdf01a-c79b-11e8-82b3-00163e088352
       Master_Info_Datei: mysql.slave_master_info
          SQL_Delay: 0
     SQL_Remaining_Delay: NULL
   Slave_SQL_Running_State: Slave hat alle Relay-Logs gelesen; wartet auf weitere Updates
      Master_Retry_Count: 86400
         Master_Bind:
   Letzter_IO_Error_Timestamp: 190521 10:32:57
   Letzter_SQL_Fehler_Zeitstempel:
        Master_SSL_Crl:
      Master_SSL_Crlpfad:
      Abgerufenes_Gtid_Set:
      Ausgeführtes_Gtid_Set: 4c423515-6661-11e9-b767-00163e088352:1-7,
e8bdf01a-c79b-11e8-82b3-00163e088352:1-57192
        Auto_Position: 0
     DB replizieren_neu schreiben:
         Kanalname:
      Master_TLS_Version:
1 Zeile im Satz (0,00 Sek.)
Aus dem Fehler auf dem Slave geht hervor, dass der Slave, nachdem der Master die Binärprotokolle geleert hat, das registrierte Binärprotokoll liest und erneut anwendet.

3. Phänomenerklärung

Im gesamten Test scheint MySQL die manuell registrierten Dateien zu übertragen und anzuwenden. Der Fehler liegt daran, dass die Bibliothek früher GITD_MODE=ON hatte, aber während des Tests wurde GTID_MODE ausgeschaltet und in den POSITION-Modus geändert. Der Fehler liegt daran, dass der DUMP-Thread Folgendes erkennt:

Dieses Bild stammt aus einer neuen Serie, die ich geschrieben habe (sie ist noch nicht veröffentlicht und wird voraussichtlich bis Ende des Jahres fertiggestellt sein). Auf jeden Fall hat der DUMP-Thread mit der Übertragung alter Binlog-Dateien begonnen. Was ist also der Grund? Wir erklären es weiter unten.

4. Binärprotokollvorgänge im Binlog leeren

Das Leeren von Binärprotokollen umfasst die folgenden Vorgänge:

  • Holen Sie sich den neuen Binlog-Dateinamen
  • Schließen Sie das alte Binlog
  • Schließen Sie die Indexdatei
  • Öffnen Sie die Indexdatei
  • Öffnen Sie ein neues Binlog
  • Neues Binärprotokoll zur Indexdatei hinzufügen

Einzelheiten finden Sie in der Funktion MYSQL_BIN_LOG::new_file_impl. Es ist zu beachten, dass das Abrufen des neuen Binlog-Dateinamens durch die Funktion find_uniq_filename implementiert wird, die den folgenden Code enthält:

 file_info= Verzeichnisinfo->Verzeichniseintrag;
 für (i = dir_info->Anzahl_aus_Dateien; i--; file_info++)
 {
  wenn (strncmp(file_info->name, start, länge) == 0 &&
  ist_Nummer(Dateiinfo->Name+Länge, &Nummer,0))
  {
   setze_wenn_größer(max_gefunden, Zahl);
  }
 }
...
 *nächstes = (nächstes_brauchen || max_gefunden == 0) ? max_gefunden + 1 : max_gefunden;

Die allgemeine Bedeutung besteht darin, die Binlog-Dateien in der Indexdatei zu scannen, die mit der höchsten Sequenznummer zu erhalten und dann 1 hinzuzufügen. Der Stapelrahmen sieht wie folgt aus:

#0 find_uniq_filename (Name=0x7fffec5ec6d0 "/mysqldata/mysql3340/log/binlog", Weiter=0x7fffec5ec678, Weiter_brauchen=true)
  bei /mysqldata/percona-server-locks-detail-5.7.22/sql/binlog.cc:3679
#1 0x000000000187d208 in generate_new_log_name (new_name=0x7fffec5ec6d0 "/mysqldata/mysql3340/log/binlog", new_ext=0x0, 
  log_name=0x7ffedc011520 "/mysqldata/mysql3340/log/binlog", is_binlog=true) bei /mysqldata/percona-server-locks-detail-5.7.22/sql/binlog.cc:3767
#2 0x0000000001884fdb in MYSQL_BIN_LOG::new_file_impl (dies=0x2e83640, need_lock_log=false, extra_description_event=0x0)
  bei /mysqldata/percona-server-locks-detail-5.7.22/sql/binlog.cc:7175
#3 0x0000000001884cbb in MYSQL_BIN_LOG::neue_Datei_ohne_Sperre (dies=0x2e83640, extra_description_event=0x0)
  bei /mysqldata/percona-server-locks-detail-5.7.22/sql/binlog.cc:7099
#4 0x0000000001886b6b in MYSQL_BIN_LOG::rotate (diese=0x2e83640, force_rotate=true, check_purge=0x7fffec5ecbfb)
  bei /mysqldata/percona-server-locks-detail-5.7.22/sql/binlog.cc:7775
#5 0x0000000001886d53 in MYSQL_BIN_LOG::rotate_and_purge (dies=0x2e83640, thd=0x7ffedc000b90, force_rotate=true)
  bei /mysqldata/percona-server-locks-detail-5.7.22/sql/binlog.cc:7846

Selbst wenn wir die Indexdatei manuell ändern, gibt es daher kein Problem beim Leeren der Binärprotokolle, da die Indexdatei tatsächlich gescannt wird.
Gleichzeitig können wir sehen, dass durch das Leeren der Binärprotokolle die Indexdatei neu geladen wird. Zu diesem Zeitpunkt wird die manuell geänderte Indexdatei wirksam. Verwenden Sie „Binärprotokolle anzeigen“, um die von Ihnen hinzugefügten Dateien anzuzeigen.

5. Die Entstehung des Master-Slave-Problems

Nachdem das Binlog umgeschaltet wurde, muss der DUMP-Thread auch die nächste Binlog-Datei lesen. Sehen wir uns an, wie bestimmt wird, welche Datei gelesen werden soll.

Den Code zum Durchlaufen jeder Binärprotokolldatei finden Sie in der Funktion sender.run(). Der folgende Satz dient zum Auffinden der nächsten Binlog-Datei:

int-Fehler = mysql_bin_log.find_next_log(&m_linfo, 0);

mysql_bin_log.find_next_log enthält den folgenden Code:

 my_b_seek(&index_file, linfo->index_file_offset);//Versatz linfo->index_file_start_offset = linfo->index_file_offset;
 length=my_b_gets(&index_file, fname, FN_REFLEN)); //Dateinamen lesen...
  wenn (normalize_binlog_name (vollständiger_Fname, Fname, is_relay_log))
...

 linfo->index_file_offset = my_b_tell(&index_file); //Der Offset wird für die nächste Verwendung neu aufgezeichnet

Wir können sehen, dass der DUMP-Thread nicht wirklich die gesamte Indexdatei scannt, sondern einen Indexdatei-Offset durchliest. Wenn Sie die Indexdatei manuell ändern, wird der Offset durcheinandergebracht. Daher ist die nächste von DUMP gesendete Datei undefiniert. Daher tritt das Phänomen auf, dass manuell registrierte Binlog-Dateien an die Slave-Bibliothek gesendet werden. In diesem Fall können die folgenden Situationen auftreten:

  1. Wenn GTID_MODE deaktiviert ist und POSITION verwendet wird, wird in diesem Fall ein Fehler gemeldet, z. B. doppelte Zeilen.
  2. Wenn GTID_MODE und AUTO_POSITION = 1 sind, filtert der DUMP-Thread die GTID und sendet sie nicht. Da das Ereignis nicht gesendet wird, bleibt die Verzögerung für einen bestimmten Zeitraum bei 0.
  3. Wenn GTID_MODE und AUTO_POSITION=0, filtert der SQL-Thread beim Anwenden von GITD_EVENT und die Verzögerung kann sehr groß sein.

Obwohl GTID dieses Problem möglicherweise abschirmen kann, erwägt der DUMP-Thread bereits, alte Binlog-Dateien zu senden, was nicht angemessen ist.

6. Durch das Bereinigen von Binärprotokollen kann dieser Offset beibehalten werden

Warum verursacht das Bereinigen von Binärprotokollen keine Probleme? Weil bei der Anweisung zum Bereinigen von Binärprotokollen der Offset wie folgt beibehalten wird:

 virtueller void-Operator()(THD *thd)
 {
  LOG_INFO* linfo;
  mysql_mutex_lock(&thd->LOCK_thd_data);
  wenn ((linfo = thd->current_linfo)) //b binlog.cc:2829
  {
   /*
    Der Indexdatei-Offset kann nur dann kleiner als der Lösch-Offset sein, wenn
    wir haben gerade mit dem Lesen der Indexdatei begonnen.
    wir müssen nichts anpassen.
   */
   wenn (linfo->Indexdateioffset < m_Purge_Offset)
    linfo->fatal = (linfo->index_file_offset != 0);
   anders
    linfo->index_file_offset -= m_purge_offset;
  }
  mysql_mutex_unlock(&thd->LOCK_thd_data);

Wir können eine Anweisung wie linfo->index_file_offset -= m_purge_offset; sehen. Hier ist der Stapelrahmen:

#0 Adjust_offset::operator() (dies=0x7fffec5ec720, thd=0x7ffedc000be0) bei /mysqldata/percona-server-locks-detail-5.7.22/sql/binlog.cc:2831
#1 0x0000000000eef320 in Do_THD::operator() (dies=0x7fffec5ec6a0, thd=0x7ffedc000be0) bei /mysqldata/percona-server-locks-detail-5.7.22/sql/mysqld_thd_manager.cc:46
#2 0x0000000000eefa0f in std::for_each<THD**, Do_THD> (__first=0x3003358, __last=0x3003368, __f=...)
  unter /usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../include/c++/4.4.7/bits/stl_algo.h:4200
#3 0x0000000000eeefc0 in Global_THD_manager::do_for_all_thd (diese=0x3003340, Funktion=0x7fffec5ec720)
  bei /mysqldata/percona-server-locks-detail-5.7.22/sql/mysqld_thd_manager.cc:273
#4 0x000000000187ae0a in adjust_linfo_offsets (purge_offset=0) bei /mysqldata/percona-server-locks-detail-5.7.22/sql/binlog.cc:2873
#5 0x0000000001883239 in MYSQL_BIN_LOG::remove_logs_from_index (dies=0x2e83640, log_info=0x7fffec5ec7d0, need_update_threads=true)
  bei /mysqldata/percona-server-locks-detail-5.7.22/sql/binlog.cc:6352
#6 0x0000000001883676 in MYSQL_BIN_LOG::purge_logs (dies=0x2e83640, to_log=0x7fffec5eca80 "/mysqldata/mysql3340/log/binlog.000001", enthalten=false, 
  need_lock_index=true, need_update_threads=true, decrease_log_space=0x0, auto_purge=false) bei /mysqldata/percona-server-locks-detail-5.7.22/sql/binlog.cc:6469
#7 0x000000000187b4b5 in purge_master_logs (thd=0x7ffee0000c00, to_log=0x7ffee0006600 "binlog.000001")
  bei /mysqldata/percona-server-locks-detail-5.7.22/sql/binlog.cc:3127

7. Testen Sie den Fehler im POSITION-Modus

1. Umwelt

mysql> Binärprotokolle anzeigen;
+---------------+-----------+
| Protokollname | Dateigröße |
+---------------+-----------+
| binlog.000001 | 198 |
| binlog.000002 | 154 |
+---------------+-----------+
2 Zeilen im Satz (0,00 Sek.)

mysql> anzeigen, Tabelle erstellen, testcp \G;
*************************** 1. Reihe ***************************
    Tabelle: testcp
Tabelle erstellen: CREATE TABLE `testcp` (
 `id` int(11) NICHT NULL,
 PRIMÄRSCHLÜSSEL (`id`)
) ENGINE=InnoDB STANDARD-CHARSET=utf8
1 Zeile im Satz (0,00 Sek.)

FEHLER: 
Keine Abfrage angegeben

2. Führen Sie eine Anweisung aus

Hauptbibliothek:

mysql> in testcp-Werte einfügen (20);
Abfrage OK, 1 Zeile betroffen (0,43 Sek.)

mysql> wähle * aus testcp;
+----+
|Ich würde|
+----+
| 10 |
| 20 |
+----+
2 Zeilen im Satz (0,01 Sek.)

Aus der Bibliothek:

mysql> Slave-Status anzeigen \G;
*************************** 1. Reihe ***************************
        Slave_IO_State: Wartet darauf, dass der Master ein Ereignis sendet
         Master_Host: 192.168.99.41
         Master_Benutzer: repl
         Master_Port: 3340
        Verbindungswiederholung: 60
       Master_Log_File: binlog.000002
     Read_Master_Log_Pos: 417
        Relay_Log_Datei: relay.000004
        Relay_Log_Pos: 624
    Relay_Master_Log_File: binlog.000002
       Slave_IO_Running: Ja
      Slave_SQL_Running: Ja
...
mysql> wähle * aus testcp;
+----+
|Ich würde|
+----+
| 10 |
| 20 |
+----+

Zu diesem Zeitpunkt lautet der Offsetzeiger der DUMP-Thread-Indexdatei wie folgt:

3. Die Hauptdatenbank führt eine Bereinigung der Binärprotokolle durch

Kopieren Sie vorher das Original binlog.000001 nach binlog.000001bak, da Sie es später wieder zurückkopieren müssen.

mysql> Binärprotokolle nach „binlog.000002“ löschen;
Abfrage OK, 0 Zeilen betroffen (3,14 Sek.)

mysql> Binärprotokolle anzeigen;
+---------------+-----------+
| Protokollname | Dateigröße |
+---------------+-----------+
| binlog.000002 | 417 |
+---------------+-----------+
1 Zeile im Satz (0,00 Sek.)

Da der Befehl „Binärprotokolle bereinigen“ den Offsetzeiger verwaltet, lautet der Indexdatei-Offsetzeiger des DUMP-Threads wie folgt:

4. Manuelle Änderungen

Kopieren Sie binlog.000001bak nach binlog.000001, ändern Sie dann die Indexdatei, um binlog.000001 wieder hinzuzufügen, und leeren Sie dann die Binärprotokolle wie folgt:

mysql> Binärprotokolle leeren;
Abfrage OK, 0 Zeilen betroffen (0,15 Sek.)

mysql> Binärprotokolle anzeigen;
+---------------+-----------+
| Protokollname | Dateigröße |
+---------------+-----------+
| binlog.000001 | 198 |
| binlog.000002 | 461 |
+---------------+-----------+
2 Zeilen im Satz (0,00 Sek.)

Wenn Sie dies manuell tun, bleibt der Indexdatei-Offsetzeiger des DUMP-Threads nicht erhalten. Es läuft also wie folgt ab:

Auf diese Weise sendet der DUMP-Thread den Inhalt von binlog.000002 erneut, und die Slave-Bibliothek von POSITION kann nur wie folgt einen Fehler melden:

mysql> wähle * aus replication_applier_status_by_worker \G
*************************** 1. Reihe ***************************
     KANALNAME: 
      WORKER_ID: 1
      THREAD_ID: NULL
    SERVICE_STATE: AUS
LAST_SEEN_TRANSACTION: ANONYM
  LAST_ERROR_NUMBER: 1062
  LAST_ERROR_MESSAGE: Worker 1 konnte die Transaktion „ANONYMOUS“ im Master-Log binlog.000002, end_log_pos 386 nicht ausführen; Write_rows-Ereignis konnte für Tabelle testmts.testcp nicht ausgeführt werden; Doppelter Eintrag „20“ für Schlüssel „PRIMARY“, Fehlercode: 1062; Handler-Fehler HA_ERR_FOUND_DUPP_KEY; das Master-Log des Ereignisses binlog.000002, end_log_pos 386
 LAST_ERROR_TIMESTAMP: 2019-05-21 14:46:26

8. Fazit

Dieser Vorgang ist sehr unregelmäßig. Wenn Sie dies wirklich tun möchten, beachten Sie die folgenden Schritte:

  • Schließen Sie alle Slave-Bibliotheken
  • Binlog-Dateien manuell registrieren und Indexdateien ändern
  • Binärprotokolle leeren
  • Starten Sie die Slave-Bibliothek

In diesem Fall wird der DUMP-Offsetzeiger neu initialisiert, daher sollte kein Problem auftreten. Versuchen Sie, nicht einmal daran zu denken.

Oben finden Sie ausführliche Informationen zu den Gründen, warum die Master-Slave-Abnormalität durch die manuelle Registrierung von MySQL-Binlog-Dateien verursacht wird. Weitere Informationen zu MySQL-Master-Slave-Abnormalitäten finden Sie in den anderen verwandten Artikeln auf 123WORDPRESS.COM!

Das könnte Sie auch interessieren:
  • So zeigen Sie MySQL-Links an und löschen abnormale Links
  • Zusammenfassung der Ausnahmen bei der MySQL-Datenbankverbindung (sammelwürdig)
  • So beheben Sie den abnormalen Start von mysql5.7.21
  • Erfahrungsaustausch zur Reparatur von MySQL InnoDB-Ausnahmen
  • MySQL-Definition und Details zur Ausnahmebehandlung
  • Einige grundlegende Tutorials zur Ausnahmebehandlung in gespeicherten MySQL-Prozeduren
  • Analysieren eines abnormalen MySQL-Abfragefalls
  • Eine kurze Analyse der MySQL-Ausnahmebehandlung
  • Analysieren Sie mehrere gängige Lösungen für MySQL-Ausnahmen

<<:  Lösung für FileZilla 425. Verbindung zum FTP (Alibaba Cloud Server) nicht möglich.

>>:  So stellen Sie ein SSL-Zertifikat in einer Windows-Apache-Umgebung bereit, damit die Website https unterstützt

Artikel empfehlen

Zwei Methoden zum Wiederherstellen von MySQL-Daten

1. Einleitung Vor einiger Zeit gab es eine Reihe ...

Detaillierte Erklärung des Grid-Layouts und des Flex-Layouts der Anzeige in CSS3

Das Gitterlayout weist einige Ähnlichkeiten mit d...

Eigenschaften von JavaScript-Pfeilfunktionen und Unterschiede zu normalen Funktionen

Inhaltsverzeichnis 1. Verwendung von Pfeilfunktio...

Linux-Installationsschritte für Jenkins und verschiedene Problemlösungen (Seitenzugriffsinitialisierungskennwort)

1. Bereiten Sie die Java-Umgebung vor, jdk1.8 Übe...

Lösung für das Problem, dass die virtuelle Maschine Ubuntu 16.04 keine Verbindung zum Internet herstellen kann

Ich habe gerade Ubuntu installiert und als ich es...

Prozessdiagramm zur Implementierung der Zabbix WEB-Überwachung

Nehmen Sie als Beispiel die WEB-Schnittstelle von...

Lösung für Fremdschlüsselfehler bei der MySQL-Tabellenerstellung

Datenbanktabelle A: Tabelle erstellen Task_Desc_T...

MySQL partitioniert vorhandene Tabellen in der Datentabelle

Inhaltsverzeichnis So funktioniert es Betriebsabl...

React + ts realisiert den sekundären Verknüpfungseffekt

In diesem Artikel wird der spezifische Code von R...

So leiten Sie eine URL mit Nginx Rewrite um

Ich muss in letzter Zeit bei der Arbeit oft die N...

Beschreibung der Ausführungsmechanismen von statischen Seiten und dynamischen Seiten

1. Eine statische Seite bedeutet, dass die Webseit...

HTML-Webseite: geordnete Liste ol und ungeordnete Liste ul

Listen zum Organisieren von Daten Nachdem die Les...

Leitfaden zu bewährten Methoden für die Benutzerautorisierung im WeChat Mini-Programm

Vorwort Bei der Entwicklung von WeChat-Applets mü...

Zusammenfassung der speicherbezogenen Parameter von MySQL 8.0

Theoretisch entspricht der von MySQL verwendete S...

Verwenden Sie PSSH zur Stapelverwaltung von Linux-Servern

pssh ist eine in Python implementierte Open-Sourc...