gdocrimg04从库无法重启问题
Version: '5.6.25-log' socket: '/tmp/mysqld.3324_gdocrimg04.sock' port: 3324 Source distribution
2019-10-05 23:35:08 1480 [ERROR] InnoDB: Tried to read 16384 bytes at offset 276480000. Was only able to read 8192.
2019-10-05 23:35:08 1480 [ERROR] InnoDB: File (unknown): 'read' returned OS error 0. Cannot continue operation
191005 23:35:09 mysqld_safe Number of processes running now: 0
191005 23:35:09 mysqld_safe mysqld restarted
2019-10-05 23:35:11 0 [Note] /usr/local/mysql/bin/mysqld (mysqld 5.6.25-log) starting as process 7805 ...
2019-10-05 23:35:11 7805 [Warning] Buffered warning: Using unique option prefix max_connection instead of max_connections is deprecated and will be removed in a future release. Please use the full name instead.
2019-10-05 23:35:12 7805 [Note] Plugin 'FEDERATED' is disabled.
2019-10-05 23:35:12 7805 [Note] InnoDB: Using atomics to ref count buffer pool pages
2019-10-05 23:35:12 7805 [Note] InnoDB: The InnoDB memory heap is disabled
2019-10-05 23:35:12 7805 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2019-10-05 23:35:12 7805 [Note] InnoDB: Memory barrier is not used
2019-10-05 23:35:12 7805 [Note] InnoDB: Compressed tables use zlib 1.2.3
2019-10-05 23:35:12 7805 [Note] InnoDB: Using CPU crc32 instructions
2019-10-05 23:35:12 7805 [Note] InnoDB: Initializing buffer pool, size = 2.0G
2019-10-05 23:35:12 7805 [Note] InnoDB: Completed initialization of buffer pool
2019-10-05 23:35:12 7805 [Note] InnoDB: Highest supported file format is Barracuda.
2019-10-05 23:35:12 7805 [Note] InnoDB: Log scan progressed past the checkpoint lsn 224198343218
2019-10-05 23:35:12 7805 [Note] InnoDB: Database was not shutdown normally!
2019-10-05 23:35:12 7805 [Note] InnoDB: Starting crash recovery.
2019-10-05 23:35:12 7805 [Note] InnoDB: Reading tablespace information from the .ibd files...
2019-10-05 23:35:12 7805 [Note] InnoDB: Restoring possible half-written data pages
2019-10-05 23:35:12 7805 [Note] InnoDB: from the doublewrite buffer...
InnoDB: Doing recovery: scanned up to log sequence number 224203586048
InnoDB: Doing recovery: scanned up to log sequence number 224208828928
InnoDB: Doing recovery: scanned up to log sequence number 224214071808
InnoDB: Doing recovery: scanned up to log sequence number 224219314688
InnoDB: Doing recovery: scanned up to log sequence number 224224557568
InnoDB: Doing recovery: scanned up to log sequence number 224229800448
InnoDB: Doing recovery: scanned up to log sequence number 224235043328
InnoDB: Doing recovery: scanned up to log sequence number 224240286208
InnoDB: Doing recovery: scanned up to log sequence number 224245529088
InnoDB: Doing recovery: scanned up to log sequence number 224250771968
InnoDB: Doing recovery: scanned up to log sequence number 224256014848
InnoDB: Doing recovery: scanned up to log sequence number 224261257728
InnoDB: Doing recovery: scanned up to log sequence number 224266500608
InnoDB: Doing recovery: scanned up to log sequence number 224271743488
InnoDB: Doing recovery: scanned up to log sequence number 224276986368
InnoDB: Doing recovery: scanned up to log sequence number 224282229248
InnoDB: Doing recovery: scanned up to log sequence number 224287472128
InnoDB: Doing recovery: scanned up to log sequence number 224292715008
InnoDB: Doing recovery: scanned up to log sequence number 224297957888
InnoDB: Doing recovery: scanned up to log sequence number 224303200768
InnoDB: Doing recovery: scanned up to log sequence number 224308443648
InnoDB: Doing recovery: scanned up to log sequence number 224313686528
InnoDB: Doing recovery: scanned up to log sequence number 224318929408
InnoDB: Doing recovery: scanned up to log sequence number 224324172288
InnoDB: Doing recovery: scanned up to log sequence number 224329415168
InnoDB: Doing recovery: scanned up to log sequence number 224334658048
InnoDB: Doing recovery: scanned up to log sequence number 224339900928
InnoDB: Doing recovery: scanned up to log sequence number 224345143808
InnoDB: Doing recovery: scanned up to log sequence number 224350386688
InnoDB: Doing recovery: scanned up to log sequence number 224355629568
InnoDB: Doing recovery: scanned up to log sequence number 224360872448
InnoDB: Doing recovery: scanned up to log sequence number 224366115328
InnoDB: Doing recovery: scanned up to log sequence number 224371358208
InnoDB: Doing recovery: scanned up to log sequence number 224376601088
InnoDB: Doing recovery: scanned up to log sequence number 224381843968
InnoDB: Doing recovery: scanned up to log sequence number 224387086848
InnoDB: Doing recovery: scanned up to log sequence number 224392329728
InnoDB: Doing recovery: scanned up to log sequence number 224397572608
InnoDB: Doing recovery: scanned up to log sequence number 224402815488
InnoDB: Doing recovery: scanned up to log sequence number 224408058368
InnoDB: Doing recovery: scanned up to log sequence number 224413301248
InnoDB: Doing recovery: scanned up to log sequence number 224418544128
InnoDB: Doing recovery: scanned up to log sequence number 224423787008
InnoDB: Doing recovery: scanned up to log sequence number 224425526540
InnoDB: 1 transaction(s) which must be rolled back or cleaned up
InnoDB: in total 262 row operations to undo
InnoDB: Trx id counter is 416256
2019-10-05 23:35:58 7805 [Note] InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percent: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99
InnoDB: Apply batch completed
InnoDB: Last MySQL binlog file position 0 716953278, file name mysql-bin.000195
InnoDB: Starting in background the rollback of uncommitted transactions
2019-10-05 23:36:48 7805 [Note] InnoDB: 128 rollback segment(s) are active.
2019-10-05 23:36:48 7ff29f6b6700 InnoDB: Rolling back trx with id 415796, 262 rows to undo
2019-10-05 23:36:48 7805 [Note] InnoDB: Waiting for purge to start
2019-10-05 23:36:48 7805 [Note] InnoDB: 5.6.25 started; log sequence number 224425526540
2019-10-05 23:36:48 7805 [Note] Recovering after a crash using /data01/mysql_3324_gdocrimg04/binlog/mysql-bin
2019-10-05 23:36:51 7805 [ERROR] InnoDB: Tried to read 16384 bytes at offset 276480000. Was only able to read 8192.
2019-10-05 23:36:52 7805 [ERROR] InnoDB: File (unknown): 'read' returned OS error 0. Cannot continue operation
191005 23:36:52 mysqld_safe mysqld from pid file /data01/mysql_3324_gdocrimg04/data/mysqld.pid ended
修改/etc/my.3324_gdocrimg04.cnf加
innodb_force_recovery = 1 尝试
innodb_force_recovery = 2
innodb_force_recovery = 3 成功
innodb_force_recovery = 4
innodb_force_recovery = 5
innodb_force_recovery = 6
191008 11:35:32 mysqld_safe Starting mysqld daemon with databases from /data01/mysql_3324_gdocrimg04/data
2019-10-08 11:35:33 0 [Note] /usr/local/mysql/bin/mysqld (mysqld 5.6.25-log) starting as process 20043 ...
2019-10-08 11:35:33 20043 [Warning] Buffered warning: Using unique option prefix max_connection instead of max_connections is deprecated and will be removed in a future release. Please use the full name instead.
2019-10-08 11:35:33 20043 [Note] Plugin 'FEDERATED' is disabled.
2019-10-08 11:35:33 20043 [Note] InnoDB: Using atomics to ref count buffer pool pages
2019-10-08 11:35:33 20043 [Note] InnoDB: The InnoDB memory heap is disabled
2019-10-08 11:35:33 20043 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2019-10-08 11:35:33 20043 [Note] InnoDB: Memory barrier is not used
2019-10-08 11:35:33 20043 [Note] InnoDB: Compressed tables use zlib 1.2.3
2019-10-08 11:35:33 20043 [Note] InnoDB: Using CPU crc32 instructions
2019-10-08 11:35:34 20043 [Note] InnoDB: Initializing buffer pool, size = 2.0G
2019-10-08 11:35:34 20043 [Note] InnoDB: Completed initialization of buffer pool
2019-10-08 11:35:34 20043 [Note] InnoDB: Highest supported file format is Barracuda.
2019-10-08 11:35:34 20043 [Note] InnoDB: Log scan progressed past the checkpoint lsn 224198343218
2019-10-08 11:35:34 20043 [Note] InnoDB: Database was not shutdown normally!
2019-10-08 11:35:34 20043 [Note] InnoDB: Starting crash recovery.
2019-10-08 11:35:34 20043 [Note] InnoDB: Reading tablespace information from the .ibd files...
2019-10-08 11:35:34 20043 [Note] InnoDB: Restoring possible half-written data pages
2019-10-08 11:35:34 20043 [Note] InnoDB: from the doublewrite buffer...
InnoDB: Doing recovery: scanned up to log sequence number 224203586048
InnoDB: Doing recovery: scanned up to log sequence number 224208828928
InnoDB: Doing recovery: scanned up to log sequence number 224214071808
InnoDB: Doing recovery: scanned up to log sequence number 224219314688
InnoDB: Doing recovery: scanned up to log sequence number 224224557568
InnoDB: Doing recovery: scanned up to log sequence number 224229800448
InnoDB: Doing recovery: scanned up to log sequence number 224235043328
InnoDB: Doing recovery: scanned up to log sequence number 224240286208
InnoDB: Doing recovery: scanned up to log sequence number 224245529088
InnoDB: Doing recovery: scanned up to log sequence number 224250771968
InnoDB: Doing recovery: scanned up to log sequence number 224256014848
InnoDB: Doing recovery: scanned up to log sequence number 224261257728
InnoDB: Doing recovery: scanned up to log sequence number 224266500608
InnoDB: Doing recovery: scanned up to log sequence number 224271743488
InnoDB: Doing recovery: scanned up to log sequence number 224276986368
InnoDB: Doing recovery: scanned up to log sequence number 224282229248
InnoDB: Doing recovery: scanned up to log sequence number 224287472128
InnoDB: Doing recovery: scanned up to log sequence number 224292715008
InnoDB: Doing recovery: scanned up to log sequence number 224297957888
InnoDB: Doing recovery: scanned up to log sequence number 224303200768
InnoDB: Doing recovery: scanned up to log sequence number 224308443648
InnoDB: Doing recovery: scanned up to log sequence number 224313686528
InnoDB: Doing recovery: scanned up to log sequence number 224318929408
InnoDB: Doing recovery: scanned up to log sequence number 224324172288
InnoDB: Doing recovery: scanned up to log sequence number 224329415168
InnoDB: Doing recovery: scanned up to log sequence number 224334658048
InnoDB: Doing recovery: scanned up to log sequence number 224339900928
InnoDB: Doing recovery: scanned up to log sequence number 224345143808
InnoDB: Doing recovery: scanned up to log sequence number 224350386688
InnoDB: Doing recovery: scanned up to log sequence number 224355629568
InnoDB: Doing recovery: scanned up to log sequence number 224360872448
InnoDB: Doing recovery: scanned up to log sequence number 224366115328
InnoDB: Doing recovery: scanned up to log sequence number 224371358208
InnoDB: Doing recovery: scanned up to log sequence number 224376601088
InnoDB: Doing recovery: scanned up to log sequence number 224381843968
InnoDB: Doing recovery: scanned up to log sequence number 224387086848
InnoDB: Doing recovery: scanned up to log sequence number 224392329728
InnoDB: Doing recovery: scanned up to log sequence number 224397572608
InnoDB: Doing recovery: scanned up to log sequence number 224402815488
InnoDB: Doing recovery: scanned up to log sequence number 224408058368
InnoDB: Doing recovery: scanned up to log sequence number 224413301248
InnoDB: Doing recovery: scanned up to log sequence number 224418544128
InnoDB: Doing recovery: scanned up to log sequence number 224423787008
InnoDB: Doing recovery: scanned up to log sequence number 224425819327
InnoDB: 1 transaction(s) which must be rolled back or cleaned up
InnoDB: in total 262 row operations to undo
InnoDB: Trx id counter is 418304
2019-10-08 11:35:35 20043 [Note] InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percent: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99
InnoDB: Apply batch completed
InnoDB: Last MySQL binlog file position 0 716953278, file name mysql-bin.000195
2019-10-08 11:35:36 20043 [Note] InnoDB: 128 rollback segment(s) are active.
2019-10-08 11:35:36 20043 [Note] InnoDB: 5.6.25 started; log sequence number 224425819327
2019-10-08 11:35:36 20043 [Note] InnoDB: !!! innodb_force_recovery is set to 3 !!!
2019-10-08 11:35:36 20043 [Note] Recovering after a crash using /data01/mysql_3324_gdocrimg04/binlog/mysql-bin
2019-10-08 11:35:42 20043 [Note] Starting crash recovery...
2019-10-08 11:35:42 20043 [Note] Crash recovery finished.
2019-10-08 11:35:44 20043 [Note] Server hostname (bind-address): '*'; port: 3324
2019-10-08 11:35:44 20043 [Note] IPv6 is available.
2019-10-08 11:35:44 20043 [Note] - '::' resolves to '::';
2019-10-08 11:35:44 20043 [Note] Server socket created on IP: '::'.
2019-10-08 11:35:45 20043 [Warning] 'user' entry 'root@zsyx-pte3033-f12-42' ignored in --skip-name-resolve mode.
2019-10-08 11:35:45 20043 [Warning] 'user' entry '@zsyx-pte3033-f12-42' ignored in --skip-name-resolve mode.
2019-10-08 11:35:45 20043 [Warning] 'proxies_priv' entry '@ root@zsyx-pte3033-f12-42' ignored in --skip-name-resolve mode.
2019-10-08 11:35:46 20043 [Warning] Storing MySQL user name or password information in the master info repository is not secure and is therefore not recommended. Please consider using the USER and PASSWORD connection options for START SLAVE; see the 'START SLAVE Syntax' in the MySQL Manual for more information.
2019-10-08 11:35:46 20043 [Note] Slave I/O thread: connected to master 'repl@10.9.33.154:3324',replication started in log 'mysql-bin.000196' at position 627556118
2019-10-08 11:35:46 20043 [Warning] Slave SQL: If a crash happens this configuration does not guarantee that the relay log info will be consistent, Error_code: 0
2019-10-08 11:35:47 20043 [Note] Event Scheduler: Loaded 0 events
2019-10-08 11:35:47 20043 [Note] /usr/local/mysql/bin/mysqld: ready for connections.
Version: '5.6.25-log' socket: '/tmp/mysqld.3324_gdocrimg04.sock' port: 3324 Source distribution
2019-10-08 11:35:47 20043 [Note] Slave SQL thread initialized, starting replication in log 'mysql-bin.000195' at position 1038060754, relay log '/data01/mysql_3324_gdocrimg04/relaylog/relay-bin.000576' position: 1038060917
InnoDB: innodb_force_recovery is on: we do not allow
InnoDB: database modifications by the user. Shut down
InnoDB: mysqld and edit my.cnf so thatInnoDB: innodb_force_... is removed.
2019-10-08 11:35:47 20043 [ERROR] Slave SQL: Could not execute Write_rows event on table ocr.edu_ocr_task; Operation not allowed when innodb_forced_recovery > 0., Error_code: 1881; handler error No Error!; the event's master log mysql-bin.000195, end_log_pos 1038069086, Error_code: 1881
2019-10-08 11:35:47 20043 [Warning] Slave: Operation not allowed when innodb_forced_recovery > 0. Error_code: 1881
2019-10-08 11:35:47 20043 [ERROR] Error running query, slave SQL thread aborted. Fix the problem, and restart the slave SQL thread with "SLAVE START". We stopped at log 'mysql-bin.000195' position 1038060754
mysql> show slave status\G
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 10.9.33.154
Master_User: repl
Master_Port: 3324
Connect_Retry: 60
Master_Log_File: mysql-bin.000199
Read_Master_Log_Pos: 409475023
Relay_Log_File: relay-bin.000576
Relay_Log_Pos: 1038060917
Relay_Master_Log_File: mysql-bin.000195
Slave_IO_Running: Yes
Slave_SQL_Running: No
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 1881
Last_Error: Could not execute Write_rows event on table ocr.edu_ocr_task; Operation not allowed when innodb_forced_recovery > 0., Error_code: 1881; handler error No Error!; the event's master log mysql-bin.000195, end_log_pos 1038069086
Skip_Counter: 0
Exec_Master_Log_Pos: 1038060754
Relay_Log_Space: 4710497755
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: NULL
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 1881
Last_SQL_Error: Could not execute Write_rows event on table ocr.edu_ocr_task; Operation not allowed when innodb_forced_recovery > 0., Error_code: 1881; handler error No Error!; the event's master log mysql-bin.000195, end_log_pos 1038069086
Replicate_Ignore_Server_Ids:
Master_Server_Id: 1183324
Master_UUID: 7ccac49c-880e-11e9-9a0f-90e2ba87e0fc
Master_Info_File: /data01/mysql_3324_gdocrimg04/data/master.info
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State:
Master_Retry_Count: 86400
Master_Bind:
Last_IO_Error_Timestamp:
Last_SQL_Error_Timestamp: 191008 11:35:47
Master_SSL_Crl:
Master_SSL_Crlpath:
Retrieved_Gtid_Set:
Executed_Gtid_Set:
Auto_Position: 0
1 row in set (0.00 sec)
time /usr/local/mysql/bin/mysqldump -ubluewhale -pbluewhale001 --single-transaction --master-data=2 ocr edu_ocr_task -S /tmp/mysqld.3324_gdocrimg04.sock > edu_ocr_task-`date +%Y%m%d`.sql
drop table edu_ocr_task;
在innodb_force_recovery = 0模式下启动
source /root/edu_ocr_task-20191008.sql
成功
screen -S allen
pt-table-sync --print --sync-to-master h=10.10.xx.xx,u=xx,p=xx,P=3324,D=ocr,t=edu_ocr_task --charset=utf8
ctrl + ad
gdocrimg04从库无法重启问题的更多相关文章
- 配置完php.ini中的扩展库后,重启apache出现错误1067
网上有很多解决办法,比如更改环境变量,重装apache等等,但没有一个是符合我的.最后发现只是犯了一个低级错误,因为是第一次配置php.ini中的扩展库,忘记配置扩展库的路径. 解决办法:需要先加上扩 ...
- [Oracle] Data Guard 系列(5) - 创建逻辑备库
在创建逻辑备库之前,必须得先创建物理备库,关于如何创建物理备库,请参考<Data Guard 系列(4) - 在不停主库的情况下创建物理备库>. 1. 在物理备库上停止日志应用服务 SYS ...
- 计算机安装了IE8一半退出重启时,桌面只显示背景
记得我在一家公司实习网管的时候,我遇到过一个这样的情况:那时候公司就我一个网管(原来的那个老员工走了才临时要了我),公司有台台式,上面装了公司的ERP还有一系列的软件.因为那个ERP限制了机器,用另外 ...
- DG备库无法接受主库归档日志之密码文件
DG备库无法接受主库归档日志之密码文件 实验目的:还原某个客户案例,客户审计需要,对主库sys用户进行锁定,一小时后对sys用户进行解锁后,发现备库无法接受主库的归档日志 本篇文章,测试sys用户与D ...
- Rime中州韵导入QQ五笔词库
过程记录如下: 1.在QQ五笔中导出QQ五笔系统词库 2.使用「深蓝词库转换」转换QQ五笔系统词库,输入源修改为”五笔86版“,输出方式修改为Rime中州韵-五笔. 3.在Ubuntu中打开Termi ...
- pgsql物理复制(pgsql 备库的搭建以及角色互换,提升)
结构图如下: Postgresql早在9.0版本开始支持物理复制,也称为流复制,通过从实例级复制出一个与主库一模一样的备库.流复制同步方式有同步,异步两种,如果主节点和备节点不是很忙,通常异步模式下备 ...
- Python使用EasyOCR库对行程码图片进行OCR文字识别介绍与实践
关注「WeiyiGeek」点我,点我 设为「特别关注」,每天带你在B站玩转网络安全运维.应用开发.物联网IOT学习! 希望各位看友[关注.点赞.评论.收藏.投币],助力每一个梦想. 文章目录 0x00 ...
- KingbaseES集群管理维护案例之---备库checkpoint分析
数据库异常关闭时,数据库关闭时来不及或者没机会做checkpoint,则需要从上一个一致性检查的开始恢复.KingbaseES备机checkpoint是不能产生checkpoint WAL日志条目 ...
- 第2讲 Redis常用命令与高级应用
目录 一.redis数据类型 5. sorted sets类型和操作 二.Redis常用命令 1.键值相关命令 2.服务器相关命令 三. redis高级应用 1. 给redis服务器设置密码 2.持久 ...
随机推荐
- learning java 实例序列化
对Person类实例进行序例化及反序例化: Person.java public class Person implements java.io.Serializable { private Stri ...
- ArrayList 集合 简单运用
集合 遍历 import java.util.ArrayList; class Demo02 { public static void main(String[] args) { // 创建Arra ...
- WinDbg常用命令系列---显示数据类型dt/dtx
dt (Display Type) dt命令显示有关局部变量.全局变量或数据类型的信息.这可以显示有关简单数据类型以及结构和联合的信息. 用户模式下: dt [-DisplayOpts] [-Sear ...
- 解决Ubuntu系统下 mysql 远程连接失败的问题 ERROR 2003 (HY000): Can't connect to MySQL server on 'xxx.xxx.xx.xx' (110)
如果远程连不上mysql.cnf 里面也修改了:bind注销掉了127.0.0.1 等所有的 但是telnet xxx.xxx.xx.xx 3306 端口 不通:那么 就是防火墙的问题了 1.修改Ub ...
- python实现:判断某一天是那一年中的第几天
方法1:先判断是否是闰年,然后再利用求和,得出某一天是第几天 # 方法1:low版 def func1(year, month, day): # 分别创建平年,闰年的月份天数列表(注意列表下标从0开始 ...
- mysql 分组条件筛选
mysql> select * from table1; +----------+------------+-----+---------------------+ | name_new | t ...
- 【CSP模拟赛】Confess(数学 玄学)
题目描述 小w隐藏的心绪已经难以再隐藏下去了.小w有n+ 1(保证n为偶数)个心绪,每个都包含了[1,2n]的一个大小为n的子集.现在他要找到隐藏的任意两个心绪,使得他们的交大于等于n/2. 输入描述 ...
- 第06组 Alpha冲刺(5/6)
队名:拾光组 组长博客链接 作业博客链接 团队项目情况 燃尽图(组内共享) 组长:宋奕 过去两天完成了哪些任务 主要完成了个人中心模块的接口设计 完善后端的信息处理 GitHub签入记录 接下来的计划 ...
- 创建批处理文件.bat文件(删除指定文件夹下的文件及文件夹并循环)
1.针对仅仅是删除文件夹下的文件的操作:使用del命令,单纯的删除文件操作,如下:del /f /s /q C:\Users\dell\AppData\Local\Temp\*.* 2.删除文件夹操作 ...
- linux设置程序运行超时时间
在某些情况下,我们需要限制程序的运行时间(比如cronjob等),这里简单介绍下使用信号及timeout的实现方法 1. 假如有如下代码(test_timout.sh): #!/bin/bash wh ...