Veritabanından Silinmiş Alanı Temizle


10

Onları silmiş alanlar oluşturdum. Alanlar için tablolar silindikten sonra gitti, ancak hala field_configvefield_config_instance

Onları temizlemek için yine de var mı?

Teşekkürler

Yanıtlar:


10

Girişler field_configve field_config_instancemuhtemelen bir değeri vardı olacaktır 1içinde deletedkolona.

Bu, silinmek üzere işaretlendikleri anlamına gelir, ancak cron çalıştırılıncaya kadar gerçekten silinmeyecektir (silinmiş alan verileri temizlenir field_cron()).


adamsın. Ben yüklü phpmyadmin yoktu, bu yüzden ssh bağlantısı yoluyla bu iki tablo için diğer sütunları kontrol etmedi. teşekkürler Clive
lusketeer

12

drush kullanarak:

$ drush eval "field_purge_batch(500)"

birkaç kez çalıştırmanız veya $ batch_size değerini artırmanız gerekebilir, o zaman cron çalıştırıldıktan sonra bile field_deleted ve field_deleted_revision tabloları olabilir.

sorgu

SELECT * FROM `field_config` WHERE `deleted` = 1
SELECT * FROM `field_config_instance` WHERE `deleted` = 1

boş kalırsanız, artık kalan tabloları güvenle silebilirsiniz


Bu harika bir cevap, teşekkürler @ decibel.places!
joelpittet

6

Silinen verileri kaldırmak için cron çalıştırmaya alternatif olarak field_purge_batch ($ batch_size) 'yi manuel olarak çalıştırabilirsiniz .

İşlevi manuel olarak çalıştırmak için aşağıdakilerden birini yapabilirsiniz:

  • Bir php dosyasında Bootstrap Drupal
  • Menü kanca sayfası geri arama oluşturma
  • Devel modülünüz kurulu ise, / devel / php adresini ziyaret edin.

Kullanılacak $ batch_size, sunucu ortamınıza ve gereksinimlerinize bağlı olarak değişir. 5 gibi düşük ve 10000 kadar yüksek değerler kullandım.


4

Bu Drupal 8 kullanıcıları için,

Bunu da yaşadım, kodu kazın. Bunu yaptıktan sonra alanların silinmemesinin tüm nedenlerini buldum:

  • cron gazillion kez icra
  • drush eval "field_purge_batch (500)" milyon kere çalıştır

Alanlar gitmiyor, bu alandaki, field_purge_batch içindeki bir mantık nedeniyle

  // We cannot purge anything if the entity type is unknown (e.g. the
  // providing module was uninstalled).
  // @todo Revisit after https://www.drupal.org/node/2080823.
  if (!isset($info[$entity_type])) {
    continue;
  }

Bağımlı olan modüller kaldırılır. alanların kaldırılmamasının nedeni budur.

Bunu nasıl çözebilirim? Öncelikle modülü yeniden kurmanız ve bu alanları temizlemeniz ve geri kaldırmanız önerilir. Hangi modülü yeniden yüklemeniz gerektiğini bulmak için:

$fields = entity_load_multiple_by_properties('field_config', array(
  'deleted' => TRUE,
  'include_deleted' => TRUE,
));
dpm($fields); // this is devel module of var_dump

// check the protected member called "dependencies"

Eğer modülü yeniden kurma yaklaşımına gitmek istemiyorsanız, hemen silebilirsiniz, davranışın ne olduğundan emin değilim ama işi yapmalı.

Önce yedekleme !!!

Evet, tembel olma, bir şeyler ters giderse kıçını kurtaracak.

$fields = entity_load_multiple_by_properties('field_config', array(
  'deleted' => TRUE,
  'include_deleted' => TRUE,
));

foreach ($fields as $field) {
  $field->delete();
}

