ALTER TABLE, masayı kilitlemeden mi?

MySQL'de bir ALTER TABLE deyimi yaparken, tüm tablo, ifade süresi boyunca okuma kilitlidir (eşzamanlı okumalara izin verir, ancak eşzamanlı yazmaları yasaklar). Büyük bir masaysa, INSERT veya UPDATE ifadeleri çoooook uzun bir süre engellenebilir. Tablonun işlem boyunca hala güncellenebilir olmasını sağlayacak şekilde sütun eklemek gibi "sıcak değişiklik" yapmanın bir yolu var mı?

Çoğunlukla MySQL için bir çözümle ilgileniyorum, ancak MySQL bunu yapamazsa diğer RDBMS ile ilgilenirim.

Açıklığa kavuşturmak gerekirse, amacım fazladan bir tablo sütunu gerektiren yeni bir özellik üretime gönderildiğinde kesinti sürelerinden kaçınmaktır. Herhangi veritabanı şeması olacak hayatın bir gerçektir ki, zaman içinde değişebilir. Neden bu değişikliklerin kaçınılmaz olarak kesinti süresine yol açması gerektiğini kabul etmemiz gerektiğini anlamıyorum; bu sadece zayıf.

Diğer tek seçenek, birçok RDBMS sisteminin zaten yaptığını manuel olarak yapmaktır ...
- Yeni bir tablo oluştur

Daha sonra eski tablonun içeriğini bir seferde bir yığın üzerine kopyalayabilirsiniz. Her zaman kaynak tablodaki herhangi bir INSERT / UPDATE / DELETE konusunda dikkatli olun. (Bir tetikleyici tarafından yönetilebilir. Bu yavaşlamaya neden olsa da kilit değildir ...)

Bitirdiğinizde, kaynak tablonun adını değiştirin, ardından yeni tablonun adını değiştirin. Tercihen bir işlemde.

Bittiğinde, bu tabloyu kullanan saklı yordamları vb. Yeniden derleyin. Uygulama planları büyük olasılıkla artık geçerli olmayacak.

DÜZENLE:

Bu sınırlamanın biraz zayıf olduğuna dair bazı yorumlar yapılmıştır. Bu yüzden neden böyle olduğunu göstermek için ona yeni bir bakış açısı koyacağımı düşündüm ...

• Yeni bir alan eklemek, her satırda bir alanı değiştirmek gibidir.
• Alan Kilitleri, Satır kilitlerinden çok daha zor olurdu, masa kilitlerini boşverin.
  
  
• Aslında diskteki fiziksel yapıyı değiştiriyorsunuz, her kayıt hareket ediyor.
• Bu gerçekten Tüm tablodaki bir GÜNCELLEME gibidir, ancak daha fazla etkiyle ...

Percona, bunun yapılmasını sağlayan pt-online-schema-change adlı bir araç yapar .

Esasen tablonun bir kopyasını oluşturur ve yeni tabloyu değiştirir. Yeni tabloyu orijinal ile senkronize tutmak için, güncellemek için tetikleyiciler kullanır. Bu, yeni tablo arka planda hazırlanırken orijinal tabloya erişim sağlar.

Bu, yukarıda Dems tarafından önerilen yönteme benzer, ancak bunu otomatik bir şekilde yapar.

Araçlarından bazılarının bir öğrenme eğrisi vardır, yani veritabanına bağlanır, ancak bunu bir kez indirdiğinizde, sahip olunması gereken harika araçlardır.

Ör:

pt-online-schema-change --alter "ADD COLUMN c1 INT" D=db,t=numbers_are_friends

2009'dan bu soru. Şimdi MySQL bir çözüm sunuyor:

Çevrimiçi DDL (Veri Tanımlama Dili)

DDL (öncelikle ALTER TABLE) işlemleri sırasında InnoDB tablolarının performansını, eşzamanlılığını ve kullanılabilirliğini artıran bir özellik. Ayrıntılar için Bölüm 14.11, "InnoDB ve Çevrimiçi DDL" ye bakın.

