khanhnnvn

Hướng dẫn sử dụng phần mềm Trans

 Uncategorized  Comments Off on Hướng dẫn sử dụng phần mềm Trans
Apr 202020
 

1. Tải Trans cho máy tính

Để tải phần mềm Trans cho máy tính các bạn nhấn vào đây.

2. Cách cài đặt phần mềm Trans

Bước 1:

Nhấn chọn link tải TranS cho Windows hoặc Mac để tải phần mềm TranS về máy tính.

Bước 2:

Nhấn chuột phải hoặc kích đúp vào file SetupTranS.exe mới tải về → Run.

Bước 3:

Ngay sau đó sẽ xuất hiện cửa sổ Welcome to the TranS Setup Wizard hãy nhấn Next để đi tiếp.

Bước 4:

Tại cửa sổ Choose a file location bạn hãy chọn thư mục cài đặt ở mục Browse → Next.

Cách cài đặt Trans

Bước 5:

Giao diện Begin installation of TranS sẽ xác nhận lại việc cài đặt, nhấn Install để bắt đầu cài đặt.

Cách cài đặt Trans

Khi quá trình cài đặt hoàn tất hệ thống sẽ có thông báo cài đặt TranS thành công.

Bước 6:

Nhấn Run TranS để bắt đầu sử dụng ứng dụng.

Cách cài đặt Trans

3. Cách dùng Trans học trực tuyến

Bước 1. Khởi động chương trìnhNhấn đúp chuột vào biểu tượng TranS trên màn hình Desktop (máy tính) hoặc trên màn hình ứng dụng (Smartphone).

0 0

Bước 2: Đăng nhậpTừ cửa sổ đăng nhập, nhập tài khoản (email, password).

1 1

Nếu trước đó đã đăng nhập, hãy nhập lại đúng email để xác nhận và đăng nhập.

1

Bước 3: Sau khi đăng nhập thành công, xuất hiện giao diện chính của chương trình.

2

Một số lưu ý:

  1. Số hiệu TranS ID của bạn: (ví dụ 173526) là mã (số hiệu ID) của người đăng nhập.
  2. Nếu là Giảng viên: Mã số này chính là mã số của lớp học, Giảng viên cần cung cấp mã số này cho Sinh viên/Học viên, để Sinh viên/Học viên tham gia vào lớp học.
  3. Nếu là Sinh viên/Học viên: Mã số này được hiển thị kèm theo thông tin của Sinh viên/Học viên, giúp Giảng viên kiểm tra việc điểm danh cũng như mức độ tham gia lớp học của người học.

Bước 4:

Dành cho giáo viên

  • Nếu giảng viên thực hiện buổi giảng dạy tự do (không theo lịch hay thời khóa biểu) có thể chọn ngay chức năng Giáo viên để khởi tạo phòng học và bắt đầu buổi giảng dạy.
  • Nếu thực hiện theo lịch hay thời khóa biểu, Giảng viên cần chọn CÀI ĐẶT PHÒNG để thực hiện cấu hình một số thông tin của lớp học: Kiểm tra danh sách học viên, Cài đặt phòng, Cài đặt lịch/thời khóa biểu …
3

Cửa sổ cài đặt phòng học.

4.1. Tiếp theo, chọn Cài đặt phòng:

4

Kiểu phòng:

  • Bất kỳ khi nào (vào dạy/học bất cứ lúc nào).
  • Theo lịch (theo thời gian định sẵn).
  • Lịch chu kỳ (theo thời khóa biểu).

Chọn yêu cầu xác thực với người dùng:

  • Vào tự do: Cho phép vào tự do mà không cần đăng nhập (không khuyến khích vì khó kiểm soát việc điểm danh).
  • Phải đăng nhập: Chỉ chấp nhận vào phòng khi đăng nhập và tham gia theo TranS ID (khuyến khích).
  1. Tắt tất cả video của người vào học: Tích chọn để không cho phép hiển thị video người học (giúp tiết kiệm lưu lượng nhằm tăng độ mượt cũng như tốc độ truyền tín hiệu từ giảng viên đến lớp học).
  2. Tắt âm ding dong khi có người mới vào: Tích chọn để tắt cảnh báo chuông khi có người tham gia lớp học.

Sau cùng, chọn Lưu để hoàn tất cài đặt Phòng.

4.2. Chọn Đặt lịch phòng

Chức năng này chỉ được phép khi trong phần Cài đặt phòng chọn hình thức Theo lịch hoặc Lịch chu kỳ.

5

Danh sách lịch phòng

6

Thêm lịch phòng theo lịch bất kỳ.

6 1

Theo lịch phòng hình thức Thời khóa biểu.Lưu ý: Nếu Giảng viên cài đặt phòng, chỉ có thể vào lớp (Chọn Giảng viên) khi chọn hình thức tự do. Nếu lớp học diễn ra theo lịch, Giảng viên vào phòng bất cứ khi nào, sẽ xuất hiện hộp thoại cảnh báo sau đây:

7

4.3. Sau khi chọn chức năng Giáo viên để khởi tạo phòng học, xuất hiện cửa sổ video giống như Zoom.Bước tiếp theo, Giảng viên cần kiểm tra microphone và camera (laptop) hoặc camera (chân đế gắn ngoài) để phục vụ cho việc thu âm và ghi hình buổi học.

Thực hiện như sau:

Góc dưới bên phải cửa sổ, chọn mũi tên cạnh Mute.

9

Chọn Audio Setting để kiểm tra Microphone (lưu ý bật loa để kiểm tra): Chọn Test Speaker và Test Mic.

10

Kiểm tra camera: Góc dưới bên phải cửa sổ chính, chọn mũi tên cạnh Stop Video.

9 1

Tiếp theo, chọn Video Setting để thiết lập một số tính năng khác.

4.4. Tắt một số tính năng đối với Sinh viên/Học viên

Việt tắt các tính năng này, đảm bảo cho việc người học không tự ý chia sẻ (share) màn hình hoặc thực hiện vẽ chú thích lên màn hình mà giảng viên đang chia sẻ. Chỉ có Giảng viên mới thực hiện việc chia sẻ hoặc vẽ chú thích.

Thực hiện như sau:

  • Tắt chức năng chia sẻ màn hình (SHARE)

Nhấn vào mũi tên bên cạnh Share, chọn Advanced Sharing Option.

9 2

Chọn Only Host như hình dưới đây (chỉ có Giảng viên mới có thể chia sẻ).

13
  • Tắt chức năng vẽ chú thích (Annotation)

Chọn chức năng Share để thực hiện chia sẻ màn hình, chọn Screen để chia sẻ màn hình, chọn Whiteboard để chia sẻ nội dung được thể hiện trên bảng (dùng camera chân đế để ghi hình các nội dung từ bảng viết), tiếp theo chọn Share.

13 1

