A: 使用自定义集群,可长期维持在一定数量,满足日常的渲染需求,当波峰来临时,可以提交 AutoCluster 任务或者调高集群规模(波峰过去调低数量),省钱又省力。
A: 场景文件,还有场景引用了的贴图、素材及渲染中使用的其他数据,建议在制作场景时所有使用的数据和场景文件都在一个目录里,这样上传一个目录即可。要保证在镜像中访问数据的路径同制作场景时相同,有些渲染软件也可设置素材路径。
A: 目前 BatchCompute 启动的计算节点只有内网 IP,无法连接公网,但同一个作业里的计算节点可以互相连通。
A: 在配置中将 RENDER_FLAG 设置成不同的值,千万不要使用同一个 RENDER_FLAG 部署多份渲管实例,会出错的。
A: 在节点日志页面,查看 worker 运行信息以及其它几个日志信息,相信能找到蛛丝马迹。
A: 上传数据到 OSS 时,保持目录结构,在数据映射时填好前缀(可能需要多个映射),尽量保证在计算节点中看到的渲染数据文件结构与制作时一样。
A: 制作镜像时,将远程 nas 的名字设置成本地机器的别名,在执行代码中执行命令将目标文件夹共享,如果数据小,也可以直接将数据制作进镜像,并共享。
A: 在创建项目时,OSS数据映射项,直接映射多个盘符。
A: 是的,虚拟机只有一个 C 盘(默认 40G)。
A: 在制作计算节点镜像时可以使用更大的系统盘,在使用该计算节点镜像创建集群时也需要选择足够大的磁盘容量,但使用超过 40G 的磁盘,BatchCompute 可能会收取少量费用。
A: 看场景。AutoCluster 类型的作业每个节点都要经历启停(启停时间在分钟级别),对于运行时间很短的任务比较不划算,而且可能因为资源紧张而等待,大量小任务建议创建集群进行渲染。对等待时间有要求的用户也应该使用自定义集群,这样提交任务到该集群,马上就可以运行,但 AutoCluster 的任务不用担心集群利用率的问题。
A:渲管是开源的(apache 2.0),想怎么改怎么改,请记得贡献回社区哦。
信息,获取主库信息连接主库
文件,获取到上次执行到的 relay-log 的位置,作为起点,回放 relay-log
信息,获取主库信息连接主库
文件,获取到上次执行到的 relay-log 的位置,作为起点,回放 relay-log
控制 binlog 从内存写入磁盘的控制开关
每次事务提交都立即刷新 binlog 到磁盘(双一标准中的其一)
每次事务提交不立即写入磁盘,靠操作系统判断什么时候写入
2 dump 线程多导致的,系统资源压力大,由于传送日志是串行的。
由于超大事务存在,由于是串行工作,会阻塞后续其他事务的传送。
事务量大(主库压力大)
从库 默认只有一个 SQL 线程,串行回放事务。在主库有并发事务量大,或者有超大事务时,都会导
致 SQL 延时较严重。
5.6 版本,加入了 GTID 特性,所以支持了并发 SQL 特性,基于不同库实现并行回放事务
5.7 版本,GTID 功能进行了升级,可以通过 Logical_clock 模式,实现事务级别的多 SQL 线程的回
放。我们把这种复制模式叫做 MTS。
每一条会修改数据的 sql 语句会记录到 binlog 中。优点是并不需要记录每一条 sql 语句和每一行的数
据变化,减少了 binlog 日志量,节约 IO,提高性能。缺点是在某些情况下会导致 master-slave 中的
不记录每条 sql 语句的上下文信息,仅需记录哪条数据被修改了,修改成什么样了。而且不会出现
某些特定情况下的存储过程、或 function、或 trigger 的调用和触发无法被正确复制的问题。缺点是
会产生大量的日志,尤其是 alter table 的时候会让日志暴涨。
无法复制的操作使用 ROW 模式保存 binlog,MySQL 会根据执行的 SQL 语句选择日志保存方式。
--databases, -B: 用于备份多个数据库,如果没有该选项,mysqldump 把第一个名字参数作为数据库
名,后面的作为表名。使用该选项,mysqldum 把每个名字都当作为数据库名。
-d: 只导出数据库的表结构
-t: 只导出数据库的数据
条数据被修改了,修改成了什么样子了。
binlog,MySQL 会根据执行的 SQL 语句选择日志保存方式。
双向的主从复制,也就是互为对方的从服务器,每台服务器即是对方的主服务器,又是对方的从服
1:主服务器凡运行语句,都产生一个二进制日志 binlog