为了做好运维面试路上的助攻手,特整理了上百道 【运维技术栈面试题集锦】 ,让你面试不慌心不跳,高薪offer怀里抱!
这次整理的面试题,小到shell、MySQL,大到K8s等云原生技术栈,不仅适合运维新人入行面试需要,还适用于想提升进阶跳槽加薪的运维朋友。
本份面试集锦涵盖了
- 174 道运维工程师面试题
- 128道k8s面试题
- 108道shell脚本面试题
- 200道Linux面试题
- 51道docker面试题
- 35道Jenkis面试题
- 78道MongoDB面试题
- 17道ansible面试题
- 60道dubbo面试题
- 53道kafka面试
- 18道mysql面试题
- 40道nginx面试题
- 77道redis面试题
- 28道zookeeper
总计 1000+ 道面试题, 内容 又全含金量又高
- 174道运维工程师面试题
1、什么是运维?
2、在工作中,运维人员经常需要跟运营人员打交道,请问运营人员是做什么工作的?
3、现在给你三百台服务器,你怎么对他们进行管理?
4、简述raid0 raid1raid5二种工作模式的工作原理及特点
5、LVS、Nginx、HAproxy有什么区别?工作中你怎么选择?
6、Squid、Varinsh和Nginx有什么区别,工作中你怎么选择?
7、Tomcat和Resin有什么区别,工作中你怎么选择?
8、什么是中间件?什么是jdk?
9、讲述一下Tomcat8005、8009、8080三个端口的含义?
10、什么叫CDN?
11、什么叫网站灰度发布?
12、简述DNS进行域名解析的过程?
13、RabbitMQ是什么东西?
14、讲一下Keepalived的工作原理?
15、讲述一下LVS三种模式的工作过程?
16、mysql的innodb如何定位锁问题,mysql如何减少主从复制延迟?
17、如何重置mysql root密码?
网上学习资料一大堆,但如果学到的知识不成体系,遇到问题时只是浅尝辄止,不再深入研究,那么很难做到真正的技术提升。
一个人可以走的很快,但一群人才能走的更远!不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!
5.2编译镜像
注意: 所有机器操作
通过dockerfile来编译镜像,用于后面的安装,命令:docker build -t mcr.microsoft.com/mssql/server:2017-ty .
其中mcr.microsoft.com/mssql/server
为镜像名称,2017-ty
是镜像标签,.
表示在当前目录下编译,因为dockerfile就在当前目录下。
最后出现Successfully
表示编译成功,否则根据错误信息进行解决。
5.3创建master容器
在sql01执行:
docker run --name sql01 \
--hostname sql01 \
-p 1433:1433 \
-p 5022:5022 \
-e 'ACCEPT\_EULA=Y' \
-e 'SA\_PASSWORD=P@ssw0rd02' \
-e "MSSQL\_AGENT\_ENABLED=True" \
-e "MSSQL\_PID=Developer" \
-d mcr.microsoft.com/mssql/server:2017-ty
5.4创建slave容器
在sql02执行:
docker run --name sql02 \
--hostname sql02 \
-p 1433:1433 \
-p 5022:5022 \
-e 'ACCEPT\_EULA=Y' \
-e 'SA\_PASSWORD=P@ssw0rd02' \
-e "MSSQL\_AGENT\_ENABLED=True" \
-e "MSSQL\_PID=Developer" \
-d mcr.microsoft.com/mssql/server:2017-ty
在sql03执行:
docker run --name sql03 \
--hostname sql03 \
-p 1433:1433 \
-p 5022:5022 \
-e 'ACCEPT\_EULA=Y' \
-e 'SA\_PASSWORD=P@ssw0rd02' \
-e "MSSQL\_AGENT\_ENABLED=True" \
-e "MSSQL\_PID=Developer" \
-d mcr.microsoft.com/mssql/server:2017-ty
至此容器已经启动完成,下面通过SSMS连接数据库进行相关检查和配置ALWAYSON。
5.5SSMS连接MSSQL
通过宿主机的外网IP+端口连接相应的数据库,如下:
注意:IP和端口之间是逗号
可以看到数据库的图标也是Linux的图标。
6.配置-数据库
这部分就是在数据库中进行相关配置,如:创建KEY加密文件,管理用户、可用组等。
6.1连接主库-sql01
主库也就是节点1,端口是1433,连接方法如上图。
我们将证书和私钥提取到/tmp/dbm_certificate.cer
和/tmp/dbm_certificate.pvk
文件中。
我们将这些文件复制到其他节点,并根据以下文件创建主密钥和证书:执行以下脚本
USE master
GO
CREATE LOGIN dbm_login WITH PASSWORD = 'Test@13579';
CREATE USER dbm_user FOR LOGIN dbm_login;
GO
CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'Test@13579';
go
CREATE CERTIFICATE dbm_certificate WITH SUBJECT = 'dbm';
BACKUP CERTIFICATE dbm_certificate
TO FILE = '/tmp/dbm\_certificate.cer'
WITH PRIVATE KEY (
FILE = '/tmp/dbm\_certificate.pvk',
ENCRYPTION BY PASSWORD = 'Test@13579'
);
GO
将文件拷贝到其他两个节点:
#sql01操作
docker cp sql01:/tmp/dbm_certificate.cer ./
docker cp sql01:/tmp/dbm_certificate.pvk ./
scp dbm_certificate.* 192.168.1.31:/data/ty/
scp dbm_certificate.* 192.168.1.32:/data/ty/
#sql02操作
docker cp dbm_certificate.cer sql02:/tmp/
docker cp dbm_certificate.pvk sql02:/tmp/
#sql03操作
docker cp dbm_certificate.cer sql03:/tmp/
docker cp dbm_certificate.pvk sql03:/tmp/
6.2连接从库-sql02和sql03
两个从库的端口分别是:1502和1503.然后重复主库执行的操作,如下:
CREATE LOGIN dbm_login WITH PASSWORD = 'Test@13579';
CREATE USER dbm_user FOR LOGIN dbm_login;
GO
CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'Test@13579';
GO
CREATE CERTIFICATE dbm_certificate
AUTHORIZATION dbm_user
FROM FILE = '/tmp/dbm\_certificate.cer'
WITH PRIVATE KEY (
FILE = '/tmp/dbm\_certificate.pvk',
DECRYPTION BY PASSWORD = 'Test@13579'
);
GO
6.3所有节点
在所有节点上执行以下命令
CREATE ENDPOINT [Hadr_endpoint]
AS TCP (LISTENER_IP = (0.0.0.0), LISTENER_PORT = 5022)
FOR DATA_MIRRORING (
ROLE = ALL,
AUTHENTICATION = CERTIFICATE dbm_certificate,
ENCRYPTION = REQUIRED ALGORITHM AES
);
ALTER ENDPOINT [Hadr_endpoint] STATE = STARTED;
GRANT CONNECT ON ENDPOINT::[Hadr_endpoint] TO [dbm_login];
GO
启用开机自启动ALWAYON,在所有节点执行以下命令
ALTER EVENT SESSION AlwaysOn_health ON SERVER WITH (STARTUP_STATE=ON);
GO
6.4创建高可用组
可以用SSMS工具和T-SQL两种方式,下面以T-SQL为例:
运行以下脚本在主节点
中创建一个可用性组。 请注意,选择CLUSTER_TYPE = NONE
选项是因为它是在没有诸如Pacemaker或Windows Server故障转移群集之类的群集管理平台的情况下安装的。
如果要在Linux上安装AlwaysOn AG,则应为Pacemaker选择CLUSTER_TYPE = EXTERNAL:
CREATE AVAILABILITY GROUP [AG1]
WITH (CLUSTER_TYPE = NONE)
FOR REPLICA ON
N'sql01'
WITH (
ENDPOINT_URL = N'tcp://192.168.1.30:5022',
AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,
SEEDING_MODE = AUTOMATIC,
FAILOVER_MODE = MANUAL,
SECONDARY_ROLE (ALLOW_CONNECTIONS = ALL)
),
N'sql02'
WITH (
ENDPOINT_URL = N'tcp://192.168.1.31:5022',
AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,
SEEDING_MODE = AUTOMATIC,
FAILOVER_MODE = MANUAL,
SECONDARY_ROLE (ALLOW_CONNECTIONS = ALL)
),
N'sql03'
WITH (
ENDPOINT_URL = N'tcp://192.168.1.32:5022',
AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,
SEEDING_MODE = AUTOMATIC,
FAILOVER_MODE = MANUAL,
SECONDARY_ROLE (ALLOW_CONNECTIONS = ALL)
);
GO
在从库中执行以下命令,将从库加入到AG组中
ALTER AVAILABILITY GROUP [ag1] JOIN WITH (CLUSTER_TYPE = NONE);
ALTER AVAILABILITY GROUP [ag1] GRANT CREATE ANY DATABASE;
GO
至此在Docker容器中安装SQL Server Alwayson集群已经完成了!
注意:当指定
CLUSTER_TYPE = NONE
创建可用组时,在执行故障转移时需执行以下命令-- 将主角色转移到可用性组中的某个备份副本 ALTER AVAILABILITY GROUP [ag1] FORCE_FAILOVER_ALLOW_DATA_LOSS; -- 尝试进行优雅的故障转移,如果不能完成,则允许丢失数据 -- ALTER AVAILABILITY GROUP [ag1] FAILOVER;
6.5测试
在主库上创建一个数据库,并加入到可用组AG中。
--创建数据库
CREATE DATABASE agtestdb;
GO
ALTER DATABASE agtestdb SET RECOVERY FULL;
GO
BACKUP DATABASE agtestdb TO DISK = '/var/opt/mssql/data/agtestdb.bak';
GO
ALTER AVAILABILITY GROUP [ag1] ADD DATABASE [agtestdb];
GO
-- 创建表
use agtestdb
CREATE TABLE ExampleTable (
ID INT PRIMARY KEY,
Name NVARCHAR(50),
Description NVARCHAR(100)
);
-- 插入数据
DECLARE @counter INT = 1;
WHILE @counter <= 100
BEGIN
INSERT INTO ExampleTable (ID, Name, Description)
VALUES (@counter, 'Name ' + CAST(@counter AS NVARCHAR(10)), 'Description for ' + CAST(@counter AS NVARCHAR(10)));
SET @counter = @counter + 1;
END;
GO
通过SSMS查看同步状态是否正常.
6.6监控 AG 状态
通过以下这些视图可以监控 AG 中各个部分的状态。
group的监控
select * from sys.availability_groups; select * from sys.availability_groups_cluster; select * from sys.dm_hadr_availability_group_states;
replica 的监控
select * from sys.availability_replicas; select * from sys.dm_hadr_availability_replica_states; select * from sys.dm_hadr_availability_replica_cluster_nodes; select * from sys.dm_hadr_availability_replica_cluster_states;
在 AG 中的 database 的监控
select * from sys.availability_databases_cluster; select * from sys.dm_hadr_database_replica_states; select * from sys.dm_hadr_database_replica_cluster_states; select name,database_id,replica_id,group_database_id from sys.databases;
6.7故障转移读取缩放AG上的主要副本
每个可用性组仅有一个主要副本。 主要副本允许读取和写入操作。 若要更改哪个副本为主要副本,可进行故障转移。 在典型的可用性组中,群集管理器自动执行故障转移过程。 在群集类型为 NONE 的可用性组中,需手动执行故障转移过程。
在群集类型为 NONE 的可用性组中,有两种对主要副本进行故障转移的方法:
手动故障转移(无数据丢失)
强制手动故障转移(会丢失数据)
手动故障转移(无数据丢失)
主要副本可用时使用此方法,但你需要暂时或永久更改托管主要副本的实例。 若要避免潜在的数据丢失,发出手动故障转移前,确保目标次要副本为最新版本。
手动故障转移(无数据丢失):
- 将当前的主要副本和目标次要副本设置为 SYNCHRONOUS_COMMIT。
ALTER AVAILABILITY GROUP [AGRScale]
MODIFY REPLICA ON N'<node2>'
WITH (AVAILABILITY_MODE = SYNCHRONOUS_COMMIT);
- 若要确定已将活动事务提交到主要副本和至少一个同步次要副本,请运行以下查询:
SELECT ag.name,
drs.database_id,
drs.group_id,
drs.replica_id,
drs.synchronization_state_desc,
ag.sequence_number
FROM sys.dm_hadr_database_replica_states drs, sys.availability_groups
ag
WHERE drs.group_id = ag.group_id;
当 synchronization_state_desc 为 SYNCHRONIZED 时,会同步次要副本。
- 将 REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT 更新为 1。以下脚本在名为 ag1 的可用性组上将REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT 设置为 1。 运行以下脚本前,将ag1 替换为可用性组的名称:
ALTER AVAILABILITY GROUP [AGRScale]
SET (REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT = 1);
此设置可确保将每个活动事务提交到主要副本和至少一个同步次要副本。
备注
此设置并非特定于故障转移,应根据环境要求进行设置。
- 将主要副本和不参与故障转移的次要副本设置为脱机,以便为角色更改做好准备:
ALTER AVAILABILITY GROUP [AGRScale] OFFLINE
- 将目标次要副本升级为主要副本。
ALTER AVAILABILITY GROUP AGRScale FORCE_FAILOVER_ALLOW_DATA_LOSS;
- 将旧的主要和其他次要副本的角色更新为 SECONDARY,在托管旧的主要副本的 SQL Server 实例上运行以下命令:
ALTER AVAILABILITY GROUP [AGRScale]
SET (ROLE = SECONDARY);
备注
若要删除可用性组,请使用删除可用性组。 对于使用群集类型为 NONE 或EXTERNAL 创建的可用性组,请对可用性组的所有副本执行该命令。
- 恢复数据移动,为托管主要副本的 SQL Server(主要和次要副本) 实例上的可用性组中的每个数据库运行以下命令:
ALTER DATABASE [db1]
SET HADR RESUME
- 重新创建出于读取缩放目的创建且不受群集管理器管理的所有侦听器。 如果原始侦听器指向旧的主要副本,请将其删除,然后将其重新创建为指向新的主要副本。
强制手动故障转移(会丢失数据)
如果主要副本不可用且无法立即恢复,则需要强制执行向次要副本的故障转移(存在数据丢失)。 但是,如果原始主要副本在故障转移后恢复,它将承担主要角色。 若要避免每个副本处于不同的状态,在存在数据丢失的情况下进行强制故障转移后,从可用性组中删除原始主要副本。 原始主要副本重新联机后,从该副本完全删除该可用性组。
若要强制执行从主要副本 N1 到次要副本 N2 的手动故障转移(存在数据丢失),请执行以下步骤:
- 在次要副本 (N2) 上,启动强制故障转移:
ALTER AVAILABILITY GROUP [AGRScale] FORCE_FAILOVER_ALLOW_DATA_LOSS;
- 在新的主要副本 (N2) 上,删除原始主要副本 (N1):
ALTER AVAILABILITY GROUP [AGRScale]
REMOVE REPLICA ON N'N1';
- 验证所有的应用程序流量均指向侦听器和/或新的主要副本。
- 如果原始主要副本 (N1) 进入联机状态,则立即在原始主要副本 (N1) 上使可用性组AGRScale 脱机:
ALTER AVAILABILITY GROUP [AGRScale] OFFLINE
- 如果存在数据或未同步的更改,则通过备份或其他可满足业务需求的数据复制选项来保存这些数据。
- 接下来,从原始主要副本 (N1) 中删除可用性组:
先自我介绍一下,小编浙江大学毕业,去过华为、字节跳动等大厂,目前在阿里
深知大多数程序员,想要提升技能,往往是自己摸索成长,但自己不成体系的自学效果低效又漫长,而且极易碰到天花板技术停滞不前!
因此收集整理了一份《2024年最新Linux运维全套学习资料》,初衷也很简单,就是希望能够帮助到想自学提升又不知道该从何学起的朋友。
既有适合小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,涵盖了95%以上运维知识点,真正体系化!
由于文件比较多,这里只是将部分目录截图出来,全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频,并且后续会持续更新
除可用性组:
先自我介绍一下,小编浙江大学毕业,去过华为、字节跳动等大厂,目前在阿里
深知大多数程序员,想要提升技能,往往是自己摸索成长,但自己不成体系的自学效果低效又漫长,而且极易碰到天花板技术停滞不前!
因此收集整理了一份《2024年最新Linux运维全套学习资料》,初衷也很简单,就是希望能够帮助到想自学提升又不知道该从何学起的朋友。
[外链图片转存中…(img-twYJPy7p-1715722962499)]
[外链图片转存中…(img-Ry6jSg89-1715722962499)]
[外链图片转存中…(img-VC6KPIPL-1715722962499)]
[外链图片转存中…(img-rXSe0pJK-1715722962500)]
[外链图片转存中…(img-RSgJ1VUK-1715722962500)]
既有适合小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,涵盖了95%以上运维知识点,真正体系化!
由于文件比较多,这里只是将部分目录截图出来,全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频,并且后续会持续更新