mariadb-dump ile Yedekleme ve Geri Yükleme

mariadb-dump ne üretir?

Belgeler yedekleri ikiye ayırır. Mantıksal yedek, verinin yeniden oluşturulması için gereken SQL ifadelerinden oluşur. Fiziksel yedek ise veri dizinindeki dosyaların kopyalanmasıdır. mariadb-dump mantıksal yedek alır. Bu yüzden ürettiği dosya farklı donanıma, farklı bir MariaDB sürümüne, hatta sürüme özgü ifade içermiyorsa başka bir veritabanı sistemine aktarılabilir. Bedeli de vardır: mantıksal yedek eşdeğer fiziksel yedekten daha büyüktür, hem alınması hem geri yüklenmesi daha uzun sürer ve günlük dosyaları ile yapılandırma dosyaları yedeğe girmez.

Aracın eski adı mysqldump'tır ve Linux'ta bu ad bir sembolik bağ olarak hâlâ çalışabilir. Belgeler, MariaDB 11.0'dan itibaren mysqldump sembolik bağının kullanımdan kaldırılmak üzere işaretlendiğini ve resmî mariadb Docker imajından çıkarıldığını belirtir. Betiklerinizde doğrudan mariadb-dump adını kullanmak bu yüzden daha güvenlidir.

Bilmeniz gereken bir ayrıntı daha var: mariadb-dump, döküm dosyasının başına istemcinin sandbox (kum havuzu) kipini açan bir komut yazar. Bu kip, dosyanın içinden sistem komutu çalıştırma veya başka dosya okuma gibi dosya sistemine erişen istemci komutlarını engeller. Eski mariadb istemcileri ve MySQL'in mysql istemcisi bu komutu tanımadığı için hata verir. Dökümü başka bir istemciyle yüklemeniz gerekirse bu davranışı hesaba katın; başka içe aktarma yöntemleri bundan etkilenmez.

Dört çağırma biçimi

Belgeler aracın dört genel kullanım biçimini listeler. İlk biçimde ilk ad veritabanı, sonraki adlar tablo olarak yorumlanır. --databases (kısa hâli -B) verildiğinde bütün adlar veritabanı sayılır ve çıktıya her veritabanından önce CREATE DATABASE ile USE ifadeleri eklenir. --all-databases (-A) sunucudaki tüm veritabanlarını alır. --system ise mysql sistem veritabanındaki kullanıcı, eklenti, sunucu ve saat dilimi gibi bilgileri CREATE USER benzeri taşınabilir SQL ifadeleri olarak döker.

mariadb-dump [options] db_name [tbl_name ...]
mariadb-dump [options] --databases db_name ...
mariadb-dump [options] --all-databases
mariadb-dump [options] --system=[option_list]

--system seçeneğinin kabul ettiği değerler belgelerde all, users, plugins, udfs, servers, stats ve timezones olarak geçer. Kullanıcı hesaplarını başka bir sunucuya taşırken --system=users ham mysql tablolarını kopyalamaktan daha temiz bir yoldur. INFORMATION_SCHEMA ve etkinse PERFORMANCE_SCHEMA varsayılan olarak dökülmez; INFORMATION_SCHEMA'yı açıkça adlandırırsanız dökülür ama bu durumda --skip-lock-tables da vermeniz gerekir.

Tek bir veritabanının belirli tablolarını almak için --databases kullanılmaz; önce veritabanı adı, ardından tablo adları yazılır. Aşağıdaki üç komut belgelerdeki rehberden uyarlanmıştır: ilki tüm sunucuyu, ikincisi iki veritabanını, üçüncüsü bir veritabanındaki iki tabloyu yedekler.

mariadb-dump --user=admin_backup --password --single-transaction --all-databases > /data/backup/tum.sql
mariadb-dump --user=admin_backup --password --single-transaction --databases magaza blog > /data/backup/magaza_blog.sql
mariadb-dump --user=admin_backup --password --single-transaction magaza siparis musteri > /data/backup/magaza_tablolar.sql

