MySQL備份和備份
備份/還原
- 冷備：需要停止當前正在運行mysqld,然后直接拷貝或打包數據文件。
- 半熱備：mysqldump＋binlog －－適合數據量比較小的應用
- 在線熱備：AB復制 －－實時備份
第一種冷備（物理備份）
-
停掉mysql服務器
-
拷貝數據
cd /data tar cjvf /tmp/mysql_bak.tar.bz2 ./ -
測試還原（只需要把原來備份的文件拷貝回來即可）。
第二種邏輯備份mysqldump
mysqld必須是運行着，不需要停掉mysql服務,但需要鎖表。 邏輯備份＝表結構＋數據（插入）
mysqldump：
-
備份一張表或多張表
-
備份一個或多個庫
-
備份所有的庫
Usage: mysqldump [OPTIONS] database [tables] OR mysqldump [OPTIONS] --databases [OPTIONS] DB1 [DB2 DB3...] OR mysqldump [OPTIONS] --all-databases [OPTIONS]
# mysqldump -uroot -p456 test t1 t2> /tmp/t1.sql --備份單個或多個表
# mysql -uroot -p123 test < /var/tmp/test_t1.sql 還原test庫的t1,t2表
# mysqldump -uroot -p456 --databases test test1 test2 > /tmp/test.sql --備份多個庫
# mysqldump -uroot -p456 --all-databases > /tmp/all.sql --備份所有庫
還原:
還原一個表:
mysql> use test;
mysql> drop table t1;
# mysql -uroot -p456 test < /tmp/t1.sql
# mysql -uroot -p456 -e "use test; show tables;"
+----------------+
| Tables_in_test |
+----------------+
| imptest |
| t1 |
+----------------+
還原一個庫:
mysql> drop database test;
# mysql -uroot -p456 -e "create database test;"
# mysql -uroot -p456 test < /tmp/test.sql
# mysql -uroot -p456 -e "show databases;"
+--------------------+
| Database |
+--------------------+
| information_schema |
| mysql |
| test |
## +--------------------+
mysqldump --在線備份，需要鎖表，效率低。只能備份某個時刻數據狀態.
# mysqldump -uroot -p147258369 DB > /tmp/DB.sql --單庫
# mysqldump -uroot -p147258369 DB t1 > /tmp/DB.t1.sql --單表
# mysqldump -uroot -p147258369 --all-databases > /tmp/all.sql --全庫
恢復:
# mysql -uroot -p123 < /tmp/all.sql
第三種增量數據：
binlog --記錄着mysql服務器增刪改的操作記錄. mysqlbinlog --start-datetime=name 開始的時間 --stop-datetime=name 結束的時間 --start-position=# 開始的位置(POS) --stop-position=# 結束的位置
mysql> flush logs;
# mysqlbinlog --start-position=190 --stop-position=833 mysqld.000001
# mysqlbinlog --start-position=1554 --stop-datetime="2011-09-02 11:48:10" mysqld.000001
## 106-280
備份方案1： 完全備份(mysqldump)+增量備份(binlog)
- 數據總量不大，一般在幾百M的數據可以使用這種方法
- 如果數據量大太，每次備份鎖表的時間會比較長，這樣就可能影響上層應用正常使用.
備份：
# mysqldump -uroot -p147258369 --flush-logs --master-data=2 --all-databases > /tmp/all2.sql
--flush-logs --備份時先內存中日志寫入回磁盤，然后截斷日志,並產生新的日志文件
--master-data=2 --進行全庫鎖表，並記錄當前all2.sql,對應的binlog文件名叫什么
查看完整備份文件中的字段
# vim /tmp/all2.sql
-- CHANGE MASTER TO MASTER_LOG_FILE='mysqld.000002', MASTER_LOG_POS=106;
還原
# mysql -uroot -p147258369 < /tmp/all2.sql
# mysqlbinlog --start-position=106 --stop-datetime="2011-09-02 14:00:20" mysqld.000002 | mysql -uroot -p147258369
使用腳本備份:
# vim mysql_backup.sh
#!/bin/bash
name=`date +%Y%m%d-%T`
/usr/bin/mysqldump -uroot -p147258369 --flush-logs --master-data=2 --all-databases > /tmp/$name.sql
crontab -e 設置第天5點鍾做備份
00 05 * * * /bin/sh /var/ftp/notes/scripts/mysql_backup.sh &> /dev/null
AB復制 --主從復制,可以實現在線備份.
-
mysql 復制介紹 將某一台主機上的 Mysql 數據復制到其它主機(slaves)上，並重新執行一遍從而實現當前主機上的 mysql數據與(master)主機上數據保持一致的過程我們可以稱為復制。復制過程中一個服務器充當主服務器，而一個或多個其它服務器充當從服務器。主服務器將更新寫入二進制日志文件，並維護文件的一個索引以跟蹤日志循環。這些日志可以記錄發送到從服務器的更新。當一個從服務器連接主服務器時，它通知主服務器從服務器在日志中讀取的最后一次成功更新的位置。從服務器接收從那時起發生的任何更新，然后封鎖並等待主服務器通知新的更新。
-
mysql復制能解決什么問題
- 數據的分布(data Distribution)
- 負載均衡| mysql 讀寫分離
- 可以實現數據的備份，但是不能當真正意義上數據備份來用
- 高可用性和容錯性(比如雙主模式中的互為主從能實現高可用)
-
mysql主從復制原理
-
步驟
- 在Master服務器將改變的數據記錄到二進制日志(binary log)中(這些記錄叫做二進制日志事件)
- Slave 服務器將 Master 服務器上的二進制日志拷貝到自己的中繼日志(relay-log)中
- Slave 服務器讀取中繼日志中的事件，然后將改變的數據寫入到自己的數據庫中
-
流程
- 第一步：是在 Master 服務器上記錄二進制日志。在每個更新數據的事務完成之前，Master 服務器都會將數據更改記錄到二進制日志中。即使事務在執行期間是交錯的，Mysql 也會串行地將事務寫入到二進制日志中。在把事件寫入二進制日志之后，Master 服務器告訴存儲引擎可以提交事務了
- 第二步：是 Slave 服務器把主服務器的二進制日志拷貝到自己的硬盤上，進入所謂的“中繼日志”中。首先，它啟動一個工作線程，叫 I/O 線程，這個 I/O 線程開啟一個普通的客戶端連接，然后啟動一個特殊的二進制日志轉儲進程（它沒有相應的 SQL 命令）。這個轉儲進程 Master 服務器的二進制日志中讀取數據。它不會對事件進行輪詢。如果 3 跟上了 Master 服務器，就會進入休眠狀態並等待有新的事件發生時 Master 服務器發出的信號。I/O 線程把數據寫入 Slave 服務器的中繼日志中
- 第三步： 107 SQL 線程讀取中繼日志，並且重放其中的事件，然后更新 Slave 服務器的數據。由於這個線程能跟上 I/O 線程，中繼日志通常在操作系統的緩存中，所以中繼日志的開銷很低。SQL 線程執行事件也可以被寫入 Slave服務器自己的二進制日志中，它對於有些場景很實用上圖中顯示了在 Slave 服務器有兩個運行的線程，在 Master服務器上也有一個運行的線程：和其他普通連接一樣，由 Slave 服務器發起的連接，在 Master 服務器上同樣擁有一個線程。
master-->slave1--slave2
-6->slave3
master(binlog)-->slave
192.168.0.123 192.168.0.254
1、主從機器使用的mysql版本最好一致。 2、在主服務器上必須啟用二進制日志，並且server-id的取值要大於從服務器。 3、在主服務器上新建一個用於同步binlog的賬號。 4、在主服務器上導出原始數據到從服務器上。 5、在從服務器上指定主服務器，指定賬號、binlog名稱、binlog的起始位置(偏移量)。
常用的命令:
start slave
stop slave
STOP SLAVE IO_THREAD ;
STOP SLAVE SQL_THREAD;
-->
Slave_IO_Running: Yes
Slave_SQL_Running: No
在從服務器上啟用binlog:
vim /etc/my.cnf
log-slave-updates
log-bin
鏈式復制 A -> B -> C 也就是說，A為從服務器B的主服務器，B為從服務器C的主服務器。為了能工作，B必須既為主服務器又為從服務器。你必須用--logs-bin啟動A和B以啟用二進制日志，並且用--logs-slave-updates選項啟動B。
C將B當成主服務器來操作
延遲復制（只開IO線程，關閉SQL線程）
關閉IO_THREAD 或者 SQL_THREAD
僅僅讀的請求。他的數據更新都是根據從主服務器上獲得信息進行更新。它會打開兩個線程：SQL_THREAD, IO_THREAD。
IO_THREAD 負責連接主服務器，把相關更新下載回來
SQL_THREAD 執行下載回來的更新操作。
bin-log日志(數據的還原)
1）使用mysqlbinlog自帶查看命令法：
注意：
-->binlog是二進制文件，普通文件查看器cat、more、vim等都無法打開，必須使用自帶的mysqlbinlog命令查看
-->binlog日志與數據庫文件在同目錄中
-->在MySQL5.5以下版本使用mysqlbinlog命令時如果報錯，就加上 “--no-defaults”選項
[root@vagrant-centos65 mysql]# ps axu |grep mysql
root 1410 0.2 0.2 106088 1488 pts/0 S 07:14 0:00 /bin/sh /usr/bin/mysqld_safe --datadir=/var/lib/mysql --socket=/var/lib/mysql/mysql.sock --pid-file=/var/run/mysqld/mysqld.pid --basedir=/usr --user=mysql
mysql 1518 3.7 3.2 396240 19816 pts/0 Sl 07:14 0:00 /usr/libexec/mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --log-error=/var/log/mysqld.log --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/lib/mysql/mysql.sock
找到 --datadir這個參數后面的目錄就是mysql的數據目錄 可以找到bin-log日志
查看bin-log日志的方法
mysqlbinlog mysql-bin.000001
[root@vagrant-centos65 mysql]# mysqlbinlog mysql-bin.000001
/*!40019 SET @@session.max_insert_delayed_threads=0*/;
/*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/;
DELIMITER /*!*/;
# at 4
#170619 7:21:27 server id 1 end_log_pos 106 Start: binlog v 4, server v 5.1.73-log created 170619 7:21:27 at startup
# Warning: this binlog is either in use or was not closed properly.
ROLLBACK/*!*/;
BINLOG '
d3tHWQ8BAAAAZgAAAGoAAAABAAQANS4xLjczLWxvZwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAB3e0dZEzgNAAgAEgAEBAQEEgAAUwAEGggAAAAICAgC
'/*!*/;
# at 106
#170619 7:38:00 server id 1 end_log_pos 244 Query thread_id=3 exec_time=0 error_code=0
SET TIMESTAMP=1497857880/*!*/;
SET @@session.pseudo_thread_id=3/*!*/;
SET @@session.foreign_key_checks=1, @@session.sql_auto_is_null=1, @@session.unique_checks=1, @@session.autocommit=1/*!*/;
SET @@session.sql_mode=0/*!*/;
SET @@session.auto_increment_increment=1, @@session.auto_increment_offset=1/*!*/;
/*!\C latin1 *//*!*/;
SET @@session.character_set_client=8,@@session.collation_connection=8,@@session.collation_server=8/*!*/;
SET @@session.lc_time_names=0/*!*/;
SET @@session.collation_database=DEFAULT/*!*/;
SET PASSWORD FOR 'root'@'localhost'='*22DF0FE262826C66C3A1E8BC8DC2AF2259B42F46'
解釋 server id 1 ： 數據庫主機的服務號； end_log_pos 796： sql結束時的pos節點 thread_id=11： 線程號
方法2 上面這種辦法讀取出binlog日志的全文內容比較多，不容易分辨查看到pos點信息 下面介紹一種更為方便的查詢命令： 命令格式：
mysql> show binlog events [IN 'log_name'] [FROM pos] [LIMIT [offset,] row_count];
參數解釋：
IN 'log_name' ：指定要查詢的binlog文件名(不指定就是第一個binlog文件)
FROM pos ：指定從哪個pos起始點開始查起(不指定就是從整個文件首個pos點開始算)
LIMIT [offset,] ：偏移量(不指定就是0)
row_count ：查詢總條數(不指定就是所有行)
mysql> show master logs;
+------------------+-----------+
| Log_name | File_size |
+------------------+-----------+
| mysql-bin.000001 | 695 |
| mysql-bin.000002 | 106 |
+------------------+-----------+
舉例
mysql> show binlog events in 'mysql-bin.000001'\G;
*************************** 1. row ***************************
Log_name: mysql-bin.000001
Pos: 4
Event_type: Format_desc
Server_id: 1
End_log_pos: 106
Info: Server ver: 5.1.73-log, Binlog ver: 4
*************************** 2. row ***************************
Log_name: mysql-bin.000001
Pos: 106
Event_type: Query
Server_id: 1
End_log_pos: 244
Info: SET PASSWORD FOR 'root'@'localhost'='*22DF0FE262826C66C3A1E8BC8DC2AF2259B42F46'
*************************** 3. row ***************************
Log_name: mysql-bin.000001
Pos: 244
Event_type: Query
Server_id: 1
End_log_pos: 359
Info: CREATE USER 'slave'@'172.16.147.%' IDENTIFIED BY 'slave'
*************************** 4. row ***************************
Log_name: mysql-bin.000001
Pos: 359
Event_type: Query
Server_id: 1
End_log_pos: 510
Info: GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'slave'@'172.16.147.%'
*************************** 5. row ***************************
Log_name: mysql-bin.000001
Pos: 510
Event_type: Query
Server_id: 1
End_log_pos: 585
Info: flush privileges
*************************** 6. row ***************************
Log_name: mysql-bin.000001
Pos: 585
Event_type: Query
Server_id: 1
End_log_pos: 695
Info: create database tanzhouawen charset utf8
6 rows in set (0.00 sec)
補充
上面這條語句可以將指定的binlog日志文件，分成有效事件行的方式返回，並可使用limit指定pos點的起始偏移，查詢條數！
如下操作示例：
a）查詢第一個(最早)的binlog日志：
mysql> show binlog events\G;
b）指定查詢 mysql-bin.000002這個文件：
mysql> show binlog events in 'mysql-bin.000002'\G;
c）指定查詢 mysql-bin.000002這個文件，從pos點:624開始查起：
mysql> show binlog events in 'mysql-bin.000002' from 624\G;
d）指定查詢 mysql-bin.000002這個文件，從pos點:624開始查起，查詢10條（即10條語句）
mysql> show binlog events in 'mysql-bin.000002' from 624 limit 10\G;
e）指定查詢 mysql-bin.000002這個文件，從pos點:624開始查起，偏移2行（即中間跳過2個），查詢10條
mysql> show binlog events in 'mysql-bin.000002' from 624 limit 2,10\G;
利用binlog日志恢復mysql數據
場景模擬
- 第一步 wiki庫每天都會備份一次 ``` 0 4 * /usr/bin/mysqldump -uroot -p -B -F -R -x --master-data=2 wiki|gzip >/opt/backup/wiki_$(date +%F).sql.gz 參數說明： -B：指定數據庫 -F：刷新日志 -R：備份存儲過程等 -x：鎖表 --master-data：在備份語句里添加CHANGE MASTER語句以及binlog文件及位置點信息 由於上面在全備份的時候使用了-F選項，那么當數據備份操作剛開始的時候系統就會自動刷新log，這樣就會自動產生 一個新的binlog日志，這個新的binlog日志就會用來記錄備份之后的數據庫“增刪改”操作.
查看一下：
mysql> show master status;
+------------------+----------+--------------+------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
| mysql-bin.000003 | 202 | | |
+------------------+----------+--------------+------------------+
1 row in set (0.00 sec)
也就是說， mysql-bin.000003 是用來記錄4:00之后對數據庫的所有“增刪改”操作。
第二步我們對這個庫進行了各種操作(早上9點) 我們插入一條數據
mysql> insert into wiki_user(`username`,`password`,`email`)values('tanzhouawen','123456','123123@qq.com')
-> ;
Query OK, 1 row affected, 1 warning (0.00 sec)
第三步 下午18:00 悲劇了 我把數據給刪掉了
mysql> drop database wiki;
Query OK, 48 rows affected (0.00 sec)
第四步 這個時候大家一定不要慌張 先仔細查看最后一個binlog 日志 並記錄一下關鍵的pos點 看看是哪一個pos點導致了數據庫的破壞
- 先停掉業務 不能再插入數據庫。如果是java后端 需要把java停掉
- 備份最后一個binlog日志
[root@vagrant-centos65 mysql]# cd /var/lib/mysql/
[root@vagrant-centos65 mysql]# cp mysql-bin.000003 /opt/backup/
[root@vagrant-centos65 mysql]# cp -v mysql-bin.000003 /opt/backup/
cp: overwrite `/opt/backup/mysql-bin.000003'? y
`mysql-bin.000003' -> `/opt/backup/mysql-bin.000003'
[root@vagrant-centos65 mysql]#
執行刷新日志索引的操作 我們重新開始新的binlog日志記錄文件 一般來說bin-log3不會插入數據了的 但是便於我們分析和找節點，以后所有的數據操作都會寫入到下一個日志文件
mysql> flush logs; Query OK, 0 rows affected (0.01 sec)
mysql> show master status;
+------------------+----------+--------------+------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
| mysql-bin.000004 | 106 | | |
+------------------+----------+--------------+------------------+
1 row in set (0.00 sec)
第五步 讀取binlog日志，分析問題
查看binlog日志以及說過了 我們用第二種辦法查看
mysql> show binlog events in 'mysql-bin.000003';
+------------------+-----+-------------+-----------+-------------+----------------------------------------------------------------------------------------------------------------+
| Log_name | Pos | Event_type | Server_id | End_log_pos | Info |
+------------------+-----+-------------+-----------+-------------+----------------------------------------------------------------------------------------------------------------+
| mysql-bin.000003 | 4 | Format_desc | 1 | 106 | Server ver: 5.1.73-log, Binlog ver: 4 |
| mysql-bin.000003 | 106 | Query | 1 | 202 | use `wiki`; DELETE FROM `wiki`.`wiki_session` |
| mysql-bin.000003 | 202 | Intvar | 1 | 230 | INSERT_ID=2 |
| mysql-bin.000003 | 230 | Query | 1 | 391 | use `wiki`; insert into wiki_user(`username`,`password`,`email`)values('tanzhouawen','123456','123123@qq.com') |
| mysql-bin.000003 | 391 | Query | 1 | 472 | drop database wiki |
| mysql-bin.000003 | 472 | Rotate | 1 | 515 | mysql-bin.000004;pos=4 |
+------------------+-----+-------------+-----------+-------------+----------------------------------------------------------------------------------------------------------------+
6 rows in set (0.00 sec)
很明顯可以看到有一個語句drop database wiki
分析得出結果 對數據庫造成影響的pos點在於 230-472之間
第六步 先把凌晨4點全備份的數據恢復
[root@vagrant-centos65 backup]# cd /opt/backup/
[root@vagrant-centos65 backup]# gzip -d wiki_2017-06-21.sql.gz
[root@vagrant-centos65 backup]# mysql -uroot -p'tanzhouawen' -v < wiki_2017-06-21.sql
登錄數據庫 查看數據
[root@vagrant-centos65 backup]# mysql -uroot -p'tanzhouawen' Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is 32 Server version: 5.1.73-log Source distribution
Copyright (c) 2000, 2013, Oracle and/or its affiliates. All rights reserved.
Oracle is a registered trademark of Oracle Corporation and/or its affiliates. Other names may be trademarks of their respective owners.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
mysql> show databases; +--------------------+ | Database | +--------------------+ | information_schema | | mysql | | tanzhouawen | | test | | wiki | +--------------------+ 5 rows in set (0.00 sec)
可以看到wiki這個數據庫已經回來了
但是這緊緊只是恢復了當天凌晨4點之前的數據， 在4:00-18:00的數據還沒有恢復回來
怎么辦
我們可以根據之前的mysql-bin.0000003的新binlog日志進行恢復
第七步 從binlog日志恢復數據
恢復命令的語法格式:
mysqlbinlog mysql-bin.0000xx | mysql -u用戶名 -p密碼 數據庫名
常用參數選項解釋：
--start-position=875 起始pos點
--stop-position=954 結束pos點
--start-datetime="2016-9-25 22:01:08" 起始時間點
--stop-datetime="2019-9-25 22:09:46" 結束時間點
--database=zyyshop 指定只恢復zyyshop數據庫(一台主機上往往有多個數據庫，只限本地log日志)
不常用選項：
-u --user=name 連接到遠程主機的用戶名
-p --password[=name] 連接到遠程主機的密碼
-h --host=name 從遠程主機上獲取binlog日志
--read-from-remote-server 從某個MySQL服務器上讀取binlog日志
小結：實際是將讀出的binlog日志內容，通過管道符傳遞給mysql命令。這些命令、文件盡量寫成絕對路徑；
指定恢復pos結束點恢復 --stop-position=391 pos結束節點（按照事務區間算，是391） 執行命令
/usr/bin/mysqlbinlog --stop-position=391 --database=wiki /var/lib/mysql/mysql-bin.000003 | /usr/bin/mysql -uroot -p'awen' -v wiki
恢復成功
mysql> show binlog events in 'mysql-bin.000003'\G;
*************************** 1. row ***************************
Log_name: mysql-bin.000003
Pos: 4
Event_type: Format_desc
Server_id: 1
End_log_pos: 106
Info: Server ver: 5.1.73-log, Binlog ver: 4
*************************** 2. row ***************************
Log_name: mysql-bin.000003
Pos: 106
Event_type: Query
Server_id: 1
End_log_pos: 202
Info: use `wiki`; DELETE FROM `wiki`.`wiki_session`
*************************** 3. row ***************************
Log_name: mysql-bin.000003
Pos: 202
Event_type: Intvar
Server_id: 1
End_log_pos: 230
Info: INSERT_ID=2
*************************** 4. row ***************************
Log_name: mysql-bin.000003
Pos: 230
Event_type: Query
Server_id: 1
End_log_pos: 391
Info: use `wiki`; insert into wiki_user(`username`,`password`,`email`)values('tanzhouawen','123456','123123@qq.com')
*************************** 5. row ***************************
Log_name: mysql-bin.000003
Pos: 391
Event_type: Query
Server_id: 1
End_log_pos: 472
Info: drop database wiki
*************************** 6. row ***************************
Log_name: mysql-bin.000003
Pos: 472
Event_type: Rotate
Server_id: 1
End_log_pos: 515
Info: mysql-bin.000004;pos=4
6 rows in set (0.00 sec)
如果我只想恢復tanzhouawen這一條數據怎么辦
可以指定需要恢復的區間來寫代碼
更新 name='tanzhouawen' 這條數據，日志區間是Pos[230] --> End_log_pos[391]，按事務區間是：Pos[230] --> End_log_pos[391] 按照事務區間單獨恢復
[root@vagrant-centos65 backup]# /usr/bin/mysqlbinlog --start-position=230 --stop-position=391 --database=wiki /var/lib/mysql/mysql-bin.000003 | /usr/bin/mysql -uroot -p'tanzhouawen' -v wiki
擴展 可以自己去找寫資料完善一下 按時間恢復 擴展2 備份方案 方案1 每天凌晨4:00做一次全備 使用mysqldump
方案2 rsync同步binlog日志到備份的機器 實現備份
擴展3 mysql使用技巧
[root@vagrant-centos65 backup]# mysql --help |grep dummy
-U, --i-am-a-dummy Synonym for option --safe-updates, -U.
i-am-a-dummy FALSE
如果在mysql后面加上-U選項 當發出沒有wherer 或者limit關鍵字的update或DELETE時，mysql程序就會拒絕執行 舉例
[root@vagrant-centos65 backup]# mysql -U -uroot -p'tanzhouawen'
delete from wiki_user;
ERROR 1175 (HY000): You are using safe update mode and you tried to update a table without a WHERE that uses a KEY column
做成別名讓實現 不加條件無法刪除
[root@vagrant-centos65 backup]# alias mysql='mysql -U'
rsync -vzrtopg --progress --delete /var/lib/mysql root@172.16.147.26:/tmp/