欢迎各位兄弟 发布技术文章
这里的技术是共享的
老是看到 找不到 无法找到 zhiao.baidu.com 的服务器ip地址
找不到 无法找到 jingyan.baidu.com 的服务器ip地址
然后 过一两秒钟网页就能打开了
应该是 dns 解析器有问题
如下图 第 2) 步后 点详细信息(第二张图,发现 dns 服务器地址是 192.168.0.1)
IP地址和DNS服务器地址既可以自动获取,也可以手动设置;自动获取不会造成IP的冲突,但会影响开机速度;手动设置可能会造成IP冲突,但可以提高开机速度,各有优缺点,如何查看DNS服务器地址以及IP地址呢?可以看看哦!
集群基础概念负载过高超出单台服务器资源:
scale on 向上扩展 (换cpu,内存,换io吞吐能力强的磁盘)
4G内存,2cpu 变成 16G内存,8cpu;;;
硬件带来的增长比例与性能的增长比例不是线性的,一定范围内上升,最后反而下降
8颗cpu,有仲裁策略,分配策略,会争资源,架构不好,性能反而下降
硬件扩展4倍,价格远不止4倍
硬件扩展有瓶颈(不可能无限制cpu,无限制内存)
向上扩展只能在一定范围内使用,而且代价高昂,中小型企业难以承受
而且切换cpu,内存,硬盘都要时间
# xargs -n 3 ;#这里-n为3,表示,以空格为分隔符(即以空格来分段),以3个为一批,
set sql_log_bin=0 先禁用 二进制日志,,,,,,,,备份完后,,,,,,,set sql_log_bin=1 再启用
innodb_support_xa=true; 支持分布式事务的功能,它应该是启用的
sync_binlog=# 多久同步二进制日志到磁盘文件 ,,,0表示不同步(是提交时才同步?),,,,任何正数值都表示对二进制每多少次写操作之后同步一次;;;;备份时,建议设定为 1 ,,,,,会使得二进制日志写入到磁盘的时候,能够以安全的方式进行,不会因为我们的备份导致二进制日志文件的损坏
flush logs会滚动二进制日志
二进制日志:
基于语句 statement
基于行 row
混合方式 mixed
mysqldump:
还原过程涉及到写操作,
一大堆 dml ddl
假如还原的sql语句有3G
二进制日志会增长,应该大于3G,因为里面涉及到许多额外信息,
还原过程没必要让二进制记录下来(假如记录进二进制,既占据磁盘空间,又产生大量的IO,导致还原速度变慢)
基于逻辑备份还原数据库的时候,应该关掉二进制日志,然后再还原,还原后,再启动二进制日志
小编家里的WIFI放在二楼,一楼的信心有点差,特别是卫生间,信号基本为零,小编受不了了,买了个TP-LINK信号放大器(无线扩展器),之所以购买TP-LINK这个牌子,是因为小编的WIFI无线路由器也是这个牌子的,据说WIFI信号差用这玩意儿可以增加信号。
镜像
MySQL的备份和还原
备份:副本
RAID1,RAID10:保证硬件坏而不会业务中止;
drop table mydb.tb1;
备份和raid是两个不同层次上的概念
假设50G
cp (把服务器停了,把内存中的缓存同步到磁盘,再cp;;;但是服务器停了的话,代价太大了吧)
备份类型:
(根据备份的时候服务器是否能够在线)
热备份:在线备份,读,写操作可继续进行,不受影响
温备份:仅可以执行读操作,
冷备份:离线备份,,,读写操作均中止(均不能进行)
(根据是直接拷贝数据文件还是将数据导出)
1)
2)
二进制日志是写操作是,首先写入二进制日志缓冲(binlog_cache)然后commit,再从binlog_cache写入到binlog文件,默认大小为32K,而binlog_cache是session级别的,也就是说实际binlog cache占用内存数= connections * binlog_cache,可见如果connection过高,binlog_cache不宜设置的过大,如果binlog_cache设置的过小,不足以满足