--password değer almadan yazıldığında parola sorulur. Betiklerde --password=parola biçimi de çalışır, ancak belgelerin uyardığı gibi parola bu durumda komut geçmişinde ve betik dosyasında görünür. Daha temiz yol, parolayı izinleri kısıtlanmış bir seçenek dosyasına yazmaktır. mariadb-dump seçenek dosyalarında [mysqldump], [mariadb-dump], [client], [client-server] ve [client-mariadb] gruplarını okur. Seçenek dosyalarının okunma sırası my.cnf yapılandırma dosyaları yazısında anlatılıyor.

[mariadb-dump]
user=admin_backup
password=cok_gizli_parola

Yedek kullanıcısı ve gereken yetkiler

Yedeği root ile almak yerine yalnızca gereken yetkilere sahip ayrı bir kullanıcı açmak iyi bir alışkanlıktır. Belgelerdeki rehbere göre dökülen tablolar için en az SELECT yetkisi gerekir; --lock-tables kullanılıyorsa LOCK TABLES, --flush-logs veya --master-data gibi seçenekler için RELOAD ya da FLUSH_TABLES, --single-transaction için de PROCESS ve RELOAD gerekebilir. Rehber, yedek için sık kullanılan bir hesabın genel SELECT, LOCK TABLES, SHOW VIEW, EVENT ve TRIGGER yetkilerine sahip olduğunu söyler. --routines seçeneği ayrıca mysql.proc tablosunda SELECT yetkisi ister.

CREATE USER 'admin_backup'@'localhost' IDENTIFIED BY 'cok_gizli_parola';
GRANT SELECT, LOCK TABLES, SHOW VIEW, EVENT, TRIGGER ON *.* TO 'admin_backup'@'localhost';

Kullanıcı oluşturma ve yetki verme ayrıntıları için CREATE USER ve GRANT ve REVOKE yazılarına bakabilirsiniz. Hesabı localhost ile sınırlamak, yedeğin yalnızca sunucunun kendisinden alınabilmesini sağlar.

Tutarlı yedek: --single-transaction, --lock-tables, --lock-all-tables

Yedek alınırken uygulama yazmaya devam ediyorsa, farklı tablolar farklı anlarda okunur ve dosya mantıksal olarak tutarsız olabilir. mariadb-dump bu sorunu üç farklı yolla ele alır ve doğru seçim tablolarınızın depolama motoruna bağlıdır.

--single-transaction, veriyi dökmeden önce sunucuya bir START TRANSACTION gönderir. InnoDB gibi işlemsel tablolarda bu sayede işlemin başladığı andaki tutarlı görüntü okunur ve uygulamalar engellenmez. Belgeler önemli sınırları da açıkça yazar: yalnızca InnoDB tabloları tutarlı dökülür, MyISAM veya MEMORY tabloları döküm sırasında değişmeye devam edebilir. Döküm sürerken başka bir bağlantının ALTER TABLE, CREATE TABLE, DROP TABLE, RENAME TABLE veya TRUNCATE TABLE çalıştırmaması gerekir; tutarlı okuma bu ifadelerden yalıtılmadığı için tablo içeriği yanlış gelebilir ya da okuma başarısız olabilir. Büyük tablolar için belgeler bu seçeneği --quick ile birlikte kullanmayı önerir.

--lock-tables (-l), her veritabanı için dökülecek tabloları önce kilitler. Kilitleme veritabanı başına yapıldığı için farklı veritabanlarındaki tablolar birbirine göre tutarlı olmayabilir. Belgeler InnoDB için --single-transaction seçeneğinin çok daha iyi olduğunu, çünkü tabloları hiç kilitlemesi gerekmediğini vurgular. İki seçenek birbirini dışlar: LOCK TABLES bekleyen işlemleri örtük olarak sonlandırdığı için --single-transaction verildiğinde --lock-tables kendiliğinden kapanır.

--lock-all-tables (-x), döküm boyunca FLUSH TABLES WITH READ LOCK ile genel bir okuma kilidi alır. Karışık depolama motorlarında tutarlılık sağlar ama döküm süresince yazmalar bekler. Bu seçenek --single-transaction ve --lock-tables seçeneklerini kapatır. Belgelerdeki rehber kısa seçenek olarak -x'i --lock-tables ile birlikte anar; seçenek listesinde ise -x, --lock-all-tables, -l de --lock-tables karşılığıdır. Karışıklık yaşamamak için betiklerde uzun adları yazın.

