English | 简体中文 | 繁體中文 | Русский язык | Français | Español | Português | Deutsch | 日本語 | 한국어 | Italiano | بالعربية
对于做过大型系统的人来说，日志的作用不容小觑，通常在项目后期，对项目进行优化升级都是基于日志做出的升级优化决策。那么学习MySQL，日志部分当然不能错过。我们在面试中实际应用的所讨论的优化都是要从日志中得出的。系统地学习MySQL的日志，有助于我们准确定位问题，提高自己的工作水平。此外，后续的一系列日志将重点从DBA的运维方面进行探讨，系统地理解MySQL各方面的配置，做到知己知彼，使MySQL成为得心应手的数据仓库。
1. MySQL的日志类型
By default, all MySQL logs are stored in the file format in the root directory of the database:
[root@roverliang data]# pwd /usr/local/webserver/extend_lib/mysql/data [root@roverliang data]# ls auto.cnf ibdata1 ib_logfile0 ib_logfile1 mysql mytest performance_schema roverliang roverliang.err roverliang.pid test
The types of MySQL logs are as follows:
1. Error Log (error), information related to the start, operation, or stop of the MySQL service instance.
2. Standard Query Log (general), all SQL statements or MySQL commands executed by the MySQL service instance.
3. Binary Log (binary), all update statements executed on the database, excluding select and show statements.
4. Slow Query Log (slow), SQL statements that take longer than the value set by long_query_time, or SQL statements that do not use an index.
2. MySQL Log Cache
A high-speed, stable, and reliable system, caching plays a crucial role in it. MySQL log processing also uses caching mechanisms. Initially, MySQL logs are stored in the memory of the MySQL server. If the storage capacity exceeds the specified limit, the logs in memory are written (or flushed) to external storage in the form of a database table or a file, and are permanently stored on the hard disk.
3. MySQL Error Log (error log)
The error log of MySQL mainly records the detailed information of each start and stop of the MySQL service instance, as well as warnings or error information generated during the operation of the MySQL instance. Unlike other logs, the error log of MySQL must be enabled and cannot be disabled.
By default, the name of the error log file is: hostname.err. However, the error log does not record all error information; only critical errors that occur during the operation of the MySQL service instance are recorded.
mysql> show variables like 'log_error'\G *************************** 1. Reihe *************************** Variable_name: log_error Value: /usr/local/webserver/extend_lib/mysql/data/roverliang.err 1 row in set (0.02 sec)
4. MySQL Standard Query Log (general log)
MySQL Standard Query Log records all operations of the MySQL service instance, such as select, update, insert, delete, and so on, regardless of whether the operation is executed successfully. It also includes relevant information about the connection and disconnection of the MySQL client and MySQL server, regardless of whether the connection is successful or not. There are three parameters related to the MySQL standard query log.
[]()general_log mysql> show variables like 'general_log'; +---------------+-------+ | Variable_name | Wert | +---------------+-------+ | general_log | AUS | +---------------+-------+ 1 row in set (0.01 sec)
Man kann 'set @@global.general_log = 1 in der Weise aktivieren.
mysql> set @@global.general_log =1; mysql> show variables like 'general_log'; +---------------+-------+ | Variable_name | Wert | +---------------+-------+ | general_log | AN | +---------------+-------+
Durch diese Methode geänderte MySQL-variablen wirken nur während der Laufzeit des aktuellen MySQL-Instanzes, werden MySQL neu gestartet, kehrt der Wert zurück zum Standardstatus. Der dauerhafte Effekt ist, die Datei 'my.cnf' von MySQL zu ändern. Fügen Sie im Konfigurationsdatei nach:
general_log = 1
general_log_file
Wenn die normalen Abfrageprotokolle aktiviert sind, erstellt der MySQL-Dienstinstanz automatisch die Protokolldatei der normalen Abfrageprotokolle, und der Parameter 'general_log_file' hat die physische Position der Protokolldatei der normalen Abfrageprotokolle festgelegt. Zum Beispiel:
mysql> show variables like 'general_log_file'; +------------------+-----------------------------------------------------------+ | Variablenname | Wert | +------------------+-----------------------------------------------------------+ | general_log_file | /usr/local/webserver/extend_lib/mysql/data/roverliang.log | +------------------+-----------------------------------------------------------+
Hinweis: Da die normalen Abfrageprotokolle fast alle Operationen von MySQL aufzeichnen, würde die Aktivierung der normalen Abfrageprotokolle von MySQL die Leistung der Datenbank erheblich verringern, wenn die Datenbankserver häufig auf Daten zugreifen. Daher wird empfohlen, die normalen Abfrageprotokolle auszuschalten. Nur in besonderen Zeiten, wenn bestimmte spezielle Abfrageprotokolle verfolgt werden müssen, kann die normale Abfrageprotokolle temporär geöffnet werden.
log_output
Der Parameter 'log_output' hat die Einstellung, dass der Inhalt der normalen Abfrageprotokolle und der langsamen Abfrageprotokolle in die Datenbanktabelle gespeichert wird. Man kann die normalen Abfrageprotokolle und die langsamen Abfrageprotokolle in die MySQL-Systemdatenbank in die Tabellen 'general' und 'slow_log' speichern, indem man 'set @@global.log_output='table'' verwendet. Zu beachten ist, dass die Speicherengines dieser beiden Tabellen CSV sind, sodass man die neuen Inhalte der normalen Abfrageprotokolle abrufen kann, indem man SQL-Anweisungen verwendet;
set @@global.log_output = 'table'; mysql> show variables like 'log_output'; +---------------+-------+ | Variable_name | Wert | +---------------+-------+ | log_output | TABLE | +---------------+-------+
Fünf, MySQL Slow-Query-Log (slow log)
Probleme mit dem Slow-Query-Log sind ein beliebtes Thema in Interviews. Früher konnte man nur über das Master-Slave-Design von MySQL und die verschiedenen Optimierungsmöglichkeiten sprechen, aber man hat nie wirklich verstanden, wie man das Slow-Query-Log aktiviert und konfiguriert.
Die Verwendung des MySQL Slow-Query-Logs ermöglicht eine effektive Verfolgung von Anfragen mit zu langer Ausführungsdauer oder ohne Indexnutzung. Dies umfasst SELECT-, UPDATE-, DELETE- und INSERT-Anweisungen und hilft bei der Optimierung der Abfragen. Ein weiterer Unterschied zu den normalen Query-Logs ist, dass das Slow-Query-Log nur erfolgreiche Abfragen enthält. Mit Bezug auf die Slow-Query-Logs gibt es mehrere Parameter:5Stück.
1、slow_query_log
slow_query_log stellt ein, ob das Slow-Query-Log aktiviert ist.
mysql> show variables like 'slow_query_log'; +----------------+-------+ | Variable_name | Wert | +----------------+-------+ | slow_query_log | OFF | +----------------+-------+
2、slow_query_log_file
Wenn das Slow-Query-Log aktiviert ist, erstellt der MySQL-Server automatisch die Slow-Query-Log-Datei. Die Datei, die durch slowquerylog_file angegeben wird, enthält den Inhalt des Slow-Query-Logs. Die Änderungsmethode ist wie im obigen Text beschrieben. Bearbeiten Sie einfach die my.cnf-Datei.
3、long_query_time
long_query_time legt den Zeit阈值 für Slow Queries fest. Der Standardwert ist10s。
4、log_quries_not_using_indexes
log_quries_not_using_indexes entscheidet, ob Anfragen, die keine Indizes verwenden, in das Slow-Query-Log eingetragen werden, unabhängig von der Geschwindigkeit der Abfrage.
mysql> set @@global.log_queries_not_using_indexes=1; mysql> show variables like 'log_queries_not_using_indexes'; +-------------------------------+-------+ | Variable_name | Value | +-------------------------------+-------+ | log_queries_not_using_indexes | ON | +-------------------------------+-------+
5、log_output
设置了普通查询日志以及慢查询日志的输出形式，值有两个 file、table;
六、MySQL 慢查询日志查看
log_output 参数可以设置慢查询日志的输出形式。默认为 FILE，可以设置为 TABLE;
mysql> desc mysql.slow_log; +----------------+---------------------+ | Field | Type | +----------------+---------------------+ | start_time | timestamp | | user_host | mediumtext | | query_time | time | | lock_time | time | | rows_sent | int(11) | | rows_examined | int(11) | | db | varchar(512) | | last_insert_id | int(11) | | insert_id | int(11) | | server_id | int(10) unsigned | | sql_text | mediumtext | | thread_id | bigint(21) unsigned | +----------------+---------------------+
其中: lock_time 表示该 SQL 执行时被锁阻塞的时间。rows_send 表示执行 SQL 后返回的内容行数。rows_examined 表示该 SQL 执行时实际扫描的记录条数。
但是使用 TABLE 来存储慢查询日志并不常见，业务量较大的情况下，对于系统的主服务会有影响。我们可以使用 FILE 的方式来进行日志存储。安装 MySQL 的时候在 MySQL 的 bin 目录下已经默认安装了 mysqldumpslow.pl 工具来进行慢查询的日志分析。在 window 下使用这个工具，可能需要一些配置，这不在本文的介绍范围内，学习系统服务，还是移步 Linux 吧。Linux 下的命令以及工具都可以使用 命令本身。 + --使用 help 的选项来查看帮助文档。
-s bedeutet, wie man sortieren soll
Unterschiedliche Optionen: c, t, l, r
c: Anzahl der Ausführungen der SQL
t: Ausführungszeit
l: Wartezeit des Locks
r: Gibt die Anzahl der Datenzeilen zurück
at, al, ar sind die Durchschnitte von t, l, r. -t: Stellt dar, wie viele Einträge zurückgegeben werden sollen.
-g: grep-Abkürzung. Enthält fließende Übereinstimmungen
Häufig verwendete Methoden:
//Gibt die Anzahl der Zugriffe zurück20 SQL-Anweisungen ./mysqldumpslow -s c -t 20 /usr/local/webserver/extend_lib/mysql/data/roverliang-slow.log //Gibt die Anzahl der zurückgegebenen return-Aufzeichnungen zurück20 SQL-Anweisungen ./mysqldumpslow -s r -t 20 /usr/local/webserver/extend_lib/mysql/data/roverliang-slow.log //Gibt SQL-Anweisungen zurück, die 'like' enthalten ./mysqldumpslow -g 'like' 20 /usr/local/webserver/extend_lib/mysql/data/roverliang-slow.log
Siebentens, Binärprotokoll (binary)
Das Binärprotokoll unterscheidet sich von den zuvor erwähnten Arten von Protokollen, das Binärprotokoll kann nicht direkt mit cat oder dem Textbetrachter less angezeigt werden. Es ist notwendigerweise mit spezialisierten Werkzeugen zu verwenden. Das Binärprotokoll protokolliert hauptsächlich die Änderungen der Datenbank, kann daher als Synchronisationsprotokoll zwischen Master- und Slave-DB verwendet werden. Zu den Hauptinhalten gehören alle Update-Operationen der Datenbank, use-Anweisungen, insert-Anweisungen, delete-Anweisungen, update-Anweisungen, create-Anweisungen, alter-Anweisungen, drop-Anweisungen. Mit einem einfacheren und verständlicheren Satz zusammengefasst: Alle Operationen, die Datenänderungen betreffen, müssen in das Binärprotokoll aufgenommen werden.
Aktivierung des Binärprotokolls Über show variables like 'log_bin'\G kann überprüft werden, ob das Binärprotokoll aktiviert ist.
mysql> show variables like 'log_bin'\G
*************************** 1. Reihe ***************************
Variablenname: log_bin
Wert: AUS
1 row in set (0.00 sec)
mysql> set @@global.log_bin=1;
ERROR 1238 (HY000): Variable 'log_bin' ist eine schreibgeschützte Variable
mysql>
Man sieht, dass log_bin standardmäßig nicht aktiviert ist und ein schreibgeschützter Variable ist, die in der Datei my.cnf konfiguriert werden muss, und dann MySQL neu starten. service mysql restart Nach dem Neustart von MySQL wird im Verzeichnis data eine neue Datei erstellt1.000001Die Datei. Tatsächlich wird bei jedem Neustart von MySQL in diesem Verzeichnis eine solche Datei erstellt, deren Namen in aufsteigender Reihenfolge zunehmen. Außerdem erstellt MySQL in diesem Verzeichnis eine Indexdatei für das Binärprotokoll, deren Position man mit dem Befehl show variables like 'log_bin_index'\G überprüfen kann, und dann mit dem cat-Befehl ansehen. Man wird feststellen, dass darin die relativen Pfade der Binärdateien aufgeführt sind.
Um den Binlog zu betrachten, können Sie die im MySQL enthaltenen Werkzeuge verwenden. Der genaue Ort befindet sich im bin-Verzeichnis von MySQL. Häufig verwendete Optionen des mysqlbinlog-Befehls:
-s Zeige den Protokollinhalt im komprimierten Modus
-v Zeige den Protokollinhalt im detaillierten Modus
-d=Database_name Zeige nur den Inhalt der Protokolldatei der angegebenen Datenbank
-o=n Ignoriere die ersten n Zeilen der MySQL-Kommandos im Protokoll
-r=file Schreibe den angegebenen Inhalt in die angegebene Datei
--start-datetime
Zeige den Inhalt der Protokolldatei im angegebenen Zeitbereich an
--stop-datetime
--start-position
Zeige den Inhalt der Protokolldatei im angegebenen Positionsbereich an
--stop-position
Erhalten Sie den aktuellen verwendeten Binlog-Datei
mysql> show master status; +----------+----------+--------------+------------------+-------------------+ | Datei | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set | +----------+----------+--------------+------------------+-------------------+ | 1.000002 | 120 | | | | +----------+----------+--------------+------------------+-------------------+ 1 row in set (0.00 sec)
Datenwiederherstellung mit dem Binlog
Die Syntax ist einfach:
mysqlbinlog -s 1.000001 | mysql -h 192.168.1.188 -u root -p
Nach mysqlbinlog kann --start-datetime ,--stop-datetime , start-position , stop-position und anderen Parametern.
--start-datetime ,--stop-datetime Diese beiden Parameter ermöglichen die Datenwiederherstellung basierend auf Zeitpunkten;
start-position , stop-position kann zur feineren Definition des Wiederherstellungspunkts beitragen;
MySQL-Binlog-Parameter
mysql> show variables like '%binlog%'; +-----------------------------------------+----------------------+ | Variable_name | Value | +-----------------------------------------+----------------------+ | binlog_cache_size | 32768 | | binlog_checksum | CRC32 | | binlog_direct_non_transactional_updates | OFF | | binlog_error_action | IGNORE_ERROR | | binlog_format | STATEMENT | | binlog_gtid_simple_recovery | OFF | | binlog_max_flush_queue_time | 0 | | binlog_order_commits | ON | | binlog_row_image | FULL | | binlog_rows_query_log_events | OFF | | binlog_stmt_cache_size | 32768 | | binlogging_impossible_mode | IGNORE_ERROR | | innodb_api_enable_binlog | OFF | | innodb_locks_unsafe_for_binlog | OFF | | max_binlog_cache_size | 18446744073709547520 | | max_binlog_size | 1073741824 | | max_binlog_stmt_cache_size | 18446744073709547520 | | simplified_binlog_gtid_recovery | OFF | | sync_binlog | 0 | +-----------------------------------------+----------------------+
max_binlog_size
maxbinlogsize Größe eines einzelnen binären Protokolldateis. Wenn dieser Wert überschritten wird, wird eine neue Datei erstellt, mit dem Suffix+1;
binlog_cache_size
binlogcachesize Größe des Caches für binäres Protokoll im Speicher
sync_binlog
sync_binlog Schreibt mehrere Male binäres Protokoll in den Cache, beginnt mit der Synchronisierung und Aktualisierung in den externen Speicher (Festplatte).
log_slave_updates
logslvaeupdates 用于主从复制
Bereinigung der Binärdateienprotokolle
Im Prinzip sollten die Logdateien, die bereitet sind, gelöscht zu werden, zunächst durch physische Backups auf andere Speichergeräte gesichert und dauerhaft aufbewahrt werden. Danach wird empfohlen, die folgenden beiden risikoärmeren Bereinigungsmethoden zu verwenden:
Erste Methode:
Purge master logs before '2017-02-16 00:00:00';
Zweite Methode:
Setzen Sie den Parameter expire_logs_days direkt in der MySQL-Konfigurationsdatei my.cnf, um die Anzahl der Tage der Binarydateien zu konfigurieren, die abgelaufenen Binarydateien werden automatisch gelöscht. Es wird empfohlen, einen Zeitplan für die Wartung zu starten, um regelmäßig die Binarydateien zu sichern, um sicherzustellen, dass einige Daten nicht nach einigen Tagen festgestellt werden, dass es Fehler gibt, und die Binarydateien werden automatisch gelöscht.
expire_logs_days=90
Achtung, InnoDB-Transaktionsprotokoll
Die InnoDB-Transaktionsprotokolle unterscheiden sich von den vorhin erwähnten Protokollen, die InnoDB-Transaktionsprotokolle werden von der InnoDB-Speicherengine selbst verwaltet und können von Datenbankadministratoren nicht gelesen werden. MySQL nutzt den Cache so gut wie möglich, um die Effizienz des Datenzugriffs zu erhöhen. Auf diese Weise könnte man sagen, dass jeder leistungsfähige System die Nutzung des Caches benötigen muss, auf jeder Ebene spielt der Cache eine große Rolle. Und noch eine Ebene höher zusammenzufassen: Cache und Queue sind der Pfad, um leistungsfähig zu sein. Für Datenbanken ist dies jedoch ein heikles Problem, um sicherzustellen, dass Daten effizienter gelesen und gespeichert werden, muss der Cache genutzt werden. Aber um die Konsistenz der Daten zu gewährleisten, müssen alle Daten sicherstellen, dass sie genau und fehlerfrei in die Datenbank gespeichert werden, selbst wenn eine Notlage auftritt, müssen die Daten wiederherstellbar sein. Wir wissen, dass InnoDB ein transaktionsicher Speicherantrieb ist, und Konsistenz ist eine wichtige Eigenschaft der ACID-Transaktionen. Der InnoDB-Speicherantrieb erreicht die Datenkonsistenz hauptsächlich durch das InnoDB-Transaktionsprotokoll, das das Redo-Protokoll (redo) und das Rollback-Protokoll (undo) umfasst.
Redo-Protokoll (redo)
Das Redo-Protokoll speichert hauptsächlich vollständig abgeschlossene Transaktionen, d.h. Protokolle, die nach dem Ausführen von commit, und im Standardfall werden die Werte des Redo-Protokolls in iblogfile0 sowie iblogfile1im Redo-Protokoll.
[root@roverliang data]# pwd /usr/local/webserver/mysql/data [root@roverliang data]# ls ib* ibdata1 ib_logfile0 ib_logfile1
Rollback-Protokoll (undo)
Die Rollback-Protokolle speichern hauptsächlich unvollendete Transaktionen, die teilweise abgeschlossen wurden und auf die Festplatte geschrieben wurden, und die Informationen der Rollback-Protokolle werden standardmäßig in Tabellenbereichsdateien, gemeinsamen Tabellenbereichsdateien ibdata1oder in der eigenen Tabellestrecke, die in ibd nicht sichtbar ist.
Wie wir aus dem obigen Bild wissen, wird das Rollback-Log standardmäßig in ibdta1meines MySQL-Systems ist:5.6.24.
Checkpoint-Mechanismus
Nach dem Absturz des MySQL-Servers wird, wenn der MySQL-Dienst neu gestartet wird, aufgrund der Existenz des Redo-Logs (redo) und des Undo-Logs, InnoDB alle nicht abgeschlossenen Transaktionen, die bereits teilweise in die Festplatte geschrieben wurden, durch das Undo-Log (undo) zurückgerollt. Danach werden alle Transaktionen im Redo-Log (undo) erneut ausgeführt, um alle Daten wiederherzustellen. Da jedoch die Datenmenge groß ist, um die Wiederherstellungsdauer zu verkürzen, führt InnoDB das Checkpoint-Mechanismus ein.
Schmutzige Seiten (dirty page)
Wenn eine Transaktion ein bestimmtes Protokoll ändern muss, liest InnoDB zunächst den Datenblock, in dem sich das Datenprotokoll befindet, aus dem externen Speicher in die Festplatte, ändert InnoDB das Protokoll im Datenseitenpuffer nach der Transaktionserklärung, zu diesem Zeitpunkt sind die im Puffer gespeicherten Datenseiten nicht mehr mit dem Datenblock im externen Speicher identisch, die im Puffer gespeicherten Datenseiten werden daher als schmutzige Seiten (dirty pages) bezeichnet, die schmutzigen Seiten werden in den externen Speicher gelesen und werden zu sauberen Seiten (clean pages).
Anmerkung: Eine Speicherseite ist standardmäßig4K, oder4Kerzen. Man kann das Gedächtnis als ein Buch mit wischbaren Seiten vorstellen, bei dem MySQL beim Lesen von Daten einige saubere Seiten im Gedächtnis anfordert und darauf schreibt. Wenn die Daten auf die Festplatte geschrieben werden, werden diese Datenseiten sofort gelöscht und für andere Programme bereitgestellt.
Log-Sequence-Nummer (log sequence number)
Die Log-Sequence-Nummer (LSN) ist der Endpunkt jedes Eintrags im Log-Speicher, angegeben durch den Bytes-Offset, und wird bei Checkpoint und Wiederherstellung verwendet.
Prinzip des Checkpoint-Mechanismus Angenommen, dass zu einem bestimmten Zeitpunkt alle schmutzigen Seiten (dirty pages) auf die Festplatte geschrieben wurden, ist das Redo-Log (redo) vor diesem Zeitpunkt nicht mehr erforderlich. Das System verwendet also diesen Zeitpunkt als Endpunkt des Redo-Logs als Checkpoint. Die Redo-Logs vor dem Checkpoint müssen nicht mehr ausgeführt werden und können sicher gelöscht werden. Um den Speicherplatz des Redo-Logs (redo) besser zu nutzen, verwendet InnoDB eine轮循策略来使用重做日志空间， daher muss die Größe der InnoDB-Redo-Log-Datei mindestens2Durch das Checkpoint-Mechanismus, indem die Transaktionen, die bei einem Datenbankabsturz bereits abgeschlossen waren, aber noch nicht vollständig in den Auslagerungsspeicher geschrieben wurden, durch das Redo-Log (redo) erneut ausgeführt werden, kann die Konsistenz der Daten gewährleistet und die Wiederherstellungsdauer verkürzt werden.
Parameter des InnoDB-Redo-Logs (redo)
innodb_log_buffer_size: Setzt die Größe des Redo-Log-Puffers.
innodb_log_files_in_group: Legt die Anzahl der Redo-Logs (redo) in der Logdateigruppe fest.
innodb_log_file_size: Legt die Größe der Redo-Logdatei fest, je größer die Datei, desto länger dauert die Wiederherstellung.
innodb_mirrored_log_groups: Legt die Anzahl der Redo-Logdateigruppen fest, kann nur1.
innodb_log_group_home_dir: Legt den Verzeichnisort für die Logdateien der Logdateigruppe fest, Standardwert ist im Datenbankverzeichnis.
Parameter des InnoDB-Rollback-Logs (undo)
innodb_undo_directory: Legt den Verzeichnisort für das Rollback-Log fest.
innodb_undo_logs: Legt die Größe des Rollback-Logs fest, Standardwert ist128k
innodb_undo_tablespace: Legt fest, aus wie vielen Rollback-Logdateien das Rollback-Log besteht, Standardwert ist 0.
Hinweis: Nach der Installation von MySQL müssen Sie die Parameter für das Rollback-Log in der Datei my.cnf einstellen. Wenn Sie die Parameter für das Rollback-Log nach der Erstellung der Datenbank einstellen, wird MySQL einen Fehler ausgeben, und nach der Erstellung des Rollback-Logs können die Parameter nicht mehr geändert oder hinzugefügt werden.
Neun, Logdateien sichern
Beim Sichern können Sie flush logs verwenden, um alle aktuellen Logdateien zu schließen und neue Logdateien zu erzeugen. Nach dem Schließen der Logdateien können Sie physisch sichern. Außerdem kann flush logs spezifische Logtypen hinzufügen:
flush error logs flush general logs flush binary logs flush slow logs
Erklärung: Der Inhalt dieses Artikels wurde aus dem Internet übernommen und gehört dem Urheberrechtsinhaber. Der Inhalt wurde von Internetbenutzern freiwillig beigesteuert und hochgeladen. Diese Website besitzt keine Eigentumsrechte und hat den Inhalt nicht von Hand bearbeitet. Sie übernimmt keine rechtlichen Verantwortlichkeiten. Wenn Sie verdächtige Urheberrechtsinhalte finden, senden Sie bitte eine E-Mail an: notice#w3Hinweis: Bitte ersetzen Sie # durch @, wenn Sie eine E-Mail senden, um eine Meldung zu senden, und fügen Sie relevante Beweise bei. Sobald überprüft, wird die Website die beanstandeten Inhalte sofort löschen.