Mysql
 sql >> Cơ Sở Dữ Liệu >  >> RDS >> Mysql

Giám sát cơ sở dữ liệu - Khắc phục sự cố Prometheus với SCUMM Dashboards

Đã gần hai tháng kể từ khi chúng tôi phát hành SCUMM (Quản lý và Giám sát hợp nhất của Somenines ClusterControl). SCUMM sử dụng Prometheus làm phương pháp cơ bản để thu thập dữ liệu chuỗi thời gian từ các nhà xuất đang chạy trên các phiên bản cơ sở dữ liệu và bộ cân bằng tải. Blog này sẽ chỉ cho bạn cách khắc phục sự cố khi các nhà xuất Prometheus không chạy hoặc nếu biểu đồ không hiển thị dữ liệu hoặc hiển thị "Không có điểm dữ liệu".

Prometheus là gì?

Prometheus là một hệ thống giám sát mã nguồn mở với mô hình dữ liệu chiều, ngôn ngữ truy vấn linh hoạt, cơ sở dữ liệu chuỗi thời gian hiệu quả và cách tiếp cận cảnh báo hiện đại. Đây là một nền tảng giám sát thu thập các chỉ số từ các mục tiêu được giám sát bằng cách cạo các điểm cuối HTTP chỉ số trên các mục tiêu này. Nó cung cấp dữ liệu chiều, truy vấn mạnh mẽ, trực quan hóa tuyệt vời, lưu trữ hiệu quả, hoạt động đơn giản, cảnh báo chính xác, nhiều thư viện máy khách và nhiều tích hợp.

Prometheus đang hoạt động cho Trang tổng quan SCUMM

Prometheus thu thập dữ liệu chỉ số từ các nhà xuất khẩu, với mỗi nhà xuất khẩu chạy trên cơ sở dữ liệu hoặc máy chủ cân bằng tải. Sơ đồ dưới đây cho bạn thấy cách các nhà xuất khẩu này được liên kết với máy chủ lưu trữ quy trình Prometheus. Nó cho thấy rằng nút ClusterControl có Prometheus đang chạy nơi nó cũng chạy process_exporter và node_exporter.

Biểu đồ cho thấy rằng Prometheus đang chạy trên máy chủ ClusterControl và các nhà xuất process_exporter node_exporter cũng đang chạy để thu thập số liệu từ chính nút của nó. Theo tùy chọn, bạn có thể đặt máy chủ lưu trữ ClusterControl của mình làm mục tiêu cũng như trong đó bạn có thể thiết lập HAProxy hoặc ProxySQL.

Đối với các nút cụm ở trên (node1, node2 và node3), nó có thể có mysqld_exporter hoặc postgres_exporter đang chạy, là các tác nhân quét dữ liệu nội bộ trong nút đó và chuyển nó đến máy chủ Prometheus và lưu trữ trong bộ lưu trữ dữ liệu của riêng nó. Bạn có thể định vị dữ liệu vật lý của nó qua / var / lib / prometheus / data trong máy chủ lưu trữ nơi Prometheus được thiết lập.

Khi bạn thiết lập Prometheus, ví dụ, trong máy chủ ClusterControl, nó phải mở các cổng sau. Xem bên dưới:

[[email protected] share]# netstat -tnvlp46|egrep 'ex[p]|prometheu[s]'
tcp6       0      0 :::9100                 :::*                    LISTEN      16189/node_exporter 
tcp6       0      0 :::9011                 :::*                    LISTEN      19318/process_expor 
tcp6       0      0 :::42004                :::*                    LISTEN      16080/proxysql_expo 
tcp6       0      0 :::9090                 :::*                    LISTEN      31856/prometheus

Dựa trên kết quả đầu ra, tôi có ProxySQL cũng đang chạy trên máy chủ testccnode trong đó ClusterControl được lưu trữ.

Các sự cố thường gặp với Trang tổng quan SCUMM sử dụng Prometheus

Khi Trang tổng quan được bật, ClusterControl sẽ cài đặt và triển khai các tệp nhị phân và trình xuất như node_exporter, process_exporter, mysqld_exporter, postgres_exporter và daemon. Đây là những tập hợp gói phổ biến cho các nút cơ sở dữ liệu. Khi chúng được thiết lập và cài đặt, các lệnh daemon sau sẽ được kích hoạt và chạy như hình dưới đây:

[[email protected] bin]# ps axufww|egrep 'exporte[r]'
prometh+  3604  0.0  0.0  10828   364 ?        S    Nov28   0:00 daemon --name=process_exporter --output=/var/log/prometheus/process_exporter.log --env=HOME=/var/lib/prometheus --env=PATH=/usr/local/bin:/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin --chdir=/var/lib/prometheus --pidfile=/var/run/prometheus/process_exporter.pid --user=prometheus -- process_exporter
prometh+  3605  0.2  0.3 256300 14924 ?        Sl   Nov28   4:06  \_ process_exporter
prometh+  3838  0.0  0.0  10828   564 ?        S    Nov28   0:00 daemon --name=node_exporter --output=/var/log/prometheus/node_exporter.log --env=HOME=/var/lib/prometheus --env=PATH=/usr/local/bin:/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin --chdir=/var/lib/prometheus --pidfile=/var/run/prometheus/node_exporter.pid --user=prometheus -- node_exporter
prometh+  3839  0.0  0.4  44636 15568 ?        Sl   Nov28   1:08  \_ node_exporter
prometh+  4038  0.0  0.0  10828   568 ?        S    Nov28   0:00 daemon --name=mysqld_exporter --output=/var/log/prometheus/mysqld_exporter.log --env=HOME=/var/lib/prometheus --env=PATH=/usr/local/bin:/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin --chdir=/var/lib/prometheus --pidfile=/var/run/prometheus/mysqld_exporter.pid --user=prometheus -- mysqld_exporter --collect.perf_schema.eventswaits --collect.perf_schema.file_events --collect.perf_schema.file_instances --collect.perf_schema.indexiowaits --collect.perf_schema.tableiowaits --collect.perf_schema.tablelocks --collect.info_schema.tablestats --collect.info_schema.processlist --collect.binlog_size --collect.global_status --collect.global_variables --collect.info_schema.innodb_metrics --collect.slave_status
prometh+  4039  0.1  0.2  17368 11544 ?        Sl   Nov28   1:47  \_ mysqld_exporter --collect.perf_schema.eventswaits --collect.perf_schema.file_events --collect.perf_schema.file_instances --collect.perf_schema.indexiowaits --collect.perf_schema.tableiowaits --collect.perf_schema.tablelocks --collect.info_schema.tablestats --collect.info_schema.processlist --collect.binlog_size --collect.global_status --collect.global_variables --collect.info_schema.innodb_metrics --collect.slave_status

Đối với một nút PostgreSQL,

[[email protected] vagrant]# ps axufww|egrep 'ex[p]'
postgres  1901  0.0  0.4 1169024 8904 ?        Ss   18:00   0:04  \_ postgres: postgres_exporter postgres ::1(51118) idle
prometh+  1516  0.0  0.0  10828   360 ?        S    18:00   0:00 daemon --name=process_exporter --output=/var/log/prometheus/process_exporter.log --env=HOME=/var/lib/prometheus --env=PATH=/usr/local/bin:/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin --chdir=/var/lib/prometheus --pidfile=/var/run/prometheus/process_exporter.pid --user=prometheus -- process_exporter
prometh+  1517  0.2  0.7 117032 14636 ?        Sl   18:00   0:35  \_ process_exporter
prometh+  1700  0.0  0.0  10828   572 ?        S    18:00   0:00 daemon --name=node_exporter --output=/var/log/prometheus/node_exporter.log --env=HOME=/var/lib/prometheus --env=PATH=/usr/local/bin:/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin --chdir=/var/lib/prometheus --pidfile=/var/run/prometheus/node_exporter.pid --user=prometheus -- node_exporter
prometh+  1701  0.0  0.7  44380 14932 ?        Sl   18:00   0:10  \_ node_exporter
prometh+  1897  0.0  0.0  10828   568 ?        S    18:00   0:00 daemon --name=postgres_exporter --output=/var/log/prometheus/postgres_exporter.log --env=HOME=/var/lib/prometheus --env=PATH=/usr/local/bin:/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin --env=DATA_SOURCE_NAME=postgresql://postgres_exporter:[email protected]:5432/postgres?sslmode=disable --chdir=/var/lib/prometheus --pidfile=/var/run/prometheus/postgres_exporter.pid --user=prometheus -- postgres_exporter
prometh+  1898  0.0  0.5  16548 11204 ?        Sl   18:00   0:06  \_ postgres_exporter