Detaylar işlemin türüne göre değişiklik gösterir. Bazı durumlarda, ALTER TABLE devam ederken tablo eşzamanlı olarak değiştirilebilir. İşlem, bir tablo kopyası yapılmadan veya özel olarak optimize edilmiş bir tablo kopyası türü kullanılmadan gerçekleştirilebilir. Alan kullanımı innodb_online_alter_log_max_size yapılandırma seçeneği ile kontrol edilir.

DDL işlemi sırasında, tabloya erişimi tamamen engellemeyi (LOCK = EXCLUSIVE yan tümcesi), sorgulara izin verip DML'ye izin vermemeyi (LOCK = SHARED yan tümcesi) veya tam sorgu ve DML'ye izin vermeyi seçerek, performans ve eşzamanlılık arasındaki dengeyi ayarlamanıza olanak tanır. tabloya erişim (LOCK = NONE cümlesi). LOCK yan tümcesini atladığınızda veya LOCK = DEFAULT seçeneğini belirlediğinizde, MySQL işlemin türüne bağlı olarak mümkün olduğunca fazla eşzamanlılığa izin verir.

Tablonun yeni bir kopyasını oluşturmak yerine, mümkün olduğunda yerinde değişiklik yapmak, tablonun kopyalanması ve ikincil dizinlerin yeniden yapılandırılmasıyla ilişkili disk alanı kullanımında ve G / Ç ek yükünde geçici artışları önler.

Daha fazla bilgi için bkz. MySQL 5.6 Referans Kılavuzu -> InnoDB ve Çevrimiçi DDL .

Görünüşe göre çevrimiçi DDL, MariaDB'de de mevcut

Alternatif olarak, ALTER TABLE'ınızın eşzamanlı işlemleri engellemediğinden (kilit almadığından) emin olmak için ALTER ONLINE TABLE'ı kullanabilirsiniz. LOCK = NONE ile eşdeğerdir.

ALTER TABLE hakkında MariaDB KB

Facebook'un çevrimiçi şema değiştirme aracına bakın.

http://www.facebook.com/notes/mysql-at-facebook/online-schema-change-for-mysql/430801045932

Kalbin zayıflığı için değil; ama işi yapacak.

Bu bir seçenekse Postgres'i öneririm. Postgres ile, aşağıdaki prosedürlerde esasen kesinti olmaz:

• ALTER TABLE SÜTUN EKLE (sütun BOŞ olabilirse)
• ALTER TABLE DROP SÜTUN
• DİZİN OLUŞTUR (CONCURRENTLY CREATE INDEX kullanılmalıdır)
• DROP INDEX

Diğer bir harika özellik, çoğu DDL ifadesinin işlemsel olmasıdır, bu nedenle bir SQL işlemi içinde tüm bir geçiş yapabilirsiniz ve bir şeyler ters giderse, her şey geri alınır.

Yazdığım bu belki de diğer esasına ilişkin bazı daha fazla fikir tutabilir, biraz önce.

Diğer veritabanları hakkında soru sorduğunuz için, işte Oracle hakkında bazı bilgiler.

Oracle tablosuna bir NULL sütunu eklemek, yalnızca veri sözlüğünü güncellediği için çok hızlı bir işlemdir. Bu, çok kısa bir süre için masanın üzerinde özel bir kilit oluşturur. Bununla birlikte, depedant depolanan prosedürleri, görünümleri, tetikleyicileri vb. Geçersiz kılacaktır. Bunlar otomatik olarak yeniden derlenecektir.

Buradan gerekirse ONLINE maddesini kullanarak dizin oluşturabilirsiniz. Yine, sadece çok kısa veri sözlüğü kilitlenir. Dizine eklenecek şeyleri arayan tüm tabloyu okur, ancak bunu yaparken kimseyi engellemez.

Bir yabancı anahtar eklemeniz gerekiyorsa, bunu yapabilir ve Oracle'ın verilerin doğru olduğuna dair size güvenmesini sağlayabilirsiniz. Aksi takdirde, tüm tabloyu okuması ve yavaş olabilecek tüm değerleri doğrulaması gerekir (önce dizininizi oluşturun).