--order-by-size seçeneği de bu bağlamda işe yarar. Belgelere göre tabloları küçükten büyüğe döker; sık kesilen ya da değiştirilen tabloların genelde küçük olduğu varsayımıyla, --single-transaction dökümünün 'Table definition has changed, please retry transaction' hatasıyla başarısız olma ihtimalini azaltır. Bu seçenek MariaDB 10.9.1'den itibaren vardır.

--opt ve varsayılan davranış

--opt bir kısaltmadır ve varsayılan olarak açıktır. Belgelere göre --add-drop-table, --add-locks, --create-options, --quick, --extended-insert, --lock-tables, --set-charset ve --disable-keys seçeneklerinin hepsini birden açar. Yani hiçbir şey yazmasanız da dosyanızdaki her CREATE TABLE öncesinde bir DROP TABLE bulunur, satırlar çok satırlı INSERT ifadeleriyle yazılır ve satırlar belleğe toplanmadan teker teker okunur.

--quick özellikle önemlidir: aracı satırları sunucudan tek tek alıp doğrudan çıktıya yazmaya zorlar. Kapatırsanız (--skip-quick) tablonun tamamı önce belleğe alınır ve büyük tablolarda bellek sorunu çıkabilir. --extended-insert daha küçük dosya ve daha hızlı geri yükleme sağlar; her satırın ayrı bir INSERT olmasını istiyorsanız (örneğin dosyayı satır satır karşılaştırmak için) --skip-extended-insert kullanırsınız. --compact ise yorumları, DROP TABLE satırlarını, kilit ifadelerini ve SET NAMES satırını kaldırarak okunması kolay ama geri yüklemede daha az koruyucu bir çıktı üretir.

Grup seçenekleriyle oynarken sıra önemlidir, çünkü seçenekler soldan sağa işlenir. Belgelerdeki örneğe göre --disable-keys --lock-tables --skip-opt yazarsanız son seçenek öncekileri ezer ve sonuç yalnızca --skip-opt ile aynı olur. Önce grubu kapatıp sonra istediklerinizi tek tek açmanız gerekir.

Saklı yordamlar, olaylar ve tetikleyiciler

Sık atlanan bir nokta: tetikleyiciler tablo tanımının parçası sayıldığı için varsayılan olarak dökülür (--triggers açıktır, --skip-triggers ile kapatılır). Saklı yordamlar ve olaylar ise dökülmez. Bunları da almak için --routines (-R) ve --events (-E) eklemeniz gerekir. Saklı yordam ya da zamanlanmış olay kullanan bir uygulamanın yedeğini bu seçenekler olmadan alırsanız, geri yükledikten sonra yordamların eksik olduğunu fark edersiniz.

Belgeler --routines için bir ayrıntıya dikkat çeker: üretilen CREATE PROCEDURE ve CREATE FUNCTION ifadeleri yordamın oluşturulma ve değiştirilme zaman damgalarını içermez, geri yüklenen yordamlar yükleme anının tarihini alır. Özgün zaman damgaları gerekiyorsa mysql.proc tablosunu doğrudan dökmeniz gerekir.

Sistem sürümlü tablolarda da benzer bir tuzak vardır. Temporal tablolar geçmiş satırları saklar, fakat mariadb-dump bu satırları varsayılan olarak yazmaz. Geçmişi de yedeğe katmak için --dump-history (-H) seçeneği gerekir; belgelere göre bu seçenek MariaDB 10.11'den beri vardır.

mariadb-dump --single-transaction --routines --events --databases magaza > /data/backup/magaza_tam.sql

Seçici yedek: yalnızca şema, bazı tablolar, bazı satırlar

Her zaman bütün veriye ihtiyacınız olmaz. --no-data (-d) yalnızca CREATE TABLE ifadelerini yazar; boş bir test ortamı kurmak ya da şemayı sürüm kontrolüne eklemek için kullanışlıdır. --no-create-info (-t) tersini yapar ve yalnızca veriyi yazar. --ignore-table=veritabani.tablo bir tabloyu tamamen dışarıda bırakır ve her tablo için ayrı ayrı tekrarlanır. --ignore-table-data ise tablonun yapısını alır ama verisini almaz; büyük günlük ya da oturum tabloları için idealdir. --ignore-database yalnızca --all-databases ile birlikte etkilidir.

