MySQL optimization practice behind secure and high-availability communication

background

Internet services have very high requirements for high availability. Both application services and databases must be highly available. For government departments, group companies and other organizations, the importance of the system's high availability is self-evident. Taking the stability of 99.9% as the standard, it means that there are 8 hours of normal access failure in a year, and the organization system contains many modules, such as front-end applications, caches, databases, search, message queues, etc., each module All need to be highly available to ensure the stable operation of the entire system. In the entire organization, the communication system has the highest frequency of use and the widest coverage. The communication system also includes instant messaging and real-time audio and video. During the instant messaging chat, a large amount of text, expressions, pictures, videos, files and other data will be generated. Real-time audio and video will generate video recording files, and some of the information will be stored in the database. Therefore, whether the database is highly available directly affects the use of the communication system. On the other hand, some organizations attach great importance to information security and set different viewing permissions for different personnel to avoid leakage of sensitive information from being viewed by irrelevant personnel. Next, let's analyze the optimization practice of MySQL from the two aspects of high availability and control permissions. Sources of high-availability optimization problems 1. The database cannot be accessed because of a single point of failure, which affects the entire service and causes the service to become unresponsive. 2. Although the database cluster is deployed, it cannot be automatically switched after a failure occurs, resulting in prolonged failure time. Optimization ideas




1. MySQL adopts a dual-master synchronization deployment method to achieve high data availability, and user related data will not be lost in the case of a single node failure.

2. Application access to MySQL uses the local HA proxy mode. For the front end, because it is a local proxy, any proxy server (application server) downtime will not affect the use of other application servers. For the back end, because it is an HA proxy mode , So as long as one node of MySQL is alive, the application can be accessed normally.


Implementation steps

1. MySQL configuration dual master mode

 
 

# Master and Slave node configuration
[mysqld]
server-id=21 # The same id cannot appear in the same cluster
log_bin = /data/mysql/mysql-bin

# Master node creates a master-slave replication user
create user'repl'@'%' identified with mysql_native_password by'password'; grant replication slave on *.* to'repl'@'%';

#View Master node log_file and log_pos
show master status;

#Slave node configuration Master node information
change master to master_host='mysql- master', master_port=4306, master_user='repli', master_password='123456', master_log_file='mysql-bin.000001', master_log_pos=123299;

# Slave node enables slave
start slave;

Swipe left to see more →

2. Application server configuration Nginx HA proxy

 
 

upstream mysql{
 server mysql-node-1:{{ mysql_port }} max_fails=10 fail_timeout=30s;
 server mysql-node-2:{{ mysql_port }} backup;
}
server {
 listen 5307;
 proxy_pass mysql;
 proxy_connect_timeout 5s;
 proxy_timeout 120s;
 access_log /data/logs/mysql-ha-access.log stream_main;
 error_log /data/logs/mysql-ha-error.log;
}

左滑查看更多→

3.MySQL 其中一台节点配置探测脚本,只有另一台节点宕机才允许应用访问

 
 

#!/bin/bash
export PATH='/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/root/bin'
mysql_status=`{{ mysql_app_path }}/bin/mysqladmin -u{{ database_user }} -p{{ database_password }} -hrce-mysql-node-1 -P{{ mysql_port }} PING 2>/dev/null`
Date=`date '+%Y-%m-%d %H:%M:%S'`
Date_m=`date '+%Y%m'`
if [ "$mysql_status" != "mysqld is alive" ]
then
 iptables -D INPUT -s {{ host }} -j ACCEPT >/dev/null 2>&1
 iptables -I INPUT -s {{ host }} -j ACCEPT
 echo "$Date rce-mysql-node-1 is failed !!!" >> "{{ logs_path }}/scripts/set-mysql-iptables_$Date_m.log"
 echo "$Date Accept service access rce-mysql-node-2" >> "{{ logs_path }}/scripts/set-mysql-iptables_$Date_m.log"
else
 iptables -D INPUT -p tcp --dport 4306 -j DROP >/dev/null 2>&1
 iptables -I INPUT -p tcp --dport 4306 -j DROP
 iptables -D INPUT -s rce-mysql-node-1 -p tcp --dport 4306 -j ACCEPT >/dev/null 2>&1
 iptables -I INPUT -s rce-mysql-node-1 -p tcp --dport 4306 -j ACCEPT
 echo "$Date rce-mysql-node-1 is normal" >> "{{ logs_path }}/scripts/set-mysql-iptables_$Date_m.log"
 echo "$Date Denial of service access rce-mysql-node-2" >> "{{ logs_path }}/scripts/set-mysql-iptables_$Date_m.log"
fi


控制权限的优化

问题来源1.MySQL 用户权限管理混乱,不同项目的用户均可访问所有资源,导致了信息泄露。2.MySQL 目录杂乱,难以快速检索,导致运维实施难度大。
优化思路1.MySQL 使用普通用户启动,且该用户无法登录,避免因系统权限漏洞导致的信息泄露。2.MySQL 用户均只针对该用户所需访问的库开放权限,避免了不同服务用户越权操作的隐患。3.MySQL 数据及应用目录,统一归档到一级目录,且仅授予 MySQL 启动用户权限,易于管理。
实施步骤1.MySQL 初始化及配置文件指定普通用户账户

 
 

[mysqld]
user = {{ mysql_user }}


2.MySQL 授权需指明需访问哪个应用的库

grant all on {{ database_name }}.* to {{ database_user }}@'%' identified by {{ database_password }};


3.MySQL 相关目录均在配置文件中指定至一级目录

 
 

[mysqld]
socket = /data/app/mysql-node-2/mysql.sock
datadir = /data/data/mysql-node-2
socket = /data/app/mysql-node-2/mysql.sock
pid-file = /data/app/mysql-node-2/mysqld.pid
tmpdir = /data/app/mysql-node-2/tmp
log-error = /data/logs/mysql-node-2/mysqld.err
slow_query_log_file = /data/logs/mysql-node-2/mysql-slow.log
log_bin = /data/logs/mysql-node-2/mysql-bin
log-bin-index = /data/logs/mysql-node-2/mysql-bin.index
relay-log = /data/logs/mysql-node-2/relay-bin
relay-log-index = /data/logs/mysql-node-2/relay-bin.index
lc_messages_dir = /data/app/mysql-node-2/share
pid-file = /data/app/mysql-node-2/mysqld.pid


组织机构可以先从 MySQL 优化来确保通信系统底层支持系统稳定,来提高整个通信系统的安全高可用。


Guess you like

Origin blog.51cto.com/14206262/2665760