Kế tiếp, chọn More, tiếp theo chọn Disable partiipants annotation.

Đến đây, nếu hình ảnh hiển thị và thiết bị âm thanh hoạt động ổn định, việc kiểm tra thành công. Giáo viên bắt đầu có thể thực hiện các hoạt động giảng dạy của mình.Chúc các bạn thành công./.

Install WordPress on Ubuntu 18.04 LTS with Nginx, MariaDB and PHP-FPM

 Hệ thống  Comments Off on Install WordPress on Ubuntu 18.04 LTS with Nginx, MariaDB and PHP-FPM
Apr 112020
 

STEP 1: PREPARE AND UPDATE UBUNTU

It’s good to always update Ubuntu servers before installing packages… to update Ubuntu, run the commands below.

sudo apt update && sudo apt dist-upgrade && sudo apt autoremove

After updating Ubuntu, continue below with installing required packages for WordPress to work.

STEP 2: INSTALL Nginx WEB SERVER

After updating Ubuntu, run the commands below to install Nginx HTTP Server..

sudo apt install nginx

After installing Nginx, the commands below can be used to stop, start and enable Nginx service to always start up with the server boots.

sudo systemctl stop nginx.service
sudo systemctl start nginx.service
sudo systemctl enable nginx.service

STEP 3: INSTALL MARIADB DATABASE SERVER

MariaDB database server is rapidly overtaking MySQL in the open source and Linux communities… MariaDB is the default database server on majority of Linux distributions… and WordPress requires a database server.. run the commands below to install MariaDB.

sudo apt install mariadb-server mariadb-client

After installing, the commands below can be used to stop, start and enable MariaDB service to always start up when the server boots.

sudo systemctl stop mariadb.service
sudo systemctl start mariadb.service
sudo systemctl enable mariadb.service

After that, run the commands below to secure MariaDB server and create a new root password.

sudo mysql_secure_installation

When prompted, answer the questions below by following the guide.

  • Enter current password for root (enter for none): Just press Enter
  • Set root password? [Y/n]: Y
  • New password: Enter password
  • Re-enter new password: Repeat password
  • Remove anonymous users? [Y/n]: Y
  • Disallow root login remotely? [Y/n]: Y
  • Remove test database and access to it? [Y/n]:  Y
  • Reload privilege tables now? [Y/n]:  Y

STEP 4: INSTALL PHP-FPM AND RELATED MODULES

Now that Nginx and MariaDB are installed, run the commands below to install PHP-FPM and related PHP modules on the new server. This is a good list of PHP modules to install.

sudo apt install php-fpm php-common php-mbstring php-xmlrpc php-soap php-gd php-xml php-intl php-mysql php-cli php-ldap php-zip php-curl

After installing PHP, run the commands below to open PHP-FPM default configuration file.

sudo nano /etc/php/7.2/fpm/php.ini

Then scroll down the lines in the file and change the following lines below and save.

post_max_size = 100M
memory_limit = 256M
max_execution_time = 360
upload_max_filesize = 100M
date.timezone = America/Chicago

STEP 5: CREATE A BLANK WORDPRESS DATABASE

At this point, all the required WordPress packages and and servers are installed. The new server  is now ready to host WordPress… On the new server, create a blank WordPress database. WordPress will use this empty database to store its content.

Run the commands below to logon to the database server. When prompted for a password, type the root password you created above.

sudo mysql -u root -p

Then create a blank database called WP_database  you can use the same database name from the old server.

CREATE DATABASE WP_database;

Create a database user called wp_user with new password.  You can use the same username and password from the old server.

CREATE USER 'wp_user'@'localhost' IDENTIFIED BY 'type_password_here';

Then grant the user full access to the database.

GRANT ALL ON WP_database.* TO 'wp_user'@'localhost' IDENTIFIED BY 'type_user_password_here' WITH GRANT OPTION;

Finally, save your changes and exit.

FLUSH PRIVILEGES;
EXIT;

STEP 6: DOWNLOAD WORDPRESS LATEST RELEASE

Next, visit WordPress site and download the latest…. or run the commands below to do that for you.

cd /tmp && wget https://wordpress.org/latest.tar.gz
tar -zxvf latest.tar.gz
sudo mv wordpress /var/www/html/wordpress

Then run the commands below to set the correct permissions for WordPress root directory.

sudo chown -R www-data:www-data /var/www/html/wordpress/
sudo chmod -R 755 /var/www/html/wordpress/

STEP 7: CONFIGURE WORDPRESS

Next, run the commands below to create WordPress wp-config.php file. This is the default configuration file for WordPress.

sudo mv /var/www/html/wordpress/wp-config-sample.php /var/www/html/wordpress/wp-config.php

Then run the commands below to open WordPress configuration file.

sudo nano /var/www/html/wordpress/wp-config.php

Enter the highlighted text below that you created for your database and save.

// ** MySQL settings - You can get this info from your web host ** //
/** The name of the database for WordPress */
define('DB_NAME', 'WP_database');

/** MySQL database username */
define('DB_USER', 'wp_user');

/** MySQL database password */
define('DB_PASSWORD', 'new_password_here');

/** MySQL hostname */
define('DB_HOST', 'localhost');

/** Database Charset to use in creating database tables. */
define('DB_CHARSET', 'utf8');

/** The Database Collate type. Don't change this if in doubt. */
define('DB_COLLATE', '');

Save the file and you’re done.

STEP 8: CONFIGURE THE NEW WORDPRESS SITE

Next, configure the WordPress site configuration file on the server. Run the commands below to create a new configuration file called wordpress

sudo nano /etc/nginx/sites-available/wordpress

Then copy and paste the content below into the file and save it. Replace example.com with your own domain name.

server {
    listen 80;
    listen [::]:80;
    root /var/www/html/wordpress;
    index  index.php index.html index.htm;
    server_name  example.com www.example.com;

     client_max_body_size 100M;

    location / {
        try_files $uri $uri/ /index.php?$args;        
    }

    location ~ \.php$ {
    include snippets/fastcgi-php.conf;
    fastcgi_pass             unix:/var/run/php/php7.2-fpm.sock;
    fastcgi_param   SCRIPT_FILENAME $document_root$fastcgi_script_name;
    }
}

Save the file and exit.

STEP 9: ENABLE THE WORDPRESS SITE

After configuring the VirtualHost above, enable it by running the commands below

sudo ln -s /etc/nginx/sites-available/wordpress /etc/nginx/sites-enabled/

Now all is configured… run the commands below to reload Nginx web server and PHP-FPM settings.

sudo systemctl restart nginx.service
sudo systemctl restart php7.2-fpm.service

After restarting Nginx, open your browser and browse to the server IP address or hostname. If everything was setup correctly, you should see WordPress default configuration wizard.http://example.com

WordPress default setup page

Follow the on-screen instructions until you’re successfully configured WordPress. When you’re done, login to the admin dashboard and configure WordPress settings.