--where (-w) ile yalnızca belirli koşulu sağlayan satırlar alınır. Koşul boşluk veya kabuğa özel karakter içeriyorsa tırnak içine alınmalıdır. MariaDB 12.1'den itibaren --wildcards (-L) seçeneği tablo ya da veritabanı adlarında joker karakter kullanmaya izin verir: --databases olmadan joker yalnızca tablo adlarında, --databases ile birlikte veritabanı adlarında tanınır.

mariadb-dump --no-data --databases magaza > /data/backup/magaza_sema.sql
mariadb-dump --single-transaction --ignore-table-data=magaza.oturum --databases magaza > /data/backup/magaza_oturumsuz.sql
mariadb-dump --single-transaction --where="durum = 'acik'" magaza siparis > /data/backup/acik_siparisler.sql

Geri yükleme

mariadb-dump yalnızca dosya üretir; geri yükleme mariadb komut satırı istemcisi ile yapılır. Dosyadaki SQL ifadeleri sırayla çalıştırılır. --databases ya da --all-databases ile alınmış bir dosya kendi CREATE DATABASE ve USE satırlarını içerdiğinden veritabanı adı vermeden yüklenebilir. Tek veritabanı biçimiyle alınmış bir dosyada bu satırlar yoktur; hedef veritabanını önce oluşturup komut satırında adını vermeniz gerekir.

mariadb --user=admin --password < /data/backup/magaza_blog.sql
mariadb --user=admin --password magaza < /data/backup/magaza_tablolar.sql
mariadb -e "source /data/backup/magaza_tablolar.sql" magaza

Geri yüklemeden önce iki uyarıyı aklınızda tutun. Birincisi, dosya DROP TABLE ve CREATE TABLE içeriyorsa (varsayılan --opt ile içerir) aynı adlı mevcut tablolar silinip yeniden oluşturulur ve yedekten sonra eklenen veriler kaybolur. İkincisi, yedek birkaç günlükse hepsini yüklemek, yalnızca küçük bir kısmı bozulmuş olsa bile ilgili tabloların tamamını eski hâline döndürür. Belgeler bu yüzden mümkünse önce üretim dışı bir ortamda denemeyi önerir.

Tam bir dökümden yalnızca tek tabloyu geri almak için belgelerdeki rehber ilginç bir yöntem anlatır: geçici bir kullanıcı açılır, bu kullanıcıya veritabanında yalnızca SELECT, geri yüklenecek tabloda ise tüm yetkiler verilir. Ardından dosya bu kullanıcıyla ve --force ile yüklenir. Yetkisi olmayan tablolardaki ifadeler hata verip atlanır, hedef tablodaki ifadeler başarılı olur. İş bitince geçici kullanıcı silinir.

CREATE USER 'admin_restore_temp'@'localhost' IDENTIFIED BY 'gecici_parola';
GRANT SELECT ON magaza.* TO 'admin_restore_temp'@'localhost';
GRANT ALL PRIVILEGES ON magaza.siparis TO 'admin_restore_temp'@'localhost';

mariadb --user admin_restore_temp --password --force magaza < /data/backup/magaza_tam.sql

DROP USER 'admin_restore_temp'@'localhost';

Aynı aracı iki sunucu arasında veri taşımak için de kullanabilirsiniz. Belgelerdeki örnekte döküm doğrudan uzak sunucudaki istemciye borulanır ve ara dosya hiç oluşmaz:

mariadb-dump --opt magaza | mariadb --host=remote_host -C magaza

Binary log koordinatları ve zamana göre kurtarma