Yeni sütunun her satırına varsayılan veya hesaplanan bir değer koymanız gerekiyorsa, büyük bir güncelleme veya belki de yeni verileri dolduran küçük bir yardımcı program çalıştırmanız gerekir. Bu yavaş olabilir, özellikle sıralar çok büyürse ve artık bloklarına sığmazsa. Bu işlem sırasında kilitlenme yönetilebilir. Uygulamanızın halen çalışmakta olan eski sürümünün bu sütunu bilmemesi nedeniyle sinsi bir tetikleyiciye veya bir varsayılan belirtmeye ihtiyacınız olabilir.

Oradan, uygulama sunucularınızda kodun yeni sürümüne geçiş yapabilirsiniz ve kod çalışmaya devam eder. Sinsi tetiğinizi bırakın.

Alternatif olarak, bu tür şeyleri yapmak için tasarlanmış bir kara kutu olan DBMS_REDEFINITION'ı kullanabilirsiniz.

Tüm bunları test etmek o kadar zahmetli ki, büyük bir sürümü yayınladığımızda Pazar sabahı erken saatlerde bir kesinti yaşıyoruz.

Uygulama güncellemeleri yaparken veritabanınız için kesinti süresini karşılayamıyorsanız, yüksek kullanılabilirlik için iki düğümlü bir küme tutmayı düşünmelisiniz. Basit bir çoğaltma kurulumuyla, önerdiğiniz gibi neredeyse tamamen çevrimiçi yapısal değişiklikler yapabilirsiniz:

• tüm değişikliklerin pasif bir köle üzerinde kopyalanmasını bekleyin
• pasif köleyi aktif yönetici olarak değiştirin
• yapısal değişiklikleri eski ustaya yap
• değişiklikleri yeni ana makineden eski ana ana bilgisayara kopyala
• ana değiştirmeyi tekrar yapın ve yeni uygulama dağıtımını aynı anda yapın

Her zaman kolay değildir, ancak genellikle 0 kesinti ile çalışır! İkinci düğümün yalnızca pasif olması gerekmez, test etmek, istatistik yapmak veya geri dönüş düğümü olarak kullanılabilir. Altyapınız yoksa, tek bir makinede (iki MySQL örneğiyle) çoğaltma kurulabilir.

Hayır! MyISAM tablolarını kullanıyorsanız, en iyi anladığım kadarıyla sadece masa kilitleri yaparlar - kayıt kilitleri yoktur, sadece basitlik yoluyla her şeyi hiper hızlı tutmaya çalışırlar. (Diğer MySQL tabloları farklı şekilde çalışır.) Her durumda, tabloyu başka bir tabloya kopyalayabilir, değiştirebilir ve ardından farklılıklar için güncelleyerek onları değiştirebilirsiniz.

Bu o kadar büyük bir değişiklik ki, herhangi bir DBMS'nin onu destekleyeceğinden şüpheliyim. İlk etapta tablodaki verilerle bunu yapabilmek bir fayda olarak kabul edilir.

Geçici çözüm...

Diğer çözüm, yeni sütununuzla birlikte orijinal tablonun birincil anahtarını içeren başka bir tablo eklemek olabilir.

Birincil anahtarınızı yeni tabloya doldurun ve yeni tablonuzdaki yeni sütun için değerleri doldurun ve belirli işlemler için bu tabloya katılmak üzere sorgunuzu değiştirin ve ayrıca bu sütun değeri için ayrı ayrı eklemeniz, güncellemeniz gerekir.

Kesinti süresi elde edebildiğinizde, orijinal tabloyu değiştirebilir, DML sorgularınızı değiştirebilir ve daha önce oluşturulan yeni tablonuzu bırakabilirsiniz.

Aksi takdirde, percona'dan kümeleme yöntemi, çoğaltma, pt-çevrimiçi-şema aracı için gidebilirsiniz.

Innodb eklentisi kullanılarak, yalnızca ikincil dizinleri ekleyen veya çıkaran ALTER TABLE deyimleri "hızlı", yani tabloyu yeniden oluşturmadan yapılabilir.

