tidb的安装配置规划 0x1 参考文档 软硬件环境和端口 https://docs.pingcap.com/zh/tidb/stable/hardware-and-software-requirements https://docs.pingcap.com/zh/tidb/stable/high-concurrency-best-practices tiflash运维文档 https://docs.pingcap.com/zh/tidb/stable/maintain-tiflash 0x2 前置要求 关闭swap 关闭透明大页 ntp 防火墙 io调度器为noop或者none，跟内核版本有关系 cpu频率为performance 关闭selinux 选择支持epollexclusive的内核版本 网卡速率不低于千兆 sysctl echo "fs.file-max = 1000000">> /etc/sysctl.conf echo "net.core.somaxconn = 32768">> /etc/sysctl.conf echo "net.ipv4.tcp_tw_recycle = 0">> /etc/sysctl.conf echo "net.ipv4.tcp_syncookies = 0">> /etc/sysctl.conf echo "vm.overcommit_memory = 1">> /etc/sysctl.conf sysctl -p ulimit cat << EOF >>/etc/security/limits.conf tidb soft nofile 1000000 tidb hard nofile 1000000 tidb soft stack 32768 tidb hard stack 32768 EOF 0x3 安装维护 安装模板 global: user: "tidb" ssh_port: 22 deploy_dir: "/data/tidb-deploy" data_dir: "/data/tidb-data" arch: "amd64" monitored: node_exporter_port: 9100 blackbox_exporter_port: 9115 pd_servers: - host: 10.8.16.92 - host: 10.8.16.93 - host: 10.8.16.94 tidb_servers: - host: 10.8.16.92 - host: 10.8.16.93 - host: 10.8.16.94 tikv_servers: - host: 10.8.16.95 - host: 10.8.16.96 - host: 10.8.16.97 tiflash_servers: - host: 10.8.16.98 - host: 10.8.16.99 monitoring_servers: - host: 10.8.16.91 grafana_servers: - host: 10.8.16.91 alertmanager_servers: - host: 10.8.16.91 安装前检测 tiup cluster check ./topology.yaml --user root --password 尝试修复 tiup cluster check ./topology.yaml --apply --user root --password 查询可以安装的版本列表 tiup list tidb 执行安装 tiup cluster deploy tidb-succez v5.2.1 ./topology.yaml --user root --password 启动 tiup cluster start tidb-succez 查询状态 tiup cluster display tidb-succez 查询kvstore状态 select STORE_ID,ADDRESS,STORE_STATE,STORE_STATE_NAME,CAPACITY,AVAILABLE,UPTIME from INFORMATION_SCHEMA.TIKV_STORE_STATUS; 一些优化 server_configs: tidb: log.level: error log.slow-threshold: 300 oom-action: cancel performance.max-procs: 20 performance.txn-total-size-limit: 10737418240 prepared-plan-cache.enabled: true tikv-client.max-batch-wait-time: 2000000 tikv: log-level: error pessimistic-txn.pipelined: true raftdb.allow-concurrent-memtable-write: true raftdb.max-background-jobs: 16 raftstore.apply-max-batch-size: 2048 raftstore.apply-pool-size: 3 raftstore.store-max-batch-size: 2048 raftstore.store-pool-size: 3 readpool.coprocessor.use-unified-pool: true readpool.storage.normal-concurrency: 10 readpool.storage.use-unified-pool: false readpool.unified.max-thread-count: 20 readpool.unified.min-thread-count: 5 rocksdb.max-background-jobs: 28 server.enable-request-batch: false server.grpc-concurrency: 6 storage.scheduler-worker-pool-size: 20 pd: replication.enable-placement-rules: true schedule.leader-schedule-limit: 4 schedule.region-schedule-limit: 2048 schedule.replica-schedule-limit: 64 tiflash: profiles.default.max_memory_usage: 0 profiles.default.max_memory_usage_for_all_queries: 0

tomcat之rewrite 0x1 如果前面没有放置反向代理，那么拦截uri需要在tomcat中处理 conf/context.xml中加入以下内容 <Valve className="org.apache.catalina.valves.rewrite.RewriteValve" asyncSupported="true"/> 在项目的目录内加入以下内容 webapps/sample/WEB-INF/rewrite.config，注意先移除war包，待测试好后此文件直接写入war中 RewriteCond %{REQUEST_URI} ^/sample/aaa [OR] RewriteCond %{REQUEST_URI} ^/sample/test [OR] RewriteCond %{REQUEST_URI} ^/sample/webdav RewriteRule ^(.*)$ /dashboard