// Retrieve all deleted field storages. Any that have no fields can be purged.
$deleted_storages = \Drupal::state()->get('field.storage.deleted') ? : array();
foreach ($deleted_storages as $field_storage) {
  $field_storage = new FieldStorageConfig($field_storage);
  $fields = entity_load_multiple_by_properties('field_config', array('field_storage_uuid' => $field_storage->uuid(), 'include_deleted' => TRUE));
  if (empty($fields)) {
    field_purge_field_storage($field_storage);
  }
}

Son kez cron yap. Umarım sorunu düzeltir :)


Drupal Cevaplarına Hoşgeldiniz! Lütfen birden fazla soru için aynı cevabı kopyalayıp yapıştırmayın. Yineleniyorsa, yinelenen olarak işaretleyin.
kiamlaluno

-1

Herhangi bir çözüm bulamıyorum. Bu yüzden onları bu iki tablodan manuel olarak sildim.


Bu da benim başıma geldi: üretimde alanlar yarattı, test sistemine kopyaladı. Üretimdeki alanlara geri döndü, tekrar test sistemine kopyalandı. Cron muhtemelen bu arada çalışmıştır, bu nedenle test veritabanı düzgün bir şekilde düşürülmediği / yeniden oluşturulmadığından, veri ve revizyonlar için iki artık tablo etrafta tutuldu ... Bulgular: * her zaman bir yedekleme almadan ÖNCE cron'u çalıştırın * bir test veritabanına aktarırken * , her zaman bırak ve yarat
Christen'i yendi

drupal.org/node/1351506 bu hala bilinen bir sorundur.
Kevin Morse

-1

Drupal cron'un birkaç kez çalıştırılırsa, drupal alan tablolarını ve içeriğini siler. Sonraki adımları birkaç kez cron'u çalıştırmak için takip edebilirsiniz, ancak bu adımlar sisteminizi, web'inizi veya barındırma işleminizi engelleyebilir, ancak sisteminizi kontrol ederseniz yapabilirsiniz.

  1. Drupal durum sayfasına gidin (admin / raporlar / durum).
  2. Sayfada, "cron'u manuel olarak çalıştır" ve "cron'u dışarıdan çalıştır" gibi bir bağlantı ve cron_key parametresine sahip bir bağlantı görebilirsiniz. Bu bağlantıyı kopyalayın.
  3. Bir terminale gidin (linux veya mac terminali).
  4. Sonraki bash komutunu yazın:

    gerçekken; kıvrılma [köşeli parantezleri silerek kopyalanan bağlantıyı buraya koyun]; yapılan;

  5. Enter tuşuna basın. Komut sınırsız kez çalıştırılacaktır.

  6. Phpmyadmin gibi veritabanınıza gidebilir ve "silme" adlı tabloları arayabilirsiniz. Satırların nasıl silinmekte olduğunu görebilir ve aşağı inebilirsiniz. Adında "delete" olan tüm tablolar boşaldığında, bırakılır. Veritabanında silinmiş tablo göremediğinizde, son 7 adıma geçebilirsiniz.
  7. Terminaldeki bash komutunu durdurdu. Ctrl + c tuşlarına basabilirsiniz. Yapamıyorsanız terminali kapatın.

Daha önce yorumladığım gibi, en iyi çözüm değil, ama basit, işe yarıyor, çünkü yanlış bir şey yapmayacaksınız, çünkü sadece drupal cron'u çalıştırıyorsunuz, bu yüzden bazı yanlış php kodu ile her şeyi kırabilirsiniz. Aksi takdirde, sunucuyu, sistemi, barındırma veya web'inizdeki herhangi bir şeyi doyurabilirsiniz, çünkü bu adımlar cron ve web kaynakları tüketimini birçok kez çalıştırır, ancak kaynakların kontrolüne sahipseniz, çok fazla şey yoktur. tabloları veya satırları temizlemek ya da sisteminiz için güvenli olduğunu biliyorsunuz, bunu yapabilirsiniz.

Ve biliyorum, bu en iyi çözüm değil. Ama işe yarıyor. Belki de durumunuz için en kolay ve en iyi çözümdür.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.