Genel olarak konuşursak, MySQL'de herhangi bir ALTER TABLE, çok uzun bir zaman alabilen tüm tablonun yeniden oluşturulmasını içerir (yani, tabloda yararlı miktarda veri varsa).

ALTER TABLE ifadelerinin düzenli olarak yapılması gerekmeyecek şekilde uygulamanızı gerçekten tasarlamanız gerekiyor; Beklemeye hazır olmadığınız veya küçük tabloları değiştirmediğiniz sürece uygulamanın normal çalışması sırasında kesinlikle ALTER TABLE yapılmasını istemezsiniz.

İki yaklaşımdan birini tavsiye ederim:

1. Veritabanı tablolarınızı potansiyel değişiklikleri göz önünde bulundurarak tasarlayın. Örneğin, içerikteki veri alanlarını düzenli olarak değiştiren İçerik Yönetim Sistemleri ile çalıştım. Fiziksel veritabanı yapısını ilk CMS saha gereksinimlerini karşılayacak şekilde oluşturmak yerine, esnek bir yapıda inşa etmek çok daha iyidir. Bu durumda, esnek XML verilerini tutmak için bir blob metin alanı (örneğin varchar (max)) kullanma. Bu, yapısal değişiklikleri çok daha az sıklıkta yapar. Yapısal değişiklikler maliyetli olabilir, bu nedenle burada da maliyetin bir faydası vardır.