Congratulations! You’ve just successfully installed WordPress.

Làm việc với CentOS

 Hệ thống  Comments Off on Làm việc với CentOS
Feb 212020
 

Chào các bạn,

Để làm việc với CentOS hiệu quả có số việc tôi muốn chia sẻ vớic các bạn để làm việc đó như sau:

  1. Thiết lập history

export HISTFILESIZE=
export HISTSIZE=
export HISTTIMEFORMAT=”[%F %T] “

Làm việc với Mysql Server

 Database  Comments Off on Làm việc với Mysql Server
Feb 202020
 

Disable mod only_full_group_by của msql :

SET GLOBAL sql_mode=(SELECT REPLACE(@@sql_mode,’ONLY_FULL_GROUP_BY’,”));

Kiểm tra lại:

SELECT @@sql_mode;

GRANT ALL PRIVILEGES ON . TO ‘root’@’192.168.31.1’ IDENTIFIED BY ‘daicakhanh21*’;
flush privileges;

Chạy ứng dụng Nodejs sử dụng PM2

 Uncategorized  Comments Off on Chạy ứng dụng Nodejs sử dụng PM2
Feb 172020
 

Khởi động app
$ pm2 start app.js

Load Balance 4 instances of api.js:
$ pm2 start api.js -i 4
Monitor in production:
$ pm2 monitor
Make pm2 auto-boot at server restart:
$ pm2 startup

Các lệnh hay làm việc với Ubuntu

 Hệ thống  Comments Off on Các lệnh hay làm việc với Ubuntu
Feb 172020
 

useradd -m -d /opt/home/khanhnnvn khanhnnvn

Cho tài khoản có quyền sudo

usermod -aG sudo khanhnnvn

List các tài khoản có quyền sudo:

grep '^sudo:.*$' /etc/group | cut -d: -f4

ufw allow from 183.81.32.14 to any port 3306

GRANT ALL PRIVILEGES ON . TO ‘root’@’192.168.31.1’ IDENTIFIED BY ‘daicakhanh21*’;
flush privileges;

Sự khác biệt giữa Permissioned và Permissionless Blockchain

 BlockChain  Comments Off on Sự khác biệt giữa Permissioned và Permissionless Blockchain
Oct 082019
 

Một trong những phần lớn nhất trong công nghệ blockchain chính là permissioned blockchain (blockchain được cấp phép hay blockchain đóng) và permissionless blockchain (blockchain không cần cấp phép hay blockchain mở). Sự khác biệt cơ bản khá rõ ràng: Bạn cần phê duyệt để sử dụng một permissioned blockchain, trong khi bất kỳ ai cũng có thể tham gia vào các hệ thống không cần cấp phép (permissionless). Ví dụ, blockchain Bitcoin ban đầu vẫn hoàn toàn mở, nhưng khi các công ty và tổ chức bắt đầu áp dụng công nghệ này, họ đã sẵn sàng hy sinh sự tin cậy và tính minh bạch để có quyền kiểm soát truy cập cũng như tùy chỉnh dễ dàng hơn.

Permissioned và Permissionless Blockchain thực sự không nên được sử dụng cho cùng một thứ. Ví dụ, mọi người có lẽ không quan tâm đến việc sử dụng một loại tiền điện tử được cấp phép (permissioned cryptocurrency), vì một trong những điểm hấp dẫn nhất của tiền điện tử là không ai có thể kiểm soát cách thức hoạt động của nó hoặc nơi nó đến. Ngược lại, một công ty như Maersk, sử dụng blockchain để theo dõi dịch vụ hậu cần vận chuyển của mình, không muốn đưa tất cả dữ liệu bí mật của mình lên một permissionless blockchain.

So sánh Permissioned và Permissionless Blockchain

  • Permissioned và Permissionless Blockchain có gì giống nhau?
  • Permissioned và Permissionless Blockchain co gì khác nhau?
    • Permissionless Blockchain
    • Permissioned blockchain
  • Permissioned hay permissionless blockchain tốt hơn?

Permissioned và Permissionless Blockchain có gì giống nhau?

Cả permissioned và permissionless blockchain đều có một số đặc điểm quan trọng:

Permissioned và Permissionless Blockchain có gì giống nhau?
  • Chúng là hai distributed ledger (sổ cái phân tán), có nghĩa là có nhiều phiên bản của cùng một dữ liệu được lưu trữ ở những nơi khác nhau và được kết nối thông qua một số loại mạng.
  • Cả hai đều sử dụng một số hình thức của cơ chế đồng thuận (consensus mechanism), nghĩa là chúng có cách để nhiều phiên bản sổ cái đạt được sự đồng thuận về việc chúng thực sự trông sẽ ra sao.
  • Cả hai về mặt lý thuyết đều bất biến theo nghĩa là dữ liệu chúng lưu trữ không thể bị thay đổi nếu không có đủ quyền kiểm soát mạng. Thậm chí sau đó, các block (khối) được liên kết bằng hàm băm mật mã (cryptographic hash) sẽ thay đổi nếu có bất kỳ dữ liệu nào bị thay đổi.

Nói một cách đơn giản, cả permissioned và permissionless blockchain đều sử dụng mật mã và phân cấp ở nhiều mức độ khác nhau, để lưu trữ chính xác dữ liệu ở định dạng khó hack hoặc thay đổi.

Permissioned và Permissionless Blockchain co gì khác nhau?

Permissionless Blockchain

Hầu hết các blockchain mà bạn từng nghe nói đều rơi vào loại này: Bitcoin, Ethereum, Litecoin, Dash và Monero. Tất cả những cái khác là blockchain công khai mà bất cứ ai cũng có thể giao dịch hoặc thậm chí tham gia với tư cách là validator (người xác thực).

Permissionless Blockchain

Tất cả dữ liệu được lưu trữ trên các chuỗi này đều có sẵn công khai và các bản sao đầy đủ của sổ cái được lưu trữ trên toàn thế giới. Đó là điều khiến các hệ thống này rất khó bị hack hoặc kiểm duyệt. Không ai điều hành blockchain, không ai có thể hạn chế quyền truy cập vào nó và bạn vẫn tương đối ẩn danh vì không cần phải xác minh chính mình để nhận một địa chỉ và thực hiện giao dịch.

Loại blockchain này có xu hướng tạo ra tiếng vang vì nó có những gì làm nền tảng cho hầu hết các loại tiền điện tử và những giải pháp phân cấp thú vị nhất. Sự cường điệu này là xứng đáng, vì các permissionless blockchain công khai có khả năng cách mạng hóa những dịch vụ trước đây yêu cầu người trung gian đáng tin cậy – không chỉ là tiền tệ. Ví dụ, một blockchain bất biến của ô tô có thể cung cấp cho bạn khả năng tra cứu dữ liệu đáng tin cậy trên mọi bộ phận, hồ sơ dịch vụ và giao dịch liên quan đến một chiếc xe đã qua sử dụng, thay vì tin tưởng một người trung gian nào đó.