Nó có các trình xuất giống như đối với nút MySQL, nhưng chỉ khác ở postgres_exporter vì đây là nút cơ sở dữ liệu PostgreSQL.

Tuy nhiên, khi một nút bị gián đoạn nguồn, sự cố hệ thống hoặc hệ thống khởi động lại, các trình xuất này sẽ ngừng chạy. Prometheus sẽ báo cáo rằng một nhà xuất khẩu đang giảm giá. ClusterControl lấy mẫu Prometheus và yêu cầu các trạng thái của nhà xuất khẩu. Vì vậy, nó hoạt động dựa trên thông tin này và sẽ khởi động lại nhà xuất khẩu nếu nó không hoạt động.

Tuy nhiên, lưu ý rằng đối với các trình xuất chưa được cài đặt qua ClusterControl, chúng sẽ không được khởi động lại sau sự cố. Lý do là chúng không được giám sát bởi systemd hoặc một daemon hoạt động như một tập lệnh an toàn có thể khởi động lại quá trình khi gặp sự cố hoặc tắt máy bất thường. Do đó, ảnh chụp màn hình bên dưới sẽ cho biết giao diện của nó như thế nào khi các nhà xuất không chạy. Xem bên dưới:

và trong Bảng điều khiển PostgreSQL, sẽ có cùng một biểu tượng tải với nhãn "Không có điểm dữ liệu" trong biểu đồ. Xem bên dưới:

Do đó, chúng có thể được khắc phục sự cố thông qua các kỹ thuật khác nhau sẽ theo dõi trong các phần sau.

Khắc phục sự cố với Prometheus

Các đại lý Prometheus, được gọi là nhà xuất khẩu, đang sử dụng các cổng sau:9100 (node_exporter), 9011 (process_exporter), 9187 (postgres_exporter), 9104 (mysqld_exporter), 42004 (proxysql_exporter) và 9090 rất riêng do một prometheus sở hữu tiến trình. Đây là các cổng cho các tác nhân này được ClusterControl sử dụng.