tomcat的contextpath问题 0x1 问题 一直苦于产品对于上下文路径支持的不够灵活，比如 war 包名为 test.war，那么产品会在内部的请求中加载的资源全部写成 /test 开头，这样即使我们在 nginx 中用重写、反代等手段在前面增加一个上下文，或者完全修改这个上下文也是不行的。只是第一个修改后的请求能到后端，一但服务器返回资源后，请求内仍然是 /test 开头，下面的请求全部不能成功了 0x2 难度 要解决灵活设置上下文的问题，有哪些办法呢？ 请求简单，如果我们只需要一个接口，那么重写没有问题，因为它返回的内容不再有其他资源需要加载或者跳转 使用相对路径，使用相对路径不在显示上下文，那么可以很好的自己控制上下文是什么 产品本身实现设置上下文的功能，能够实现路径映射 在上面写的方式中，除了接口我们能够解决外，对于整个产品的上下文仍然没有很好的解决办法。 0x3 折中 在经过了一系列搜索后，终于找到了一个折中的办法，通过tomcat的配置来实现路径映射，如下： <Host name="localhost" appBase="webapps" unpackWARs="true" autoDeploy="false" deployOnStartup="false"> <Context path="aaa" docBase="testa" debug="0" reloadable="true"/> <Context path="bbb" docBase="testb" debug="0" reloadable="true"/> 在Host段内配置Context标签，path为浏览器访问的上下文路径，docBase为webapps下实际物理目录，这两行配置就可以实现通过aaa、bbb访问到之前的testa、testb项目，此时实现了testa、aaa共存的方式访问。 经过测试后，这个方案基本上能够满足修改上下文的需求，但是这个方案也有弊端，它会把项目部署两次，如果是通过war包部署，可以看到解压到了新的目录中。所以其实跟一个war复制到两个名字部署区别不大。 这个方法对于一般项目来说应该没问题，但是有些产品可能启动多个会自动组成集群，那么就可能会有集群问题 0x4 其他方案 上面的方案可能最终导致集群问题，那么还有方案吗？在经过检索后是有的，不过也是一个没有那么好的方案，可以增加上下文路径的级数来变相修改，比如默认是 /test，这种方法是修改为 /aaa/test。一开始以为 tomcat/webapps 下可以通过创建两级目录来实现这个效果，但测试失败，war根本不会部署。需要修改 war 名为 aaa#test.war ，这样解压后目录仍然是 aaa#test，但 # 的间隔符能够让我们在浏览器上使用两级目录访问了。 这种方法虽然仍然不是最优的，但目前测试下来并没有其他问题 0x5 20230830更新 上面的方法中使用 # 来作为 war 包的分隔符使得上下文路径有多级确实是tomcat支持的，所以是一个较好的解决方法，不过这一次经过检索后发现了多种配置方案达到此目的 方案一 修改 server.xml 为如下配置 <Host name="localhost" appBase="webapps" unpackWARs="true" autoDeploy="false" deployOnStartup="true" > <Context path="/ss/aa" docBase="/opt/tomcat8.5.91/war/test.war" /> 比较关键的是 path="/ss/aa" 和 docBase="/opt/tomcat8.5.91/war/test.war" ，第一个参数表示我们想要的上下文路径(contextpath)，第二表示war包的路径，这样把war放到外面可以防止二次部署，这是必须的。观察到这样启动后会自动解压缩指定路径的war到 webapps 下，并且目录名是 path 设置的路径。 方案二 修改 server.xml 为如下配置 <Host name="localhost" appBase="webapps" unpackWARs="false" autoDeploy="false" deployOnStartup="false" > <Context path="/ss/aa" docBase="test.war" /> 这个配置跟方案一差别不是很大，最大的区别就是没有指定war的绝对路径，那么会从webapps下识别，为了防止二次部署，需要把上面的 unpackWARS, autoDeploy, deployOnStartup 全部设置为 false，这样的话 webapps 目录下不会产生项目的目录，可防止二次部署的情况。但这种不解压war的方式对项目有一定的要求，有些项目启动的时候会要求从war解压的目录下读取文件，没有解压会报错，如下： 2023-08-30 15:40:22.587 [localhost-startStop-1] ERROR c.s.sys.service.JavaScriptCompiler - ServletContext resource [/dist/sys/nodejs/es6toes5.js] cannot be resolved to absolute file path - web application archive not exp anded? java.io.FileNotFoundException: ServletContext resource [/dist/sys/nodejs/es6toes5.js] cannot be resolved to absolute file path - web application archive not expanded? at org.springframework.web.util.WebUtils.getRealPath(WebUtils.java:344) at org.springframework.web.context.support.ServletContextResource.getFile(ServletContextResource.java:199) at com.succez.sys.service.JavaScriptCompiler.setServletContext(JavaScriptCompiler.java:170) at org.springframework.web.context.support.ServletContextAwareProcessor.postProcessBeforeInitialization(ServletContextAwareProcessor.java:108) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.applyBeanPostProcessorsBeforeInitialization(AbstractAutowireCapableBeanFactory.java:440) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1796) 方案三 跟上面的方法类似， Context 配置部分是可以在 conf/Catalina/localhost/ 目录下新建xml配置文件实现的。但是这种方案有一些限制，此 xml 文件内的 Context 内不能使用 path 参数，使用不会生效，仅能定义 docBase 指定 war 路径，而 contextpath 路径的指定由此文件名决定，所以 xml 文件需要大概格式如: test#aaa.xml ，那在这种情况下如果 war 也设置成两级目录，那么配置文件是优先生效的，比如： xml配置文件内 docbase 路径为 /app/war/test#aaa.war 配置文件名为 aaa#bbb.xml 方案四 开启 tomcat 的管理页面，在管理页面中可以上传 war 包部署，并且设置 path PS. 不管在上面哪个方案，会解压war包的方案最终都会生成 aaa#bbb 这种形式的目录，说明 tomcat 应该是使用这一种方法实现的定义 contextpath，只是配置方法有不同而已。 所以推荐使用直接命名 war 的方式，或者方案一 参考文档： https://octopus.com/blog/defining-tomcat-context-paths

