1661344583
Trong blog này, chúng tôi sẽ hướng dẫn bạn thông tin chi tiết về biến secure_file_priv trong MySQL.
Nếu bạn đã từng đi sâu hơn vào các cài đặt cho phép bạn giải phóng toàn bộ sức mạnh của MySQL, bạn có thể đã bắt gặp một vài cài đặt cho phép bạn thực hiện nhiều tác vụ khác nhau - một trong những cài đặt như vậy là secure_file_priv
biến.
Biến secure_file_priv
được kết hợp chặt chẽ với việc nhập hàng loạt dữ liệu bên trong các phiên bản cơ sở dữ liệu dựa trên InnoDB của bạn. Hãy nhớ làm thế nào chúng ta đã nói rằng điều đó LOAD DATA INFILE
nhanh hơn đáng kể so với INSERT
các tuyên bố do thực tế là nó đi kèm với nhiều cái gọi là "chuông và còi" duy nhất cho chính nó ? Một phần của sự kỳ diệu đó là load_data_infile
. Biến thường nằm trong tệp my.cnf của bạn (chính nó nằm trong thư mục của bạn /var/bin/mysql
) và trông giống như sau (ví dụ sau đề cập đến biến đang được sử dụng trong môi trường Windows):
secure_file_priv=”d:/wamp64/tmp”
Nói một cách đơn giản, biến này hạn chế các thư mục có thể được sử dụng để tải dữ liệu vào phiên bản cơ sở dữ liệu MySQL của bạn. Nói cách khác, nếu bạn chạy một LOAD DATA INFILE
truy vấn và tệp bạn tải vào phiên bản cơ sở dữ liệu dựa trên InnoDB của bạn không nằm trong thư mục này, MySQL sẽ quay lại với một lỗi như sau:
ERROR 1290 (HY000): The MySQL server is running with the --secure-file-priv option so it cannot execute this statement
Để khắc phục lỗi này, bạn cần phải điều khiển --secure-file-priv
cài đặt từ xa khỏi tệp my.cnf hoặc tải dữ liệu của bạn từ một thư mục được chỉ định trong giá trị của biến. Khi bạn làm như vậy, dữ liệu của bạn sẽ được tải vào mà không gặp bất kỳ sự cố nào!
Ngoài việc tải dữ liệu vào các phiên bản cơ sở dữ liệu MySQL của bạn bằng cách sử dụng LOAD DATA INFILE
và sử dụng đặc quyền này, giá trị của một biến như vậy cũng có thể có liên quan khi xuất dữ liệu ra khỏi MySQL bằng cách sử dụng SELECT … INTO OUTFILE
. biến này cũng có thể được sử dụng để tắt các hoạt động nhập và xuất bằng cách sử dụng LOAD DATA INFILE
và SELECT ... INTO OUTFILE
: chỉ cần đặt biến này thành NULL
trong trường hợp như vậy. Mặc dù vậy, nói chung, bạn cũng có thể chạy một truy vấn như SHOW VARIABLES LIKE ‘secure_file_priv’
hoặc SELECT @@secure_file_priv
để quan sát tên của thư mục mà biến này được đặt thành. Đây là những gì Arctype sẽ đưa ra:
Kết quả có được từ ứng dụng Arctype SQL Client
Như bạn có thể thấy, thư mục thực sự được đặt thành ”d:/wamp64/tmp”
như trong ví dụ mà chúng tôi đã cung cấp cho bạn ở trên.
Biến secure_file_priv
biểu thị thư mục mà từ đó các tệp dữ liệu có thể được tải vào một cá thể cơ sở dữ liệu nhất định hoặc dữ liệu thư mục nào có thể được ghi khi xuất dữ liệu khi sử dụng LOAD DATA INFILE
hoặc SELECT ... INTO OUTFILE
. MySQL cho phép bạn quan sát giá trị của tham số này mọi lúc bằng cách chạy SELECT @@secure_file_priv
các truy vấn hoặc truy vấn như SHOW QUERY VARIABLES LIKE ‘secure_file_priv’
. Giá trị của tham số này luôn đáng để theo dõi: ngay cả khi bạn nghĩ rằng bạn sẽ không bao giờ cần tải các tập dữ liệu lớn hơn vào một cá thể cơ sở dữ liệu nhất định hoặc xuất các tập dữ liệu đó từ nó.
Liên kết: https://arctype.com/blog/mysql-secure-file-priv-tutorial/
#mysql #database
1595905879
HTML to Markdown
MySQL is the all-time number one open source database in the world, and a staple in RDBMS space. DigitalOcean is quickly building its reputation as the developers cloud by providing an affordable, flexible and easy to use cloud platform for developers to work with. MySQL on DigitalOcean is a natural fit, but what’s the best way to deploy your cloud database? In this post, we are going to compare the top two providers, DigitalOcean Managed Databases for MySQL vs. ScaleGrid MySQL hosting on DigitalOcean.
At a glance – TLDR
ScaleGrid Blog - At a glance overview - 1st pointCompare Throughput
ScaleGrid averages almost 40% higher throughput over DigitalOcean for MySQL, with up to 46% higher throughput in write-intensive workloads. Read now
ScaleGrid Blog - At a glance overview - 2nd pointCompare Latency
On average, ScaleGrid achieves almost 30% lower latency over DigitalOcean for the same deployment configurations. Read now
ScaleGrid Blog - At a glance overview - 3rd pointCompare Pricing
ScaleGrid provides 30% more storage on average vs. DigitalOcean for MySQL at the same affordable price. Read now
MySQL DigitalOcean Performance Benchmark
In this benchmark, we compare equivalent plan sizes between ScaleGrid MySQL on DigitalOcean and DigitalOcean Managed Databases for MySQL. We are going to use a common, popular plan size using the below configurations for this performance benchmark:
Comparison Overview
ScaleGridDigitalOceanInstance TypeMedium: 4 vCPUsMedium: 4 vCPUsMySQL Version8.0.208.0.20RAM8GB8GBSSD140GB115GBDeployment TypeStandaloneStandaloneRegionSF03SF03SupportIncludedBusiness-level support included with account sizes over $500/monthMonthly Price$120$120
As you can see above, ScaleGrid and DigitalOcean offer the same plan configurations across this plan size, apart from SSD where ScaleGrid provides over 20% more storage for the same price.
To ensure the most accurate results in our performance tests, we run the benchmark four times for each comparison to find the average performance across throughput and latency over read-intensive workloads, balanced workloads, and write-intensive workloads.
Throughput
In this benchmark, we measure MySQL throughput in terms of queries per second (QPS) to measure our query efficiency. To quickly summarize the results, we display read-intensive, write-intensive and balanced workload averages below for 150 threads for ScaleGrid vs. DigitalOcean MySQL:
ScaleGrid MySQL vs DigitalOcean Managed Databases - Throughput Performance Graph
For the common 150 thread comparison, ScaleGrid averages almost 40% higher throughput over DigitalOcean for MySQL, with up to 46% higher throughput in write-intensive workloads.
#cloud #database #developer #digital ocean #mysql #performance #scalegrid #95th percentile latency #balanced workloads #developers cloud #digitalocean droplet #digitalocean managed databases #digitalocean performance #digitalocean pricing #higher throughput #latency benchmark #lower latency #mysql benchmark setup #mysql client threads #mysql configuration #mysql digitalocean #mysql latency #mysql on digitalocean #mysql throughput #performance benchmark #queries per second #read-intensive #scalegrid mysql #scalegrid vs. digitalocean #throughput benchmark #write-intensive
1661344583
Trong blog này, chúng tôi sẽ hướng dẫn bạn thông tin chi tiết về biến secure_file_priv trong MySQL.
Nếu bạn đã từng đi sâu hơn vào các cài đặt cho phép bạn giải phóng toàn bộ sức mạnh của MySQL, bạn có thể đã bắt gặp một vài cài đặt cho phép bạn thực hiện nhiều tác vụ khác nhau - một trong những cài đặt như vậy là secure_file_priv
biến.
Biến secure_file_priv
được kết hợp chặt chẽ với việc nhập hàng loạt dữ liệu bên trong các phiên bản cơ sở dữ liệu dựa trên InnoDB của bạn. Hãy nhớ làm thế nào chúng ta đã nói rằng điều đó LOAD DATA INFILE
nhanh hơn đáng kể so với INSERT
các tuyên bố do thực tế là nó đi kèm với nhiều cái gọi là "chuông và còi" duy nhất cho chính nó ? Một phần của sự kỳ diệu đó là load_data_infile
. Biến thường nằm trong tệp my.cnf của bạn (chính nó nằm trong thư mục của bạn /var/bin/mysql
) và trông giống như sau (ví dụ sau đề cập đến biến đang được sử dụng trong môi trường Windows):
secure_file_priv=”d:/wamp64/tmp”
Nói một cách đơn giản, biến này hạn chế các thư mục có thể được sử dụng để tải dữ liệu vào phiên bản cơ sở dữ liệu MySQL của bạn. Nói cách khác, nếu bạn chạy một LOAD DATA INFILE
truy vấn và tệp bạn tải vào phiên bản cơ sở dữ liệu dựa trên InnoDB của bạn không nằm trong thư mục này, MySQL sẽ quay lại với một lỗi như sau:
ERROR 1290 (HY000): The MySQL server is running with the --secure-file-priv option so it cannot execute this statement
Để khắc phục lỗi này, bạn cần phải điều khiển --secure-file-priv
cài đặt từ xa khỏi tệp my.cnf hoặc tải dữ liệu của bạn từ một thư mục được chỉ định trong giá trị của biến. Khi bạn làm như vậy, dữ liệu của bạn sẽ được tải vào mà không gặp bất kỳ sự cố nào!
Ngoài việc tải dữ liệu vào các phiên bản cơ sở dữ liệu MySQL của bạn bằng cách sử dụng LOAD DATA INFILE
và sử dụng đặc quyền này, giá trị của một biến như vậy cũng có thể có liên quan khi xuất dữ liệu ra khỏi MySQL bằng cách sử dụng SELECT … INTO OUTFILE
. biến này cũng có thể được sử dụng để tắt các hoạt động nhập và xuất bằng cách sử dụng LOAD DATA INFILE
và SELECT ... INTO OUTFILE
: chỉ cần đặt biến này thành NULL
trong trường hợp như vậy. Mặc dù vậy, nói chung, bạn cũng có thể chạy một truy vấn như SHOW VARIABLES LIKE ‘secure_file_priv’
hoặc SELECT @@secure_file_priv
để quan sát tên của thư mục mà biến này được đặt thành. Đây là những gì Arctype sẽ đưa ra:
Kết quả có được từ ứng dụng Arctype SQL Client
Như bạn có thể thấy, thư mục thực sự được đặt thành ”d:/wamp64/tmp”
như trong ví dụ mà chúng tôi đã cung cấp cho bạn ở trên.
Biến secure_file_priv
biểu thị thư mục mà từ đó các tệp dữ liệu có thể được tải vào một cá thể cơ sở dữ liệu nhất định hoặc dữ liệu thư mục nào có thể được ghi khi xuất dữ liệu khi sử dụng LOAD DATA INFILE
hoặc SELECT ... INTO OUTFILE
. MySQL cho phép bạn quan sát giá trị của tham số này mọi lúc bằng cách chạy SELECT @@secure_file_priv
các truy vấn hoặc truy vấn như SHOW QUERY VARIABLES LIKE ‘secure_file_priv’
. Giá trị của tham số này luôn đáng để theo dõi: ngay cả khi bạn nghĩ rằng bạn sẽ không bao giờ cần tải các tập dữ liệu lớn hơn vào một cá thể cơ sở dữ liệu nhất định hoặc xuất các tập dữ liệu đó từ nó.
Liên kết: https://arctype.com/blog/mysql-secure-file-priv-tutorial/
#mysql #database
1595781840
MySQL does not limit the number of slaves that you can connect to the master server in a replication topology. However, as the number of slaves increases, they will have a toll on the master resources because the binary logs will need to be served to different slaves working at different speeds. If the data churn on the master is high, the serving of binary logs alone could saturate the network interface of the master.
A classic solution for this problem is to deploy a binlog server – an intermediate proxy server that sits between the master and its slaves. The binlog server is set up as a slave to the master, and in turn, acts as a master to the original set of slaves. It receives binary log events from the master, does not apply these events, but serves them to all the other slaves. This way, the load on the master is tremendously reduced, and at the same time, the binlog server serves the binlogs more efficiently to slaves since it does not have to do any other database server processing.
Ripple is an open source binlog server developed by Pavel Ivanov. A blog post from Percona, titled MySQL Ripple: The First Impression of a MySQL Binlog Server, gives a very good introduction to deploying and using Ripple. I had an opportunity to explore Ripple in some more detail and wanted to share my observations through this post.
Ripple supports only GTID mode, and not file and position-based replication. If your master is running in non-GTID mode, you will get this error from Ripple:
Failed to read packet: Got error reading packet from server: The replication sender thread cannot start in AUTO_POSITION mode: this server has GTID_MODE = OFF instead of ON.
You can specify Server_id and UUID for the ripple server using the cmd line options: -ripple_server_id and -ripple_server_uuid
Both are optional parameters, and if not specified, Ripple will use the default server_id=112211 and uuid will be auto generated.
While connecting to the master, you can specify the replication user and password using the command line options:
-ripple_master_user and -ripple_master_password
You can use the command line options -ripple_server_ports and -ripple_server_address to specify the connection end points for the Ripple server. Ensure to specify the network accessible hostname or IP address of your Ripple server as the -rippple_server_address. Otherwise, by default, Ripple will bind to localhost and hence you will not be able to connect to it remotely.
You can use the CHANGE MASTER TO command to connect your slaves to replicate from the Ripple server.
To ensure that Ripple can authenticate the password that you use to connect to it, you need to start Ripple by specifying the option -ripple_server_password_hash
For example, if you start the ripple server with the command:
rippled -ripple_datadir=./binlog_server -ripple_master_address= <master ip> -ripple_master_port=3306 -ripple_master_user=repl -ripple_master_password='password' -ripple_server_ports=15000 -ripple_server_address='172.31.23.201' -ripple_server_password_hash='EF8C75CB6E99A0732D2DE207DAEF65D555BDFB8E'
you can use the following CHANGE MASTER TO command to connect from the slave:
CHANGE MASTER TO master_host='172.31.23.201', master_port=15000, master_password=’XpKWeZRNH5#satCI’, master_user=’rep’
Note that the password hash specified for the Ripple server corresponds to the text password used in the CHANGE MASTER TO command. Currently, Ripple does not authenticate based on the usernames and accepts any non-empty username as long as the password matches.
Exploring MySQL Binlog Server - Ripple
It’s possible to monitor and manage the Ripple server using the MySQL protocol from any standard MySQL client. There are a limited set of commands that are supported which you can see directly in the source code on the mysql-ripple GitHub page.
Some of the useful commands are:
SELECT @@global.gtid_executed;
– To see the GTID SET of the Ripple server based on its downloaded binary logs.STOP SLAVE;
– To disconnect the Ripple server from the master.START SLAVE;
– To connect the Ripple server to the master.#cloud #database #developer #high availability #mysql #performance #binary logs #gtid replication #mysql binlog #mysql protocol #mysql ripple #mysql server #parallel threads #proxy server #replication topology #ripple server
1618911221
MySQL configuration variables are a set of server system variables used to configure the operation and behavior of the server. In this blog post, we will explain the differences in managing the configuration variables between MySQL 5.7 and MySQL 8.0.
We will explain three different ways for setting the configuration variables based on your use-case. Configuration variables that can be set at run-time are called Dynamic variables and those that need a MySQL server restart to take effect are called Non-Dynamic variables.
#mysql #mysql 5.7 #mysql server #mysql 8.0
1618900707
MySQL configuration variables are a set of server system variables used to configure the operation and behavior of the server. In this blog post, we will explain the differences in managing the configuration variables between MySQL 5.7 and MySQL 8.0.
We will explain three different ways for setting the configuration variables based on your use-case. Configuration variables that can be set at run time are called Dynamic variables and those that need a MySQL server restart to take effect are called Non-Dynamic variables.
#mysql #mysql 5.7 #mysql 8.0 #mysql server