Tất nhiên, hệ thống này không hề hoàn hảo. Nó có thể chậm, khó xây dựng và mở rộng quy mô, quá minh bạch để lưu trữ dữ liệu nhạy cảm, khó kiểm soát truy cập, tốn nhiều năng lượng và phức tạp. Đó là lý do tại sao các permissioned blockchain đang trở thành một giải pháp phổ biến hơn cho các công ty và tổ chức muốn sử dụng blockchain để thay thế các hệ thống truyền thống.

Permissioned blockchain

Tóm lại, permissioned blockchain chỉ dành cho những người được phép truy cập. Bất cứ ai muốn xác thực các giao dịch và/hoặc xem dữ liệu trên mạng, trước tiên phải được central authority (bộ phận trung tâm, chịu trách nhiệm quản lý chính) chấp thuận.

Permissioned blockchain

Điều này đặc biệt hữu ích cho các ngân hàng, công ty và những tổ chức khác phải tuân thủ các quy định và không muốn mất quyền kiểm soát hoàn toàn dữ liệu. Thay vì xây dựng trên một blockchain lớn, phi tập trung như Ethereum, các đơn vị này có thể tạo ra một giải pháp tùy chỉnh, chỉ được điều hành bởi những tổ chức mà họ chấp thuận.

Hãy tưởng tượng một công ty chuyên bán dưa hấu đưa chuỗi cung ứng của họ lên một tầm cao mới:

1. Công ty quyết định xây dựng một hệ thống blockchain để theo dõi trái cây của mình từ trang trại đến cửa hàng. Họ muốn biết chính xác ai là người tham gia trong mỗi bước, vì vậy công ty này quyết định sử dụng một permissioned blockchain mà chỉ người dùng được ủy quyền mới có thể truy cập.

2. Họ xây dựng Melonchain và cung cấp cho mỗi điểm trên chuỗi cung ứng cách để truy cập và thêm dữ liệu, được xác thực bởi một mạng lưới các máy chủ do công ty điều hành. Bằng cách này, bất cứ khi nào dữ liệu về một quả dưa được ghi lại, nó có thể được tra cứu trong sổ cái và được xác minh bằng mật mã sau đó.

3. Một số dữ liệu nhất định về mỗi quả dưa hấu, như ngày và địa điểm thu hoạch, được công khai cho người tiêu dùng, trong khi các dữ liệu khác, như chuyển động chính xác trong chuỗi cung ứng, được giữ bí mật để giúp công ty duy trì lợi thế cạnh tranh.

Tiền điện tử Libra của Facebook là một ví dụ điển hình khác. Nó có thể ra mắt công chúng trong tương lai, nhưng tại thời điểm ra mắt, chỉ một số công ty được chọn, đã đầu tư và được phê duyệt, mới có quyền vận hành nó và người dùng có thể phải đăng ký bằng danh tính thực.

Những lợi thế lớn của permissioned blockchain là chúng có:

  • Quyền kiểm soát truy cập
  • Khả năng tùy biến cao
  • Thay đổi thời gian dễ dàng hơn để tuân thủ các quy định
  • Hiệu quả năng lượng tốt hơn
  • Khả năng mở rộng tốt hơn

Tuy nhiên, chúng cũng có những nhược điểm. Đó là:

  • Tập trung hơn
  • Ít minh bạch
  • Dễ bị tấn công và thao túng hơn
  • Dễ dàng kiểm duyệt hơn
  • Ít ẩn danh hơn

Permissioned hay permissionless blockchain tốt hơn?

Các permissioned và permissionless blockchain chỉ là những nhánh của cùng một công nghệ, được phát triển để đáp ứng nhiều nhu cầu khác nhau. Cả hai đều hữu ích theo cách riêng của mình, đối với hầu hết các mục đích và công nghệ khác nhau trong thực tế.

Điều này có nghĩa là những lợi ích do permissionless blockchain mang lại không trực tiếp tác động đến các hệ thống được cấp phép, vì vậy việc một công ty nói rằng mình sử dụng công nghệ blockchain không hẳn nghĩa là nó riêng tư hoặc phi tập trung hơn nhiều so với cơ sở dữ liệu truyền thống. Nắm được sự biệt giữa permissioned và permissionless blockchain là một phần khá quan trọng.

Reset MySQL 5.7 root password

 Database  Comments Off on Reset MySQL 5.7 root password
Apr 092019
 
sudo mysqld_safe --skip-grant-tables &

Then when paste this and hit [ENTER]
mysql -uroot
use mysql;
update user set authentication_string=password('YOURSUPERSECRETPASSWORD') where user='root';
flush privileges;
quit
Restart MySQL
Login Mysql and change pass
set password=password('Admin321*');

Cài đặt Kubernetes trên Ubuntu

 Database  Comments Off on Cài đặt Kubernetes trên Ubuntu
Mar 052019
 

Kubernetes là một hệ thống mã nguồn mở để tự động triển khai, scaling, quản lý các container. Kubernetes được xây dựng bởi Google dựa trên kinh nghiệm quản lý sử dụng các container trong khi triển khai một hệ thống quản lý gọi là Borg ( nhiều lúc gọi là Omega).

Chuẩn bị

Cấu hình địa chỉ IP tĩnh

vim /etc/network/interfaces

iface enp2s0 inet static
address 172.16.12.120
netmask 255.255.255.0
network 172.16.12.0
gateway 172.16.12.1
dns-nameservers 8.8.8.8

Thiết lập file host theo yêu cầu, chú ý thiết lập cả trên master và các node

vim /etc/hosts

172.16.12.120 k8s-master
172.16.12.135 k8s-node1
172.16.12.136 k8s-node2

service networking restart

Cập nhật các bản vá

apt update && apt upgrade -y

Thiết lập kho cài đặt k8s

apt-get update && apt-get install -y apt-transport-https curl
curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | apt-key add –

cat </etc/apt/sources.list.d/kubernetes.list
deb https://apt.kubernetes.io/ kubernetes-xenial main
EOF

Cài đặt K8s

apt-get update
apt-get install -y kubelet kubeadm kubectl docker.io

Tiếp theo các bạn chạy lệnh sau:

kubeadm init –pod-network-cidr 10.244.0.0/16

cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
chown $(id -u):$(id -g) $HOME/.kube/confi
chown $(id -u):$(id -g) /root/.kube/config

Tiếp tục chạy lệnh

kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml

Thống kê các namespaces đang chạy

kubectl get pods –all-namespaces
watch kubectl get pods –all-namespaces

Khởi động lại dịch vụ

systemctl daemon-reload
systemctl restart kubelet
kubectl get node
watch kubectl get node

