Skip to main content

Μεταφορα απο 20.04 σε 24.04 - steps

Τι τρεχει στο παλιο σερβερ και πρεπει να μεταφερθει

  1. database server & main app για διαχειριση mydata δεδομενων
  2. ergani sync εργασιες (http://localhost:7000, /workers)
  3. salary εργασίες (http://localhost:7001, /salary)
  4. notification για ληξη ssl, λιγος χωρος κτλπ (server monitoring)

Στησιμο νεου σερβερ 178.105.43.239

  1. install mysql [X]
  2. secure mysql και ρυθμιση mysql παραμετρων να δειχνουμε το datadir στον μεγαλο σκληρο (2TB) [X]
  3. στησιμο apache2 με ρυθμισεις απο το προηγουμενο σερβερ 
    1. Ο προηγουμενος σερβερ ετρεχε prefork με τις παρακατω ρυθμισεις <IfModule mpm_prefork_module>
      ServerLimit 250
      StartServers 10
      MinSpareServers 5
      MaxSpareServers 10
      MaxRequestWorkers 150
      MaxConnectionsPerChild 0
      MaxConnectionsPerChild 10000
      </IfModule>
    2. Ο καινουργιος σερβερ δε θα τρεχει prefork αλλα να εχουμε υποψιν τα ορια που μπηκαν [X]
  4.  στησιμο SSL
  5. να ξεκινησουνε τα services του 7000, 70017001[X]
  6. ρυθμιση σωστης ωρας [X]
  7. Στησιμο modsecurity [OPTIONAL] (ο προηγουμενος δεν ειχε)
  8. install gunicorn [X]
  9. install php [X]
  10. install php modules used in server [X]
  11. install cronjobs from previous server

Replication φαση

1. Step-by-Step Configuration

Πρέπει πρώτα να αλλάξουμε τον main server για να εχει bind-address: 0.0.0.0 ωστε να μπορει να γινει το replication. Επισης για να γινει self-healing το replcaiton ειναι προτιμοτερο να τρεχει με GTIDs:

# Enable GTID mode 
gtid_mode = ON

 
# Ensure only GTID-safe statements are allowed 
enforce_gtid_consistency = ON 

# Required for GTIDs to work with replication

log_bin = mysql-bin

log_slave_updates = ON

Ο λόγος που ειναι καλυτερα τα GTIDs (https://gemini.google.com/share/aac5bf6e69e6) επισης δεν χρειαζεται να βαζουμε καθολου τα replication positions που κανει τη διαδικασια πιο ασφαλες

Phase A: Prepare the Donor (Primary)

Log into your Primary server and run:

SQL 
-- Install the plugin
INSTALL PLUGIN clone SONAME 'mysql_clone.so';

-- Create a replication user with cloning permissions
CREATE USER 'clone_user'@'%' IDENTIFIED BY 'password';
GRANT BACKUP_ADMIN ON *.* TO 'clone_user'@'%';

Phase B: Prepare the Recipient (Replica)

Log into your New Replica server and run:

SQL 
-- Install the plugin
INSTALL PLUGIN clone SONAME 'mysql_clone.so';

-- Allow the recipient to be overwritten by the donor
SET GLOBAL clone_valid_donor_list = 'primary-ip-address:3306';

Phase C: Execute the Clone

On the Recipient server, trigger the data transfer. Warning: This will delete all existing data on the recipient and restart the MySQL service automatically after completion.

SQL 
CLONE INSTANCE FROM 'clone_user'@'primary-ip-address':3306 IDENTIFIED BY 'password';

3. Completing the Replication

The beauty of the Clone plugin is that it automatically captures the Binary Log coordinates (GTID or filename/position) during the transfer.

Once the recipient restarts, log back in and check the status:

SQL 
SELECT BINLOG_FILE, BINLOG_POS FROM performance_schema.clone_status;

Option 1: If using GTIDs (Recommended)

If your primary uses GTIDs, replication might start automatically or simply require:

SQL 
CHANGE REPLICATION SOURCE TO 
    SOURCE_HOST='primary-ip-address', 
    SOURCE_USER='repl_user', 
    SOURCE_PASSWORD='password', 
    SOURCE_AUTO_POSITION=1;
START REPLICA;

Option 2: If using Binary Log Position

SQL 
-- Use the coordinates found in performance_schema.clone_status
CHANGE REPLICATION SOURCE TO 
    SOURCE_HOST='primary-ip-address', 
    SOURCE_USER='repl_user', 
    SOURCE_PASSWORD='password', 
    SOURCE_LOG_FILE='binlog.00000X', 
    SOURCE_LOG_POS=123;
START REPLICA;

Back to top