Để bắt đầu khắc phục sự cố Bảng điều khiển SCUMM, bạn có thể bắt đầu bằng cách kiểm tra các cổng mở từ nút cơ sở dữ liệu. Bạn có thể theo dõi các danh sách dưới đây:

  • Kiểm tra xem các cổng có mở không

    ví dụ:

    ## Use netstat and check the ports
    [[email protected] vagrant]# netstat -tnvlp46|egrep 'ex[p]'
    tcp6       0      0 :::9100                 :::*                    LISTEN      5036/node_exporter  
    tcp6       0      0 :::9011                 :::*                    LISTEN      4852/process_export 
    tcp6       0      0 :::9187                 :::*                    LISTEN      5230/postgres_expor 

    Có thể có khả năng các cổng không mở do tường lửa (chẳng hạn như iptables hoặc firewalld) chặn nó mở cổng hoặc bản thân trình nền tiến trình không chạy.

  • Sử dụng curl từ màn hình máy chủ và xác minh xem cổng có thể truy cập và mở được không.

    ví dụ:

    ## Using curl and grep mysql list of available metric names used in PromQL.
    [[email protected] prometheus]# curl -sv mariadb_g01:9104/metrics|grep 'mysql'|head -25
    * About to connect() to mariadb_g01 port 9104 (#0)
    *   Trying 192.168.10.10...
    * Connected to mariadb_g01 (192.168.10.10) port 9104 (#0)
    > GET /metrics HTTP/1.1
    > User-Agent: curl/7.29.0
    > Host: mariadb_g01:9104
    > Accept: */*
    > 
    < HTTP/1.1 200 OK
    < Content-Length: 213633
    < Content-Type: text/plain; version=0.0.4; charset=utf-8
    < Date: Sat, 01 Dec 2018 04:23:21 GMT
    < 
    { [data not shown]
    # HELP mysql_binlog_file_number The last binlog file number.
    # TYPE mysql_binlog_file_number gauge
    mysql_binlog_file_number 114
    # HELP mysql_binlog_files Number of registered binlog files.
    # TYPE mysql_binlog_files gauge
    mysql_binlog_files 26
    # HELP mysql_binlog_size_bytes Combined size of all registered binlog files.
    # TYPE mysql_binlog_size_bytes gauge
    mysql_binlog_size_bytes 8.233181e+06
    # HELP mysql_exporter_collector_duration_seconds Collector time duration.
    # TYPE mysql_exporter_collector_duration_seconds gauge
    mysql_exporter_collector_duration_seconds{collector="collect.binlog_size"} 0.008825006
    mysql_exporter_collector_duration_seconds{collector="collect.global_status"} 0.006489491
    mysql_exporter_collector_duration_seconds{collector="collect.global_variables"} 0.00324821
    mysql_exporter_collector_duration_seconds{collector="collect.info_schema.innodb_metrics"} 0.008209824
    mysql_exporter_collector_duration_seconds{collector="collect.info_schema.processlist"} 0.007524068
    mysql_exporter_collector_duration_seconds{collector="collect.info_schema.tables"} 0.010236411
    mysql_exporter_collector_duration_seconds{collector="collect.info_schema.tablestats"} 0.000610684
    mysql_exporter_collector_duration_seconds{collector="collect.perf_schema.eventswaits"} 0.009132491
    mysql_exporter_collector_duration_seconds{collector="collect.perf_schema.file_events"} 0.009235416
    mysql_exporter_collector_duration_seconds{collector="collect.perf_schema.file_instances"} 0.009451361
    mysql_exporter_collector_duration_seconds{collector="collect.perf_schema.indexiowaits"} 0.009568397
    mysql_exporter_collector_duration_seconds{collector="collect.perf_schema.tableiowaits"} 0.008418406
    mysql_exporter_collector_duration_seconds{collector="collect.perf_schema.tablelocks"} 0.008656682
    mysql_exporter_collector_duration_seconds{collector="collect.slave_status"} 0.009924652
    * Failed writing body (96 != 14480)
    * Closing connection 0

    Lý tưởng nhất, tôi thực tế thấy phương pháp này khả thi đối với tôi vì tôi có thể gửi và gỡ lỗi từ thiết bị đầu cuối một cách dễ dàng.

  • Tại sao không sử dụng giao diện người dùng Web?

    • Prometheus cho thấy cổng 9090 được ClusterControl sử dụng trong Bảng điều khiển SCUMM của chúng tôi. Bên cạnh đó, các cổng mà nhà xuất khẩu đang sử dụng cũng có thể được sử dụng để khắc phục sự cố và xác định các tên chỉ số có sẵn bằng PromQL. Trong máy chủ nơi Prometheus đang chạy, bạn có thể truy cập http:// :9090 / target . Ảnh chụp màn hình bên dưới cho thấy nó đang hoạt động:

      và nhấp vào "Điểm cuối", bạn có thể xác minh các chỉ số cũng như ảnh chụp màn hình bên dưới:

      Thay vì sử dụng địa chỉ IP, bạn cũng có thể kiểm tra địa chỉ này cục bộ thông qua localhost trên nút cụ thể đó chẳng hạn như truy cập http:// localhost:9104 / metrics trong giao diện Web UI hoặc sử dụng cURL.

      Bây giờ, nếu chúng ta quay lại “ Mục tiêu ”, Bạn có thể xem danh sách các nút có thể xảy ra sự cố với cổng. Những lý do có thể gây ra điều này được liệt kê dưới đây:

      • Máy chủ không hoạt động
      • Không thể truy cập mạng hoặc không mở được cổng do tường lửa đang chạy
      • Daemon không chạy ở nơi _exporter không chạy. Ví dụ:mysqld_exporter không chạy.

Khi các trình xuất này đang chạy, bạn có thể kích hoạt và chạy quy trình bằng daemon yêu cầu. Bạn có thể tham khảo các quy trình đang chạy có sẵn mà tôi đã sử dụng trong ví dụ trên hoặc được đề cập trong phần trước của blog này.

Còn những đồ thị “Không có điểm dữ liệu” nào trong Trang tổng quan của tôi?

SCUMM Dashboards đưa ra một tình huống sử dụng chung thường được sử dụng bởi MySQL. Tuy nhiên, có một số biến khi gọi số liệu như vậy có thể không khả dụng trong một phiên bản MySQL cụ thể hoặc một nhà cung cấp MySQL, chẳng hạn như MariaDB hoặc Máy chủ Percona.

Hãy để tôi đưa ra một ví dụ dưới đây:

Biểu đồ này được lấy trên máy chủ cơ sở dữ liệu chạy trên Máy chủ MariaDB phiên bản 10.3.9-MariaDB-log với wsrep_patch_version của phiên bản wsrep_25.23. Bây giờ câu hỏi là, tại sao không có bất kỳ điểm dữ liệu nào đang tải? Chà, khi tôi truy vấn nút về trạng thái tuổi của điểm kiểm tra, nó cho thấy nút trống hoặc không tìm thấy biến. Xem bên dưới:

MariaDB [(none)]> show global status like 'Innodb_checkpoint_max_age';
Empty set (0.000 sec)

Tôi không biết tại sao MariaDB không có biến này (vui lòng cho chúng tôi biết trong phần nhận xét của blog này nếu bạn có câu trả lời). Điều này trái ngược với Máy chủ cụm Percona XtraDB có biến Innodb_checkpoint_max_age tồn tại. Xem bên dưới:

mysql> show global status like 'Innodb_checkpoint_max_age';
+---------------------------+-----------+
| Variable_name             | Value     |
+---------------------------+-----------+
| Innodb_checkpoint_max_age | 865244898 |
+---------------------------+-----------+
1 row in set (0.00 sec)

Mặc dù vậy, điều này có nghĩa là gì, có thể có các biểu đồ không có các điểm dữ liệu được thu thập bởi vì nó không có dữ liệu nào được thu thập trên số liệu cụ thể đó khi truy vấn Prometheus được thực thi.

Tuy nhiên, một biểu đồ không có điểm dữ liệu không có nghĩa là phiên bản MySQL hiện tại của bạn hoặc biến thể của nó không hỗ trợ nó. Ví dụ:có một số biểu đồ yêu cầu một số biến nhất định cần được thiết lập đúng cách hoặc được bật.

Phần sau đây sẽ cho thấy những biểu đồ này là gì.

Biểu đồ kéo xuống điều kiện chỉ mục (ICP)

Biểu đồ này đã được đề cập trong blog trước đây của tôi. Nó dựa trên một biến toàn cục MySQL có tên là innodb_monitor_enable. Biến này là biến động nên bạn có thể đặt biến này mà không cần khởi động lại cơ sở dữ liệu MySQL của mình. Nó cũng yêu cầu innodb_monitor_enable =module_icp hoặc bạn có thể đặt biến toàn cục này thành innodb_monitor_enable =all. Thông thường, để tránh những trường hợp như vậy và nhầm lẫn về lý do tại sao biểu đồ đó không hiển thị bất kỳ điểm dữ liệu nào, bạn có thể phải sử dụng tất cả, trừ trường hợp cẩn thận. Có thể có một số chi phí nhất định khi biến này được bật và đặt thành tất cả.

Biểu đồ hiệu suất MySQL

Vậy tại sao những biểu đồ này lại hiển thị "Không có điểm dữ liệu"? Khi bạn tạo một cụm bằng ClusterControl bằng cách sử dụng các mẫu của chúng tôi, theo mặc định, nó sẽ xác định các biến performance_schema. Ví dụ:các biến dưới đây được đặt:

performance_schema = ON
performance-schema-max-mutex-classes = 0
performance-schema-max-mutex-instances = 0

Tuy nhiên, nếu performance_schema =OFF thì đó là lý do tại sao các biểu đồ liên quan sẽ hiển thị "Không có điểm dữ liệu".

Nhưng tôi đã bật performance_schema, tại sao các biểu đồ khác vẫn là một vấn đề?

Vâng, vẫn có những đồ thị yêu cầu nhiều biến số cần được thiết lập. Điều này đã được đề cập trong blog trước của chúng tôi. Do đó, bạn cần đặt innodb_monitor_enable =all và userstat =1. Kết quả sẽ như thế này:

Tuy nhiên, tôi nhận thấy rằng trong phiên bản MariaDB 10.3 (đặc biệt là 10.3.11), việc đặt performance_schema =ON sẽ điền các chỉ số cần thiết cho MySQL Performance Schema Dashboard. Đây là một lợi thế lớn vì nó không phải đặt innodb_monitor_enable =ON, điều này sẽ làm tăng thêm chi phí trên máy chủ cơ sở dữ liệu.

Khắc phục sự cố nâng cao

Có cách khắc phục sự cố trước nào mà tôi có thể giới thiệu không? Có, có! Tuy nhiên, ít nhất bạn cũng cần một số kỹ năng JavaScript. Vì Trang tổng quan SCUMM sử dụng Prometheus dựa trên biểu đồ cao, cách các số liệu đang được sử dụng cho các yêu cầu PromQL có thể được xác định thông qua tập lệnh app.js được hiển thị bên dưới:

Vì vậy, trong trường hợp này, tôi đang sử dụng Công cụ dành cho nhà phát triển của Google Chrome và cố gắng tìm kiếm Chờ giản đồ hiệu suất (Sự kiện) . Làm thế nào điều này có thể giúp đỡ? Chà, nếu bạn nhìn vào các mục tiêu, bạn sẽ thấy:

targets: [{
expr: 'topk(5, rate(mysql_perf_schema_events_waits_total{instance="$instance"}[$interval])>0) or topk(5, irate(mysql_perf_schema_events_waits_total{instance="$instance"}[5m])>0)',
legendFormat: "{{event_name}} "
}]

Bây giờ, bạn có thể sử dụng số liệu được yêu cầu là mysql_perf_schema_events_waits_total. Ví dụ:bạn có thể kiểm tra điều đó bằng cách xem qua http:// :9090 / graph và kiểm tra xem đã có số liệu nào được thu thập chưa. Xem bên dưới:

ClusterControl Auto-Recovery để giải cứu!

Cuối cùng, câu hỏi chính là, có cách nào dễ dàng để khởi động lại các nhà xuất bị lỗi không? Đúng! Chúng tôi đã đề cập trước đó rằng ClusterControl xem trạng thái xuất và khởi động lại chúng nếu được yêu cầu. Trong trường hợp bạn nhận thấy rằng Bảng điều khiển SCUMM không tải đồ thị bình thường, hãy đảm bảo rằng bạn đã bật Tự động khôi phục. Xem hình ảnh bên dưới:

Khi điều này được bật, điều này sẽ đảm bảo rằng _exporters sẽ được khởi động chính xác nếu nó phát hiện ra rằng những thứ này không chạy. ClusterControl sẽ giải quyết việc đó cho bạn và bạn không cần thực hiện thêm hành động nào.

Cũng có thể cài đặt lại hoặc định cấu hình lại trình xuất.

Kết luận

Trong blog này, chúng tôi đã xem cách ClusterControl sử dụng Prometheus để cung cấp Trang tổng quan SCUMM. Nó cung cấp một bộ tính năng mạnh mẽ, từ dữ liệu giám sát độ phân giải cao và đồ thị phong phú. Bạn đã biết rằng với PromQL, bạn có thể xác định và khắc phục sự cố Trang tổng quan SCUMM của chúng tôi, cho phép bạn tổng hợp dữ liệu chuỗi thời gian trong thời gian thực. Bạn cũng có thể tạo đồ thị hoặc xem qua Bảng điều khiển để biết tất cả các chỉ số đã được thu thập.

Bạn cũng đã học cách gỡ lỗi Trang tổng quan SCUMM của chúng tôi, đặc biệt khi không có điểm dữ liệu nào được thu thập.

Nếu bạn có thắc mắc, vui lòng thêm vào nhận xét của bạn hoặc cho chúng tôi biết thông qua Diễn đàn cộng đồng của chúng tôi.


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. 3 cách để tìm vị trí của một chuỗi con trong một chuỗi trong MySQL

  2. Cú pháp CƠ SỞ DỮ LIỆU SQL DROP - Được DBMS liệt kê

  3. Lỗi:Không gian bảng cho bảng xxx tồn tại. Vui lòng XÓA không gian bảng trước khi NHẬP

  4. Sử dụng strtotime cho các ngày trước năm 1970

  5. MySQLSyntaxErrorException gần? khi cố gắng thực thi PreparedStatement