Cài đặt Dashboard cho k8s

kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v1.10.1/src/deploy/recommended/kubernetes-dashboard.yaml

Run command

cat < /root/khanh1.yml
apiVersion: v1
kind: ServiceAccount
metadata:
name: admin-user
namespace: kube-system
EOF

cat < /root/khanh2.yml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: admin-user
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: cluster-admin
subjects:

  • kind: ServiceAccount
    name: admin-user
    namespace: kube-system

EOF

Thực hiện chạy lệnh để apply

kubectl apply -f /root/khanh1.yml
kubectl apply -f /root/khanh2.yml

Hiển thị token để đăng nhập vào dashboard

kubectl -n kube-system describe secret $(kubectl -n kube-system get secret | grep admin-user | awk ‘{print $1}’)

kubectl proxy –address 0.0.0.0 –accept-hosts=’^*$’

http://127.0.0.1:8001/api/v1/namespaces/kube-system/services/https:kubernetes-dashboard:/proxy/#!/login

—————————————– Install Keepalived ——————————-

  1. Install

apt-get install keepalived -y

  1. Create file keepalived.conf

vrrp_instance VI_1 {
state MASTER
interface ens33
virtual_router_id 101
priority 101
advert_int 1
authentication {
auth_type PASS
auth_pass 1111
}
virtual_ipaddress {
172.16.12.123
}
}

  1. Copy file to node server and start it

service keepalived start

  1. Check

ip addr show eth0

result

2: ens33: mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 00:0c:29:a5:ee:89 brd ff:ff:ff:ff:ff:ff
inet 172.16.12.120/24 brd 172.16.12.255 scope global ens33
valid_lft forever preferred_lft forever
inet 172.16.12.123/32 scope global ens33
valid_lft forever preferred_lft forever
inet6 fe80::20c:29ff:fea5:ee89/64 scope link
valid_lft forever preferred_lft forever

   Note: Max 20 ip per vip

Intro MySQL replication

 Database  Comments Off on Intro MySQL replication
Dec 182018
 

1. Giới thiệu

Right tool for right job. Trước tiên phải hiểu là MySQL Replication không phải là giải pháp giải quyết mọi bài toán về quá tải hệ thống cơ sở dữ liệu. Để mở rộng một hệ thống ta có hai phương pháp mở rộng là scale up và scale out. Bắt đầu với 1 máy chủ thì hai phương pháp trên được diễn giải như sau:

Scale up có nghĩa là với một máy chủ ta làm cách nào đó để nó có thể phục vụ nhiều hơn số lượng kết nối, truy vấn. Nghĩa là giá trị 1/(số kết nối phục vụ) càng nhỏ thì càng tốt. Để đạt được mục đích này thì có 2 phương pháp:

  • Tăng phần cứng lên cho máy chủ. Nghĩa là với CPU là 4 core, RAM là 8 GB phục vụ được 500 truy vấn thì giờ ta tăng CPU lên 24 core, RAM tăng lên 32GB -> máy chủ có thể phục vụ được số lượng kết nối truy vấn nhiều hơn.
  • Optimize ứng dụng, câu truy vấn. Ví dụ với câu truy vấn lấy dữ liệu tốn 5s để lấy được dữ liệu, sau đó mới trả lại tài nguyên cho hệ thống phục vụ các truy vấn khác. Máy chủ có thể đồng thời phục vụ 500 truy vấn dạng như vậy thì nếu ta tối ưu để truy vấn lấy dữ liệu chỉ tốn 1s => Máy chủ có thể phục vụ đồng thời nhiều truy vấn hơn

Scale out là giải pháp tăng số lượng server và dùng các giải pháp load-balacer để phân phối truy vấn ra nhiều server. Ví dụ bạn có 1 server có khả năng phục vụ 500 truy vấn. Nếu ta dựng thêm 5 server nữa có cấu hình tương tự, đặt thêm một LB phía trước để phân phối thì có khả năng hệ thống có thể phục vụ đc 5×500 truy vấn đồng thời.

MySQL Replication là một giải pháp scale out (tăng số lượng instance MySQL) nhưng không phải bài toán nào cũng dùng được. Các bài toán mà MySQL Replication sẽ giải quyết tốt:

  • Scale Read
  • Data Report
  • Real time backup

1.1 Scale Read

Scale Read thường gặp ở các ứng dụng mà số truy vấn đọc dữ liệu nhiều hơn ghi, tỉ lệ read/write có thể 8020 hoặc hơn. Các ứng dụng thường gặp là báo, trang tin tức.

Với scale read ta sẽ chỉ có một Master instance phục vụ cho việc đọc/ghi dữ liệu. Có thể có một hoặc nhiều Slave instance chỉ phục vụ cho việc đọc dữ liệu

Một số ứng dụng write nhiều (thương mại điện tử) cũng có sử dụng MySQL Replication để scale out hệ thống

1.2 Data Report

Một số hệ thống cho phép một số người (leader, manager, người làm report, thống kê, data) truy cập vào dữ liệu trên production phục vụ cho công việc của họ. Việc chọc thẳng vào data production sẽ rất nguy hiểm vì:

  • Vô tình chỉnh sửa làm sai lệnh dữ liệu (nếu có quyền insert, update)
  • Vô tình thực thi các câu truy vấn tốn nhiều tài nguyên, thời gian truy vấn dài làm treo hệ thống

Việc setup một máy chủ làm data report (application cũng sẽ không kết nối tới server này) làm giảm thiểu 2 rủi ro trên

1.3 Real time backup

Với cơ sở dữ liệu lớn việc backup không thể thực hiện thường xuyên được (hàng giờ, hàng phút). Với các ứng dụng giao dịch tài chính, thanh toán, TMDT nếu bị mất dữ liệu 1 giờ, 1 ngày thì thiệt hại sẽ rất lớn (máy chủ chính tư dưng bị hỏng). Real time backup là một giải pháp bổ sung cho offline backup, chạy đồng thời cả 2 phương pháp này để bảo đảm sự an toàn cho dữ liệu.

Tuy nhiên, việc dùng replicate để backup dữ liệu chỉ đảm bảo nếu đĩa cứng của master bị hỏng, trong trường hợp human error khi xóa nhầm dữ liệu, hành động xóa sẽ được replicate sang slave luôn => vẫn bị mất dữ liệu.

Để tránh xảy ra trường hợp trên và giảm thiểu rủi ro mất dữ liệu, mình có giới thiệu một bài khác delay-replication.

2. Hoạt động như thế nào?

2.1 Một số mô hình

mysql-replication

Với cả hai mô hình ta luôn chỉ có 1 Master database phục vụ cho Write dữ liệu, có thể có một hoặc nhiều Slave database. Tùy từng mô hình ta có thể cấu hình mỗi web node connect vào một Slave DB tương ứng hoặc có thể dùng một LB đặt trước cụm Slave để LB tự động phân phối connection vào từng Slave DB theo thuật toán của LB

