Skip to content

MariaDB - Replication

MariaDB
  • Wer hier fleißig mit liest, weiß das ich Redis schon lange repliziere. Dazu läuft halt woanders ein Slave, der im Idealfall den selben Datenstand hat wie der Master. Da hier keine finanziellen Transaktionen stattfinden, reicht mir das persönlich.

    Da ich ja mit dem Umzug zu Proxmox, ein wenig mein System geändert habe, gibt es jetzt für verschiedene Aufgaben eigene VMs. So kann ich das hoffentlich besser warten. Das war zuletzt doch auf meinem überladenen Root, für mich immer schwerer geworden. Auch der Grund warum ich aufgeräumt habe. Aber, ich komme vom Thema ab 🙂

    Die Replication werde ich heute nicht mehr angehen, aber ich möchte hier schon mal festhalten was ich dann vermutlich morgen umsetzen werde.

    Installation

    Die Anleitung von MariaDB findet man hier.

    Master

    In my.cnf folgendes eintragen, danach MariaDB neustarten.

    [mariadb]
    log-bin
    server_id=1
    log-basename=master1
    

    Neustarten

    service mysql restart
    

    Slave

    Installation

     apt install mariadb-server
    

    In my.cnf

    server_id=2
    

    eintragen. Neustarten!

    Binary Log Position

    Nun müssen wir eine Position ermitteln. Ich kopiere dazu mal eben flott den Teil aus der Anleitung 😉

    Now you need prevent any changes to the data while you view the binary log position. You'll use this to tell the slave at exactly which point it should start replicating from.

    • On the master, flush and lock all tables by running FLUSH TABLES WITH READ LOCK. Keep this session running - exiting it will release the lock.
    • Get the current position in the binary log by running SHOW MASTER STATUS:
    SHOW MASTER STATUS;
    +--------------------+----------+--------------+------------------+
    | File               | Position | Binlog_Do_DB | Binlog_Ignore_DB |
    +--------------------+----------+--------------+------------------+
    | mariadb-bin.000096 |      568 |              |                  |
    +--------------------+----------+--------------+------------------+
    
    • Record the File and Position details. If binary logging has just been enabled, these will be blank.

    • Now, with the lock still in place, copy the data from the master to the slave. See Backup, Restore and Import for details on how to do this.

    • Note for live databases: You just need to make a local copy of the data, you don't need to keep the master locked until the slave has imported the data.

    • Once the data has been copied, you can release the lock on the master by running UNLOCK TABLES.

    UNLOCK TABLES;
    

    Quelle: https://mariadb.com/kb/en/library/setting-up-replication/

    Datenbank sichern

    Installation

    apt install mariadb-backup
    

    Mit diesem Tool sichern wir die komplette Datenbank, die DB auf dem Master ist immer noch im Status LOCKED! Damit das möglich ist, muss in der DB ein User existieren.

    CREATE USER 'mariabackup'@'localhost' IDENTIFIED BY 'mypassword';
    GRANT RELOAD, PROCESS, LOCK TABLES, REPLICATION CLIENT ON *.* TO 'mariabackup'@'localhost';
    

    Der Befehl zum Sichern der DB sieht dann so aus.

     mariabackup --backup \
        --target-dir=/var/mariadb/backup/ \
        --user=mariabackup --password=mypassword
    

    Wenn ich das oben alles richtig verstanden habe, kann ich jetzt den Status LOCKED der DB auf dem Master entfernen. Die Daten sind jetzt gesichert, wir kennen die Position. Ab hier holt sich der SLAVE dann von alleine die Daten.

    Quelle: https://mariadb.com/kb/en/library/mariabackup-overview/

    Starten des Slave

    Hier der Auszug aus der Anleitung.

    Once the data has been imported, you are ready to start replicating. Begin by running a CHANGE MASTER TO, making sure that MASTER_LOG_FILE matches the file and MASTER_LOG_POS the position returned by the earlier SHOW MASTER STATUS. For example:

    CHANGE MASTER TO
    MASTER_HOST='master.domain.com',
    MASTER_USER='replication_user',
    MASTER_PASSWORD='bigs3cret',
    MASTER_PORT=3306,
    MASTER_LOG_FILE='mariadb-bin.000096',
    MASTER_LOG_POS=568,
    MASTER_CONNECT_RETRY=10;
    

    If you are starting a slave against a fresh master that was configured for replication from the start, then you don't have to specify MASTER_LOG_FILE and MASTER_LOG_POS.

    Use Global Transaction Id (GTID)

    MariaDB starting with 10.0

    MariaDB 10.0 introduced global transaction IDs (GTIDs) for replication. It is generally recommended to use (GTIDs) from MariaDB 10.0, as this has a number of benefits. All that is needed is to add the MASTER_USE_GTID option to the CHANGE MASTER statement, for example:

    CHANGE MASTER TO MASTER_USE_GTID = slave_pos
    

    See Global Transaction ID for a full description.

    • Now start the slave with the START SLAVE command:
    START SLAVE;
    
    • Check that the replication is working by executing the SHOW SLAVE STATUS command:

      SHOW SLAVE STATUS \G
      
    • If replication is working correctly, both the values of Slave_IO_Running and Slave_SQL_Running should be Yes:

      Slave_IO_Running: Yes
      Slave_SQL_Running: Yes
      

    Eine Menge Stoff zum Ausprobieren 🙂 Liest sich aber alles logisch nachvollziehbar. Wenn es denn dann auf dem Server auch rund läuft, sollte das ja Morgen erledigt sein. Aktuell ist mir das jetzt zu spät, da sollte man auf dem Server nichts mehr schrotten 🙂

    Ich werde das hier morgen ausführlich erweitern, und berichten, wie es mir so ergangen ist.

  • Fangen wir mal mit dem Testen von mariabackup an. Die Installation wie oben erledigt.

    Dann mal ein Backup zum Testen angelegt.

    mariabackup --backup \
       --target-dir=/root/mariadb/backup/ \
       --user=mariabackup --password=mypassword
    

    Das klappt so weit problemlos.

    [00] 2019-09-05 18:13:14 Connecting to MySQL server host: localhost, user: mariabackup, password: set, port: not set, socket: /var/run/mysqld/mysqld.sock
    [00] 2019-09-05 18:13:14 Using server version 10.3.15-MariaDB-1
    mariabackup based on MariaDB server 10.3.15-MariaDB debian-linux-gnu (x86_64)
    [00] 2019-09-05 18:13:14 uses posix_fadvise().
    [00] 2019-09-05 18:13:14 cd to /var/lib/mysql/
    [00] 2019-09-05 18:13:14 open files limit requested 0, set to 1024
    [00] 2019-09-05 18:13:14 mariabackup: using the following InnoDB configuration:
    [00] 2019-09-05 18:13:14 innodb_data_home_dir = 
    [00] 2019-09-05 18:13:14 innodb_data_file_path = ibdata1:12M:autoextend
    [00] 2019-09-05 18:13:14 innodb_log_group_home_dir = ./
    [00] 2019-09-05 18:13:14 InnoDB: Using Linux native AIO
    2019-09-05 18:13:14 0 [Note] InnoDB: Number of pools: 1
    [00] 2019-09-05 18:13:14 mariabackup: Generating a list of tablespaces
    2019-09-05 18:13:14 0 [Warning] InnoDB: Allocated tablespace ID 266 for joomla/xxxxx_action_log_config, old maximum was 0
    [00] 2019-09-05 18:13:14 >> log scanned up to (2019250097)
    [01] 2019-09-05 18:13:14 Copying ibdata1 to /root/mariadb/backup/ibdata1
    [01] 2019-09-05 18:13:14         ...done
    [01] 2019-09-05 18:13:14 Copying ./joomla/xxxxx_action_log_config.ibd to /root/mariadb/backup/joomla/lbwv2_action_log_config.ibd
    [01] 2019-09-05 18:13:14         ...done
    [01] 2019-09-05 18:13:14 Copying ./joomla/xxxxx_action_logs_users.ibd to /root/mariadb/backup/joomla/lbwv2_action_logs_users.ibd
    [01] 2019-09-05 18:13:14         ...done
    [01] 2019-09-05 18:13:14 Copying ./joomla/xxxxx_finder_links_terms3.ibd to /root/mariadb/backup/joomla/lbwv2_finder_links_terms3.ibd
    [01] 2019-09-05 18:13:14         ...done
    ...[gekürzt]
    [00] 2019-09-05 18:13:20 mariabackup: The latest check point (for incremental): '2019255092'
    mariabackup: Stopping log copying thread.[00] 2019-09-05 18:13:20 >> log scanned up to (2019255101)
    
    [00] 2019-09-05 18:13:20 >> log scanned up to (2019255101)
    [00] 2019-09-05 18:13:20 Executing UNLOCK TABLES
    [00] 2019-09-05 18:13:20 All tables unlocked
    [00] 2019-09-05 18:13:20 Copying ib_buffer_pool to /root/mariadb/backup/ib_buffer_pool
    [00] 2019-09-05 18:13:20         ...done
    [00] 2019-09-05 18:13:20 Backup created in directory '/root/mariadb/backup/'
    [00] 2019-09-05 18:13:20 Writing backup-my.cnf
    [00] 2019-09-05 18:13:20         ...done
    [00] 2019-09-05 18:13:20 Writing xtrabackup_info
    [00] 2019-09-05 18:13:20         ...done
    [00] 2019-09-05 18:13:20 Redo log (from LSN 2019250088 to 2019255101) was copied.
    [00] 2019-09-05 18:13:20 completed OK!
    

    Nun habe ich wieder ein paar Fragen mehr, erst mal sacken lassen... 🤔

  • Ok, den Slave eingerichtet. Verbindung getestet. So weit ist jetzt alles fertig um die Daten vom Master zum Slave zu transportieren und dann die Replication zu starten. Ich bin gespannt 😉

  • Erster Versuch

    MariaDB [(none)]> SHOW SLAVE STATUS \G;
    *************************** 1. row ***************************
                    Slave_IO_State: Waiting for master to send event
                       Master_Host: 192.168.0.101
                       Master_User: user
                       Master_Port: 3306
                     Connect_Retry: 10
                   Master_Log_File: master1-bin.000001
               Read_Master_Log_Pos: 19751580
                    Relay_Log_File: mysqld-relay-bin.000002
                     Relay_Log_Pos: 362735
             Relay_Master_Log_File: master1-bin.000001
                  Slave_IO_Running: Yes
                 Slave_SQL_Running: No
    

    Diese beiden Zeilen müssen jeweils auf YES stehen, dann ist alles ok.

    Slave_IO_Running: Yes
    Slave_SQL_Running: No
    

    Ok, der erste Versuch war für die Tonne 🙂 Zum Glück weiß ich evt. warum. Auf ein Neues 🙂

  • Ein Traum wie einfach das mit Redis machbar ist. Ich bekomme es nicht hin, dann mal jetzt ein Break und abschalten 😉

  • Ich habe das Thema mal beerdigt. Vermutlich reichen meine Kenntnisse dafür nicht aus, obwohl ich alles nach Anleitung gemacht habe. Auch eine Recherche im Internet hat mich nicht weiter gebracht. Ich liebe Redis 🙂

    Ok, machen wir es mit mariabackup 🙂 Sollte für meinen Anwendungsfall auch völlig ausreichend sein.

  • MariaDB - Wireguard

    MariaDB
    1
    0 Stimmen
    1 Beiträge
    237 Aufrufe
    Niemand hat geantwortet
  • MariaDB - Ein paar Befehle

    MariaDB
    1
    0 Stimmen
    1 Beiträge
    236 Aufrufe
    Niemand hat geantwortet
  • MariaDB - LXC Container

    MariaDB
    2
    0 Stimmen
    2 Beiträge
    563 Aufrufe
    FrankMF

    Link Preview Image [SOLVED] - Proxmox Debian 10 Buster Template and mariadb

    I don't know is this a good place to post a bug: I created CT with template debian-10 and then installed mariadb. root@dev1:/var/www/html/dev/include#...

    favicon

    Proxmox Support Forum (forum.proxmox.com)

  • Optimales Filesystem für mariadb 10.3

    MariaDB
    2
    0 Stimmen
    2 Beiträge
    237 Aufrufe
    FrankMF

    Hallo @webstudio ,

    sehr spannendes Thema, wo ich jetzt nicht der Experte drin bin.

    Meine Erfahrungen mit BTRFS kann man hier irgendwo nachlesen, ich hatte da auch so meine Probleme mit. Somit bin ich wieder zurück auf "normalem" ext4.

    MariaDB nutze ich auch, auf meinem Test-Webserver und auch hier irgendwo auf dem Root. Kann da jetzt nichts zu sagen, funktioniert. Mir fehlen aber da tiefer gehende Erkenntnisse. Ich kann sie einrichten, absichern (hoffentlich nix vergessen) und bedienen. Arbeite aber auch nicht mit solchen Datenmengen.

    Vielleicht liest jemand mit, der das nötige Fachwissen besitzt.

  • MariaDB Datenbank wiederherstellen

    MariaDB
    1
    0 Stimmen
    1 Beiträge
    238 Aufrufe
    Niemand hat geantwortet
  • MariaDB Datenbank sichern

    MariaDB
    2
    0 Stimmen
    2 Beiträge
    294 Aufrufe
    FrankMF
    SQL Dump erzeugen mysqldump -u username -p database > /home/frank/database.sql
  • MariaDB installieren

    Verschoben MariaDB
    1
    0 Stimmen
    1 Beiträge
    599 Aufrufe
    Niemand hat geantwortet