Bir dökümü geri yükledikten sonra yedekten sonraki değişiklikleri de geri getirmek istiyorsanız, dökümün binary log'un hangi noktasına karşılık geldiğini bilmeniz gerekir. --master-data seçeneği bu koordinatları dosyaya ekler: değer 1 (varsayılan) ise bir CHANGE MASTER komutu olarak, 2 ise aynı komut yorum satırı olarak yazılır. Belgeler bu seçeneğin --single-transaction ile birlikte kullanılabildiğini ve InnoDB tablolarında zamana göre kurtarmaya hazır, çevrimiçi bir yedek almanın pratik yolu olduğunu belirtir. --flush-logs eklerseniz döküm anında yeni bir binary log dosyasına geçilir; böylece yedekten sonraki değişiklikler temiz bir dosyada başlar.

mariadb-dump --all-databases --single-transaction --flush-logs --master-data=2 > /data/backup/tum_pitr.sql

--single-transaction ile birlikte kullanıldığında bile dökümün başında FLUSH TABLES WITH READ LOCK ile kısa süreli bir genel kilit alınır, koordinatlar okunur ve kilit bırakılır. Belgeler, o anda uzun süren güncelleme ifadeleri varsa sunucunun bunlar bitene kadar duraklayabileceğini not eder. Kısa ifadelerin olduğu sistemlerde bu ilk kilit genelde fark edilmez.

--gtid seçeneği --master-data veya --dump-slave ile birlikte verildiğinde koordinatları dosya adı ve konum yerine GTID biçiminde yazar; bu, yeni bir replika kurarken işinizi kolaylaştırır. Binary log'u yedekten sonraki değişiklikleri uygulamak için nasıl kullanacağınızı binary log ve PITR yazısında, dökümden replika kurmayı replikasyon kurulumu yazısında anlatıyoruz.

Performans ve büyük veritabanları

Belgelere göre mariadb-dump varsayılan olarak tek iş parçacığı kullanır ve fazla işlemci tüketmez, ama disk G/Ç yükü artabilir: döküm tablo tablo, sırayla yapıldığı için tam tablo taramaları ve bellekte olmayan sayfalar için çok sayıda okuma oluşur. Yedeği veritabanıyla aynı diske yazmak gereksiz rastgele G/Ç üretir. Belgeler yedeği ağ üzerindeki bir konuma almayı, ama normal trafiğin etkilenmemesi için ayrı bir ağ kartı kullanmayı önerir.

Mantıksal yedeğin InnoDB tampon havuzuna da bir etkisi vardır. Tam tablo taramaları, nadiren kullanılan sayfaları belleğe çekip sık kullanılanları dışarı itebilir. Belgeler bunun için innodb_old_blocks_time değerini artırmayı ya da yedekten önce innodb_buffer_pool_dump_now, sonra innodb_buffer_pool_load_now ile tampon havuzunu diske yazıp geri yüklemeyi önerir. Tampon havuzunun genel ayarları InnoDB performans ayarları yazısında.

Paralel döküm için iki seçenek vardır. --tab her tablo için bir .sql (tanım) ve bir .txt (veri) dosyası üretir; yalnızca sunucuyla aynı makinede çalışır ve FILE yetkisi ister. --parallel (-j) MariaDB 11.4.1'den itibaren yalnızca --tab ile birlikte kullanılır. MariaDB 11.5'ten itibaren gelen --dir ise --tab gibi çalışır ama --databases ve --all-databases ile de kullanılabilir ve her veritabanı için ayrı bir dizin açar. Bu biçimlerde veri dosyaları sekmeyle ayrılmış metin olduğu için geri yüklemede LOAD DATA ve mariadb-import devreye girer.

Windows'ta çıktıyı > ile yönlendirmek yerine --result-file (-r) kullanın; belgelere göre bu, satır sonlarının \r\n'ye dönüşmesini önler. Saat dilimi de bir başka ayrıntıdır: varsayılan olarak açık olan --tz-utc, bağlantının saat dilimini UTC yapar ve dosyanın başına SET TIME_ZONE='+00:00' ekler. Böylece farklı saat dilimlerindeki sunucular arasında TIMESTAMP değerleri kaymaz.

Uygulamalı örnek: gecelik yedek

Küçük bir VPS'te, InnoDB kullanan tek bir uygulama veritabanının gece yedeği için yukarıdaki parçaları birleştirelim. Kimlik bilgileri seçenek dosyasında, komut ise zamanlanmış bir görevde çalışır. Seçeneklerin her biri belgelerde tanımlandığı biçimde kullanılıyor: tutarlı görüntü için --single-transaction, yordamlar ve olaylar için --routines ile --events, sonradan zamana göre kurtarma için --master-data=2 (sunucuda binary log açık olmalıdır).