mysql-replication-lb

2.2 Cách hoạt động

Trên Master:

  • Các kết nối từ web app tới Master DB sẽ mở một Session_Thread khi có nhu cầu ghi dữ liệu. Session_Thread sẽ ghi các statement SQL vào một file binlog (ví dụ với format của binlog là statement-based hoặc mix). Binlog được lưu trữ trong data_dir (cấu hình my.cnf) và có thể được cấu hình các thông số như kích thước tối đa bao nhiêu, lưu lại trên server bao nhiêu ngày.
  • Master DB sẽ mở một Dump_Thread và gửi binlog tới cho I/O_Thread mỗi khi I/O_Thread từ Slave DB yêu cầu dữ liệu

Trên Slave:

  • Trên mỗi Slave DB sẽ mở một I/O_Thread kết nối tới Master DB thông qua network, giao thức TCP (với MySQL 5.5 replication chỉ hỗ trợ Single_Thread nên mỗi Slave DB sẽ chỉ mở duy nhất một kết nối tới Master DB, các phiên bản sau 5.6, 5.7 hỗ trợ mở đồng thời nhiều kết nối hơn) để yêu cầu binlog.
  • Sau khi Dump_Thread gửi binlog tới I/O_TheadI/O_Thread sẽ có nhiệm vụ đọc binlog này và ghi vào relaylog.
  • Đồng thời trên Slave sẽ mở một SQL_ThreadSQL_Thread có nhiệm vụ đọc các event từ relaylog và apply các event đó vào Slave => quá trình replication hoàn thành.
arch

Về logic mỗi Slave DB sẽ chỉ nhận dữ liệu từ Master DB, mọi hành động cập nhật dữ liệu BẮT BUỘC phải được thực hiện trên Master. Về nguyên tắc nếu ghi dữ liệu trực tiếp lên Slave DB => hỏng replication. Nhưng thực chất ta hoàn toàn có thể ghi dữ liệu trên Slave miễn sao khi Slave đọc binlog và apply không đụng gì tới những trường dữ liệu mà ta mới ghi vào thì sẽ không bị lỗi (mục này sẽ nói thêm ở các phần sau)

Với MySQL 5.5 thì mỗi slave sẽ chỉ có một slave_thread connect tới Master, tuy nhiên từ phiên bản 5.6 chúng ta có thể cấu hình nhiều slave_thread để việc apply bin log tới các slave nhanh hơn.

3. Hướng dẫn cài đặt và cấu hình

Mô hình:

  • Master DB: 172.17.0.1
  • Slave DB: 172.17.0.2

Trên Master DB

Cấu hình my.cnf

event-scheduler = on
bind-address = 172.17.0.1
server-id = 1

log-bin
binlog-format=row
binlog-do-db=dwh_prod
binlog-ignore-db=mysql
binlog-ignore-db=test

sync_binlog=0
expire_logs_days=2

Tạo user replication

GRANT REPLICATION SLAVE ON *.* TO 'slave_user'@'172.16.0.2' IDENTIFIED BY 'p@ssword';
FLUSH PRIVILEGES;

Tạo schema, dữ liệu để test

CREATE SCHEMA dwh_prod CHARACTER SET utf8 COLLATE utf8_general_ci;