2. Sistem bakım süresine sahip olun. Sistem değişiklikler sırasında (aylık vb.) Çevrimdışı olur ve değişiklikler günün en yoğun trafiğe maruz kalan saatinde (örneğin, öğleden sonra 3-5: 00'da) planlanır. Değişiklikler, üretim sunumundan önce aşamalandırılır, bu nedenle duruş süreleri için iyi bir sabit pencere tahminine sahip olursunuz.

2a. Yedek sunuculara sahip olun, böylece sistem kesintiye uğradığında, tüm site kapanmaz. Bu, tüm siteyi kapatmadan güncellemelerinizi kademeli bir şekilde "yaymanıza" olanak tanır.

Seçenek 2 ve 2a uygun olmayabilir; bunlar yalnızca daha büyük siteler / işlemler için olma eğilimindedir. Ancak bunlar geçerli seçenekler ve burada sunulan tüm seçenekleri kişisel olarak kullandım.

Hala bunu okuyan biri varsa veya buraya gelirse, bu mongodb gibi bir NoSQL veritabanı sistemi kullanmanın en büyük yararıdır. Milyonlarca satır ve yüksek yazma içeren büyük bir tabloya ek özellikler için sütunlar veya dizinler eklemek için tabloyu değiştirirken aynı sorunu yaşadım. Sonunda çok uzun bir süre kilitlenecek ve bunu LIVE veritabanında yapmak kullanıcılarımızı hayal kırıklığına uğratacaktır. Küçük masalarda bundan kurtulabilirsiniz.

"Tablolarımızı değiştirmekten kaçınmak için tasarlamamız" gerektiğinden nefret ediyorum. Bugünün web sitesi dünyasında işe yaradığını sanmıyorum. İnsanların yazılımınızı nasıl kullanacağını tahmin edemezsiniz, bu yüzden kullanıcı geri bildirimlerine göre işleri hızla değiştirirsiniz. Mongodb ile, herhangi bir kesinti olmadan istediğiniz zaman "sütunlar" ekleyebilirsiniz. Onları gerçekten eklemiyorsunuz, sadece yeni sütunlarla veri eklersiniz ve otomatik olarak yapar.

Kontrol etmeye değer: www.mongodb.com

Genel olarak cevap "Hayır" olacaktır. Tablonun yapısını değiştiriyorsunuz, bu da potansiyel olarak çok fazla güncelleme gerektirecektir "ve kesinlikle buna katılıyorum. Bunu sık sık yapmayı düşünüyorsanız," kukla "sütunlara bir alternatif sunacağım - VIEWbunun yerine s kullanın için tabloların SELECTverileri ing. IIRC, bir görünüm tanımını değiştirme nispeten hafiftir ve sorgu planı derlenmiş bir görünümü aracılığıyla dolaylı söz yapılır. gider yeni bir tabloya sütun eklemek ve yapmak zorunda olduğunu ifade etti JOINsütunda görünüm .

Elbette bu, yalnızca silme işlemlerinin basamaklandırılması ve başka şeyler yapmak için yabancı anahtarlar kullanabiliyorsanız işe yarar. Diğer bonus, verilerin bir kombinasyonunu içeren yeni bir tablo oluşturabilmeniz ve müşteri kullanımını bozmadan görünümü ona yönlendirebilmenizdir.

Sadece bir düşünce.

Bu bakımdan Postgres ve MySQL arasındaki fark, Postgres'te bir tabloyu yeniden oluşturmaması, Oracle'a benzer veri sözlüğünü değiştirmesidir. Bu nedenle, işlem hızlıdır, ancak yine de yukarıda başkaları tarafından belirtildiği gibi çok kısa bir süre için özel bir DDL tablo kilidi tahsis etmek gerekir.

MySQL'de işlem, işlemleri bloke ederken verileri yeni bir tabloya kopyalayacaktır; bu, v. 5.6'dan önceki MySQL DBA'ları için temel sorun olmuştur.

İyi haber şu ki, MySQL 5.6 sürümünden bu yana kısıtlama çoğunlukla kaldırıldı ve artık MYSQL DB'nin gerçek gücünden yararlanabilirsiniz.

SeanDowney'in bahsettiği gibi, buradaki soruda anlattıklarınızı pt-online-schema-changeyapmak için en iyi araçlardan biridir. Son zamanlarda canlı bir DB'de birçok şema değişikliği yaptım ve oldukça iyi gitti. Blog yazımda daha fazla bilgi edinebilirsiniz: http://mrafayaleem.com/2016/02/08/live-mysql-schema-changes-with-percona/ .

Kesinlikle denemelisin pt-online-schema-change. AWS RDS üzerinde birden çok slave ile geçiş yapmak için bu aracı kullanıyorum ve benim için çok iyi çalıştı. Bunun nasıl yapılacağına dair size yardımcı olabilecek ayrıntılı bir blog yazısı yazdım.

Blog: http://mrafayaleem.com/2016/02/08/live-mysql-schema-changes-with-percona/

Kukla sütunlar, türlerini tahmin edebiliyorsanız (ve onları null yapılabilir hale getirebiliyorsanız) iyi bir fikirdir. Depolama motorunuzun boş değerleri nasıl işlediğini kontrol edin.

MyISAM, telefonda, havaalanından geçerken bir masa isminden bahsetseniz bile, her şeyi kilitleyecektir. Sadece bunu yapar ...

Bununla birlikte, kilitler gerçekten o kadar da önemli değil; Her satıra yeni sütun için varsayılan bir değer eklemeye çalışmadığınız, ancak boş olarak kalmasına izin verdiğiniz ve depolama motorunuz yazmaya devam etmeyecek kadar akıllı olduğu sürece, yalnızca bir kilitle tamam olmalısınız meta verileri güncellemek için yeterince uzun süre tutuldu. Yeni bir değer yazmaya çalışırsanız, kızardınız demektir.

TokuDB, sütunlar ekleyebilir / bırakabilir ve "sıcak" dizinleri ekleyebilir, tablo işlem boyunca tamamen kullanılabilir. Www.tokutek.com adresinden temin edilebilir.

Pek sayılmaz.

Sonuçta, tablonun temel yapısını değiştiriyorsunuz ve bu, temeldeki sistem için oldukça önemli olan bir bilgi parçasıdır. Ayrıca (muhtemelen) verilerin çoğunu diskte hareket ettiriyorsunuz.

Bunu çok yapmayı planlıyorsanız, tabloyu ileride kullanabileceğiniz "sahte" sütunlarla doldurmanız daha iyi olur.