tomcat详细日志打印 0x1 问题 经常换包或者升级一些功能之后重启tomcat报错，但是只是最后日志提示监听启动失败，具体的错误却没有显示： Context [] startup failed due to previous errors 这种情况怎么办呢？ 我们可以修改 tomcat 的日志打印配置，来记录更详细的日志 0x2 日志级别 修改 tomcat/conf/logging.properties 或者在 WEB-INF/classes目录下新建一个文件叫logging.properties，增加或者修改下面的内容 handlers = org.apache.juli.FileHandler, java.util.logging.ConsoleHandler ############################################################ # Handler specific properties. # Describes specific configuration info for Handlers. ############################################################ org.apache.juli.FileHandler.level = FINE org.apache.juli.FileHandler.directory = ${catalina.base}/logs org.apache.juli.FileHandler.prefix = error-debug. java.util.logging.ConsoleHandler.level = FINE java.util.logging.ConsoleHandler.formatter = java.util.logging.SimpleFormatter 0x3 其他 在 tomcat/conf/logging.properties 中追加上面的内容并不能解决所有的情况，有一次遇到错误: 一个或多个listeners启动失败，更多详细信息查看对应的容器日志文件 没有更多的内容了，在经过检索后需要使用下面的办法解决 把项目war包解压出来，添加文件 WEB-INF/classes/logging.properties 文件增加内容如下： org.apache.catalina.core.ContainerBase.[Catalina].level=INFO org.apache.catalina.core.ContainerBase.[Catalina].handlers=java.util.logging.ConsoleHandler 这样的话，就可以看到启动是哪里导致的错误

tomcat自签证书以及http跳转https 0x1 自签证书生成 使用java的命令： keytool -genkey -alias webgis -keyalg RSA -keypass gisplatform -storepass gisplatform -keysize 2048 -keystore webgis.keystore -validity 7300 keytool -export -alias webgis -storepass gisplatform -file webgis.cer -keystore webgis.keystore keytool -import -trustcacerts -alias webgis -storepass gisplatform -file webgis.cer -keystore cacerts server.xml 配置证书 keystoreFile="D:\apache-tomcat-8.5.15\bin\webgis.keystore" keystorePass="gisplatform" truststoreFile="D:\apache-tomcat-8.5.15\bin\cacerts" server.xml 配置tls版本以及加密套件，其中useServerCipherSuitesOrder="true"很重要，要优先使用服务端的顺序 <Connector port="8443" protocol="user.Http11Protocol" SSLEnabled="true" sslEnabledProtocols="TLSv1,TLSv1.2" useServerCipherSuitesOrder="true" ciphers="TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TLS_RSA_WITH_AES_128_CBC_SHA256, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_128_GCM_SHA256, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_256_CBC_SHA" scheme="https" secure="true" clientAuth="false" connectionTimeout="20000" redirectPort="8443" URIEncoding="UTF-8" keystoreFile="keystore.jks" keystorePass="password" /> 0x2 http跳转https tomcat默认配置了https是会共存http的，所以需要修改配置，使得访问http的时候自动跳转到https页面，修改web.xml <security-constraint> <web-resource-collection> <web-resource-name>SSL</web-resource-name> <url-pattern>/*</url-pattern> </web-resource-collection> <user-data-constraint> <transport-guarantee>CONFIDENTIAL</transport-guarantee> </user-data-constraint> </security-constraint>