CREATE TABLE tb1 (
 id INT,
 data VARCHAR(100)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
 
CREATE TABLE tb2 (
 id INT,
 data VARCHAR(100)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

SHOW TABLES;

Trên Slave DB

Cấu hình my.cnf

event_scheduler=off
bind-address = 172.17.0.2
server-id=2

log-bin
binlog-format=row
binlog-do-db=dwh_prod
binlog-ignore-db=mysql
binlog-ignore-db=test

transaction-isolation=read-committed
sync_binlog=0
expire_logs_days=2

Tạo replication và kiểm tra

Nguyên tắc khi tạo replication là phải LOCK tất cả các table trên Master DB, để dữ liệu không thay đổi, sau đó xác định binlog và position, 2 thông số dùng để cấu hình trên Slave xác định đoạn dữ liệu bắt đầu đồng bộ

Trên Master DB

FLUSH TABLES WITH READ LOCK;
SHOW MASTER STATUS;

+----------------+----------+--------------+------------------+
| File           | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+----------------+----------+--------------+------------------+
| m01-bin.000001 |      827 | dwh_prod     | mysql,test       |
+----------------+----------+--------------+------------------+

Giá trị cần quan tâm là

  • m01-bin.000001
  • 827

Sau đó ta sẽ dump dữ liệu từ Master DB và đẩy qua Slave DB (sau khi dump xong có thể UNLOCK TABLES; để Master DB có thể hoạt động lại).

mysqldump -uroot -p dwh_prod > dwh_prod_03072015.sql
rsync -avz -P -e'ssh' dwh_prod_03072015.sql root@172.17.0.2:/root/

Trên Slave

mysql -uroot -p dwh_prod < /root/dwh_prod_03072015.sql

> CHANGE MASTER TO MASTER_HOST='172.17.0.1',MASTER_USER='slave_user', MASTER_PASSWORD='p@ssword', MASTER_LOG_FILE='m01-bin.000001', MASTER_LOG_POS=827;
> START SLAVE
> SHOW SLAVE STATUS\G

Một số thông tin đã được lược bỏ cho dễ nhìn

*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 172.0.0.1
                  Master_User: slave_user
              Master_Log_File: m01-bin.000001
          Read_Master_Log_Pos: 827
               Relay_Log_File: m02-relay-bin.000002
                Relay_Log_Pos: 251
        Relay_Master_Log_File: m01-bin.000001
                   Last_Errno: 0
                   Last_Error: 
                 Skip_Counter: 0
          Exec_Master_Log_Pos: 827
              Relay_Log_Space: 405
        Seconds_Behind_Master: 0
                Last_IO_Errno: 0
                Last_IO_Error: 
               Last_SQL_Errno: 0
               Last_SQL_Error: 
             Master_Server_Id: 1

Các thông số cần quan tâm là

  • Last_Error: 0
  • Last_SQL_Error
  • Seconds_Behind_Master: 0

Hai thông số đầu tiên là lỗi khi Slave DB thực thi các event đọc từ relay log. Thông số Seconds_Behind_Master cho ta biết dữ liệu của Slave DB đang bị trễ (delay, lag) bao nhiêu giây so với Master DB. Các phần sau ta sẽ nói kỹ hơn về replication lag này.

4. Vận hành hệ thống MySQL Replicatione

4.1 Test logic replication

Ở trạng thái bình thường dữ liệu trên Slave DB đã đồng bộ với Master DB. Kiểm tra

Trên Master

mysql> USE dwh_prod
mysql> SHOW TABLES;
+--------------------+
| Tables_in_dwh_prod |
+--------------------+
| tb1                |
| tb2                |
| tb3                |
| tb4                |
+--------------------+

Trên Slave

mysql> USE dwh_prod
mysql> SHOW TABLES;
+--------------------+
| Tables_in_dwh_prod |
+--------------------+
| tb1                |
| tb2                |
| tb3                |
| tb4                |
+--------------------+
mysql -e -p 'SHOW SLAVE STATUS\G' | grep -i 'error\|seconds'
                   Last_Error: 
        Seconds_Behind_Master: 0
                Last_IO_Error: 
               Last_SQL_Error:

Mọi thứ đều ổn, không lỗi và không có Lag.

Giờ giả sử ta sẽ tạo một table với tên là tb00 trên Slave và kiểm tra xem có đúng là khi ghi dữ liệu lên Slave DB thì replication có bị hỏng hay không.

mysql> CREATE TABLE tb00 (
 id INT,
 data VARCHAR(100)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

mysql> SHOW TABLES;
+--------------------+
| Tables_in_dwh_prod |
+--------------------+
| tb00               |
| tb1                |
| tb2                |
| tb3                |
| tb4                |
+--------------------+
5 rows in set (0.00 sec)

Kiểm tra các table trên Master DB

mysql> SHOW TABLES;
+--------------------+
| Tables_in_dwh_prod |
+--------------------+
| tb1                |
| tb2                |
| tb3                |
| tb4                |
+--------------------+

Và kiểm tra lại trạng thái của replication

mysql -e 'SHOW SLAVE STATUS\G' | grep -i 'error\|seconds'                                                                                                   
            Last_Error: 
      Seconds_Behind_Master: 0
            Last_IO_Error: 
            Last_SQL_Error:

=> Như ta thấy rõ ràng là dữ liệu trên Slave và Master đã khác nhau (Slave có tb00 nhưng Master thì không) nhưng trạng thái của replication vẫn hoàn toàn ổn.

Giờ chúng ta sẽ thử thêm một trường hợp nữa là trên Master ta sẽ tạo một table tên là tb6 để kiểm tra xem chuyện gì sẽ xảy ra

mysql> CREATE TABLE tb6 (
 id INT,
 data VARCHAR(100)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

mysql> SHOW TABLES;
+--------------------+
| Tables_in_dwh_prod |
+--------------------+
| tb1                |
| tb2                |
| tb3                |
| tb4                |
| tb6                |
+--------------------+

Kiểm tra các table trên Slave DB

mysql> SHOW TABLES;
+--------------------+
| Tables_in_dwh_prod |
+--------------------+
| tb00               |
| tb1                |
| tb2                |
| tb3                |
| tb4                |
| tb6                |
+--------------------+

=> bảng tb6 đã được đồng bộ từ Master qua, kiểm tra trạng thái replication

mysql -e 'SHOW SLAVE STATUS\G' | grep -i 'error\|seconds'
                   Last_Error: 
        Seconds_Behind_Master: 0
                Last_IO_Error: 
               Last_SQL_Error:

=> Mọi thứ vẫn ổn, nghĩa là dù ta có ghi dữ liệu vào Slave, nhưng nếu Master thực thi các câu truy vấn không đụng gì tới dữ liệu được ghi mới ở Slave thì trạng thái của replication vẫn ổn.

Giờ ta sẽ thực hiện thêm một thử nghiệm nữa là trên Master ta tạo một table tên là tb00, trùng với table đã tạo lúc trước ở Slave phía trên và kiểm tra lại trạng thái của replication

Kiểm tra trạng thái replication trên Slave

mysql -e 'SHOW SLAVE STATUS\G' | grep -i 'error\|seconds'
              Last_Error: Error 'Table 'tb00' already exists' on query. Default database: 'dwh_prod'. Query: 'CREATE TABLE tb00 (
   Seconds_Behind_Master: NULL
           Last_IO_Error:
          Last_SQL_Error: Error 'Table 'tb00' already exists' on query. Default database: 'dwh_prod'. Query: 'CREATE TABLE tb00 (

=> như ta thấy hệ thống báo lỗi do trên Slave không thể thực thi hành động tạo table tb00 từ Master đẩy xuống (do table này đã tồn tại trước đó)

Kết Luận: Việc ghi dữ liệu vào Slave là có thể thực hiện được, nhưng sẽ gây ra rủi ro hỏng replication ở một lúc nào đó. Nhất là các câu truy vấn dạng SELECT … UPDATE. Tốt nhất là nên tránh ghi dữ liệu vào Slave

4.2 Replication Lag

Replication Lag là độ trễ dữ liệu của Slave so với Master. Khi triển khai một hệ thống MySQL Replication thì Lag là vấn đề chắc chắn gặp phải. Ta chỉ có thể giảm thiểu độ trễ dữ liệu trong mức chấp nhận được chứ không thể không có lag. Lí do là việc đồng bộ dữ liệu là Asynchronous, nghĩa là các Slave server không cần thông báo cho Master biết khi transaction thực hiện trên Slave thành công -> điều này giúp giữ nguyên hiệu suất (khác với cơ chế đồng bộ synchronous, một transaction được gọi là thành công khi nó committed trên master server và master server nhận được một thông báo từ slave server là transaction này đã được write và committed. Quá trình này đảm bảo tính thống nhất giữa master và slave server nhưng đồng thời nó làm giảm hiệu suất đi một nữa do các vấn đề về network, bandwidth, location.)

Vấn đề của replication lag ảnh hưởng tới các truy vấn vừa write dữ liệu xuống là read dữ liệu lên liền. Ví dụ

Một trang thương mại điện tử có tính năng add vào giỏ hàng một sản phẩm. Sau khi sản phẩm được add vào giỏ hàng sẽ trừ số lượng trong tồn kho. 2 user thực hiện mua sản phẩm đó (sản phẩm đó có số lượng tồn kho là 1). Cả 2 đều thấy sản phẩm đó trên website hiển thị trạng thái CÒN HÀNG. Khi một user mua sản phẩm đó và thanh toán thành công. Do độ trễ dữ liệu (ví dụ 5s) nên dữ liệu chưa đc cập nhật tồn kho xuống Slave là sản phẩm đã hết hàng. Khi user đó add giỏ hàng và thanh toán thì lúc này dữ liệu mới cập nhật và trả về mã lỗi là thanh toán không thành công do số lượng tồn kho không đáp ứng => ảnh hưởng tới trải nghiệm của user trên hệ thống.

Thường với những trường hợp này (truy vấn write xong là read liền) thì nên sử dụng cấu hình truy vấn trên Master (đây là lí do Master có thể vừa write vừa read chứ không nhất thiết là chỉ có write)

4.3 Lb mysql và healthchk

Như 1 trong 2 mô hình phía trên thì với mô hình thứ 2 ta có thể dùng haproxy làm lb cho các MySQL Instance.

Với mô hình 1 nhược điểm là nếu MySQL instance bị delay quá lâu, server quá tải hoặc rủi ro nhất là instace đó bị down thì ta không có cách nào check hoặc remove instance đó ra được.

Với mô hình 2 nhược điểm là ta mất thêm 1 layer (haproxy) nữa mới có thể kết nối tới MySQL (tốn thời gian, xử lí nhiều lớp) nhưng lợi điểm là có thể cấu hình healthchk, hoặc remove instance theo một số điều kiện.

5. Một số lưu ý

5.1 Vấn đề về server, phần cứng

Các vấn đề về CPU, RAM, đĩa cứng (kích thước, loại đĩa cứng, SSD hay HDD, tốc độ đọc ghi của đĩa cứng)

Với một hệ thống DB các thông số phần cứng NÊN quan tâm là

  • CPU: Càng nhiều core càng tốt, tốc độ càng nhanh càng tốt
  • RAM: RAM càng nhiều càng tốt

Với đĩa cứng

  • Nên sử dụng RAID 5, 6, 10
  • Nên sử dụng SSD (Enterprise thì càng tốt) IOPS càng cao càng tốt
  • Đĩa cứng nên có dung lượng ít nhất là x2 lần dung lượng của CSDL (sẽ cần thiết trong trường hợp dump, backup dữ liệu để fix replication)

Khác với các ứng dụng khác như web, static (thường CPU không cần nhiều core, đĩa cứng không cần nhiều và nhanh), máy chủ CSDL sẽ cần nhiều các thông số trên

Với AWS khi chọn Instance cũng nên chú ý các điểm trên

5.2 Các vấn đề về kích thước dữ liệu

Vấn đề kích thước dữ liệu ảnh hưởng khá nhiều đến vận hành một hệ thống MySQL Replication. Dữ liệu lớn thì quá trình replication đầu tiên hoặc khi hỏng replication sẽ rất lâu => Slave không thể sử dụng được trong thời gian replication, đến khi Second_Behind_Master = 0 thì mới có thể sử dụng được.

Ngoài ra các yếu tố về ổ đĩa cứng (SSD, tốc độ đọc ghi) cũng ảnh hưởng nhiều đến việc import hoặc apply các binlog từ Master

Dưới đây là một mô tả thực tế:

  • Dữ liệu thô /var/lib/mysql có kích thước 80-100GB
  • Dữ liệu dump ra chưa nén 18-30GB
  • Dữ liệu nén bằng chuẩn tgz ~ 2-3GB
  • Máy chủ 24 core, 32GB RAM, SSD Plextor M6 PRO (4×256, RAID 10)
  • Thời gian dump dữ liệu là 1h-1h30
  • Thời gian sync bản dump qua các server (local, port 1Gb) ~ 1h
  • Thời gian import dữ liệu ~1.5h
  • Thời gian Second_Behind_Master sau khi import xong ~ 3600s

6. Failover

Một vấn đề khác ngoài chuyện scale đó là nếu master db chết thì chuyện gì xảy ra?. Có một số mindset mà bạn bắt buộc phải hiểu khi chọn giải pháp replication master-slave đó là:

  • Quá trình promote 1 Slave thay thế Master là thủ công, không thể tự động switch sang slave mà hệ thống không có vấn đề gì.
  • Vẫn sẽ có downtime nếu master db chết, tuy nhiên việc dùng slave đảm bảo thời gian downtime tối thiểu nhất có thể.

Quay trở lại mô hình 1 master và 2 slave (gọi lần lượt là S1 và S2), ta cần trả lời là nếu master chết thì chuyện gì xảy ra với hệ thống và cách promote một slave lên thay thế master là gì?

Mặc định, Slave vẫn sẽ có binlog, và binlog này là của riêng slave chứ không giống với binlog của master (binlog của master khi đẩy qua slave sẽ thành relay-log), có nghĩa là nếu S1 đẩy lên làm master thì S2 sẽ không còn đồng bộ với S1 nữa và ta sẽ cần build lại S2.

Để giải quyết vấn đề này, mysql khuyến cáo chúng ta bật --skip-log-slave-updates trên Slave, chuyện này đảm bảo:

  • Slave vẫn sẽ có binlog nhưng với các hành vi apply relay-log (update dữ liệu như master) thì slave sẽ không ghi ra binlog.
  • Khi master chết, ta có nhu cầu promote S1 lên làm master, ta sẽ cần reset master của S2 trỏ về S1, tuy nhiên như ở trên ta sẽ cần chỉ định file binlog và position của file log, và do S1 sau khi đc đổi thành master thì mới bắt đầu sinh ra binlog, nên trên S2 ta chỉ cần trỏ về file binlog và position đầu tiên của S2 là đủ. => chuyện này đảm bảo rằng S2 sẽ đồng bộ dữ liệu với S1.

Sau khi việc promote hoàn thành, ta có thể cập nhật lại ở phía client địa chỉ củ a S1 và hoàn thành việc bảo trì hệ thống. Tuy nhiên để ý là quá trình trên là thủ công và ta vẫn có downtime trong quá trình promote.

Tuy nhiên, điều trên chỉ đúng chỉ đúng khi slave sync với master trước khi master chết với second_behind_master = 0.

https://dev.mysql.com/doc/refman/8.0/en/replication-solutions-switch.html

7. Semi-synchronous

Có một vấn đề với asynchronous đó là nếu bạn có nhu cầu đọc ngay dữ liệu vừa ghi xuống thì có thể dữ liệu sẽ sai, do slave chưa kịp apply dữ liệu từ master (lag dữ liệu), có 2 cách giải quyết tạm:

  • Với trường hợp vừa ghi và đọc liền dữ liệu, ta nên dùng ở master.
  • Dùng cơ chế semi-synchronous để giảm lag dữ liệu.

Semi-synchronous là một kiểu lai giữa asynchronous và synchronous. Bình thường nếu xài synchronous thì càng nhiều slave thì càng giảm tốc độ ghi dữ liệu, do slave phải committed và trả lời ngược về master. Với semi-synchronous thì master coi như ghi thành công là khi có tối thiểu một slave đã nhận và ghi ra relay log event mà master gửi qua. Điểm khác biệt là không cần tất cả các slave gửi tín hiệu ngược lại master, và event cũng không bắt buộc phải được execute và commited trên slave, chỉ cần đảm bảo là đã nhận và ghi ra relay log là đủ.

Như mô tả ở trên thì slave vẫn có thể không có dữ liệu nếu relay log bị tác động với con người, hoặc server bị hỏng ngay khi chưa kịp apply relay log, tuy nhiên nhờ việc đảm bảo binlog event đã đc nhận với slave và ghi xuống đĩa đã làm giảm thời gian delay và vấn đề về data race condition có thể được hạn chế phần nào.