Ubuntu上的ibdata1文件去哪里了?

在Ubuntu桌面版上使用apt安装MySQL之后,无论使用find还是locate都找不到MySQL的重要文件ibdata1。解决问题的方法很简单,就是切换到root账号之下。

$ locate ibdata1 
$ 
$ su
# locate ibdata1
# /var/lib/mysql/ibdata1

MySQL的数据文件位置

root@TC8304:/var/lib/mysql# ls
auto.cnf         ibdata1      ibtmp1              phpmyadmin  TC8304-slow.log
debian-5.7.flag  ib_logfile0  mysql               sujx
ib_buffer_pool   ib_logfile1  performance_schema  sys

MySQL的性能测试

常用性能测试工具

  • sysbench
  • tpcc-mysql
  • mysqlslap

性能衡量指标

  • 服务吞吐量(TPS\QPS)
    tps是每秒内的事务数,比如执行了dml操作,那么相应的tps会增加;
    qps是指每秒内查询次数,比如执行了select操作,相应的qps会增加。
  • 服务响应时间
  • 服务的并发性

sysbench

  • 业界知名
  • 支持磁盘、cpu和数据库
  • 支持多种数据库

测试准备

$ sysbench --test=oltp --oltp-table-size=1000000 --mysql-host=127.0.0.1 --mysql-user=sujx --mysql-db=sujx --mysql-password=****  prepare

执行测试

$ sysbench --num-threads=16 --max-requests=100000  --test=oltp --oltp-table-size=1000000 --oltp-read-only --mysql-host=127.0.0.1 --mysql-user=sujx --mysql-db=sujx --mysql-password=**** run

测试结果

No DB drivers specified, using mysql
Running the test with following options:
Number of threads: 16

Doing OLTP test.
Running mixed OLTP test
Doing read-only test
Using Special distribution (12 iterations,  1 pct of values are returned in 75 pct cases)
Using "BEGIN" for starting transactions
Using auto_inc on the id column
Maximum number of requests for OLTP test is limited to 100000
Threads started!
Done.

OLTP test statistics:
    queries performed:
        read:                            1400028
        write:                           0
        other:                           200004
        total:                           1600032
    transactions:                        100002 (1936.18 per sec.)
    deadlocks:                           0      (0.00 per sec.)
    read/write requests:                 1400028 (27106.57 per sec.)
    other operations:                    200004 (3872.37 per sec.)

Test execution summary:
    total time:                          51.6490s
    total number of events:              100002
    total time taken by event execution: 825.9599
    per-request statistics:
         min:                                  2.09ms
         avg:                                  8.26ms
         max:                                 20.08ms
         approx.  95 percentile:              11.48ms

Threads fairness:
    events (avg/stddev):           6250.1250/10.94
    execution time (avg/stddev):   51.6225/0.00

Tpcc-mysql

  1. Ubuntu下执行安装
$ sudo apt install -y git mysql-server libmysqlclient-dev  
$ git clone https://github.com/Percona-Lab/tpcc-mysql.git
$ cd tpcc-mysql/src
$ make 
$ export LD_LIBRARY_PATH=$MYSQL_HOME/lib
export C_INCLUDE_PATH=$MYSQL_HOME/include
export PATH=$MYSQL_HOME/bin:$PATH
mysql>create database tpcc;
mysql>source create_table.sql
mysql>source add_fkey_idx.sql
$ ./tpcc_load 127.0.0.1 sujx sujx ***** 5
./tpcc_start -h 127.0.0.1 -d sujx -u sujx -p ***** -w 5 -c 16 -r 1 -l 10 -i 1 -f report-mysql-tpcc.txt

输出结果

STOPPING THREADS................

<Raw Results>
  [0] sc:3243  lt:0  rt:0  fl:0 
  [1] sc:3235  lt:0  rt:0  fl:0 
  [2] sc:325  lt:0  rt:0  fl:0 
  [3] sc:323  lt:0  rt:0  fl:0 
  [4] sc:325  lt:0  rt:0  fl:0 
 in 10 sec.

<Raw Results2(sum ver.)>
  [0] sc:3243  lt:0  rt:0  fl:0 
  [1] sc:3242  lt:0  rt:0  fl:0 
  [2] sc:325  lt:0  rt:0  fl:0 
  [3] sc:323  lt:0  rt:0  fl:0 
  [4] sc:325  lt:0  rt:0  fl:0 

<Constraint Check> (all must be [OK])
 [transaction percentage]
        Payment: 43.42% (>=43.0%) [OK]
   Order-Status: 4.36% (>= 4.0%) [OK]
       Delivery: 4.33% (>= 4.0%) [OK]
    Stock-Level: 4.36% (>= 4.0%) [OK]
 [response time (at least 90% passed)]
      New-Order: 100.00%  [OK]
        Payment: 100.00%  [OK]
   Order-Status: 100.00%  [OK]
       Delivery: 100.00%  [OK]
    Stock-Level: 100.00%  [OK]

<TpmC>                 19458.000 TpmC

总结

  • IO测试要远大于内存、CPU测试要小于内存;
  • 测试时间应当大于60分钟;
  • sysbench倾向于测试MySQL性能,TPCC更接近业务;
  • 运行测试程序需要同时监控机器负载、MySQL各项监控指标

tips:
- tpcc的详细介绍和使用tpcc
- Sysbench的介绍和具体使用sysbench

MySQL的恢复

什么时候需要恢复数据

  • 硬件故障(如磁盘损坏、raid丢失)
  • 人为删除(如误删数据、黑客入侵)
  • 业务回滚(如游戏bug需要回滚)
  • 正常需求(部署镜像库、查看历史某时刻数据)

恢复条件

  • 有效备份
  • 完整日志
  • row格式的binlog(反转SQL)

恢复工具与命令

  • source
  • innodbackupex
  • mysql

案例

恢复某几条误删数据
恢复误删除表、库
将数据库恢复到指定时间点

MySQL示例数据库

MySQL数据库实际上提供了试验用的数据库,类似于MS SQLServer的Advancedworks示例数据库。

tips:数据库文件比较大,下载会比较慢。

#获取
git clone https://github.com/datacharmer/test_db.git
cd test_db
mysql -usujx -p
#导入数据库
mysql> source employees.sql
#数据校验
mysql> source test_employees_md5.sql;
mysql> source test_employees_sha.sql;
#提示OK之后就可以使用了
mysql> select * from departments;e
+---------+--------------------+
| dept_no | dept_name          |
+---------+--------------------+
| d009    | Customer Service   |
| d005    | Development        |
| d002    | Finance            |
| d003    | Human Resources    |
| d001    | Marketing          |
| d004    | Production         |
| d006    | Quality Management |
| d008    | Research           |
| d007    | Sales              |
+---------+--------------------+
9 rows in set (0.00 sec)

mysql> select * from employees order by birth_date desc limit 1,1;
+--------+------------+------------+-----------+--------+------------+
| emp_no | birth_date | first_name | last_name | gender | hire_date  |
+--------+------------+------------+-----------+--------+------------+
|  11157 | 1965-02-01 | Mario      | Cochrane  | M      | 1985-03-30 |
+--------+------------+------------+-----------+--------+------------+
1 row in set (0.25 sec)
mysql> select count(*) from employees;
+----------+
| count(*) |
+----------+
|   300024 |
+----------+
1 row in set (0.11 sec)