mariadb-dump --single-transaction --routines --events --master-data=2 --databases magaza > /data/backup/magaza-gece.sql
gzip /data/backup/magaza-gece.sql

Yedeğin gerçekten işe yaradığını görmenin tek yolu onu geri yüklemektir. Belgelerin önerdiği gibi dosyayı düzenli aralıklarla üretim dışı bir sunucuya yükleyin, tablo sayılarını ve önemli tabloların satır sayılarını kontrol edin. Sıkıştırılmış dosyayı yüklerken açıp istemciye borulamanız yeterlidir.

gunzip -c /data/backup/magaza-gece.sql.gz | mariadb --user=admin --password

Sık yapılan hatalar

• Saklı yordamları ve olayları unutmak: --routines ve --events vermezseniz bunlar yedekte olmaz; tetikleyiciler ise varsayılan olarak dökülür.
• InnoDB'de --lock-tables kullanmak: Tablolar gereksiz yere kilitlenir ve veritabanları arası tutarlılık yine garanti edilmez. InnoDB için --single-transaction seçin.
• Döküm sırasında DDL çalıştırmak: --single-transaction dökümü sürerken ALTER TABLE veya TRUNCATE TABLE çalışırsa içerik yanlış gelebilir ya da döküm başarısız olabilir. Şema değişikliklerini yedek penceresinin dışına alın.
• MyISAM tablolarının tutarlı olduğunu sanmak: --single-transaction yalnızca InnoDB tablolarını tutarlı döker; MyISAM ve MEMORY tabloları değişmeye devam eder.
• Tek veritabanı dökümünü veritabanı adı vermeden yüklemek: Bu biçimde CREATE DATABASE ve USE satırı yoktur; hedef veritabanını oluşturup adını komut satırında verin.
• Parolayı komut satırına yazmak: Belgelerin uyardığı gibi parola komut geçmişinde ve betikte açıkça durur. İzinleri kısıtlı bir seçenek dosyası kullanın.
• Yedeği hiç denememek: Geri yüklenmemiş bir yedeğin çalıştığından emin olamazsınız.

Sık Sorulan Sorular

mysqldump ile mariadb-dump aynı şey mi?

Evet, mysqldump aracın eski adıdır ve Linux'ta genelde sembolik bağ olarak durur. Belgeler bu sembolik bağın MariaDB 11.0'dan itibaren kullanımdan kaldırılmak üzere işaretlendiğini söyler; yeni betiklerde mariadb-dump adını kullanın.

Sunucuyu durdurmam gerekir mi?

Hayır. Belgelere göre yedek sunucu çalışırken alınabilir. InnoDB tablolarında --single-transaction ile uygulamalar engellenmeden tutarlı bir görüntü elde edilir; yalnızca başlangıçta koordinat okumak için kısa bir genel kilit alınabilir.

Kullanıcı hesaplarını nasıl yedeklerim?

--system=users seçeneği mysql veritabanındaki hesapları CREATE USER gibi taşınabilir ifadeler olarak döker. mysql veritabanını ham olarak döküyorsanız belgeler, yükleme sonrası yetkilerin etkin olması için --flush-privileges eklemeyi önerir.

Veritabanım çok büyük, ne yapmalıyım?

Belgeler mariadb-dump'ı veri görece küçükken en esnek seçenek olarak tanımlar; büyük veri kümelerinde dosya büyür ve geri yükleme uzar. Bu durumda fiziksel yedek alan mariadb-backup aracını değerlendirin ya da --tab ile --parallel seçeneklerini deneyin.

Marka adları sahiplerine aittir. Bu yazı bağımsız bir teknik rehberdir; adı geçen kuruluşlarla bayilik veya ortaklık ilişkisi bulunduğu anlamına gelmez.

İlgili içerikler: MariaDB öğrenme rehberi · mariadb-backup ile fiziksel yedek · Binary log ve PITR · Replikasyon kurulumu · LOAD DATA ve mariadb-import · Yedekleme stratejileri