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.持久 ...
随机推荐
- cube.js 新版本试用preosto
cube.js 新的版本添加了更多的数据库的支持,但是目前cubejs-cli 以及官方文档问题还挺多,使用不清晰,文档有明显的错误 以下演示presto 数据库的使用 环境准备 安装新版本的cube ...
- lyft amundsen简单试用
昨天有说过amundsen 官方为我们提供了dockerc-compose 运行的参考配置,以下是一个来自官方的 quick start clone amundsen 代码 amundsen 使用了g ...
- isntall
#! /bin/bash # zabbix server address zabbix='10.10.238.110' # repo address REPO='10.10.238.114:4507' ...
- [RN] React Native 常用命令行
[RN] React Native 常用命令行 1.查看当前版本 react-native --version 或 react-native -v 2.创建指定版本的React Native项目 1) ...
- CF1098E Fedya the Potter
CF1098E Fedya the Potter 题意:有一个序列\(A\). 对所有\(1\leq l\leq r\leq |A|\),将\(\gcd_{i=l}^{r}A_i\)加入\(B\)中. ...
- 设计模式之MVC和MVT
MVC各部分的功能 全拼为Model-View-Controller(如上图所示) M(模型)全拼为Model,主要封装对数据库层的访问(内嵌ORM框架),对数据库中的数据进行增.删.改.查操作. V ...
- vue中父级与子组件生命周期的先后顺序
1.vue的生命周期 2.views/createrCustormer.vue为父级 <template> <expressService /> </ ...
- RecyclerView 实现快速滚动
RecyclerView 实现快速滚动 https://www.cnblogs.com/mamamia/p/8311449.html
- android -------- SHA 加密算法
安全散列算法(英语:Secure Hash Algorithm,缩写为SHA)是一个密码散列函数家族,是FIPS所认证的安全散列算法.能计算出一个数字消息所对应到的,长度固定的字符串(又称消息摘要)的 ...
- bim模型中所有IfcWallStandardCase构件
ifc中的IfcWallStandardCase构件 //执行吊装 void startHoisting() { osg::Vec3f vec3f1 = index_node1->getBoun ...